A fixed-scope, rapid assessment of your readiness against DORA's requirements. You get a gap analysis against the regulation, a prioritised remediation plan, and a clear, practical path to compliance — without a lengthy, open-ended engagement.

What to expect:

• Mobilisation — scope confirmed and evidence request list issued

• Discovery — document review and stakeholder interviews across your risk, incident, testing and third-party functions

• Gap assessment — findings mapped and RAG-rated against all five DORA pillars

• Roadmap & reporting — prioritised remediation roadmap and full assessment report

• Close-out — review cycle and executive readout

Typical duration: 3–4 weeks.

What DORA requires:

The Digital Operational Resilience Act (Regulation (EU) 2022/2554) sets out five areas of obligation for in-scope financial entities. A DORA Sprint assesses your readiness against all five, article by article:

• ICT risk management (Chapter II, Articles 5-16) - governance, the risk management framework, and the identify/protect/detect/respond/recover controls around it

• ICT-related incident management, classification and reporting (Chapter III, Articles 17-23) - your incident process, how you classify a major incident, and reporting it to your regulator in time

• Digital operational resilience testing (Chapter IV, Articles 24-27) - from basic testing of ICT tools through to threat-led penetration testing (TLPT), where you’re in scope for it

• ICT third-party risk management (Chapter V, Articles 28-44) - your ICT provider register, concentration risk, and the specific contractual provisions DORA requires with critical providers

• Information-sharing arrangements (Chapter VI, Article 45) - participation in cyber threat intelligence sharing, where relevant

Is this for you?

DORA applies directly to 21 categories of “financial entity” defined in Article 2 - among them credit institutions, payment and e-money institutions, investment firms, fund and asset managers, insurers and reinsurers, insurance intermediaries, crypto-asset service providers, and trading venues - plus their critical ICT third-party providers. In practice, that most often means:

• Banks, building societies and specialist lenders

• Insurers, reinsurers and MGAs

• Payment institutions and e-money firms

• Asset and investment managers

• ICT providers a regulated financial entity depends on (cloud, core banking platforms, payments infrastructure)

A note for UK-based firms, since this comes up on almost every first call: DORA is EU law, so it doesn’t apply directly to a purely UK-regulated entity. It becomes relevant where the firm (or its group) operates in the EU, or where it’s a critical ICT provider to EU financial-sector clients who are now contractually required to push DORA’s third-party provisions down the supply chain. The UK also runs its own parallel operational resilience regime (the FCA/PRA rules), covering much of the same ground - so a UK-only firm without EU exposure is a candidate for a readiness assessment against the UK regime rather than DORA itself, but the method and most of the findings translate directly either way. Worth raising on the discovery call if you’re not sure which applies to you.

Frequently asked questions

How long does a DORA Sprint take?

Around 3-4 calendar weeks from kickoff to executive readout - client-side interview scheduling and a review cycle are usually the pace-setters, not the assessment itself.

Does DORA apply to us if we’re UK-only?

See the note above - short answer, not directly unless you or your group operate in the EU or supply critical ICT services to EU financial entities, but the UK’s own operational resilience rules cover similar ground and a readiness assessment maps across cleanly either way.

What’s actually in the gap analysis?

A RAG-rated gap register, mapped article-by-article against all five areas above, with the root cause behind each gap - not just a pass/fail - plus a prioritised remediation roadmap sequenced by regulatory risk and effort, and an executive summary deck for your board or leadership team.

Do we need threat-led penetration testing (TLPT)?

Only a subset of entities - designated by their regulator, generally larger or more systemically important firms - are required to run TLPT under Articles 26-27. Most firms aren’t in scope for it, but should still know whether they are; establishing that is part of the Sprint’s testing-pillar assessment, not an assumption either way.

Can you review our contracts with critical ICT suppliers?

Yes - the third-party pillar of the Sprint checks your key contracts against DORA’s required provisions (audit rights, exit assistance, sub-outsourcing notification, under Articles 28-30). A deeper, supplier-by-supplier contract and concentration-risk review is covered by the standalone Third-Party, Supplier & Cloud Risk service.

What happens if we don’t comply?

