DORA internal audit of the ICT framework: what it requires

What DORA internal audit of the ICT framework requires and who does it

Article 6(6) and (7) of DORA require every financial entity other than a microenterprise to have its ICT risk management framework internally audited on a regular basis, by auditors with sufficient ICT risk expertise and independence. All entities, including microenterprises, must run a formal follow-up process that verifies and remediates critical ICT audit findings in a timely way. The audit function belongs to the organization. It must sit apart from the teams that run ICT risk management, under the three lines of defence model or an internal risk management and control model that Article 6(4) describes, so the people who build and operate controls do not also certify them.

A partner can help the organization prepare for this work by mapping the framework to the audit universe, assembling control evidence, documenting response and recovery plans for review and tracking remediation of findings. A partner cannot issue the audit opinion, and nothing in DORA provides for an authority-issued certificate of internal audit. The internal audit function, or an external auditor it engages, produces the findings and the conclusion. Article 6(10) allows some verification work to be outsourced to intra-group or external undertakings, but the entity remains fully responsible for it, so any contract should make clear who performs each task and who signs off the result.

Cost and effort depend on the entity's size, the number and complexity of its ICT services, the maturity of its existing evidence and how much audit capability is built in-house versus bought in. No supplied fact gives a price or duration for this work, so do not budget from a generic figure. Ask any provider for a fixed-scope proposal that separates preparation work from the audit itself, states which artefacts it will deliver, names the people who will perform each task, and explains how remediation of critical findings will be tracked. Confirm with your competent authority which audit expectations apply to your entity type and whether you fall under the simplified regime.

How independence and ICT expertise are set up

Article 6(4) of DORA requires entities other than microenterprises to separate ICT risk management, control and internal audit. The cards below show how those roles fit together, who approves the audit plan, and where outside auditors can help without moving responsibility away from the entity.

First line: ICT operations owners

The first line is the staff who run systems, change configurations and operate services day to day. They own the ICT risks in their area and apply the controls the framework sets. For internal audit, the question is whether these owners keep records that auditors can test, such as asset records, access approvals and change logs. Check that the first line cannot approve its own exceptions to controls it operates.

Second line: independent control function

Article 6(4) requires a control function with appropriate independence to be assigned responsibility for managing and overseeing ICT risk. This function sets risk criteria, challenges the first line and reports to the management body. Confirm its reporting line does not run through the people whose work it reviews, and that it has the staff and access it needs to test controls rather than only collect self-assessments.

Third line: internal audit with ICT expertise

Internal audit provides independent assurance on the ICT risk management framework. Article 6(6) requires auditors with sufficient ICT risk expertise and independence, so a generalist audit team may need specialist ICT auditors or co-sourced support. Check that the audit function does not design the controls it later tests and that its findings go directly to the management body or its audit committee.

Audit plan approval by the management body

Article 5(2) requires the management body to approve and periodically review the ICT internal audit plans. Approval makes the audit scope a board decision, covering which systems, ICT services supporting critical or important functions, and response and recovery plans are reviewed each cycle. Ask for minutes showing the board reviewed the plan, the risks that shaped it, and any scope it declined to cover.

External auditors under Article 6(10)

Article 6(10) allows verification of compliance with ICT risk management requirements to be outsourced to intra-group or external undertakings. The entity stays fully responsible for that verification, so it must set the scope, review the working papers and decide what to act on. Contract for access to evidence, independence declarations and a clear way to escalate findings. An implementation partner can prepare systems and evidence for this work, but it does not replace the auditor.

How the internal audit cycle runs from plan to follow-up

The sequence turns an approved audit plan into tested evidence on the ICT risk management framework, then into tracked remediation and verified closure of critical findings. Each phase hands a defined output to the next so the board and supervisors can see what was checked and what changed.

