ISO 27001 ISMS Scope for NIS2, DORA and GDPR

Maria, the CISO at a fast-growing European fintech, thought the ISO 27001 surveillance audit was under control.

The certificate was fresh. The Statement of Applicability looked mature. The scope statement covered “the corporate information security management system supporting SaaS platform operations.” The production cloud environment was documented. The incident response procedure existed. The risk register had owners, dates and residual risk ratings.

Then the auditor asked one simple question:

“Which parts of this SaaS platform are also in scope for NIS2 registration, which outsourced services support DORA critical or important functions for your financial customers, and where exactly is GDPR personal data processed?”

The room went quiet.

Legal opened a spreadsheet of regulatory obligations. Product opened an architecture diagram. The DPO opened the records of processing activities. Procurement opened the supplier list. Operations opened the disaster recovery plan. None of them matched.

The ISMS scope said “SaaS platform.” The NIS2 assessment identified digital infrastructure services in several Member States. Customer contracts described the platform as supporting regulated financial operations. The GDPR records included identity data, telemetry, IP addresses, payment metadata, support tickets and subcontracted analytics. The disaster recovery plan covered production, but not the customer support platform used for breach communications. Supplier due diligence covered the hosting provider, but not the managed detection service connected to production logs.

This is the 2026 ISMS scoping problem. ISO 27001 certification is still valuable, but a narrow “minimal viable scope” can become a liability when supervisors, customers and auditors expect the same management system to explain NIS2 essential services, DORA critical or important functions and GDPR processing boundaries.

For ISO/IEC 27001:2022, NIS2, DORA and GDPR, weak scope is not an administrative defect. It is the first domino. If scope is wrong, the risk assessment is incomplete, the SoA is misleading, supplier controls miss critical providers, incident reporting clocks become uncertain and privacy accountability fragments across teams.

Why ISO 27001 ISMS scope is now a regulatory boundary

ISO/IEC 27001:2022 Clause 4.3 requires an organization to determine the boundaries and applicability of the ISMS, considering internal and external issues, interested-party requirements, and interfaces and dependencies with other organizations ISO/IEC 27001:2022.

That language matters more in 2026 than it did in earlier certification cycles. NIS2, DORA, GDPR, cloud outsourcing, customer contracts, group technology services and managed service providers are not side notes. They are inputs into the ISMS boundary.

NIS2 raises the governance stakes for essential and important entities. It requires management bodies to approve cybersecurity risk-management measures, oversee implementation and receive training. NIS2 Article 21 requires appropriate and proportionate technical, operational and organizational measures, including risk analysis, incident handling, business continuity, supply chain security, secure acquisition and development, effectiveness assessment, cyber hygiene, cryptography, HR security, access control, asset management and multifactor authentication where appropriate.

DORA changes the scope conversation for financial entities. It applies from 17 January 2025 and establishes uniform requirements for ICT risk management, ICT-related incident reporting, digital operational resilience testing, information sharing and ICT third-party risk management. DORA Article 6 requires a documented ICT risk management framework. DORA Article 8 requires identification, classification and documentation of ICT-supported business functions, information assets and ICT assets, including dependencies. DORA Article 28 requires management of ICT third-party risk.

GDPR adds the personal data axis. It applies to automated or structured personal data processing, including processing by EU establishments and certain non-EU controllers or processors offering goods or services to people in the Union or monitoring their behavior. GDPR Article 30 requires records of processing activities, Article 32 requires security of processing, and Article 33 sets breach notification expectations.

A defensible ISMS scope is therefore not written around departments. It is written around regulated services, critical or important functions, personal data processing, supporting assets and third-party dependencies.

The mistake: treating ISO 27001, NIS2, DORA and GDPR as separate programs

A common pattern appears in many organizations:

• Security drafts the ISO 27001 scope.
• Legal assesses NIS2 applicability.
• Risk or compliance manages DORA obligations.
• Privacy maintains the GDPR records of processing activities.
• Procurement owns the supplier list.
• Operations owns business continuity and disaster recovery.

Each team may be doing reasonable work. The problem is that regulated reality cuts across all of them.

A cloud-hosted customer identity service may support NIS2 service provision, DORA-regulated customer operations and GDPR personal data processing at the same time. A managed detection provider may be a security supplier, an incident response dependency, a processor or subprocessor of log data and a key input into regulatory notification decisions. A support platform may be considered “non-production,” while still handling personal data breach communications and customer evidence requests.

The ISMS is the best place to integrate these obligations because ISO 27001 forces one disciplined question: what is inside the boundary, what is outside, and why?

Clarysec’s Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint addresses this in the ISMS Foundation & Leadership phase, Step 2: Stakeholder Needs and ISMS Scope:

