ISO 27001 SoA for NIS2 and DORA Readiness

It is 08:30 on a Monday, and Elena, the CISO of a fast-growing B2B FinTech SaaS provider, opens a board request marked urgent. The company has just achieved ISO/IEC 27001:2022 certification, but a major EU banking prospect is asking harder questions than the usual security questionnaire.

They are not asking only whether the company encrypts data, uses MFA, or has a penetration test report. They want to know whether the SaaS platform supports their DORA obligations, whether the provider could be in scope for NIS2 as an ICT service or digital infrastructure dependency, and whether the ISO 27001 Statement of Applicability can justify every included control, every excluded control, and every piece of evidence.

The board asks the question every CISO, compliance manager, and SaaS founder is hearing more often:

Can our ISO 27001 SoA prove NIS2 and DORA readiness?

Elena knows the wrong answer would be to launch three separate compliance programs, one for ISO 27001, one for NIS2, and one for DORA. That would create duplicated evidence, conflicting control owners, and a constant scramble before every customer assessment. The better answer is to use the existing ISMS as the operating system for compliance, with the Statement of Applicability, or SoA, as the master traceability document.

The SoA is not just a spreadsheet for ISO certification. In an EU cybersecurity and operational resilience environment, it is where an organization proves why controls exist, why exclusions are defensible, who owns each control, what evidence supports implementation, and how the control set addresses NIS2, DORA, GDPR, customer contracts, and internal risk treatment.

Clarysec’s Enterprise Information Security Policy Information Security Policy states:

The ISMS shall include defined scope boundaries, a risk assessment methodology, measurable objectives, and documented controls justified in the Statement of Applicability (SoA).

That requirement, from policy clause 6.1.2 in the Information Security Policy, is the foundation for an audit-ready approach. The SoA should become the bridge between obligations, risks, controls, evidence, and management decisions.

Why NIS2 and DORA changed what “applicable” means

A traditional ISO/IEC 27001:2022 SoA often starts with a simple question: “Which Annex A controls apply to our risk treatment plan?” That is still correct, but it is no longer enough for SaaS, cloud, managed service, fintech, financial technology, and critical supply chain providers.

NIS2 raises the baseline for cybersecurity risk management across essential and important entities in the EU. It covers sectors such as digital infrastructure, cloud computing service providers, data centre service providers, content delivery networks, managed service providers, managed security service providers, banking, and financial market infrastructures. Member States must identify essential and important entities and domain-name registration service providers, and many technology providers that previously treated cybersecurity regulation as a customer issue are now either directly in scope or exposed through contractual flow-down requirements.

NIS2 Article 21 requires appropriate and proportionate technical, operational, and organizational measures across risk analysis, security policies, incident handling, business continuity, supply chain security, secure acquisition and development, control effectiveness assessment, cyber hygiene, training, cryptography, HR security, access control, asset management, and authentication where appropriate. NIS2 Article 23 adds staged incident reporting expectations, including early warning, notification, updates, and final reporting for significant incidents.

DORA, the Digital Operational Resilience Act, applies from 17 January 2025 and focuses on financial entities and their ICT risk ecosystem. It covers ICT risk management, ICT-related incident reporting, operational or security payment incident reporting for certain entities, digital operational resilience testing, cyber threat information sharing, ICT third-party risk management, contractual arrangements, and oversight of critical ICT third-party service providers.

For financial entities that are also essential or important entities under NIS2, DORA functions as the sector-specific regime for equivalent ICT risk management and incident reporting obligations. But for SaaS providers, cloud providers, MSPs, and MDR providers serving financial customers, the practical reality is that DORA expectations arrive through procurement, contracts, audit rights, incident support obligations, exit planning, subcontractor transparency, and resilience evidence.

That changes the SoA conversation. The question is no longer, “Does Annex A contain this control?” The better question is:

Can we prove that the control selection is risk-based, obligation-aware, proportionate, owned, implemented, monitored, evidenced, and approved?

ISO 27001 is the universal translator for NIS2 and DORA

ISO/IEC 27001:2022 is valuable because it is a management system standard, not a narrow checklist. It requires the ISMS to be integrated into organizational processes and scaled to the organization’s needs. That makes it an effective universal translator for overlapping compliance demands.

Clauses 4.1 to 4.4 require the organization to understand its context, identify interested parties, determine relevant requirements, and define the ISMS scope. For a FinTech SaaS provider like Elena’s company, those interested party requirements may include EU customers, financial customers affected by DORA, NIS2 sector exposure, GDPR controller and processor obligations, outsourced cloud dependencies, supplier interfaces, and board expectations.

