Data Processing Agreement
Version 1.0.0-draft · drafted 2026-08-16
This is a working draft. It has not been reviewed or approved by a lawyer, and it does not yet name a contracting entity or a governing law. 8 questions in it are still open for legal review, and each one is marked in the text below.
# Data Processing Agreement (TEMPLATE) > **TEMPLATE — NOT LEGALLY REVIEWED, NOT EXECUTABLE.** > This is a skeleton with a factual annex. The contractual terms are placeholders. > **A technical control existing does not mean the corresponding contractual > obligation is satisfied.** Do not send this to a customer. ## 1. Parties **[LEGAL REVIEW REQUIRED — contracting entity]** and the Customer. ## 2. Roles **[LEGAL REVIEW REQUIRED — controller / processor characterisation]** including whether the roles differ between account data and the advertising data processed on the Customer's behalf. ## 3. Subject matter, duration, nature and purpose Subject matter: providing advertising reporting, analysis and automation over data the Customer authorises the service to read. **[LEGAL REVIEW REQUIRED — duration, and its relationship to the subscription term and to the termination effects in the Terms.]** ## 4. Categories of data subjects and personal data Data subjects: the Customer's own personnel who hold accounts, and — indirectly — people who placed orders in a connected store. Personal data: account identity (name, email); authentication credentials; audit records of user actions. For store orders, **customer identity is reduced to a salted one-way hash at ingest**; no email address, name or address is stored. ## 5. Instructions **[LEGAL REVIEW REQUIRED]** Standard wording on processing only on documented instructions, confidentiality of personnel, and assistance obligations. ## 6. Sub-processors The maintained sub-processor list forms part of this agreement. **[LEGAL REVIEW REQUIRED — authorisation model and change-notice period.]** ## 7. International transfers **[LEGAL REVIEW REQUIRED — whether transfers occur, to where, and the mechanism (SCCs or otherwise).]** No hosting provider or region has been selected, so this cannot be stated. ## 8. Security incidents **[LEGAL REVIEW REQUIRED — notification obligations and timescales.]** The service has structured logging with credential redaction, an alert catalogue, and operational runbooks. **No monitoring or paging provider is configured**, so there is no automated notification today. A capability does not create a commitment. ## 9. Deletion and return On request the service deletes a workspace or an account: the subject is marked immediately, access stops at that moment, and a staged purge erases the data. Data can be exported before deletion. Two limits are stated in the annex rather than implied: erasure does not reach database backups, and it does not reach the advertising platforms. **[LEGAL REVIEW REQUIRED — the contractual erasure obligation, its window, and how the backup limitation is described.]** ## 10. Audit rights **[LEGAL REVIEW REQUIRED.]** No certification exists. No audit has been performed. ## 11. Liability **[LEGAL REVIEW REQUIRED.]** --- # Annex — technical and organisational measures *This annex describes controls that exist in the software today. It is factual. It is not a certification and not a compliance claim.* ## Tenant isolation Each workspace's data is isolated in four layers: a scoped database client that adds the tenant predicate to every query; an authorization context resolved server-side from the caller's membership; **PostgreSQL row-level security policies enforced by the database itself**; and a generated test suite that attempts cross-tenant access and asserts it fails. Row-level security is FORCED, so it applies even to the table owner. A verified audit confirms every tenant table carries a policy, and a closed-world test fails if a future table is added without one. ## Database roles Three roles with different privileges. The application's role is subject to row-level security and **holds no privilege at all** on the tables containing password hashes, sessions and verification tokens. It cannot UPDATE or DELETE the audit log. A separate identity role, exempt from row-level security, is restricted by grant to identity tables only. ## Encryption Platform access tokens are encrypted at rest with AES-256-GCM using a versioned keyring held outside the database. Passwords are hashed with Argon2id. Store-customer identifiers are stored only as a peppered one-way hash. ## Access control Role-based permissions within a workspace. Membership is re-read from the database on every request, so a revoked permission takes effect immediately rather than at session expiry. An arrangement between an agency and a client grants no access by itself — access requires a membership. ## Audit logging An append-only record of security-relevant actions, enforced by database grant rather than by convention. Retained through deletion, so an erasure does not destroy the evidence that it happened. ## Application security A nonce-based Content Security Policy with no `unsafe-inline` in script-src; security headers including HSTS; rate limiting on authentication, OAuth and expensive operations; cross-origin rejection on state-changing endpoints; webhook signatures verified before any database work, with replay protection. ## Deletion and export Documented, tested workflows. Export excludes credentials, audit records and billing records. Deletion is staged and idempotent, destroying credentials first so a partial failure cannot leave a usable token. ## Backups Backups are taken separately from live data and **a deletion does not reach them**. A restore drill has been executed and documented, confirming that a backup restores into a working, isolated database with its policies and grants intact. ## What is NOT in place Stated so the annex cannot be read as more than it is: - no error-tracking provider is configured; - no monitoring or paging provider is configured, so alerting is a catalogue rather than an active system; - no certification of any kind has been obtained, and no external audit or penetration test has been performed; - no hosting provider has been selected, so no statement about physical location or regional processing can be made.
