Processor agreements are one of the most audited documents a DPO will ever own. Supervisory authorities routinely request them during investigations, and fines have followed not because data was misused, but because the underlying contract was missing a required element. Article 28 of the GDPR sets a precise floor. What follows is a clause-by-clause account of that floor — drawn directly from the regulation's text — along with the practical decisions that separate a defensible agreement from a template that merely looks the part.

Why does Article 28 exist at all?

GDPR's accountability principle, established in Article 5, places the burden of demonstrating compliance squarely on the controller. A controller that outsources processing to a cloud provider, payroll bureau, or analytics vendor has not outsourced that accountability. Article 28 closes the loop: if a controller cannot produce a written agreement showing the processor was bound to compliant behaviour, the controller has demonstrably failed its Article 5 obligations, regardless of what the processor actually did.

Article 28 also imposes a due-diligence gate. Before signing anything, the controller must use only processors "providing sufficient guarantees to implement appropriate technical and organisational measures in such a manner that processing will meet the requirements of this Regulation". That phrase is not boilerplate — it is a pre-contract selection obligation. A controller that picks a processor on price alone, without reviewing that processor's security posture, certifications, or audit reports, has arguably breached Article 28 before the ink is dry.

What must the contract actually contain?

Article 28(3) requires the contract — or equivalent legal act — to bind the processor on eight specific points. Each one is mandatory, not optional.

Instruction-bound processing. The processor must process personal data only on documented instructions from the controller, including with regard to transfers to third countries or international organisations. The processor may deviate only where required by Union or Member State law, and even then must inform the controller of that legal requirement before processing, unless the law prohibits disclosure on public-interest grounds. This clause is the source of truth for scope control: any processing activity not covered by a documented instruction is unauthorised.

Confidentiality of authorised personnel. All persons authorised to access the personal data must be bound by confidentiality — either by contract or by an appropriate statutory obligation. This obligation sits on the processor, but the controller's agreement must make it mandatory.

Security measures. The processor must implement all measures required under Article 32, which covers the security of processing. The DPA need not reproduce Article 32 verbatim, but it must make compliance with it a binding contractual obligation.

Sub-processor governance. The processor must respect the conditions in Article 28(2) and 28(4) when engaging a sub-processor. Article 28(2) prohibits engaging any further processor without the controller's prior specific or general written authorisation. Where general authorisation has been granted, the processor must still inform the controller of any intended addition or replacement of sub-processors, giving the controller a meaningful opportunity to object. This notification-and-objection mechanism is frequently missing from vendor-standard DPAs — its absence makes the general-authorisation clause unenforceable in practice.

Assistance with data subject rights. Taking into account the nature of the processing, the processor must assist the controller — through appropriate technical and organisational measures — in fulfilling the controller's obligation to respond to data subject requests under Chapter III. "Assist" is deliberately broad: it encompasses search and retrieval capabilities, not merely forwarding requests.

Compliance assistance (Articles 32–36). The processor must assist the controller in ensuring compliance with the obligations in Articles 32 through 36 — security, breach notification, data protection impact assessments, and prior consultation — calibrated to the nature of the processing and the information available to it. A processor running a high-risk pipeline but claiming it has nothing to contribute to a DPIA is not meeting this standard.

Return or deletion at end of services. At the controller's choice, the processor must either delete or return all personal data at the end of the service relationship, and must delete existing copies — unless Union or Member State law requires retention. The choice belongs to the controller. Any DPA that lets the processor decide unilaterally what happens to data after termination is deficient.

Audit and information rights. The processor must make available all information necessary to demonstrate compliance with Article 28 and must allow for and contribute to audits, including inspections, conducted by the controller or another auditor the controller mandates. Alongside this, the processor must immediately inform the controller if it believes a controller instruction would infringe the GDPR or other applicable data protection law.

Who is actually the controller and who is the processor?

The distinction matters because Article 28(10) draws a sharp line: if a processor determines the purposes and means of processing — rather than following the controller's instructions — the processor is deemed a controller for that processing, with full direct liability. This reclassification can happen silently, through contract drift or scope creep.

A common failure mode is "joint processing by another name": the vendor selects the retention period, decides what data to collect for its own analytics, or determines which third countries receive the data. Each of those decisions crosses the controller/processor boundary. Controllers should map every decision point in the processing activity and verify that the processor's documented instructions account for all of them — or acknowledge where the relationship is actually joint and structure it under Article 26.

How do sub-processors fit in?

Sub-processors are processors engaged by the initial processor. Article 28(4) requires that the same data protection obligations set out in the controller–processor contract be imposed on every sub-processor, by contract. Critically, if a sub-processor fails to meet those obligations, the initial processor remains fully liable to the controller.

This creates a chain-of-liability architecture. A controller with general-authorisation language in its DPA is not absolved of governance responsibility — it has delegated that responsibility to the processor, which must enforce equivalent obligations down the chain. Require your processors to maintain an up-to-date sub-processor list and to flow down all Article 28(3) obligations contractually, not merely by reference.

What happens when the processor transfers data internationally?

Article 44 establishes the general principle: any transfer of personal data to a third country or international organisation — including onward transfers — must comply with Chapter V in full, and must not undermine the level of protection guaranteed by the GDPR.

Article 28(3)(a) connects directly to this: the processor's instruction-bound obligation explicitly covers transfers to third countries or international organisations. A controller cannot authorise a transfer simply by including a broad instruction clause; the transfer itself must be covered by an appropriate safeguard under Article 46 — such as standard contractual clauses adopted by the Commission, binding corporate rules, an approved code of conduct with binding commitments, or an approved certification mechanism. In the absence of an adequacy decision under Article 45, Article 46 requires that enforceable data subject rights and effective legal remedies remain available in the destination country.

In practice, the DPA and any transfer mechanism must be read together. A DPA that grants the processor wide latitude to host data anywhere it chooses, with no transfer mechanism specified, simultaneously breaches Article 28 (undocumented transfer instruction) and Article 44 (transfer without a compliant safeguard).

FAQ

Does the agreement have to be a separate document? No — Article 28(3) requires a contract or other legal act under Union or Member State law that is binding on the processor, in writing including electronic form. It can be a schedule to a master services agreement, provided it contains the mandatory elements.

Who decides whether data is deleted or returned at the end? The controller. Article 28(3) frames it as the controller's choice; a DPA that defaults the decision to the processor is non-conforming.

We granted general sub-processor authorisation — are we done? No. General authorisation still requires the processor to notify you of additions or replacements and to give you the opportunity to object, and the same Article 28(3) obligations must flow down to every sub-processor.

Can a broad instruction clause cover international transfers? Not on its own. The transfer still needs an Article 46 safeguard (or an Article 45 adequacy decision); the instruction clause documents the controller's authorisation, it does not create the legal basis for the transfer.

How Aigis GRC operationalises Article 28

Aigis GRC maps every Article 28(3) sub-obligation to an auditable expectation in your compliance programme. When a processor relationship is registered, the platform flags missing clauses, tracks sub-processor authorisations, and surfaces transfer-mechanism gaps alongside your Article 44 and 46 obligations. Audit trails are append-only, so every version of a DPA and every authorisation decision is retained for supervisory review.

If you would like to see how Aigis GRC builds Article 28 coverage into your processor inventory, visit agrc.ai to request a walkthrough.