DORA Testing Programme: Map Tests to ISO 27001

It is February 2026. The CISO of a mid-sized payment institution has a board meeting in two days, an ISO/IEC 27001:2022 surveillance audit in six weeks, and a DORA supervisory request sitting in the compliance inbox.

The regulator is not asking for a glossy cyber strategy. The request is practical:

• Provide your 2026 digital operational resilience testing programme.
• Show which tests cover critical or important functions.
• Demonstrate how findings are remediated and retested.
• Evidence management body oversight.
• Explain how ICT third-party providers are included.
• Provide records for vulnerability assessments, scenario-based tests, performance and capacity testing, and penetration testing.

The CISO opens four folders. Vulnerability scans are in the SOC ticketing system. Tabletop exercise notes are in a shared drive. Load test results are owned by engineering. Penetration test reports are in legal’s restricted repository. Remediation tracking is split between Jira, email and a spreadsheet created for last year’s ISO audit.

Nothing is fake. Much of it is good work. But it is not yet a governed DORA digital operational resilience testing programme. It is a collection of tests.

That difference matters in 2026. DORA applies from 17 January 2025 and establishes a uniform EU framework for digital operational resilience across ICT risk management, incident reporting, resilience testing, cyber threat and vulnerability information sharing, ICT third-party risk management, contractual requirements and oversight of critical ICT third-party providers. It covers a broad range of financial entities, including credit institutions, payment institutions, investment firms, crypto-asset service providers, insurance undertakings and other regulated entities. DORA also acts as the sector-specific Union legal act for financial entities that would otherwise fall under equivalent NIS2 cybersecurity obligations.

The practical question for boards, CISOs, compliance managers and ICT providers is no longer whether testing happens. The question is whether testing is planned, risk-based, evidenced, remediated, reviewed and reusable across DORA and ISO/IEC 27001:2022.

Clarysec’s operating model is built for this exact problem. Using the Zenith Blueprint: An Auditor’s 30-Step Roadmap, Clarysec’s ISO-aligned policy suite and Zenith Controls: The Cross-Compliance Guide, organizations can turn scattered resilience activities into a controlled annual test catalogue that satisfies supervisors, auditors, clients and boards.

Why DORA turns testing into a governance issue

DORA is explicit about executive accountability. Article 5 places responsibility for ICT risk management on the management body. Article 6 requires a sound, comprehensive and well-documented ICT risk management framework integrated into the organization’s overall risk management system. Article 4 adds proportionality, meaning requirements should be applied based on size, overall risk profile and the nature, scale and complexity of services, activities and operations.

This makes digital operational resilience testing more than a technical task. It becomes evidence that the management body understands risk, has approved a strategy, receives meaningful reporting and drives remediation.

ISO/IEC 27001:2022 uses a similar management-system logic. Clauses 4.1 to 4.4 require the organization to understand context, interested parties, legal and contractual obligations, scope, interfaces and dependencies. Clauses 5.1 to 5.3 require leadership, policy alignment, resources, communication, assigned responsibilities and reporting to top management. Clause 6.1 requires information security risk assessment and risk treatment.

A DORA testing programme should therefore connect:

• Business services and critical or important functions
• ICT assets, data and third-party dependencies
• Risk assessment, risk owners and treatment plans
• Test types, frequency and triggers
• Authorization, independence and rules of engagement
• Findings, remediation deadlines and retesting
• Evidence retention and access control
• Management reporting and continual improvement

For smaller or lower-risk financial entities, Article 16 provides a simplified ICT risk management framework, but simplified does not mean informal. Even scaled programmes still need documented ICT risk management, monitoring, resilient systems, identification of ICT risk sources and anomalies, key ICT third-party dependencies, continuity and recovery measures, regular testing and lessons learned.

In other words, DORA does not reward test volume. It rewards governed, risk-based testing that proves resilience for the services that matter most.

What belongs in a 2026 DORA testing programme?

A mature DORA testing programme should operate as an annual test catalogue. It should not be limited to one annual penetration test or a pile of vulnerability scan exports. It should include basic and advanced tests, planned around risk, service criticality, regulatory obligations, supplier dependencies, major changes and previous findings.

DORA Article 24 establishes the digital operational resilience testing programme. Article 25 describes a range of tests, including vulnerability assessments and scans, open source analyses, network security assessments, gap analyses, physical security reviews, questionnaires, scanning software solutions, source code reviews where feasible, scenario-based tests, compatibility testing, performance testing, end-to-end testing and penetration testing. Article 26 adds threat-led penetration testing for financial entities identified by competent authorities.

