ISO 27001 Audit Evidence for NIS2 and DORA

It is 08:17 on a Tuesday, and the CISO of a fast-growing fintech SaaS company has three messages waiting.

The first is from a major banking customer: “Please send your latest internal audit report, management review minutes, corrective action status, incident reporting procedure, supplier register and evidence of board oversight.”

The second is from the CFO: “Are we NIS2 or DORA in scope, and what evidence do we already have?”

The third is from the CEO: “Can we say we are audit-ready?”

The uncomfortable answer in many organizations is not that nothing is happening. It is worse. Security work is happening everywhere, but evidence is nowhere. There are controls, but no audit trail. There are tickets, but no clear linkage to risks. There are leadership updates, but no formal management review outputs. There are supplier discussions, but no defensible supplier register, contract review or exit strategy.

That gap is exactly where ISO/IEC 27001:2022 internal audit and management review become more than certification activities. They become the operating rhythm for NIS2, DORA, GDPR, customer assurance, cyber insurance and board accountability.

SaaS, cloud, MSP, MSSP and fintech teams rarely fail because they lack security activity. They fail because activity is scattered across Slack, Jira, spreadsheets, vendor portals, SOC tickets, procurement files and board decks. A regulator, external auditor or enterprise customer does not want a heroic explanation. They want objective evidence.

The practical solution is not to run separate audit programs for every framework. It is to use the ISO 27001 ISMS as the central evidence engine, then tag that evidence for NIS2, DORA, GDPR and contractual requirements. Done well, one internal audit and one management review cycle can answer many compliance questions.

From framework fatigue to a unified ISMS evidence model

Many CISOs face a version of Maria’s problem. Maria leads security for a B2B SaaS company with financial-sector customers. Her team passed an ISO/IEC 27001:2022 certification audit six months ago. The ISMS is maturing, policies are being followed and control owners understand their responsibilities. Then the CEO forwards two articles, one on the NIS2 Directive and one on DORA, with a short question: “Are we covered?”

The answer depends on scope, services, customers and legal entities. But the operational answer is clear: if Maria treats NIS2 and DORA as separate compliance projects, she will create duplicate work, inconsistent evidence and spiraling audit fatigue. If she treats them as requirements from interested parties within the ISMS, she can use ISO 27001 to absorb, test and prove readiness.

ISO/IEC 27001:2022 is designed for this. Clause 4 requires the organization to understand its context and interested-party requirements, including legal, regulatory, contractual and dependency-driven obligations. Clause 5 requires leadership and integration into business processes. Clause 6 requires risk assessment and risk treatment. Clause 9 requires performance evaluation through monitoring, internal audit and management review. Clause 10 requires improvement and corrective action.

NIS2 and DORA fit naturally into that structure.

NIS2 requires essential and important entities to implement appropriate and proportionate technical, operational and organizational cybersecurity risk-management measures. It also places responsibility on management bodies to approve those measures, oversee implementation and be capable of being held liable for infringements. Its minimum measures cover risk analysis, incident handling, business continuity, supply chain security, secure development, vulnerability handling, effectiveness assessment, training, cryptography, HR security, access control, asset management and, where appropriate, multi-factor authentication or continuous authentication.

DORA applies from 17 January 2025 and creates a sector-specific digital operational resilience regime for financial entities. It requires management body responsibility for ICT risk management, a documented ICT risk management framework, digital operational resilience strategy, ICT continuity and recovery plans, resilience testing, ICT incident governance and ICT third-party risk management. For SaaS and cloud providers serving financial entities, DORA may appear through contractual obligations, customer audits and ICT third-party risk management expectations, even when the provider is not itself a financial entity.

GDPR adds the accountability layer. Where personal data is processed in scope of GDPR, organizations must be able to demonstrate compliance with data protection principles and appropriate technical and organizational measures.

ISO 27001 is not a magic compliance certificate for these obligations. It is the management system that can organize, evidence and improve them.

The scope question: what are you proving, and for whom?

Before building an audit-ready evidence pack, leadership must answer a basic question: which obligations are in scope?

