ISO 27017 in Real Audits: What the Cloud Controls Actually Catch

Compliance

ISO 27017 is the cloud-specific extension of ISO 27002. As a checklist for both cloud customers and providers it pulls weight. Here is what auditors look at and where teams typically fail.

By Arjun Raghavan, Security & Systems Lead, BIPI · June 22, 2024 · 6 min read

ISO 27017 has lived in the awkward middle of cloud security frameworks since 2015. It is not a certification on its own; it is implemented as part of an ISO 27001 program with cloud scope. The 35 cloud-specific controls it adds to ISO 27002 read like common sense, which has caused most teams to skim them. We have helped four cloud-native SaaS companies through ISO 27001 with 27017 scope, and the controls catch real issues every time.

Why bother adding 27017 scope

ISO 27001 by itself does not require cloud-specific controls. You can certify a fully cloud-hosted SaaS without ISO 27017 in scope. So why do it? Three reasons we hear from clients: enterprise buyers in regulated sectors specifically ask for it on questionnaires, it forces a cleaner separation of customer and provider responsibilities than 27001 alone, and it is the entry point to ISO 27018 (privacy in the cloud) which buyers increasingly want.

The premium on certification is small. Most certification bodies charge a 10 to 20 percent uplift for adding 27017 to an existing 27001 audit. The internal effort is larger because the controls require evidence that often does not exist in a default cloud SaaS.

The shared responsibility documentation control

Control CLD.6.3.1 requires both customer and provider to document and agree on the allocation of information security responsibilities. Auditors take this seriously. They will ask for a written matrix that covers identity management, data encryption, network controls, monitoring, and incident response, with explicit ownership for each.

Most SaaS companies we have audited had this matrix as a marketing PDF on their trust center. That is not enough. The auditor wants the actual document used internally, signed by both parties, attached to the customer contract. We had to build this for a workflow automation vendor in 2024. The work surfaced three responsibility ambiguities that legal had not noticed in three years of contracts.

Returning or removing customer assets

Control CLD.8.1.5 requires the cloud service provider to return or remove customer assets, including data, after the contract ends, in a timeframe and format both parties agreed on. The auditor will ask three questions: what is the agreed retention period, what is the deletion mechanism, and how do you evidence deletion to the customer.

The deletion evidence question is where most providers fail. Saying you ran a delete query is not evidence. Auditors want logs showing the deletion, with a hash or some other artifact that proves the records are gone. We built one client a deletion certificate workflow that runs nightly, processes ended-contract tenants, and emails a signed receipt to the former customer. It took six weeks of engineering work and made future audits painless.

Controls that catch real issues

• CLD.9.5.1 (segregation in virtual computing environments) catches teams running customer workloads on shared instances without proper isolation
• CLD.12.1.5 (administrator's operational security) catches privileged access without MFA and audit logging
• CLD.12.4.5 (monitoring of cloud services) catches gaps where provider-side logs are not ingested or retained by the customer-facing security team
• CLD.13.1.4 (alignment of security management for virtual and physical networks) catches inconsistent firewall rules between IaC and what is actually deployed

What auditors typically look for

The auditor walks in with a sample of customer accounts, picks one or two, and traces the responsibility matrix end to end. They look at how the customer's data was provisioned, encrypted, monitored, backed up, and (for terminated accounts) deleted. They cross-check the provider's claims against logs they ask for during fieldwork.

Three patterns produce findings consistently. First, marketing claims that are not backed by technical evidence. Second, IaC drift where the documented control does not match the deployed reality. Third, missing or inconsistent logging across regions or environments. None of these are exotic, and all of them are catchable in advance with an internal mock audit.

When 27017 is not worth it

If you sell only to non-regulated SMB buyers and your customers do not ask for it on questionnaires, ISO 27001 alone is sufficient. The controls 27017 adds are good practice, but if your customers are not paying you for the certification you should put the budget elsewhere. We have advised two clients to skip 27017 and invest in SOC 2 Type II instead because their actual buyer demand pointed that direction. Compliance work follows the buyer, not the framework catalogue.

Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.