ISO 27001 / 27017 / 27018 / 27701 — The Universal Underlay Every National Framework Builds On

Every national cloud security framework in this series — Slovak KsVC, German BSI C5, Spanish ENS, Italian ACN Qualificazione, French SecNumCloud, Finnish PiTuKri, Dutch BIO2 — references some combination of four ISO standards: 27001, 27017, 27018, and 27701. Understanding what each actually covers, what it does not, and how they fit together is the foundation that makes the national frameworks legible. This article walks through the four standards as a coherent stack and explains where each one earns its keep.

The four-standard stack at a glance

Standard	Year	What it is	Audit form
ISO/IEC 27001	2022 (current rev.)	Information Security Management System (ISMS) — the organisational discipline of running security	Certification (3-year cycle, annual surveillance)
ISO/IEC 27002	2022	The control catalogue 27001 audits against — 93 controls in 4 themes	Not directly certifiable; cited via 27001
ISO/IEC 27017	2015	Cloud-specific extension of 27002	Audit attestation; often paired with 27001
ISO/IEC 27018	2019	PII protection in public cloud — processor obligations	Audit attestation; often paired with 27001
ISO/IEC 27701	2019	Privacy Information Management System (PIMS) — extension of 27001 for GDPR	Certification (extension to 27001 cycle)

The stack runs vertically: 27001 is the management system, 27002 is its control catalogue, 27017 extends 27002 for cloud, 27018 extends it for PII in cloud, and 27701 adds the privacy management layer above 27001.

ISO 27001 — the management system, not the controls

ISO 27001 is widely misunderstood. It is not a catalogue of security controls — that’s 27002. It is the management discipline for selecting, implementing, monitoring, and continuously improving an organisation’s set of security controls. The standard requires:

• Context analysis — what the organisation does, who its stakeholders are, what regulatory environment it operates in.
• Risk assessment — a documented, repeatable methodology for identifying, analysing, and evaluating information security risks.
• Statement of Applicability (SoA) — explicit list of which 27002 controls the organisation has selected, and which it has excluded with justification.
• Risk treatment plan — how the organisation will address each identified risk.
• Management review — periodic top-down review of the ISMS’s effectiveness.
• Continual improvement — Plan-Do-Check-Act, documented evidence of corrections and adaptations.

The audit verifies that the management system functions, not that any specific control is “good.” A 27001-certified organisation has demonstrated it runs security as a sustained discipline. What it does not demonstrate is that any individual control is implemented to a particular technical depth — that’s what supporting attestations (SOC 2 Type 2, BSI C5, ENS audit) add on top.

The 2022 revision restructured 27002’s controls from 114 to 93, reorganised them into 4 themes (organisational / people / physical / technological), and introduced 11 new controls covering threat intelligence, ICT readiness for business continuity, physical security monitoring, configuration management, information deletion, data masking, data leakage prevention, monitoring activities, web filtering, secure coding, and cloud services usage. The “cloud services” control (5.23) is the explicit hook 27017 extends.

ISO 27017 — cloud-specific controls for both provider and customer

ISO 27017 is the cloud-specific extension of 27002. It uses 27002’s controls as a base and adds:

• Cloud-specific implementation guidance for many 27002 controls — what the control means concretely in a cloud context.
• Seven additional cloud-specific controls covering shared roles and responsibilities, removal of cloud service customer assets, segregation in virtual computing environments, virtual machine hardening, administrator’s operational security, monitoring of cloud services, and network alignment.

The standard explicitly addresses both roles: cloud service provider (CSP) and cloud service customer. This is the conceptual basis for the shared-responsibility model that every national framework references downstream. A CSP can use 27017 to document its provider-side controls; a customer can use 27017 to document its customer-side controls; the two together describe the responsibility split.

Where 27017 stops: it does not address sovereignty, jurisdiction, or third-country data transfers. Those are handled by national frameworks (SecNumCloud, KsVC U4, ACN PSN) or by GDPR transfer mechanisms. 27017 is a technical and operational standard; sovereignty is political.

ISO 27018 — PII protection in public cloud

ISO 27018 narrows the focus: it covers the protection of personally identifiable information when a public cloud provider acts as a PII processor (in GDPR terms, a processor). The standard adds:

• Specific obligations for cloud providers handling PII: consent and choice, purpose legitimacy, data minimisation, accuracy and quality, openness, individual participation, accountability.
• Restrictions on use of PII for the provider’s own marketing or advertising purposes without explicit consent.
• Notification requirements when a public authority requests PII access.
• Transparency about subprocessing and data location.

27018 is the most direct ISO alignment with GDPR Article 28 — the article that defines processor obligations and the controller-processor contract. A CSP that holds 27018 certification has demonstrably operationalised the most concrete subset of Article 28 obligations.

Where 27018 stops: it does not satisfy Article 28 by itself (the controller-processor contract has additional content requirements), and it does not address the third-country transfer chapter (Chapter V) of GDPR. Those are addressed by SCCs, BCRs, or schemes like the EU Cloud Code of Conduct’s Third Country Transfer Module.