For SaaS and cloud businesses, NIS2 scope can be broader than expected. NIS2 applies to public or private entities in listed sectors that meet size thresholds, and to certain high-impact entities regardless of size. Relevant sectors may include digital infrastructure, cloud computing providers, data centre providers, content delivery networks, trust service providers, public electronic communications providers and ICT service management B2B providers such as managed service providers and managed security service providers. SaaS providers should pay close attention to how services are delivered, which sectors they support and whether they enable on-demand administration and broad remote access to scalable shared computing resources.

For fintech and financial-sector service providers, DORA must be analyzed separately. DORA directly covers a broad range of financial entities, including credit institutions, payment institutions, account information service providers, electronic money institutions, investment firms, crypto-asset service providers, trading venues, fund managers, insurance and reinsurance undertakings and crowdfunding service providers. ICT third-party service providers are also part of the DORA ecosystem because financial entities must manage their ICT dependencies, maintain registers of contractual arrangements and include specific contractual provisions for ICT services supporting critical or important functions.

NIS2 and DORA also interact. Where a sector-specific EU legal act imposes equivalent cybersecurity risk-management or incident notification requirements, the corresponding NIS2 provisions may not apply to those entities for those areas. DORA is the sector-specific operational resilience regime for financial entities. That does not make NIS2 irrelevant to all surrounding providers. It means the evidence model must distinguish whether the organization is a financial entity directly subject to DORA, an ICT third-party service provider supporting financial entities, a SaaS provider in NIS2 scope or a group with multiple legal entities and service lines.

This scope analysis belongs in the ISMS context and interested-party register. Without it, the audit plan will test the wrong things.

One audit trail, many compliance questions

A common mistake is to create separate evidence packs for ISO 27001, NIS2, DORA, GDPR, cyber insurance and customer audits. That approach creates duplication and conflicting answers. A better approach is one evidence model with multiple lenses.

At the center is the ISMS. Around it sit five evidence families.

This structure aligns with Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint. In the Audit, Review & Improvement phase, Step 25 focuses on the internal audit program, Step 26 on audit execution, Step 28 on management review and Step 29 on continual improvement.

The Blueprint’s Step 25 guidance is deliberately practical:

“Develop a schedule that outlines when audits will occur and what they will cover.”

“Use the Internal Audit Plan template if provided, this might be a simple document or spreadsheet that lists audit dates, scope, and assigned auditors.”

From Zenith Blueprint, Audit, Review & Improvement phase, Step 25: Internal Audit Program Zenith Blueprint

That simple audit plan becomes powerful when it is risk-based and tagged to NIS2, DORA and GDPR obligations.

ISO 27001 controls that anchor audit readiness

For audit readiness, three ISO/IEC 27002:2022 controls are especially important when interpreted through Zenith Controls: The Cross-Compliance Guide Zenith Controls:

• 5.4 Management responsibilities
• 5.35 Independent review of information security
• 5.36 Compliance with policies, rules and standards for information security

These are not separate “Zenith controls.” They are ISO/IEC 27002:2022 controls that Zenith Controls helps map, audit and interpret across frameworks.

Control 5.4 asks whether information security responsibilities are assigned and understood. Control 5.35 asks whether information security is independently reviewed. Control 5.36 asks whether the organization complies with its policies, rules and standards.

Zenith Controls classifies control 5.35 in an assurance-oriented way:

ISO/IEC 27002:2022 control 5.35, “Independent Review of Information Security,” is treated in Zenith Controls as “Preventive, Corrective,” supporting confidentiality, integrity and availability through the cybersecurity concepts “Identify” and “Protect,” with operational capability in “Information Security Assurance.” Zenith Controls

This matters because internal audit is both preventive and corrective. It prevents blind spots by testing the ISMS before external scrutiny, and it corrects weaknesses through documented actions.

The wider crosswalk starts with NIS2 and DORA requirements and then identifies the ISO 27001 evidence that can prove them.

Control mapping is useful only when evidence is strong. If the record is weak, no crosswalk will save it. If the record is complete, the same evidence can answer ISO, NIS2, DORA, GDPR, NIST Cybersecurity Framework 2.0 and COBIT 2019 style questions.

Policy evidence Clarysec expects organizations to retain