Approve the internal audit plan at management body level
The management body approves the ICT internal audit plan and reviews it periodically, as Article 5(2) of DORA requires. The plan lists the ICT risk management framework areas, the ICT response and recovery plans, and the ICT services supporting critical or important functions that will be audited in the period. The audit function or its head prepares the draft, and the board minute records the approval. The output is a signed-off plan with named owners for each area and a record of the board's decision.
Scope the framework and critical ICT services
Before fieldwork, the audit team defines what is in scope for each engagement. This covers the ICT risk management framework controls, the asset inventory and the ICT services that support critical or important functions, which Article 3(7) requires to be independently reviewed and included in the audit plan. The team also confirms which contracts with ICT third-party providers fall within scope and whether the entity is a microenterprise, since the audit obligations under Article 6 do not apply to microenterprises. The output is a written scope memo that names the systems, controls, providers and evidence sources to be tested.
Test controls and response and recovery plans in fieldwork
Auditors with sufficient ICT risk expertise test the design and operation of the controls in scope. For response and recovery plans, the review follows Article 11(3), which requires independent internal audit review, and checks the business impact analysis required by Article 11(5). Testing draws on configuration records, access reviews, incident logs, test results and contract clauses, and auditors record what they sampled and why. Where the organization uses an external reviewer to verify compliance, Article 6(10) allows that outsourcing, but the entity stays fully responsible for the outcome. The output is a set of workpapers that link each test to its evidence and to a rated result.
Report findings to the management body
The audit function issues a report that states each finding, its evidence, its risk rating and the recommended action. Findings are discussed with the control owners before issue so that factual errors are corrected. The report goes to the management body and the relevant committee, which keeps the board informed of the state of the framework as its oversight duties require. Critical findings are flagged separately so they enter the follow-up process without waiting for the next cycle. The output is an issued audit report with an agreed action plan and a named owner and status for each finding.
Track remediation of critical findings
Article 6(7) requires every entity to run a formal follow-up process that verifies and remediates critical ICT audit findings in a timely way. Each critical finding is logged in a tracker with its owner, the agreed fix, the evidence expected at closure and the escalation path if the date slips. The control function and the management body receive status updates so that overdue items are visible at board level. Owners cannot close a finding on their own statement alone. The output is a current register of open critical findings with status and escalations recorded.
Verify closure before a finding is retired
Audit independent from the control owner re-tests each remediated finding against the evidence agreed at the start of remediation. Verification confirms that the fix works in production and not only in documentation, and the auditor records the result in the workpapers. A finding closes only when verification passes, and failed verifications return to the tracker with the reason stated. Closed findings feed the next audit plan, so repeated weaknesses can shape future scope. The output is a closure record for each finding and an updated view of open exposure for the next report to the management body.

What applies to smaller entities and microenterprises

Microenterprises are the one group for which the internal audit requirements of DORA do not apply in the same way. Article 6(4) (the control function and the segregation of ICT risk management, control and internal audit under the three lines of defence model) and Article 6(6) (regular internal audit of the framework by auditors with ICT risk expertise and independence) are not imposed on them. A microenterprise still has to manage ICT risk under Chapter II, and it still answers to its competent authority for that management, so an absence of formal audit is not an absence of duties.

Exemption scope: the exemption covers the specific audit and segregation duties in Article 6, not the wider ICT risk management obligations.
Proportionate substitute: many microenterprises use an external reviewer or a periodic self-assessment, but this is a choice, not a requirement, and it should be documented as such.
Incident and continuity duties remain: reporting, response and recovery planning still apply, so the plans still need to be tested and kept current.
Outsourcing verification: if you rely on a provider, Article 6(10) still applies to any verification you outsource, and you stay responsible for it.
Growth triggers: a firm that grows past the microenterprise definition must plan its audit function before the change takes effect.

Confirm with your competent authority whether your entity is a microenterprise under the Regulation's definition and whether any national guidance adds expectations.

What internal audit of the framework costs and who is paid

This table compares each cost component of auditing the DORA ICT risk management framework, who is paid for it, whether it is one-time or recurring, and what drives it up. No price is given here, because a quote follows a written scope agreed before work starts. Use the table to build the scope you send to bidders and to check that every component is priced.

