Skip to main content
Oversight Institute
Category: Regulatory Frameworks

Article 28 Requirements

Also known as: GDPR Article 28, Article 28 GDPR, Processor obligations under GDPR
Simply put

Article 28 Requirements refer to the obligations set out in Article 28 of the EU General Data Protection Regulation (GDPR) that govern the relationship between a data controller and a data processor. They require, among other things, a written contract that sets rules for how the processor handles personal data, when and how it may use sub-processors, and how it supports the controller's compliance duties. In practice, these requirements shape the terms organizations put in place when engaging third parties that process personal data on their behalf.

Formal definition

Article 28 of the GDPR sets out the conditions under which a processor may process personal data on behalf of a controller, most notably the requirement for a binding written agreement (commonly a data processing agreement, or DPA) governing the processing. Per the evidence, its scope includes documented processing instructions, confidentiality obligations, security measures, support for the controller's compliance obligations, and controls on engaging sub-processors: a processor shall not engage another processor without prior specific or general written authorisation of the controller, and in the case of general written authorisation must inform the controller of intended changes. These requirements are specific to the controller-processor relationship for personal data under GDPR and do not, on their own, address financial, operational, geopolitical, or broader ESG risk, nor do they extend GDPR obligations beyond parties within its material and territorial scope. The presence of an Article 28-compliant contract or a processor's attestation to these obligations is a contractual and documentation control; it does not by itself constitute independent verification of the processor's actual practices, and obligations may be interpreted and enforced differently across EU member-state supervisory authorities. Note that 'Article 28' also appears in unrelated legal contexts (for example, Article 28 of New York Public Health Law governing hospitals and clinics), which is distinct from the GDPR provision and should not be conflated with it.

Why it matters

Most organizations do not process personal data entirely in-house; they rely on third parties such as cloud hosting providers, payroll services, marketing platforms, and analytics vendors that handle personal data on their behalf. Article 28 of the GDPR is the provision that governs these controller-processor relationships, requiring a binding written contract (commonly a data processing agreement, or DPA) before a processor handles personal data. For third-party risk and procurement teams, this makes Article 28 a foundational checkpoint in onboarding any vendor that touches personal data within the GDPR's scope: without a compliant agreement in place, the controller may be unable to demonstrate that its processing arrangements meet regulatory expectations.

Article 28's requirements also extend visibility one layer deeper into the supply chain. Because a processor cannot engage a sub-processor without the controller's prior specific or general written authorisation, and because under general authorisation the processor must inform the controller of intended changes, the provision gives controllers a contractual mechanism to track and object to changes among fourth parties. This is significant given that limited visibility beyond the first tier is a persistent challenge in supply chain risk management, though the mechanism is only as effective as the controller's ability to actually monitor and act on the notifications it receives.

It is important not to overstate what an Article 28-compliant contract achieves. The presence of a DPA or a processor's attestation to Article 28 obligations is a contractual and documentation control; it does not by itself independently verify that the processor's actual security and handling practices match its commitments. It also addresses only personal data under GDPR and does not, on its own, cover financial, operational, geopolitical, or broader ESG risk associated with the same third party. Organizations that treat a signed DPA as evidence of verified compliance rather than as a starting point for ongoing oversight may carry more residual risk than they assume.

Who it's relevant to

