Remediating DORA test findings: what the rules require

How DORA test findings must be remediated and who pays for it

Article 24(5) of DORA requires financial entities to have procedures that prioritise, classify and remedy all issues revealed by testing and internal validation, and to confirm that every identified weakness, deficiency or gap is fully addressed. If a test has produced findings and your board or supervisor wants proof of remediation, the question is no longer whether the findings were logged but whether you can show, finding by finding, what was fixed, who verified it and when. The financial entity owns that remediation. Its management body approves the priorities, accepts any residual risk and signs off closure. An implementation partner can change configurations, harden systems, patch code and assemble the evidence, but only the competent authority or an independent assessor can judge whether the response is adequate.

Cost and effort depend on three things: the number and severity of findings, the systems involved and whether any finding touches an ICT third-party provider. A handful of medium findings on one internet-facing application is a bounded piece of work. Findings that sit in shared identity, logging or backup services, or that depend on a provider's own patch cycle, take longer and may need contract changes or provider cooperation before they can close. Ask any partner for a quote that lists each finding or finding group, the fix, who performs the retest, and the evidence delivered at closure. Separate one-time remediation from recurring work such as revalidation at the next test cycle, and confirm whether the partner's retest is included or billed as a new engagement.

Before you commission work, check three things with your team and your competent authority's expectations. Confirm which findings are in scope for the remediation plan and which are accepted risks, because accepted risks need a documented decision by the management body. Confirm the deadlines your own procedures set for each severity class. Confirm how much of the evidence your assessor will expect to see, such as before-and-after test output, change records and a retest by someone independent of the fix. Where a finding relates to the threat-led testing regime, the remediation timetable follows the reporting deadlines in Article 12 and is covered separately in this guide.

What DORA requires after a test

DORA does not stop at testing. Four separate provisions require the organization to fix what tests and audits reveal, confirm the fixes worked, and carry lessons into risk decisions and board reporting. Each card names the provision, what it asks for and what an assessor will look for.

Prioritise, classify and remedy all issues

Article 24(5) requires procedures that prioritise, classify and remedy every issue revealed by testing and internal validation, and confirm that each weakness, deficiency or gap is fully addressed. This covers findings from penetration tests and vulnerability assessments, not only the most serious ones. Check that each finding has a severity rating, an owner, a target date and a closure record that links back to a retest. A ticket marked closed without validation evidence will not satisfy an assessor.

Formal follow-up of critical audit findings

Article 6(6) and (7) require a formal process for timely verification and remediation of critical ICT audit findings. Entities other than microenterprises must also have the ICT risk management framework audited regularly by auditors with sufficient ICT risk expertise and independence. The follow-up process should record when each critical finding was raised, who verified the fix and when, and whether the auditor or internal audit function confirmed closure. Confirm with your own auditors how they expect closure to be evidenced.

Feeding lessons into the ICT risk assessment

Article 13(3) to (5) requires lessons from threat-led testing and real incidents to flow continuously into the ICT risk assessment and into monitoring of how the resilience strategy is implemented. Senior ICT staff must also report to the management body at least yearly. In practice, this means that a finding which exposes a flawed assumption should change the risk register, the residual risk position and the control plan, not just the system it affected. Keep a traceable record from each test lesson to the risk entry it changed.

Continuity test deficiencies reported to the board

Article 25(5) of Delegated Regulation (EU) 2024/1774 requires business continuity test results to be documented, with any deficiencies analysed, addressed and reported to the management body. A failed recovery time or a restore that did not complete is a deficiency even if the system was later fixed informally. Record the analysis, the corrective action and the date the board received the report. Ask whether your continuity test records are structured so that a board paper can be produced from them without rework.

TLPT remediation plan deadlines under Article 12 and 13

The sequence sets fixed report deadlines for each part of a threat-led penetration test, then ties the summary report and remediation plan to the competent authority's notice that the test reports are complete. Each step produces a document or check that shows the entity is moving toward closing the findings.

