TPRM Under GDPR: Article 28 and Sub-Processors

GDPR makes vendor risk a legal duty, not just good practice

For most frameworks, third-party risk management is strongly recommended. Under the GDPR it is a legal obligation. The moment you hand personal data to a vendor, the regulation makes you — the controller — responsible for the vendor you chose and for proving you chose well. Vendor diligence stops being a best practice and becomes something a regulator can ask you to evidence.

Two provisions drive this. Article 5(2), the accountability principle, says you must not only comply but be able to demonstrate it. Article 28 spells out exactly what that looks like when a third party processes personal data on your behalf. Together they turn your TPRM program into the paper trail that shows you met the standard.

(This is an explainer, not legal advice — confirm specifics with your own counsel and your supervisory authority's guidance.)

Controller, processor, sub-processor — the chain

GDPR assigns roles, and the duties follow the role. The controller decides why and how personal data is processed — that's you. A processor processes that data on the controller's behalf — that's your vendor. A sub-processor is a processor engaged by your processor — the vendors behind your vendor.

The obligations flow down the chain, but the accountability flows back up it. You remain answerable for the personal data even after it has passed to a processor and on to a sub-processor you may never have heard of. That is precisely why the sub-processor layer — the fourth party — matters so much under GDPR specifically.

What Article 28 requires in the contract (the DPA)

Article 28(3) requires a binding written contract — the Data Processing Agreement — between controller and processor, and it enumerates the terms it must contain. A processor relationship without a compliant DPA is itself a finding. The mandatory commitments:

• Process personal data only on the controller's documented instructions.
• Ensure persons authorised to process the data are bound by confidentiality.
• Implement appropriate technical and organisational security measures (per Article 32).
• Respect the conditions for engaging sub-processors (see below).
• Assist the controller in responding to data-subject rights requests.
• Assist the controller with security, breach notification, and DPIAs.
• Delete or return all personal data at the end of the engagement.
• Make available the information needed to demonstrate compliance, and allow and contribute to audits.

The sub-processor duty

Article 28 is unusually specific about the vendors behind your vendor. A processor may not engage a sub-processor without the controller's prior authorisation — either specific, or general with notice of intended changes so the controller can object. When a sub-processor is engaged, the same data-protection obligations must be flowed down to it by contract, and the original processor remains fully liable to you for the sub-processor's performance.

The practical consequence: you need your processors' sub-processor lists, and you need to be told when they change. A vendor that won't disclose its sub-processors, or that swaps one in without notice, is not meeting the Article 28 standard — and you can't assess a fourth party you can't see.

"Sufficient guarantees" — where TPRM meets GDPR

Article 28(1) says a controller may use only processors that provide "sufficient guarantees" to implement appropriate technical and organisational measures. That phrase is the bridge between GDPR and your vendor risk program: assessing whether a processor's safeguards are adequate is exactly what a vendor security review does.

So your TPRM artifacts do double duty. The diligence you run, the security attestations you collect, the questionnaire responses, the risk scores — under GDPR these are the evidence that you assessed the processor's guarantees before trusting it with personal data. Run the assessment well and you have satisfied Article 28(1) and produced the Article 5(2) accountability record at the same time.

When the data crosses a border

If personal data leaves the EEA — including when a processor's sub-processor sits outside it — Chapter V (Articles 44 and following) requires a valid transfer mechanism: an adequacy decision for the destination country, or appropriate safeguards such as the Standard Contractual Clauses, usually backed by a transfer impact assessment.

This is where data-residency and concentration risk become a compliance question, not just an operational one. Mapping where each processor — and each sub-processor — actually stores and processes the data, and which transfer mechanism covers it, is part of the same vendor record you are already maintaining.

What this means for your TPRM program

Translating Article 28 into program mechanics:

• Maintain a current DPA for every processor that touches personal data, with the Article 28(3) terms in place.
• Collect each processor's sub-processor list and get notified when it changes — then assess the new sub-processor.
• Record the transfer mechanism (adequacy / SCCs) wherever data leaves the EEA, including through sub-processors.
• Keep your "sufficient guarantees" assessment as evidence — the diligence is the proof you met the standard.
• Re-check on triggers — a new sub-processor, a changed data flow, an expired attestation — not just once at onboarding.

Common mistakes

GDPR vendor obligations tend to fail in familiar ways:

• No DPA, or a generic one that omits the Article 28(3) terms — relying on the vendor's standard terms of service instead.
• Never collecting the sub-processor list, leaving the fourth-party layer — and its transfers — entirely unassessed.
• Ignoring international transfers until a regulator or a data-subject complaint forces the question.
• Treating GDPR as a one-time legal checkbox at signing rather than an ongoing diligence duty that the accountability principle expects you to evidence continuously.
• Being unable to demonstrate the diligence — having done the work but kept no record a regulator would accept.

Where this fits — demonstrating accountability

Article 5(2) is the part programs underestimate: it is not enough to have assessed your processors; you must be able to show it on demand. That makes the vendor record itself the deliverable — DPAs, sub-processor relationships, transfer mechanisms, and the diligence behind each "sufficient guarantees" decision, all retrievable when an auditor or supervisory authority asks.

v3ndor's interface lets you map sub-processor relationships as linked vendors and record each processor's DPA and evidence documents linked to the vendor record — so the Article 28 paper trail is one place instead of scattered across inboxes and shared drives. Request access at /request-access to see it on your own vendors.