ICT risk management
A framework owned by the management body, from asset identification to recovery.
What assessors look forAn asset inventory linked to critical functions, reviewed yearly.
EU operational resilience · Core service
DORA readiness that holds up under supervisory scrutiny.
Prove your critical functions can withstand, respond to and recover from ICT disruption, including disruption that starts at a provider.
- Regulation (EU) 2022/2554
- Register of information
- TLPT preparation
- Who it is for
- EU financial entities in scope, and the ICT providers that serve them
- What it covers
- ICT risk, incidents, testing, third-party risk and information sharing
- Starting point
- A gap assessment against DORA and its technical standards
- Our role
- Readiness assessment, program design and resilience testing
The challenge
Resilience is now something you evidence.
Supervisors expect the mechanics: which assets and providers sit beneath each critical function, and how fast it recovers when one fails.
The information usually exists, spread across architecture, procurement and continuity records that have never been forced to agree. The register of information exposes that gap immediately.
- Pillars of the regulation
- 5
- Hours to the initial major-incident notification, after classification
- 4h
- Hours to the intermediate report
- 72h
- Applied since January
- 2025
The register of information is not an administrative return. It is a dependency map a supervisor can read across the sector.
What a well-run program leaves behind
01
A dependency model you trust
Functions traced and reconciled to assets, providers and subcontractors.
02
Classification without debate
Teams that apply the criteria fast, with report templates ready.
03
Tested recovery
Realistic scenarios, including provider loss, against tolerances.
04
Defensible third-party governance
Contracts, exits and concentration analysis that stand up to review.
Regulatory requirements
Five pillars, and what each demands.
We work from the level-one text and its technical standards together.
Incident reporting
For major incidents: an initial notice within 4 hours of classification and no later than 24 hours after awareness, an intermediate report within 72 hours and a final report within one month.
What assessors look forConsistent classification and decision logs.
Resilience testing
A risk-based testing program. Designated entities also perform TLPT, generally every three years.
What assessors look forEvery critical function covered, with remediation tracked.
ICT third-party risk
Due diligence, mandatory contract provisions, exit strategies and the register of information.
What assessors look forA register that reconciles with reality.
Critical provider oversight
The ESAs oversee designated critical providers; first designations announced November 2025.
What assessors look forDesignation never replaces your own due diligence.
Information sharing
Voluntary threat-intelligence exchange within trusted communities.
What assessors look forClear governance over what is shared, and how.
Timeframes summarize the technical standards on major-incident reporting. Each engagement works from the current text and your supervisor’s guidance.
Interactive model
Trace a critical function. Then break a provider.
Simulate a provider outage on a fictional bank and watch tolerances, classification and the reporting clock respond.
Loading interactive demonstration…
A demonstration model. The institution, providers, tolerances and costs are synthetic, and the classification logic is a simplified reading of the regulatory technical standards.
Our methodology
How we assess and advise on DORA.
Our five-phase lifecycle, tuned to how supervisors examine resilience.
01
Function-first scoping
We start from critical functions rather than systems, so shared services such as identity and DNS are never missed.
02
Evidence against the standards
For each requirement: what exists, what proves it and who owns it.
03
Realistic scenarios
Scenarios built from the dependencies we actually find, tested against your impact tolerances.
04
Proportionality, documented
Where the regulation permits a lighter approach, we record it as a reasoned decision your supervisor can follow.
05
Separate testing team
The people who test your resilience are not the people who helped design your controls.
Capabilities & deliverables
What we deliver.
Used by your teams, readable by your supervisor.
DORA gap assessment
Against the regulation and its standards, prioritized by risk.
Dependency model
Functions to assets, providers and subcontractors.
Register of information review
Completeness, quality and reconciliation.
Incident classification playbook
Decision trees, roles and report templates.
Resilience testing program
Multi-year, covering every critical function.
TLPT readiness
Scoping, control team and provider involvement.
Accreditation & scope
What you get from us
What MarkTillson delivers
- Independent DORA readiness and gap assessments
- Design support for ICT risk, incident, testing and third-party frameworks
- Scenario exercises and resilience testing
- Register of information review and reconciliation
- TLPT preparation: scoping, control team and provider arrangements
Every proposal sets out the scope, the team and the dates before work begins.
Framework mapping
Where DORA overlaps, and where it does not.
ISO, NIST and NIS2 work is useful input, but DORA adds obligations none of them cover.
| Control area | DORA | NIS2 | ISO/IEC 27001:2022 | ISO 22301 | NIST CSF 2.0 |
|---|---|---|---|---|---|
| ICT risk framework & governance | Directly addressed | Directly addressed | Directly addressed | Partially addressed | Directly addressed |
| Incident classification against regulatory criteria | Directly addressed | Partially addressed | Partially addressed | Not addressed– | Partially addressed |
| Regulatory reporting timelines | Directly addressed | Directly addressed | Not addressed– | Not addressed– | Not addressed– |
| Continuity & impact tolerances | Directly addressed | Partially addressed | Partially addressed | Directly addressed | Partially addressed |
| Threat-led penetration testing | Directly addressed | Not addressed– | Not addressed– | Not addressed– | Not addressed– |
| Register of information | Directly addressed | Not addressed– | Not addressed– | Not addressed– | Not addressed– |
| Contract provisions & exit strategies | Directly addressed | Partially addressed | Partially addressed | Partially addressed | Partially addressed |
Directly addressed Partially addressed or different evidence expectations , Not a primary objective. For financial entities, DORA operates as sector-specific law alongside NIS2. We confirm your Member State’s position at the outset.
Industry considerations
Same regulation. Different pressure points.
Proportionality and business models change where effort belongs.
The full weight of the framework, and the likeliest TLPT candidates.
- Core banking on SaaS and outsourcing
- Intragroup ICT services as third-party arrangements
Heavy reliance on processors, cloud and banking partners.
- Concentration and exit planning
- Overlap with PCI DSS
Latency-sensitive systems and strict settlement deadlines.
- Connectivity provider concentration
- Coordinated testing with counterparties
Large application estates and extensive outsourcing.
- Legacy policy platforms
- Claims subcontracting chains
Clients must impose DORA provisions on you. Prepare a reusable response.
- Contract-clause readiness
- Support for clients’ TLPT
Technologies, risks & use cases
The scenarios that keep resilience teams awake.
Single-region identity
Applications fail over. The identity service they all depend on does not.
Backups that share fate
Reachable with the same admin credentials as production.
Fourth-party concentration
“Different” providers on the same hyperscaler.
Platforms you cannot exit
Exit plans that assume a migration nobody has sized.
Engagement journey
From first workshop to a program that runs itself.
-
01
Mobilize
Scope, proportionality and critical functions.
OutputScoping note
-
02
Map
Functions to assets, providers and subcontractors.
OutputDependency model
-
03
Assess
Each pillar, classification and contracts.
OutputGap assessment
-
04
Exercise
Provider-loss and ransomware scenarios.
OutputExercise report
-
05
Plan & sustain
Roadmap, testing plan and board cadence.
OutputBoard briefing
FAQ
Questions we are asked most.
DORA has applied since January 2025. Is readiness still relevant?
Yes. Many entities met the deadline on paper and are now asked to show effectiveness: a register that reconciles, consistent classification and testing that covers every critical function.
We hold ISO/IEC 27001. How much of DORA does that cover?
Much of ICT risk management, but not incident reporting, the register, contract provisions, exit strategies or TLPT. We map your controls so nothing is rebuilt.
Will we have to perform TLPT?
Only if your competent authority identifies you. Preparing the scope, a control team and provider arrangements strengthens ordinary testing either way.
Our provider is designated critical. Does that reduce our obligations?
No. You remain responsible for due diligence, contract provisions, monitoring and exit planning.
Can you prepare our incident reports?
Yes. We build the playbook, train your team and sit with you during a live incident, so every report goes out on time and in your name.
Related services and insights
DORA
Find out what your supervisor will see.
Start with a scoping conversation about your critical functions, register and testing program.