ISO 27017 and 27018 penetration testing: what the cloud extensions expect
ISO/IEC 27017 and 27018 are code-of-practice extensions to ISO/IEC 27002 for cloud services and PII protection, not standalone laws or regulations. Neither names penetration testing directly, but both build on ISO 27001's technical controls, which auditors expect to see evidenced through testing - the same expectation that applies to ISO 27001 itself.
Do ISO 27017 and 27018 require a penetration test?
Not by name, and not on their own. ISO/IEC 27017 and ISO/IEC 27018 are not independent regulations - they are codes of practice that extend ISO/IEC 27002's control guidance for cloud computing and for the protection of personally identifiable information (PII) in public clouds, respectively. Organizations typically pursue them alongside an ISO/IEC 27001 certification, using 27017 and 27018 to add cloud-specific and PII-specific guidance to the same Information Security Management System (ISMS) that 27001 certifies. Neither standard uses the phrase "penetration test," and neither can be pursued in isolation from 27001 the way SOC 2 or PCI DSS operate as standalone programs.
27017 and 27018 do not create a new testing obligation - they inherit ISO 27001's technical vulnerability and security-testing controls and apply them specifically to a cloud context. If your auditor already expects testing evidence for A.8.8 and A.8.29 under 27001, that expectation carries over here.
A vendor page claiming "27017/27018 require a pentest" overstates it in the same way an ISO 27001 overclaim would. The accurate framing: no named mandate, but an inherited expectation, now scoped to cloud infrastructure and shared responsibility.
What the cloud extensions add
ISO/IEC 27017 (code of practice for information security controls based on ISO/IEC 27002 for cloud services) adapts the ISO 27002 control set to cloud computing and adds guidance for both cloud service providers and cloud service customers - covering areas like shared roles and responsibilities, removal of assets on contract termination, and segregation in virtual environments. ISO/IEC 27018 (guidelines for protection of PII in public clouds acting as PII processors) does the same for privacy: it applies specifically to organizations acting as PII processors in a public cloud, extending 27002's guidance with PII-specific controls such as breach notification and restrictions on subcontracting PII processing. Both are guidance documents that organizations certify against alongside - not instead of - ISO/IEC 27001.
Shared responsibility and what a pentest covers
Cloud security runs on a shared-responsibility model: the cloud provider secures the underlying infrastructure, while the customer secures what they configure and deploy on top of it. Both 27017 and 27018 make that division of duties explicit. A penetration test typically exercises the customer's side of that line - the application, API, and configuration layers a customer controls - which is exactly the technical vulnerability-management and security-testing evidence that ISO 27001's Annex A.8.8 (management of technical vulnerabilities) and A.8.29 (security testing in development and acceptance) call for, now applied in a cloud deployment. It does not test the cloud provider's underlying infrastructure, which is typically covered by the provider's own certifications and shared-responsibility documentation.
How Intrudify helps
Intrudify runs a full web and API pentest and produces a report that maps each finding to the relevant ISO 27001 Annex A controls, with reproducible proof for high and critical findings and developer-ready remediation. It supports the technical testing evidence your ISMS needs for a cloud-scoped 27017/27018 extension; Intrudify does not itself certify you against ISO 27017, ISO 27018, or ISO 27001.
- Findings mapped to the relevant Annex A controls, scoped to your cloud deployment
- Reproducible proof-of-exploit for high and critical findings
- Developer-ready remediation and a re-test window
- Delivered in hours, validated by OSCE3-certified testers
How a pentest maps to controls
| Control | What a pentest evidences |
|---|---|
| A.8.8 | Management of technical vulnerabilities: obtaining information about technical vulnerabilities, evaluating exposure, and taking appropriate measures - inherited from ISO 27001/27002 and extended by 27017 to the cloud services in scope. |
| A.8.29 | Security testing in development and acceptance: testing security functionality, including vulnerability scanning and penetration testing, before systems go live - the same control 27017/27018 build on for cloud-hosted systems. |
See how Intrudify tests web apps and APIs against the controls that carry ISO 27017/27018 into your security program.
Explore the platformFrequently asked questions
Do ISO 27017 and 27018 require a penetration test?
Not by name. Neither standard uses the phrase "penetration test." They extend ISO/IEC 27002's controls for cloud services (27017) and PII protection in public clouds (27018), and inherit the same technical testing expectation auditors already apply to ISO 27001's A.8.8 and A.8.29.
How do ISO 27017 and 27018 relate to ISO 27001?
They are extensions, not substitutes. Organizations certify their ISMS against ISO 27001 first, then add 27017 and/or 27018 to extend the same management system with cloud-specific and PII-specific guidance. You cannot certify against 27017 or 27018 alone.
What is the difference between ISO 27017 and ISO 27018?
ISO 27017 covers information security controls for cloud services generally, for both cloud providers and customers. ISO 27018 is narrower: it covers protecting personally identifiable information specifically for organizations acting as PII processors in a public cloud.
What is the shared-responsibility model in ISO 27017/27018?
Both standards make explicit that cloud security is divided between the provider, who secures the underlying infrastructure, and the customer, who secures what they configure and deploy. A penetration test typically covers the customer's side of that line - the application, API, and configuration layers.
What should a pentest report include for a cloud-scoped ISO extension?
Findings mapped to the relevant Annex A controls (A.8.8, A.8.29), severity ratings, reproducible proof for high and critical issues, developer-ready remediation, and a re-test window - scoped to the cloud-hosted systems and application layers your organization controls.
Can Intrudify certify us against ISO 27017 or 27018?
No. Intrudify runs the penetration test that supports your technical testing evidence for these extensions; certification is issued by an accredited certification body after an audit of your full ISMS, not by a pentest provider.