“With context understood and stakeholder requirements identified, Clause 4.3 asks you to determine the boundaries and applicability of the ISMS to establish its scope. The ISMS scope is a crucial definition that sets what is included under your security management program (and what is not).”

The Zenith Blueprint also highlights a point many scope statements still miss:

“If you outsource your IT infrastructure to a cloud provider, that doesn’t exclude it from scope; rather, you include the management of that relationship and the cloud assets as part of scope.”

Outsourcing shifts execution. It does not erase accountability.

The four-boundary model for ISO 27001 scope in 2026

For organizations affected by NIS2, DORA and GDPR, Clarysec recommends defining ISO 27001 ISMS scope through four connected boundaries.

A weak scope statement says only “the SaaS platform.” A stronger statement says which business services, systems, environments, locations, data processing activities, personnel groups, supplier relationships and management processes are included.

A more defensible version might read:

“The ISMS covers the governance, risk management, operation and continual improvement of information security for the company’s EU SaaS payment analytics platform, including production and non-production cloud environments, customer identity services, administrative interfaces, support operations, logging and monitoring platforms, incident response, business continuity, supplier management and all personal data processing activities supporting the service. The ISMS includes the management of outsourced cloud hosting, managed detection and customer support tooling used for service delivery, resilience, security monitoring or GDPR-related communications.”

That scope is not merely longer. It is more auditable because it connects services, assets, processing and dependencies.

How Clarysec policies turn scope into governance language

Scope should not live in a standalone document. It must align with information security policy, legal and regulatory compliance, risk management, privacy, supplier governance, audit criteria and continuity planning.

The Enterprise Information Security Policy Information Security Policy prevents ambiguity around exclusions:

“Any exclusions or limitations to this scope shall be documented in the ISMS Scope Statement and justified with formal approval from Top Management.”

This clause matters when a business unit argues that customer support is outside the platform, even though support agents access customer identifiers and handle breach communications. Exclusion is possible only if it is documented, justified and approved.

The Enterprise Legal and Regulatory Compliance Policy Legal and Regulatory Compliance Policy makes legal mapping operational:

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

This is the bridge between legal applicability and the Statement of Applicability. NIS2 Article 21 should not remain in a legal memo. DORA ICT third-party obligations should not remain only in procurement guidance. GDPR Article 30 and Article 32 obligations should not sit only in the privacy register. They need mapped owners, controls and evidence.

The Enterprise Risk Management Policy Risk Management Policy widens the scope to third parties:

“This policy applies to all organizational units, business processes, systems, personnel, and third-party engagements involved in the handling, development, storage, or management of information assets.”

That wording aligns with NIS2 supply chain security, DORA ICT third-party risk and GDPR controller or processor accountability.

The Enterprise Data Protection and Privacy Policy Data Protection and Privacy Policy anchors privacy scope to processing:

“This policy applies to all organizational units, personnel, and systems involved in the processing of personal information (PII), including:”

The principle is decisive. If a system processes PII, it cannot be invisible to the ISMS because it is “support only,” “non-production” or “owned by marketing.”

The Enterprise Business Continuity Policy and Disaster Recovery Policy Business Continuity Policy and Disaster Recovery Policy ties scope to BIA results:

“This policy applies to all organizational units, information systems, business processes, personnel, and third-party services classified as critical or essential based on Business Impact Analysis (BIA) results.”

That clause aligns naturally with DORA critical or important functions and NIS2 service continuity.

For smaller organizations, Clarysec’s SME policies keep the wording concise while preserving the same logic. The SME Audit and Compliance Monitoring Policy-sme Audit and Compliance Monitoring Policy-sme - SME defines audit coverage as:

“All controls and systems within the scope of the Information Security Management System (ISMS)”

The SME Data Protection and Privacy Policy-sme Data Protection and Privacy Policy-sme - SME defines privacy scope as:

“Any system, application, or location in which personal data is stored or transmitted”

The SME Risk Management Policy-sme Risk Management Policy-sme - SME keeps outsourced services visible:

“All information, services, and assets managed internally or through third parties”

Short clauses like these are powerful because they stop a certification boundary from excluding regulated data, cloud services or supplier-managed assets.

Asset inventory is where scope becomes real

A scope statement is only credible if it can be traced to assets, owners, suppliers, data flows and evidence.

The Zenith Blueprint, in the Risk Management phase, Step 9: Identifying Assets, Threats, and Vulnerabilities, instructs organizations to list assets in the ISMS scope and capture owner, location and classification. It gives a practical example:

“Customer Database – owned by IT Dept – hosted on AWS – contains personal and financial data (High sensitivity).”

The same step adds a scoping reminder that is directly relevant to NIS2 and GDPR:

