Data processing addendum

Last updated [DATE - SET AT PUBLICATION]

This addendum forms part of the terms of service between [MARSHAL LEGAL ENTITY NAME] ("Marshal") and the customer ("Customer"). It applies when Marshal processes personal data on the Customer's behalf. Where this addendum and the terms conflict on data protection, this addendum wins.

1. Definitions

Data protection law means the laws that apply to the processing described here, which may include the EU General Data Protection Regulation, the UK GDPR and Data Protection Act 2018, and US state privacy laws. [APPLICABLE LAWS - COUNSEL TO CONFIRM THE FINAL LIST.] Controller, processor, personal data, processing, data subject, and personal data breach have the meanings given in that law. Customer personal data means personal data within the customer data that Marshal processes under the terms.

2. Roles

1. The Customer is the controller of customer personal data. Marshal is the processor.
2. Marshal is an independent controller for the account data of the individuals who sign in to Marshal, and for its own security and billing records. That processing is described in the privacy policy and is outside this addendum.
3. Where the Customer is itself a processor for another organization (for example a DevOps agency managing a client's cloud), Marshal is a subprocessor, and the Customer confirms it has authority to appoint one.
4. The Customer is responsible for the lawfulness of the data it makes available to Marshal, for having a legal basis, and for giving any notices required to the individuals concerned. This matters most for device telemetry from staff computers and for cloud change records that identify individuals.

3. Scope of processing

1. Subject matter and purpose. Providing the Marshal service: reading cloud cost and configuration data, monitoring availability and certificates, reporting on tracked computers, producing recommendations and explanations, sending alerts, and carrying out infrastructure changes the Customer approves.
2. Duration. For as long as the Customer's organization exists, then as set out in section 8.
3. Categories of data subject. The Customer's personnel and contractors who use Marshal; the Customer's personnel whose actions appear in cloud audit records; the Customer's personnel who use computers on which the Customer installs the device reporter; recipients the Customer configures for alerts.
4. Types of personal data. Names, business email addresses, roles and permissions, IP addresses in account security records, cloud identity strings in change records, IP addresses and network rules within cloud resource configuration, and per-computer facts: hostname, operating system version, disk and memory figures, pending update count, firewall state, and disk encryption state.
5. Special category data. None is requested, required, or intended. The Customer must not put special category data into the service, for example in a resource name or tag.

4. Marshal's obligations

1. Marshal processes customer personal data only on the Customer's documented instructions. The terms, this addendum, and the Customer's use of the product (including each approval of an action) are those instructions. If Marshal must process for a legal obligation instead, it will tell the Customer first unless the law forbids it.
2. Marshal will tell the Customer if it believes an instruction breaks data protection law.
3. People at Marshal with access to customer personal data are bound by confidentiality obligations and get access only where their role needs it.
4. Marshal will not sell customer personal data, share it for advertising, or use it to train artificial intelligence models.
5. Marshal will give reasonable help with the Customer's data protection impact assessments and consultations with supervisory authorities, taking account of the information available to it.

5. Data subject requests

If an individual contacts Marshal about customer personal data, Marshal will not answer the substance itself. It will pass the request to the Customer without undue delay and help the Customer respond, including by locating, correcting, exporting, or deleting the data. Export is partial today: cost and security evidence exports exist in the product, and anything wider is produced manually on request.

6. Security

Marshal maintains the technical and organizational measures in Annex 2, which describes what is implemented today. Marshal may change a measure, but not in a way that materially lowers overall security.

7. Personal data breach

1. Marshal will notify the Customer without undue delay, and in any case within [BREACH NOTIFICATION PERIOD - COMPANY TO CONFIRM; 72 HOURS IS THE COMMON COMMITMENT] of becoming aware of a personal data breach affecting customer personal data.
2. The notice will describe what is known: the nature of the breach, the categories and approximate number of records and individuals affected, the likely consequences, and the steps taken or proposed. Where the information is not all available at once, Marshal will send it in stages.
3. Marshal will help the Customer meet its own notification duties. Notice under this section is not an admission of fault.
4. Notices go to the Customer's organization owners by email. The Customer must keep those addresses current.

8. Deletion and return

1. The Customer can end Marshal's access to its cloud at any time and without Marshal's involvement, by removing the role it installed, uninstalling the cluster agent, or removing a tracked computer.
2. On termination, or on request, Marshal deletes customer personal data. Organization deletion is implemented in the product: it erases the organization's rows from the primary database, deletes its billing, usage, and uptime rows from the analytics store, and clears its cached data. The analytics and cache steps are best effort and are individually reported as succeeded or failed, so a partial erasure is never recorded as a complete one; a failed step is repeated until it succeeds.
3. Deleting an organization does not delete an individual's login record or their account security log, which sit outside any single organization. Marshal deletes those separately on request.
4. Data in backups is deleted as the backups age out. See [BACKUP RETENTION PERIOD - COMPANY TO CONFIRM]. Until then it remains subject to this addendum and is not restored into live use.
5. Marshal may retain data where the law requires it, for the period required, and only for that purpose.

9. Subprocessors

1. The Customer gives general authorization for Marshal to appoint subprocessors. The current list is at marshalcloud.com/legal/subprocessors and forms part of this addendum.
2. Marshal will give at least [SUBPROCESSOR CHANGE NOTICE PERIOD - COMPANY TO CONFIRM; 30 DAYS IS COMMON] notice before a new subprocessor starts processing customer personal data, by [NOTICE MECHANISM - COMPANY TO CONFIRM: EMAIL TO OWNERS, OR A SUBSCRIBABLE FEED ON THE SUBPROCESSORS PAGE].
3. The Customer may object on reasonable data protection grounds within that notice period. The parties will discuss it in good faith. If it cannot be resolved, the Customer may terminate the affected part of the service without penalty. [REFUND ON SUCH TERMINATION - COMPANY TO CONFIRM.]
4. Marshal imposes data protection obligations on each subprocessor that are no less protective than this addendum, and remains liable to the Customer for its subprocessors' performance.
5. Some subprocessors are engaged only if the Customer turns on the relevant feature. Slack is engaged only if the Customer connects Slack; the email provider is engaged only for the alert channels the Customer configures, and the Customer can instead point Marshal at its own mail server.

10. International transfers

Where customer personal data is transferred out of the European Economic Area, Switzerland, or the United Kingdom to a country without an adequacy decision, the parties incorporate the European Commission's standard contractual clauses by reference, with the UK International Data Transfer Addendum and the Swiss adaptations as applicable.

• [SCC MODULE - COUNSEL TO SELECT. Module Two (controller to processor) is expected for a direct customer; Module Three (processor to processor) where the Customer is itself a processor, for example an agency.]
• [CLAUSE 7 DOCKING, CLAUSE 9 SUBPROCESSOR OPTION AND NOTICE PERIOD, CLAUSE 11 INDEPENDENT DISPUTE RESOLUTION OPTION, CLAUSE 17 GOVERNING LAW, CLAUSE 18 FORUM - COUNSEL TO SELECT.]
• [ANNEXES: the parties intend Annex 1 to be section 3 of this addendum and Annex II to be Annex 2 below. COUNSEL TO CONFIRM THE MAPPING.]
• [TRANSFER IMPACT ASSESSMENT - COUNSEL TO PREPARE.]

11. Audit

1. Marshal will make available the information reasonably needed to show compliance with this addendum, including its security documentation and any third-party audit report it holds.
2. The Customer may audit no more than once in any twelve months, and more often only after a personal data breach or where a supervisory authority requires it. The Customer gives at least 30 days' written notice, audits during business hours, does not disrupt the service, keeps findings confidential, and bears its own costs. An audit must not give access to another customer's data or to Marshal's production systems.
3. Marshal may satisfy an audit request with a current independent report. [MARSHAL HOLDS NO COMPLETED SOC 2 OR ISO 27001 REPORT TODAY. DO NOT STATE OTHERWISE UNTIL ONE EXISTS.]

12. Liability

Liability under this addendum is subject to the limitations in the terms of service, except where data protection law does not allow that. [INTERACTION BETWEEN THE LIABILITY CAP AND SCC LIABILITY - COUNSEL TO CONFIRM.]

Annex 1: processing details

Section 3 of this addendum sets out the subject matter, duration, nature and purpose of processing, the categories of data subject, and the types of personal data. The competent supervisory authority is [SUPERVISORY AUTHORITY - COUNSEL TO DETERMINE].

Annex 2: technical and organizational measures

These describe what is implemented in the product today. Items still to be completed are named as such rather than omitted.

Access control

• Every request is authorized against the caller's membership of the organization it names, and every record fetched by identifier is checked against the caller's organization through a single shared enforcement point.
• Five roles per organization (owner, admin, infosec, sre, viewer) determine what a user can read and do. Owner and admin manage the account and its connections; infosec owns security and compliance and is the lowest role that may approve an infrastructure change or sign off a compliance control; sre reads everything and runs incidents; viewer is read-only.
• Marshal personnel roles are separate and limited: a reliability role and a compliance-oversight role are read-only across organizations; a support role holds no cross-organization access.
• API keys are stored only as hashes, are shown once, and can be revoked.
• Not yet implemented: multi-factor authentication and single sign-on for Marshal logins.

Encryption and secrets

• Traffic is served over TLS.
• Cloud credentials, single sign-on tokens for cloud connections, and connector API keys are encrypted at rest with an application key supplied to the application at runtime as configuration, never stored in the codebase or the database. Migration to envelope encryption with a hardware key management service is planned and not yet done.
• Secrets are never returned by the API and never written to logs; webhook addresses are shown host-only, and delivery failures record only the error type.
• Passwords are stored as PBKDF2-HMAC-SHA256 hashes at 600,000 iterations with a per-user salt.
• The default cloud connection uses a cross-account role and a secret external ID, so Marshal holds no long-lived cloud keys.

Change control on customer infrastructure

• Only actions in a fixed, reviewed catalog can be proposed or executed, and each is bound at build time to a matching, minimally scoped cloud permission.
• Every action requires a named human approval from a user holding an approving role. There is no automatic mode.
• Live state is re-checked before a change, a snapshot is taken before anything is destroyed and kept 14 days, and each step is recorded with who proposed and who approved it. Rollback is available where the action is reversible.
• The AI surface has no write capability. This is enforced by the set of tools it is given, not by instructions in a prompt.

Network and application security

• Outbound requests to customer-supplied addresses are resolved and rejected if they point at private, loopback, link-local, or metadata addresses, and the connection is pinned to the validated address, with every redirect re-validated.
• Database and analytics queries use parameters; identifiers come from allowlists.
• Per-address rate limits, stricter limits on authentication endpoints, a per-organization daily AI usage cap, and a cap on alert delivery attempts.
• Data reaching the AI is length-limited and stripped of control characters, error text is stripped of URL credentials, query strings, and paths, and only an allowlist of resource shape fields is indexed for search.

Segregation, logging, and resilience

• Every stored record carries its organization identifier, including cached entries, and queries are scoped by it.
• Action execution logs, alert delivery records, and account security events including sign-in IP addresses are retained.
• Deletion of an organization removes its data from the primary database, the analytics store, and the cache, and reports which of those actually completed.
• Still to be completed: centralized log retention with a stated period, formal access reviews, a documented incident response runbook, an independent penetration test, and a documented backup and restore schedule. [OPERATIONAL CONTROLS - COMPANY TO COMPLETE BEFORE MAKING ASSURANCE CLAIMS.]