Data protection and privacy compliance teams
These teams own the design and review of data processing agreements and are typically responsible for ensuring that contracts with processors reflect the obligations set out in Article 28, including processing instructions, confidentiality, security, and sub-processor controls. They also interpret how the requirements apply given variation in enforcement across member-state supervisory authorities.
Procurement and vendor onboarding functions
Procurement teams often act as the gatekeeper for engaging third parties that process personal data, making an Article 28-compliant DPA a common precondition for onboarding. They should treat the signed agreement as a starting point rather than as independent verification of the processor's actual practices.
Third-party and supply chain risk managers
Risk managers rely on Article 28's sub-processor authorisation and notification mechanisms to gain some visibility into fourth-party relationships that would otherwise be difficult to see. They should note that the contractual right to be informed of sub-processor changes is only useful if the organization has the capacity to monitor and act on those notifications, and that Article 28 addresses only personal data risk, not the broader financial, operational, or geopolitical risk a vendor may present.
Legal and contracting teams
Legal teams draft and negotiate the binding written agreements Article 28 requires and must distinguish the GDPR provision from unrelated legal contexts that share the 'Article 28' label, such as New York Public Health Law. They also help frame authorisation terms for sub-processors as specific or general, each of which carries different downstream notification obligations.

Inside Article 28 Requirements

Data Processor Obligations
Article 28 governs the relationship between a controller and a processor under the EU General Data Protection Regulation, setting out the terms that must bind a processor engaged to process personal data on the controller's behalf. It applies specifically to personal data processing arrangements and does not, in itself, address broader third-party risks such as financial stability, operational resilience, or non-privacy security exposures.
Written Contract or Legal Act
The provision requires that processing by a processor be governed by a contract or other legal act that is binding on the processor and that sets out the subject matter, duration, nature, and purpose of the processing, the type of personal data, categories of data subjects, and the obligations and rights of the controller. It is a contractual mandate rather than a certification, and a signed clause does not by itself demonstrate that the processor's practices are effective.
Prescribed Processor Duties
Article 28 enumerates specific duties a processor typically must accept, including processing only on documented instructions, ensuring persons authorized to process are bound by confidentiality, implementing appropriate technical and organizational measures, assisting the controller with data subject requests and security obligations, and deleting or returning data at the end of the engagement. These are commitments made in the agreement and are distinct from independent verification that they are met.
Sub-processor (Nth-Party) Controls
The provision addresses the engagement of sub-processors, generally requiring prior authorization from the controller and flow-down of equivalent data protection obligations. This introduces a fourth-party or Nth-party dimension, but the controller's direct visibility typically remains strongest at the immediate processor tier and weaker across onward sub-processing chains.
Audit and Inspection Rights
Article 28 requires the processor to make available information necessary to demonstrate compliance and to allow for and contribute to audits, including inspections, conducted by the controller or a mandated auditor. Adherence to an approved code of conduct or certification mechanism may be used as an element to help demonstrate sufficient guarantees, but such mechanisms do not replace the underlying contractual obligations or guarantee compliance.

Common questions

Answers to the questions practitioners most commonly ask about Article 28 Requirements.

