Data Processing Agreement

Effective date: [effective date]

This Data Processing Agreement ("DPA") is part of the Terms of Service between [Company legal name] ("Dynamic Document API", "we", "us") and the Customer. It applies whenever we process personal data in Customer Content for the Customer and takes effect with the Terms; no signature is needed. A countersigned copy is available from privacy@dynamicdocumentapi.com; Scale and Enterprise customers may agree amendments in an Order Form.

1. Definitions

"Controller", "processor", "personal data", "processing", "data subject" and "personal data breach" have the meanings given in the GDPR. "Data Protection Laws" means the GDPR, the UK GDPR, the Swiss FADP and other data protection laws that apply. "Customer Personal Data" means personal data within Customer Content that we process for the Customer. "SCCs" means the Standard Contractual Clauses in Commission Implementing Decision (EU) 2021/914. Other capitalised terms follow the Terms.

2. Roles and responsibilities

The Customer is the controller of Customer Personal Data, or a processor acting for its own controllers, and we are its processor or sub-processor. Personal data we process for our own purposes, such as account, billing and security data, is covered by our Privacy Policy, not by this DPA.

The Customer is responsible for the lawfulness of its instructions, for having a legal basis and giving required notices, and for the content it submits. It must not submit special categories of personal data without appropriate safeguards, and never protected health information, as set out in the Acceptable Use Policy.

3. Processing details

Annex 1 describes the subject matter, duration, nature and purpose of the processing, the data categories, the data subjects and retention.

4. Our instructions

We process Customer Personal Data only on the Customer's documented instructions. These instructions consist of the Terms, this DPA, the documentation, the settings chosen in a Workspace (Region, retention, request logging, storage destinations, webhooks) and the API requests the Customer sends. Further instructions must be agreed in writing.

We tell the Customer if we believe an instruction breaches Data Protection Laws. Where the law requires processing beyond the Customer's instructions, we inform the Customer first unless that law forbids it.

5. Confidentiality

Everyone who may process Customer Personal Data is bound by confidentiality duties and gets access only where needed. Staff have no standing access to render payloads or generated files: support views Workspace metadata through audited read-only impersonation with a recorded reason, and reaches files only when the Customer enables that access.

6. Security

We implement and maintain the measures in Annex 2, taking account of the state of the art, the cost of implementation and the risks to data subjects, and may change them as long as protection is not materially reduced. The Customer is responsible for the settings under its control, such as key scopes, multi-factor authentication, retention periods, logging and shared file links.

7. Sub-processors

The Customer gives general authorisation for us to use sub-processors. The current list, with purpose, data and location, is published at /legal/subprocessors and forms Annex 3.

We give at least 30 days' notice before a new sub-processor starts processing Customer Personal Data, by updating that page and notifying subscribers. Within the notice period the Customer may object on reasonable data protection grounds at privacy@dynamicdocumentapi.com. We then look for a solution, such as another configuration or Region; if none is found, the Customer may terminate the affected part of the Service before the change takes effect. [Counsel to decide whether prepaid fees are refunded.]

Each sub-processor is bound by a written contract with equivalent data protection obligations, and we remain liable for its performance.

8. Assistance with data subject requests and assessments

If a data subject contacts us about Customer Personal Data, we do not respond on the merits but refer the person to the Customer and forward the request without undue delay.

The Customer can retrieve, correct and delete Customer Content itself through the dashboard and the API. Where that is not sufficient, we assist with requests under Chapter III of the GDPR within 10 business days of a written request, and with data protection impact assessments and prior consultations under Articles 35 and 36, mainly through this DPA, our security documentation and available audit reports.

9. Personal data breaches

We notify the Customer without undue delay and in any event within 48 hours after becoming aware of a personal data breach affecting Customer Personal Data. The notification describes, so far as known, the nature of the breach, the categories and approximate number of records concerned, likely consequences, measures taken and a contact point; further details follow as the investigation progresses. We assist with the Customer's own notification duties; a notification is not an admission of fault.

10. Deletion and return

The Customer can export and delete Customer Content at any time. After the Agreement ends it stays available for export for 30 days, as set out in the Terms; we then delete Customer Personal Data from active systems within [30] days, and backups roll off within 35 days. We keep data longer only where the law requires it, and protect it while we do. On request we confirm deletion in writing.

11. Audits and evidence of compliance

We provide the information needed to show compliance with Article 28: this DPA, Annex 2, our security documentation and, once available, third-party audit reports and penetration-test summaries under a confidentiality agreement. A SOC 2 Type I report is planned about six months after launch, with SOC 2 Type II and ISO/IEC 27001 later; none exists yet.

If that is not sufficient, or a supervisory authority requires it, the Customer may audit us once in any 12 months, with [30] days' notice, during business hours, at its own cost and under confidentiality, without access to other customers' data. Enterprise audit terms can be agreed in an Order Form.

12. International transfers

Customer Personal Data is stored in the Region the Customer selects, the EU by default. Where processing involves a restricted transfer, the SCCs apply and are incorporated by reference: Module 2 (controller to processor) where the Customer is a controller, Module 3 (processor to processor) where it acts as a processor for its own controllers. The docking clause applies; the optional redress clause in Clause 11 does not; Clause 9 follows option 2 with the notice period in section 7; governing law and forum under Clauses 17 and 18 are [EU Member State law] and [courts of …]; Annexes I to III of the SCCs are populated by Annexes 1 to 3 of this DPA.

