DORA TLPT Evidence with ISO 27001 Controls

It is 07:40 on a Monday morning and the CISO of a mid-sized payment institution is staring at three versions of the same uncomfortable question.

The board wants to know whether the organization can survive a ransomware-driven outage of its customer payment portal. The regulator wants proof that digital operational resilience testing is not a PowerPoint exercise. Internal audit wants a clean trail from DORA obligations to ICT risk, ISO 27001 controls, test results, remediation plans, supplier evidence, and management sign-off.

The CISO has a red-team report. The SOC has alert screenshots. Infrastructure has a backup restoration log. Legal has a DORA readiness tracker. Procurement has cloud provider attestations.

None of it is connected.

This is where many DORA TLPT and resilience testing programmes fail. Not because the testing is weak, but because the evidence is fragmented. When an auditor asks, “Show me how this test proves resilience of a critical or important function,” the answer cannot be a folder full of screenshots. It must be a defensible chain of evidence.

That chain is where an ISO/IEC 27001:2022-aligned ISMS ISO/IEC 27001:2022 becomes powerful. ISO 27001 gives structure to scope, risk assessment, control selection, Statement of Applicability, operational control, internal audit, management review, and continual improvement. DORA supplies the sector-specific pressure. Clarysec’s methodology and cross-compliance tooling connect both into a single audit-ready evidence model.

DORA TLPT is a governance test, not only an attack simulation

Threat-led penetration testing, or TLPT, is easy to misunderstand. Technically, it may look like a sophisticated red-team exercise: threat intelligence, realistic attack paths, stealth, exploitation attempts, lateral movement scenarios, and blue-team response validation.

For DORA, the deeper issue is digital operational resilience. Can the financial entity withstand, respond to, and recover from severe ICT disruption affecting business processes? Can it prove that critical or important functions remain within impact tolerances? Can management demonstrate that ICT risk is governed, funded, tested, remediated, and improved?

DORA Article 1 establishes a uniform EU framework for the security of network and information systems supporting financial entities’ business processes. It covers ICT risk management, major ICT-related incident reporting, digital operational resilience testing, ICT third-party risk management, mandatory ICT supplier contract requirements, oversight of critical ICT third-party providers, and supervisory cooperation. DORA applies from 17 January 2025.

For organizations also covered by NIS2, DORA acts as the sector-specific Union legal act for overlapping cybersecurity requirements. In practical terms, financial entities should prioritize DORA for ICT risk management, incident reporting, testing, and ICT third-party risk where the regimes overlap, while still understanding NIS2 expectations for group structures, suppliers, and non-financial digital services.

DORA also places accountability at the top. Article 5 requires the management body to define, approve, oversee, and implement ICT risk arrangements. That includes the digital operational resilience strategy, ICT business continuity policy, response and recovery plans, audit plans, budgets, ICT third-party policies, reporting channels, and sufficient ICT risk knowledge through regular training.

So the audit question is not simply, “Did you run a TLPT?”

It is:

• Was the TLPT linked to critical or important functions?
• Was it authorized, scoped, safe, and risk-assessed?
• Were suppliers, cloud dependencies, and outsourced ICT services included where relevant?
• Did the test generate evidence of detection, response, recovery, and lessons learned?
• Were findings converted into risk treatment, tracked remediation, retesting, and management reporting?
• Did the Statement of Applicability explain which ISO 27001 Annex A controls were selected to manage the risk?

That is why Clarysec treats DORA TLPT evidence as an ISMS evidence problem, not only as a penetration testing deliverable.

Build the ISO 27001 evidence spine before the test starts

ISO 27001 requires an organization to establish, implement, maintain, and continually improve an ISMS that preserves confidentiality, integrity, and availability through a risk management process. Clauses 4.1 to 4.4 require the organization to understand internal and external issues, interested parties, legal and regulatory obligations, interfaces, dependencies, and then document the ISMS scope.

For a DORA-regulated entity, this scoping step should explicitly capture critical or important functions, ICT assets, cloud platforms, outsourced operations, payment systems, customer portals, identity services, logging platforms, recovery environments, and ICT third-party service providers. If the TLPT scope does not map back to the ISMS scope, the audit trail is already weak.

ISO 27001 Clauses 6.1.1, 6.1.2 and 6.1.3, together with Clauses 8.2 and 8.3, require a risk assessment and risk treatment process. Risks must be identified against confidentiality, integrity, and availability. Risk owners must be assigned. Likelihood and consequence must be assessed. Controls must be selected and compared against Annex A. Residual risk must be accepted by risk owners.

