Data Processor Due Diligence: GDPR Article 28 Meets NIS2 Supply Chain

Almost every organisation depends on other organisations to handle data. The cloud platform, the SaaS tools, the payroll provider, the analytics service, the managed IT firm — each one processes data on the organisation's behalf, and each one is regulated, from a different angle, by a different EU regime.

GDPR Article 28 governs them as data processors. NIS2 Article 21(2)(d) governs them as suppliers and service providers. DORA Articles 28 to 30 govern them as ICT third-party providers. Three regimes, three vocabularies, substantially one set of vendor relationships. This article shows how to run a single supplier due-diligence programme that satisfies all three rather than three overlapping ones.

For the broader picture of how the regimes intersect, start with GDPR, NIS2 and DORA: How the Three EU Regimes Intersect.

This is not legal advice. National NIS2 transpositions and DORA technical standards continue to refine the supplier obligations.

The three regimes on suppliers, side by side

GDPR Article 28 — the data processor

GDPR draws a sharp line between the controller (who determines the purposes and means of processing) and the processor (who processes personal data on the controller's behalf). Any third party processing personal data for you is a processor, and Article 28 governs the relationship.

Article 28 requires three things in particular:

• Use only processors providing sufficient guarantees to implement appropriate technical and organisational measures (Article 28(1)) — this is the due diligence obligation
• A written contract — the Data Processing Agreement — with the specific content prescribed in Article 28(3): subject matter, duration, nature and purpose, type of personal data, categories of data subjects, and the processor's obligations
• Controller authorisation for sub-processors (Article 28(2) and (4)) — the processor cannot engage another processor without the controller's authorisation, and must flow the same data protection obligations down the chain

The controller remains accountable for the processor's compliance. Choosing a processor badly is the controller's failure.

NIS2 Article 21(2)(d) — the supplier

NIS2's supply chain measure requires essential and important entities to address security in the relationships with their direct suppliers and service providers. It is broader than GDPR Article 28 in one respect and narrower in another. Broader: it covers any supplier whose product or service touches the entity's network and information systems, not only those processing personal data. Narrower: it has no prescribed contract template and no mandatory register — it is principle-based. The detail is in NIS2 Supply Chain Security: What Article 21(2)(d) Requires.

DORA Articles 28 to 30 — the ICT third-party provider

DORA's third-party regime is the most prescriptive of the three. It requires pre-contractual risk assessment, a mandatory Register of Information, specific contractual provisions (with an even higher bar for ICT services supporting critical or important functions), concentration risk assessment, and tested exit strategies. The detail is in DORA Third-Party Oversight and DORA Register of Information.

The overlap — one vendor, three regulatory identities

Consider a single cloud provider hosting an HR system containing employee personal data for a financial entity. That one vendor is:

• A GDPR processor — it processes personal data on the entity's behalf
• A NIS2 supplier — its service touches the entity's network and information systems (if the entity is in NIS2 scope)
• A DORA ICT third-party provider — it provides an ICT service to a financial entity

Three regulatory identities, one contract, one due-diligence relationship. Running three separate due-diligence processes for this one vendor is wasteful and produces three inconsistent records. The efficient approach is a single programme.

One programme, three regimes' requirements satisfied. Photo: Adeolu Eletu / Unsplash.

Building one supplier due-diligence programme

A unified programme has five components — the same backbone as the NIS2 supply chain programme, extended to carry the GDPR and DORA requirements.

1. One supplier register, three classifications

A single inventory of every third party. But each entry carries three tags:

• Personal data tag — does this vendor process personal data? If yes, GDPR Article 28 applies and a Data Processing Agreement is required.
• NIS2 supplier tag — does this vendor's service touch your network and information systems? If yes, and you are in NIS2 scope, Article 21(2)(d) applies.
• DORA ICT tag — is this vendor an ICT third-party provider, and you a financial entity? If yes, DORA Articles 28 to 30 apply. And if it supports a critical or important function, the heavier Article 30(3) obligations apply.

One register, three overlapping classifications. A given vendor may carry one tag, two, or all three.

2. Criticality and sensitivity tiering

You cannot apply equal scrutiny to every vendor. Tier them on two axes at once:

• Operational criticality — how badly would this vendor's failure disrupt your operations? (The NIS2 and DORA axis.)
• Data sensitivity — how sensitive is the personal data this vendor handles? (The GDPR axis.)

A vendor high on either axis warrants full due diligence. The two-axis tiering ensures a vendor that is operationally minor but handles special-category personal data is not under-scrutinised — and vice versa.

3. One due-diligence questionnaire, three regimes' worth of questions

A single security-and-data due-diligence questionnaire that covers all three regimes' concerns:

• GDPR questions — what personal data is processed, where, what sub-processors are used, what is the legal basis for any onward transfer, can the processor support data subject rights, what is the data return/deletion process
• NIS2 / security questions — security certifications, incident notification commitments, encryption, access control, business continuity, penetration testing
• DORA questions (for financial entities) — substitutability, the provider's own resilience testing, subcontracting chains, audit rights

Where a vendor holds a current ISO 27001 certificate or a recent SOC 2 Type II report, that evidence answers a large part of the security questionnaire. The GDPR-specific questions — sub-processors, transfer mechanisms, data subject rights support — generally still need explicit answers, because security certifications do not cover them.

4. Contracts to the strictest applicable regime

This is the key efficiency. A vendor carrying multiple regulatory tags needs a contract that satisfies the strictest applicable regime — with the regime-specific clauses layered in:

• The GDPR layer — the Article 28(3) Data Processing Agreement terms. Required whenever the vendor processes personal data, regardless of the other regimes.
• The DORA layer — the Article 30 prescribed provisions, with Article 30(3) additions for critical-or-important functions. Required for ICT third parties of financial entities.
• The NIS2 layer — security clauses for direct suppliers. Less prescriptive; generally satisfied if the DORA or GDPR security terms are present.

For a financial entity, a contract built to DORA Article 30 with the GDPR Article 28 processor terms included will generally satisfy all three regimes. The ordering principle: start from the most prescriptive regime that applies, then add the others' specific requirements. The reverse — starting from a GDPR DPA and hoping it covers DORA — does not work, because DORA's prescribed provisions go well beyond a standard DPA.

5. One review cycle

A single periodic review per vendor, covering all applicable regimes at once. Tier 1 vendors annually; lower tiers on contract renewal; any vendor on a trigger event — a breach, an ownership change, a material service change. The review re-checks certifications, incident history, sub-processor changes, and — for GDPR — any change in data location or transfer arrangements. The review log is audit evidence for all three regimes simultaneously.

Each node is another diligence target. Photo: Alina Grubnyak / Unsplash.

Sub-processors — the chain problem, three times

Each regime cares about the chain beyond your direct vendor, and the three concerns reinforce each other.

GDPR Article 28 requires the processor to obtain controller authorisation before engaging a sub-processor, and to flow the same data protection obligations down. NIS2's supply chain measure directs attention to the security quality of the broader chain. DORA requires, for critical-or-important functions, information on the provider's subcontractors in the Register of Information.

The unified approach: require sub-processor disclosure in every contract where personal data is processed or an ICT service supports an important function, and require advance notice of sub-processor changes with a right to object. One contractual mechanism serves all three regimes' chain concerns.

The honest difficulty is that sub-processor transparency depends on the vendor's cooperation, and the contract is the only lever. A vendor unwilling to disclose its sub-processors is a vendor you cannot fully assess under any of the three regimes — which is itself a finding to record.

The international dimension

Where a processor processes personal data outside the EEA, GDPR Chapter V's international transfer rules apply on top of Article 28 — Standard Contractual Clauses, a transfer impact assessment, and so on. The detail is in GDPR International Data Transfers. For the unified supplier programme, the practical point is that the data location question belongs in the due-diligence questionnaire — and a vendor that processes entirely within the EU removes a whole category of compliance work, which is part of the EU-first commercial case.

Common pitfalls

1. Running three separate supplier programmes. GDPR processor management, NIS2 supplier management, and DORA third-party management as three silos — three registers, three questionnaires, three review cycles, inevitably inconsistent.
2. A GDPR DPA mistaken for a DORA-compliant contract. A standard Data Processing Agreement does not contain DORA's Article 30 prescribed provisions. For financial entities, the DPA is necessary but not sufficient.
3. Tiering on one axis only. Tiering purely on operational criticality misses the vendor that is operationally small but handles sensitive personal data. Tier on both axes.
4. Forgetting the sub-processor chain. All three regimes care about the chain. A direct-vendor-only assessment is incomplete under each.
5. Treating certifications as a complete answer. ISO 27001 and SOC 2 answer most security questions but not the GDPR-specific ones — sub-processors, transfer mechanisms, data subject rights support.
6. No review cycle. Onboarding due diligence is a snapshot. All three regimes expect ongoing review.

Frequently asked questions

Is every supplier a data processor under GDPR? No. Only suppliers that process personal data on your behalf are processors. A supplier that touches your systems but processes no personal data is a NIS2 supplier but not a GDPR processor.

Can one contract cover GDPR, NIS2 and DORA? Yes, if built to the strictest applicable regime. For a financial entity, a DORA Article 30-compliant contract with GDPR Article 28 processor terms included generally satisfies all three.

Does a GDPR Data Processing Agreement satisfy DORA? No. A standard DPA lacks DORA's prescribed Article 30 provisions — service level detail, audit rights, exit strategies, subcontracting terms. The DPA is necessary for personal data processing but not sufficient for DORA.

Do I need to assess my processor's sub-processors? Effectively yes, under all three regimes. GDPR requires authorisation and obligation flow-down; NIS2 directs attention to chain quality; DORA requires subcontractor information for critical functions.

Is a security certification enough for processor due diligence? It covers much of the security assessment but not the GDPR-specific questions. Request the certificate or audit report, then ask the GDPR-specific questions separately.

How often should I review suppliers? Tier 1 annually; lower tiers on renewal; any vendor on a trigger event. One review cycle serving all applicable regimes.

The bottom line

Three takeaways:

1. One vendor, up to three regulatory identities. A processor under GDPR, a supplier under NIS2, an ICT third party under DORA — assess them once, not three times.
2. Contract to the strictest applicable regime, layer in the rest. For financial entities, that means DORA Article 30 as the base, with GDPR Article 28 processor terms included.
3. Tier on two axes — criticality and data sensitivity. A single axis misses the operationally minor vendor handling sensitive personal data.

For the regime-by-regime detail, see NIS2 Supply Chain Security, DORA Third-Party Oversight, and the broader GDPR, NIS2 and DORA intersection guide.

---

Sources & further reading

• Regulation (EU) 2016/679 — GDPR — Article 28 (processor), Article 4(8) (definition of processor), Chapter V (international transfers)
• Directive (EU) 2022/2555 — NIS2 — Article 21(2)(d) (supply chain security)
• Regulation (EU) 2022/2554 — DORA — Articles 28 to 30 (ICT third-party risk management)
• European Data Protection Board (EDPB) — Guidelines on the concepts of controller and processor
• Commission Implementing Regulation (EU) 2024/2956 — DORA Register of Information