Building Your DORA Register: Map Critical ICT Third-Party Providers

Updated at Nov 28, 2025. Published at Dec 19, 2025.
Building Your DORA Register: Map Critical ICT Third-Party Providers

The Digital Operational Resilience Act (DORA) requires financial institutions to maintain a comprehensive register of their critical ICT third-party providers. This register isn't just a compliance checkbox, it's a strategic tool for managing operational risk and ensuring business continuity. Building an effective DORA register requires systematic identification, classification, and continuous monitoring of your SaaS dependencies.

Understanding DORA's Requirements for Third-Party Mapping

DORA mandates that financial entities maintain detailed records of all ICT services supporting critical functions. This includes cloud providers, payment processors, communication platforms, and any SaaS tools integral to your operations.

The regulation distinguishes between regular vendors and critical ICT third-party providers based on several factors:

  • Impact on essential business functions

  • Difficulty of substitution

  • Number of financial entities dependent on the provider

  • Systemic importance to the financial sector

Your register must capture not just direct relationships but also concentration risks and fourth-party dependencies that could affect your operations.

Starting Your Third-Party Inventory

Begin by conducting a comprehensive audit of all technology services your organization uses. This process often reveals shadow IT and forgotten subscriptions that pose untracked risks.

Start with these data sources:

  • Procurement records and contracts

  • IT asset management systems

  • Financial statements and invoices

  • Department surveys and interviews

  • Network traffic analysis

  • Single sign-on (SSO) logs

Create a master spreadsheet capturing basic information for each vendor: service name, primary function, business owner, contract details, and initial criticality assessment. This becomes your working document for deeper analysis.

Classifying Provider Criticality

Not all vendors require the same level of scrutiny. DORA expects you to apply risk-based prioritization, focusing resources on providers that could materially impact your operations.

Develop a scoring framework considering:

Business Impact

  • Revenue generation dependency

  • Customer-facing service involvement

  • Regulatory reporting functions

  • Data sensitivity and volume

Operational Factors

  • Recovery time objectives (RTO)

  • Alternative solutions availability

  • Integration complexity

  • Geographic concentration

Risk Indicators

  • Provider's financial stability

  • Security certifications

  • Past incident history

  • Subcontracting practices

Assign each provider a criticality tier (Critical, High, Medium, Low) based on your scoring. Critical ICT third-party providers require enhanced due diligence, contractual provisions, and exit strategies.

Documenting Dependency Chains

Modern SaaS ecosystems involve complex interdependencies. Your authentication provider might rely on a CDN, which depends on specific DNS services. Mapping these chains helps identify single points of failure and concentration risks.

For each critical provider, document:

  • Primary services delivered

  • Key subcontractors and fourth parties

  • Infrastructure dependencies (cloud regions, data centers)

  • Integration points with your systems

  • Data flows and storage locations

Visual dependency maps make it easier to spot vulnerabilities. Tools like draw.io or Lucidchart can help create clear diagrams showing how services connect.

Building Monitoring Capabilities

Static documentation quickly becomes outdated. Effective DORA compliance requires continuous monitoring of your critical ICT third-party providers' operational status and risk profile.

Implement these monitoring practices:

Real-time Status Tracking

Subscribe to vendor status pages and configure alerts for service disruptions. A status page aggregator can centralize monitoring across multiple providers, reducing the overhead of tracking individual status pages.

Performance Metrics

Track key indicators like uptime percentage, incident frequency, and resolution times. Compare actual performance against contractual SLAs.

Risk Signal Monitoring

Set up alerts for:

  • Security breach notifications

  • Financial distress indicators

  • Regulatory sanctions

  • Major organizational changes

  • Service sunset announcements

Regular Reviews

Schedule quarterly reviews of critical providers including:

  • Contract renewal assessments

  • Criticality re-scoring

  • Exit strategy updates

  • Alternative vendor evaluation

Implementing Exit Strategies

DORA requires documented exit plans for critical ICT third-party providers. These plans must be realistic and regularly tested.

Your exit strategies should address:

Data Portability

  • Export formats and procedures

  • Data retention timelines

  • Deletion confirmation processes

Transition Planning

  • Alternative provider identification

  • Migration effort estimates

  • Parallel running capabilities

  • Training requirements

Contractual Provisions

  • Termination notice periods

  • Transition assistance obligations

  • Post-termination support

  • Escrow arrangements for critical code

Test exit procedures annually for your most critical providers. Document lessons learned and update plans accordingly.

Maintaining Register Accuracy

Your DORA register requires ongoing maintenance to remain useful and compliant. Establish clear governance processes:

Update Triggers

  • New vendor onboarding

  • Contract modifications

  • Service scope changes

  • Criticality reassessments

  • Incident learnings

Review Cycles

  • Monthly: New additions and changes

  • Quarterly: Criticality scoring validation

  • Annually: Complete register audit

  • Ad-hoc: Post-incident updates

Stakeholder Responsibilities

  • Business owners: Service criticality input

  • Procurement: Contract details maintenance

  • IT Operations: Technical dependency mapping

  • Risk Management: Overall register governance

Integration with Broader Risk Management

Your DORA register shouldn't exist in isolation. Integrate it with your incident management processes to improve response times when third-party issues arise.

Connect register data to:

  • Business continuity plans

  • Incident response runbooks

  • Risk assessment frameworks

  • Vendor management programs

  • Audit procedures

This integration ensures your third-party risk management efforts support broader operational resilience objectives.

Preparing for Regulatory Scrutiny

Regulators will expect to see:

  • Complete and current provider inventory

  • Clear criticality assessment methodology

  • Documented monitoring procedures

  • Tested exit strategies

  • Evidence of regular reviews

Maintain an audit trail showing register updates, review decisions, and testing results. This demonstrates active management rather than mere compliance.

Frequently Asked Questions

What qualifies as a critical ICT third-party provider under DORA?

Critical ICT third-party providers are those whose failure would materially impact your ability to deliver essential services. This typically includes core banking platforms, payment processors, cloud infrastructure providers, and security services. The classification depends on your specific business model and the provider's role in supporting critical functions.

How often should we update our DORA register?

The register should be a living document updated whenever significant changes occur, such as new vendor onboarding or service modifications. At minimum, conduct monthly reviews for changes, quarterly criticality assessments, and annual comprehensive audits. More frequent updates may be necessary for rapidly evolving environments.

Do we need to include all SaaS tools in our DORA register?

While DORA focuses on critical ICT third-party providers, best practice suggests maintaining a complete inventory of all ICT services. Start with comprehensive documentation, then apply risk-based filtering to identify which providers require enhanced oversight. Non-critical providers can be tracked with less detail.

How detailed should our exit strategies be?

Exit strategies for critical providers should be detailed enough to execute under stress. Include specific procedures for data extraction, migration timelines, resource requirements, and decision triggers. The level of detail should match the provider's criticality and the complexity of transitioning away from their services.

Can we use automated tools to maintain our DORA register?

Yes, automation can significantly improve register accuracy and reduce maintenance burden. Tools can help with vendor discovery, status monitoring, and alert generation. However, human oversight remains essential for criticality assessments, exit strategy development, and strategic decision-making.

What happens if we identify concentration risks in our register?

When multiple critical services depend on the same provider or infrastructure, document this concentration risk clearly. Develop specific mitigation strategies such as multi-vendor approaches, enhanced monitoring, or stronger contractual protections. Regulators expect you to actively manage identified concentrations, not just document them.

Nuno Tomas Nuno Tomas Founder of IsDown
Share this article
IsDown Logo

Status Aggregator for All Your Third-Party Services

Unified vendor dashboard

4600+ third-party services available to monitor

Early Outage Detection

Alerts 30+ minutes before official updates

Stop the Support Flood

Cut "is it down?" tickets by 80%

14-day free trial • No credit card required

Related articles

Status Aggregator for All Your Third-Party Services
Sign in with Google Start Free Trial
14 day free trial • No credit card required