Once ISO/IEC 27001 certification is done — or while the plan for it is still being drawn up — customers start asking a second question: "Do you hold the cloud certifications?" The names that come up are ISO/IEC 27017 and ISO/IEC 27018.
Neither is a certification you obtain on its own. Both are add-ons that sit on top of an existing ISMS certification. Miss that structure and you end up asking a certification body for something that cannot be quoted: "27017 only."
This article covers what each standard addresses, how they attach to an ISMS, what it means that the requirements split between cloud providers and cloud customers, and when a healthcare SaaS or PHR operator genuinely benefits from adding them. For the overall picture of ISMS, see What Is an ISMS (ISO/IEC 27001)?.
Disclaimer: This article is general information. The authoritative texts are ISO/IEC 27001, 27017, and 27018 themselves and the publications of the accreditation and certification bodies. Base actual decisions on those.
Where the Two Standards Sit
The ISO/IEC 27000 family contains requirements standards that can be certified against (27001) and guidance standards that describe how to implement. 27017 and 27018 belong to the second group.
They are nonetheless spoken of as "27017 certification" because a scheme exists to audit them as an add-on to ISMS certification. In Japan, ISMS-AC operates this as the ISMS Cloud Security Certification.
| Standard | Subject | Role | Standalone? |
|---|---|---|---|
| ISO/IEC 27001 | Information assets generally | The requirements standard that forms the base | Yes — this is the body of it |
| ISO/IEC 27017 | Information security for cloud services | Cloud-specific implementation guidance plus extended controls on top of 27002 | No — 27001 is a prerequisite |
| ISO/IEC 27018 | PII in public clouds | Guidance for operating as a PII processor in the cloud | No — 27001 is a prerequisite |
The practical consequence: you can only certify within your ISMS scope. A service left out of the ISMS scope cannot be covered by 27017 separately. Conversely, if an add-on is on the roadmap, the service must be inside scope when scope is first decided. See Defining ISMS Scope and Scope Design for Healthcare Companies.
ISO/IEC 27017 — Filling the Cloud-Specific Gaps
27017 addresses what on-premises-oriented controls leave out: separation in virtualised infrastructure, the boundary of administrative privilege, who is responsible for collecting which logs, deletion of data at contract termination — the areas where "where does my responsibility end" turns vague.
It has two kinds of content:
- Cloud-oriented implementation guidance for the controls in 27002, written separately for cloud providers and cloud customers
- Extended, cloud-specific controls — segregation in virtual environments, operational security for administrators, monitoring, return and removal of assets
The most important practical point is that requirements are written separately for the cloud service provider (CSP) and the cloud service customer (CSC).
| Role | Typical organisation | What is asked of you |
|---|---|---|
| Cloud service provider (CSP) | A company offering SaaS/PaaS/IaaS | Tenant separation, control and logging of administrative actions, information that must be disclosed to customers, data handling at termination |
| Cloud service customer (CSC) | An organisation running its service on, or using, someone else's cloud | Risk assessment of the cloud used, awareness of configuration responsibility, its own access management, logging, and key management |
Most healthcare SaaS companies are both at once: a CSP to their hospital customers, a CSC to AWS or Azure. Both postures can be in scope at audit. This doubling overlaps with the shared responsibility discussion in Security Design for AI-Assisted EMRs: the Shared Responsibility Model.
ISO/IEC 27018 — Protecting PII Held in the Cloud
27018 is guidance for the party that holds and processes other people's personally identifiable information in a public cloud — the PII processor. Whose information? The individuals behind your customer. In healthcare SaaS, that is the patient data a hospital enters into your system.
What distinguishes 27018 is how firmly it insists that you do not use entrusted data for your own purposes. Typical topics:
- Not using entrusted PII beyond the customer's instructions — advertising and marketing being the named example
- Disclosing subcontractors and having a procedure for customer consent
- How to handle law enforcement disclosure requests, and the approach to notifying the customer
- Disclosing the countries where PII is stored
- Return and deletion of PII at termination, with evidence
- Restricting which personnel can access PII, and binding them to confidentiality
That makes it the certification that answers, directly, the customer worry of "prove you will not repurpose the data I gave you." With anxiety about generative-AI training use running high, this lands especially well in healthcare. See also Generative AI in Healthcare: A Legal and Security Guide.
Note that 27018 does not itself certify compliance with Japan's personal information law or the GDPR. For that framing, ISO/IEC 27701 is the better fit.
Choosing Between 27017, 27018 and 27701
Three add-ons is one too many to hold in the head. Split them by whose worry each one answers.
| Standard | The question it answers | Typical reason to certify |
|---|---|---|
| ISO/IEC 27017 | Does this cloud service handle cloud-specific risk? | You provide SaaS/PaaS and must explain infrastructure, tenant separation, operational control |
| ISO/IEC 27018 | Will the provider repurpose the personal data I entrust? | You hold large volumes of customer personal data and need to settle secondary-use concerns |
| ISO/IEC 27701 | Is privacy managed as a management system? | You need to demonstrate a compliance posture including GDPR, and to sort out controller/processor roles |
27017 and 27018 are frequently certified together, since audit coverage overlaps and doing them separately costs more. 27701 is a different order of effort — see ISO 27701 (PIMS): Connecting Privacy to Your ISMS.
Where overseas counterparties are involved, which accreditation body stands behind your certification body can matter — see ISMS-AC, UKAS and ANAB.
The Decision for Healthcare SaaS and PHR Operators
The answer turns on what your customers actually inspect.
Add-ons pay off when
- Hospital or pharma procurement documents and security check sheets repeatedly probe cloud-specific controls — tenant separation, key management, deletion evidence
- Questions about secondary use and AI training recur, and contract wording alone is not settling them
- You have overseas customers or partners, and explaining a domestic-only certification is costing time
ISMS alone is enough when
- The only thing specified as a condition of trade is "ISMS certification"
- You are mainly a cloud customer, with a narrow provider-side responsibility
- Your first ISMS certification is not yet complete, or the operating cycle has not run once
Realistically, run the ISMS for one full cycle before widening. The add-ons operate on top of the existing ISMS machinery; broadening scope while the base is still unsteady multiplies the burden on internal audit and management review without adding assurance.
Knowing what hospitals ask of suppliers sharpens the decision: Security Check Sheets for Vendors and The Three-Ministry Guidelines are written from the buyer's side.
Conclusion
- 27017 and 27018 cannot be certified standalone — they are add-ons to ISO/IEC 27001
- 27017 covers cloud-specific controls, written separately for providers (CSP) and customers (CSC); healthcare SaaS is usually both
- 27018 centres on not repurposing entrusted PII — it answers secondary-use and AI-training concerns directly
- To demonstrate a compliance posture, 27701 fits better; 27017 and 27018 are efficient to certify together
- Decide by what your customers actually ask, and only after one full ISMS operating cycle
- If add-ons are on the roadmap, put the service inside ISMS scope from the start
Pottech supports ISMS certification with a focus on healthcare. We supply templates for procedures, registers, and training material and lead project management and dealings with the certification body, so your team can concentrate on decisions such as what belongs in scope — including scope designed with cloud add-ons in mind.
See ISMS Certification Support for scope and pricing, or contact us to discuss your situation.
References and Sources
- Information Management System Accreditation Center (ISMS-AC)
- ISO/IEC 27017 Information security controls for cloud services | ISO
- ISO/IEC 27018 Protection of PII in public clouds acting as PII processors | ISO
- ISO/IEC 27001 Information security management systems | ISO
- Guidelines for the Safe Management of Medical Information Systems | MHLW
Note: interpretation of requirements and controls, and the handling of accreditation and certification, are governed by the standards themselves and the publications of the accreditation and certification bodies. Add-on certification schemes are subject to revision.