“Ensure personal data assets are flagged (for GDPR relevance) and critical service assets are noted (for potential NIS2 applicability if you’re in a regulated sector).”

Clarysec’s Zenith Controls: The Cross-Compliance Guide Zenith Controls treats ISO/IEC 27002:2022 control 5.9, Inventory of information and other associated assets, as a foundational cross-compliance control. Its attributes classify the control as preventive, supporting confidentiality, integrity and availability, aligned with the Identify cybersecurity concept, asset management operational capability, and governance, ecosystem and protection domains.

Zenith Controls explains the GDPR and NIS2 relevance plainly:

“Without an accurate and current asset inventory, organizations cannot assess or implement appropriate protections.”

For NIS2, asset inventory supports identification of critical systems and components underpinning essential or important services. For DORA, DORA Article 8 makes ICT asset and information asset identification central to operational resilience. For GDPR, the asset inventory supports data flow mapping, RoPA quality and breach response.

Supporting ISO standards reinforce the same logic. ISO/IEC 27005:2024 strengthens asset identification in information security risk assessment. ISO 22301:2019 supports identifying resources needed for business continuity. ISO/IEC 19770-1:2017 supports IT asset management maturity. ISO/IEC 27017:2015 and ISO/IEC 27018:2019 support cloud-specific controls and protection of PII in public clouds. ISO/IEC 27701:2019 extends privacy information management. ISO/IEC 29100:2011 contributes privacy principles such as transparency, minimization and security safeguards.

A practical scoping exercise for SaaS and fintech teams

Start with one regulated service, not the whole company. For example: “EU payment analytics SaaS for financial institutions.”

Then build a service-to-asset-to-processing map.

A more detailed asset sample might look like this.

Next, use Zenith Blueprint Step 13: Risk Treatment Planning and Statement of Applicability. The guide instructs users to build the SoA using the template that lists all Annex A controls and decide applicability based on risk treatment, legal or contractual requirements, scope relevance and organizational context. It states:

“For each control (row) in the SoA sheet, decide if it is Applicable to your ISMS.”

For the example above, the SoA should consider controls for supplier security, cloud services, incident management, continuity, legal and regulatory requirements, privacy, vulnerability management, backups, logging, monitoring, cryptography, secure development, security testing and change management.

A practical workflow is:

1. Create an “ISMS Scope Mapping” tab in the Risk Register and SoA Builder.
2. Add one row per regulated service or product line.
3. Link each service to assets, data types, suppliers, locations and business owners.
4. Flag NIS2 relevance, DORA relevance and GDPR processing relevance.
5. Add risk scenarios for unavailable service, personal data breach, supplier failure, cloud misconfiguration, critical vulnerability and incident reporting failure.
6. Select SoA controls based on those risks and obligations.
7. Document exclusions, compensating controls and risk acceptance.
8. Obtain top management approval for final boundaries and exclusions.
9. Feed the final boundary into internal audit, management review and supplier monitoring.

The output is not just a better scope statement. It is a defensible chain from regulated service to asset, supplier, data, control, owner and evidence.

Cross-compliance mapping: one scope, many obligations

A well-scoped ISO 27001 ISMS becomes the operating layer where NIS2, DORA, GDPR, NIST CSF and COBIT expectations can be reconciled.

For ISO/IEC 27002:2022 control 5.31, Legal, statutory, regulatory and contractual requirements, Zenith Controls ties compliance obligations to privacy, PII protection, records retention, independent review and internal policy compliance. It maps naturally to GDPR accountability, NIS2 supply chain compliance, DORA ICT risk management and compliance, NIST CSF governance, and COBIT 2019 external compliance monitoring.

For ISO/IEC 27002:2022 control 5.34, Privacy and protection of PII, Zenith Controls connects privacy to asset inventory, cloud services, classification, information transfer, access control, identity management and project change reviews. Its GDPR mapping covers security of processing and data protection by design. Its DORA mapping supports data integrity, security and confidentiality, including personal data handled in ICT services.

The principle is simple: do not create four disconnected compliance programs. Create one scoped ISMS that can explain how obligations are satisfied, evidenced and audited.

Incident reporting scope: where boundaries affect regulatory clocks

Incorrect scope becomes painfully visible during incidents.

NIS2 Article 23 requires staged significant incident reporting, including an early warning within 24 hours, an incident notification within 72 hours, intermediate reports when requested and a final report within one month. Communication to affected recipients may also be required.

DORA requires financial entities to detect, manage, classify and report major ICT-related incidents using criteria such as affected clients or counterparts, duration, downtime, geographic spread, data losses, criticality of affected services and economic impact. Clients must be informed without undue delay where a major ICT incident affects their financial interests.