Clarysec’s policies turn ISMS theory into evidence expectations.

For SMEs, Audit and Compliance Monitoring Policy-sme Audit and Compliance Monitoring Policy-sme requires leadership approval and audit discipline:

“The General Manager (GM) must approve an annual audit plan.”

From Audit and Compliance Monitoring Policy-sme, Governance Requirements, clause 5.1.1 Audit and Compliance Monitoring Policy-sme

It also sets a minimum cadence:

“Internal audits or compliance reviews must be conducted at least annually.”

From Audit and Compliance Monitoring Policy-sme, Governance Requirements, clause 5.2.1

And it connects findings to correction and management review:

“The GM must approve a corrective action plan and track its implementation.”

From Audit and Compliance Monitoring Policy-sme, Governance Requirements, clause 5.4.2

“Audit findings and status updates must be included in the ISMS management review process.”

From Audit and Compliance Monitoring Policy-sme, Governance Requirements, clause 5.4.3

Evidence retention is also explicit:

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

From Audit and Compliance Monitoring Policy-sme, Policy Implementation Requirements, clause 6.2.4

For larger organizations, Audit and Compliance Monitoring Policy Audit and Compliance Monitoring Policy, also referenced in some Clarysec materials as the P33 Audit and Compliance Monitoring Policy, expands the structure:

“A risk-based Audit Plan shall be developed and approved annually, taking into account:”

From Audit and Compliance Monitoring Policy, Governance Requirements, clause 5.2 Audit and Compliance Monitoring Policy

“The organization shall maintain an Audit Register containing:”

From Audit and Compliance Monitoring Policy, Governance Requirements, clause 5.4

“Internal audits shall follow a documented procedure including:”

From Audit and Compliance Monitoring Policy, Policy Implementation Requirements, clause 6.1.1

“All findings shall result in a documented CAPA that includes:”

From Audit and Compliance Monitoring Policy, Policy Implementation Requirements, clause 6.2.1

Management review is anchored in Information Security Policy Information Security Policy, also referenced in some Clarysec materials as P01 Information Security Policy:

“Management review activities (per ISO/IEC 27001 Clause 9.3) shall be conducted at least annually and shall include:”

From Information Security Policy, Governance Requirements, clause 5.3 Information Security Policy

These requirements create the evidence chain auditors expect: approved plan, defined procedure, audit register, findings, CAPA, retention and leadership review.

Building the audit-ready evidence pack

An audit-ready evidence pack is not a giant folder created two days before the audit. It is a living structure maintained throughout the year.

The evidence pack should be mapped to ISO/IEC 27001:2022 clauses and Annex A controls, but tagged for regulatory relevance. A supplier audit record, for example, may support Annex A supplier controls, NIS2 supply chain security and DORA ICT third-party risk management. An incident tabletop record may support ISO 27001 incident management, NIS2 staged notification readiness and DORA major ICT-related incident governance.

How to perform the integrated internal audit

Step 26 of Zenith Blueprint emphasizes objective evidence:

“Perform the audit by collecting objective evidence for each item on your checklist.”

“Interview relevant personnel.”

“Review documentation.”

“Observe practices.”

“Sample and spot-check.”

From Zenith Blueprint, Audit, Review & Improvement phase, Step 26: Audit Execution Zenith Blueprint

That is exactly what NIS2 and DORA readiness requires. Regulators and customers will not accept “we believe this works.” They will ask how you know.

A well-run audit tests four evidence dimensions.

Consider a simulated ransomware event on a staging server. The auditor tests whether the incident response process can meet ISO 27001 requirements, NIS2 staged reporting expectations and DORA customer obligations.

NIS2 has a staged reporting structure for significant incidents, including early warning within 24 hours of awareness, incident notification within 72 hours and a final report within one month of the incident notification. DORA has its own ICT-related incident classification and reporting framework for financial entities. The internal audit should verify that playbooks capture awareness time, severity criteria, affected services, indicators of compromise, mitigation actions, root cause, customer notification duties and final reporting data.

Turning one audit finding into NIS2 and DORA evidence

A realistic supplier finding shows how evidence should flow.