This is the bridge between DORA and audit-ready testing.

Clarysec’s Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, in the Risk Management phase, Step 13, describes this traceability role clearly:

The SoA is effectively a bridging document : it links your risk assessment/treatment to the actual controls you have. By completing it, you also double-check if you missed any controls.

For DORA TLPT, the Statement of Applicability should not be a static certification artifact. It should explain why controls such as supplier security, incident management, ICT readiness for business continuity, logging, monitoring, technical vulnerability management, backups, secure development, and security testing are applicable to the resilience scenario.

A practical risk scenario might read:

“Compromise of privileged identity provider credentials allows an attacker to access payment processing administration systems, alter routing configurations, and disrupt a critical payment function, causing service outage, regulatory reporting obligations, customer harm, and reputational damage.”

That single scenario can drive the TLPT scope, detection use cases, supplier involvement, recovery drill, board reporting, and evidence set.

The Zenith Blueprint also recommends making regulatory traceability explicit:

Cross-reference regulations: If certain controls are implemented specifically to comply with GDPR, NIS2, or DORA, you can note that in either the Risk Register (as part of risk impact justification) or in the SoA notes.

That advice is simple, but it changes the audit conversation. Instead of telling an auditor that DORA was considered, the organization can show where DORA appears in the risk register, SoA, testing programme, policy set, and management review.

Map DORA testing to ISO 27001 controls that auditors recognize

DORA Article 6 expects a documented ICT risk management framework integrated into overall risk management. ISO 27001 Annex A gives the control catalogue that makes this operational.

For DORA TLPT and resilience testing, these ISO/IEC 27001:2022 Annex A controls are especially important:

Clarysec’s Zenith Controls: The Cross-Compliance Guide Zenith Controls helps organizations avoid treating these controls as isolated checklist items. It maps ISO/IEC 27002:2022 controls to attributes, domains, operational capabilities, audit expectations, and cross-framework patterns.

For example, Zenith Controls classifies ISO/IEC 27002:2022 control 5.30, ICT readiness for business continuity, as “Corrective”, aligned to “Availability”, associated with the “Respond” cybersecurity concept, and placed in the “Resilience” domain. That classification is useful when explaining to auditors why a recovery drill is not just an IT operation, but a resilience control with a defined role in the control environment.

Zenith Controls also classifies control 8.29, Security Testing in Development and Acceptance, as a preventive control supporting confidentiality, integrity, and availability, with operational capabilities in application security, information security assurance, and system and network security. For TLPT findings that trace back to application design weakness, insecure API behavior, poor authentication flow, or inadequate validation, this is the control pathway into secure development governance.

Control 5.35, Independent Review of Information Security, is also important. It supports independent challenge, governance assurance, and corrective improvement. Internal teams may coordinate testing, but audit-ready evidence requires review, escalation, and oversight beyond the people who built or operated the tested systems.

Protect the system while testing it

One dangerous assumption in resilience testing is that testing is automatically good. In reality, intrusive testing can create outages, expose sensitive data, pollute logs, trigger automated defences, break customer sessions, or cause suppliers to invoke emergency procedures.

Clarysec’s Security Testing and Red-Teaming Policy Security Testing and Red-Teaming Policy gives organizations a governance pattern for safe execution. Clause 6.1 states:

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.

For TLPT, the red-teaming element is obvious, but the audit value comes from the programme design. Vulnerability scanning, penetration testing, red-team exercises, resilience drills, and retesting should form a cycle, not a collection of disconnected tests.

Clause 6.2 of the same policy addresses safe execution:

Scope and Rules of Engagement: For each test or exercise, the STC shall define the scope, including systems and IP ranges in scope, permitted test methods, objectives, timing, and duration. Rules of engagement must be documented. For example, operationally sensitive systems may be designated as monitor-only to avoid disruption, and any testing in production must include rollback and stop procedures. Safety measures, such as defined time windows and communication channels, shall be established to prevent unintended service outages.

This maps directly to Zenith Blueprint, Controls in Action phase, Step 21, which focuses on ISO 27001 Annex A control 8.34, Protection of Information Systems during Audit Testing. The Zenith Blueprint warns that audits, penetration tests, forensic reviews, and operational evaluations can involve elevated access, intrusive tools, or temporary changes to system behavior. It emphasizes authorization, scope, time windows, system-owner approval, rollback, monitoring, and secure handling of test data.

