Common mistakes are using incomplete processor terms, leaving out sub-processors, audit rights, breach duties, or deletion obligations, and not matching the contract to the actual service. Controllers should check that the terms cover the required processing instructions, security measures, and end-of-service data handling, and that supplier changes trigger review.
How Article 28 processor terms usually fail in practice
Most Article 28 mistakes are not subtle legal debates, they are gaps between what the contract says and what the processor actually does. The common failure pattern is that the template looks complete, but it does not describe the real processing instructions, the real sub-processor chain, or the real end-of-service handling. That creates a mismatch between governance, operations, and supplier behaviour.
A second frequent mistake is treating processor terms as a one-time procurement artefact. If supplier tooling, hosting, support access, or data flows change after signature, the terms can become stale even though the relationship has materially changed. The practical issue is not just missing clauses, it is failing to keep the contract aligned with the live service.
Which clauses are most often missing or too vague?
The weakest agreements usually omit one or more operational obligations that matter most when something goes wrong. NHIMG’s GDPR Compliance Guide for Security Teams is useful here because Article 28 sits alongside security of processing, breach handling, and controller-processor role clarity, all of which need to be reflected in the contract, not assumed from policy.
In practice, the clauses that get missed are the ones that create accountability: sub-processor approval and notification, audit and assurance rights, breach notification duties, deletion or return obligations at termination, and minimum security requirements. If any of those are left open-ended, the controller may still be responsible for the outcome without having a contractual lever to enforce it.
It is also common to see generic wording that says the processor will “act securely” or “support compliance” without specifying the actual processing instructions, categories of data, retention limits, or transfer conditions. That kind of language looks reassuring but is weak evidence that the supplier is contractually bound to do the right thing under pressure.
What should controllers check before signing, and when the service changes?
Controllers should verify that the terms match the live service, not just the procurement description. That means checking whether the processor will use sub-processors, where the data will be stored or accessed, whether support staff can reach production data, and whether the exit path includes deletion, return, and confirmation of completion.
Controllers should also confirm that supplier change control triggers a contract review. If the vendor adds a new hosting region, introduces a new support partner, or changes how incidents are handled, the Article 28 terms may need an update or a formal addendum. A contract that was correct at signature can become inaccurate after a product or service change.
The strongest agreements are the ones that can be tested against reality: what data is processed, by whom, under what instructions, with which security measures, and with what evidence of deletion or return when the relationship ends. If those answers are not available, the contract is usually too thin to support operational control.
Risk and Threat Considerations
Weak processor terms create exposure because they leave critical handling obligations ambiguous at the exact points where privacy, security, and accountability failures are most likely. The practical risk is not only non-compliance, but also loss of control over sub-processing, incident response, and data lifecycle handling when the service is under stress.
Failure mechanism: A controller relies on a contract that does not clearly bind the processor to follow instructions, disclose sub-processors, notify breaches, or delete data on exit, so the real service diverges from the intended control model.
Impact: That gap can delay response, weaken auditability, extend data retention beyond what was intended, and make it harder to prove that personal data was handled lawfully and securely.
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 and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| GDPR | Art. 28 — Processor | Article 28 directly governs processor terms, instructions, sub-processors, security and deletion duties. |
| Recommendation — Review processor contracts to ensure instructions, sub-processors, security and deletion duties are explicit. | ||
| ISO/IEC 27001:2022 | A.5.19 — Information security in supplier relationships | Processor terms are a supplier control issue that depends on enforceable third-party security obligations. |
| A.5.20 — Addressing information security within supplier agreements | The subject is specifically about what clauses must be present in processor agreements. | |
| Recommendation — Include contractual security obligations and oversight for processors in supplier management. Put security, audit, incident and exit obligations into supplier agreements. | ||
| NIST SP 800-53 Rev 5 | SA-9 — External System Services | Processor terms define required conditions for externally provided processing services. |
| SR-3 — Supply Chain Controls and Processes | Supplier changes and sub-processors are supply-chain governance issues with contract implications. | |
| Recommendation — Define required security controls and responsibilities for external processing services. Apply supplier control requirements to sub-processors and service changes. | ||
| CIS Controls v8 | 15 — Service Provider Management | The question is about common mistakes in third-party processor contracting and oversight. |
| Recommendation — Verify service provider obligations, oversight and offboarding requirements before approval. | ||
Practitioner Guidance
What to verify: Confirm that the processor terms describe the actual service design, including sub-processors, support access, retention, breach notification, and deletion or return at termination. If the contract is more generic than the service, treat that as a review failure rather than a drafting detail.
Decision rule: If the supplier can change infrastructure, support model, or processing locations without a contract review trigger, the terms are too weak for reliable governance. Tie material service changes to legal and security re-review so the agreement does not drift away from the operating reality.
Practitioner takeaway: Article 28 terms are only effective when they bind the live service, so the real test is not whether the document exists, but whether it still matches what the processor actually does.