During the internal audit, the auditor samples five critical suppliers. One cloud logging provider supports fraud monitoring and security alerting for the fintech platform. The supplier is listed in the inventory, but there is no documented exit plan, no evidence of annual security review and no confirmation that the contract includes incident assistance or audit rights.

The auditor records a nonconformity against supplier security and cloud exit requirements. A weak response would say “supplier review missing.” A strong response creates a cross-compliance evidence chain:

1. Record the finding in the audit report, including sample size, supplier name, contract reference and missing evidence.
2. Add a CAPA entry with root cause, such as “supplier onboarding checklist did not include criticality classification or exit-plan trigger.”
3. Assign the supplier owner and risk owner.
4. Update the supplier register to flag the service as supporting a critical or important function.
5. Perform a risk assessment covering service interruption, data access, concentration risk, incident reporting dependency and contractual gaps.
6. Update the risk treatment plan and Statement of Applicability where relevant.
7. Obtain an updated contract addendum or documented risk acceptance.
8. Create or test an exit plan.
9. Re-audit the supplier evidence after remediation.
10. Report the finding, risk and resource needs in management review.

This single chain supports multiple obligations. NIS2 expects supply chain security and consideration of supplier vulnerabilities, cybersecurity practices and secure development procedures. DORA requires financial entities to manage ICT third-party risk, maintain registers of contractual arrangements, assess providers before contracting, include audit and inspection rights where appropriate, maintain termination rights and document exit strategies for ICT services supporting critical or important functions. GDPR may also be relevant if the supplier processes personal data.

The audit record is no longer just compliance evidence. It is resilience evidence.

Management review: where evidence becomes accountability

Internal audit finds the truth. Management review decides what to do about it.

Step 28 of Zenith Blueprint describes the management review input pack:

“ISO 27001 specifies several required inputs to the management review. Prepare a brief report or presentation covering these points.”

The Blueprint lists status of previous actions, changes in external and internal issues, ISMS performance and effectiveness, incidents or nonconformities, opportunities for improvement and resource needs.

From Zenith Blueprint, Audit, Review & Improvement phase, Step 28: Management Review Zenith Blueprint

For NIS2 and DORA, management review is where board-level accountability becomes visible. The review should not say only “security was discussed.” It should show that leadership reviewed:

• Changes in NIS2, DORA, GDPR, customer and contractual requirements.
• Scope changes, including new countries, products, regulated customers or ICT dependencies.
• Internal audit results, including major and minor nonconformities.
• Status of CAPAs and overdue actions.
• Security objectives and metrics.
• Incident trends, near misses and lessons learned.
• Supplier and cloud concentration risks.
• Business continuity and backup test results.
• Vulnerability and patching performance.
• Resource needs, including people, tooling, training and budget.
• Residual risks requiring formal acceptance.
• Improvement decisions and accountable owners.

This is where Maria can turn a technical report into strategic assurance. Instead of saying “we found one incident process gap,” she can say: “The audit identified one minor nonconformity in our NIS2 incident reporting decision criteria. The CAPA updates the procedure, adds a decision matrix and requires a tabletop exercise within 30 days. We need management approval for legal review and training time.”

That is the kind of record that supports governance, oversight and defensible decision-making.

Corrective action: the difference between a finding and maturity

An internal audit without corrective action is only a diagnosis.

Step 29 of Zenith Blueprint tells organizations to use a CAPA log:

“Populate it with each issue: Issue description, root cause, corrective action, responsible owner, target date for completion, status.”

From Zenith Blueprint, Audit, Review & Improvement phase, Step 29: Continual Improvement Zenith Blueprint

It also makes an important distinction:

“In audit terms: correction fixes the symptom, corrective action fixes the cause. Both are important.”

From Zenith Blueprint, Audit, Review & Improvement phase, Step 29: Continual Improvement

If backup restore evidence is missing, the correction may be to run and document a restore test this week. The corrective action is to change the backup procedure so restore tests are scheduled quarterly, automatically ticketed, reviewed by the service owner and included in management review metrics.

