Automated security audit for DORA: what good looks like

An automated security audit for DORA has to do more than produce a report at the end of the quarter. It has to collect repeatable technical evidence, test live systems and APIs, and keep enough context for a financial entity to show real operational resilience under Regulation (EU) 2022/2554, which has applied since 17 January 2025.

The useful version turns recurring technical findings into audit evidence, not paperwork. Governance, risk acceptance and legal interpretation stay with people. The testing, the evidence capture and the retest are what you automate.

Key takeaways

• DORA needs evidence on a recurring cadence, not a one-time scan or a static checklist.
• An automated audit should cover internet-facing apps, APIs, authentication, TLS, exposed paths, exposed infrastructure and the third-party components behind them.
• Good audit evidence carries the asset scope, test date, severity, owner, remediation status and retest result.
• Automation can collect, test, map and re-check. Decisions on risk acceptance and control ownership remain human.

A DORA audit is evidence, not a one-off scan

DORA asks for demonstrable resilience, so a single point-in-time report is only a starting point. The regulation rests on five themes: ICT risk management, incident reporting, digital operational resilience testing, ICT third-party risk management and information sharing. That mix is why a compliance folder alone never satisfies an auditor for long.

What matters is whether your process can show what changed, what was tested again and what stayed open. A snapshot goes stale the week after the next deployment.

What automation should replace

Automation should take over the repetitive parts: asset discovery, recurring tests, evidence capture, prioritisation and retesting. It should also remove the errors that come from spreadsheets, pasted screenshots and hand-assembled exports. For a bank or fintech shipping every week, it is the only practical way to keep pace with change.

What still needs human judgment

Governance decisions do not become automated because the testing does. Someone still decides whether a risk is acceptable, whether a remediation deadline is realistic and whether a compensating control is enough. People also decide how a finding maps to a DORA requirement, because in regulated environments context matters more than raw severity.

What an automated DORA security audit must cover

The right scope starts with production-facing assets: internet-facing web apps, APIs, authentication flows, TLS, exposed sensitive paths, exposed infrastructure and the third-party components that sit on those paths. If the audit never touches the systems customers actually use, it misses the risk that matters most.

DORA's testing chapter calls for regular vulnerability assessment and scanning on ICT systems that support critical or important functions, at least yearly, while threat-led penetration testing (TLPT) is reserved for designated entities on a three-year cycle. In practice the annual exercise is the floor, not the finish line, because a regulated environment keeps changing between reporting cycles. The detail is in our guide to DORA penetration testing requirements.

Production-facing assets

A payment firm should test login, session handling, password reset, API authentication, admin routes, partner integrations and externally reachable services. It should also look at the edges where one system hands off to another, because that is where bad assumptions live. A scope that ignores those edges is too narrow to be useful.

Controls and evidence

Your evidence set should record what was tested, when, on which asset, what failed, the severity, the owner, the remediation status and the retest result. In a mid-size fintech that could mean a monthly run on the customer portal, a weekly pass on public APIs and a retest after every critical fix. The value is not only finding issues. It is proving that the same issue did not stay open unnoticed.

Where automation helps most in the DORA lifecycle

Recurring work is where automation pays off. It cuts the manual effort of repeating the same tests, re-exporting the same findings and re-checking the same fixes across reporting cycles. The trade-off is simple: if the scope is wrong, automation only makes the blind spot faster.

Before the audit

1. Define in-scope assets with security, engineering and vendor management, then confirm which systems are customer-facing or externally reachable.
2. Run a gap analysis against ICT risk management, incident reporting, testing, third-party oversight and information sharing.
3. Set the first baseline assessment on the highest-risk web apps and APIs before widening coverage.

During remediation

1. Assign an owner and a remediation deadline to each finding, and push it into the ticketing system engineering actually uses.
2. Check that the fix changed the exposed behaviour, not just that the ticket was closed.
3. Retest after every fix so the proof stays current instead of getting buried in email.

Between reporting cycles

1. Repeat the assessments on a monthly or release-driven cadence for exposed systems and APIs.
2. Review recurring patterns with compliance and security so they map back to DORA domains.
3. Keep the latest evidence package ready, so the next audit request starts from current facts rather than archived guesses.

What auditors and regulators will look for

Expect supervisors to ask for more than a vulnerability export. DORA is also specified through delegated and implementing acts, including on incident reporting and the subcontracting of ICT services. As the European Commission puts it, DORA "gives the Commission the power to adopt delegated and implementing acts to specify how competent authorities and market participants need to comply with the obligations laid down in the regulation."