Does signing an Article 28 processor agreement mean my organization has verified the processor's actual security practices?
No. An Article 28 contract is a legal instrument that binds a processor to specified obligations; it is a form of contractual commitment or attestation, not independent verification. The presence of the required clauses does not confirm that the processor has implemented the agreed measures in practice. Verification typically requires separate mechanisms such as audits, inspections, or independent assurance reports, and Article 28 itself contemplates that controllers may exercise audit and inspection rights. Treating the executed contract as evidence of operational compliance conflates a documented obligation with demonstrated performance.
Do Article 28 requirements cover every third party my organization works with?
No. Article 28 applies specifically to the controller-processor relationship where a party processes personal data on behalf of, and under the instructions of, a controller. It does not govern relationships with parties acting as independent controllers, nor does it address third-party risks unrelated to personal data processing, such as financial, operational, geopolitical, or broader supply chain exposures. Determining whether a given supplier, vendor, or service provider falls within Article 28's scope depends on the actual role that party plays with respect to the personal data, which is a factual assessment rather than a labeling exercise.
What core provisions does an Article 28 agreement typically need to include?
Article 28 sets out a set of mandatory contractual terms governing processing carried out on behalf of a controller. These generally include the subject matter, duration, nature, and purpose of the processing, the types of personal data and categories of data subjects, processing only on documented instructions, confidentiality commitments, security measures, conditions for engaging sub-processors, assistance to the controller with data subject rights and obligations, arrangements at the end of processing, and provisions supporting audits and inspections. Programs typically map these elements to a checklist to confirm each required term is present in every in-scope contract.
How should Article 28 obligations be handled when a processor engages sub-processors?
Article 28 addresses the engagement of sub-processors and generally requires the processor to obtain authorization from the controller before engaging another processor, and to flow down data protection obligations comparable to those in the controller-processor agreement. In practice this creates a chain of contractual commitments across fourth-party and Nth-party relationships. Controllers often address this through prior specific or general authorization arrangements, notification of intended changes, and mechanisms to object. Note that flow-down clauses bind the parties contractually but do not by themselves give the controller direct visibility into how sub-processors operate beyond the first tier.
How do Article 28 audit rights typically work in ongoing vendor monitoring?
Article 28 contemplates that processors make available information needed to demonstrate compliance and allow for and contribute to audits, including inspections, conducted by the controller or an appointed auditor. In many programs these rights are operationalized through a combination of direct audits, questionnaires, and reliance on independent assurance reports where available. It is worth distinguishing a point-in-time report from continuous monitoring: an assessment or audit reflects conditions at a specific time and can become stale, so many programs supplement contractual audit rights with periodic reassessment tied to the vendor's risk tier.
How does Article 28 relate to cross-border transfer requirements when a processor is located outside the region?
Article 28 governs the processing relationship itself, but it does not on its own satisfy requirements that apply to transfers of personal data across jurisdictional boundaries. Where a processor or sub-processor is located in another region, additional transfer mechanisms may be required alongside the Article 28 terms. Because regulatory expectations for such transfers differ across regions and can change, organizations typically treat processing obligations and transfer safeguards as related but separate workstreams rather than assuming one instrument addresses both.

Common misconceptions

Signing an Article 28 data processing agreement means the processor is compliant and the data is secure.
The agreement is a contractual attestation of obligations, not independent verification that controls operate effectively. Article 28 requires audit and inspection rights precisely because a signed clause does not confirm implementation. Ongoing monitoring is typically needed, since a point-in-time contract execution can become stale as the processor's practices, subcontractors, and environment change.
Article 28 covers a supplier's full third-party risk profile.
Article 28 addresses only the processing of personal data under the GDPR. It does not cover financial, operational, geopolitical, or ESG risk, nor does it address information security matters unrelated to personal data. Programs generally supplement it with separate assessments to cover those out-of-scope areas.
Authorizing a processor automatically extends control over all downstream sub-processors.
While Article 28 requires flow-down of equivalent obligations to sub-processors, this addresses direct third-party and Nth-party arrangements contractually but does not deliver full transparency across every tier. In practice, visibility and enforcement typically weaken beyond the immediate processor, so onward sub-processing warrants specific attention.

Best practices

Treat the Article 28 agreement as a baseline for personal data processing, and pair it with separate due diligence covering financial, operational, geopolitical, and non-privacy security risks that fall outside its scope.
Exercise the audit and inspection rights the provision grants rather than relying solely on the processor's written commitments or self-attestations; where certifications or codes of conduct are offered, treat them as supporting evidence rather than proof of compliance.
Map and document sub-processors, require prior authorization and equivalent flow-down obligations, and apply heightened scrutiny where visibility into onward (Nth-party) processing is limited.
Confirm that documented processing instructions, data categories, retention, and end-of-engagement deletion or return terms are specific and current, and refresh them as the relationship or processing purpose changes.
Replace reliance on point-in-time contract execution with ongoing monitoring, scaling frequency and depth to the risk tier and the sensitivity of the personal data involved.
Account for jurisdictional and sectoral variation, recognizing that Article 28 reflects EU GDPR expectations and that equivalent obligations may differ or require additional terms in other regions or regulated sectors.
Promotional banner graphic asking if you are ready for PCI DSS 4.0 with a call-to-action to get the guide