DORA requires each EU member state to set effective, proportionate and dissuasive administrative penalties and remedial measures (Article 50) - the actual monetary amounts are set at member-state level, not a fixed EU-wide percentage, and can include cease-and-desist orders, restrictions on practices, and public notice of the breach. The reputational and supervisory exposure tends to matter as much as the fine itself for a firm relying on financial-sector trust.

Standing up or maturing your operational resilience programme — identifying important business services, setting impact tolerances, mapping dependencies, and designing scenario testing, delivered directly by the person who does the work, not a delegated-down team. Built to give your board a governance model that holds up to scrutiny.

What to expect:

• Mobilisation — scope confirmed and workshops scheduled

• Current state review — existing resilience, incident and governance documentation reviewed

• IBS identification & impact tolerances — important business services agreed and impact tolerances set

• Dependency mapping & scenario testing — dependencies mapped and a severe-but-plausible test plan designed

• Governance design — resilience committee structure and operating model defined

• Roadmap & reporting — maturity assessment, implementation roadmap and executive readout

Typical duration: 6–8 weeks

What operational resilience requires

The UK's operational resilience regime (FCA PS21/3, PRA SS1/21) required in-scope firms to have this fully embedded by 31 March 2025 — the end of a three-year transition from the rules taking effect in March 2022. That deadline has now passed, which changes the nature of the gap: this is no longer "getting ready," it's "is it actually holding up." The regime requires:

• Identification of Important Business Services (IBS) — services that, if disrupted, could cause harm to consumers or market integrity.

• Impact tolerances set for each IBS — the maximum tolerable disruption, measured in time, volume, and consumer/market harm, not just a recovery-time target.

• Dependency mapping — the people, processes, technology, facilities and third parties each IBS actually depends on.

• Scenario testing against severe-but-plausible disruptions, to prove impact tolerances would genuinely be met, not just documented.

• Governance and board ownership of the whole programme, including a self-assessment document the board has actually reviewed and challenged.

For EU-scope entities, DORA (Regulation (EU) 2022/2554) requires the equivalent discipline under different terms — a documented ICT risk management framework (Chapter II, Articles 5–16) covering "critical or important functions," business continuity and disaster recovery policies (Article 11), and resilience testing (Chapter IV, Articles 24–27), approved and owned by the management body. The two regimes don't share identical vocabulary, but the underlying build — identify what matters, decide how much disruption you can tolerate, map the dependencies, test it, govern it — is the same shape, and the assessment approach transfers directly either way.

Is this for you?

This service is for firms in one of these situations:

• The March 2025 deadline has passed, but the programme lives more on paper than in practice — an IBS register that hasn't been touched since, testing that hasn't been repeated, a self-assessment the board signed off once and hasn't revisited.

• A DORA readiness assessment has flagged programme maturity as the real gap, not just article-by-article compliance — a common next step after a DORA Sprint.

• The firm is building this for the first time — a newer entrant, a firm growing into scope, or a business line expanding into an area that now counts as an important or critical function.

• A board or audit committee wants independent assurance that the resilience programme would actually hold up under scrutiny, not just pass a paper review.

In practice: banks, building societies and specialist lenders, insurers and MGAs, payment and e-money firms, and asset/investment managers — UK PRA/FCA-regulated firms primarily, and EU DORA-scope entities building the equivalent programme.

Frequently asked questions

How long does this take?

Around 6–8 weeks elapsed, across roughly 19.5 person-days of facilitation and design work. It runs longer than a DORA Sprint because it depends on scheduling workshops with business-line stakeholders, not just document review and interviews — the workshops are where the real work happens, and stakeholder time is the honest pace-setter.

We already have IBS and impact tolerances documented. Why would we need this?

Documented and embedded aren't the same thing. If the register hasn't been touched since the original deadline, testing hasn't been repeated, or the board hasn't actually challenged the assumptions behind it, this becomes a maturity review and rebuild rather than a from-scratch exercise — often faster as a result.

Does this replace a DORA Sprint?

No — they're complementary. A DORA Sprint (or equivalent readiness assessment) tells you where the gaps are against the regulation, article by article. This service builds or matures the programme itself. Many clients run a DORA Sprint first, then this.

