Third-Party Risk Management Software: DORA Article 28, Tiering

Third-party risk stopped being a procurement checkbox the moment regulators made you accountable for your suppliers' security. NIS2 puts supply-chain security in Article 21; DORA devotes Article 28 to it. Both ask the same practical thing: a current register, tiered by criticality, that you can show.

The supplier blind spot

Most suppliers are assessed once, at onboarding, then become invisible for the life of the contract while the dependency on them deepens. A spreadsheet cannot chase an overdue reassessment, and it cannot tell you which critical vendor has not been reviewed in two years. That silence is the gap supply-chain attacks exploit, and it is exactly what both NIS2 and DORA now make you close.

What DORA Article 28 requires

For financial entities, DORA (Regulation (EU) 2022/2554), applicable since 17 January 2025, is explicit about the supplier side.

A register of information on all contractual arrangements with ICT third-party providers, kept current and producible to the competent authority on request.
Concentration-risk analysis: which single provider, or provider that is hard to substitute, sits under too many of your services.
Exit strategies and minimum contractual clauses for providers supporting critical or important functions.
Awareness that the European Supervisory Authorities can designate the largest providers as critical ICT third-party providers and supervise them directly.

Tiering: proportionate effort

You cannot assess every supplier to the same depth, and you should not. The point of tiering is to spend your effort where the risk is. The tier drives the questionnaire, the review cadence and the monitoring.

VENDOR TIER → EFFORT
TIER	QUESTIONNAIRE	REVIEW	MONITORING
Low	Short, self-declared	Every 18 to 24 months	Passive
Moderate	Standard, evidence-backed	Annual	Periodic
Critical	In-depth, DPO and security sign-off	Every 6 to 12 months	Continuous

From obligation to evidence

Both regimes judge you on what you can produce. Here is the mapping we use on engagements.

REQUIREMENT → EVIDENCE → SYNAPSERM
REQUIREMENT	WHAT YOU MUST PRODUCE	IN SYNAPSERM
DORA Art. 28, register	Every ICT provider, its function, criticality and contract, current and exportable	The register of information, tiered and exportable
NIS2 Art. 21(2)(d)	The suppliers behind your service, what you assessed and when	Third-party register and questionnaire workflow
Concentration	Which provider sits under too many services	Criticality and dependency view
Exit and continuity	A plan for the providers you cannot lose overnight	Exit and contingency fields on the tier

Questions we get asked

What is the DORA register of information?

It is a structured inventory, mandated by Article 28, of every contractual arrangement with an ICT third-party provider: who they are, what function they support, whether that function is critical or important, the contract terms, and the subcontracting chain. It must be kept current and produced to the competent authority on request, and the ESAs collect it in a harmonised format.

Does NIS2 also require third-party oversight?

Yes. Article 21(2)(d) requires supply-chain security, including the security aspects of the relationship with each direct supplier. It is less prescriptive than DORA about the register format, but the practical need is the same: know your suppliers, their criticality, and what you have assessed.

How is this different from sending a vendor questionnaire?

A questionnaire is a moment; third-party risk management is a lifecycle. The questionnaire is one input. What regulators want is the maintained record around it: the tier, the review date, the evidence, the concentration view and the exit plan, kept true over the life of the contract.

How often should we reassess a supplier?

Proportionately to the tier. A low-risk vendor every 18 to 24 months is defensible; a critical vendor supporting an important function should be on a 6 to 12 month cycle with continuous monitoring. The key is that the cadence is defined and the overdue ones surface by themselves.

Do we need an exit plan for every vendor?

No, only for providers supporting critical or important functions, which is DORA's language. But you cannot decide which those are without the tiering, which is why the register and the tier come first.