Organisations implement Article 28 processor terms by putting a written contract in place with each processor and checking it covers the required processing instructions, confidentiality, security, sub-processing, assistance and return or deletion of data. Security teams should confirm contracts match actual data flows, processor controls, breach handling and audit rights, then review them when processing changes.
What Article 28 processor terms must cover
Article 28 is a contract design problem as much as a legal one. The processor terms should spell out what the processor may do, why it may do it, and the guardrails around security, sub-processing, assistance, deletion or return, and audit support. The practical test is whether the written terms match the real processing relationship, not just the template language.
That means the contract should align to the actual data flows and the processor’s operational role. If the agreement is broader than the service, or narrower than what the processor really does, organisations end up with unenforceable expectations and gaps in accountability when incidents, access requests, or retention decisions arise.
How teams check that the contract is operationally complete
Security, privacy, and procurement teams should validate the contract against the live service description, not in isolation. The key question is whether the instructions cover the full processing scope, including categories of data, permitted purposes, confidentiality obligations, security measures, approved sub-processors, and how assistance will work for requests, incidents, and deletions. For the underlying GDPR obligations, the processor term should be read alongside the EU General Data Protection Regulation (GDPR) so the clause set matches the legal baseline rather than an internal shortcut.
Contract review also needs to test implementation reality. If the processor can technically access production data, replicate it to another region, or involve a sub-processor, the agreement should say so and should define the approval, notice, and control expectations. If the service uses security controls that are documented elsewhere, the terms should still make those controls contractually enforceable rather than merely aspirational.
Where the processor relationship is part of a broader regulated outsourcing or resilience model, teams should also make sure the contract supports continuity and exit obligations. That is especially important when the processor is embedded in business-critical operations, because the clause set may need to support incident handling, auditability, and orderly offboarding as well as simple data processing permissions. The DORA Guide is useful where the processor relationship sits inside ICT third-party risk management and exit planning.
When processor terms become a control failure
Processor terms fail most often when the paper contract and the live service drift apart. Common failure modes include vague security language, missing instructions for sub-processing, weak deletion or return commitments, and audit rights that exist on paper but cannot be exercised in practice. That gap matters because the controller remains accountable for the processing chain even when a processor is doing the operational work.
Another failure mode is treating the contract as a one-time procurement step. If the processor’s architecture, data handling, hosting region, support model, or incident procedures change, the original terms may no longer describe the actual risk. At that point the organisation may still believe it has contractual coverage while the real exposure has shifted. A good privacy control review should therefore treat contract maintenance as a living obligation, not a filing exercise, and compare it to the service’s current processing profile. The Top 10 Privacy Compliance Mistakes is a useful reminder of how often processor clauses fail when operational change outpaces governance.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while GDPR, ISO/IEC 27001:2022 and SOC 2 (AICPA) define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| GDPR | Art. 28 — Processor | Article 28 is the exact processor-contract requirement at issue. |
| Recommendation — Draft written processor terms that cover instructions, security, sub-processing, assistance, and deletion or return. | ||
| NIST SP 800-53 Rev 5 | SA-9 — External System Services | Processor terms govern security obligations for an external service provider handling data. |
| Recommendation — Flow security and audit obligations into the external service contract and review them on change. | ||
| ISO/IEC 27001:2022 | A.5.19 — Information security in supplier relationships | Processor terms are a supplier security control governing outsourced processing. |
| Recommendation — Include supplier security requirements and monitoring in the processor agreement. | ||
| CIS Controls v8 | CIS-15 — Service Provider Management | Processor terms are part of managing third-party service risk and contractual safeguards. |
| Recommendation — Require contractual controls and ongoing review for service providers handling sensitive data. | ||
| SOC 2 (AICPA) | CC9.2 — Subservice Organizations | Processor sub-processing and oversight map to assurance over subservice organizations. |
| Recommendation — Obtain and review subservice commitments before relying on the processor relationship. | ||
Practitioner Guidance
What to verify: Confirm that the signed processor terms match the current service description, data map, security obligations, and sub-processor list. If the vendor contract is generic, ask whether the vendor can actually meet the deletion, assistance, and audit commitments in the timeline and form you need.
Decision rule: If the processor handles regulated, sensitive, or operationally critical data, do not accept “standard terms” without a line-by-line check against the real processing activity. Where the service is high-impact, the contract should be reviewed together with security architecture, breach handling, and exit arrangements, not after go-live.
What practitioners underestimate: The hardest part is often not drafting the clause, but proving the processor’s operating model still fits the clause six months later. The most useful control is a repeatable review trigger for material changes in processing, hosting, sub-processing, or incident handling.
Practitioner takeaway: Article 28 terms are only effective when they bind the actual service, so the priority is continuous contract-to-operations reconciliation, not one-time legal approval.