Article 28 Clauses

What Article 28 Clauses Cover

Article 28 clauses turn GDPR controller-processor expectations into contractual obligations. They define what the processor may do with personal data, how security and confidentiality must be handled, how sub-processors are governed, and what support the processor must provide so the controller can meet its own accountability duties.

For organisations, these clauses matter because GDPR compliance does not stop at selecting a processor. The controller must be able to point to written terms that describe processing scope, permitted instructions, audit support, deletion or return at end of service, and other operational commitments that keep the relationship legally and technically controlled.

Why Article 28 Matters in Data Processing Relationships

Article 28 clauses are the bridge between legal responsibility and operational delivery. They convert abstract obligations into enforceable contract terms, which is why they are central to vendor onboarding, outsourcing, cloud services, managed services, and any arrangement where a third party processes personal data on a controller’s behalf.

They are also where organisations shape expectations for sub-processing and assistance with requests, incidents, and compliance evidence. A weak clause set can leave the controller relying on informal assurances instead of verifiable commitments, which is especially problematic when the processor is deeply embedded in core business systems or handles sensitive data.

For a broader view of how Article 28 sits inside the GDPR control model, the EU General Data Protection Regulation (GDPR) remains the primary legal reference point.

Security, Sub-Processing, and Accountability Expectations

Although Article 28 is a legal construct, it has a real security function. The clause set is where organisations require appropriate technical and organisational measures, constrain who can access personal data, and define how downstream subprocessors are approved and controlled. That makes it a governance control as much as a contractual one.

Article 28 also supports evidence-based oversight. If a processor cannot explain its controls, its sub-processor chain, or its deletion and return processes, the controller has a harder time demonstrating accountability. In practice, this is where privacy obligations intersect with vendor security management, data handling discipline, and exit planning.

NHIMG’s Third-Party Security Contract Clauses Template is useful when the Article 28 discussion extends into supplier security terms, audit rights, subprocessors, and exit language.

For teams managing processor contracts in a broader GDPR programme, the GDPR Compliance Guide for Security Teams helps place Article 28 alongside security of processing, breach handling, and controller oversight.

Common Gaps in Article 28 Drafting

Article 28 clauses often fail when they are too generic to operationalise. A contract may mention “appropriate security” without specifying the processor’s duty to notify before adding subprocessors, support data deletion at termination, or cooperate with controller audits and assessments. Those omissions matter because they leave the controller without enforceable leverage when the relationship changes.

Another common gap is assuming that a processor’s standard paper is enough. Controllers should expect the clause set to align with the actual service model, including where data is hosted, who can administer it, and how the processor handles exports, retention, and destruction. Where the service is cloud-based, that often means mapping contractual terms to a recognised privacy control baseline, not just relying on marketing assurances.

For cloud processors handling personal data, the ISO/IEC 27018 Cloud PII Protection Guide gives a practical lens on provider commitments, sub-processor disclosure, and PII handling expectations.

Risk and Threat Considerations

Article 28 clauses create risk when they are vague, incomplete, or misaligned with the processor’s actual operations. The main exposure is loss of controller oversight: data may be passed to unauthorised subprocessors, retained longer than expected, or handled without the security and deletion commitments the controller assumes are in place.

Failure mechanism: Weak contract language lets a processor expand processing scope, rely on undisclosed subprocessors, or fail to support deletion, audit, and security obligations when the relationship changes or is terminated.

Impact: The controller can lose contractual control over personal data handling, weaken its ability to demonstrate GDPR accountability, and face heightened exposure if the processor suffers a security incident or disputes its obligations.

Practitioner Guidance

Governance implication: Treat Article 28 as a control artifact, not a legal formality. The contract should reflect the real data flow, the actual sub-processor model, and the operational steps needed to prove oversight, security, and termination handling.

What to watch for: Pay close attention when a processor changes hosting, adds a subprocessor, broadens service scope, or resists deletion and audit commitments. Those are the moments when Article 28 terms often diverge from practice.

Where the relationship includes vendor exit, access removal, or data destruction commitments, Vendor Offboarding and Termination Guide is a natural companion because it turns contract language into a clean termination process.

For teams building a broader third-party control set, Privacy Policy Template helps connect processor terms to internal governance, retention, rights handling, and breach response.

Related resources from NHI Mgmt Group

• What happens when controller and processor clauses are not aligned with Article 28 obligations?
• How does Article 28 Processor Terms work?
• How do organisations implement Article 28 processor terms?
• What are common mistakes with Article 28 Processor Terms?