ISO 27001 Internal Audit for NIS2 and DORA

It is the first audit committee meeting of 2026. Sarah, the CISO of FinSecure, a fast-growing SaaS and FinTech provider, has fifteen minutes on the agenda. The board has five questions.

Are we ready for our ISO/IEC 27001:2022 surveillance audit? Are we in scope for NIS2 as a managed service provider? Does DORA affect us because we support financial-sector clients? Can we prove incident reporting, supplier due diligence and business continuity are operating? And why did last quarter’s access review still find accounts that should have been removed?

Sarah has evidence, but it is scattered. Engineering has vulnerability scan exports. Procurement has supplier questionnaires. Legal has contract clauses. The compliance manager has a GDPR tracker. The SOC has incident tickets. None of it is obviously wrong, but none of it tells a coherent assurance story.

This is the moment where an ISO 27001 internal audit programme either becomes a strategic evidence engine or remains a once-a-year scramble.

For organisations affected by NIS2 and DORA, internal audit can no longer be a ceremonial checklist. It must become a risk-based assurance system that confirms whether the ISMS scope is right, whether controls work in practice, whether regulatory requirements are mapped, whether findings are classified consistently and whether corrective actions reach management review. In 2026, the strongest programmes will not ask only, “Did we do an audit?” They will ask, “Can we prove, month by month, that cybersecurity governance, ICT resilience, supplier security and incident readiness are operating?”

That is the approach Clarysec builds into Zenith Blueprint: An Auditor’s 30-Step Roadmap, Zenith Controls: The Cross-Compliance Guide, and the Clarysec policy suite. The goal is not to create separate ISO, NIS2 and DORA projects. The goal is to enrich the ISMS so that one audit programme produces reusable evidence across multiple assurance demands.

Why 2026 internal audit programmes need to change

NIS2 and DORA shifted the audit conversation from documentation to governed resilience.

NIS2 applies to many medium and large organisations in critical and important sectors, including digital infrastructure, cloud computing providers, data centre providers, managed service providers, managed security service providers, online marketplaces, online search engines and social networking platforms. Member States began applying national measures from October 2024, and by 2026 many organisations are operating in the first full year of mature NIS2 expectations.

DORA applies from 17 January 2025 to a wide range of financial entities, including credit institutions, payment institutions, electronic money institutions, investment firms, crypto-asset service providers, insurance and reinsurance undertakings, crowdfunding service providers and relevant ICT third-party service providers. DORA is the sector-specific digital operational resilience regime for covered financial entities. ICT providers that serve financial entities may also feel DORA through contracts, audit rights, testing participation, incident support, subcontracting controls and exit requirements.

Both regulations elevate accountability. NIS2 Article 20 requires management bodies to approve and oversee cybersecurity risk-management measures and to receive cybersecurity training. DORA Article 5 makes the management body ultimately responsible for ICT risk, including approval and oversight of the digital operational resilience strategy, ICT policies, continuity arrangements and third-party risk.

ISO 27001 is well suited to this environment because it is a management system. It requires the organisation to understand its context, define interested parties and requirements, set the ISMS scope, assess and treat risks, monitor performance, run internal audits and drive continual improvement. The point is not to force NIS2 and DORA into an ISO-shaped box. The point is to use ISO 27001 as the operating system for repeatable assurance.

Start with scope: audit the system the board relies on

A weak internal audit programme starts with a vague scope such as “information security.” A strong programme starts with the business and regulatory boundary.

ISO 27001 requires the ISMS scope to consider internal and external issues, interested-party requirements, and interfaces or dependencies with other organisations. That matters because NIS2 and DORA obligations often sit at the edges of the organisation: cloud platforms, outsourced SOC providers, managed detection and response, payment systems, fintech APIs, customer data processing, backup services and incident escalation partners.

Clarysec’s Audit and Compliance Monitoring Policy-sme sets the governance baseline:

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

From section ‘Governance Requirements’, policy clause 5.1.1.

For larger environments, Clarysec’s Audit and Compliance Monitoring Policy raises the expectation:

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

From section ‘Governance Requirements’, policy clause 5.2.

Scope is therefore not merely an auditor’s preference. It is a management-approved assurance commitment.