Auditors look for that maturity. An ISO 27001 auditor tests conformity to the ISMS and selected controls. A NIS2 reviewer asks whether risk-management measures are effective and overseen. A DORA reviewer looks for ICT risk framework integration, resilience testing, third-party dependency management and remediation. A NIST Cybersecurity Framework 2.0 assessor may ask whether governance, identify, protect, detect, respond and recover outcomes are operating. A COBIT 2019 auditor may focus on governance objectives, ownership, performance indicators and assurance.

The same CAPA record can satisfy these lenses if it includes root cause, owner, risk impact, corrective action, due date, evidence of implementation, effectiveness review and management visibility.

The auditor’s multiple lenses

Different auditors read the same evidence differently. Zenith Controls helps anticipate those questions by acting as a cross-compliance guide for ISO/IEC 27002:2022 controls and related frameworks.

Control 5.36 is a good example. The ISO 27001 auditor may focus on whether compliance reviews happen and feed into corrective action. The NIS2 reviewer may ask whether those reviews test legal cybersecurity measures, not only internal rules. The DORA reviewer may focus on whether compliance reviews include critical ICT providers and contractual enforcement.

That is why the evidence must be designed for multiple readers from the start.

A practical 30-day audit readiness sprint

If the CEO asks whether the organization can be audit-ready in 30 days, the honest answer is: you can build a credible evidence baseline if leadership supports the sprint and scope is realistic.

This sprint does not replace long-term maturity. It creates a defensible operating baseline. The real value comes when the organization repeats the cycle quarterly or semi-annually, not only once a year.

Common evidence failures Clarysec finds

The same weaknesses appear across SaaS, cloud and fintech audits:

• The audit plan exists, but it is not risk-based.
• The audit checklist tests ISO clauses but ignores NIS2, DORA, GDPR and customer obligations.
• Management review minutes exist, but they do not show decisions, resource allocation or risk acceptance.
• CAPA records list actions but no root cause.
• Findings are closed without effectiveness verification.
• Supplier reviews are performed, but critical suppliers are not distinguished from low-risk vendors.
• Incident playbooks exist, but no one can prove the 24-hour or 72-hour reporting workflow would work.
• Backup jobs are green, but restore tests are not evidenced.
• Access reviews are exported, but exceptions are not tracked to closure.
• Logs are collected, but nobody can show monitoring, escalation or response.
• Evidence is stored in personal folders instead of a controlled repository.
• Retention requirements are unclear or inconsistent with customer contracts.

These failures are fixable. They require a structured ISMS evidence architecture, not last-minute document chasing.

What good looks like for the board

When the CISO returns to the CEO and CFO, the strongest answer is not “we passed an audit checklist.” It is:

“We have an approved audit plan. We performed a risk-based internal audit. We identified findings with objective evidence. We approved CAPAs with owners and due dates. We escalated material risks, incidents, supplier dependencies and resource needs into management review. We mapped evidence to ISO/IEC 27001:2022, NIS2, DORA and GDPR. We can show the audit trail.”

That answer changes the conversation. It gives the CEO confidence with customers. It gives the CFO clarity on regulatory exposure. It gives the board a defensible oversight record. It gives the CISO a prioritized roadmap instead of a pile of disconnected requests.

Most importantly, it moves the organization from compliance theater to operational resilience.

Next steps with Clarysec

Your next audit should not be a scramble. It should be visible proof that your ISMS works, leadership is engaged and the organization is ready for ISO 27001, NIS2, DORA, GDPR and customer assurance.

Clarysec can help you:

• Build a risk-based internal audit plan using Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint.
• Map audit evidence through Zenith Controls: The Cross-Compliance Guide Zenith Controls.
• Implement SME or enterprise audit governance using Audit and Compliance Monitoring Policy-sme Audit and Compliance Monitoring Policy-sme or Audit and Compliance Monitoring Policy Audit and Compliance Monitoring Policy.
• Prepare management review packs aligned to Information Security Policy Information Security Policy and ISO/IEC 27001:2022 Clause 9.3 expectations.
• Turn findings into CAPA records, management decisions and measurable improvement.

Download the Clarysec toolkits, book a readiness assessment or request a demo to turn your next internal audit into board-ready evidence for ISO 27001, NIS2, DORA and beyond.