data processing agreement — template.

§ 1parties

Under GDPR Art. 4(7) and Art. 4(8) respectively. The Processor acts as data processor for the Controller during the engagement scope defined in § 2.

§ 2subject matter + duration

Subject matter: processing of personal data carried out by the Processor on behalf of the Controller in the context of the engagement specified in the underlying service agreement (typically: CRM architecture, automation expansion, or AI agent build).

Duration: for the term of the engagement (3–5 weeks build), plus the 30-day open-line period post-handover. Processor retains no Controller data beyond engagement close except as required to fulfill the 30-day open-line support, after which data is returned or deleted per § 8.

§ 3nature + purpose of processing

The Processor will process personal data only to the extent necessary to:

• Design + implement the agreed CRM, automation, or agent system
• Migrate data from legacy systems to the new architecture
• Test, validate, and demonstrate the system before handover
• Train the Controller's team on system operation
• Provide the 30-day open-line support post-handover

Processor will not process Controller data for its own purposes, will not aggregate or anonymize Controller data for separate use, and will not use Controller data to train or improve any model.

§ 4categories of data + data subjects

Special categories under Art. 9 GDPR (health data, biometric data, etc.) are out of scope by default. If the engagement requires special categories, an Annex IV addendum to this DPA is signed before processing begins.

§ 5processor obligations (Art. 28(3))

Processor undertakes to:

1. Process personal data only on documented instructions from the Controller, including with regard to transfers of personal data to a third country
2. Ensure that persons authorised to process the personal data have committed themselves to confidentiality
3. Take all measures required pursuant to Art. 32 (security of processing) — see § 8 (TOMs)
4. Respect the conditions referred to in § 6 (sub-processors) for engaging another processor
5. Assist the Controller by appropriate technical and organisational measures, for the fulfilment of the Controller's obligation to respond to requests for exercising the data subject's rights laid down in Chapter III GDPR
6. Assist the Controller in ensuring compliance with the obligations pursuant to Articles 32 to 36 (security, breach notification, DPIA, prior consultation)
7. At the choice of the Controller, delete or return all the personal data to the Controller after the end of the provision of services, and delete existing copies (see § 9)
8. Make available to the Controller all information necessary to demonstrate compliance with the obligations laid down in Art. 28 and allow for and contribute to audits, including inspections, conducted by the Controller or another auditor mandated by the Controller

§ 6sub-processors

The Controller authorises the use of the following sub-processors, as relevant to the engagement scope:

Caelith Labs's own sub-processors (apply to every engagement)

Engagement-specific sub-processors (vary by engagement)

Depending on the engagement scope, the following may apply:

The Controller's signature on the engagement service agreement constitutes prior specific authorisation for the engagement-scoped sub-processors listed in the proposal. Changes to the sub-processor list during the engagement require 14 days prior written notice to the Controller, who may object on reasonable grounds.

§ 7international transfers

Where personal data is transferred outside the EEA, the following safeguards apply:

• USA (Anthropic, GitHub): EU–US Data Privacy Framework (Commission Implementing Decision (EU) 2023/1795). Where Anthropic's standard DPA is in place, SCCs Module 2 (controller-to-processor, Decision 2021/914) apply as a secondary basis.
• USA (Calendly, Notion): SCCs Module 2 per the respective vendor DPA.
• Other third countries: not in scope by default. If the engagement requires a third-country transfer outside the above, a transfer impact assessment (TIA) is conducted and added as an addendum.

§ 8technical + organisational measures (TOMs)

Processor implements appropriate technical and organisational measures pursuant to Art. 32 GDPR, including:

access control

• Engagement credentials stored in 1Password vault, MFA-protected
• Least-privilege principle — Processor accesses only data required for the engagement scope
• Credential rotation per the schedule in the engagement runbook (§ 6 of runbook)

data security

• All vendor connections use OAuth or API tokens — no shared passwords
• Where Labs hosts data: AES-256 at rest (Railway managed Postgres default), TLS 1.2+ in transit
• PostgreSQL row-level security where the engagement architecture warrants it
• No long-term storage of Controller data on Processor's local devices

operational

• Eval suite + audit trail per build — every system change logged, every agent decision auditable
• Encrypted backups for the duration of Processor-hosted data, with documented restore procedure
• Breach notification: Processor notifies Controller within 24 hours of becoming aware of a personal-data breach

§ 9return / deletion · audit · termination

at engagement close

At Controller's choice, Processor will return or delete all personal data within 30 days of engagement close. Default: deletion + written confirmation. Exceptions: data Processor is legally required to retain (e.g., invoicing records under § 147 AO).

audit rights

Controller may, no more than once per year and on 30 days' written notice, audit Processor's compliance with this DPA. Audits are at Controller's cost. Processor will assist by providing access to relevant records (sub-processor list, TOM documentation, breach log, deletion confirmations).

termination

This DPA terminates automatically when the underlying service agreement ends. The obligations in § 5 (confidentiality), § 9 (deletion), and any pending breach notification continue to apply.

signatures