What's delivered at the end?

An Important Business Services register, impact tolerance statements per IBS, dependency maps across people/process/technology/third-party, a severe-but-plausible scenario test plan, a governance and operating-model design, and a maturity assessment with an implementation roadmap.

Do you run the scenario tests for us?

This engagement designs the test plan — what to test, and how to prove impact tolerances actually hold. Running the tests themselves is a follow-on engagement, since it typically needs live operational involvement beyond a fixed-scope design piece.

What does it cost?

Scoped and quoted after a short call — there's no published price. A single-entity programme is typically around 19.5 days of work, fixed-fee with no open-ended billing. Get in touch and we'll confirm scope and cost together.

Independent second-line review and control assurance — objective, evidence-based reporting that gives boards and regulators confidence in how risk is actually managed, delivered by a practitioner who understands both the framework and the front line.

What to expect — Baseline Assurance Review:

• Mobilisation — scope and governance access confirmed

• Documentation & stakeholder review — programme documentation reviewed; sponsor, programme manager and workstream leads interviewed

• Assurance assessment — scope control, schedule realism, cost/benefit tracking, risk management, quality and governance assessed

• Reporting & readout — baseline assurance report with RAG rating, delivered as a board-ready executive readout

Optional: Periodic Assurance Cycle — once the baseline is complete, ongoing monthly or per-gate reviews are available: a document/gate review, stakeholder check-ins and an updated report with trend commentary each cycle, quoted separately on request.

Typical baseline duration: 2–3 weeks

Why independent programme assurance

Boards and audit committees increasingly expect independent challenge on major technology and transformation programmes — not because one specific rule mandates it, but because programme status reporting has a structural conflict of interest built in: the person telling the board "we're on track" is usually the person accountable for it being on track. That's not a dishonesty problem, it's a proximity problem, and it's exactly what an independent assurance function exists to correct.

This service is that independent view — assessed against a standard assurance framework (scope control, schedule realism, cost/benefit tracking, risk management, quality, benefits realisation, governance), delivered as either a one-off baseline review or an ongoing periodic cycle.

Is this for you?

This is for a programme that is:

• High-value or high-risk enough that the board or a risk committee wants independent assurance, not just the programme's own status reports.

• Showing signs of drift — schedule slippage, scope creep, or unclear benefits tracking — where an outside view can cut through internal politics.

• Subject to a governance requirement for independent assurance on major change, whether from an internal audit charter or a board risk committee mandate.

• Approaching, or has just passed, a major gate or funding decision, where the sponsor wants a clean-sheet check before committing further.

Typical buyers: Programme Sponsor, PMO Director, CIO/CTO, or a Board Risk Committee overseeing a major technology or transformation programme.

Frequently asked questions

How is this different from our own PMO reporting?

Independence. The programme manager and PMO have a natural interest in reporting progress positively — not through dishonesty, but through proximity. This assurance reports directly to the sponsor or board, separate from programme leadership, specifically so the answer isn't shaped by who's accountable for the outcome.

How long does the baseline review take?

Around 10 person-days, typically 2–3 weeks elapsed depending on document access and stakeholder availability for interviews.

What do we get at the end?

An assurance framework tailored to your programme, a baseline assurance report with a RAG rating, an executive/board-ready readout, and an escalation log for anything serious enough to flag outside the normal reporting cycle.

Do we have to commit to ongoing assurance?

No. The baseline review is a bounded, one-off engagement. A periodic assurance cycle (monthly, or per governance gate) is offered afterward, only once the baseline has shown its value — never sold as an open-ended retainer up front.

Does this cover technical or architecture quality?

No — this assesses governance, planning, risk management and delivery discipline, not solution design or technical architecture. A technical review can be scoped separately if that's what's needed.

What does it cost?

Scoped and quoted after a short call — there's no published price. A periodic assurance cycle, if taken up afterward, is quoted separately and scaled to fit the baseline review. Get in touch and we'll confirm scope and cost together.

