Extracting Data Processing Terms From a Data Processing Addendum

A DPA is the rare contract whose required contents are written down somewhere else. Article 28(3) of the GDPR lists them, which means the extraction schema is not a design question — it is a transcription of a statute, and what remains is finding where each item is hiding.

Article 28 gives you the field list

Article 28(3) of Regulation (EU) 2016/679, published by the EU in EUR-Lex, requires the processing to be governed by a contract that sets out the subject matter and duration of the processing, the nature and purpose of the processing, the type of personal data, the categories of data subjects, and the obligations and rights of the controller. Those five are your first five fields, and in practice all of them are in an annex rather than in the body.

The article then requires the contract to stipulate, in points (a) through (h), that the processor: processes only on documented instructions from the controller, including as regards transfers; ensures persons authorised to process have committed to confidentiality or are under a statutory duty of it; takes the security measures required by Article 32; respects the conditions in paragraphs 2 and 4 for engaging another processor; assists the controller in responding to data subject rights requests; assists with the obligations in Articles 32 to 36; deletes or returns the personal data at the end of the services, at the controller’s choice, unless law requires storage; and makes available the information needed to demonstrate compliance and allows for and contributes to audits and inspections.

That is a fixed, ordered checklist, and it makes this extraction qualitatively different from the other clause types in this cluster. You are not discovering what fields a document has; you are asking, for each of thirteen known items, whether the document addresses it, where, and on what terms. Emit one row per item — item key, present boolean, clause reference, verbatim span, and a short normalised summary of any qualification — and the output doubles as a gap report. An item marked absent is more interesting than any item marked present, so the schema has to distinguish absent from unread in the way missing required fields generally should.

Two adjacent paragraphs matter enough to extract as well. Article 28(9) requires the contract to be in writing, including electronic form, which in practice means capturing execution evidence. And Article 28(10) provides that a processor determining the purposes and means becomes a controller in respect of that processing — relevant because DPAs increasingly contain a clause carving out some activity as the vendor’s own controller processing, and that carve-out is a field worth having.

Subprocessors and the list that moves

Article 28(2) requires prior specific or general written authorisation before a processor engages another processor, and in the general- authorisation case requires the processor to inform the controller of intended changes so the controller can object. Article 28(4) requires the same data protection obligations to be imposed on the subprocessor by contract, with the initial processor remaining fully liable for the subprocessor’s performance.

So the fields are: authorisation model (specific or general), the notice period for changes, the objection mechanism and what happens if the controller objects — typically a right to terminate, which is the only remedy with teeth — the flow-down obligation, and the liability statement.

Then there is the list itself, and it is the part that makes this a refresh-cadence extraction rather than a one-shot one. Most modern DPAs do not enumerate subprocessors inline. They point at a web page, and the web page changes without the contract changing. The correct extracted value is therefore a pointer plus provenance: { "subprocessor_list_ref": { "type": "url", "value": "...", "retrieved_at": "2026-08-11" } }. Treating the contents of that URL as a contract term without a retrieval date produces a record that is wrong at an unknown later moment and looks identical to one that is right; the provenance machinery for that belongs in an extraction field audit trail. The published pages on subprocessor disclosure and the subprocessor checklist cover what to do with the list once you have it.

The transfer mechanism

If personal data leaves the EEA, something has to make that lawful, and the DPA names it. The candidates are a small closed set, which makes this an enum with a caveat:

• An adequacy decision under Article 45 — the Commission has decided the destination country ensures an adequate level of protection. The list of such decisions changes, so extract the country and the decision as named rather than a boolean.
• Standard contractual clauses under Article 46. For EU transfers these are the clauses in Commission Implementing Decision (EU) 2021/914 of 4 June 2021, which are modular: the controller-to-processor module is not the same document as the processor-to-processor module, and a DPA that incorporates the SCCs without saying which module is incomplete in a way worth flagging. Extract the module, the docking-clause option, the choices made in the optional clauses, and the governing law and forum selected.
• Binding corporate rules under Article 47, where an intra-group transfer is covered by approved rules.
• A UK addendum or the UK international data transfer agreement, where UK data is in scope, extracted as a separate mechanism rather than folded into the EU one.
• A transfer impact assessment reference, where the DPA commits to one.

Everything important is in an annex

The body of a DPA is largely stable boilerplate; the parts that differ between two vendors are in the annexes. Annex-style content typically includes the processing description satisfying the opening words of 28(3), the technical and organisational measures satisfying Article 32, the subprocessor list, and the completed SCC annexes.

Extraction therefore has to follow references, and annexes are structurally awkward: they are often tables rather than prose, they restart their own numbering, they may be a separate PDF attached to an email, and the security measures annex is frequently a bullet list written at a level of generality that resists normalisation. A reasonable compromise is to extract the annex as a structured record where it is tabular and to keep it as a verbatim block where it is prose, flagging which you did. Attempting to normalise “encryption of data in transit and at rest using industry standard algorithms” into a control framework is a modelling decision, not an extraction, and it belongs in a separate pass that can be revised without re-reading the documents.

Where it goes wrong

• The SCCs are incorporated with empty annexes. A sentence saying the parties agree the SCCs apply, with Annex I and II left as a template, is common and is precisely the finding worth surfacing. An extractor that reports the mechanism as present marks it compliant.
• The audit right is reduced to a report. Article 28(3)(h) speaks of audits and inspections; many DPAs satisfy it with an annual third-party assurance report and a right to ask questions. That is a qualification, not an absence, and needs a value between true and false.
• Deletion has three variants. Delete, return, or delete after a stated retention window — and separately, whether backups are excluded until expiry of a backup cycle. Extract the retention period as a number.
• Two DPAs are in force. A customer’s DPA attached to an order form and a vendor’s online DPA incorporated by reference can both exist, with an order-of-precedence clause deciding between them. Extract the precedence clause.
• Controller and processor roles are reversed in one section. DPAs covering bidirectional data flows switch roles mid-document. A schema with a single role field cannot represent it; use one record per processing activity.