Article 28 processor terms are the contractual clauses a controller must put in place when using a processor for personal data processing. They should define subject matter, duration, nature and purpose of processing, confidentiality, security, sub-processing, assistance, deletion, and audit rights. Teams should check that the contract matches the actual data flows and service scope.
What Article 28 processor terms actually do
Article 28 processor terms are not just boilerplate, they are the legal mechanism that turns a vendor relationship into a controlled data-processing arrangement. They define what the processor may do, for how long, and under what instructions, so the controller can show that personal data handling stays within an agreed scope rather than drifting into informal or implied use.
That scope matters because the contract should match the real service, real data flows, and real operational boundaries. If the processor is handling only limited personal data, the terms should not read like a broad outsourcing agreement; if the processor has access to sensitive production data, the clauses should reflect stronger obligations around confidentiality, security, sub-processing, assistance, deletion, and audit rights.
A practical way to think about Article 28 is that it forces precision. The terms should describe the subject matter of processing, duration, nature and purpose, the categories of data and data subjects, and the controller’s instructions. When those details are vague, teams often end up with a contract that looks compliant on paper but does not actually govern the service being delivered.
Where Article 28 terms fail in practice
Most failures start when procurement, legal, privacy, and technical teams work from different assumptions. One team may think the supplier is only hosting a system, while another believes the supplier can support, troubleshoot, replicate, or export the data. Article 28 terms are meant to close that gap by making the processing model explicit and by tying the contract to the actual system design and operating model.
That is why review should include the exact data flows, sub-processors, support access, retention behaviour, and exit process. If a supplier can engage other processors, the controller needs visibility and control over that arrangement. If the supplier needs to delete or return data at termination, the contract should state what that means operationally, not just legally. The same is true for assistance with data subject requests, security incidents, and compliance queries.
NHIMG’s GDPR Compliance Guide for Security Teams is useful here because it ties Article 28 terms to the surrounding GDPR obligations that usually determine whether a vendor arrangement is actually under control, including security of processing and accountability.
What good Article 28 governance looks like
Good governance starts before signature. The contract should be reviewed against the architecture diagram, the data inventory, and the operational support model so that the legal text matches the way the processor will really touch personal data. If the service changes, the contract should be revisited, because a narrow onboarding review is not enough to keep pace with new integrations, new regions, or new sub-processors.
Teams should also make auditability real. That means knowing who can inspect the processor’s controls, what evidence can be requested, how sub-processor changes are tracked, and how deletion or return is verified at the end of the relationship. A contract without a workable verification path often gives a false sense of control.
Top 10 Privacy Compliance Mistakes is a useful companion because it highlights the recurring operational gaps, especially contracts that do not line up with actual processing, retention, transfer, or processor oversight.
Risk and Threat Considerations
Article 28 terms are a control over exposure, not just documentation. When they are too generic, the organisation can lose oversight of where personal data goes, who can access it, and whether the processor’s support model creates hidden transfer, retention, or sub-processing risk.
Failure mechanism: The controller assumes the contract covers the real service, but the processor’s live operating model includes broader access, onward sharing, or retention than the terms describe. That mismatch weakens accountability and can leave the controller unable to prove that processing stays within authorised limits.
Impact: The organisation may face unlawful processing, weak enforcement of deletion or return duties, poor incident response coordination, and difficulty demonstrating compliance during an audit or regulatory inquiry. In a dispute, vague processor terms also make it harder to enforce security, confidentiality, and sub-processor obligations.
EU General Data Protection Regulation (GDPR) is the primary external reference for the Article 28 requirement itself, while the contract terms sit alongside the GDPR’s broader processing, security, and accountability obligations.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
GDPR and ISO/IEC 27001:2022 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| GDPR | Art. 28 — Processor | Article 28 is the direct legal basis for processor contract terms. |
| Art. 32 — Security of processing | Processor terms must support security obligations for personal data processing. | |
| Art. 5 — Principles relating to processing of personal data | Processor terms must align with purpose limitation, minimisation, and accountability. | |
| Recommendation — Map processor duties, security, sub-processing, assistance, deletion, and audit rights into the contract. Require appropriate technical and organisational measures for processor-held personal data. Align contracted processing scope with the actual data flows and stated purpose. | ||
| ISO/IEC 27001:2022 | A.5.19 — Information security in supplier relationships | Processor terms are a supplier-control mechanism governing security obligations. |
| A.5.20 — Addressing information security within supplier agreements | The contract should codify security and privacy duties for the processor relationship. | |
| A.5.21 — Managing information security in the ICT supply chain | Sub-processing and downstream service dependencies create supply-chain security exposure. | |
| Recommendation — Include supplier security obligations and oversight in the contractual relationship. Write security responsibilities, auditability, and handling requirements into the agreement. Control downstream service dependencies and review changes in the processor chain. | ||
Practitioner Guidance
What to verify: Check that the signed Article 28 terms match the actual service scope, data categories, support model, and sub-processing chain. If the vendor will touch production personal data, verify that deletion, audit, and assistance clauses are operationally testable, not just legally promised.
Decision rule: If the contract cannot be tied back to a current data-flow map, treat it as incomplete and do not rely on it as evidence of control. If the service has changed since signature, revalidate the terms before renewal, expansion, or incident response depends on them.
Practitioner takeaway: Article 28 is only effective when the legal wording and the real processing relationship stay aligned; the moment those diverge, the contract stops being a control and becomes only paper.