GDPR Article 28 Obligations When Using Document Processing APIs

Article 28 creates concrete, enforceable obligations (around DPA terms, sub-processor control, data deletion, and audit rights) that must be satisfied before a single file is sent. This piece maps each of those obligations to the exact question an engineering or legal team should be putting to a vendor.

Why a document processing API triggers Article 28 the moment a file is sent

The statute doesn't wait for harm. Article 28 activates as soon as a separate entity gains access to personal data on a controller's behalf, and access itself is the trigger, not misuse, not storage duration, not intent. Document processing APIs sit right in the middle of that definition. Invoices, payslips, bank statements, tax forms, health records, closing disclosures: almost every file type these systems are built to ingest carries personal data belonging to identifiable people.

So the practical reality for any team plugging in a document API is blunt. The moment a PDF gets routed through an external extraction API, the organization sending it becomes a controller with binding obligations toward that processor. There's no grace period for figuring out the paperwork afterward.

This isn't a hypothetical risk sitting on a shelf somewhere. The DLA Piper GDPR Fines and Data Breach Survey put cumulative GDPR fines at EUR 7.1 billion, with roughly EUR 1.2 billion of that total issued in 2025 alone orbiqhq.com. Regulators are actively enforcing this framework, and the pace hasn't slowed. What follows traces each Article 28 obligation to a concrete question to ask any document processing vendor before a contract gets signed. No DPA in place means a GDPR violation occurs before a single document is processed, with fines reaching up to EUR 20 million or 4% of global annual turnover orbiqhq.com.

The eight mandatory DPA terms for document API contracts

Article 28(3) doesn't leave much room for interpretation on format. It requires a binding written contract, electronic form included, that spells out the subject matter and duration of processing, its nature and purpose, the types of personal data and categories of data subjects involved, and the obligations and rights belonging to the controller. Eight specific stipulations underlie that framing, and each one maps directly onto how a document API vendor is expected to behave.

The vendor has to process data only on documented instructions from the controller, keep confidentiality commitments in place for every authorized staff member (an obligation that survives even after the contract ends), and implement the security measures Article 32 requires, covering encryption, access control, and incident response. Sub-processor conditions have to flow down the chain.

The eight mandatory DPA stipulations per Article 28(3) are relevant to document API procurement. They're the floor, and a DPA missing even one of them is deficient on its face, regardless of how comprehensive the rest of the document looks. The DPA is the only document that carries legal weight here, so procurement teams must treat it, and not any other material, as the binding basis for compliance. A vendor's help center article or public privacy page promising "we don't train on your data" means nothing if that commitment doesn't appear in the signed contract itself.

With AI and ML extraction APIs, the DPA must expressly cover prompts, outputs, embeddings, attached files, and tool-call results, and vendors who scope these out create an Article 28 gap the controller cannot rely on. Before any file gets sent, the signed DPA must be reconciled against what's actually running in production, and the legal entities, data storage locations, the list of authorized sub-processors, and the version of the security annex all need to match what the paperwork describes.

The processor-becomes-controller risk specific to document AI vendors

Article 28(10) sets a trap door most procurement checklists miss entirely: if a processor determines the purposes and means of processing independently, it is automatically reclassified as a controller and becomes directly liable under GDPR. If a processor starts determining the purposes and means of processing on its own, independent of controller instruction, it gets automatically reclassified as a controller, and that reclassification brings direct liability under GDPR. The CJEU's Russmedia ruling from December 2025 dealt with whether an online marketplace operator counts as a controller (or joint controller) over user-generated content it exerts influence over, which is a platform liability question, not a processor-reclassification question under Article 28(10) orbiqhq.com.

The document AI risk is more specific than that ruling. Vendors that take customer-submitted documents and use them to train or improve their own models, without an explicit instruction from the controller authorizing that use, risk crossing exactly this line. And the consequence lands on the wrong party. A controller organization can't hand off its GDPR liability to a vendor that's quietly operating as a second controller; the contract doesn't shield the controller from exposure just because the vendor was the one making the independent decision.

