onTerms Data Processing Addendum (onDPA) v1.0 — Standard Terms

onterms:dpa:1.0.0:EW · Status: v0.9 DRAFT · Not legal advice (requires E&W data-protection counsel sign-off). The topic module incorporated by reference whenever an onTerms Order involves processing of personal data; relied on by saas-1.0-ew.md §7.

Architecture. These terms are immutable and incorporated by reference from the Order. The negotiable surface is the Order's elections.data_protection block (encoded in onterms-order.schema.json). Capitalised terms not defined here have the meaning in UK GDPR / EU GDPR and the onTerms Dictionary.

Precedence (non-derogable). Per spec/onterms-protocol.md §2.2, the mandatory provisions of this module — the Article 28(3) processor obligations, the security floor (Art. 32), breach-notification minimums, and the SCC/IDTA mandatory clauses — sit at the top of the precedence ladder with Mandatory Law. No Election can weaken them; an Election may only make a parameter stricter (spec/verifier.md §V2 / dispute floor).

1. Roles, scope & instructions

1.1 This module applies where, in providing the Service, the Provider (as Processor) processes Personal Data on behalf of the Customer (as Controller), or where the Customer is itself a processor and the Provider is a Sub-processor (Module Three of the SCCs/IDTA applies, mutatis mutandis). The subject-matter, duration, nature and purpose of processing, the types of Personal Data and categories of Data Subjects are set out in the Order and Annex A (Processing Details). 1.2 The Provider processes Personal Data only on the Customer's documented instructions (including as to international transfers), unless required by law (in which case it notifies the Customer unless the law prohibits it). The Order, this module and the Provider's documented features constitute the Customer's initial instructions. The Provider tells the Customer if, in its opinion, an instruction infringes data-protection law.

2. Processor obligations (UK/EU GDPR Art. 28(3))

The Provider will: (a) process only on documented instructions; (b) ensure persons authorised to process are under an obligation of confidentiality; (c) take all measures required by Art. 32 (security — clause 3); (d) respect the conditions for engaging Sub-processors (clause 4); (e) assist the Customer, by appropriate technical and organisational measures, to respond to Data Subject rights requests; (f) assist the Customer with Art. 32–36 obligations (security, breach notification, DPIAs, prior consultation) taking into account the nature of processing and information available; (g) at the Customer's choice, delete or return all Personal Data at the end of provision of services (clause 6); and (h) make available information necessary to demonstrate compliance and allow for and contribute to audits (clause 5).

3. Security (Art. 32)

3.1 The Provider implements and maintains appropriate technical and organisational measures appropriate to the risk, set out in Annex B (Security Measures) and consistent with the elected security_certification (∈ none, cyber_essentials, cyber_essentials_plus, soc2_type2, iso27001, both; default soc2_type2). cyber_essentials (the UK NCSC scheme, self-assessed) and cyber_essentials_plus (independently audited) are the accessible, low-cost baseline for UK SMBs — a recognised assurance floor where SOC 2 / ISO 27001 are disproportionate. A value other than none is a binding contractual commitment to hold and maintain that certification during the term and to provide the current certificate/report on request. 3.2 This is a floor, not a ceiling: the Provider will not reduce the overall level of security during the term.

4. Sub-processors

4.1 General authorisation. The Customer gives general written authorisation for the Provider to engage Sub-processors, provided the Provider: maintains an up-to-date list; imposes data-protection obligations no less protective than this module by written contract (Art. 28(4)); and remains fully liable for its Sub-processors' acts and omissions. 4.2 Notice & objection. The Provider gives at least 10 business days' notice of an intended addition/replacement of a Sub-processor. Where subprocessor_objection_right is true (default), the Customer may object on reasonable, data-protection-related grounds within that period; the parties will work in good faith to resolve, and failing resolution the Customer may terminate the affected Service without penalty for the unused, prepaid period.

5. Audits & information