For transfers under UK law, the SCCs are supplemented by the international data transfer addendum issued under section 119A of the Data Protection Act 2018. For transfers subject to Swiss law, references in the SCCs are read to include the FADP and the Federal Data Protection and Information Commissioner. Where we act as a service provider under the CCPA, we do not sell or share Customer Personal Data and use it only to provide the Service.

[Counsel: confirm module selection once the contracting entity is fixed, including whether Module 4 is needed outside the EEA, and add Singapore and Australia terms before those Regions launch.]

13. Residency and zero-retention mode

Render payloads and generated files remain in the Region of the API host the Customer calls. Account data, templates and configuration are managed in the EU control plane and made available to the Regions in use; only usage events without personal data cross Regions. In zero-retention mode no hosted copy of a file is kept, payload and response logs are not written, job data stays in memory only, and the render record keeps technical metadata without personal data. Files the Customer delivers to its own storage or webhook endpoints leave our control, and those systems are not our sub-processors.

14. Liability, precedence and term

Liability under this DPA is subject to the limits in the Terms, so far as Data Protection Laws allow; data subjects' rights under the SCCs are unaffected. In a conflict, the SCCs prevail over this DPA, which prevails over the rest of the Agreement for personal data. This DPA lasts as long as we process Customer Personal Data.

Annex 1 — Description of the processing

Item	Description
Subject matter	Generating PDFs, images and related files from templates and data through the Service
Duration	The term of the Agreement plus the export and deletion periods in section 10
Nature and purpose	Receiving, validating, queueing, rendering, storing, delivering and logging render requests; support; abuse prevention
Categories of data subjects	Anyone whose data the Customer includes in templates, payloads, uploads or rendered URLs, such as its customers, employees, suppliers and document recipients, plus the Customer's own users
Categories of personal data	Determined by the Customer: typically names, contact and address data, order references, invoice and payment details, employment or certification details, images, signatures and free text; technical data such as IP addresses in request logs; for opt-in AI features, prompts and uploaded samples
Special categories	Not intended. The Customer must not submit them without appropriate safeguards, and never protected health information
Frequency	Continuous while the Customer sends requests
Retention	Generated files: Workspace setting within the Plan maximum (Free 7 days; paid Plans 30 days by default, up to unlimited). Request payload logs: off or metadata only by default, otherwise 7, 30 or 90 days by Plan. Webhook delivery logs: 30 days. Render metadata without payloads: 13 months, then aggregated. Deleted Workspaces: 7-day soft delete, then purge; backups within 35 days
Processing locations	The Regions chosen by the Customer (EU by default), plus the EU control plane for account and template data
Competent supervisory authority	[competent supervisory authority]

Annex 2 — Technical and organisational measures

Summarised at a high level; details are shared under a confidentiality agreement.

• Encryption: TLS 1.2 or higher in transit, including between internal services; AES-256 at rest for databases, object storage and backups with managed keys per Region; extra application-level encryption for secrets such as storage credentials and webhook secrets; API keys stored only as hashes.
• Access control: single sign-on with hardware security keys for staff, least-privilege roles, approved time-limited elevated access with session recording, no standing access to production data, regular access reviews; for customers, multi-factor authentication, roles, key scopes and IP allowlists.
• Tenant isolation: every object belongs to one Workspace, enforced in the application and in the database with row-level security; partitioned caches; private files by default with expiring links; automated tenancy tests.
• Sandboxed rendering: renderers run in a hardened sandbox as non-root with a read-only file system on isolated capacity, with separate browser contexts per job and time, memory and output limits.
• Network and SSRF controls: outbound traffic from renderers and webhooks passes an egress proxy that blocks internal, private and cloud-metadata destinations, re-checks redirects and defends against DNS rebinding, with a dedicated test suite in CI.
• Logging and monitoring: security and audit events go to a separate, restricted archive (1 year available, 3 years archived) with alerting and on-call response; payloads are redacted and regional logs stay in their Region.
• Backups and resilience: point-in-time recovery for control-plane databases with copies in a second EU location, monthly restore tests, defined recovery objectives and regular failure exercises; generated files are not backed up, and object versioning guards against accidental deletion for 7 days.
• Incident response: documented plan with severity levels, runbooks and defined roles, customer notification per section 9, status page updates and post-incident reviews.
• Secure development: OWASP ASVS Level 2 baseline, mandatory review with two reviewers for security-critical code, automated static analysis, dependency, container and secret scanning, signed images, threat modelling for features handling untrusted input, and external penetration testing planned before launch and annually.
• Organisational: separate cloud accounts per environment, default-deny network policies, edge protection and rate limiting, confidentiality and IP agreements for everyone who contributes, and a compliance programme working towards the certifications in section 11.

[Security lead and counsel to confirm each measure is in place on the effective date.]

Annex 3 — Sub-processors

Authorised sub-processors, their purposes, data and locations are listed at /legal/subprocessors, as updated under section 7.