Supplier risk frameworks, concentration risk assessment, contractual resilience reviews, and cloud readiness assessments for regulated workloads — scoped to your third-party estate and tailored to your regulatory obligations under DORA and beyond.

What to expect — Module A: Supplier/Third-Party Risk Framework

• Review of your existing third-party risk policy and register of ICT providers

• Stakeholder interviews with procurement, vendor management and risk

• Criticality tiering methodology designed and assessed against DORA third-party risk requirements

• Sample contract review against required contractual provisions, with framework and recommendations report

Module B: Cloud Concentration & Exit-Risk Assessment

• Cloud service inventory and dependency mapping

• Concentration risk analysis — hyperscaler dependency and single points of failure

• Exit strategy and substitutability assessment

• Cloud risk report, recommendations and executive readout

Typical duration: 5–6 weeks for both modules (3 weeks standalone)

What DORA requires

DORA's ICT third-party risk management provisions (Chapter V, Articles 28–44) are among the most prescriptive in the regulation. They require in-scope financial entities to:

• Maintain a register of information on all contractual arrangements with ICT third-party providers, identifying which ones support critical or important functions.

• Assess concentration risk before contracting with a new critical ICT provider, and monitor it on an ongoing basis.

• Include specific contractual provisions with every critical ICT provider — audit and access rights, exit assistance, sub-outsourcing notification, and clear service-level descriptions, among others required under Articles 28–30.

• Maintain an exit strategy for each critical ICT provider, so the firm isn't unable to leave if the relationship needs to end.

Cloud services are a specific focus area, since concentration in a small number of hyperscalers is exactly the kind of systemic dependency DORA's third-party provisions were written to surface.

Is this for you?

This is for any DORA-scope entity — banks, insurers, payment and e-money firms, investment and asset managers — that:

• Doesn't have a clean, current register of ICT third-party providers, or isn't confident which ones would count as critical.

• Has never formally assessed concentration risk across its cloud and critical-supplier estate.

• Is renewing or renegotiating contracts with critical ICT providers and needs to know what DORA requires be in them before signing.

• Needs a standalone cloud concentration and exit-risk view, separate from the broader supplier register work.

It's also relevant to UK-only firms without direct DORA exposure who want the same discipline applied under the UK's own operational resilience and outsourcing expectations — the assessment method transfers directly.

Frequently asked questions

Can we buy just the cloud piece, or just the supplier framework?

Yes — the two modules (supplier/third-party risk framework, and cloud concentration/exit-risk assessment) are sold independently or bundled. Module B (cloud) alone suits a firm that already has a supplier risk framework but hasn't specifically assessed cloud concentration.

How long does each module take?

Around 3 weeks elapsed per standalone module (10 days for the supplier framework, 8 days for the cloud assessment), or 5–6 weeks bundled.

We don't have an existing register of ICT third-party providers. Can you still help?

The engagement as scoped assumes a register exists to assess and improve. Building one from scratch is additional effort beyond the standard scope — flagged and agreed upfront on the kickoff call, not assumed.

What do you actually check in our contracts?

Contracts with critical providers are checked against the specific provisions DORA requires under Articles 28–30 — audit rights, exit assistance, sub-outsourcing notification, and service-level clarity. This is a gap review against those requirements, not a full legal contract redraft.

Does this replace legal advice?

No — the framework identifies what's contractually required and where the gaps are; drafting or renegotiating the actual contract language is a follow-on with your legal counsel.

What does it cost?

Scoped and quoted after a short call — there's no published price. Module A (supplier framework) and Module B (cloud concentration and exit-risk) are priced separately, with a discount when bundled. Get in touch and we'll confirm scope and cost together.

A practical readiness assessment against the EU AI Act - risk classification of your AI systems, a gap analysis against governance, transparency and documentation requirements, and a prioritised remediation roadmap. Scoped for regulated and technology firms preparing for phased compliance deadlines.

What to expect:

• Mobilisation — scope confirmed and systems/business units agreed

• AI inventory & classification — your AI systems identified and classified by EU AI Act risk tier

• Discovery — governance and data documentation reviewed, stakeholder interviews held

• Gap assessment — findings mapped against applicable obligations per risk tier

