HC3 banking · DORA operational resilience
Understand the systems behind your critical functions.
DORA asks financial entities to know which ICT systems deliver critical functions — and what depends on what. Adapts builds the technical evidence layer underneath those activities: a connected model of applications, code, data, jobs, interfaces, and dependencies.
Adapts supports technical evidence and analysis for DORA programs. Adapts does not certify regulatory compliance.
01 · The challenge
Regulatory resilience depends on technical understanding.
A critical banking function rarely depends on one application. Payments, deposits, lending, settlement, and customer servicing can span APIs, databases, batch jobs, mainframe programs, shared libraries, queues, schedulers, and external providers. Resilience, engineering, architecture, and risk each hold a partial view — yet the institution still needs a defensible answer to what actually delivers the function, and what happens when something changes or fails.
What DORA asks
Article 8 identification — and the technical evidence Adapts supplies.
Regulation (EU) 2022/2554 requires identification, mapping, inventories, major-change assessment, and legacy ICT risk context. Those activities need a defensible technical model of the estate — not another workshop diagram.
- Art. 8(1)
Identify & document ICT-supported functions and supporting assets
AdaptsMap each critical function to the apps, data, jobs, and interfaces that deliver it.
- Art. 8(2)
Identify ICT risk sources and review risk scenarios at least yearly
AdaptsGround scenarios in real dependencies — what breaks when a shared system fails.
- Art. 8(3)
Assess ICT risk before major infrastructure or process changes
AdaptsShow the blast radius: upstream, downstream, and which critical functions are in scope.
- Art. 8(4)
Map critical assets and the links between them
AdaptsTrace interdependencies across applications, shared components, data stores, and integrations.
- Art. 8(6)
Keep inventories current — and update them after major change
AdaptsRefresh the system model from technology sources instead of rebuilding docs by hand.
- Art. 8(7)
Assess legacy ICT systems at least yearly
AdaptsShow dependency, critical-function, and shared-component exposure — not just system age.
Source: Regulation (EU) 2022/2554 — Official Journal (EUR-Lex).
02 · Critical-function mapping
Connect business functions to the technology that delivers them.
Instead of interviews and static diagrams alone, teams can trace how the systems under a critical or important function actually connect — from channels and APIs through programs, data, and providers.
- 01Critical functionPayments · Deposits · Lending · Settlement · Customer servicing
- 02Applications and servicesChannels · APIs · Distributed services · Core platforms
- 03Programs and executionPrograms · Transactions · Batch jobs · Schedulers · Shared components
- 04DataDatabases · Files · Queues · Schemas · Data flows
- 05Infrastructure and providersPlatforms · External systems · Third-party services · Shared infrastructure
Connected technical evidence
03 · Dependencies & concentration
See what depends on what — including hidden shared points.
DORA expects entities to map links and interdependencies, and to understand ICT risk scenarios. A shared database, API, batch process, or external integration can become a concentration point where one disruption hits multiple critical functions.
- What applications support this critical function?
- What critical functions could be affected if this system becomes unavailable?
- Where do multiple critical functions depend on the same technology?
- Which downstream processes use this data store?
04 · Legacy ICT risk
Understand where legacy systems sit inside critical operations.
Covered entities must assess legacy ICT systems at least yearly. Age alone does not determine operational risk — a shared component under twenty services is a different problem from an isolated stable system. Adapts adds the technical exposure context.
| Exposure type | What teams investigate |
|---|---|
| Dependency exposure | What depends on the legacy system? |
| Critical-function exposure | Which important functions rely on the system? |
| Shared-component exposure | Is the component reused across multiple applications? |
| Change complexity | How far could a change propagate? |
| Integration exposure | Which modern applications, APIs, databases, and external systems connect to the legacy environment? |
05 · Change impact
Understand the impact boundary before introducing operational risk.
Major changes to ICT infrastructure or ICT-supported functions require risk assessment. Adapts helps teams investigate the technical blast radius before the change lands.
| Change type | Impact question |
|---|---|
| Application change | What other applications depend on the component? |
| Database change | Which programs, services, jobs, and workflows access the affected data? |
| API change | Which upstream and downstream systems use the interface? |
| Infrastructure change | Which critical functions depend on the affected environment? |
| System retirement | What remaining dependencies prevent safe retirement? |
| Third-party change | Which internal services depend on the provider or external integration? |
06 · Continuous evidence
Move from assertion to a defensible technical model.
Inventories must stay current as the estate changes. Instead of “architecture believes A depends on B,” teams can show the interface, program, job, or data path — and refresh that evidence as technology evolves.
Traditional approach
- Critical-function workshop
- Application inventory
- Architecture diagrams
- SME interviews
- Manual dependency documentation
- Technology changes
- Repeat the exercise
With Adapts
- Technology sources
- Deterministic system analysis
- Connected dependency model
- Critical-function context
- Impact and resilience analysis
- Technology changes
- Refresh the evidence
Keep the technical understanding aligned with the actual estate.
See it on your codebase
Explore DORA operational resilience with Adapts.
30-minute technical walkthrough with an enterprise architect. No slides · a live demo on real system evidence.