Clauses 6.1.1 to 6.1.3 require planning for risks and opportunities, a repeatable information security risk assessment process, a risk treatment process, comparison with Annex A, and a Statement of Applicability that identifies included controls, implementation status, and exclusion justifications.

This is where the SoA becomes a control decision record. A control may be included because it treats a risk, satisfies a legal requirement, fulfils a customer contract, supports a business objective, or represents baseline security hygiene. A control may be excluded only after the organization has consciously assessed it, found it irrelevant to the ISMS scope, documented the rationale, and obtained appropriate approval.

Clarysec’s Enterprise Risk Management Policy Risk Management Policy states:

A Statement of Applicability (SoA) shall reflect all treatment decisions and shall be updated whenever control coverage is modified.

This requirement, from policy clause 5.4 in the Risk Management Policy, is critical for NIS2 and DORA readiness. A new regulated customer, a new cloud dependency, a new incident reporting obligation, or a new supplier concentration risk can all change control applicability.

Start with the compliance register, not the control list

A weak SoA starts with Annex A and asks, “Which controls do we already have?” A strong SoA starts with the organization’s operating reality and asks, “Which obligations, services, risks, data, suppliers, and customers must the ISMS address?”

ISO/IEC 27005:2022 supports this approach by emphasizing interested party requirements, risk criteria, and the need to consider standards, internal rules, laws, regulations, contracts, and existing controls. It also stresses that non-applicability or non-compliance should be explained and justified.

Clarysec’s SME Legal and Regulatory Compliance Policy-sme Legal and Regulatory Compliance Policy-sme - SME captures the same operating principle:

The GM must maintain a simple, structured Compliance Register listing:

That requirement comes from clause 5.1.1 of the Legal and Regulatory Compliance Policy-sme. For a smaller organization, the register can be simple. For an enterprise, it should be more detailed. The logic is the same: obligations must be visible before they can be mapped.

Clarysec’s Enterprise Legal and Regulatory Compliance Policy Legal and Regulatory Compliance Policy is explicit:

All legal and regulatory obligations must be mapped to specific policies, controls, and owners within the Information Security Management System (ISMS).

That is policy clause 6.2.1 in the Legal and Regulatory Compliance Policy. It is the governance backbone for using an ISO 27001 Statement of Applicability for NIS2 and DORA compliance readiness.

Build risk criteria that reflect resilience, privacy, suppliers, and regulation

Many SoA justifications fail because the risk scoring model is too narrow. It measures technical likelihood and impact, but it does not capture regulatory exposure, service criticality, customer harm, supplier dependency, privacy impact, or systemic operational disruption.

NIS2 is not only about confidentiality. It focuses on preventing and minimizing incident impact on services and service recipients. DORA defines critical or important functions based on whether disruption would materially impair financial performance, service continuity, or regulatory compliance. GDPR adds accountability, integrity, confidentiality, breach readiness, and data subject harm.

Clarysec’s SME Risk Management Policy-sme Risk Management Policy-sme - SME gives a practical minimum:

Each risk entry must include: description, likelihood, impact, score, owner, and treatment plan.

This is clause 5.1.2 of the Risk Management Policy-sme. For NIS2 and DORA readiness, Clarysec expands that minimum into fields such as obligation source, affected service, data category, supplier dependency, business owner, regulatory impact, residual risk, treatment status, and evidence source.

Notice the language. A strong justification does not say only “implemented.” It explains why the control is applicable in the organization’s business, regulatory, and risk context.

Map NIS2 and DORA domains to ISO 27001:2022 controls

Once the compliance register and risk criteria are established, the practical work is to map regulatory domains to Annex A controls. This mapping does not prove compliance by itself, but it gives auditors and customers a clear index for testing evidence.

For Elena, this mapping changed the board conversation. Instead of presenting NIS2 and DORA as separate projects, she could show the overlap: governance, risk management, incidents, continuity, suppliers, testing, access control, and cryptography.

The three ISO controls every NIS2 and DORA SoA depends on

In Zenith Controls: The Cross-Compliance Guide Zenith Controls, Clarysec treats three ISO/IEC 27002:2022 controls as central to audit-ready SoA governance for NIS2 and DORA. These are ISO controls, enriched with cross-compliance attributes in the Zenith Controls guide.

These controls are not isolated. They connect directly to supplier relationship controls A.5.19 to A.5.23, incident management controls A.5.24 to A.5.28, continuity controls A.5.29 and A.5.30, privacy control A.5.34, vulnerability management A.8.8, configuration management A.8.9, information backup A.8.13, logging A.8.15, monitoring activities A.8.16, cryptography A.8.24, secure development controls A.8.25 to A.8.29, and change management A.8.32.