• Roadmap & reporting — prioritised remediation roadmap and full assessment report

• Close-out — review cycle and executive readout

Typical duration: 3–4 weeks

What the EU AI Act requires

The EU AI Act (Regulation (EU) 2024/1689) classifies AI systems into risk tiers and attaches different obligations to each:

• Prohibited practices (Article 5) — a short list of AI uses banned outright, including subliminal manipulation, social scoring, and certain biometric categorisation and real-time remote biometric identification uses. In force since 2 February 2025.

• High-risk systems (Chapter III, Article 6 and Annex III) — AI used in areas like employment, education, essential services, and biometrics. These carry the Act's heaviest obligations (Articles 8–21): a risk management system across the system's lifecycle, data governance, technical documentation, record-keeping, human oversight, accuracy/robustness/cybersecurity standards, and conformity assessment with CE marking before use.

• Limited-risk / transparency obligations (Article 50) — systems like chatbots and deepfake generators, which must make clear that a person is interacting with AI or AI-generated content. In force since 2 August 2026.

• General-purpose AI (GPAI) models (Chapter V) — documentation, copyright-policy and systemic-risk obligations for model providers, phased in from 2 August 2025 for new models, with existing models given until 2 August 2027 to catch up.

A note on timing, since this shifted recently: the original 2 August 2026 deadline for high-risk (Annex III) obligations has been pushed back. The Digital Omnibus (Regulation (EU) 2026/1744), which entered into force on 27 July 2026, extended the high-risk compliance deadline to 2 December 2027 — giving in-scope organisations more runway, but the classification and gap-assessment work is worth doing now rather than at the deadline, not less.

Is this for you?

This is for any organisation developing or deploying AI systems that:

• Doesn't have a clean, central inventory of AI systems in use — including tools individual teams or business units have adopted without central sign-off.

• Hasn't formally classified its AI systems against the Act's risk tiers, and can't say with confidence which, if any, are high-risk.

• Is preparing for the 2 December 2027 high-risk deadline and wants a head start rather than a scramble.

• Sits in financial services or another regulated sector already managing DORA, GDPR, or similar obligations, and wants AI Act readiness assessed with the same rigour rather than bolted on as an afterthought.

Typical buyers: CISO, Head of Technology Risk, Data Protection Officer, or Chief AI/Data Officer at a regulated entity deploying or developing AI systems.

Frequently asked questions

How long does an AI Act readiness assessment take?

Around 17.5 person-days over roughly 4–5 weeks, matched to the same shape as a DORA Sprint — inventory and classification, discovery, gap assessment, roadmap and reporting.

We're not using AI in anything "high-risk." Do we still need this?

Worth confirming rather than assuming — the Annex III high-risk categories (including employment decisions, credit scoring, and some biometric uses) catch more than people expect, and "shadow AI" adopted by individual teams is often the biggest classification blind spot. The inventory and classification phase exists precisely to answer that question with evidence, not a guess.

Does the extended deadline mean we can wait?

The 2 December 2027 deadline gives more runway, but the underlying work — knowing what AI you're actually using and how it's classified — doesn't get easier by waiting, and the prohibited-practice rules (Article 5) and GPAI obligations are already in force now. Firms that start the inventory and classification work early avoid a scramble later.

Can you help with genuinely ambiguous classification calls?

The assessment flags genuinely ambiguous cases clearly rather than resolving them unilaterally — those are noted as needing legal input, since a classification dispute is ultimately a legal question.

What happens if we don't comply?

Article 99 sets three penalty tiers: up to €35m or 7% of global annual turnover (whichever is higher) for prohibited-practice violations; up to €15m or 3% for most other non-compliance; and up to €7.5m or 1% for supplying incorrect information to authorities. SMEs get the lower of the amount or percentage in each tier.

What does it cost, and how does it pair with DORA work?

Scoped and quoted after a short call, tailored to your AI inventory and risk profile — there's no published price. It's structured to match the DORA Sprint, so a firm facing both regulations can run them as a paired "regulatory readiness sprint" rather than two disconnected engagements. Get in touch and we'll confirm scope and cost together.