Skip to content
HackingByte Book a scoping call

DORA isn’t a compliance project. It’s operational resilience under inspection.

Practical DORA readiness — gap analysis, ICT third-party register, incident reporting, and resilience testing — for financial entities and their critical ICT providers.

Book a scoping call See how we work
  • Senior-led delivery.
  • No tools sold.
  • Evidence-driven reporting.

A lot of DORA compliance work treats the regulation like a checklist — a binder of policies that satisfies an internal review and falls apart the first time a supervisor asks a hard question. DORA isn’t built for that. It’s an operational-resilience regulation with teeth: supervisors can inspect, your critical ICT providers are in scope, and “we have a policy” is not the same as “we could keep running through an incident and prove it afterwards.”

HackingByte’s DORA readiness gets financial entities and their critical ICT third-party providers to a defensible position — gap analysis against the regulation and its technical standards, an ICT third-party register that’s actually complete, incident classification and reporting that works under the clock, and resilience testing that maps to what supervisors expect. To be clear about scope: this is practical readiness consulting, not legal interpretation. We don’t give legal opinions on the regulation or renegotiate your contracts — where you need that, we work alongside your counsel and lawyers.

DORA readiness.

DORA readiness, across all five requirement areas.

  • ICT risk management.

    The foundation: a governance and risk-management framework for your ICT, owned at board level, not buried in IT. We review your existing framework against DORA and its regulatory technical standards, find where governance, asset management, or risk treatment fall short, and give you a prioritized path to close the gaps. The test isn’t whether a document exists — it’s whether the framework would hold up when a supervisor traces a real risk through it.

  • ICT-related incident management and reporting.

    DORA sets specific expectations for classifying ICT incidents and reporting major ones to your competent authority on a defined timeline. We build the classification logic and the reporting workflow so that when something happens, your team knows whether it’s reportable, on what clock, and to whom — instead of working it out under pressure. This is where readiness either pays off or doesn’t.

  • Digital operational resilience testing.

    DORA requires a testing programme proportionate to your size and risk — and for significant entities, threat-led penetration testing (TLPT) aligned to the TIBER-EU framework and the DORA TLPT regulatory technical standards. We design the testing programme, and where TLPT applies we run it: intelligence-driven, regulator-aligned, and reported in a structure suitable for supervisory submission. (See penetration testing for the threat-led testing itself.)

  • ICT third-party risk management.

    The area most entities underestimate. DORA expects a complete register of your ICT third-party arrangements, contractual terms that meet specific requirements, and oversight of your critical providers. We build out the ICT third-party register against reality, review your contract clauses against what DORA requires, and flag the dependencies that would actually hurt if a provider failed. Sound ICT third-party risk management is also what your own financial-entity customers will demand if you are the critical provider.

  • Information sharing and applicability.

    DORA encourages threat-intelligence sharing among financial entities, and — crucially — it doesn’t apply to everyone the same way. Before any of the above, we run an applicability and classification assessment: does DORA apply to you, are you a “significant” entity for testing purposes, and are any of your providers critical ICT third parties? Scoping the regulation correctly is the difference between a proportionate programme and a wasted one.

Whether you’re a bank, insurer, asset manager, payment or e-money institution, crypto-asset service provider — or a critical ICT provider serving them — we scope the work to your classification, not a generic template.

Resilience under inspection, not policies on a shelf.

The cheap version of DORA readiness produces documents. The useful version produces a programme that would actually hold if a supervisor inspected it or an incident tested it — and those are not the same deliverable. HackingByte is a security firm first, so we read DORA through an operational lens. When we review your ICT risk framework, we’re asking whether the controls would survive contact with a real disruption, not just whether they’re written down. When we build your third-party register, we’re asking which dependency would genuinely take you offline. And where DORA calls for threat-led testing, we don’t subcontract it or treat it as a tick-box — adversary-simulation testing is core to what we do, and we run it to the standard supervisors expect. <strong>We’re also clear about the boundary.</strong> We deliver practical readiness — gap analysis, registers, workflows, testing, and remediation plans. We don’t write legal opinions on how the regulation should be interpreted, we don’t renegotiate your provider contracts for you, and we don’t implement new infrastructure. Where you need legal interpretation or contract negotiation, that’s your counsel’s work, and we’ll support it rather than pretend to replace it.

How we work.

A six-stage lifecycle worked to DORA and its technical standards.

We work to DORA itself — the Regulation and its regulatory and implementing technical standards — alongside the relevant EBA, ESMA, and EIOPA guidance, and we tell you the basis before we start. The engagement runs on HackingByte’s six-stage lifecycle.