Cost component	Who is paid	One-time or recurring	What drives it
Internal audit staff time	The entity's own internal audit function (salaried staff or time charged internally)	Recurring, each audit cycle	Size of the ICT estate, number of critical or important functions in scope, and whether auditors hold sufficient ICT risk expertise
External ICT-skilled auditors	Independent external firm, if the entity outsources part of the audit	Recurring, usually per audit engagement	Breadth of the audit plan, depth of technical testing, and how much the internal team can cover with its own skills
Implementation partner work on evidence and plans	Implementation partner, under a fixed-scope agreement	One-time for initial preparation, then recurring for updates	Number of response and recovery plans, state of existing logs and records, and how much documentation must be rebuilt
Audit findings tracking tooling	Software vendor or hosting provider, or internal platform team	Recurring licence or hosting, plus one-time setup	Number of findings, integration with ticketing and asset records, and whether the tool is self-hosted inside the entity's own environment
Remediation of critical findings	Internal engineering teams, or an implementation partner for technical fixes	One-time per finding, with recurring verification	Severity and count of findings, architecture changes needed, and time available before follow-up verification
Follow-up verification and re-testing	Internal audit, or an external assessor if independence requires it	Recurring, after each remediation cycle	Number of closed findings that need evidence review and whether retests are needed to confirm the fix
Management body reporting and sign-off	Internal time of management body and control functions	Recurring, at least yearly for audit plan approval	Frequency of board meetings, depth of reporting, and the need to explain audit results to supervisors

What must be in place before the audit starts

DORA internal audit assumes a framework that already exists on paper and in practice. The items below are what an auditor will look for first, and each one can be checked before the audit fieldwork begins.

An approved audit plan covering the ICT framework

Article 6(6) expects the ICT risk management framework to be audited on a regular basis, and Article 5(2) makes the management body responsible for approving ICT internal audit plans. Check that the plan names the framework areas in scope, the ICT systems and ICT services that support critical or important functions, the auditors and their dates, and the record of management body approval. Under Article 3(7), ICT services supporting critical or important functions must also be included in the plan, so confirm they appear by name rather than under a general heading.

Documented response and recovery plans with BIA results

Article 11 requires ICT response and recovery plans, and for entities other than microenterprises these plans are subject to independent internal audit review. The plans need a business impact analysis of exposure to severe business disruptions, using quantitative and qualitative criteria and scenario analysis under Article 11(5). Check that each plan links to a BIA result, that the recovery objectives in the plan match the BIA, and that the plan shows a version date and an approver.

A findings register with owners and dates

Article 6(7) requires a formal follow-up process for the timely verification and remediation of critical ICT audit findings, applicable to all entities. The register should record each finding, its severity, a named owner, a remediation due date, the evidence used to close it, and who verified the closure. Check whether prior-cycle findings are still open, whether any critical finding has passed its due date without a documented decision, and whether closure evidence was reviewed by someone other than the owner.

Evidence of management body review

Under Article 5(2), the management body bears ultimate responsibility for ICT risk and must approve and periodically review the ICT business continuity policy, response and recovery plans, and ICT internal audit plans. An auditor will look for minutes or written resolutions showing that these were reviewed, what the board questioned, and what it asked management to change. Check that the review dates fall within the period under audit and that the minutes name the documents reviewed, not only the agenda item.

A current asset inventory and third-party list

Auditors test the scope of an internal audit against what the entity actually runs, so the asset inventory and the register of ICT third-party arrangements must be current before fieldwork. Check that the inventory covers the systems in the response and recovery plans, that each record shows its business function and dependencies, and that the third-party list identifies which providers support critical or important functions. Any gap between the inventory and the audit plan should be resolved or documented before the audit starts.

Questions buyers ask about DORA internal audit

Can our organization audit its own ICT risk management framework?

Only if the auditors are independent of the people who run the framework. Article 6(4) requires the ICT risk management, control and internal audit functions to be segregated under the three lines of defence model or an internal risk management and control model, and Article 6(6) requires regular internal audits by auditors with sufficient ICT risk expertise and independence. A team that operates the controls cannot audit them and sign off its own work. In practice, the question is whether your internal audit function has staff with real ICT depth and a reporting line that bypasses the people being audited. If it does not, you need to add that capability internally or buy it in. Confirm the exact requirements for your entity type with your competent authority, since the simplified regime for smaller entities sets its own expectations.

Can we use external auditors under DORA Article 6(10)?

Yes. Article 6(10) allows verification of compliance with ICT risk management requirements to be outsourced to intra-group or external undertakings. The outsourcing does not transfer responsibility. Your management body remains fully accountable for the outcome, so you need to set the scope, review the methodology, receive the findings and decide on remediation. When choosing an external auditor, check that the firm has demonstrable ICT audit expertise, that its people are independent of the teams that built or operate your systems, and that the contract gives you access to working papers and findings. Ask who will sign the engagement and how conflicts of interest are handled. If the auditor also helped design the framework, independence is weakened and your competent authority may question the result.