A defensible package includes audit trails, dates, scope, severity rationale, incident links where relevant and proof of retest. The adjacent evidence matters too: the register of information on ICT third-party providers, which the ESAs collect through competent authorities as EIOPA's DORA page details, has to line up with the technical audit, or the story falls apart.

Evidence that stands up

Within 48 hours, a team should be able to produce the latest asset scope, the most recent test report, the open findings, the retest log, the owners and any incident or change ticket tied to an issue. If that package is hard to assemble, the process is too manual to trust.

Common proof gaps

The usual misses are stale scope, missing timestamps and no link between the technical finding and the remediation record. Another frequent one: the team can show scanner output but not the retest proving the fix held. That is where compliance work and engineering discipline have to meet. We cover how to merge that evidence across frameworks in one evidence program for DORA and NIS2.

How to choose a DORA audit tool without buying paperwork

Buy for technical proof, not document volume. Look for risk mapping, recurring vulnerability testing, reporting you can hand to an auditor and a fit with adjacent frameworks such as GDPR, ISO 27001 and NIS2. Workflow-heavy systems document obligations well, but they usually stop short of testing live systems.

Categories matter more than logos. Form builders and GRC suites route approvals and store attestations. Scanners surface issues but do not always turn them into audit-ready evidence. Offensive testing is the category closest to what DORA actually asks you to demonstrate.

Option	Best for	Key strength	Main limitation	DORA audit fit
Form builders	Approval and intake workflows	Easy routing	No live testing	Weak for technical proof
GRC suites	Policy and control management	Central tracking of obligations	Evidence often static	Useful alongside testing, not enough alone
Vulnerability scanners	Broad, frequent coverage	Finds known weaknesses fast	No proof of exploitability, noisy	Partial, needs validation
Agentic pentest (Fleuret)	Recurring tests on web apps, APIs and external infrastructure	Exploitable findings with replayable proofs of concept, retest after the fix	Not a governance or legal workflow tool	Strong for the technical testing stream

The verdict is straightforward. If your audit problem is proving that production systems are tested, retested and owned, pick the category that starts with testing. If your problem is only routing sign-offs, a workflow tool is enough, but that is a different problem.

Where Fleuret fits

Fleuret is an offensive security company. It runs agentic pentests on web apps, REST and GraphQL APIs and external infrastructure, with results in hours. Every finding comes with a replayable proof of concept and a DORA / NIS2 mapping, lands in Jira, Linear or Slack, and gets retested after the fix. A signed report is available on demand for the audit file.

That covers the technical testing stream of a DORA audit. It does not replace governance decisions, legal interpretation, subcontractor oversight or the non-technical parts of the regulation, which stay with your compliance team and its tools.

A 90-day plan to make the audit repeatable

A mid-size fintech can make this real in one quarter if ownership is clear: security owns scope and testing, engineering owns fixes, compliance owns the mapping to DORA domains and vendor management owns third-party follow-up.

Days 1 to 30

1. List in-scope assets, then rank internet-exposed systems and APIs first, because they carry the highest audit value.
2. Run baseline assessments and capture the first evidence package, with dates, owners and severity rationale.
3. Keep test records and retest results in one place so the process starts clean.

Days 31 to 60

1. Set remediation deadlines by severity and business criticality, and tie each item to an engineering owner.
2. Retest the fixes and check that the exposed behaviour changed, not just the ticket state.
3. Map findings to DORA domains and note any overlap with ISO 27001 or GDPR controls already in place.

Days 61 to 90

1. Hold a monthly review with security, compliance and vendor management so evidence stays current.
2. Extend coverage to adjacent systems and third-party dependencies on the same customer journeys.
3. Define done as being able to show scope, results, remediation and retest within one audit request cycle.

Start with the assets that change fastest

For most regulated teams, the next step is not a longer checklist. It is a tighter process around the systems that change most often, especially internet-facing apps and APIs, with clear owners and repeatable retests. If you can show the path from finding to fix to retest, you have an audit process that holds up.

Anchor it in the technical layer first. Then let compliance map the evidence to DORA, instead of trying to manufacture proof after the fact.

Fleuret runs agentic pentests that feed the technical side of a DORA audit: replayable PoCs, tickets, retest and a signed report. See Fleuret in action.

Sources

• Implementing and delegated acts: DORA, European Commission, 2025
• Digital Operational Resilience Act (DORA), EIOPA