ICT dependency mapping is a foundational exercise for DORA compliance. Before you can build a Register of Information, assess third-party risk, or plan for resilience, you need to know what ICT systems and providers your critical business functions depend on. Most financial entities discover, during their first dependency mapping exercise, that their actual technology dependencies are broader and more complex than their documented architecture suggests.
Why Dependency Mapping Matters for DORA
DORA requires financial entities to:
- Identify and document all ICT third-party arrangements (Register of Information)
- Assess which providers are critical
- Ensure contracts with critical providers include specific provisions
- Plan exit strategies for critical providers
- Test resilience against the loss of critical dependencies
None of this is possible without an accurate, current map of what your critical functions depend on and who provides each component.
The Scope of ICT Dependencies
For a typical fintech, the dependency map covers:
Core product infrastructure:
- Cloud hosting provider (AWS, Azure, GCP, or private cloud)
- Database service (managed cloud database or self-hosted)
- Message queue / event streaming (Kafka, SQS, Kinesis)
- CDN and load balancing
- DNS providers
Payment and financial infrastructure:
- Payment processing network (Stripe, Worldpay, Adyen, or direct card network)
- Core banking ledger (if applicable)
- SWIFT/ISO 20022 connectivity
- Open banking aggregators
Identity and authentication:
- Identity verification / KYC provider
- Fraud detection service
- Authentication service (Auth0, Okta, or similar)
Security and monitoring:
- SIEM or log management
- Endpoint detection and response
- Vulnerability management platform
Internal operational tools:
- Email and collaboration (Microsoft 365, Google Workspace)
- Customer support platform (Zendesk, Intercom)
- CRM (Salesforce, HubSpot)
- HR and payroll systems
Development and deployment:
- Source code hosting (GitHub, GitLab)
- CI/CD pipeline
- Container registry and orchestration
The Dependency Mapping Process
Step 1: Identify Critical Business Functions
Start with business outcomes, not technology. What functions, if unavailable, would:
- Prevent customers from making payments?
- Prevent you from executing trades or processing transactions?
- Create immediate financial or regulatory exposure?
- Cause significant reputational harm?
These are your critical functions. Everything else is important but not critical.
Step 2: Map Services to Critical Functions
For each critical function, identify every ICT service involved in delivering it:
- Trace the request or transaction path from user to data store
- Identify each external service called
- Identify each internal service that depends on external services
A payment transaction at a typical fintech might involve: DNS → CDN → Load balancer → Application server → Message queue → Core banking service → Card network → Fraud detection → Database → Notification service. Each component is a potential dependency.
Step 3: Identify the Providers
For each service component, identify:
- Who provides it
- Where it is hosted
- What the fallback is if it is unavailable
Step 4: Assess Concentration and Substitutability
For each provider:
- How many critical functions depend on this provider?
- If this provider were unavailable for 4 hours, what would fail?
- If this provider went out of business, how long would replacement take?
High concentration + low substitutability = critical provider.
Step 5: Build the Register of Information
The completed dependency map feeds directly into the DORA Register of Information. Each third-party service identified in the map becomes an entry in the register.
Documenting the Map
The dependency map should be documented in a format that can be updated as the architecture evolves. Common approaches:
Architecture diagrams: Visual maps showing the flow between services and the external providers at each point. Good for understanding, difficult to maintain at scale.
Dependency register: A structured spreadsheet or database listing services, their providers, and the critical functions they support. Easier to maintain and directly maps to the Register of Information.
Combination: Visual diagrams for communication; structured register for compliance documentation.
The ICT Asset Inventory
DORA also requires a current ICT asset inventory as part of the risk framework. This is distinct from the dependency map:
Dependency map: What external services do our critical functions depend on? Asset inventory: What ICT assets do we own or control — servers, endpoints, network equipment, software licences?
Both are required. The dependency map drives the Register of Information; the asset inventory underpins the broader risk assessment.
Maintaining the Map Over Time
A dependency map that is completed once and never updated becomes misleading quickly. Integrate dependency map maintenance into your change management process:
- New vendor contracts trigger an update to the Register of Information
- Infrastructure changes are reviewed for new dependencies
- Annual dependency review as part of the ICT risk assessment cycle