How much effort does a DORA internal audit need from our internal staff?

The effort depends mainly on how well documented your framework is, how many critical or important functions it covers and how many ICT third-party services it depends on. Internal staff are needed to provide policies, the asset inventory, risk assessments, incident records, test results, continuity plans and evidence of management body approvals. The more these artefacts are current and traceable, the less time auditors spend reconstructing them. Staff also need to answer interviews, confirm ownership of controls and review draft findings for accuracy. Ask any auditor or partner for a written list of evidence requests and interview roles before the engagement starts, so you can plan staff time. Effort figures should come from the agreed scope, not from generic estimates.

What can a DORA implementation partner do for internal audit, and what can it not do?

A partner can prepare the audit readiness of your systems and evidence. That includes mapping existing controls to the framework, organizing evidence for audit, documenting remediation of earlier findings, and helping build the internal audit plan and its test procedures. DeployOpen, for example, can plan and document these items in a fixed scope agreed in writing. A partner cannot act as the independent auditor. It cannot issue audit reports, attestations or certifications, and it should not perform the audit of work it helped build, because that breaks the independence Article 6 requires. Keep the roles separate in your contract: the organization owns the controls, the partner prepares systems and evidence, and the independent auditor tests and reports.

How must DORA audit findings be followed up?

Article 6(7) requires every entity to run a formal follow-up process that verifies timely remediation of critical ICT audit findings. Each finding should be logged with an owner, a severity rating, a remediation plan with a target date and a verification step performed by someone other than the remediation owner. Critical findings need escalation to the management body, which must also approve the internal audit plan under Article 5(2). For entities under the simplified regime, Article 28 of Delegated Regulation (EU) 2024/1774 requires critical audit findings to be remediated in time. Keep closure evidence, such as retest results or configuration exports, so that a supervisor can trace each finding from report to closure.

What does DORA internal audit require for microenterprises?

Microenterprises are exempt from several Article 6 duties, including the requirement to have the framework internally audited on a regular basis and the segregation of ICT risk management and internal audit functions. This exemption does not remove the need for sound ICT risk management, which still applies in proportion to your size and risk profile under Article 4. Confirm your classification with your competent authority, because the exemption depends on the microenterprise definition and may change if your size or activities change. Smaller entities that are not microenterprises fall under the simplified regime and should check the requirements in Delegated Regulation (EU) 2024/1774 rather than assuming they are exempt.

How should we scope the first DORA internal audit?

Start with the parts of the framework that carry the most risk: critical or important functions, ICT services that support them and the response and recovery plans. Article 11(3) requires independent internal audit reviews of those plans for entities other than microenterprises, and Article 3(7) requires ICT services supporting critical or important functions to be reviewed independently and included in the audit plan. Define the scope in writing: which entities, systems, providers and documents are covered, which period is tested and what the auditor will and will not assess. Agree the methodology, evidence list and reporting format before fieldwork. A narrow first scope with clear criteria is usually easier to defend to a supervisor than a broad scope that is only partly tested.

How DeployOpen prepares systems and evidence for the audit

DeployOpen helps financial entities prepare the systems, records and evidence that their internal auditors will test against the ICT risk management framework. We plan and build the work inside your own infrastructure, and the audit itself stays with your internal audit function, which owns the opinion and the findings.

How we scope

Engagements are fixed-scope, with the framework areas, systems and audit evidence agreed in writing before work starts.
We map which ICT systems support critical or important functions so the audit plan covers them in the agreed scope.
The written scope names the people who own each control, so internal audit knows who to ask for each record.

How we build

We configure logging, access records, change histories and backup evidence on self-hosted open-source platforms in your environment.
We prepare response and recovery plans and business impact analysis records so internal audit can review them as written documents.
We help set up a tracked register for audit findings, owners and remediation dates so critical findings follow a formal process.

How we hand over

We document configurations, evidence locations and control owners in a handover pack your internal auditors can follow independently.
We provide the remediation record for each finding we fixed, showing what changed, when and who approved it.
We confirm with your audit function which evidence it will accept before handover, so gaps surface while there is time to close them.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the initial engagement ends.
Retainers can keep audit evidence current between annual internal audit cycles, including after major ICT changes.
Confirm with us in writing which audit activities sit outside our scope, such as the audit opinion and independence decisions.

DORA internal audit of the ICT risk management framework