A 2026 ISO 27001 internal audit programme supporting NIS2 and DORA should include:

• ISMS clauses and processes, including context, leadership, risk management, objectives, support, operations, performance evaluation and improvement.
• Relevant ISO/IEC 27001:2022 Annex A control areas, including supplier relationships, incident management, business continuity, legal obligations, privacy, logging, monitoring, vulnerability management, access control, cryptography, secure development, change management and cloud governance.
• Regulatory overlays, including NIS2 Articles 20, 21 and 23, DORA Articles 5, 6, 8 to 14, 17 to 19, 24 to 27 and 28 to 30, plus GDPR security and accountability requirements.
• Key services and business processes, especially critical or important functions, essential services, customer-facing platforms and systems supporting regulated clients.
• Third-party dependencies, including ICT suppliers, cloud providers, outsourced development, SOC, MSSP, data processors and critical subcontractors.
• Evidence-producing processes, including risk assessments, access reviews, vulnerability remediation, incident exercises, backup restoration tests, supplier reviews, continuity tests and management reviews.

The Zenith Blueprint reinforces this in the Audit, Review & Improvement phase, Step 25, Internal Audit Program:

Decide the scope of your internal audit program. Ultimately, over the course of a year, you need to cover all relevant ISMS processes and controls.

From the Audit, Review & Improvement phase, Step 25: Internal Audit Program.

You do not need to audit everything every month. But over the annual cycle, you should cover all relevant ISMS processes and controls, with more frequent work on high-risk and regulated areas.

Build the audit universe around NIS2 and DORA control themes

NIS2 Article 21 requires appropriate and proportionate technical, operational and organisational measures. Its baseline includes risk analysis, security policies, incident handling, business continuity, backup management, disaster recovery, crisis management, supply-chain security, secure acquisition and development, vulnerability handling, effectiveness assessment, cyber hygiene, training, cryptography, HR security, access control, asset management, MFA or continuous authentication where appropriate, and secure communications.

DORA has a similar operational lifecycle. It requires financial entities to identify and classify ICT-supported business functions, information assets, ICT assets, dependencies and third-party interconnections. It also requires protection, detection, incident classification, response, recovery, backup, restoration, testing, post-incident learning, communication and ICT third-party risk management.

A unified audit universe prevents the common mistake of auditing ISO 27001 separately from NIS2 and DORA.

This structure turns each audit domain into a shared assurance object. The internal auditor tests the ISO 27001 requirement, then records whether the same evidence also supports NIS2, DORA, GDPR, NIST CSF and COBIT 2019 expectations.

Plan the year around risk, not paperwork

The Zenith Blueprint gives teams a practical sequence for turning audit into improvement:

• Step 25, Internal Audit Program: plan scope, frequency, independence and risk-based priorities.
• Step 26, Audit Execution: gather objective evidence through interviews, document review, observation and sampling.
• Step 27, Audit Findings, Analysis & Root Cause: classify findings and identify root cause.
• Step 28, Management Review: feed audit results, incidents, nonconformities, objectives, risks and resource needs into leadership review.
• Step 29, Continual Improvement: build corrective actions that eliminate causes, not just symptoms.

The Zenith Blueprint is explicit on independence:

Ideally, the internal auditor should not audit their own work.

From the Audit, Review & Improvement phase, Step 25: Internal Audit Program.

For a smaller SaaS or fintech company, this may mean asking a manager from another function to audit security processes, rotating control owners, or using an external consultant. The key is to document competence and independence, especially when NIS2 and DORA evidence may later be reviewed by customers, regulators, supervisory bodies or external auditors.

The Audit and Compliance Monitoring Policy-sme also defines the minimum audit structure:

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

From section ‘Governance Requirements’, policy clause 5.2.3.

A practical quarterly structure for a high-growth SaaS or ICT provider could be:

This does not replace monthly evidence collection. It gives the year a clear assurance rhythm.

Sampling: how much evidence is enough?

Sampling is where many internal audits become either too shallow or too expensive. In regulated ICT environments, sampling must be risk-based, explainable and documented.

The Zenith Blueprint, Step 26, provides the practical principle:

Sample and spot-check: You can’t check everything, so use sampling.

