--- title: "ISO/IEC 27017 explained: cloud security controls for SaaS providers and buyers" description: "What ISO/IEC 27017 adds to ISO 27001, the seven cloud-only controls, how certification works and how to read a vendor's certificate before you sign." canonical: "https://saascron.com/iso-27017-explained/" language: "en-US" author: "Ricardo Machado" author_url: "https://saascron.com/author/ricardo-machado/" published: "2026-10-17T07:00:00-04:00" updated: "2026-10-17T07:00:00-04:00" category: "Security & Compliance" tags: ["SaaS security", "Compliance", "ISO 27001", "Cloud computing"] --- # ISO/IEC 27017 explained: cloud security controls for SaaS providers and buyers > What ISO/IEC 27017 adds to ISO 27001, the seven cloud-only controls, how certification works and how to read a vendor's certificate before you sign. A prospect's security questionnaire asks whether your SaaS product is "ISO 27017 certified". Or a vendor you are about to sign lists the standard on its trust page. Either way, you are not sure what it proves. ISO/IEC 27017 is a set of cloud-specific security controls that a provider adds on top of an ISO/IEC 27001 certification. Its main job is to spell out which security tasks belong to the provider and which belong to you. That split matters to two readers: the SaaS vendor that wants to pass enterprise security reviews, and the buyer who has to decide what a certificate actually covers. If the basic idea of SaaS and "who manages what" is new to you, start with [What is SaaS?](https://saascron.com/what-is-saas/) and come back. ## ISO 27017 in plain terms Think of an office building that has passed its general safety inspection. Now the owner turns it into shared space for many tenants. The inspector adds a second list: who maintains the shared corridors, who holds the master keys, and what happens to a tenant's furniture when the lease ends. The general inspection is ISO/IEC 27001. It certifies an information security management system (ISMS): the policies, risk assessments and controls a company runs to protect information. ISO/IEC 27002 is the catalog of controls that an ISMS draws from. ISO/IEC 27017 is the extra list for shared cloud services. It adds cloud guidance to existing controls and introduces controls that only make sense in the cloud. Two consequences follow. First, nobody is certified to ISO/IEC 27017 alone. Microsoft, for example, says its cloud services "are audited once a year for the ISO/IEC 27017:2015 code of practice as part of the certification process for ISO/IEC 27001:2013" ([Microsoft Learn](https://learn.microsoft.com/en-us/compliance/regulatory/offering-iso-27017)). Second, the standard is written for both sides. It gives controls to cloud service providers and to cloud service customers, so it also tells you, the buyer, what to expect and what to do yourself. ## Two editions: 2015 and 2026 Most certificates you will see in late 2026 still cite **ISO/IEC 27017:2015**. That edition, according to Microsoft's summary, gives cloud guidance on 37 controls of ISO/IEC 27002:2013 and adds seven new controls. A second edition, **ISO/IEC 27017:2026**, was published on July 27, 2026 ([IEC Webstore](https://webstore.iec.ch/en/publication/115400)). It is 39 pages long and provides "additional guidance for relevant controls specified in ISO/IEC 27002:2022" plus "additional controls with guidance that specifically relate to cloud services." It applies to every cloud deployment model, private cloud included. For you, the practical point is the year printed on the certificate. AWS describes its own certificate against the 2015 edition ([AWS](https://aws.amazon.com/compliance/iso-27017-faqs/)), and so does Microsoft. A 2015 certificate is not wrong in October 2026. It does mean the vendor still has to move to the new edition at a future audit, and you can ask when. ## The seven cloud controls of the 2015 edition The table below turns Microsoft's list of the seven new 2015 controls into the question each one lets you ask a vendor. The "who acts" column is the reading most audits apply; your contract decides the details. | Control area | What it covers | Who acts | Ask the vendor | |---|---|---|---| | Shared roles | Which security tasks belong to the provider and which to the customer | Both | "Where is your shared responsibility document?" | | Asset removal | Return and deletion of your data when the contract ends | Provider | "How soon after termination is customer data deleted, and can it be exported first?" | | Tenant separation | Keeping one customer's virtual environment apart from another's | Provider | "How do you isolate tenants, and is it tested?" | | Machine hardening | Securing the virtual machines that run the service | Provider | "Which hardening baseline do you follow?" | | Admin procedures | Documented procedures for administrative operations | Provider | "Can staff reach customer data, and is that logged?" | | Customer monitoring | Letting you monitor relevant activity in your account | Both | "Which logs can customers export, and for how long?" | | Network alignment | Matching security of virtual and physical networks | Provider | Usually covered by the audit; ask only if you run regulated workloads | Notice that two of the seven controls need action from you. A provider can give you logs and a responsibility matrix, but reading the logs and doing your half is your job. ## How certification works An accredited certification body audits the ISMS against ISO/IEC 27001 and, when the company asks for it, against ISO/IEC 27017 as well. The rules that certification bodies follow, in [ISO/IEC 17021-1](https://www.iso.org/standard/61651.html), set a three-year cycle: an initial certification audit, surveillance audits in the following years, and a recertification audit before the certificate expires. AWS, for instance, names its auditor as EY CertifyPoint, accredited by the Dutch Accreditation Council. Three parts of the certificate matter more than the logo. The **scope** names the services, sites or regions covered. The **dates** tell you whether the evidence is current. The **Statement of Applicability**, which ISO/IEC 27001 requires every certified company to keep, lists which controls the company applies and which it excludes, with a reason for each. **Example:** a vendor's certificate was issued on June 15, 2025, with a three-year validity. It expires on June 14, 2028. You sign a 36-month contract on November 1, 2026, so the contract runs to October 31, 2029. - From November 1, 2026 to June 14, 2028 is 19 months and 13 days. The certificate expires during month 20 of your contract. - From June 15, 2028 to October 31, 2029 is about 16.5 months. - For roughly 16 of your 36 months, the certificate you checked at signing is no longer the current one. That is normal. It is also why the contract should require the vendor to share its renewed certificate, not just the one on the trust page today. ## Checklist for reading a vendor's certificate Use this list when a vendor sends an ISO/IEC 27001 certificate that mentions ISO/IEC 27017. - The certificate names ISO/IEC 27017 explicitly, not only ISO/IEC 27001. - The edition is printed (2015 or 2026), and you know when the vendor plans to move to 2026 if it shows 2015. - The scope names the product you are buying, not only the company or a different service. - The regions or data centers in scope include the ones that will hold your data. - The issue and expiry dates cover today, and the expiry date is not inside your first contract year. - The certification body is accredited, and the accreditation body is named. - The certificate can be verified with the certification body (a registry, a number or a contact). - The vendor will share its Statement of Applicability, or at least the list of excluded controls. - The vendor has a written shared responsibility document, and you have read your half. - The contract asks for renewed certificates and for notice if certification lapses. ## Common mistakes 1. **Treating ISO/IEC 27017 as a standalone certificate.** It is a code of practice audited inside an ISO/IEC 27001 certification. Why it happens: vendor badges show "27017" as if it stood alone. Instead: check that the 27001 certificate exists and that 27017 appears in the same document. 2. **Assuming the vendor's certificate covers you.** AWS states plainly that customers are not "automatically certified by association." Why it happens: "certified cloud" sounds like "certified customer." Instead: map the customer-side controls (shared roles, monitoring) to owners in your own team. 3. **Ignoring the scope.** A company can certify one product and sell five. Why it happens: the certificate carries the company's name in large type and the scope in small type. Instead: find the product name and regions in the scope statement before you accept the badge. 4. **Reading only the issue date.** A three-year certificate can expire mid-contract. Why it happens: the trust page shows the certificate once and never updates the conversation. Instead: write renewal evidence into the contract, as in the worked example. ## Sources - IEC, [ISO/IEC 27017:2026, Information security controls based on ISO/IEC 27002 for cloud services](https://webstore.iec.ch/en/publication/115400), published July 27, 2026. - Microsoft, [ISO/IEC 27017:2015 Code of Practice for Information Security Controls](https://learn.microsoft.com/en-us/compliance/regulatory/offering-iso-27017), checked October 2026. - AWS, [ISO/IEC 27017:2015 compliance FAQs](https://aws.amazon.com/compliance/iso-27017-faqs/), checked October 2026. - ISO, [ISO/IEC 17021-1, Requirements for bodies providing audit and certification of management systems](https://www.iso.org/standard/61651.html). ## In three sentences ISO/IEC 27017 adds cloud-specific security controls to an ISO/IEC 27001 certification and is never certified on its own. Its most useful control for you is the shared responsibility split, because two of the seven 2015 controls need action from the customer, not the provider. Before you sign, check the edition, the scope and the expiry date on the certificate, and write renewal evidence into the contract. --- Canonical: