ISO 27017 vs ISO 27018: which do you need?

Connected technology components and cloud controls Photo: Unsplash

In ISO 27017 vs ISO 27018, the simplest distinction is security versus privacy: ISO 27017 addresses cloud security controls for providers and customers; ISO 27018 addresses protection of PII processed in public clouds.

The operational boundaries, however, frequently intersect.

This guide covers:

Scope, roles, controls, and assurance differences
Where cloud security and PII protection overlap
A decision table for SaaS providers and customers
How to implement both without duplicate work

Related guides:

Choosing the right connected path

GIF via GIPHY

Key takeaways

ISO 27017 is cloud-security guidance; ISO 27018 is public-cloud PII guidance.
The standards solve different problems and often belong together.
Roles determine relevance. ISO 27017 covers provider and customer duties; ISO 27018 focuses particularly on public cloud providers acting as PII processors.
Controls overlap, but evidence context differs. An access review may support both, while privacy also needs purpose, instruction, and data-lifecycle records.
Use one control system with multiple mappings. Do not create duplicate access, incident, supplier, or deletion workflows.

The core difference

ISO 27017 extends ISO 27002 guidance for cloud services. It clarifies divided control ownership and adds cloud-specific guidance around tenant separation, virtual environments, cloud administration, monitoring, network alignment, and customer asset return/removal.

ISO 27018 provides PII protection guidance for public cloud computing when the provider processes PII for a customer. It emphasizes processing according to instructions, limiting use, transparency, disclosures, subprocessor governance, support for customer obligations, and return or deletion.

Neither replaces ISO 27001. Organizations commonly use an ISO 27001 ISMS as the governance foundation, then apply ISO 27017 and ISO 27018 based on cloud and privacy risks.

Side-by-side comparison

Dimension	ISO 27017	ISO 27018
Main objective	Secure cloud services	Protect PII in public cloud processing
Primary roles	Cloud provider and customer	Public cloud PII processor and customer
Focus	Security responsibilities and cloud technology	Privacy principles and PII lifecycle
Distinct topics	Isolation, virtual machines, admin, monitoring	Purpose, instructions, disclosure, return/deletion
Typical owner	Security/cloud engineering	Privacy/legal with security and engineering
Common foundation	ISO 27001 and ISO 27002	ISO 27001/27002; often privacy governance
Buyer question	“Is the cloud service securely operated?”	“How is our PII used and controlled?”

ISO 27017 can matter even when no PII is processed because confidentiality, integrity, and availability apply to other data. ISO 27018 is relevant where the role and processing environment fit its PII-processor focus.

Where the controls overlap

Both standards benefit from mature access control, cryptography, logging, incident response, supplier management, personnel security, asset management, and secure deletion.

Consider a customer termination:

ISO 27017 asks whether customer assets are returned or removed securely and whether provider/customer duties are clear.
ISO 27018 adds PII-specific considerations: customer instructions, retention limits, backup treatment, legal constraints, and transparent confirmation.

One offboarding workflow can satisfy both when it records service, data category, authority, export decision, deletion targets, backup expiry, access removal, exceptions, owner, and completion.

Shared workflow	Security evidence	Privacy evidence
Access review	Roles, MFA, removals	Need-to-know access to PII
Incident response	Detection and containment	PII impact and notice decision
Supplier review	Security assessment	Processing purpose, location, terms
Deletion	Secure removal result	Instruction, retention, confirmation

Which standard does your SaaS need?

SaaS scenario	ISO 27017	ISO 27018	Practical choice
B2B SaaS hosts customer business data	High value	Depends on PII	Start 27017; assess PII role
HR or healthcare SaaS processes customer PII	High value	High value	Implement both
Infrastructure service with no intended PII	High value	Role-dependent	Prioritize 27017
SaaS buying critical cloud infrastructure	Customer guidance applies	Evaluate vendor PII role	Use both in supplier review
Enterprise buyers ask security and privacy questions	High value	High value	One combined program

Ask five questions:

