Third party risk management policy: what DORA requires

A third party risk management policy sets the rules for classifying, assessing, and monitoring the vendors and ICT providers a financial entity depends on. Under DORA, Article 28 turns that from a best-practice option into a specific, checkable requirement: how vendors get tiered, what due diligence happens before signing, and what triggers a review.

The policy is the rulebook. Applying it, tracking assessments, chasing evidence, and keeping the register current is the separate, ongoing work of a programme, typically run through automated risk management rather than a shared drive.

This piece covers what DORA actually requires the policy to say, how to classify vendors without a dedicated team, the contract terms that are not optional, and where a policy alone stops being enough.

What a third party risk management policy must cover under DORA

DORA does not leave the contents of a third party risk management policy to interpretation. Article 28 sets out what a financial entity’s ICT third-party risk strategy has to include, and the policy sits inside that strategy as the operational layer, the document that says how classification, assessment, and monitoring actually happen, not just that they should.

Two things separate this from a generic vendor-risk policy borrowed from a US framework. The register of information follows a fixed structure, standard templates set by the technical standards, because a competent authority can request the complete record on demand. And the classification test looks past data sensitivity alone: whether a vendor supports a critical or important function turns on business impact and substitutability too, the same logic a business impact analysis applies to internal processes.

None of this is optional once a financial entity falls inside DORA’s scope, regardless of size.

Classifying vendors when you do not have a dedicated team

Most vendor-risk frameworks default to three to five tiers, built for organisations with a risk committee, procurement, and a dedicated security team to run each one. A financial entity running the policy with one or two people, managing a portfolio of 30 to 80 vendors, needs a system that produces a defensible answer without a meeting.

Two tiers usually cover it: vendors supporting, or plausibly affecting, a critical or important function, and everything else. A third tier earns its place only if that second group is wide enough to hide a genuinely exposed vendor: no-access vendors in one group, moderate ones warranting a lighter check in another.

Classification should run on access and impact, not on how a vendor describes itself. A marketing tool that only sends email looks low-risk until it turns out to hold the customer list a critical function depends on: what breaks, and what data moves, if the vendor fails, is what the tier should reflect.

Approval does not need an org chart to function. When one person holds both the compliance-owner and CISO-support roles, what matters is documentation, tier, reasoning, and who made the call, recorded in the risk register tool rather than left in an inbox. A one-person team that documents its reasoning holds up better under review than a committee that cannot produce a record of what it decided.

The contract terms DORA requires you to actually get in writing

DORA’s Article 30 does not leave contractual protection to negotiation goodwill. It sets out clauses that need to appear in the contract itself, not just get raised during due diligence. For arrangements supporting a critical or important function, the list runs longer still.

At minimum, the contract should specify:

• Audit and access rights. The right to inspect, audit, and access the provider’s systems and records, not a courtesy the provider extends at its discretion.
• Data location. Where data is processed and stored, including any transfer outside the EU.
• Service levels. Quantitative performance targets, not a vague commitment to best efforts.
• Sub-outsourcing notification. Advance notice, and in some cases approval rights, before the provider hands part of the work to a fourth party.
• Cooperation with authorities. A requirement for the provider to assist during an ICT incident and cooperate with a competent authority’s request.
• Termination and exit rights. The right to exit, with a transition period long enough to move the function elsewhere without disrupting the business.

Due diligence run through third-party risk management software surfaces whether a vendor will actually agree to these terms before signature, not after a problem makes the gap visible. A vendor that hedges on audit rights during due diligence rarely turns cooperative once the contract is signed.

Where third-party risk actually slips through

Most third-party risk does not show up in the policy document. It shows up in how the policy gets applied, three ways in particular.

• Treating questionnaire answers as proof, not a starting point. A vendor confirming it encrypts data at rest is a claim, not evidence. Ask for the configuration or certificate that backs it up before the assessment counts as complete.
• Under-classifying a vendor because its stated function looks low-risk. A tool procured for marketing email can end up holding the customer list a critical function depends on. Classification should track what a vendor can reach, not what it was bought to do.
• Writing the policy once and never revisiting it against a real trigger. A new regulation, an incident at a peer institution, or a new vendor category entering the portfolio should each prompt a review, not wait for the next scheduled one.

Consider a payments platform onboarding a customer-support chatbot vendor, classified as low-risk: a support tool, not a payment processor. 18 months later, an integration gives the chatbot read access to transaction history so support staff can answer billing questions without switching screens. Nobody reruns the classification. The vendor’s access footprint changed; its tier in the register did not.

That gap, between what a vendor was approved to touch and what it can touch now, is where most third-party incidents actually originate. A policy that only classifies vendors at onboarding is testing the wrong moment.

Where the policy alone stops

A third party risk management policy, a register entry, and a signed contract describe a point in time: the vendor as it was assessed, tiered, and contracted. None of that updates itself.

A policy does not notice when a vendor’s access scope grows past what was approved. It does not connect a contract’s audit-rights clause to whether that audit ever actually happened. It does not rerun a classification when a vendor adds a fourth-party subcontractor 18 months into the relationship. Those are the gaps a static document, however well written, cannot close on its own.

This is not a case for quarterly spreadsheet reviews either, which mostly confirm what a compliance owner already suspected while missing whatever changed in between.

A certification set to expire, a contract renewal approaching without a re-assessment scheduled, a vendor tier untouched since onboarding: these are the signals a policy on its own has no mechanism to surface.

Some teams close that gap with in-house CISO team input, keeping interpretation of what counts as concerning consistent as circumstances change, rather than re-litigating judgment calls each time a different reviewer picks up the file. The policy sets the rules once, at signature. Keeping pace with a vendor whose practices drift away from what the contract assumed is the separate, ongoing work the policy cannot do by itself.

Getting this right against DORA’s specific requirements, not a generic template, is worth doing properly from the start. Book a consultation to work through where the current policy and register stand.