“Which important services could fail, and are we ready if they do?”
Every EU DORA pillar, every NIS2 risk-management measure and every UK operational resilience requirement — important business services, impact tolerances, mapping and scenario testing. Dotwork puts them beside the services, systems, suppliers, contracts and budgets they cover, so one map of what depends on what serves all three regimes. Name services and set tolerances your way. As technical standards and national rules land, each is mapped onto the services and suppliers you already have. And security and financial controls draw on the same control library. Dotwork doesn’t file with regulators or certify compliance — it gives the people who do a map they can trust.
Runs in
Covers
EU DORA · NIS2 · UK op-res
The pressure
Resilience rules all ask the same questions — what matters most, what it depends on, who supplies it and whether you can recover in time. Most firms answer them in separate places: a continuity tool, a supplier register, a CMDB and a spreadsheet of tolerances. The map is redrawn for every regulator and every test, and it is out of date before the next change lands.
What it looks like today
Full coverage
EU DORA, NIS2 and UK operational resilience overlap heavily. Each requirement maps to a place in Dotwork, and where they overlap they share the same records instead of three copies.
Built for EU DORA · NIS2 · UK operational resilience (PRA and FCA)
Pillar one, owned by the management body.
Pillars two, three and five.
Pillar four, and the register of information.
Cybersecurity risk management for essential and important entities.
PRA and FCA rules, fully in force since 31 March 2025.
Where resilience becomes work.
What changes
A separate map for each regulator
A single dependency map that DORA, NIS2 and UK rules all read
Tolerances set and forgotten
Impact tolerances read against tested recovery, service by service
A supplier register built for the submission
Third parties drawn from the contracts and the systems they support
Resilience gaps on a risk log
Gaps owned, priced and funded through the portfolio
What a disruption reaches
Choose a system, a supplier or a planned change and follow the dependencies up to the capabilities and important business services that rely on it, the teams that run them, the controls that cover them and the contracts that supply them. Controls that are not attested and contracts close to renewal stand out — before the disruption, not after.
Where other tools stop
Continuity tools hold the plans. Supplier tools hold the vendors. Architecture tools hold the dependencies. None of them shows the whole path from a supplier to the service a customer feels.
Flexed to how you run
Few firms answer to only one regime. Dotwork keeps one model of services and dependencies and lets each regulator’s vocabulary sit on top.
Your service catalog
Name important business services and critical or important functions the way your firm does. One service can carry the UK and DORA designations at once.
Tolerances you set
Declare an impact tolerance for each service and read tested recovery against it — not against IT’s own target.
The right regime per entity
Apply DORA, NIS2, UK rules or several to each legal entity, without copying the map.
Start with one service
Map your most important service end to end, then extend the map as each team adds its own.
As new rules land
Resilience regulation is still being written — technical standards, designations and national laws keep landing. Each new requirement is mapped onto the services, controls and suppliers you already have and put to compliance for approval. Earlier submissions keep the basis they were made on.
EU DORA applies from 17 January 2025, replacing a patchwork of ICT guidelines
Existing policies and controls remapped to DORA’s five pillars, with gaps named
A register of information on every ICT third-party arrangement
Built from the contracts and suppliers already in Procurement & Commitments
Critical ICT third-party providers designated for EU oversight from November 2025
Designated providers flagged, with every service that depends on them
NIS2 widens scope to essential and important entities, with a 24-hour early warning
Entities in scope marked, with the same controls serving NIS2 and DORA
UK transition ended 31 March 2025 — firms must stay within tolerance
Tolerances read against tested recovery, continuously
UK incident and third-party reporting rules apply from 18 March 2027
Material third-party arrangements drawn from the same register
Every framework, one model
Resilience rules lean on the same assets, controls and suppliers as security, financial controls and architecture. Here those frameworks read one map instead of keeping their own.
NIST CSF · ISO 27001 · SOC 2 · COBIT · SEC cyber rules
NIS2 and DORA measures map to the same NIST CSF and ISO 27001 controls — attested once.
Explore Security & IT GovernanceSOX · COSO
Resilience tests exercise the same recovery controls that SOX computer-operations testing relies on.
Explore Financial ControlsADM · TOGAF Standard, 10th Edition
The baseline architecture is the dependency map regulators ask to see.
Explore TOGAFCapability and process maps
Important business services rest on the capabilities and processes already mapped.
Explore BIZBOK & APQCISO/IEC 19770 · licenses, contracts and renewals
Each ICT supplier in the register carries its contracts, licenses and renewal dates.
Explore IT Asset ManagementTIME model · 7 Rs
Applications that put a service at risk become candidates to invest in, migrate or retire.
Explore App RationalizationAI-native resilience
The repetitive work of resilience — redrawing the map, rebuilding the register, scoping an incident — is prepared from the live model. People set tolerances, accept risk and file with regulators.
Starts from a failing system or supplier and follows the dependencies up to the important business services and capabilities it would take down.
Compares each service’s recovery objectives and last test with its impact tolerance.
Assembles the register of ICT third-party arrangements from contracts, suppliers and the services they support, and flags missing fields.
Counts how many important services each supplier carries and flags single points of failure.
Flags technology losing support beneath an important service, with no funded plan to replace it.
Follows each policy — and the DORA, NIS2 or UK requirement it cites — to the controls that implement it, and flags requirements that reach nothing.
Proposes how a new requirement maps onto the services, controls and suppliers you already have.
Answers questions about services, dependencies and suppliers, citing the records — and the as-of date — behind every answer.
Where it runs in Dotwork
Dotwork does not ask you to adopt a new method. The framework becomes a view over the same model these solutions already read and write.
Govern & Deliver
“Can we prove our controls were actually working on what we shipped?”
ExploreGovern & Deliver
“What does this capability cost to run — and what depends on it?”
ExploreFund & Optimize
“What did we buy, and is it used?”
ExploreHow it compares
Resilience and continuity platforms run plans and tests. GRC suites hold the third-party register and the controls. Operational Resilience on Dotwork reads both from one model of services, systems and suppliers, and connects every gap to the money that closes it. Keep your incident and crisis tooling; Dotwork gives it the map.
| Capability | Resilience & continuity platforms | GRC suites | Operational Resilience on Dotwork |
|---|---|---|---|
| Important business services and impact tolerances | Partly | ||
| Business impact analysis and recovery plans | Partly | ||
| Register of ICT third-party arrangements | Partly | ||
| EU DORA, NIS2 and UK rules on one set of records | Partly | Partly | |
| Dependencies read from the live architecture, not redrawn | Partly | ||
| Suppliers tied to contracts, renewals and notice dates | Partly | Partly | |
| New rules mapped onto the services and suppliers already there | Partly | Partly | |
| Map and register drafts ready for review | Partly | Partly | |
| Resilience gaps priced and funded through the portfolio |
Who it is for
“Which important business services could breach tolerance, and why?
“Can we show the regulator our mapping without rebuilding it?
“Which ICT risks sit behind our most important services?
“Which ICT suppliers support critical functions, and when do they renew?
“What breaks if this system fails?
“Are we within our tolerances, and what would it cost to close the gaps?
Before you buy
How to get a number instead of a pitch.
1
Good answer · Yes — systems, data, suppliers and people on one path, with the as-of date.
Bad answer · A diagram drawn for the last regulatory review.
2
Good answer · The contracts, suppliers and systems already on the model.
Bad answer · Rebuilt by hand every reporting cycle.
3
Good answer · The gap is recorded, owned, priced and funded like any other work.
Bad answer · It goes into the test report.
More in Risk, Compliance & AI
Risk, Compliance & AI
The rules your controls have to prove they meet — including the new ones for AI.
The model underneath
Steer, Fund & Optimize and Govern & Deliver all read and write the same Enterprise Operating Model. The first module you license builds the model. Every module after it adds context instead of another silo — and Dotwork AI reads all of it, stopping where the decision is yours.
See the Enterprise Operating Model© 2025-2026 Dotwork, Inc. All rights reserved.