The Provider makes available the information necessary to demonstrate Art. 28 compliance. The elected audit_mechanism (Order/SaaS module) governs the method: report_only (default — third-party audit reports + a security questionnaire response once per year) or audit_on_notice (an audit, by the Customer or a mutually-agreed independent auditor, on 30 days' notice, no more than once per year except where required by a Supervisory Authority or following a Personal Data Breach, subject to confidentiality and not unduly disrupting the Provider).

6. Return & deletion on exit

On the end of provision of the Services the Provider, at the Customer's choice, deletes or returns all Personal Data and deletes existing copies within the elected deletion_window_days (∈ 30, 60, 90; default 60), except to the extent law requires storage (in which case the Provider isolates and protects it) and save for copies in routine backups deleted on the ordinary cycle.

7. Personal Data Breach

The Provider notifies the Customer without undue delay, and in any event within the elected breach_notice window (∈ undue_delay, 72h, 48h, 24h; default 72h) after becoming aware of a Personal Data Breach affecting the Customer's Personal Data, with the information reasonably available to enable the Customer to meet its own Art. 33–34 obligations, and cooperates and takes reasonable steps to mitigate. Notification is not an acknowledgement of fault. The elected window is a maximum; a stricter window prevails (it cannot be relaxed below this floor).

8. International transfers

8.1 The Provider does not transfer Personal Data outside the UK/EEA except on the Customer's instruction and with an appropriate safeguard in place, per the elected international_transfer_mechanism (∈ uk_idta, eu_sccs, uk_idta_and_eu_sccs, dpf, not_applicable; required whenever governing law is a UK/EU jurisdiction). dpf covers transfers to a US importer self-certified under the EU-US Data Privacy Framework (and, for UK exporters, its UK Extension / UK-US Data Bridge, or the Swiss-US DPF) — valid only while the recipient's active participation is verified on the DPF list; if the recipient drops off the list, an alternative safeguard (IDTA/SCCs) must be put in place. 8.2 Execution, not merely "deemed" — [round-2 fix 1.6]. Where the UK IDTA or EU SCCs apply, the parties populate the IDTA Part 1 / SCC Annex tables as Order Elections (Annex A/C) and actually execute them via onSign over the populated instrument — not by a bare "deemed signed" recital. The relevant SCC Module (Two: Controller→Processor; Three: Processor→Sub-processor) is selected by the role in clause 1.1. This preserves enforceability before a Supervisory Authority, which the "deemed execution" shortcut does not reliably achieve. 8.3 Each party will conduct/assist with a Transfer Risk Assessment where required and implement supplementary measures as needed.

9. Liability, term, miscellany

9.1 This module is subject to the limitation of liability in the CORE/SaaS module, save that the uncapped/super-cap treatment of data-protection and security claims in saas-1.0-ew.md §11 applies; nothing limits liability that cannot be limited by data-protection law. 9.2 This module continues for as long as the Provider processes Personal Data for the Customer. It is B2B-only (the registry-verified gate in spec/verifier.md §V2 applies).

10. Evaluation / controller-to-controller mode (pre-Order) — [round-3 fix #4]

10.1 Why this mode exists. §§1–9 assume a Controller→Processor relationship under an Order (the Provider processing on the Customer's documented instructions, with deletion keyed to "end of provision of the Services"). The pre-agreement data-sample scenario is different: during a Trial/POC (onEval) the recipient evaluates the discloser's Sample Data in the recipient's own environment, which is typically a controller-to-controller (C2C) or role-reversed relationship, with no Order to anchor "provision of services". This mode adapts onDPA to that phase so the Art. 28 / Art. 26-style obligations are not orphaned. 10.2 Activation. This mode applies where an onEval Evaluation Order sets eval.sampleDataHandling = onDPA_applies (and there is no live Order). The parties record, in the Evaluation Order, the evaluation processing details (categories of data subjects/Personal Data, the evaluation purpose, duration = the Trial Period) — the analogue of Annex A. 10.3 C2C terms. Each party: processes the Sample Data only for the evaluation Purpose; applies Art. 32 security; does not further disclose, retain, sell, or use the Sample Data to Train any model (mirroring saas-1.0-ew.md §8 / the onEval no-training rule); assists the other with data-subject requests and breach handling to the extent it holds the data; and is each an independent Controller of the Personal Data it determines the purposes of (or, where one party processes strictly on the other's instructions for the evaluation, the §§1–9 Processor terms apply instead). 10.4 Deletion trigger keyed to trial-end / deal-dead — not an Order. The Sample Data, and all copies, are returned or deleted within deletion_window_days (default 60, but the onEval return_or_destruction_days default 30 prevails where stricter) of the EARLIEST of: (a) the end of the Trial Period; (b) a deal-dead notice; or (c) the disclosing party's written request — save routine backups deleted on the ordinary cycle and copies required by law (isolated and protected). This gives the Art. 28(3)(g)/Art. 5(1)(e) deletion obligation a clean trigger that does not depend on an Order ever existing. If an Order later proceeds, the live Order's onDPA (§§1–9) takes over for ongoing Processing and the C2C deletion clock is superseded only as to data that lawfully continues under the Order. 10.5 International transfers in this mode use the same mechanisms as §8 (UK IDTA / EU SCCs), populated and executed via onSign for the C2C modules (Module One controller-to-controller where applicable).

Annexes — templated + structured + executed (not "deemed")

The annexes are provided as templates (dpa-annexes-1.0-ew.md) and a structured, onSign-executable schema (../schema/dpa-annexes.schema.json, worked example ../examples/dpa-annexes.example.json). The same structured object populates the IDTA/SCC tables and is signed via onSign over its annexes_hash — closing the round-2/3 "deemed signed" gap.

• Annex A — Processing Details (= SCC Annex I / IDTA Part 1 Tables 1–3): subject-matter, duration, nature & purpose, types of Personal Data, categories of Data Subjects, transfer frequency, competent SA; the evaluation/C2C deletion-trigger block in §10 mode.
• Annex B — Security Measures (= SCC Annex II / IDTA Table 4): the baseline TOMs, mapped to the elected certification.
• Annex C — Sub-processors (= SCC Annex III): name, service, location, transfer safeguard.

Elections (encoded in onterms-order.schema.json elections.data_protection)

These are floors: an Election may only tighten them. The Order schema requires a transfer mechanism for UK/EU governing law and requires the dpa module to be incorporated whenever a sub-90-day breach notice is elected.