DORA Audits: Prepare Without Delaying Growth

A DORA audit rarely fails because a business has no security tools. It fails because management cannot demonstrate who owns ICT risk, how critical suppliers are controlled, what happened during an incident, and whether identified weaknesses were actually closed. For payment firms, EMIs, fintechs and crypto-asset service providers, DORA audits are now a practical test of whether growth has been built on a controllable operating model.

The Digital Operational Resilience Act has applied since 17 January 2025. It creates a directly applicable EU framework for digital operational resilience across much of the financial sector, including payment institutions, electronic money institutions, investment firms, credit institutions, insurers and crypto-asset service providers. It also changes the expectations placed on ICT suppliers serving those businesses.

For an executive team, the immediate question is not whether DORA creates more documents. It does. The real question is whether the business can produce credible evidence that its people, technology, outsourced services and incident response arrangements work together under pressure.

What a DORA audit is actually testing

DORA does not prescribe one universal annual external audit with a single fixed checklist. The required assurance activity depends on the entity’s size, risk profile, governance arrangements and the applicable supervisory expectations. However, financial entities must establish and maintain an ICT risk-management framework, subject it to periodic review, and ensure independent assurance through internal audit or another appropriately independent function.

A DORA audit may therefore take several forms: an internal audit against the DORA framework, a pre-supervisory gap assessment, a review commissioned by a board or investor, or evidence gathering in response to a regulator, banking partner or institutional client. The label matters less than the standard of proof.

The reviewer will usually look beyond written policies. A policy saying that suppliers are assessed annually has little value if there is no current register, no completed assessment, no risk rating, and no record of management decisions. Equally, an incident response plan is not persuasive if the organisation cannot show that it has been tested, that lessons were recorded and that corrective actions were assigned.

For fast-growing firms, this distinction is critical. A compliance framework drafted during licensing can become outdated quickly after a cloud migration, new outsourcing arrangement, acquisition or entry into another EU market.

The five areas that create most DORA audit findings

ICT governance and clear accountability

DORA puts responsibility at management-body level. The board or equivalent governing body cannot delegate away accountability for ICT risk. It must approve, oversee and periodically review the ICT risk-management framework, while ensuring staff have suitable knowledge and training.

In practice, auditors look for a credible division of responsibility between the board, senior management, compliance, risk, information security and operational teams. Common weaknesses include vague committee minutes, no defined risk appetite for ICT disruption, and security decisions made informally by a technology lead without proper escalation.

Smaller businesses do not need to imitate a bank’s committee structure. They do need a proportionate model that identifies decision-makers, reporting lines, review dates and escalation thresholds. Proportionality reduces unnecessary process. It does not remove the requirement to govern ICT risk.

ICT asset, risk and change management

You cannot manage a system you cannot identify. An audit should establish whether the business maintains a current inventory of ICT assets, applications, data flows, interfaces and critical dependencies. That includes software-as-a-service tools, customer onboarding providers, blockchain analytics vendors, payment processors and cloud infrastructure.

The practical failure is often not a missing asset register. It is a register disconnected from risk assessments, business continuity planning and supplier records. If a core vendor fails, the firm should be able to identify affected services, customer impact, alternative arrangements and the executive responsible for the response.

Change management requires similar discipline. Rapid product releases are commercially valuable, particularly for payment and virtual asset businesses. But material changes should be assessed, approved, tested and traceable. Emergency changes need a defined route rather than an informal exception that is never reviewed.

ICT third-party risk management

Outsourcing is where DORA becomes commercially demanding. A business remains accountable for ICT risk even when critical technology is delivered by a major global provider. Contracts, onboarding checks and ongoing supplier oversight must reflect that reality.

The audit trail should show which providers support critical or important functions, how they were selected, what risks they present, where data is processed, whether subcontracting is controlled, and how the arrangement can be exited. A contract that contains general confidentiality and service-level wording may be legally sound in a broad sense but still fall short of DORA expectations.

For critical arrangements, businesses should address audit and access rights, security requirements, incident notification, data location, business continuity, termination support and subcontracting controls. The exact clauses depend on the service and risk profile. Overly aggressive contractual demands may be unrealistic when dealing with hyperscale cloud providers, so the legal position must be paired with a workable control strategy and documented management acceptance of residual risk.

Incident management and regulatory reporting

DORA requires firms to manage, classify and report major ICT-related incidents. Auditors will test whether the business can distinguish a routine operational issue from an incident requiring escalation, investigation or regulatory notification.

This is not simply a cyber security exercise. A prolonged outage at a payment processor, corrupted customer data, failed identity-verification integration or compromise at an outsourced hosting provider can all create DORA issues. The organisation needs a defined classification methodology, reporting workflow, evidence retention process and communication plan.

The most revealing evidence is generated during a real event. Incident logs, timelines, internal decisions, customer communications and post-incident reviews show whether the framework works outside a policy document. Businesses should avoid retrospectively recreating records. That approach creates a credibility problem far greater than an openly identified control gap.

Resilience testing and remediation

DORA expects digital operational resilience testing that is proportionate to the business. For many firms, this means regular vulnerability assessments, scenario testing, backup and recovery checks, and testing of business continuity and disaster recovery arrangements. Certain entities may face more advanced requirements, including threat-led penetration testing.

A frequent weakness is treating a successful technical test as the end point. The audit question is whether the firm recorded findings, assessed their business significance, allocated owners and deadlines, verified closure, and reported material issues to management. Remediation governance turns testing from a technical exercise into a compliance control.

How to prepare for a DORA audit without building unnecessary bureaucracy

Start by defining the legal perimeter. A UK-headquartered group is not automatically outside DORA if it operates an EU-regulated subsidiary or branch, provides services through an EU-authorised entity, or relies on group-level systems supporting an EU financial entity. The relevant regulated entity, its ICT dependencies and its cross-border arrangements must be mapped carefully.

Next, conduct an evidence-led gap assessment rather than a policy-only review. Test what can be produced now: management approvals, risk registers, supplier assessments, contracts, incident records, test results, training logs, audit reports and remediation trackers. Missing evidence often reveals either a control failure or an inability to prove that a control exists. Both need attention.

Then prioritise gaps according to regulatory and operational exposure. A missing version date on a low-risk policy should not delay remediation of absent exit planning for a cloud provider supporting customer transactions. Board-level reporting should make these choices visible, including accepted risks and target completion dates.

Finally, create a sustainable review cycle. DORA compliance is not a one-off project completed before a licensing application, funding round or supervisory meeting. Supplier inventories change, systems are replaced, risks evolve and incidents expose new weaknesses. The best audit preparation is a control environment that produces evidence as part of ordinary operations.

Where legal and operational work must meet

DORA cannot be delivered by legal, compliance or technology teams in isolation. Legal teams can translate regulatory obligations into governance documents and enforceable supplier terms. Technology and security teams supply the operational facts, testing and records. Management makes the risk decisions and commits resources.

That coordination becomes especially important where a firm is preparing a MiCA authorisation, acquiring a regulated entity or entering a new payments market. A regulator may view weak operational resilience as evidence that the wider governance model is immature. Addressing DORA late can therefore slow an otherwise well-prepared route to market.

NUR Legal supports regulated businesses with DORA-aligned audit preparation, documentation and remediation planning designed around the actual operating model, not a generic compliance pack. The objective is clear evidence, accountable ownership and a programme that can withstand regulator scrutiny without obstructing commercial delivery.

A useful first step is to ask one direct question: if a critical ICT provider failed this afternoon, could your board show who would act, what customers would experience, which regulator obligations may arise, and where the supporting evidence sits? The answer will usually identify the right starting point for your DORA programme.