A pre-counter-signed GDPR / UK-GDPR Article 28 DPA, ready to be incorporated by reference into your Master Service Agreement or order form. Most procurement teams accept it as-is; bespoke edits go through legal@cloakapi.io.
Template version 3.1 · Compatible with EU SCCs 2021/914 (Module 2) and the UK International Data Transfer Addendum (ICO v B1.0) · Healthtech / MDR / NHS DSPT addendum included
Executive summary
This DPA names CloakAPI AS as the Processor and the customer (you) as the Controller. The unique architecture means the categories of personal data we process are limited to account/billing identifiers and operational telemetry — for the client-side ways the prompt and response payloads are tokenised on the customer device before they reach our infrastructure, and the gateway is a blind token relay that forwards only those tokens (it does not inspect, detect, or tokenise content on our servers), so the underlying content is not within our processing scope.
Counter-signed version available. The PDF below is signed by Yrjan Klokk (CEO & DPO). Sign as Controller and email it to legal@cloakapi.io; we'll return a fully-executed copy within two business days.
The Processor processes Personal Data on behalf of the Controller for the duration of the underlying Service Agreement. Processing terminates when the Service Agreement ends, subject to the retention windows below.
2. Nature & purpose
Processing serves the operation of a privacy-preserving AI gateway: tokenising prompts client-side, routing redacted prompts to AI providers, returning responses, billing usage, and producing the cryptographic receipt chain.
3. Categories of data subjects
Authorised users of the Controller's account (employees, contractors).
Indirectly: persons whose data appears in prompts. Because of client-side tokenisation on the customer's device, these data subjects are structurally invisible to the Processor.
4. Categories of personal data
Category
Examples
Source
Account identifiers
Name, email, organisation, country, role
Controller signup form
Billing data
Address, VAT ID, Stripe customer reference
Controller portal
Authentication artefacts
Hashed password, MFA, IP, session metadata
Controller usage
Operational telemetry
Request timestamp, route, latency, byte count
Gateway runtime
Receipt chain entries
Hash digests, ECDSA signatures, sequence numbers
Gateway runtime
5. Sub-processor list
The full live list (14 entries) is at /legal/subprocessors with 30-day change-notification subscription. The DPA incorporates that list by reference, and customers can object to new sub-processors within the notification window per Art. 28(2).
6. Technical & organisational measures (Annex II)
Encryption-in-transit (TLS 1.3) for all traffic; encryption-at-rest (LUKS + AES-256-GCM) for all persistence.
Shamir 3-of-3 split custody for the receipt-signing root key, held in a software-isolated process and never written to disk in plaintext (a dedicated HSM with an audited key ceremony is available on enterprise request).
Zero-payload logging invariant enforced in middleware; CI gate on every commit.
Role-based access control with quarterly access review; production access requires hardware MFA.
Penetration testing: a scoped engagement begins on first enterprise customer request via a reputable firm. Continuous vulnerability disclosure programme at security.cloakapi.io.
7. International transfers (Annex III)
The Processor's gateway runs in Hetzner Nuremberg (EU). Where customers route to non-EU providers (e.g. Anthropic US, OpenAI US), transfers are covered by:
European Union — the EU Standard Contractual Clauses 2021/914 (Module 2: Controller to Processor) under Regulation (EU) 2016/679 (GDPR).
United Kingdom — the ICO International Data Transfer Addendum (IDTA) v B1.0 to the EU SCCs, under the UK General Data Protection Regulation (UK-GDPR) as retained by the Data Protection Act 2018. The ICO Addendum is the operative export mechanism for any Controller established in the United Kingdom; the EU SCCs above govern by reference where the Addendum cross-references them.
Switzerland — the Swiss FDPIC-approved version of the EU SCCs.
Supplementary measures: client-side tokenisation on the customer's device (in-browser WebAssembly for the chat and extension, native Rust in the desktop app) strips direct identifiers (and special-category signals — see §12 below) before the data leaves the EU, and the gateway is a blind token relay that forwards only those tokens without inspecting or detecting content on our servers; the receipt chain proves what was redacted. A separate Transfer Impact Assessment (TIA) is available on request for UK and US destinations.
8. Audit rights
The Controller may, at its own cost, audit the Processor's compliance with this DPA once per year on 30 days' written notice. The Processor will make available any applicable compliance reports or attestations in lieu of on-site audits where reasonable.
9. Data-breach notification
The Processor notifies the Controller within 48 hours of becoming aware of a personal-data breach affecting Controller data, with the information needed for the Controller to meet its 72-hour Art. 33 obligation.
10. Return / deletion on termination
On termination, the Controller can export account data via the portal API. After a 30-day window, residuals are erased. Bookkeeping rows mandated by Norwegian law (5-year retention) are pseudonymised.
Where the Controller is an essential or important entity under Directive (EU) 2022/2555 (NIS2), CloakAPI as a processor and ICT third-party service provider commits to the supply-chain risk-management measures in Article 21(2):
(a) ICT risk-management policies. CloakAPI maintains and reviews at least annually a documented information-security and ICT-risk-management programme covering policies, asset management, access control, cryptography, operations security, communications security, system acquisition / development / maintenance, supplier relationships, incident management, business continuity, and compliance — aligned to ISO/IEC 27001:2022 controls and the NIS2 Implementing Regulation (EU) 2024/2690.
(b) Significant-incident reporting within 24 hours. Where an incident affecting Controller data qualifies as a "significant incident" under NIS2 Art. 23, CloakAPI issues an early warning to the Controller within 24 hours of becoming aware of it, an incident notification within 72 hours, and a final report within one month — without prejudice to the 48-hour GDPR-breach notification in §9 above.
(c) EU residency for processing. All processing of Controller data under this DPA takes place on infrastructure located within the European Union (currently Hetzner Nuremberg, DE). Backup replicas are EU-only. Sub-processors with non-EU presence are bound by SCCs and process only the categories of data listed in Annex I.
(d) DPA execution before subcontracting. No sub-processor is engaged for the processing of Controller data without (i) a signed data-processing agreement imposing data-protection obligations equivalent to those in this DPA, and (ii) the Controller's prior general or specific authorisation per Art. 28(2) GDPR. The current sub-processor list is published at /legal/subprocessors and changes are notified with at least 30 days' notice.
(e) Vulnerability handling & coordinated disclosure. CloakAPI operates a public vulnerability-disclosure policy (VDP) and tracks CVEs affecting deployed components through an internal SBOM (/legal/sbom.json).
(f) Cryptography & key management. Data in transit is protected by TLS 1.3; data at rest is protected by AES-256-GCM. Customer-scoped tokenisation keys are isolated per tenant and rotated on schedule.
This section is anchored at /legal/dpa#nis2 and may be referenced from procurement questionnaires (DORA, NIS2, ENISA), supplier-risk attestations, and ICT-third-party registers.
12. Article 9 (special category) data — GDPR & UK-GDPR
"Special category" data under GDPR / UK-GDPR Article 9(1) (data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, trade-union membership; genetic data, biometric data for the purpose of uniquely identifying a natural person; data concerning health; data concerning a natural person's sex life or sexual orientation) and equivalent "sensitive personal data" under the Data Protection Act 2018 are processed by the Processor only in tokenised form. The client-side tokeniser running on the Controller's device (in-browser WebAssembly, or native Rust in the desktop app) replaces Article 9 indicators with deterministic placeholders before the prompt is transmitted, and the gateway blind-relays only those tokens without inspecting content on our servers; the Processor never sees, stores, or transmits the underlying special-category bytes in the clear.
Where the Controller is a healthcare provider, medical-device manufacturer, or clinical-research organisation processing health data under Article 9(2)(h) (provision of health or social care), 9(2)(i) (public-health interest) or 9(2)(j) (scientific research), the Processor commits to:
Enforce the healthtech privacy floor on every API key (`max` tier; NHS_NUMBER, UK_POSTCODE, PERSON_NAME, DOB, and MEDICAL detector categories always-on).
Maintain a current Record of Processing Activities (Art. 30) for health-data flows, available to the Controller on 5 business days' notice.
Execute a separate Business Associate Agreement (BAA) where US-HIPAA coverage is required — see §14 below.
Refuse downgrade requests that would weaken the floor (an API attempt returns 422 healthtech_tier_floor_violated).
The Processor implements Article 17 ("right to be forgotten") for every data subject whose personal data the Processor holds in identifiable form. Mechanics:
Initiation. The Controller submits an erasure request via the Data Subject Access Request (DSAR) endpoint at POST /v1/compliance/dsar (programmatic) or via privacy@cloakapi.io (manual). The Processor acknowledges within 5 business days.
Scope. Erasure covers: account identifiers, billing rows (where statutory retention has lapsed), authentication artefacts, operational telemetry, and any Processor-side projection of receipt-chain entries containing identifiable data. Tokenised payloads were never within scope (see §12).
Statutory hold exceptions. Bookkeeping rows mandated by Norwegian Bokføringsloven (5-year retention) are pseudonymised rather than deleted; the same applies to UK HMRC and EU member-state bookkeeping requirements where the Controller's billing address falls under those regimes. The exception is logged in the DSAR audit trail with the legal basis cited.
Receipt chain. Cryptographic receipt entries are append-only by design. The Processor erases the identifying projection (user_id, organisation_id, request_id) but retains the opaque hash + signature so chain integrity remains verifiable for non-erased entries. This is consistent with Recital 66 GDPR (technical limits on erasure where deletion would defeat the lawful processing purpose — here, integrity proofs for unrelated controllers).
Confirmation. The Processor delivers a written erasure confirmation within 30 calendar days (Art. 12(3) standard), including a list of sub-processors notified under Art. 19.
UK pathway. UK-resident data subjects may exercise the right via the Information Commissioner's Office; the Processor's UK representative for service of Art. 27 / DPA-2018 contact is named in the Processor's privacy policy at /legal/privacy.
Where the Controller is a manufacturer or distributor of medical devices subject to Regulation (EU) 2017/745 (Medical Device Regulation, MDR), the Processor commits to the supplier obligations relevant to a software / cloud-service input to a device's quality-management system:
(a) MDR Art. 14(1) verification — identity. The Processor provides the Controller with the Processor's unique device-input identifier (Service Inventory Reference, "SIR-CLOAKAPI-GW-001") for the Controller's technical documentation and EUDAMED registration where applicable.
(b) Art. 14(2) checks at receipt. The Processor publishes the gateway's currently-deployed image digest (SHA-256), build provenance (SLSA level 3 attestation), and Software Bill of Materials (SBOM in CycloneDX 1.5) at /legal/sbom.json. The Controller can pin to a specific digest via X-CloakAPI-Image-Pin; mismatches return 409 image_pin_mismatch rather than silently routing to a newer build.
(c) Storage & handling conditions. Customer data is stored under the conditions in §6 (TOMs). The Processor warrants that no environmental, transport, or handling condition outside the documented operational envelope (EU residency, AES-256-GCM at rest, TLS 1.3 in transit, hardware-MFA operator access) is permitted by the deployment pipeline.
(d) Reporting of suspected non-conformity. Where the Processor becomes aware that any element of its service does not conform to the MDR-relevant commitments above, it notifies the Controller within 24 hours and provides root-cause analysis within 14 days. Where the non-conformity is "serious" within the meaning of Art. 87 MDR, the Processor cooperates with the Controller's vigilance reporting to the competent authority on the Art. 87 timeline.
(e) Distributor traceability. The Processor retains operational logs (timestamps, request-id, image digest, configuration revision) sufficient to reconstruct the state of the service for any Controller request for the period required by Art. 10(8) MDR (technical-documentation retention — minimum 10 years post end-of-life for the device).
Anchor: /legal/dpa#mdr-article-14.
15. NHS Data Security and Protection Toolkit (DSPT) alignment
Where the Controller is a National Health Service (NHS) body, an NHS contractor, or any UK-health-and-social-care organisation required to publish an annual NHS DSPT assertion, the Processor aligns its TOMs (§6), incident handling (§9, §11(b)), supply-chain governance (§11(d)), and erasure mechanics (§13) to the National Data Guardian's 10 standards, as operationalised by the NHS DSPT (v6, 2024-2025 edition):
Standard 1 (Personal Confidential Data). Tokenisation invariant (§12) plus zero-payload-logging gate (§6) provide a stronger-than-baseline control: PCD never reaches the Processor in identifiable form.
Standard 6 (Responding to Incidents). The 24-hour early-warning commitment in §11(b) exceeds the DSPT "within 72 hours of becoming aware" requirement.
Standard 7 (Continuity Planning). Encrypted off-site backups + tested restore procedure; recovery-time objective documented in the customer-facing operations runbook.
Standard 9 (IT Protection). CIS-aligned hardening on every host; automated configuration drift detection; quarterly vulnerability-scan reports available to the Controller under NDA.
Standard 10 (Accountable Suppliers). The full sub-processor list (§5) is published under change-notification; each sub-processor flows-down the DSPT-equivalent obligations via the standard upstream-DPA.
The Processor does not itself publish a DSPT assertion (it is not a Data Security and Protection Toolkit Reporting Organisation in its own right; it is a software supplier to such organisations) but provides, on request, the supplier-evidence pack a Controller's DSPT submission needs to evidence its supply chain.