Scoping. We run the applicability and classification assessment, agree which of the five areas are in scope, set deliverables, and fix a price — ending in a signed Statement of Work.

Kickoff. We confirm contacts across risk, IT, procurement, and the board, plus access to the people who know how your ICT and your providers actually operate.

Execution. Gap analysis, third-party register build-out, contract-clause review, incident-reporting workflow design, and operational-resilience exercise design — scoped to your classification. Where threat-led testing is in scope, it adds an intelligence and scenario-design stage up front.

Reporting. We produce the DORA readiness pack and the Three-Artifact Model, peer-reviewed before you see them.

Debrief. A working session with the people who’ll own remediation, plus a board-ready readout — because DORA accountability sits with the management body.

Closure and ongoing support. The remediation plan goes to its owners; many entities keep us on through the remediation window or for the recurring testing programme.

DORA overlaps heavily with NIS 2 and ISO 27001, so where you’ve done that work — or need it — the evidence is reused rather than rebuilt, inside our broader GRC advisory practice. Full lifecycle detail is on our methodology page.

See how we work

What you get.

Concrete artifacts that hold up under inspection.

Concrete artifacts that hold up under inspection, not a policy folder:

  • DORA readiness pack — the gap analysis against the regulation and its technical standards, with a prioritized remediation plan.
  • ICT third-party register — built or completed against your real arrangements, with the critical-provider dependencies and contractual gaps flagged.
  • Incident classification and reporting workflow — so a major ICT incident gets classified and reported on the right clock, to the right authority.
  • Tabletop exercise output — evidence that your team has actually run the resilience scenario, not just documented it.

Timeline and pricing.

A DORA readiness engagement typically runs two to six months end to end, depending on the size of the entity, the maturity of your existing ICT risk framework, and the size of your third-party footprint. A focused applicability assessment or a third-party register build is faster; a full readiness programme across all five areas for a complex group takes longer. Where threat-led testing is in scope, that runs as its own workstream alongside.

Pricing is fixed, banded by entity size and third-party footprint, with the band shared during scoping before you sign — no day rates and no open-ended hours. We don’t run free pilots; the scoping call is free, and everything past it is a defined, paid engagement. If you’re working to a supervisory deadline or an application date, tell us during scoping and we’ll be straight about what’s achievable in the time, and what should come first.

When teams call us.

The most common moments financial entities and ICT providers bring us in for DORA:

  • An application or supervisory deadline approaching with the programme not yet defensible.

  • A supervisory inspection scheduled or signalled.

  • Designation — or the risk of designation — as a critical ICT third-party provider.

  • A new ICT outsourcing arrangement that changes the third-party picture.

  • A sector incident driving fresh supervisory focus.

  • A financial-entity customer demanding DORA evidence before they’ll keep using you as a provider.

Frequently asked questions

Does DORA apply to us?
It applies to a broad set of financial entities and to their critical ICT third-party providers. We start every engagement with an applicability and classification assessment so you know exactly where you stand before committing to a programme.
Is this legal advice?
No. We provide practical DORA readiness consulting — gap analysis, registers, workflows, testing, and remediation plans. We don’t give legal opinions on how the regulation should be interpreted, and we don’t renegotiate your contracts. Where you need that, we work alongside your counsel.
What does DORA actually require?
Five areas: ICT risk management, ICT-related incident management and reporting, digital operational resilience testing, ICT third-party risk management, and information sharing. We work each to a defensible state.
Do you run the threat-led penetration testing (TLPT)?
Yes. Where DORA’s testing requirements apply to you as a significant entity, we run threat-led testing aligned to TIBER-EU and the DORA TLPT technical standards, reported for supervisory submission.
What does it cost?
Fixed, banded by entity size and third-party footprint, with the band shared during scoping before you commit. We don’t quote day rates.
How long does it take?
Typically two to six months depending on your size, maturity, and third-party footprint. We set the schedule around your supervisory deadline.
We’re an ICT provider, not a financial entity — is DORA relevant to us?
Yes, if you’re a critical ICT third-party provider to financial entities. We help you build the register evidence, meet the contractual requirements, and give your financial-entity customers the assurance they now have to ask for.
How does DORA relate to NIS 2 and ISO 27001?
They overlap substantially on ICT risk and resilience controls. Where you’ve done — or need — that work, we reuse the evidence across frameworks rather than rebuilding it.

Related services

Most engagements pair with one of the routes below — each is a senior-led, fixed-scope, evidence-first programme that follows the same reporting model.

Tell us your entity type and your deadline, and we’ll scope the DORA work — and the testing — around both.

Book a scoping call