GDPR personal data breach notification depends on whether a breach leads to accidental or unlawful destruction, loss, alteration, unauthorized disclosure of or access to personal data.

If the support platform, log environment, identity service, customer notification channel or managed detection provider sits outside the ISMS scope, incident teams may not know whether an event triggers NIS2, DORA, GDPR, customer contract reporting or all of them. That uncertainty burns the reporting clock.

A mature scope includes incident-relevant dependencies: detection tools, log stores, forensic repositories, customer communication channels, support tooling, backup environments, incident bridges and suppliers involved in triage or recovery.

How auditors and supervisors will test your ISMS scope

A strong scope survives sampling. A weak scope collapses when auditors compare documents against reality.

Zenith Controls provides useful audit expectations for ISO/IEC 27002:2022 control 5.9. ISO/IEC 19011-style auditors request the inventory early to scope other evaluations and spot-check physical, software and cloud assets. ISO/IEC 27007-style auditors ask how and when the inventory is updated, looking for links to procurement, change management and decommissioning. NIST SP 800-53A-style auditors verify that inventory details include asset type, owner, location, network address where applicable and status, and that cloud, virtual and mobile assets are included.

For control 5.31, Zenith Controls notes that certification auditors expect a compliance register or list of laws and contracts, referenced in the SoA and risk treatment plans. COBIT auditors look for compliance owners, assessments and senior management reporting. ISACA ITAF auditors sample evidence to confirm the organization not only knows its obligations, but actively ensures they are met.

For control 5.34, auditors review privacy policies, data inventories, DPIAs, training logs, encryption evidence, access controls, DSAR samples, privacy-by-design evidence and incident records involving PII. A scope statement that excludes a system processing personal data will be challenged quickly.

The board question: what cannot be excluded?

Top management often asks whether a business unit, location, supplier or system can remain outside the ISMS scope. Sometimes the answer is yes. But not if exclusion prevents the organization from meeting legal, regulatory, contractual or service security obligations.

Use this exclusion test before approving any boundary limitation:

• Does the unit, system or supplier support a NIS2-regulated service?
• Does it support a DORA critical or important function for the organization or its regulated customers?
• Does it collect, store, transmit, log, support or delete personal data?
• Does it provide security monitoring, identity, backup, incident response or recovery for an in-scope service?
• Does it provide evidence needed for incident classification or regulatory notification?
• Does a customer contract require it to be covered by the ISMS?
• Would its compromise affect confidentiality, integrity, availability, legal compliance or service continuity within the stated scope?

If the answer is yes, exclusion needs strong evidence, compensating governance, risk acceptance and formal top management approval. In many cases, it should not be excluded.

A modern ISO 27001 ISMS scope should include:

1. Business services and product lines covered.
2. Legal entities, organizational units and locations covered.
3. Customer segments and jurisdictions that drive obligations.
4. Critical or important functions and BIA-based essential services.
5. Information assets, ICT assets and cloud environments.
6. Personal data processing activities and PII repositories.
7. Development, testing, support, monitoring and incident processes.
8. Suppliers and outsourced services supporting in-scope services.
9. Interfaces and dependencies with group companies or external providers.
10. Explicit exclusions with justification, risk acceptance and top management approval.

This is how ISO 27001 scope becomes a board-level governance position, not a certification shortcut.

Make your ISMS scope audit-ready before the auditor defines it for you

The worst time to discover a scope problem is during certification, supervisory review, customer due diligence or a live incident.

A narrow certificate may satisfy a procurement checkbox, but it will not withstand serious scrutiny if it excludes the services, ICT functions, suppliers and personal data processing that create regulatory exposure. In 2026, the organizations that pass audits with confidence will be the ones that can show one coherent map from regulated service to asset, supplier, personal data, control, owner and evidence.

Start with three concrete actions:

1. Use the Zenith Blueprint Zenith Blueprint Phase: ISMS Foundation & Leadership, Step 2, to redraft your ISMS scope around services, functions, processing and dependencies.
2. Use Zenith Controls Zenith Controls to map asset inventory, legal obligations and PII protection across ISO 27001, NIS2, DORA, GDPR, NIST and COBIT 2019 audit expectations.
3. Align policy scope using Clarysec’s Information Security Policy Information Security Policy, Legal and Regulatory Compliance Policy Legal and Regulatory Compliance Policy, Risk Management Policy Risk Management Policy, Data Protection and Privacy Policy Data Protection and Privacy Policy and Business Continuity Policy and Disaster Recovery Policy Business Continuity Policy and Disaster Recovery Policy.

If your current ISMS scope still reads like a department label, rebuild it as a compliance boundary. Download the Clarysec toolkits, map one regulated service end to end, and turn your ISO 27001 scope into audit-ready evidence for NIS2, DORA and GDPR.