Skip to main content

Boardroom Answers · Security & Compliance · Compliance, Regulatory & Legal

Your DPA lands on my desk tomorrow. What Article 28 terms will I find, and which ones will your engineering actually honour rather than merely promise?

The question a Chief Privacy Officer / DPO asks.

The short answer

Every Article 28(3) clause is in the DPA — and the ones that matter are backed by shipped code: executable erasure for the deletion clause, the DSAR pipeline for the assistance clause, deadline-tracked incidents for a real 24-hour notification SLA, and a security annex that cites verifiable controls, not boilerplate.

The full executive answer

The Article 28(3) checklist will all be there — processing only on documented instructions, confidentiality, security measures, sub-processor controls, assistance with data-subject rights, breach notification, deletion or return at termination, and audit rights. But your question is which clauses have engineering behind them, so let me map promise to code. Sub-processor transparency: the ten-name list with purposes, and a notice-and-objection mechanism for changes. Assistance with data-subject rights: not "reasonable assistance" prose but shipped machinery — the DSAR export and the thirty-day erasure pipeline mean your Article 15/17 obligations are dischargeable in clicks, which contractually lets us accept tighter assistance timelines than vendors who handle DSARs by manual archaeology.

Deletion at termination: the erasure pipeline with database-level cascade rules is exactly the "delete all personal data at end of provision" clause, executable and auditable — and the gdpr_requests trail plus audit log give you the evidence artefact for your own records. Breach notification: jurisdiction-aware deadline tracking in our incident module supports a concrete contractual SLA (24 hours for confirmed personal-data breaches) rather than "without undue delay" left undefined. Security measures annex: rather than the usual generic bullet list, ours can reference the specific controls — RLS isolation with CI enforcement, AES-256 at rest and TLS 1.2+ in transit, KMS field encryption, append-only audit logging, PII redaction before AI processing — each verifiable in the codebase.

Where the honest asterisks go: audit rights we grant meaningfully (documentation, questionnaires, and — pre-certification — deeper cooperation than usual, since we can't yet hand you a SOC 2 report in lieu); but on-premise inspection of our sub-processors' data centres isn't ours to grant — you inherit AWS's and the others' standard audit artefacts, which is true of every cloud-native vendor and worth saying plainly. And the international-transfer annex will state Japan adequacy plus SCC flow-downs, exactly as engineered — no residency promises the code doesn't support.

Grounded in: GDPR Art. 28(3)(a)–(h) (mandatory processor terms), Art. 28(2)/(4) (sub-processors), Art. 32 (security measures); SOC 2 TSC CC9.2.

Want this answered live, on your data?