The audit-ready evidence bundle should include:

• TLPT charter and objectives
• Threat intelligence summary and scenario rationale
• Critical or important functions in scope
• Systems, IP ranges, identities, suppliers, and environments in scope
• Exclusions and monitor-only systems
• Rules of engagement
• Production testing risk assessment
• Rollback and stop procedures
• SOC notification model, including what is disclosed and withheld
• Legal, privacy, and supplier approvals
• Test account creation and revocation evidence
• Secure storage location for test artifacts and logs

A DORA TLPT that cannot show safe authorization and control of test activity may reveal resilience gaps, but it also creates governance gaps.

Turn TLPT output into risk treatment

The most common post-test failure is the red-team report shelf problem. A high-quality report is delivered, circulated, discussed, and then slowly loses energy. Findings remain open. Compensating controls are not documented. Accepted risks are informal. Retesting never happens.

The Security Testing and Red-Teaming Policy makes this unacceptable. Clause 6.6 states:

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.

Clause 6.7 adds the governance layer:

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. For red-teaming exercises, the report shall detail the scenarios, which attack paths were successful, what was detected by the Blue Team, and lessons learned regarding detection and response gaps. The CISO shall present summarised results and remediation status to senior management and, where relevant, include them in the annual security report to the Board of Directors.

This aligns with ISO/IEC 27005:2022 risk treatment guidance: select treatment options, determine controls from ISO 27001 Annex A and sector-specific requirements, build a risk treatment plan, assign accountable persons, define timelines, track status, obtain risk-owner approval, and document residual-risk acceptance.

Every significant TLPT finding should become one of four things: a remediation action, a control improvement, a formal risk acceptance, or a retest requirement.

The goal is not to produce more documents. The goal is to make every document explain the next decision.

Resilience testing must prove recovery, not only detection

A successful TLPT may show that the SOC detected command-and-control traffic, blocked lateral movement, and escalated correctly. That is valuable, but DORA resilience testing goes further. It asks whether the organization can continue or recover business services.

The Zenith Blueprint, Controls in Action phase, Step 23, explains control 5.30, ICT Readiness for Business Continuity, in language every CISO should use with the board:

From an audit standpoint, this control is often tested with a single phrase: Show me. Show me the last test result. Show me the recovery documentation. Show me how long it took to fail over and back. Show me the evidence that what’s been promised can be delivered.

That “Show me” standard is the difference between policy maturity and operational resilience.

Clarysec’s Business Continuity Policy and Disaster Recovery Policy-sme Business Continuity Policy and Disaster Recovery Policy - SME, from section “Policy Implementation Requirements”, clause 6.4.1, states:

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

The same policy’s enforcement section, clause 8.5.1, makes evidence accountability explicit:

The GM must ensure the following are maintained and audit-ready:

For a DORA-regulated financial entity, annual testing may be the floor, not the ambition. Higher-risk critical or important functions should be tested more frequently, especially after architecture changes, cloud migration, major incidents, new ICT suppliers, material application releases, or changes in threat exposure.

A strong resilience test evidence pack should include:

• Business impact analysis mapping the critical or important function
• RTO and RPO approved by business owners
• System dependency map, including identity, DNS, network, cloud, database, monitoring, backup, and third-party services
• Backup and restoration test results
• Failover and failback timestamps
• Evidence of security controls operating during disruption
• Customer, regulator, and internal communication templates
• Incident commander and crisis team participation logs
• Lessons learned and improvement actions
• Retest evidence for previous recovery gaps

This is also where GDPR enters the story. GDPR Articles 2 and 3 bring most SaaS and fintech processing of EU personal data into scope. Article 4 defines personal data, processing, controller, processor, and personal data breach. Article 5 requires integrity, confidentiality, and accountability, meaning the organization must be able to demonstrate compliance. If TLPT or recovery testing uses production personal data, copies logs containing identifiers, or validates breach response, privacy safeguards must be documented.

Supplier evidence is the DORA blind spot auditors will not ignore

Modern financial services are assembled from cloud platforms, SaaS applications, managed security providers, payment processors, data platforms, identity providers, observability tools, outsourced development teams, and backup providers.

DORA Article 28 requires financial entities to manage ICT third-party risk as part of the ICT risk management framework and remain fully responsible even where ICT services are outsourced. Article 30 requires written ICT service contracts with service descriptions, subcontracting conditions, processing locations, data protection, access and recovery, service levels, incident assistance, cooperation with authorities, termination rights, stronger terms for critical or important functions, audit rights, security measures, TLPT participation where relevant, and exit arrangements.