From the Audit, Review & Improvement phase, Step 26: Audit Execution.

Clarysec’s enterprise policy makes this auditable:

Documentation of the sampling strategy, audit scope, and limitations

From section ‘Governance Requirements’, policy clause 5.5.3.

For NIS2 and DORA, sampling should consider criticality, risk, supplier importance, time period, incident history, geography and whether the sampled process supports critical or important functions.

For DORA-affected environments, testing evidence deserves special attention. DORA requires digital operational resilience testing for financial entities, with more advanced testing such as threat-led penetration testing for selected entities at least every three years. Your audit sample should include not only test reports, but also evidence that findings were prioritised, remediated and retested.

Practical audit example: ICT third-party risk

Supplier security is often the fastest way to expose gaps between documentation and operational reality. DORA Articles 28 to 30 require ICT third-party risk management, contractual content and registers of information. NIS2 Article 21 requires supply-chain security that considers vulnerabilities and practices of direct suppliers.

For a Q2 audit, Sarah samples five critical suppliers, three new suppliers onboarded in the last six months and two suppliers with recently renewed contracts. The auditor interviews procurement, legal, service owners and security control owners.

This table does more than guide evidence collection. It proves that the organisation has translated regulatory text into ISO-aligned audit criteria and concrete evidence.

Findings: write them so management can act

An audit finding should not sound like a vague complaint. It should be structured enough for management to understand risk, assign ownership and approve corrective action.

The Audit and Compliance Monitoring Policy-sme states:

All audit findings must be documented with risk ratings and proposed actions.

From section ‘Governance Requirements’, policy clause 5.4.1.

The enterprise Audit and Compliance Monitoring Policy adds the corrective action discipline:

All findings shall result in a documented CAPA that includes:

From section ‘Policy Implementation Requirements’, policy clause 6.2.1.

In the Zenith Blueprint, Step 27 recommends categorising findings as major nonconformities, minor nonconformities or observations, then performing root cause analysis. A major nonconformity indicates a serious gap or systematic failure. A minor nonconformity is an isolated lapse in an otherwise conforming process. An observation is an improvement opportunity.

A strong finding includes:

• Requirement or control expectation.
• Condition observed.
• Evidence sampled.
• Risk and business impact.
• Regulatory relevance.
• Classification and risk rating.
• Root cause.
• Corrective action owner and due date.

Example finding:

Finding NC-2026-07, Minor Nonconformity, Supplier Security Review Delay

Requirement: Supplier security reviews for critical ICT providers must be performed at least annually, supporting ISO 27001 supplier controls, NIS2 supply-chain expectations and DORA ICT third-party risk obligations.

Condition: Two of twelve critical ICT suppliers did not have completed 2026 security reviews by the required date.

Evidence: Supplier register export dated 15 June 2026, vendor review tracker, interview with Procurement Lead and two missing review records.

Risk: Delayed supplier review may prevent timely identification of vulnerabilities, subcontracting changes, incident support gaps or contractual non-compliance affecting critical services.

Root cause: Procurement was not automatically notified when supplier review dates approached, and ownership for DORA-related supplier evidence was not assigned.

Corrective action: Configure automated review reminders, assign named control owners for all critical ICT suppliers, complete overdue reviews by 31 July 2026 and perform quarterly sample checks.

For root cause analysis, the “5 Whys” technique is useful. If a pre-contract assessment was missed, the true cause may not be an individual mistake. It may be that the procurement workflow allowed low-value ICT contracts to bypass security review, even though DORA and NIS2 expectations apply based on risk and dependency, not only spend.

The 2026 evidence calendar

A 2026 evidence calendar turns internal audit into an operating rhythm. It distributes evidence generation across the year and avoids the year-end scramble.

Clarysec’s Information Security Policy expects governance review of:

Review of security key performance indicators (KPIs), incidents, audit findings, and risk status

From section ‘Governance Requirements’, policy clause 5.3.2.

Evidence is not collected for auditors alone. It feeds decisions about risk, budget, resources, suppliers, tooling, training and corrective action.

This calendar gives the audit committee a forward-looking assurance plan and gives control owners time to create evidence through normal operations.