Close active red team testing
The red team's active testing ends, and that date starts the first reporting clock. The red team test report is due within 4 weeks of that end date under Article 12. Testers and the entity's test managers should agree in writing when active testing ends, because every later deadline depends on the record of that date. The entity confirms the report is complete and stores it with the test file before moving on.
Deliver the blue team and purple teaming reports
The blue team test report, along with the replay and purple teaming exercises, is due within 10 weeks under Article 12. The blue team report shows how the entity's detection and response staff handled the test, while the replay and purple teaming work compares attacker activity with defender responses. The entity checks that each exercise is documented, then sends both sets of material to the authority as the testing process requires.
Wait for the authority's completion notice
The clock for the next two deliverables starts when the competent authority notifies the entity that both the red team and blue team reports are complete, not when testing ends. The entity should record the notification date, who received it, and any conditions attached. Confirm with the authority how it sends this notice and whether it expects a formal acknowledgment, since the date on that notice drives the remaining deadlines.
Submit the summary report within eight weeks
The summary report required by Article 12(7) is due within 8 weeks of the completion notification. It condenses the test's scope, findings and conclusions for the authority and the management body. The entity should map each summarised finding to the report section where its evidence sits, so the authority can trace every conclusion. The submission is complete when the authority acknowledges receipt or the process confirms it was accepted.
File the remediation plan within eight weeks
The remediation plan under Article 13(1) is also due within 8 weeks of the completion notification, and it runs in parallel with the summary report. The plan should list each finding, its priority, the owner, the fix and the validation check that will close it. The management body approves the plan before filing. The plan is ready when it names an owner and a validation method for every finding, with no open items left undefined.
Track and validate fixes against the plan
After filing, the entity works through the plan, retests each fixed finding, and records the evidence that the weakness is closed. Lessons from the test also feed into the ICT risk assessment and the senior ICT staff's yearly report to the management body under Article 13. Each closure is complete when a retest or independent check confirms the fix and the record is updated. Ask the competent authority which progress updates it expects and how often.

How remediation differs for simplified-regime entities

Entities outside the simplified regime carry the full set of remediation duties under Article 24(5) of DORA. They must prioritise, classify and remedy every issue that testing and internal validation reveal, and then confirm that each identified weakness, deficiency or gap is fully addressed. For entities selected for threat-led testing, the red team, blue team and summary report timelines in Article 12 of the TLPT regime add fixed deadlines for remediation plans. Full-regime entities also run an internal audit function and a formal follow-up process for critical audit findings under Article 6.

Every issue, not only critical ones: Findings from all required testing enter the same classification and remediation process.
Validation before closure: A finding closes only when retesting or internal validation confirms the fix.
Audit follow-up: Critical internal audit findings need a documented, timely verification trail.
Feedback into risk assessment: Lessons from testing and incidents must be fed into the ICT risk assessment under Article 13.

Check whether your entity is in the full regime and whether any TLPT remediation deadline applies to you.

What makes remediation slower or more expensive

Remediation under DORA stalls for predictable reasons. The drivers below share a root cause: the entity cannot quickly tell what a finding affects, who must fix it, and whether the fix worked. Each card names a driver and the control that keeps it manageable.

Volume and severity of findings

A large batch of findings from one test cycle forces a choice about order, and an unranked list tends to stall. Classify every issue by severity, by the business service it touches and by whether it affects a critical or important function, then fix the top tier first. Check that the ranking is written down and approved, so the team can show Article 24(5) prioritisation to an assessor. Recurring findings from the same root cause should be grouped into one fix rather than tracked as many tickets.

Legacy systems without patch paths

Older platforms may lack vendor support, automated patching or a tested rollback, so a fix can be slow or risky to apply. Record which tested systems run unsupported versions and whether a compensating control, such as network isolation or tighter access, can reduce exposure while a upgrade is planned. Ask whether the fix can be validated in a staging copy before production. Document the residual risk and who accepted it.

Dependence on ICT providers

When a finding sits in a vendor's code or hosted service, the financial entity cannot fix it alone. Review contract terms for vulnerability notification, patch timelines and cooperation during retesting before a test begins. Where the platform is self-hosted open source, confirm which component the entity owns and which upstream project issues the patch. Track provider-side fixes as open items with named owners and evidence of retesting.

Unclear asset inventory

A finding is hard to fix when nobody can confirm which system, version, owner or data flow it affects. Reconcile test scope against the ICT asset inventory and the register of information before remediation starts. Map each finding to a named asset, its business service and its dependencies. Gaps found during this exercise are themselves findings to track, because the inventory feeds the risk assessment that Article 13 expects to learn from test results.

Weak evidence trails

Remediation that is done but not recorded still counts as an open gap to an assessor. Keep a finding register with the test reference, the fix, the change record, the retest result and the approver for each item. Store the retest output alongside the original finding so the closure can be traced. Ask the internal audit or control team to sample closed items before the assessor does.

Late board escalation