This means a TLPT scenario cannot stop at the organization’s firewall if the critical function depends on a supplier.

Clarysec’s Third-Party and Supplier Security Policy-sme Third-Party and Supplier Security Policy - SME, from section “Policy Implementation Requirements”, clause 6.3.1, states:

Critical or high-risk suppliers must be reviewed at least annually. The review must verify:

The Security Testing and Red-Teaming Policy adds a testing-specific supplier requirement in clause 6.9:

Third-Party Testing Coordination: Where any critical supplier or service provider falls within the scope of the organisation’s overall security, in accordance with the Third-Party and Supplier Security Policy, the organisation shall, where feasible, obtain assurance regarding their security testing practices or coordinate joint testing. For example, where a Cloud Service Provider (CSP) is used, the organisation may rely on its penetration testing reports or include it in collaborative red-team scenarios, subject to contractual provisions.

For audit-ready DORA evidence, supplier assurance should be linked to the same risk scenario as the TLPT. If the identity provider is essential to payments recovery, the evidence pack should include supplier due diligence, contractual security requirements, incident support terms, testing coordination, assurance reports, service level evidence, exit strategy, and constraints on testing.

NIS2 Article 21 also matters for SaaS, cloud, managed service, managed security, data centre, CDN, trust service, DNS, TLD, online marketplace, search, and social networking providers. It requires an all-hazards approach covering risk analysis, incident handling, business continuity, supply chain security, secure development, effectiveness assessment, training, cryptography, access control, asset management, MFA, and secure communications.

The practical result is simple: financial entities should build one evidence model that satisfies DORA first, then cross-reference NIS2 expectations where suppliers, group entities, or non-financial digital services are involved.

A practical Clarysec TLPT evidence ledger

Assume the scenario is:

“A threat actor compromises an administrator account at a SaaS support platform, pivots into the payment operations environment, modifies configuration, and disrupts transaction processing.”

Create an evidence ledger with one row per evidence object. Do not wait until the test ends. Populate it during planning, execution, remediation, and closure.

Then use Zenith Blueprint Step 13 to add traceability into the risk register and Statement of Applicability. Each evidence item should connect to a risk scenario, risk owner, selected control, treatment plan, and residual-risk decision.

If a finding relates to software weakness, cite secure development and testing controls. Clarysec’s Secure Development Policy-sme Secure Development Policy - SME, from section “Policy Implementation Requirements”, clause 6.5.2, requires:

Testing must be documented with:

If a finding produces forensic material, preserve chain of custody. Clarysec’s Evidence Collection and Forensics Policy-sme Evidence Collection and Forensics Policy - SME, from section “Governance Requirements”, clause 5.2.1, states:

Each item of digital evidence must be logged with:

This is the point many teams miss. Evidence is not only final reports. It is the controlled record of who approved, who executed, what happened, what was detected, what was recovered, what was changed, what remains exposed, and who accepted that exposure.

How auditors inspect the same TLPT evidence

DORA TLPT evidence will be read differently depending on the auditor’s background. Clarysec designs evidence packs so each lens can find what it needs without forcing teams to duplicate work.

COBIT 2019 appears in the Zenith Blueprint cross-compliance reference for safe audit and testing execution, including DSS05.03 and MEA03.04. The relevance is not that COBIT replaces DORA or ISO 27001, but that ISACA-style assurance professionals will look for controlled execution, monitoring, evaluation, and compliance evidence.

The board narrative: what management must approve

Board reporting should avoid technical theater. The board does not need exploit payloads. It needs decision-grade evidence:

• Which critical or important function was tested?
• What threat scenario was simulated and why?
• Did detection work?
• Did response escalation work?
• Did recovery meet RTO and RPO?
• Which suppliers were involved or constrained?
• What material weaknesses remain?
• What is the remediation cost, owner, and timeline?
• Which residual risks require formal acceptance?
• What will be retested?

This is where ISO 27001 Clause 5 becomes important. Top management must ensure the information security policy and objectives are established, aligned with strategic direction, integrated into business processes, resourced, communicated, and continually improved. Roles and responsibilities must be assigned. Objectives must be measurable where practicable and take account of applicable requirements and risk treatment results.