The value of Zenith Controls is that it helps teams avoid treating the SoA as a one-standard artifact. Control 5.31 supports legal and contractual mapping. Control 5.35 supports internal audit, independent review, and management assurance. Control 5.36 supports operational compliance with policies, procedures, standards, and control requirements.

Use the Zenith Blueprint to build, test, and defend the SoA

In Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, Clarysec places SoA construction in the Risk Management phase, Step 13: Risk Treatment Planning and Statement of Applicability. The Blueprint instructs organizations to use the SoA sheet in the “Risk Register and SoA Builder.xlsx” template, decide whether each of the 93 Annex A controls is applicable, and base the decision on risk treatment, legal and contractual requirements, scope relevance, and organizational context.

The Blueprint states:

The SoA is effectively a bridging document : it links your risk assessment/treatment to the actual controls you have.

That sentence captures the operating model. The SoA bridges obligations, risks, policies, controls, evidence, and audit conclusions.

The Zenith Blueprint also instructs teams to cross-reference regulations in the SoA notes where appropriate. If a control is implemented for GDPR, NIS2, or DORA, that should appear in the risk register or SoA notes. Later, in Step 24, the Blueprint tells organizations to update the SoA after implementation and cross-verify it with the risk treatment plan. In Step 30, Certification Preparation, Final Review & Mock Audit, the Blueprint directs teams to confirm that each applicable Annex A control has evidence such as a policy, procedure, report, plan, or implementation record.

That sequence makes the SoA a living compliance instrument:

1. Step 13 builds it from risk treatment and obligations.
2. Step 24 tests it against implementation reality.
3. Step 30 defends it through final evidence review and mock audit.

How to write inclusion justifications auditors can follow

A control should be included when at least one defensible driver exists: risk treatment, legal requirement, contractual requirement, scope relevance, baseline security hygiene, customer assurance expectation, or management-approved resilience objective.

A useful formula is:

Applicable because [risk or obligation] affects [service, asset, data, or process], and this control provides [preventive, detective, corrective, or resilience outcome], evidenced by [policy, record, test, report, or system output].

For a fintech SaaS provider, one SoA row might look like this:

This is audit-ready because it connects the control to context, risk, obligation, implementation, ownership, and evidence.

How to justify exclusions without creating audit exposure

Exclusions are not failures. Poorly justified exclusions are failures.

ISO/IEC 27001:2022 requires the SoA to justify excluded Annex A controls. ISO/IEC 27005:2022 reinforces that non-applicability should be explained and justified. Clarysec’s Enterprise Information Security Policy states:

The baseline may be tailored; however, exclusions shall be documented with formal approval and justification in the SoA.

This is clause 7.2.2 of the Information Security Policy.

Clarysec’s Information Security Policy-sme Information Security Policy-sme - SME states:

Any deviation from this policy must be documented, clearly explaining why the deviation is necessary, which alternative protective measures are in place, and the date defined for re-evaluation.

That requirement comes from clause 7.2.1 in the Information Security Policy-sme.

For NIS2 and DORA, exclusions require extra care. A SaaS company should rarely exclude logging, monitoring, backups, incident management, access control, supplier security, or vulnerability management. Even where a control is not linked to one specific risk, it may still be necessary as baseline security, customer assurance, contractual expectation, or legal obligation.

Clarysec’s Risk Management Policy-sme also reminds teams how accepted risk must be handled:

Accept: Justify why no further action is required and record the residual risk.

That clause, 6.1.1 in the Risk Management Policy-sme, is exactly the mindset needed for exclusions and residual risk decisions.

Incident reporting: prove workflow, not policy existence

NIS2 Article 23 requires staged significant incident reporting, including early warning within 24 hours of awareness, notification within 72 hours, updates where requested, and a final report within one month of the 72-hour notification. DORA requires financial entities to detect, manage, classify, escalate, communicate, and report major ICT-related incidents, inform affected clients where required, perform root-cause analysis, and improve controls.

A SaaS provider may not always report directly to a DORA authority, but it may need to support financial customers’ reporting timelines. That makes incident controls highly relevant in the SoA.

A weak SoA says: “Incident response policy exists.”

A strong SoA says: “Applicable because the organization must detect, assess, classify, escalate, communicate, preserve evidence, support regulatory reporting timelines, notify affected customers where contractually required, and learn from incidents affecting services, data, or regulated customers.”

Evidence should include:

• Incident response plan and escalation matrix.
• Severity classification criteria.
• Customer notification workflow.
• Regulatory notification decision tree where applicable.
• Incident tickets and timelines.
• Logs and monitoring alerts.
• Tabletop exercise records.
• Post-incident review and corrective actions.
• Evidence preservation procedures.

Clarysec’s Enterprise Audit and Compliance Monitoring Policy Audit and Compliance Monitoring Policy explains why this matters:

To generate defensible evidence and an audit trail in support of regulatory inquiries, legal proceedings, or customer assurance requests.

That objective comes from clause 3.4 in the Audit and Compliance Monitoring Policy.

For smaller organizations, evidence retention must also be explicit. Clarysec’s Audit and Compliance Monitoring Policy-sme Audit and Compliance Monitoring Policy-sme - SME states:

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

That is clause 6.2.4 in the Audit and Compliance Monitoring Policy-sme.

One SoA, multiple audit conversations

The best SoA does not duplicate frameworks. It creates a traceable control narrative that different auditors can understand.

An ISO 27001 auditor usually starts with clause logic: scope, interested parties, risk assessment, risk treatment, SoA, objectives, internal audit, management review, and improvement. A NIS2-oriented reviewer focuses on proportionality, management accountability, training, supply chain, incident timelines, and service impact. A DORA-oriented customer assessor focuses on ICT risk, critical or important functions, major ICT incidents, resilience testing, contract clauses, audit rights, exit plans, subcontracting, and concentration risk. A privacy reviewer focuses on GDPR accountability and breach readiness. A COBIT 2019 or ISACA-style auditor tests governance, metrics, ownership, assurance, and corrective action.

This is why the SoA cannot be maintained only by the security team. It needs legal, privacy, procurement, engineering, operations, HR, and executive ownership.

Common SoA failures in NIS2 and DORA readiness projects

Clarysec repeatedly finds the same issues in readiness projects:

1. The SoA marks controls as applicable, but no risk, obligation, or business reason is recorded.
2. NIS2 and DORA are mentioned in policies, but not mapped to controls, owners, or evidence.
3. Supplier controls are marked implemented, but there is no supplier register, criticality rating, contractual review, or exit plan.
4. Incident controls exist, but the process does not support 24-hour, 72-hour, customer, or final reporting workflows.
5. Management approval is implied, but there is no record of risk acceptance, SoA approval, or residual risk decision.
6. Exclusions are copied from a template and do not match the actual cloud, remote, SaaS, or fintech operating model.
7. Evidence exists across tools, but no audit trail connects evidence to the SoA.
8. GDPR personal data processing is not linked to security controls, breach response, supplier contracts, or retention.
9. Internal audit checks documents but does not test whether the SoA reflects real implementation.
10. The SoA is updated only before certification, not after new customers, suppliers, incidents, audit findings, or regulatory changes.

These are not paperwork issues. They are governance issues.

Practical checklist for an audit-ready ISO 27001 SoA

Use this checklist before an ISO 27001 certification audit, NIS2 readiness review, DORA customer assessment, board meeting, or investor due diligence process.

Turn the SoA into a defensible compliance bridge

Elena’s board presentation succeeded because she did not present three disconnected compliance projects. She presented one controlled, evidence-based operating model built on ISO/IEC 27001:2022, with the SoA as the bridge between regulation, risk, control implementation, evidence, and management oversight.

NIS2 and DORA do not make ISO 27001 obsolete. They make a well-built ISO 27001 Statement of Applicability more valuable. The SoA can become the single place where your organization explains why controls exist, why exclusions are defensible, how evidence is retained, how suppliers are governed, how incidents are escalated, and how management knows the ISMS is working.

Your immediate action is simple:

1. Open your current SoA.
2. Pick five controls marked applicable and ask, “What risk, obligation, or contract justifies this?”
3. Pick five exclusions and ask, “Would this still make sense to a NIS2, DORA, GDPR, or ISO/IEC 27001:2022 auditor?”
4. Check whether every applicable control has current evidence.
5. Confirm that management has approved residual risks and SoA decisions.
6. Update the compliance register, risk register, and SoA whenever services, suppliers, customers, regulations, or incidents change.

Clarysec helps organizations do this through the Zenith Blueprint Zenith Blueprint, Zenith Controls Zenith Controls, enterprise and SME policy sets, risk register tooling, SoA templates, audit preparation, and cross-compliance mapping for NIS2, DORA, GDPR, NIST CSF 2.0, COBIT 2019, and customer assurance.

If your SoA cannot answer why, who owns it, what evidence proves it, and which obligation it supports, it is not ready yet. Use Clarysec to turn it into an audit-ready compliance bridge before a regulator, auditor, or customer asks the same questions first.