GDPR Article 28 sets the rules for using processors, third parties that handle personal data for a controller. It requires written contracts, defined processing instructions, confidentiality, security, subprocessor controls, and deletion or return of data when the service ends, creating accountability across outsourced data processing.
How GDPR Article 28 Shapes Processor Relationships
Article 28 is the contractual control point between a controller and a processor. It turns outsourced processing into a governed relationship by requiring the processor to act only on documented instructions and under defined obligations.
The practical effect is that the controller does not simply “buy a service”, it delegates a processing activity that must stay within a legally bounded scope. That makes the article central to vendor onboarding, contract review, and the allocation of responsibility when personal data is handled outside the controller’s direct environment.
What Article 28 Requires in a Processing Contract
The core requirement is a written contract or other binding legal act that sets out the processor’s duties. Those duties typically include confidentiality, security, use restrictions, subprocessor controls, assistance with rights requests, and handling of data at the end of the service relationship.
For practitioners, the important point is that Article 28 is not satisfied by generic procurement language. The contract has to operationalise how the processor may handle personal data, what instructions govern that handling, and what happens if the processor wants to involve another service provider. NHIMG’s Ultimate Guide to NHIs, Regulatory and Audit Perspectives is useful for the broader governance lens on accountability, auditability and control ownership.
Why Article 28 Matters for Data Governance and Accountability
Article 28 matters because many privacy failures happen not in the controller’s own systems, but in the external services that receive data for processing. The article creates a chain of accountability so the controller can evidence that the processor is constrained, supervised, and contractually bound.
That governance role is why Article 28 often sits alongside records of processing, vendor risk reviews, and privacy oversight. It helps answer a question auditors and regulators often ask: who is responsible for the data when it leaves the controller’s direct control? The Identity Security Regulatory Map is a useful companion when mapping control obligations across GDPR and related regimes, while the EU General Data Protection Regulation (GDPR) provides the canonical legal text for Article 28 and its surrounding obligations.
How Article 28 Connects to Security and Data Handling Controls
Although Article 28 is a legal provision, its requirements are deeply operational. Processors must support confidentiality, appropriate technical and organisational measures, and secure deletion or return of data when processing ends. In practice, that means the clause set needs to align with access restrictions, retention rules, subprocessors, and incident response expectations.
One common weakness is treating processor oversight as a one-time contract review rather than an ongoing control. If the processor changes its own suppliers, handling model, or deletion process without governance, the controller may lose the assurance Article 28 is meant to provide. The same governance logic appears in the GDPR Compliance Guide for Security Teams, which ties Article 28 to security of processing and broader accountability, and in the CIS Controls v8, which reinforces practical control areas such as access control, account management and data protection.
What Practitioners Should Review When Applying Article 28
Practitioners should read Article 28 as a control design requirement, not just a procurement clause. The main judgement is whether the processor agreement accurately reflects the actual data flows, service model, and responsibilities that exist in production.
That usually means checking that the contract matches the processing purpose, that subprocessor approval and flow-down obligations are explicit, and that exit handling is realistic for both deletion and return. The most useful review habit is to treat the processor relationship as part of the security and privacy operating model, not as a legal appendix. The Data Mapping and ROPA Guide is especially helpful where Article 28 needs to be aligned with actual inventories and data flows.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while GDPR and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| GDPR | Article 28 — Processor | Article 28 is the processor contract rule for outsourced personal data handling. |
| Recommendation — Bind processors to documented instructions, security, subprocessor controls, and deletion or return duties. | ||
| CIS Controls v8 | CIS-5 — Account Management | Article 28 depends on controlled third-party access and account governance over processor environments. |
| CIS-3 — Data Protection | Article 28 requires controls over handling, retention, deletion, and confidentiality of processed data. | |
| Recommendation — Restrict and review processor access paths that handle personal data. Apply data protection controls to contracted processing and data disposal obligations. | ||
| NIST SP 800-53 Rev 5 | AC-20 — Use of External Systems | Processors are external systems handling organisational data under defined conditions. |
| Recommendation — Limit and monitor how external systems process or store personal data. | ||
| ISO/IEC 27001:2022 | A.5.19 — Information security in supplier relationships | Article 28 is fundamentally about governing supplier processing of personal data. |
| Recommendation — Define supplier security obligations for any processor handling personal data. | ||