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.
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.
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.
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.
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.
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
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.
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
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.
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.
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.
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.
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.
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.
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.
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
Founder of IsDown