Ready for Your Next DORA Audit? How to Turn Resilience Policies Into Provable Evidence

October 26, 2026
Reading Time: 7 minutes

Listen to this blog

The Digital Operational Resilience Act (DORA) is an EU regulation that helps financial entities prepare for, respond to, and recover from technology risks and keep key services running during disruptions. It has been in force since 17 January 2025.

But by mid-2026, national competent authorities (NCAs) have started looking beyond whether financial organizations have set up the right frameworks and policies. Now, they are also checking whether a firm can show the record for a recent change, the name of the approver with his signature, and explain how the team has managed that particular change.

This changes what audit readiness looks like, and every team should prepare for that. In this guide, we will cover how organizations can show that they have followed every policy.

Points clés

What you'll learn in this article

What changed in DORA audits by mid-2026 and why supervisors now look for evidence of implementation, not just policies
What the first DORA audits found across the four pillars, and the evidence that helps close each gap
The evidence chain auditors ask to see, from the regulatory obligation to the approval and historical record
How Modern Requirements4DevOps builds that chain inside Azure DevOps with approvals, baselines, and living traceability matrices

Why the Next DORA Audit Looks Different From the First One

In the first phase of DORA audits, regulators were looking at how financial firms are putting compliance programs and policies in place. But findings exposed a gap between written procedures and the way different teams manage different technology risks. Because of that, the DORA audit is now in supervisory mode, and regulators are also checking that particular policies are implemented.

The next round brings three important changes for financial institutions:

Auditors may check whether different teams within the same organization are following a connected process rather than checking each process separately. Each team can have its own processes, but auditors want to check whether these records work together.
Who audits you depends on where you are. There is no single EU audit program. France, Poland, and Luxembourg inspect firms directly; Germany and Liechtenstein rely on external auditors; and Italy mixes self-assessments with ECB and IVASS inspections.
Supervision follows the service, not the legal entity. An EU bank running on ICT services from a group company in Switzerland or the UK still has to produce its own evidence for those services. Group-level paperwork rarely covers it.
From 2026, Germany treats findings related to operating effectiveness as regulatory irregularities. This puts greater importance on how financial institutions apply their controls in daily operations and maintain records to show that those controls are working as required.

What the First DORA Audits Found, Pillar by Pillar

DORA pillar	Issues found in early reviews	Evidence that helps address the gaps
1. ICT risk management	Frameworks not aligned across processes. Incomplete or outdated records due to system changes. Ownership of key risks and controls is unclear.	A versioned and approved requirement baseline. Traceability matrices from ICT requirements to critical functions they protect to test cases
2. ICT incident management and reporting	Delays in identifying major incidents. Incomplete integration of systems Insufficient incident scenario coverage Communication between teams and service providers needs improvement.	Documented incident classification criteria. Reports showing incident detection escalation, changes in requirements, proof of implemented and tested change. Tested response procedures with clear responsibilities.
3. Digital operational resilience testing	Scope skips security testing. Remediation not tracked. Testing may rely too heavily on isolated penetration tests rather than a risk-based program.	Live bi-directional traceability matrix that can show what is tested and what is missing. Assigned corrective actions, completion records, and retest results.
4. ICT third-party risk management	Incomplete or inaccurate data register. Gaps about DORA policies in contractual agreements Weak integration with third-party tools.	A complete and regularly checked Register of Information. Reviewed contracts and documented provider risks.

What Auditors Actually Ask to See: The Evidence Chain

During the critical system review, auditors need to understand how the organization manages changes, approvals, test cases, other records, etc., and they generally require evidence and ask questions like the ones below:

Evidence required	What the auditor needs to establish
1. Regulatory obligation	Which DORA article or internal policy applies? What risk or control does it address?
2. Requirement or control	Which critical system or service does it protect?
3. Change record	What changed, and why? Was the impact assessed, including possible effects on security? Was a fallback plan identified?
4. Test results	What tests were performed before implementation? Did the tests reveal problems? Were those problems fixed and retested?
5. Approval and implementation	Who approved the change, and when? Was approval independent of the people who requested and implemented it? Was the change implemented and verified as planned?
6. Historical record	Can the firm retrieve the relevant records for the review period? Can it show what changed between review cycles and which issues remain open?

When teams use different tools to manage requirements, test cases, documents, approval logs, development activities, etc., and if they are not linked, team members may have to search across several tools to explain one change, and doing it manually is a headache, or information can be easily missed.

In short, a useful evidence chain connects each high-level obligation with its control, high-level requirements, test cases, the changes that affected it, test results, and approval records so everything stays in one place. In the next section, let’s look at how Modern Requirements4DevOps helps in keeping every record traceable and achieving DORA.

How Modern Requirements Build DORA Audit Evidence Inside Azure DevOps

Any financial organization does not become audit-ready by just storing DORA policies in Azure DevOps or any project management tool. To be compliant, teams need to connect those policies with the controls they cover, changes, test cases, low-level requirements, and approvals that can answer questions from auditors and demonstrate the evidence chain.

Modern Requirements4DevOps, an award-winning requirements management tool that works directly within Azure DevOps, helps financial teams to create a DORA evidence chain where requirements are stored and development records already exist. Teams can start from the Smart Import module, which allows them to import documents that contain DORA obligations, such as Article 9(4)(e) policies, and convert each heading of the document into ADO work items based on the heading level.

Once, for each of these obligations, work items are created, teams can send these work items for review and approval to different team members directly within Azure DevOps. Also, it stores every record of who has reviewed these work items, who approved them, and at what time. This can be exported to Microsoft Word or PDF.

After requirements are approved, teams can create a baseline for those work items and freeze them before any development starts so everyone works from the same scope.

During development, teams can create living traceability matrices that show which requirements are connected with which DORA obligation and what is missing. An intersectional traceability matrix allows us to find coverage gaps between requirements and DORA policies.

Furthermore, Copilot4DevOps AI helps to generate DORA-related requirements without missing anything, perform change impact assessment using AI, and generate audit reports based on ADO work items’ history.

Overall, Modern Requirements4DevOps removes manual traceability, review, and baseline work and helps in generating audit-ready reports that can be used directly for regulatory submission.

Want to stay compliant with DORA obligations within Azure DevOps? Book a 30-min demo of Modern Requirements4DevOps.

FAQ

1. What if a DORA control has no test evidence?

If a DORA control has no test evidence, the team should instantly record the gap, assign an owner, and decide what needs to be tested instead of just assuming the control works because the policy says it should.

2. How does Modern Requirements4DevOps link DORA requirements to software changes?

Teams can connect requirements and changes within Azure DevOps itself using work item relationship types. After that, teams can use Modern Requirements4DevOps to create a live traceability matrix and create an evidence chain.

3. Who is responsible when an ICT provider cannot supply evidence?

The financial institution still has to manage its DORA obligations. It should contact the provider, record what is missing, assess the risk, and follow the steps set out in its contract and internal process.

Commencez à utiliser Modern Requirements dès aujourd’hui

✅ Définir, gérer et tracer les exigences dans Azure DevOps
✅ Collaborez sans effort entre les équipes réglementées
✅ Commencez GRATUITEMENT — pas besoin de carte de crédit

Réservez une démo