In the cloud, the provider secures the underlying platform and the customer secures what it puts on it. This is the shared responsibility model, and where the line falls depends on whether you use IaaS, PaaS or SaaS. A cloud security audit starts by drawing that line, then tests the customer's side: access, configuration, data, logging and the provider's own assurance reports.
Last reviewed: 17 October 2026. Facts checked. We searched for how responsibility splits across IaaS, PaaS and SaaS and for audit guidance on the model. Sources were consultancy, security-vendor and professional-body articles (including an ACCA article on auditing cloud solutions). We did not open any cloud provider's own shared responsibility documentation, so the split below is general. Each provider draws the line slightly differently, so check theirs for your service.
The three service models in plain English
- IaaS (infrastructure as a service): you rent computing power, storage and networks. Examples are virtual servers.
- PaaS (platform as a service): you rent a platform to run your own code or databases, without managing the servers underneath.
- SaaS (software as a service): you use a finished application, such as an online accounting or CRM tool.
Who is responsible for what
| Layer | IaaS | PaaS | SaaS |
|---|---|---|---|
| Physical data centre | Provider | Provider | Provider |
| Virtualisation | Provider | Provider | Provider |
| Operating system | Customer | Provider | Provider |
| Application | Customer | Customer | Provider |
| Data and who can see it | Customer | Customer | Customer |
| User accounts and access | Customer | Customer | Customer |
The pattern in the sources is consistent: the more managed the service, the more the provider carries. But data, and the decisions about who gets access to it, stay with the customer in all three. This is why a breach caused by a misconfigured storage bucket or a weak admin password is usually the customer's problem, not the provider's.
Step 1: Draw your own map
Before testing, build a one-page map.
- List every cloud service in use, including ones bought by business teams without IT.
- Mark each as IaaS, PaaS or SaaS.
- Note what data it holds and how critical it is.
- For each, write down what the provider says it is responsible for, from its own documentation.
The list is often the first finding. Teams rarely have a complete inventory of cloud services.
Step 2: Test the customer's side
| Area | What to test | Evidence |
|---|---|---|
| Identity and access | Admin accounts listed and justified; multi-factor authentication on; leavers removed; no shared admin logins | User export, MFA settings, HR leaver list |
| Configuration | Storage is not open to the public; network rules are not wide open; settings follow the baseline | Configuration screenshots or exported reports |
| Data protection | Encryption settings; who holds the keys; backups and tested restores | Settings, key management records, restore test |
| Logging and monitoring | Activity logs switched on, kept, and reviewed by someone | Log settings, review records |
| Change management | Changes to cloud settings are approved and traceable | Change tickets matched to configuration history |
| Cost and sprawl | Unused or unknown accounts and resources | Billing report compared with the service inventory |
In IaaS, sources note that the customer is responsible for creating and monitoring the logs that track use of its infrastructure. If nobody looks at the logs, you cannot detect misuse.
Step 3: Use the provider's assurance, with care
Providers publish independent reports. A SOC 2 report or an ISO 27001 certificate says something about the provider's controls. To use one:
- Confirm the report covers the service you actually use and the right period.
- Read the exceptions.
- Find the complementary user entity controls, the controls the report expects you to run. These are your responsibility.
- Remember the report does not test your configuration.
Sources are clear that provider reports help but do not replace the customer's own review.
Step 4: Contracts and exit
- Does the contract say where data is stored and who can access it?
- Are incident notification duties and timings stated?
- Is there a right to audit or to receive assurance reports?
- Can you get your data back in a usable form if you leave? Has anyone tested it?
Common findings
- No complete list of cloud services in use.
- Administrator accounts without multi-factor authentication.
- Logs switched off or never reviewed.
- Backups that were never restored as a test.
- Reliance on a provider report that excludes the service in use.
Frequently Asked Questions
Does moving to the cloud move the audit risk to the provider?
Only part of it. The provider takes the platform layers. The customer keeps responsibility for its data, its users and its settings.
Is SaaS safer to audit because the provider does more?
There is less to configure, but you still own access to the data. Audit user access, sharing settings and the provider's reports.
Can internal audit test the provider's data centre?
Usually not directly. You rely on the provider's independent reports and contract rights. Check what the contract allows.
What is the single most useful test?
Compare the list of all cloud accounts and services with the list IT knows about, then check admin access and logging on the critical ones.
Where does this fit with ITGC audit?
Cloud services still need access, change and operations controls. See our ITGC guide.
Related Articles
Statutory facts on this page are checked against their sources, and the page says where it relied on secondary reporting. How we verify · Report an error