Most commercial AI providers default to a contractual no-training stance on customer API and enterprise data, but that default only carries legal force because it's written into the contract, not because it's stated somewhere on the website. The same vendor often runs an entirely different default at its consumer tier. Does the DPA explicitly prohibit the vendor from using submitted documents for model training, fine-tuning, embedding generation, or anything beyond the specific extraction task under contract?

Auditing the sub-processor chain behind a document API

Article 28(2) requires prior authorization, specific or general, before a processor can bring in another processor, and Article 28(4) requires that the same data protection obligations governing the primary contract get imposed on every sub-processor down the chain. A single API call to a document processing service rarely touches just one vendor. It typically runs through cloud infrastructure providers, a foundation model provider, an OCR engine, and separate logging and monitoring services, and every one of those links needs to be governed by contract, not assumption.

Regulatory attention here is intensifying. EDPB Opinion 22/2024 is sharpening expectations around sub-processor transparency, an area supervisory authorities are actively focused on. Germany's data protection authority issued a €45 million fine in 2025 tied in part to weak processor oversight, which is a concrete illustration of what happens when the sub-processor chain isn't actually being managed reform.app. Any vendor whose sub-processor list isn't public, isn't kept current, or offers no notification mechanism for changes has failed Article 28(2) on its face, and no amount of reassurance elsewhere in the contract fixes that. Most SaaS vendors handle authorization through general written authorization in the DPA, combined with a publicly maintained sub-processor list and a change notification mechanism. There are practical requirements to verify in the DPA. Advance notice of sub-processor changes is typically required 30 days before adding or replacing a sub-processor. Contractual flow-down requires that if the DPA mandates encryption at rest, every sub-processor must also encrypt at rest.

Cross-border data transfer obligations layered on top of Article 28

Satisfying Article 28 doesn't automatically clear the lawful basis for cross-border transfers. Article 28 DPAs must also address the lawful basis for cross-border transfers; the two obligations are separate, and both must be satisfied. Since the EU-US Privacy Shield was invalidated in the Schrems II decision (Case C-311/18, July 2020), document API vendors processing EU data on US infrastructure must rely on Standard Contractual Clauses plus a transfer impact assessment. The European Commission's 2021 SCCs are the mechanism most vendor DPAs point to, and Module Two, governing the controller-to-processor relationship, is the version that applies to most of these arrangements.

A handful of gaps tend to survive even a careful surface review of these contracts. Sometimes the DPA names the SCCs but never actually appends them as an annex, which leaves the reference floating without the underlying document. Sometimes the deal moves UK or Swiss personal data alongside EU data, and that requires its own UK Addendum or Swiss annex, separate from the standard EU clauses.

For regulated industries, the cleanest way through this is often avoiding the question altogether. Where jurisdiction of processing is a hard legal requirement, EU-resident data processed on EU infrastructure sidesteps the transfer analysis entirely, so it's worth checking whether the vendor offers EU-only deployment as a configuration option. Beyond that, the DPA should specify the processing location for each sub-processor individually and document a valid transfer mechanism for each non-EEA location.

Security obligations Article 28 requires vendors to satisfy

Article 28(3)(c) points back to Article 32, which requires technical and organizational measures proportionate to the actual risk of the processing. For document APIs handling financial records, health data, or identity documents, that risk sits high by default, and the controller has an obligation to confirm the vendor's measures are genuinely adequate rather than simply take the vendor's word for it.

Certifications offer a useful, if imperfect, proxy for that verification. SOC 2 Type II demonstrates operational security controls sustained over time, and for document APIs the controls that matter most are encryption in transit and at rest (AES-256, TLS 1.3) along with access logging detailed enough to show timestamps and user identity for every touch. ISO 27001 satisfies procurement requirements across the EU, UK, and APAC markets and functions as the international shorthand for organizational security maturity that GDPR-adjacent buyers look for. Article 28(5) acknowledges that adherence to an approved certification mechanism can serve as an element demonstrating "sufficient guarantees".