ISO 27701 — the privacy management layer

ISO 27701 is an extension to 27001 — not a standalone standard. It defines a Privacy Information Management System (PIMS) that sits above the security ISMS and adds privacy-specific requirements. Holding 27701 requires also holding 27001; certification is granted as an extension.

The standard:

• Maps to GDPR articles and provides a structured way to demonstrate compliance with controller and processor obligations.
• Adds privacy-specific controls for both PII controllers and PII processors.
• Provides explicit cross-references to GDPR articles, ISO 29100, and other privacy frameworks.

A 27701-certified CSP has the most demonstrable ISO-based GDPR alignment available. National frameworks (KsVC, ENS) reference 27701 as a recognised privacy management baseline.

How the four stack and where they sit in audits

In a typical CSP audit programme:

1. 27001 baseline — the management system. Certified.
2. 27002 controls — implemented; the SoA documents which are in scope.
3. 27017 + 27018 attestations — added as cloud-specific and PII-specific evidence layers. Often issued as a single audit covering 27001 + 27017 + 27018.
4. 27701 — added on top for organisations needing demonstrable GDPR alignment beyond what 27018 provides.

The audit cycle is typically:

• 3 years for the main certification.
• Annual surveillance audits during the 3-year window.
• Recertification audit at the end of year 3.

The 3-year cycle is the natural calendar against which national framework cycles (ENS 2-year, ACN 36-month, SecNumCloud 3-year + annual surveillance) align.

What the ISO stack does not cover

The standards are global, voluntary, and intentionally generic. They do not address:

• Sovereignty — ownership, jurisdiction, foreign-law immunity. National frameworks like SecNumCloud handle this.
• Sector-specific obligations — DORA for finance, NIS2 for essential entities, sector-specific health-data rules. Sectoral frameworks handle these.
• Continuous monitoring — ISO audits are point-in-time + annual surveillance. Continuous monitoring is what CSA STAR Continuous and FedRAMP Continuous Monitoring add.
• Specific cryptographic algorithms — 27001/27002 require cryptographic controls but do not prescribe algorithms. National frameworks (notably SecNumCloud) prescribe algorithms via national cryptographic guidance.

The ISO stack is the floor, not the ceiling. National frameworks and sectoral regulations stack on top.

Reading an ISO 27001 certificate — what to verify

When a CSP presents an ISO 27001 certificate as evidence:

1. Issuing body accreditation — is the certification body accredited by a recognised national accreditation body? (ENAC in Spain, COFRAC in France, DAkkS in Germany, IAS or UKAS internationally.) Non-accredited “certifications” are not equivalent.
2. Scope statement — what is actually in scope? “ISO 27001 certified” without a defined scope is meaningless. Look for the explicit scope statement.
3. Certificate validity dates — initial date, current cycle, expiry.
4. Annexes — many certificates include 27017 and 27018 as annexes. Read them.
5. Statement of Applicability — request the SoA, especially for high-sensitivity workloads. A CSP that won’t share the SoA is hiding scope decisions.

Multicloud factor

For a multinational CSP, the ISO stack is the portable evidence layer that travels across every national framework:

• KsVC explicitly references 27001/27017/27018/27701.
• BSI C5 maps controls to 27001/27002/27017/27018.
• ENS recognises 27001 as a substantial head start in audit prep.
• ACN’s evaluation criteria reference international standards.
• SecNumCloud uses 27001 Annex A as its base, then extends.
• BIO2 is built on the Dutch national edition of 27001:2023 and 27002:2022.
• PiTuKri references 27001/27017.

A 27001 + 27017 + 27018 + 27701 baseline does not satisfy any national framework on its own, but it is the prerequisite that makes every national audit tractable. CSPs that build the ISO stack first and the national-specific work second consistently do better economically than CSPs that build each national framework as a fresh project.

Closing checklist

• ISO 27001 is the management system, not the controls. 27002 is the controls catalogue (93 controls in 4 themes after the 2022 revision). Don’t confuse them.
• 27017 extends 27002 for cloud-specific concerns and addresses both provider and customer roles. Seven additional cloud-specific controls.
• 27018 extends 27002 for PII protection in public cloud — the standard most directly aligned with GDPR Article 28.
• 27701 is an extension to 27001 that adds a Privacy Information Management System (PIMS). Requires 27001 as prerequisite.
• Audit cycle: 3-year main certification + annual surveillance. Natural calendar for national framework alignment.
• The ISO stack is the floor. Sovereignty, sector-specific obligations, continuous monitoring, and prescribed cryptography sit on top.
• Always verify certificate scope, issuing body accreditation, and the Statement of Applicability before relying on an ISO certificate. “Certified” on a marketing page is not verification.
• For multicloud CSPs, build the ISO stack first as a single combined audit programme. National-framework audits then become evidence-mapping exercises, not fresh projects.
• See national framework articles (Slovakia KsVC, Germany BSI C5, Spain ENS, Italy ACN, France SecNumCloud) for how each uses the ISO stack as its reference point.