The ISO 27002:2022 spine: 5.31, 5.35 and 5.36

Zenith Controls is Clarysec’s cross-compliance guide. It maps ISO/IEC 27001:2022 and ISO/IEC 27002:2022 control areas to other standards, regulations, audit expectations and evidence patterns. It is especially useful for connecting internal review, legal obligations and policy compliance.

Three ISO/IEC 27002:2022 control areas form the spine of a unified internal audit programme:

Control 5.35 is the cornerstone of assurance because it validates whether the ISMS is being independently reviewed. Control 5.36 confirms that policies are not merely approved, but actually followed. Control 5.31 connects the ISMS to legal, regulatory and contractual obligations, including NIS2, DORA, GDPR and customer security requirements.

Cross-compliance mapping: one audit, many assurance lenses

A mature internal audit workpaper should explicitly show how one evidence item supports several assurance expectations.

This is what allows the CISO to tell the board, “Our July incident audit produced evidence for ISO 27001, NIS2, DORA customer assurance, GDPR breach readiness, NIST CSF response outcomes and COBIT incident governance.”

Management review: where audit becomes accountability

Internal audit has little value if findings do not reach management. ISO 27001 management review provides the mechanism, and NIS2 and DORA make the governance expectation explicit.

The Audit and Compliance Monitoring Policy-sme requires:

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

From section ‘Governance Requirements’, policy clause 5.4.3.

It also states:

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

From section ‘Governance Requirements’, policy clause 5.4.2.

Management review should answer:

• Are NIS2, DORA, GDPR and contractual obligations still correctly reflected in the ISMS scope?
• Are high-risk controls audited frequently enough?
• Which findings indicate systemic weakness rather than isolated error?
• Are corrective actions overdue?
• Are risk owners accepting residual risk knowingly?
• Are suppliers, incident reporting, continuity and testing adequately resourced?
• Do audit trends suggest policy, tooling, budget or training changes?

If these answers are not documented, the organisation may have evidence of activity but not evidence of governance.

Common pitfalls to avoid in 2026

The most common failure is treating ISO 27001 internal audit as separate from regulatory assurance. That creates duplication and blind spots.

Other pitfalls include:

• Scope excludes critical suppliers, cloud platforms or outsourced SOC services.
• NIS2 or DORA applicability is not documented in the legal register.
• Audit plan is not approved by management.
• Sampling is performed but not documented.
• Internal auditors review their own work without mitigation.
• Findings describe symptoms but not root causes.
• Corrective actions update documents but do not fix processes.
• Management review receives audit results but makes no decisions.
• Incident exercises test technical response but not regulatory notification.
• Supplier audits review questionnaires but not contracts, exit plans or concentration risk.
• Backup evidence shows successful jobs but not restoration integrity.
• Access reviews are performed but exceptions are not tracked to closure.

Each pitfall can become a minor or major nonconformity depending on severity and systemic impact. More importantly, each weakens the organisation’s ability to prove resilience under NIS2, DORA and customer scrutiny.

Turn your 2026 audit plan into an evidence engine

If your internal audit programme is still a single annual event, now is the time to redesign it.

Start with a management-approved audit plan. Define the ISMS scope around real services, regulated obligations and third-party dependencies. Build a risk-based audit universe. Document sampling. Classify findings consistently. Use root cause analysis. Track CAPA. Feed results into management review. Maintain a monthly evidence calendar.

Clarysec can help you move faster with:

• Zenith Blueprint: An Auditor’s 30-Step Roadmap for audit planning, execution, findings, management review and continual improvement.
• Zenith Controls: The Cross-Compliance Guide for mapping ISO 27001 assurance to NIS2, DORA, GDPR, NIST CSF and COBIT expectations.
• Audit and Compliance Monitoring Policy and Audit and Compliance Monitoring Policy-sme for governance-ready audit planning and findings management.
• Information Security Policy for KPI, incident, audit finding and risk-status review at management level.

Choose one high-risk domain, such as incident reporting or ICT supplier governance, and run a focused internal audit using Clarysec’s scope, sampling and findings structure. Within one cycle, you will know whether your evidence is audit-ready, whether your controls are operating and whether your management body has the information it needs to govern cyber risk.