Data Processing Addendum

Draft for counsel's review. Not yet in effect.

1. Scope and order of precedence

1.1 This Data Processing Addendum ("DPA") forms part of the Terms of Service or other agreement between [Waltz legal entity] ("Waltz") and the Customer (the "Agreement"). It applies when Waltz processes Customer Personal Data in providing the Service.

1.2 If this DPA conflicts with the Agreement, this DPA wins for the processing of personal data. If the Standard Contractual Clauses conflict with this DPA, the Clauses win.

1.3 Terms not defined here have the meaning in the Agreement.

2. Definitions

Data Protection Laws: the GDPR (Regulation (EU) 2016/679), the UK GDPR and Data Protection Act 2018, the Swiss Federal Act on Data Protection, the California Consumer Privacy Act as amended (CCPA), and other US state privacy laws, each as they apply to the processing.
Customer Personal Data: personal data in Customer Data that Waltz processes on the Customer's behalf.
Controller, processor, data subject, personal data, processing, personal data breach, supervisory authority: as defined in the GDPR. "Business", "service provider", "sell" and "share" have the CCPA's meanings.
Subprocessor: a third party Waltz engages that processes Customer Personal Data.
SCCs: the standard contractual clauses approved by Commission Implementing Decision (EU) 2021/914.
UK Addendum: the International Data Transfer Addendum to the SCCs issued by the UK Information Commissioner, version B1.0.

3. Roles

3.1 The Customer is the controller (or a processor acting for its controller) of Customer Personal Data. Waltz is its processor (or subprocessor).

3.2 Waltz is an independent controller of personal data it processes for its own business: account and sign-in data, billing contacts, support correspondence, security logs, and de-identified aggregate statistics about use of the Service. The Privacy Policy covers that data.

3.3 The Customer is responsible for the lawfulness of the Customer Personal Data it provides and for giving any notices and obtaining any consents, consultations or approvals that apply, including with employees or their representatives.

4. Details of the processing (Annex 1)

Item	Detail
Subject matter	Providing the Service: deriving facts from the systems the Customer connects, and composing, delivering and hosting Briefs
Duration	The term of the Agreement, plus the export and deletion period in section 11
Nature	Collection through integrations and uploads; analysis; storage; composition; delivery by email and Slack; display in the console and Brief viewer
Purpose	Only to provide, secure and support the Service for the Customer, under its documented instructions
Data subjects	The Customer's employees and contractors who contribute to its software (commit and pull request authors, reviewers, agent users, assignees and responders); people in its org chart; Brief recipients; its members using the Service
Categories of personal data	Hashed source identities (hashes of commit email addresses and vendor user ids); vendor user ids and logins; work email addresses; names, titles, levels, managers and teams from the org chart; activity metadata (timestamps of commits, reviews, merges, deploys, agent sessions); agent usage counts and cost per person; annotations and their authors; any personal data in pull request titles, ticket titles or code excerpts that a Brief cites
Data not collected	Source code (analyzed, never stored); chat message bodies; prompts and responses of AI agents; secret values; compensation and performance data; end-user data from error trackers and analytics
Special categories	None intended. The Customer won't send special category data or criminal-offence data to the Service
Frequency	Continuous, while integrations are connected
Retention	Section 11, and the retention table in the Privacy Policy

5. Waltz's obligations

5.1 Instructions. Waltz processes Customer Personal Data only on the Customer's documented instructions. The Agreement, this DPA and the Customer's configuration of the Service (the integrations it connects, the scopes it grants, its visibility and model settings) are the Customer's complete instructions. Waltz will tell the Customer if it believes an instruction breaks Data Protection Laws, and if the law requires processing without an instruction, unless the law forbids telling.

5.2 Confidentiality. Everyone Waltz authorizes to process Customer Personal Data is bound by confidentiality.

5.3 Security. Waltz implements the measures in Annex 2 (section 14). It may update them if the overall level of protection doesn't fall.

5.4 Assistance. Taking into account the nature of the processing, Waltz helps the Customer meet its obligations on data subject requests, security, breach notification, data protection impact assessments and prior consultation.

5.5 Isolation. Waltz keeps each org's Customer Personal Data logically separate. One org's data is never used in, or to generate, another org's Brief, and never used to prompt or tune a model for another org.