For most organizations, the practical catalogue is built around four testing families.

Clarysec’s Security Testing and Red-Teaming Policy provides a strong policy anchor for this catalogue:

“Types of Tests: The security testing programme shall include, at a minimum: (a) vulnerability scanning, consisting of automated weekly or monthly scans of networks and applications to identify known vulnerabilities; (b) penetration testing, consisting of manual in-depth testing of specific systems or applications by skilled testers to identify complex weaknesses; and (c) red-teaming exercises, consisting of scenario-based simulations of real attacks, including social engineering and other tactics, to test the organisation’s detection and response capabilities as a whole.”

The same policy requires regular scheduling:

“Testing Schedule: The organisation shall conduct security testing on a regular schedule. Key internet-facing systems and critical internal applications must undergo penetration testing at least annually. High-risk changes, such as the deployment of a new critical system or major upgrades, require ad hoc testing before and/or shortly after go-live in production.”

This is critical for DORA. A static annual plan is not enough if the entity deploys a new payment gateway, migrates a core system to cloud, changes a managed service provider or releases a new customer authentication flow. High-risk change must trigger additional testing.

Build the annual test catalogue as the single source of truth

The most efficient way to satisfy DORA and ISO/IEC 27001:2022 is to create one controlled annual test catalogue. It can live in a GRC platform, a ticketing workflow or a controlled spreadsheet. The format matters less than traceability.

Every test should answer five audit questions:

1. Which service, asset, supplier, application or process was tested?
2. Which risk, obligation or control requirement triggered the test?
3. Who authorized and performed the test?
4. What findings were identified, accepted, remediated or deferred?
5. What evidence proves the test occurred and the outcome was reviewed?

A practical Clarysec-style catalogue includes these fields.

Clarysec’s Audit and Compliance Monitoring Policy-sme - SME gives a concise governance rule that fits this structure:

“Each audit must include a defined scope, objectives, responsible personnel, and required evidence.”

Although written for audits, the same rule should apply to resilience tests. If a vulnerability scan, tabletop exercise, failover simulation or penetration test has no defined scope, objective, owner and required evidence, it will be weak under both DORA and ISO audit scrutiny.

The same policy states:

“Evidence must be retained for at least two years, or longer where required by certification or client agreements.”

For DORA-regulated financial entities and ICT providers, two years should be treated as a floor. Contractual obligations, supervisory expectations, certification cycles and incident investigations may require longer retention.

Map DORA test types to ISO 27001 evidence

The power of an integrated programme is that one test can satisfy multiple obligations. The key is to tag evidence properly and connect it to the ISMS.

The Zenith Blueprint explains this in the Audit, Review & Improvement phase, Step 24:

“Your SoA should be consistent with your Risk Register and Risk Treatment Plan. Double-check that every control you chose as a risk treatment is marked “Applicable” in the SoA.”

For a DORA testing programme, the test catalogue becomes the bridge between risk treatment and operational evidence. The Statement of Applicability should not say a control applies while the test evidence sits somewhere else, unmapped and unmanaged.

This table helps a CISO answer the CEO’s common question: “Are our ISO penetration tests and vulnerability scans enough for DORA?”

The answer is: they can be part of DORA compliance, but only if they are risk-based, linked to critical or important functions, governed by policy, tracked through remediation and reported to management.

Vulnerability assessments: continuous evidence, not just scan output

Vulnerability assessment is often the easiest testing activity to run and the easiest to mishandle. Many organizations can produce scan reports. Fewer can prove that scans cover the right assets, prioritize critical services, generate timely remediation and feed risk treatment decisions.

Clarysec’s Vulnerability and Patch Management Policy-sme - SME starts with the right objective:

“Identify and assess known vulnerabilities across all IT assets in a timely and consistent manner”

For DORA, this supports identification of ICT risk sources, resilient and updated systems, monitoring, anomaly detection and continuous improvement. For ISO/IEC 27001:2022, it maps directly to 8.8 Management of technical vulnerabilities, and it also relies on 5.9 Inventory of information and other associated assets, 8.16 Monitoring activities and 8.32 Change management.

A strong vulnerability assessment record should include:

• Asset inventory snapshot used for scoping
• Scan date, tool and authenticated or unauthenticated method
• Exclusions and business justification
• Findings by severity, exploitability and business service
• Mapping to critical or important functions and data types
• Ticket references and risk owner
• Remediation SLA and due date
• Retest result
• Exceptions with residual risk approval

Zenith Controls positions 8.8 Management of technical vulnerabilities as a core evidence area for identification, assessment, prioritization and remediation tracking. It also shows why auditors will test adjacent processes. If the asset inventory is incomplete, vulnerability coverage is incomplete. If change management is bypassed, patch deployment may create new operational risk. If monitoring is weak, exploitation attempts may not be detected.

Scenario tests: prove decision-making before the real incident

Scenario tests are where operational resilience becomes visible to executives. A ransomware tabletop, cloud region outage simulation, privileged access compromise exercise or critical ICT provider failure scenario will reveal weaknesses that a scan cannot.

DORA Articles 17 to 20 require a formal ICT-related incident lifecycle: detect, manage, notify, record, monitor, handle, follow up, document root cause, remediate, classify severity, assign roles, escalate major incidents and report through required stages. Where clients’ financial interests are affected, clients must be informed without undue delay.

NIS2 has similar urgency for entities within its scope, including early warning, notification, intermediate reporting and final reporting. For in-scope financial entities, DORA is the sector-specific legal act for equivalent cybersecurity risk management and reporting duties. ICT providers, SaaS platforms, MSPs and MSSPs still need to check whether they are directly within NIS2 scope or contractually pulled into DORA assurance by regulated clients.

The Zenith Blueprint, Controls in Action phase, Step 23, gives the practical evidence model:

“Select a recent event or conduct a tabletop exercise to validate your plan. Capture and log all decisions, roles, and communications (5.26), and update the plan with lessons learned (5.27).”

A DORA scenario test should produce auditable records, not just meeting notes:

• Scenario brief and objectives
• Participants and roles, including Legal, Comms, IT, SOC, business owner and supplier contacts
• Timeline of injects and decisions
• Classification decision and reporting threshold analysis
• Draft internal and external communications
• Evidence preservation actions
• Lessons learned
• Action owners and due dates
• Updated incident, continuity or communication procedures

Clarysec’s Business Continuity Policy and Disaster Recovery Policy-sme - SME reinforces the annual testing expectation:

“The organization must test both its BCP and DR capabilities at least annually. Tests must include:”

The testing catalogue should translate that obligation into specific exercises, such as crisis management tabletop, backup restore test, cloud failover test, contact tree test and supplier disruption simulation.

Performance, capacity and recovery tests: the neglected resilience evidence

Performance testing is often treated as an engineering concern. Under DORA, it becomes resilience evidence.

A trading platform, payment service, claims system, identity platform or customer portal does not need a cyberattack to fail customers. Capacity exhaustion, queue saturation, database bottlenecks, misconfigured autoscaling or broken failover can create the same operational disruption as a security incident.

ISO/IEC 27001:2022 Annex A 8.6 Capacity management is the primary anchor. The evidence may include load testing, stress testing, service degradation testing, infrastructure threshold validation, backup restore tests and failover simulations.

A good performance and capacity test record should capture:

• Baseline normal load and peak load assumptions
• Critical transaction journeys tested
• Infrastructure and cloud limits tested
• Monitoring dashboards and alert thresholds
• Failure modes, such as queue saturation or database bottlenecks
• RTO and RPO relevance where failover or recovery is tested
• Business impact if thresholds are breached
• Remediation actions, scaling decisions or architecture changes
• Management acceptance of residual capacity risk

The Zenith Blueprint, Step 23, connects recovery expectations to evidence:

“Verify that recovery time objectives (RTO) and recovery point objectives (RPO) for critical systems align with business continuity expectations (5.30). Conduct at least one technical recovery test or failover simulation and document the results.”

That is the difference between saying “we have backups” and proving that a critical service was restored within agreed tolerance, with documented results and management visibility.

Penetration testing and red teaming: strong evidence needs strong control

Penetration testing is highly valuable evidence, but it also carries operational risk. Poorly governed testing can affect production systems, expose sensitive data, trigger uncontrolled alarms, create legal issues or disrupt customers.

The Application Security Requirements Policy-sme - SME sets a clear release gate:

“Before deployment, all Applications must undergo security testing to verify the baseline features listed above.”

For critical applications, this should feed the DORA catalogue as pre-production security testing, post-go-live validation for high-risk changes and periodic penetration testing based on exposure and criticality.