Deficiencies that reach the management body late leave fewer options and may breach the deadlines that apply to remediation plans. Set an escalation threshold that sends critical findings and any continuity test deficiency to senior management and the board promptly, with the proposed fix and the decision needed. Under Article 25(5) of Delegated Regulation (EU) 2024/1774, continuity test deficiencies must be analysed, addressed and reported to the management body, so the reporting path should be agreed before the next test.

Who is paid for what in remediation

This table compares each remediation cost component by who is paid, whether the cost is one-time or recurring, and what drives its size. No figures are given here, so use the drivers to build a question list before requesting a written quote from each party.

Cost component	Who is paid	One-time or recurring	What drives it
Internal engineering time for fixes	The organization's own staff (salaries and time allocation, not an external invoice)	Mostly one-time per finding, with recurring time for patch cycles	Number and complexity of findings, system ownership, change approval and release windows
Implementation partner for fixes and evidence	DeployOpen or another implementation partner, under a written fixed-scope agreement	One-time for the agreed scope, with optional recurring retainer for ongoing support	Systems affected, hardening effort, evidence packs requested, and whether the partner also reruns checks
Retesting by a tester	The independent tester or security testing provider that verifies the fix	One-time per retest round, repeated if a fix fails validation	Number of retests needed, scope of the original test, and whether the retest is included in the original quote
Independent audit follow-up	The internal or external auditor who checks that critical audit findings were verified and closed	Recurring with each audit cycle	Number of open critical findings, auditor independence requirements, and the follow-up evidence the auditor expects
Tooling for tracking	Software vendor or open-source project, plus the organization's hosting and administration staff	Licences or hosting recur; setup is one-time	Number of findings tracked, integration with ticketing and asset inventory, and whether the tool is self-hosted
Provider remediation under contract	The ICT third-party provider, under the contract terms the financial entity negotiated	Usually included in the service fee, with extra charges for bespoke fixes	Contract clauses on remediation timelines, cost allocation for provider-side fixes, and testing participation terms

Who owns each remediation step

Under DORA the financial entity remains fully responsible for its ICT risk management framework, its testing programme and every finding that testing produces. Remediation is therefore a management decision before it is a technical task. Your management body and senior ICT staff decide how findings are prioritized, what risk each open item carries, and which findings are accepted with documented justification. Those decisions feed the ICT risk assessment and the yearly report to the management body.

Prioritization and risk acceptance: Approve the classification of each finding and sign off any residual risk that will not be fixed on the planned date.
Ownership: Name an accountable owner for every item, including the business owner of each affected critical or important function.
Follow-up process: Run the formal process that verifies critical ICT audit findings are remediated on time.
Board reporting: Report open deficiencies, including continuity test deficiencies, to the management body.
Evidence retention: Keep the findings register, change records and closure decisions in a form that supervisors can inspect.

Before engaging any partner, confirm internally who holds each of these decisions and how they will be documented.

Questions about remediating DORA test findings

Must every finding from a DORA test be fixed, or only the critical ones?

Every finding must be addressed. Article 24(5) of DORA requires procedures to prioritise, classify and remedy all issues revealed by testing and internal validation, and to confirm that every identified weakness, deficiency or gap is fully addressed. Prioritisation decides the order and the deadline for each fix, so a critical finding may be closed first, but a low-severity finding still needs a documented decision: fix it, accept it as residual risk under your risk framework, or compensate for it. Record that decision and who approved it, because an assessor will ask to see the trail for each finding, not only the high-severity ones.

Who signs off that a DORA test finding is closed?

The financial entity owns the decision to close a finding. Closure should rest on evidence that the fix works, such as a retest or internal validation result, and be approved by the person accountable for the affected system or process, with the ICT risk function checking the evidence independently. Your internal audit function, which DORA expects to review the framework on a regular basis, should be able to test a sample of closures. An implementation partner can prepare the retest evidence and the closure record, but the sign-off stays inside your organization, and the partner does not issue any attestation of closure.

How long does remediating DORA test findings take?

It depends on the scope of the test, the number and complexity of the findings, and how much of the affected estate has to change. Fixes to configuration or access settings can close quickly, while architecture changes, vendor-dependent patches or changes to a shared platform take longer and may need change approval and testing windows. The useful answer is in your written remediation plan, which should give an owner, a priority and a target date for each finding and state how each target was set. Ask any partner to show you how their scope and timeline are agreed in writing before work starts, rather than relying on a general estimate.

Can our own team handle DORA remediation without outside help?