5.6 No training. Waltz does not use Customer Personal Data to train or fine-tune machine-learning models.

5.7 Aggregates. Waltz may create de-identified aggregate statistics from use of the Service, and, where the Customer has turned on benchmark contribution, pooled benchmark metrics under the protection rules in the Agreement. Such data does not identify the Customer or any person and is not Customer Personal Data.

6. Subprocessors

6.1 Authorization. The Customer gives general authorization for Waltz to engage subprocessors. The current list, with each one's purpose, the data it receives and its location, is at Subprocessors.

6.2 Changes. Waltz will give at least [30] days' notice of a new subprocessor by updating the list and by email to Customers who [subscribe to updates / to the org's owners]. The Customer may object on reasonable data-protection grounds within that period. The parties will discuss the objection in good faith. If Waltz can't reasonably accommodate it, the Customer may terminate the affected Service and receive a refund of prepaid fees for the remaining term.

6.3 Flow-down. Waltz binds each subprocessor by written terms that protect Customer Personal Data at least as well as this DPA, and remains liable for its subprocessors' performance.

6.4 Not subprocessors. Integrations the Customer connects (for example GitHub, GitLab, Jira, Linear, Slack and AI agent vendors) and a model provider the Customer brings with its own key are the Customer's own service providers. Data flows to and from them on the Customer's instruction.

7. International transfers

7.1 The Service is hosted in the United States. Waltz may transfer Customer Personal Data to the United States and to the locations on the subprocessor list.

7.2 EEA. For transfers from the EEA to a country without an adequacy decision, the SCCs apply and are incorporated by reference: Module 2 (controller to processor) where the Customer is a controller, and Module 3 (processor to processor) where it is a processor. The parties choose: clause 7 (docking) applies; clause 9 option 2 (general authorization), with the notice period in section 6.2; the optional wording in clause 11 does not apply; clause 17 option 1, the law of [Ireland]; clause 18, the courts of [Ireland]. Annex I is section 4 of this DPA, with the parties' details in the Agreement. Annex II is section 14. Annex III is the subprocessor list.

7.3 UK. For transfers from the UK, the UK Addendum applies, completed with the information in section 7.2 and this DPA. Either party may end it under its section 19 [counsel to choose: "neither party" / "importer" / "exporter"].

7.4 Switzerland. For transfers from Switzerland, the SCCs apply with these changes: the Swiss Federal Data Protection and Information Commissioner is the supervisory authority; references to the GDPR include the FADP; and "member state" includes Switzerland, so data subjects there can sue in their place of habitual residence.

7.5 [Where Waltz is certified under the EU-US Data Privacy Framework, its UK Extension or the Swiss-US framework, it may rely on that certification instead. Counsel to confirm whether Waltz will self-certify.]

8. Data subject requests

If Waltz receives a request from a data subject about Customer Personal Data, it will refer the person to the Customer and won't answer it except as the Customer instructs or the law requires. The console lets admins find, correct and remove a person's identities, org chart entry and recipient addresses. Waltz will help with what the Customer can't do through the Service.

9. Personal data breaches

9.1 Waltz will notify the Customer without undue delay, and in any case within [48] hours, after becoming aware of a personal data breach affecting Customer Personal Data.

9.2 The notice will describe, as far as known: the nature of the breach, the categories and approximate numbers of data subjects and records, the likely consequences, and the measures taken or proposed. Waltz will add information as it learns it, and take reasonable steps to contain and remedy the breach.

9.3 Notification is not an admission of fault.

10. Audits

10.1 Waltz will make available the information reasonably needed to show compliance with this DPA. [When Waltz holds a SOC 2 report or ISO 27001 certificate, it will provide it under confidentiality, and that will satisfy audit requests except where a supervisory authority requires more.]

10.2 Where the information isn't enough, or a supervisory authority requires it, the Customer may audit Waltz once a year, on at least [30] days' notice, during business hours, at its own cost, through an independent auditor bound by confidentiality, without access to other customers' data.

11. Deletion and return

11.1 For [30] days after the Agreement ends, an admin may export Customer Data [in a format and by means counsel and product to define]. Then Waltz deletes Customer Personal Data from the Service, including databases, object storage and engine caches, within [30] further days.