The Security Testing and Red-Teaming Policy strengthens the remediation chain:

“Remediation of Findings: All identified vulnerabilities or weaknesses must be documented in a findings report with severity ratings. Upon receipt of the report, system owners are responsible for creating a remediation plan with due dates; for example, critical findings shall be remediated within 30 days and high-severity findings within 60 days, in accordance with the organisation’s Vulnerability and Patch Management Policy. The STC shall track remediation progress. Retesting shall be performed to confirm that critical issues have been resolved or adequately mitigated.”

The same policy defines reporting expectations:

“Reporting: A formal report shall be issued at the conclusion of each test. For penetration testing, the report shall include an executive summary, methodology, and detailed findings with supporting evidence and recommendations.”

The Zenith Blueprint, Step 21, also highlights protection during audit and testing:

“No test or audit should proceed without documented approval from system owners or relevant stakeholders.”

Rules of engagement, test windows, emergency contacts, temporary access, data handling, logging, rollback procedures and legal approvals are not bureaucracy. They are resilience safeguards.

Include ICT third-party providers before the test fails

DORA makes ICT third-party risk a central resilience issue. Article 28 requires financial entities to manage ICT third-party risk within the ICT risk management framework, remain responsible when using ICT services, maintain an information register, report certain arrangements, perform pre-contract assessments and use providers meeting appropriate information security standards. Articles 29 and 30 address concentration risk, subcontracting, data recovery, contractual protections, service levels, incident assistance, audit rights, provider contingency testing, participation in testing where relevant and exit arrangements.

ISO/IEC 27001:2022 Annex A provides supporting supplier controls, including 5.19 Information security in supplier relationships, 5.20 Addressing information security within supplier agreements, 5.21 Managing information security in the ICT supply chain, 5.22 Monitoring, review and change management of supplier services and 5.23 Information security for use of cloud services.

A DORA test catalogue should identify which tests require supplier participation or supplier evidence. Examples include:

• Cloud provider failover assumptions
• Managed SOC escalation and evidence preservation
• Core banking platform incident communication
• Payment processor outage scenario
• Identity provider recovery test
• SaaS vendor penetration testing attestations
• Critical subcontractor chain impact assessment

A programme that excludes critical ICT providers will fail the reality test. The customer-facing service may be yours, but the resilience dependency may sit in a cloud region, outsourced SOC, identity provider, software vendor, payment processor or data centre.

Cross-compliance mapping: one evidence set, many obligations

A well-designed DORA testing programme reduces audit fatigue. The same evidence can support DORA, ISO/IEC 27001:2022, NIS2, GDPR, NIST CSF 2.0 and COBIT 2019 governance reviews if it is tagged, retained and reported properly.

GDPR should not be forgotten. If resilience tests involve personal data, logs, customer records, identity data, HR records, biometrics or special category data, the organization must respect GDPR principles, including lawfulness, fairness, transparency, data minimization, storage limitation, integrity, confidentiality and accountability. Test data copies, exported logs and penetration test evidence can become regulated data stores. The test programme should define who may access them, how long they are retained and how they are securely disposed of.

How auditors will test the same programme

A DORA supervisor, ISO auditor, NIST-based assessor, COBIT reviewer and client auditor may inspect the same evidence through different lenses.

Zenith Controls is useful here as a cross-compliance compass. For DORA testing, Clarysec highlights 5.35 Independent review of information security, 8.8 Management of technical vulnerabilities and 8.6 Capacity management as especially important ISO/IEC 27001:2022 Annex A anchors. They help control owners connect testing to independent assurance, vulnerability handling and operational capacity.

Clarysec’s Information Security Policy also supports the audit trail:

“Control Owners shall maintain test results, logs, and review records to support periodic audits.”

That sentence should become an operational rule. Every test owner should know what to retain, where to retain it, how to protect it and how it links to risk and control evidence.

Build a DORA to ISO evidence pack in one week

A financial entity or ICT provider can make significant progress in five working days.

Day 1: Define scope and criticality

Use ISO/IEC 27001:2022 Clauses 4.1 to 4.4 thinking. Identify interested parties, regulatory obligations, contractual obligations, interfaces and dependencies. List business services, critical or important functions, key assets, data types and ICT providers.

Output: DORA testing scope register.

Day 2: Create the annual test catalogue