If TLPT identifies that recovery time is six hours against a four-hour business tolerance, this is not merely an infrastructure backlog item. It is a management decision involving risk appetite, budget, customer commitments, regulatory exposure, contracts, architecture, and operational capacity.

Common evidence failures in DORA resilience testing

Clarysec reviews often find the same evidence gaps across financial entities and ICT service providers preparing for DORA.

First, the TLPT scope does not map to critical or important functions. The test may be technically impressive, but it does not prove resilience of the business process regulators care about.

Second, supplier dependencies are acknowledged but not evidenced. Teams say the cloud provider, managed SOC, or SaaS platform is in scope, yet contracts, audit rights, testing permissions, incident support terms, and exit plans are missing.

Third, testing creates evidence but not treatment. Findings remain in a red-team report rather than being converted into risk register updates, control changes, owners, dates, retesting, and residual-risk decisions.

Fourth, recovery is assumed rather than demonstrated. Backup policies exist, but no one can show failover timestamps, restoration integrity checks, access validation, or business-owner confirmation.

Fifth, privacy and forensic evidence are uncontrolled. Logs and screenshots contain personal data, test artifacts are stored in shared drives, temporary accounts remain active, and evidence chain-of-custody is incomplete.

Sixth, management reporting is too technical. Senior leaders cannot see whether resilience improved, whether risk is within appetite, or what investment decisions are needed.

Every one of these gaps can be solved by treating DORA TLPT as a structured ISO 27001 evidence workflow.

Clarysec’s integrated approach to audit-ready resilience

Clarysec’s approach combines three layers.

The first layer is the Zenith Blueprint 30-step implementation roadmap. For this topic, Step 13 builds risk treatment and SoA traceability, Step 21 protects systems during audit testing, and Step 23 validates ICT readiness for business continuity. These steps turn TLPT from a technical event into a documented governance cycle.

The second layer is Clarysec’s policy library. The Security Testing and Red-Teaming Policy defines testing types, scope, rules of engagement, remediation, reporting, and supplier coordination. The Business Continuity Policy and Disaster Recovery Policy-sme sets expectations for annual BCP and DR testing and audit-ready continuity evidence. The Third-Party and Supplier Security Policy-sme supports supplier assurance. The Secure Development Policy-sme ensures security testing is documented. The Evidence Collection and Forensics Policy-sme supports evidence logging and chain-of-custody discipline.

The third layer is Zenith Controls, Clarysec’s cross-compliance guide. It helps map ISO/IEC 27002:2022 controls to attributes, domains, operational capabilities, and cross-framework expectations. For DORA TLPT, the most important pattern is not one control. It is the relationship between testing, continuity, incident management, supplier management, logging, monitoring, secure development, independent review, and governance.

When these layers work together, the CISO’s Monday morning problem changes. Instead of three disconnected questions from the board, regulator, and internal audit, the organization has one evidence story:

“We identified the critical function. We assessed the ICT risk. We selected and justified controls. We authorized and safely executed TLPT. We detected, responded, and recovered. We involved suppliers where required. We documented evidence. We remediated findings. We retested. Management reviewed and accepted the remaining risk.”

That is audit-ready resilience.

Next steps

If your DORA TLPT programme is still organized around reports rather than evidence chains, start with a Clarysec evidence walkthrough.

Use Zenith Blueprint Zenith Blueprint Step 13 to connect TLPT scenarios to risks, controls, and the Statement of Applicability. Use Step 21 to verify safe authorization, rules of engagement, rollback, monitoring, and cleanup. Use Step 23 to prove ICT readiness for business continuity with recovery evidence.

Then align your operating documents with Clarysec’s Security Testing and Red-Teaming Policy Security Testing and Red-Teaming Policy, Business Continuity Policy and Disaster Recovery Policy-sme Business Continuity Policy and Disaster Recovery Policy - SME, Third-Party and Supplier Security Policy-sme Third-Party and Supplier Security Policy - SME, Secure Development Policy-sme Secure Development Policy - SME, and Evidence Collection and Forensics Policy-sme Evidence Collection and Forensics Policy - SME.

Finally, use Zenith Controls Zenith Controls to cross-map your DORA TLPT evidence to ISO 27001 controls, NIS2, GDPR, COBIT 2019, and auditor expectations.

If you want your next resilience test to produce more than findings, use Clarysec to turn it into a defensible evidence chain. Download the toolkits, schedule an evidence-readiness assessment, or request a walkthrough of how Clarysec maps DORA TLPT to ISO 27001:2022 controls from planning through board approval.