Often yes, if the team has the skills, capacity and independence to do the work and to verify it. Remediation that touches access control, logging, backup or network design needs engineers who understand both the system and the control, and the people who verify closure should not be the people who made the change. Outside help is most useful for specific gaps: preparing a self-hosted platform so that its configuration and logs produce evidence, retesting fixes, or documenting the work in a form an auditor can follow. Decide which parts you own, which you hand to a partner under a fixed-scope agreement, and which you ask an independent auditor to test.

What does DORA remediation require from management?

Management must provide the authority, budget and accountability to get findings fixed. The management body is responsible for the ICT risk management framework under DORA, so it should approve the prioritisation approach, the risk acceptance decisions and any deferred remediation, and it should see that owners have the resources to meet their dates. Management also has to make changes to production systems possible, which means accepting short maintenance windows, funding dependencies such as licences or hardware, and enforcing deadlines with business units and ICT providers whose systems are involved.

How does DORA board reporting work for test findings and continuity deficiencies?

Senior ICT staff report to the management body at least yearly under Article 13, and that report should cover how lessons from testing and real incidents are fed into the ICT risk assessment. Continuity testing has a specific requirement: under Article 25(5) of Delegated Regulation (EU) 2024/1774, continuity test results must be documented, deficiencies analysed and addressed, and reported to the management body. In practice, the board pack should show open and closed findings, overdue items with reasons, risk acceptances awaiting approval, and continuity deficiencies with their remediation status. Confirm the exact content and frequency with your competent authority and your own governance documents.

How does DORA remediation tie into TLPT remediation plan deadlines?

Threat-led penetration testing has its own reporting clock. Under Article 12, the red team test report is due within 4 weeks after active testing ends, and the blue team report, replay and purple teaming exercises are due within 10 weeks. Once the authority confirms both reports are complete, the summary report under Article 12(7) and the remediation plan under Article 13(1) are each due within 8 weeks of that notification. Treat these as fixed dates in your plan, and make sure the findings from a TLPT feed into the same tracking system as other test results so that nothing is lost between the two tracks.

How to get ready before a supervisor asks for remediation evidence

Readiness means one findings register that a supervisor can read from top to bottom. Every issue from a test, including vulnerabilities from yearly penetration tests, deficiencies found in continuity tests, and audit findings, should sit in a single register with a unique identifier, the source test, a severity and priority rating, a named owner, a target date, and a status. Article 24(5) expects every issue to be prioritised, classified and remedied, so the register is where that classification is visible. Keep closed items in the register rather than deleting them, because the closure record is the evidence an assessor will ask for first. Confirm the field list and the rating scale with your competent authority before you build the template, since supervisors differ in how much detail they expect.

Each closed finding needs a retest record and a sign-off, not only a ticket marked done. Attach to each item the remediation change, the retest that proved the weakness is gone, the person who performed the retest, and the date of that retest. Where a finding came from an internal audit, record the follow-up verification that Article 6(7) expects. Board evidence is the other half: senior ICT staff must report to the management body at least yearly under Article 13(5), and deficiencies from business continuity tests must be reported to the management body under Article 25(5) of Delegated Regulation (EU) 2024/1774. Keep the minutes that show the board received these reports and decided on open items. Ask your supervisor who must sign off closure of high-severity items and whether the board must approve a risk acceptance for any finding left open.

How DeployOpen prepares remediation evidence

DeployOpen works with the financial entity to turn test findings into fixed, verified and documented remediation. We plan and implement changes inside your own infrastructure, then prepare the evidence your management body and independent assessors will ask to see. The organization keeps ownership of its controls and decisions throughout.

How we scope

Agree in writing which test reports, findings and systems fall within the remediation engagement.
Confirm how each finding is prioritised, classified and assigned to an owner before any change starts.
Define the deliverables, timelines and acceptance criteria for each remediation item in the fixed scope.

How we build

Implement fixes to self-hosted open-source platforms in your cloud accounts, data centers or air-gapped networks.
Retest each remediated weakness and record the result so validation is traceable to the original finding.
Update configurations, runbooks and risk entries so the ICT risk assessment reflects what the tests revealed.

How we hand over

Deliver a findings register linking each issue to its fix, validation record and responsible owner.
Prepare remediation plan documentation and continuity test deficiency write-ups for management body review.
Hand over evidence packs for independent auditors and competent authorities, which only they can assess or certify.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after the fixed-scope work ends.
Track follow-up on audit findings and re-verify items when platforms are upgraded or reconfigured.
Confirm with your compliance lead which retainer scope and reporting cadence fit your remediation obligations.

Remediating DORA test findings