Most financial entities still manage vendor risk the way they managed it in 2019. Once a year, procurement sends a questionnaire to each critical vendor. The vendor returns it, often weeks late. Someone in risk or compliance reviews the responses, assigns a risk rating, files the assessment, and moves on. The vendor is "assessed" until next year.
This model was already questionable before DORA. The pace of change in ICT service provider environments — cloud migrations, acquisitions, sub-contractor changes, security incidents — makes annual snapshots unreliable within weeks of completion. But it was the industry standard, and supervisors generally accepted it.
DORA Chapter V changed the equation. The Regulation does not merely require that financial entities assess their ICT third-party service providers. It requires ongoing management of ICT third-party risk as a continuous operational discipline. The register of information must be maintained and kept up to date. Contractual provisions must address incident notification, audit rights, and exit strategies. Concentration risk must be assessed at entity level and, through the ESA oversight framework, at sector level. Sub-contracting chains must be understood and monitored.
An annual questionnaire does not satisfy these obligations. Understanding why — and what replaces it — is the central challenge for ICT third-party risk management in 2025.
The Old Model: Annual Questionnaire, Annual Risk Rating, Annual Review
The traditional TPRM operating model follows a predictable cycle:
Onboarding. A new vendor is identified. Procurement initiates a due diligence process. The vendor completes a security questionnaire — typically a standardised template like the SIG or CAIQ, or an institution-specific questionnaire. The risk team reviews the responses, possibly requests clarifications, and assigns an initial risk rating. The vendor is approved, the contract is signed, and the assessment is filed.
Annual review. Twelve months later, the questionnaire is reissued. The vendor — often a different person than the one who completed the original — fills it out again. The risk team reviews, updates the risk rating if warranted, and files the updated assessment. The cycle repeats.
Incident-triggered reassessment. If a vendor experiences a significant security incident that becomes publicly known, the entity may conduct an ad-hoc reassessment. This is typically reactive and unstructured — a series of urgent emails followed by a management update. Once the immediate concern passes, the entity returns to the annual cycle.
This model has three structural weaknesses that DORA exposes.
Point-in-time answers decay immediately. A questionnaire response reflects the vendor's environment at the moment of completion. It does not capture changes that occur the following week, month, or quarter. A vendor that was fully patched when it completed the questionnaire may have accumulated critical vulnerabilities by the time the next annual review arrives. A vendor that reported no sub-contracting may have outsourced a critical function three months later. The annual questionnaire creates an illusion of continuous knowledge where only periodic knowledge exists.
Self-reported data lacks verification. Questionnaire responses are self-attestations. The vendor describes its own controls, its own incident history, and its own compliance status. Without independent verification — through audit rights, technical assessments, or continuous monitoring signals — the entity is accepting the vendor's self-assessment at face value. This is not inherently unreasonable for low-risk vendors, but for critical ICT service providers whose failure could disrupt the entity's essential functions, it is insufficient.
The model does not scale. A mid-sized financial entity may have 200-500 ICT service provider relationships. A large bank may have thousands. Conducting meaningful annual assessments of every relationship is operationally infeasible. The result is tiering — critical vendors get assessed, important vendors get a lighter assessment, and the long tail gets ignored. This tiering is sensible, but it means that the entity has limited visibility into the risk profile of the majority of its vendor portfolio.
What DORA Chapter V Actually Requires
DORA Articles 28 through 30 establish a fundamentally different model for ICT third-party risk management. The requirements are specific, prescriptive, and operational.
Article 28: The Register of Information
Article 28(3) requires financial entities to "maintain and keep up to date at entity level, and at sub-consolidated and consolidated levels, a register of information in relation to all contractual arrangements on the use of ICT services provided by ICT third-party service providers."
Two words carry the weight: "maintain" and "keep up to date." A register compiled once and reviewed annually does not satisfy this requirement. The register must reflect the current state of the entity's ICT third-party relationships at all times. When a new contract is signed, when a contract terminates, when a provider changes its sub-contracting arrangements, when a criticality assessment changes — the register must be updated.
The ESA implementing technical standard specifies the register's content in granular detail: provider identification, service description, criticality assessment, data processing locations, sub-contractor chains, substitutability assessment, and contractual terms. This is not a spreadsheet maintained by one person in procurement. It is a living data asset that requires input from procurement, IT, risk, and legal, and that must be reconciled against operational reality on an ongoing basis.
Article 28(8): Concentration Risk
Article 28(8) requires entities to identify and assess concentration risk. This is not just about single-vendor dependency at the entity level. The ESAs assess concentration risk at the sector level — whether the financial sector as a whole is excessively dependent on a small number of ICT service providers.
At the entity level, concentration risk assessment requires understanding which critical or important functions depend on the same provider, which providers would be difficult or impossible to substitute, and what the impact would be if a critical provider experienced a prolonged outage or termination.
This assessment cannot be performed annually. Provider dependencies shift as IT architectures evolve. New services are adopted. Existing services are consolidated. An entity that assessed concentration risk in January and adopted a new critical cloud service from the same provider in June has a stale concentration risk assessment for at least six months.
Article 30: Contractual Provisions
Article 30 specifies mandatory contractual provisions for agreements with ICT third-party service providers. Among them:
- Service level descriptions that are sufficiently precise to enable monitoring (Art. 30(2)(a))
- Data processing locations and notification requirements if the provider intends to change them (Art. 30(2)(b))
- Incident notification obligations — the provider must notify the entity of ICT-related incidents affecting the services provided (Art. 30(2)(e))
- Audit rights — the entity or its appointed auditor must have the right to conduct audits of the provider (Art. 30(2)(f))
- Exit strategies — including adequate transition periods, obligations to assist with migration, and data return or destruction provisions (Art. 30(2)(g))
- Participation in resilience testing — for critical or important functions, the provider must participate in the entity's TLPT programme (Art. 30(3))
These provisions are not one-time contractual insertions. They create ongoing operational obligations. Incident notification clauses must be exercised. Audit rights must be used. Exit strategies must be updated as the entity's dependency on the provider evolves. Service level monitoring requires actual monitoring, not annual SLA review meetings.
Why Annual Assessments Fail the DORA Test
The gap between the old model and DORA's requirements is structural, not incremental. You cannot adapt an annual questionnaire programme into DORA compliance by making the questionnaire longer or the review more thorough. The fundamental timing is wrong.
Continuous register maintenance requires event-driven updates. The register must change when the world changes — when contracts are signed, terminated, or amended; when providers change their sub-contracting; when criticality assessments shift. Annual review cannot capture these events in anything approaching real time.
Incident notification operates on hours, not months. DORA requires entities to report major ICT-related incidents within four hours of classification. If a critical provider experiences an incident, the entity's ability to classify its own exposure depends on knowing — right now, not at the next annual review — exactly which functions depend on that provider. A stale register means a slow classification, which means a missed reporting deadline.
Concentration risk is dynamic. Cloud adoption patterns shift quarterly. New projects spin up on existing providers. Shadow IT introduces dependencies that procurement never approved. An annual concentration risk snapshot is fiction by the time it is reviewed.
Exit strategy credibility requires operational validation. A contractual exit clause drafted at contract inception may become meaningless if the entity's dependency on the provider has deepened since then. Exit strategies for critical providers need periodic validation — can the entity actually migrate? How long would it take? Has the alternative provider landscape changed? Annual review catches these changes too late.
Continuous Oversight: What It Actually Means
The term "continuous monitoring" triggers anxiety in compliance teams because it sounds like real-time surveillance of every vendor's security posture. That is not what DORA requires, and it is not what effective TPRM programmes implement.
Continuous oversight means event-driven assessment supplemented by periodic deep review. The events that trigger assessment include:
Contractual events. New contract signed, contract renewed, contract amended, scope of services changed, data processing locations changed. Each of these events should trigger a register update and, for critical providers, a reassessment of the risk profile and concentration impact.
Provider events. Security incident disclosed (by the provider or publicly), ownership change (acquisition, merger), financial distress signals, sub-contractor change notified, certification expiry or downgrade, regulatory action against the provider. Each of these should trigger a risk reassessment proportionate to the event's severity and the provider's criticality.
Entity events. New critical function deployed on an existing provider's infrastructure, IT architecture change that alters provider dependency, new regulatory requirement that changes the compliance expectations placed on providers. These internal changes can alter the risk profile of existing relationships.
Periodic reviews. For critical providers, quarterly risk reviews that go beyond the questionnaire — examining SLA performance data, incident history, audit findings, and exit strategy currency. For important providers, semi-annual reviews. For standard providers, annual questionnaire reassessment remains appropriate.
This model does not require monitoring every vendor every day. It requires that the entity has mechanisms to detect relevant events and trigger proportionate responses. Some of these mechanisms are automated — security rating services that flag provider incidents, contract management systems that surface renewal dates, procurement workflows that trigger register updates. Others are manual — relationship managers who communicate with provider counterparts and escalate relevant information.
The critical infrastructure is the register of information. When it is current, complete, and accurate, event-driven assessment is feasible: you know which provider is affected, which functions depend on it, and what the criticality is. When the register is stale, every event triggers a scramble to establish basic facts before the risk assessment can even begin.
The Register of Information: Your Living Vendor Inventory
The register of information under Article 28(3) is not a reporting obligation that exists in isolation. It is the operational backbone of the entire TPRM programme under DORA. Every other obligation depends on it.
Incident classification requires knowing which functions depend on the affected provider. Concentration risk assessment requires knowing the full scope of dependency on each provider. Exit strategy development requires knowing which services the provider delivers and how substitutable they are. Supervisory reporting requires a register that can be produced on demand.
Building and maintaining the register requires integration across multiple organisational functions:
- Procurement knows which contracts exist and their terms
- IT/Engineering knows which services are operationally deployed and which functions depend on them
- Risk determines criticality classifications and concentration risk assessments
- Legal reviews contractual provisions for DORA compliance
- Finance tracks spend data that informs criticality and concentration analysis
No single function has the complete picture. The register must aggregate and reconcile data from all of these sources. Vendor risk management platforms that integrate with procurement systems, IT asset inventories, and contract management tools can automate much of this aggregation. Without such integration, the register becomes a manual compilation exercise that deteriorates between updates.
The ESA template for the register is deliberately detailed. It requires fields that many entities do not currently track: the provider's LEI (Legal Entity Identifier), the identification of sub-contractors in the ICT supply chain, the locations where data is processed and stored, and an assessment of the substitutability of the provider. Completing this template for the first time is a significant project. Maintaining it as a living document requires embedded processes, not periodic projects.
Practical Transition: From Annual to Continuous in 90 Days
Transitioning from annual questionnaire-based TPRM to continuous oversight is operationally significant, but it does not require a multi-year programme. A focused 90-day transition plan can establish the foundation.
Days 1-30: Foundation.
- Complete a current-state inventory of all ICT third-party service providers (even if rough — completeness over perfection at this stage)
- Classify providers into criticality tiers: critical (supports critical or important functions), important (supports business operations but not critical functions), standard (everything else)
- Map critical providers to the ESA register template — identify which fields are populated, which have data gaps
- Identify the top 10 concentration risk exposures — which providers, if they failed, would affect the most critical functions?
Days 31-60: Process design.
- Define event triggers for each criticality tier — which events trigger reassessment and at what depth
- Design the register update workflow — who is responsible for each data field, what triggers an update, how frequently is reconciliation performed
- Review and amend contracts with the top 5 critical providers for DORA Article 30 compliance — incident notification, audit rights, exit provisions
- Establish a quarterly review cadence for critical providers
Days 61-90: Operationalisation.
- Implement the register in a system that supports ongoing maintenance (not a static spreadsheet — a purpose-built or adapted platform)
- Conduct the first event-driven reassessment for any critical provider that has experienced a relevant event since the last annual review
- Test the incident response workflow for a supplier incident scenario — can the entity identify affected functions, assess impact, and classify its regulatory reporting obligation within the four-hour DORA window?
- Brief the management body on the new TPRM operating model and the current state of the register
This 90-day plan does not achieve perfection. The register will have gaps. Not all contracts will be amended. Not all event triggers will be automated. But it establishes the operating rhythm — the shift from annual to continuous — and provides a defensible baseline for the first supervisory engagement.
Perfection is the enemy of progress in TPRM transformation. Supervisors understand that building a comprehensive continuous oversight programme takes time. What they will not accept is an entity that has not started — that is still operating on the annual questionnaire model eleven months after DORA's application date.
For guidance on structuring exit strategies and managing the supply chain security dimension alongside DORA requirements, our framework documentation provides implementation pathways that complement this operational transition.
Key Takeaways
- Annual vendor questionnaires were the industry standard for TPRM. DORA Chapter V makes them structurally insufficient. The Regulation requires a living register of information, event-driven risk reassessment, and continuous awareness of concentration risk — none of which an annual cycle can deliver.
- Continuous oversight does not mean real-time monitoring of every vendor. It means event-driven assessment triggered by contractual changes, provider incidents, entity architecture changes, and periodic deep reviews for critical providers. The key is mechanisms to detect relevant events and respond proportionately.
- The register of information is the operational backbone of DORA TPRM. It must be maintained and kept up to date — not compiled annually. Building it requires integration across procurement, IT, risk, legal, and finance. Without this integration, the register degrades between updates.
- DORA Article 30 contractual provisions — incident notification, audit rights, exit strategies, participation in resilience testing — create ongoing operational obligations, not one-time legal insertions. These clauses must be exercised, not just included.
- A 90-day transition plan can establish the foundation: inventory and classify providers, design event triggers and register workflows, amend critical contracts, and operationalise the register in a maintainable system. Perfection follows; the operating rhythm comes first.
- The CISO's priority should be to ensure that the register is current enough to support four-hour incident classification. If a critical provider goes down at 2 AM, can you identify affected functions and classify your regulatory reporting obligation without first spending hours determining what you actually depend on?