Audit · September 2026
The shared responsibility model is a diagram, not evidence. That is where audits stall.
Every cloud provider publishes one. Every auditor has seen it. It tells you who was supposed to do something. It has never once shown that anybody did.
13 September 2026 · Kenio Shirley
The diagram everyone cites and nobody can evidence
"Security of the cloud versus security in the cloud" is a good sentence. AWS, Azure and Google all publish a version of it, and as an allocation of duty it is basically correct.
Then an auditor asks a narrower question: for control AC-2, in this system boundary, during this period, show me the artefact. The diagram has no answer, because a diagram is an assertion about intent. Evidence is a record of state.
In fifty-odd audits I have never seen a finding that said the shared responsibility model was wrong. I have lost count of the findings that said nobody could prove their half of it.
The same control reads differently at each layer
Teams inherit a matrix written for one service model and apply it to an estate that spans three. That is where the first set of gaps opens.
| Layer | Provider holds | You hold | Where it goes wrong |
|---|---|---|---|
| IaaS | Hypervisor, physical, network fabric, region availability. | Every guest OS, every patch, every identity, every security group, every key. | Nearly all control text lands on you. Inheritance is thin and easily over-claimed. |
| PaaS | Runtime, managed patching of the platform, service-level hardening. | Configuration of the managed service, identity, data classification, logging retention. | The same control ID reads 'inherited' and 'customer' depending on one config flag. |
| SaaS | Almost all technical controls, in a scope the provider defines. | Access reviews, admin roles, tenant configuration, offboarding, data export. | Least technical work, most orphaned controls — nobody is assigned the admin-side ones. |
Four failure patterns, in the order they show up
Pattern 1
Assumed inherited, never inherited
The control appears in the provider's matrix as shared. The customer half was never implemented because the diagram made it look covered.
Pattern 2
Genuinely inherited, never evidenced
You are entitled to inherit it, but you hold no artefact showing the inheritance applies to your boundary in the audit period.
Pattern 3
Attestation scope ≠ your boundary
The report covers a service list, region set and period that do not match the system you are certifying. The gap is invisible until an auditor reads both.
Pattern 4
Orphaned CUECs
Complementary user entity controls sit in the back of the provider's report. They are your controls. Frequently nobody has been assigned them.
Your provider's attestation is not your evidence
A provider's SOC 2 report proves something about the provider. Four things stop it proving anything about you.
Scope. The report names services and regions. Anything you run outside that list is uncovered, and estates drift out of scope quietly — a new region, a new managed service, a migration.
Carve-outs. Subservice organisations are often excluded from testing. The report tells you so, in a paragraph most readers skip.
CUECs. Complementary user entity controls are the report's own statement of what it assumes you are doing. They are assignments, not reassurances.
Period. A report covering January to December says nothing about February of the following year, which is frequently when your own audit window sits.
What an auditor actually accepts
Three things, and they are the same three every time. Configuration state at a point in time, from the system itself rather than from a person describing it. Change history showing what moved between those points and who approved it. And a repeatable method, so the same query run in March and in November produces comparable artefacts.
Screenshots fail the third test. A screenshot proves one console, one moment, one person's framing of it, and it cannot be re-run.
Evidence that can be regenerated on demand ends the conversation. Evidence that was assembled by hand starts a new one.
One control, from matrix row to accepted artefact
Take encryption of data at rest. The matrix row says shared: the provider supplies the encryption capability and key infrastructure, you decide whether it is switched on and who can use the key.
The provider's half is discharged by their attestation, for the services in its scope. Your half is not discharged by anything in that document. It is discharged by a list of every storage resource in your estate with its encryption state and key reference, produced from the cloud APIs, dated, and paired with the key policy showing who can decrypt.
Then the part most teams miss: the same list run again three months later, with the delta. An auditor testing a period wants to know the control held across it, not that it held on the day you exported the spreadsheet.
Treat every inherited control as unproven until you hold your own artefact for it. Publish a responsibility register next to the diagram, with a named owner and a named artefact per row.
Where Keystone helps, and where it does not
Keystone covers your side of the line: it reads the estate through the cloud APIs, records configuration state and change history, and holds the result as hash-chained evidence that can be regenerated for any date in an audit period.
What it cannot do is prove your provider's half. No tool can — that is what their attestation is for, and reading its scope, carve-outs and CUECs against your boundary is human work. Keystone does not ingest SOC 2 reports, does not map CUECs for you, and does not maintain your responsibility register.
The same evidence problem shows up in the sovereignty and AI-rule debates. On the AI side, it is covered in the piece on the regulation deadlock.
Kenio Shirley is the founder of Keystone and runs hireken.io. CISSP, CISM. Seventeen years in enterprise technology across 50+ audits covering SOC 2, HITRUST, FedRAMP, PCI DSS, SOX and IRAP.
Prove your half of the line
Configuration state and change history, produced from your own accounts, re-runnable for any date in the audit period.