There is a sentence that appears in a great many security questionnaires, and it is doing no work at all.
“We host with a provider certified to ISO 27001.”
True, almost certainly. Also irrelevant to whether you meet the control. The provider’s certificate describes the provider’s management system operating over the provider’s scope. Your control lives in your environment, and the certificate says nothing about it.
This piece is about how to close that gap properly, control by control, without doing the work three times if you run in more than one cloud.
Table of contents
Open Table of contents
What a provider certificate actually asserts
All three large providers carry a broadly similar portfolio, and the similarity is the trap. The interesting information is not which standards appear on the list but what sits inside the scope of each certificate.
Four questions matter, and only the last is ever asked.
Which legal entity. Certificates are issued to named entities. In a group of companies the entity on the certificate may not be the entity in your contract.
Which services. This is the big one. Provider certification does not cover every service in the catalogue. One provider’s information security and cloud privacy audits covered sixty one customer facing services. That is a large number and it is very far from everything offered. A service outside the audit scope is not covered by the certificate, no matter how prominently the certificate is displayed. If you build on a service that launched eight months ago, check before you rely on it.
Which regions. Scope is regional. A service in scope in one region may not be in another.
Which edition and which date. Certificates name the edition of the standard and expire. Editions themselves move: the cloud privacy standard was revised in 2025, and certificates referencing the previous edition remain valid until reissued. Neither fact is a problem. Not knowing which you are relying on is.
The three providers, side by side
Positions as at August 2026. Certificates get reissued with different services in scope, so check the portal before you cite any of this in an audit.
| Standard | AWS | Azure and Microsoft cloud | Google Cloud |
|---|---|---|---|
| Information security, 2022 edition | Yes | Yes | Yes, covering the systems, people, processes and data centres serving the platform |
| Cloud controls companion, 2015 | Yes | Yes | Yes |
| Personal data in public cloud | Yes, 2019 edition | Yes, assessed within the information security audit | Yes |
| Privacy management extension | Yes, 2019 edition | Yes | Yes, as a processor of personal data |
| Business continuity | Yes, 2019 edition | Yes | Yes, scoped to data centres |
| Service management, 20000 part 1 | Yes, 2018 edition | Yes | Yes, 2018 edition |
| Quality management | Yes, 2015 edition | Yes | Yes |
| Energy management | Not listed | Not listed | Yes, 2018 edition |
| AI management, 2023 edition | Bedrock, Q Business, Textract, Transcribe | Azure AI Foundry Models, Microsoft Foundry, Security Copilot, GitHub Copilot, Microsoft 365 Copilot, Copilot Studio | Google Cloud Platform, Google Workspace, Gemini app |
| Cloud Security Alliance registry | Yes, against the fourth version of the matrix | Yes, certification against the matrix | Yes |
The AI management row is the whole problem in miniature
All three hold the same certificate, against the same edition of the same standard, issued by accredited bodies. Now look at what each one actually put inside the scope.
AWS was first to announce accredited certification, and scoped it to four services: Amazon Bedrock, Amazon Q Business, Amazon Textract and Amazon Transcribe. Its first surveillance audit completed in November 2025 with no findings.
Microsoft scoped it to products rather than to the platform: Azure AI Foundry Models and Microsoft Foundry on the building side, and the assistant range on the other, meaning Security Copilot, GitHub Copilot, Microsoft 365 Copilot and Copilot Studio.
Google scoped it broadest of the three, to Google Cloud Platform and Google Workspace, plus the Gemini app.
So consider what happens when you train and serve a model on Amazon SageMaker, and your questionnaire asks whether your AI provider holds the AI management standard. AWS does hold it. SageMaker is not among the four services in its scope. The certificate is genuine, current and accredited, and it says nothing whatsoever about the service you actually built on. Answering yes is not a lie so much as a category error, and a competent assessor will find it in one follow up question.
The same trap sits inside Microsoft’s list. Azure AI Foundry Models is named. Whether the specific model endpoint, search index or agent service you are using falls inside that boundary is a question the certificate answers and the marketing page does not. Google’s broader scoping helps, and even there “Google Cloud Platform” in a scope statement is a phrase with a definition attached, not a wave at the whole catalogue.
Three providers, one standard, three answers that a compliance matrix recording “certified” in all three cells would flatten into nothing.
The same effect operates more quietly on the certificate everybody actually cites. Information security scope differs between providers and changes between issues. One provider’s information security and cloud privacy audits covered sixty one customer facing services, which is a lot and nothing like the whole catalogue. Newer services across all three tend to sit outside audit scope for a period after launch, which is exactly when teams are keenest to adopt them.
Where to get the authoritative version:
| Provider | Where the evidence lives |
|---|---|
| AWS | Artifact, in the console. Reports and certificates on demand, some under confidentiality terms |
| Azure and Microsoft cloud | The Service Trust Portal, with compliance tooling surfaced inside the admin experience |
| Google Cloud | Compliance Reports Manager, alongside the public compliance offerings pages |
Each requires you to be signed in, and some documents oblige you to accept confidentiality terms before download. Whoever holds your compliance evidence should have an account on all three, not a folder of certificates somebody saved in 2024.
There is no such thing as an inherited control
This is the framing that makes the rest of the exercise straightforward.
People talk about inheriting controls from a provider. You cannot. A control is something that operates in your organisation. What you actually inherit is evidence that somebody else operates a control you have decided to depend on, plus the residual risk of that dependence, which stays with you.
That distinction has practical consequences. If an auditor asks how you control physical access to the facility housing your data, the answer is not that the provider does it. The answer is that you assessed the provider, obtained current independent assurance covering the relevant scope, recorded the reliance decision, and review it on a defined cycle. That is your control. It is a supplier assurance control, and it is genuinely satisfied by the provider’s certificate, which is precisely why the framing matters. You are not pretending to run a data centre. You are running a supplier assurance process, and being clear about which of the two you are evidencing is the whole trick.
Where the mapping already exists
Most organisations build this mapping by hand in a spreadsheet. Three sources already contain most of it.
The Cloud Controls Matrix. The Cloud Security Alliance publishes a control framework of 207 controls across 17 domains, currently in its fourth version, and it maps explicitly to the information security standard, the cloud controls companion, the major payment standard and the main national control catalogue. Critically for this purpose it carries a shared responsibility view, so it states for each control whether it falls to the provider, the customer, or both. That is the per item mapping people set out to build from scratch.
The registry questionnaire. The same body publishes a questionnaire, aligned to the matrix, that providers complete and submit publicly. You get the provider’s own answer, control by control, in a format that is identical across providers. This is the only place you can compare the three clouds on the same axis without doing the normalisation yourself.
The user entity controls in the attestation report. This one is underused to the point of being a minor scandal. A service auditor’s report contains a section, within the system description, listing the controls the provider assumes its customers will operate. Enforcing more than one authentication factor. Removing accounts for departed staff promptly. Reviewing permissions. Configuring the address restrictions offered to you.
Read that list carefully, because it is the provider telling you, in writing, exactly which parts of the arrangement are yours. If you operate none of them, the provider’s own assurance does not hold for your use of the service. It is the closest thing to a definitive answer to “what do I still have to do”, and it is sitting in a document most people download to satisfy a checklist and never open.
Those documents come from the providers’ compliance portals, which each require you to be signed in and, in some cases, to accept confidentiality terms before download.
The mapping, by control theme
The current information security standard organises its 93 controls into four themes. Ownership across them is not evenly distributed, which is the useful thing to notice.
| Control area | Who operates it | What you still owe |
|---|---|---|
| Policies, roles, responsibilities | You, entirely | Nothing inherits here. The provider has no view of your policy set |
| Supplier and cloud service management | You, entirely | This is where provider assurance is consumed rather than claimed |
| People: screening, training, discipline | Split by employer | Provider covers its staff, you cover yours. No overlap, no inheritance |
| Physical and environmental security | Provider, almost entirely | A reliance decision, current assurance, and a review cycle |
| Endpoint devices | You, entirely | Provider certification is silent on your laptops |
| Identity and privileged access | Provider supplies, you operate | Mechanism inherited, configuration and review yours |
| Authentication strength | Shared, and named in user entity controls | Provider offers additional factors, you enforce them |
| Cryptography | Provider supplies, you decide | Key management service inherited. Key choice, rotation and scope are yours |
| Logging | Provider emits, you retain and read | The log source is inherited. Retention, protection and review are not |
| Monitoring and detection | You, substantially | Provider watches its platform, not your workload behaviour |
| Backup | Provider supplies, you specify | Snapshot capability inherited. Recovery objectives and restore testing yours |
| Network security and segregation | Shared | Provider isolates tenants, you segment your own estate |
| Secure development | You, entirely for your code | Applies to the platform’s software, not yours |
| Configuration and change management | You, for anything you deploy | Provider change control covers the platform beneath you |
Two patterns are worth pulling out.
The genuinely inheritable material is concentrated in physical security and the underlying platform, which is a small share of the total. Everywhere else you either own the control outright or you own its configuration, and configuration is where nearly all real world failures live. The provider offering encryption at rest tells you nothing about whether you enabled it, on which stores, with which keys.
The rest of the standard is largely unaffected by which cloud you chose, and much of it is unaffected by whether you use cloud at all.
Three ways the mapping goes wrong
Confusing availability with operation. The most common failure by a wide margin. A capability existing in the platform is not a control operating in your environment. Every audit finding of the form “encryption was available and not enabled” is this mistake.
Assuming parity between providers. The certificate portfolios look similar enough that people map once and apply the result to all three. Service level scope differs, regional scope differs, and the newer services in each catalogue tend to sit outside audit scope for a period after launch. Map to a neutral framework, then to each provider separately, and keep the differences visible.
Letting the evidence go stale. Certificates expire, reports cover a stated period, and scope changes between issues. A reliance decision recorded three years ago against a certificate that has since been reissued with different services in scope is not assurance, it is a filed document.
A method that scales
If you run in more than one cloud, do not maintain three mappings.
Keep one control set, expressed in your own language and covering your whole estate. Map it once to a neutral framework, and the cloud controls matrix is the obvious candidate precisely because it already maps outward to the standards you are asked about. Then, per provider, hold three documents: the current certificate and report with their scope recorded, the completed registry questionnaire, and the user entity controls list with each item assigned to a named owner in your organisation.
That last piece is what turns compliance mapping from a documentation exercise into something operationally real. Every user entity control is a task somebody has to perform. Give each one an owner and a review date and you have converted a section of a report nobody reads into a working list.
Then keep the shape of the answer straight. For any control you are asked about, you are asserting one of three claims: that you operate it, that you rely on a provider and here is the current assurance and the reliance decision, or that it does not apply and here is the reasoning. Three answers, and the second one is the only place a provider certificate belongs.
The sentence at the top of this piece tries to use the second answer for controls that need the first. That is the whole problem, and it is why the mapping has to go control by control rather than provider by provider.