A customer asks how you meet a control your cloud provider handles. What can you claim from their certification?

Controls are not inherited whole

The phrase "we inherit that from our cloud provider" is doing too much work. Almost every control divides into a part the provider performs and a part you perform, and the split is rarely where people assume. Physical security of the data centre, media sanitisation of failed disks, and environmental controls are genuinely theirs, and nothing you can do would help. Encryption at rest is shared: they supply the mechanism, you decide whether it is enabled, which key is used, who can use that key, and whether the key is rotated. Access control is almost entirely yours, because the provider secures the hypervisor and the console, not your role definitions.

So the answer to the customer is a division, not a citation. Name the part performed by the provider and point at their report; name the part performed by you and produce your own evidence. A response that consists only of the provider's certificate reads to an experienced reviewer as a team that has not looked at where the line falls, and the follow-up question will be about a control on your side of it.

The section of their report that tells you your homework

A service auditor's report contains a set of complementary user entity controls: the things the report explicitly assumes the customer does, without which the provider's controls do not achieve the stated objectives. It is the most useful hour anyone on your team will spend with that document, because it is a written list of your obligations produced by the auditor of the system you depend on. Typical entries are unglamorous and specific — you are responsible for managing your own users and their credentials, for configuring the service securely, for reviewing the logs the provider makes available, for notifying them when an administrator leaves.

Reading that list changes what you claim. Every entry is a control you own, and if you cannot evidence it, the provider's opinion does not cover you. Reports also disclose how the provider handles its own suppliers: subservice organisations are either carved out of the report, meaning their controls were not tested and you must assess them separately, or handled inclusively, meaning they were. Which of the two applies determines whether there is a further layer of vendor work behind the certificate you were just handed.

Scope, period and services

Three checks turn a certificate from decoration into evidence.

The first is scope. An ISO 27001 certificate covers a defined scope stated on the certificate itself, and that scope statement is the whole of what the certificate tells you. The Statement of Applicability is not issued with it: clause 6.1.3 d) requires the SoA to record the necessary controls and to justify both their inclusion and the exclusion of any Annex A control not applied, but it is an internal ISMS document, and plenty of providers will decline to release it or will only do so under an NDA. Plan on the scope statement being your evidence and treat sight of the SoA as something you ask for rather than something you are handed. A certificate whose scope is one business unit or one product tells you little about the service you depend on. Similarly, a service auditor's report lists the systems and services in scope, and providers with large catalogues do not include every service in every report — the newest managed service you built your architecture on may not be there yet.

The second is period. A type 2 report opines on whether controls operated effectively throughout a stated period, which is the only form that says anything about operation rather than design. That period ended before you read it, so there is a gap between the report's end date and today. The customary answer is a bridge letter from the provider covering the interval, and you should know what one is worth before you rely on it. A bridge letter is a management representation signed by the service organisation itself, not an opinion from the auditor, and nothing asserted in it has been independently tested. It narrows the gap by giving you the provider's word that no material change has occurred since the period end; it does not close it. The customary engineering answer is to record the report date, the period, and your review date in your vendor register so the gap is visible rather than discovered during your own audit.

The third is applicability. A report can be current, in scope, and still not address the control your customer asked about, because the provider's control objectives are theirs and not a superset of your framework. Mapping is required, and it is honest work: some of your controls will map cleanly, some partially, and some not at all.

What your evidence for an inherited control looks like

Auditors do not accept "the provider does it" as an unsupported assertion, and the artefact they want is a review record rather than the report itself.

Element	What it shows
The provider's current report or certificate, filed with its date	The reliance exists and is not stale
A note of the scope, listed services and period, checked against what you use	You verified relevance rather than filing a PDF
Your assessment of the complementary user entity controls	You know which parts are yours
Evidence for those parts, from your own systems	The controls you own actually operate
Named reviewer and review date, on a recurring cycle	Reliance is maintained, not one-off

The pattern is the same as any other control: an objective, an implementation, and an artefact an independent person can inspect. What changes for an inherited control is that part of the implementation belongs to somebody else, and your implementation is the diligence.

The failure that produces a bad finding

The version of this answer that goes wrong is not the one that says too little. It is the one that says the certificate covers something it does not, because that is an inaccurate statement to a customer and, in a questionnaire or a contract schedule, potentially one with commercial consequences. Two examples recur. Claiming encryption in transit for internal traffic because the provider offers it, when your services talk over plaintext inside the virtual network. Claiming a control over logging because the provider retains platform logs, when nobody configured export and the default retention is far shorter than the period your framework requires.

Both are cases where the capability existed and the configuration did not, and both are found by the first auditor who asks to see it rather than hear about it. When you are unsure whether a claim is supportable, the safe engineering answer is to describe what you have verified and route the wording of the claim itself to whoever owns your compliance programme, because how a control statement is phrased to a customer is their judgement rather than yours.