Use the four test families: vulnerability, scenario, performance and penetration. For each service, define which tests apply, frequency, owner, independence level and trigger. Include high-risk change triggers.

Output: 2026 digital operational resilience testing catalogue.

Day 3: Map controls and obligations

Map each test to ISO/IEC 27001:2022 Annex A, the risk register, SoA, DORA articles, supplier obligations and relevant Zenith Controls entries. For example, monthly external vulnerability scans map to 8.8 Management of technical vulnerabilities, risk treatment, monitoring, DORA ICT risk management and NIST CSF vulnerability outcomes.

Output: control mapping matrix.

Day 4: Standardize evidence folders

Create a controlled evidence structure:

• 01 Plan and authorization
• 02 Scope and rules of engagement
• 03 Raw results
• 04 Final report
• 05 Findings register
• 06 Remediation tickets
• 07 Retest evidence
• 08 Management reporting
• 09 Lessons learned and policy updates

Output: evidence repository with retention rules.

Day 5: Review findings and reporting

Consolidate open findings by severity, service, risk owner and due date. Identify overdue remediation, accepted risks and retest gaps. Prepare a management body dashboard showing test coverage, major findings, overdue actions, third-party issues and residual risk.

Output: board-ready DORA and ISO testing dashboard.

Common DORA testing programme pitfalls

The most common failure is not lack of testing. It is lack of governance.

Watch for these issues:

• Penetration tests performed annually, but findings not tracked to closure
• Vulnerability scans run frequently, but critical assets missing from scope
• Tabletop exercises held, but no decision log or lessons-learned action plan
• Backup restore tests completed, but not mapped to RTO and RPO
• Load tests run by engineering, but not reported to risk or compliance
• ICT providers excluded from scenario and recovery tests
• Evidence stored in personal folders, chat threads or unmanaged drives
• Board reports focused on activity counts rather than unresolved resilience risk
• SoA says a control applies, but no test evidence exists
• Testing creates production risk because authorization and boundaries are unclear

Each gap is solvable. The remedy is not more random testing. The remedy is one controlled programme that links risk, test activity, remediation, evidence and management oversight.

What the board should actually see

DORA makes ICT resilience a management body responsibility. A useful board report should not include every technical finding. It should answer whether the organization is resilient enough against its risk appetite and disruption tolerance.

A strong quarterly or semi-annual report includes:

• Test coverage against critical or important functions
• Completed versus planned tests
• Critical and high findings by service
• Overdue remediation by owner
• Retest pass rate
• Supplier-related findings and concentration concerns
• Scenario test lessons affecting crisis or incident plans
• Capacity risks against business growth and peak periods
• Residual risks requiring management acceptance
• Budget, resource or tooling constraints

This report becomes ISO management review input, DORA governance evidence and a practical decision tool.

From scattered tests to strategic resilience

The CISO’s original problem was not that testing was missing. The organization had scans, tabletops, load reports and penetration test PDFs. The problem was that these activities did not yet tell one coherent evidence story.

A unified DORA and ISO/IEC 27001:2022 testing programme changes that. The risk assessment drives the catalogue. The catalogue drives authorized testing. Testing produces findings. Findings drive remediation and retesting. Results feed management reporting. Lessons learned update policies, procedures, contracts and controls.

That is how a compliance burden becomes a strategic capability.

Clarysec helps organizations avoid parallel compliance programmes. DORA, ISO/IEC 27001:2022, NIS2, GDPR, NIST CSF 2.0 and COBIT 2019 do not need separate evidence universes. They need a single, governed operating model that can be presented through different audit lenses.

Our approach combines:

• The Zenith Blueprint for phased ISO implementation and audit readiness
• Zenith Controls for cross-compliance mapping across controls, frameworks and audit expectations
• Enterprise and SME policies for security testing, audit monitoring, vulnerability management, application security, continuity and information security
• Practical registers, evidence structures and management reporting templates

If your 2026 DORA testing evidence is scattered across scan tools, engineering folders, tabletop notes and penetration test PDFs, now is the time to consolidate it.

Start with one annual test catalogue mapped to ISO/IEC 27001:2022 risk treatment, your SoA, critical or important functions, ICT third parties and management reporting. Then use Clarysec’s Zenith Blueprint, Zenith Controls and policy toolkit to turn that catalogue into defensible audit evidence.

Clarysec can help you design the programme, map the controls, structure the evidence pack and prepare the board-level resilience report before the next supervisory request lands.