None of that substitutes for the contractual right to check. Article 28(3)(h) gives the controller the right to conduct or mandate audits and inspections directly, and a DPA that quietly swaps that entitlement for a "right to receive a summary report" has narrowed something the statute guarantees. Breach notification deserves the same scrutiny. Article 28 requires the processor to notify "without undue delay" after becoming aware of a breach, and that phrase can't be allowed to stretch past whatever concrete timeline the controller's own regulatory clock demands, typically the 72-hour window supervisory authorities expect. The commercial stakes back this up: the average cost of a data breach for US companies hit a record $10.22 million in 2025, so the legal case for vendor security rigor and the financial case point in the same direction truto.one.

Zero-retention architecture as the structural answer to Article 28's deletion obligation

Article 28(3)(g) requires the processor, at the controller's choice, to delete or return all personal data once services end and to delete any existing copies, absent a legal requirement to retain. The phrase "end of services" sounds simple until you try to pin it down for an API. Does deletion happen after each individual call, only at contract termination, or whenever the controller specifically requests it? A DPA silent on that distinction leaves the obligation open to interpretation nobody can enforce.

Zero-retention architecture removes the ambiguity by removing the thing being argued about. If input files are processed entirely in memory and deleted the instant the request completes, there's no stored document content sitting around waiting to be deleted later, so the obligation gets satisfied by the design of the system itself rather than by a manual process someone has to remember to run. The contract language should match that architecture explicitly: a statement that files are processed in memory and deleted immediately on completion, not vague or implied language that leaves room for doubt.

A complementary pattern to look for is metadata-only logging: timestamp, client ID, file size, processing duration, and jurisdiction, none of it personal data in itself, but enough to answer an audit question years later without keeping the underlying document around. At contract exit, a few practical steps matter beyond whatever the DPA clause says on paper: test a full data export before the service actually ends, agree in advance on how backups and any legally retained copies get treated, and keep a record of the deletion instruction along with confirmation it was carried out. A processor cannot engage another processor without prior specific or general written authorization from the controller, and the same data protection obligations in the controller–processor contract must be imposed on every sub-processor by contract.

Vendors that keep documents around for any stretch of time, for model improvement, quality checks, or debugging, reopen the exact deletion problem this section is meant to close, and the controller needs the authorized retention period documented in the DPA itself, not assumed from a conversation with a sales rep. This ties directly back to the reclassification risk raised earlier: a vendor running true zero retention simply can't use submitted documents for model training, because the documents are gone before any training pipeline could touch them. The architecture closes the deletion gap and the purpose-limitation risk at the same time.

A practical evaluation framework: questions to ask any document processing API vendor before signing

Every question below traces back to a specific Article 28 obligation covered above; none of it is a generic security questionnaire lifted from a template.

Does that DPA cover every data type the API will actually ingest, including AI-specific flows like embeddings, tool-call results, or raw model inputs? Has the DPA version been reconciled against the live service configuration, with the legal entities, data locations, and sub-processor list named in the contract matching what's actually running?

On purpose limitation: does the DPA explicitly prohibit the vendor from using submitted documents for training, fine-tuning, or any purpose outside the contracted extraction task? On sub-processors: does the contract include a 30-day advance notice mechanism and a genuine objection right when a sub-processor changes? If UK or Swiss data is part of the arrangement, does the DPA include the corresponding UK Addendum or Swiss annex? And finally, does the vendor offer an EU-only or on-premise deployment option that removes cross-border transfers from the arrangement entirely?

None of these questions are exotic. They're the direct, traceable consequence of what Article 28 already requires, and a vendor unable to answer them clearly, in the contract rather than in a sales call, has already told a procurement team most of what it needs to know. One key question is whether the vendor offers a signed DPA, or only a published privacy policy, since a missing DPA constitutes an immediate violation. Another key question is whether the 2021 EC SCCs are appended in the DPA, with the correct module, namely Module Two for controller-to-processor.