11.2 Backups are deleted on their own cycle: database backups within 7 days, prior versions of stored objects within 30 days. Server logs, which may contain IP addresses but not Customer Data content, are deleted within 30 days.

11.3 Waltz may keep data the law requires it to keep, protected under this DPA, and a record that the deletion took place.

11.4 Source code is not part of this process because Waltz never stores it: each analysis run deletes its clone when the run ends.

12. US state privacy laws

12.1 For the CCPA and similar laws, Waltz is the Customer's service provider (or processor) for Customer Personal Data.

12.2 Waltz will not:

sell or share Customer Personal Data;
retain, use or disclose it for any purpose other than the business purposes in the Agreement, or outside the direct business relationship with the Customer;
combine it with personal information Waltz receives from others or collects itself, except as the CCPA allows for service providers (for example, to detect security incidents).

12.3 Waltz will comply with the CCPA's obligations that apply to service providers, give the same level of privacy protection the CCPA requires, and tell the Customer if it can no longer meet them. The Customer may take reasonable steps to stop and remediate unauthorized use.

12.4 Waltz certifies that it understands and will comply with these restrictions.

13. Liability

Each party's liability under this DPA is subject to the limits in the Agreement. [Counsel to decide whether data-protection breaches carry a separate, higher cap.] Nothing here limits a data subject's rights under the SCCs.

14. Annex 2: Technical and organizational measures

Data minimization

Integrations request read scopes only, except delivery (for example, posting to Slack) and write-back the Customer separately grants.
Each kind of integration has a projection: only allow-listed fields are kept, applied before anything is stored or logged. Raw payloads never reach logs, dead-letter queues or traces.
Facts carry hashed source identities, never names or email addresses. [Per-org keyed hashing is planned.]
Brief deliveries keep a per-org hash and a masked form of the recipient's address, not the address. Opens are not recorded.

Source code

Code is analyzed in a short-lived container per job: a read-only root filesystem, a size-capped non-executable temporary filesystem for the clone, a non-root user, all Linux capabilities dropped, CPU, memory and process limits, and no access to Waltz's internal network, the cloud metadata service or cloud credentials.
The clone credential is read-only, limited to that repository and valid for an hour. It is passed in the environment and removed once read.
The clone is deleted on every path, success or failure. An end-to-end test plants a marker in a repository's code, comments and files, runs analysis, and checks that the marker appears in no database table and no stored object.
[Egress allow-lists for the runner: planned.]

Encryption

TLS for all traffic. Email to recipients requires TLS; a receiving server without it gets no email.
At rest: database and object storage encrypted with AWS KMS keys. Object storage refuses unencrypted uploads and non-TLS access.
Integration credentials: envelope encryption with a per-org data key and the org id as context, decrypted only in the process that uses them, destroyed when the integration is disconnected.
Platform secrets in AWS Systems Manager Parameter Store as encrypted SecureStrings, read at start-up.

Access

Member roles (owner, admin, member, viewer) per org. Every API request is checked against the caller's org and role.
Sign-in by single-use email link (15 minutes; only its hash is stored). Short-lived access tokens (10 minutes) and refresh tokens in HttpOnly, SameSite=Strict cookies; sessions end after [30] days idle and [90] days at most.
Brief links are signed, expiring (14 days by default) and bound to one edition and one recipient. Admins can require sign-in.
CLI and MCP tokens are stored hashed, scoped to one org and one purpose, and stop working when revoked or when their maker leaves.
[Enterprise: single sign-on (SAML or OIDC): planned.]

Monitoring and logging

Admin actions are written to an audit log.
Request logs blank tokens. Model calls are logged without content. MCP calls are logged without arguments or results.
Email bounce and complaint rates are monitored with alarms.

Resilience

Daily automated database backups kept for 7 days. Prior object versions kept for 30 days.
[Single availability zone at launch; multi-AZ: planned.]

Organizational

Least-privilege access for Waltz personnel. [Background checks, security training, access reviews and an incident response plan: counsel and operations to confirm.]
Vulnerability reports to [security@waltz.run].
[SOC 2: planned, not yet held.]

15. Annex 3: Subprocessors

See Subprocessors.