What Is Article 28.5 GDPR? Definition & Examples

The GDPR provision that addresses processor obligations and the safeguards needed when a controller uses a processor. It matters because cloud providers often rely on it to demonstrate that their contractual and operational arrangements support lawful processing, appropriate security, and auditable compliance.

Processor obligations under Article 28.5

Article 28.5 is the processor-side counterpart to controller due diligence: it requires the processor to implement safeguards so that processing is only carried out on documented instructions and with security, confidentiality, and compliance discipline. The practical point is not just contract language, but whether the processor can actually operate in a way that supports lawful processing and auditability.

For cloud and managed-service environments, this article is often where legal terms meet operational reality. A processor that cannot evidence access control, subprocessor oversight, retention discipline, or incident handling may be contractually compliant on paper but weak in practice. That is why compliance teams often read Article 28.5 together with the surrounding processor duties and the security obligations in the wider GDPR framework, including the EU General Data Protection Regulation (GDPR).

What the provision expects from a processor

The provision expects the processor to follow the controller’s lawful instructions and to keep the processing environment constrained, documented, and reviewable. In practice, that means the processor should be able to explain who can access data, where data is processed, how subcontractors are governed, and how deviations are detected and corrected.

That expectation is especially important where the processor uses complex infrastructure, shared services, or layered subcontracting. The legal question is still simple: can the processor demonstrate that its operating model does not expand the controller’s risk beyond what was authorised? That is where security controls, logging, change control, and data handling discipline become part of compliance rather than separate concerns. For practitioners mapping this to operational safeguards, CIS Controls v8 provides a useful control-oriented lens on access, logging, and data protection, while the NIST Privacy Framework helps structure privacy risk and data-governance thinking around the same obligations.

Why auditability and security evidence matter

Article 28.5 is not satisfied by a vague promise of “good security.” The processor needs evidence that it can preserve confidentiality, prevent unauthorised disclosure, and show how processing is controlled over time. Audit trails, policy enforcement, and contractually traceable subprocessor arrangements are often what make that evidence credible.

This matters because processors are frequently asked to support downstream assurance requests, due diligence, and regulatory review. Where that evidence is missing, the controller may not be able to prove that processing remained within scope, and the processor may be unable to show that security obligations were consistently met. In other words, the compliance burden is operational, not merely legal.

How to interpret Article 28.5 in modern service architectures

In modern cloud and SaaS environments, Article 28.5 is best understood as an operating standard for processor conduct, not a one-time legal checkbox. The provision becomes meaningful when the processor can align contractual obligations, technical safeguards, and evidence generation into a single compliance story.

For data-rich services, the strongest implementations are the ones that make governance inspectable: controlled admin access, documented subprocessors, clear retention and deletion handling, and traceable change management. Where that structure is weak, compliance risk often shows up later as audit friction, unresolved processor liability, or difficulty demonstrating that the processing stayed within the controller’s instructions. NHIMG’s Ultimate Guide to NHIs, Regulatory and Audit Perspectives is useful here because it frames how governance, audit trails, and access control support auditable processing at scale, even when the underlying operational estate is complex.

Risk and Threat Considerations

Article 28.5 creates risk when processor safeguards are weaker than the controller assumes. The main exposure is not abstract non-compliance, but unauthorised processing, poor subprocessor control, weak evidence of security, and gaps that can obstruct audits or incident response.

Failure mechanism: A processor may have broad internal access, unclear subcontracting, weak logging, or inconsistent instruction enforcement, allowing data to be processed outside the controller’s expectations or without reliable proof of control.

Impact: That can lead to regulatory findings, contractual breach, loss of customer trust, and higher blast radius if a security incident or governance failure affects personal data processing.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	GV.SC — Cybersecurity Supply Chain Risk Management	Article 28.5 governs processor and subprocessor assurance.
	PR.AA — Identity Management, Authentication, and Access Control	Processor safeguards depend on controlled access to personal data and systems.
	PR.DS — Data Security	Article 28.5 expects security safeguards for personal data processing.
Recommendation — Use GV.SC to govern processor assurance, subcontractor oversight, and evidence of controlled processing. Apply PR.AA to restrict processor access to documented processing needs and approved roles. Use PR.DS to protect data in storage, transit, and processing with enforceable safeguards.
CIS Controls v8	6 — Access Control Management	Processor obligations require controlled access and reviewable privileges.
	8 — Audit Log Management	Auditability is central to demonstrating compliant processor handling.
Recommendation — Implement Control 6 to limit processor access to approved processing functions and data. Use Control 8 to retain logs that evidence processing, access, and administrative actions.

Practitioner Guidance

Governance implication: Treat Article 28.5 as an evidence-backed operating requirement, not just a contract clause. The processor should be able to show, at any time, how its controls support the controller’s instructions and how exceptions are surfaced and corrected.

What to watch for: The most common warning signs are inconsistent subprocessor oversight, missing audit trails, unclear retention or deletion handling, and security controls that exist in policy but are not demonstrable in practice.

Article 28.5 GDPR