Do we provide or consume material cloud services?
Do we process PII in a public cloud for customers?
Are buyers asking for cloud-security or processor-privacy assurance?
Which risks and contractual promises are hardest to prove?
Is an ISO 27001 ISMS already operating?

If cloud security is the immediate gap, start with ISO 27017 while designing reusable privacy evidence. If customer PII is central, implementing both together is commonly more efficient.

Apply the decision at the service level

An organization-wide answer can be too broad. One product may process customer PII in a multi-tenant public cloud, while another handles only public content. Evaluate each service and role, then aggregate the result into the ISMS scope.

Document:

Data categories and business purpose
Provider, customer, processor, and other relevant roles
Deployment and tenancy model
Regions, transfers, and subprocessors
Customer security and privacy commitments
Control gaps and planned assurance claims

This service-level record supports an explainable decision. It also prevents sales teams from applying a certificate or statement to products outside its scope.

Use buyer demand carefully

Security questionnaires can identify market expectations, but they should not be the only risk method. A buyer may ask for ISO 27018 when the service’s role does not fit neatly, or request “ISO 27017 certification” without specifying acceptable evidence. Clarify the underlying need: secure cloud operations, PII processor assurance, an ISO 27001 certificate, or control documentation.

Respond with precise scope and issued documents. Where a standard is implemented but not named on a certificate, describe the assessment accurately and offer supporting control information under appropriate confidentiality. Avoid making a broader claim simply to satisfy a questionnaire field.

How to implement both

Create one integrated project:

Scope services, organizations, data, regions, and roles.
Map ISO 27017 and ISO 27018 to the existing control library.
Perform a combined gap assessment.
Assign accountable control owners.
Update responsibility matrices, processing agreements, and procedures.
Implement technical controls and workflow handoffs.
Collect evidence through normal operations.
Run internal audit and management review.

Security/GRC commonly coordinates mapping; cloud engineering owns baselines and monitoring; privacy and legal own processing terms; procurement governs subprocessors; support runs customer requests; internal audit tests the complete chain.

For external claims, confirm assessment criteria, scope, and certificate wording with the certification body. Codes of practice may be assessed alongside ISO 27001, and wording can vary.

Build one cross-functional operating model

Set a common control owner for overlapping outcomes and designate specialist reviewers. Security may own privileged access while privacy confirms access to PII is limited to an appropriate purpose. Procurement may own supplier intake while security and privacy complete different diligence sections. One ticket should preserve all approvals and remediation.

Use change events to trigger both perspectives:

A new region triggers architecture, logging, transfer, and transparency review.
A new support integration triggers access, supplier, purpose, and retention review.
A new analytics feature triggers secure configuration and PII-use review.
A changed backup design triggers resilience and deletion analysis.

Measure control health with a balanced set of indicators: cloud configuration exceptions, privileged access completion, missing log coverage, overdue supplier reviews, deletion failures, and open privacy incident actions. Review trends together so improvements in one domain do not create hidden risk in the other.

Manage cloud assurance in SecureSlate

SecureSlate lets teams map one control to multiple standards, assign owners, automate evidence, track risks and findings, and answer cloud security and privacy reviews from a consistent source.

Get started for free: Create your SecureSlate account

FAQ: ISO 27017 vs ISO 27018

Does ISO 27018 include cloud security?

It relies on security controls but adds PII-focused privacy guidance. ISO 27017 provides more cloud-security-specific detail.

Do we need ISO 27018 if we have ISO 27017?

Potentially. ISO 27017 does not fully address public-cloud PII processor transparency, purpose, instructions, and privacy lifecycle expectations.

Can the same evidence support both?

Yes. Access, encryption, incidents, suppliers, and deletion often overlap, but each mapping should explain the relevant outcome.

Which should we implement first?

Base the sequence on role, risk, buyer demand, and ISMS maturity. PII-heavy SaaS providers commonly implement both together.

Disclaimer (legal note)

SecureSlate is not a law firm, and this article does not constitute legal advice. Consult qualified legal counsel, privacy professionals, official standards, and your certification body.