How to Audit Cloud Security: A Control-by-Control Program

Cloud risk has been written about at length, on this site and everywhere else, and most organizations have accepted the theory: the provider secures the cloud, the customer secures what it puts in the cloud, and the boundary between the two moves with the service model. What most audit functions still lack is a program that tests the customer’s half control by control, across every account and subscription, with evidence a skeptical reader would accept. This guide is that program, written to be provider-agnostic. It sets out the shared-responsibility test map, the criteria to test against, the six control layers (identity, network, data, workload, posture management and logging), the exit-strategy question that gets asked last and matters most in a crisis, a fourteen-test program, a controls checklist and a worked example at a bank’s hyperscaler estate.

In this guide

The shared-responsibility test map
Criteria: which framework to test against
First step: the account inventory nobody has
The governance layer: who owns the controls
Layer 1: identity and access
Layer 2: network and exposure
Layer 3: data protection and keys
Layer 4: workload isolation and secrets
Layer 5: misconfiguration scanning and posture management
Layer 6: logging coverage and detection
SaaS: the half of the estate this program forgets
Exit strategy and concentration
The test program
The cloud security controls checklist
Worked example: Lakeshore Bancorp’s hyperscaler estate
Common mistakes
Related guides

The shared-responsibility test map

Every cloud provider publishes a shared-responsibility model, and every audit should begin by turning it into a test map: for each layer of the stack, who is responsible under the service model in use, what evidence the provider supplies for its half, and what the customer has to evidence for its own. The provider’s half is tested through its assurance reports, its SOC 2 Type 2 report above all, read as the SOC 2 review guide describes, with the complementary user entity controls mapped to the customer’s obligations; its certifications under ISO/IEC 27001 with the cloud-specific controls of ISO/IEC 27017 and, for personal data, ISO/IEC 27018; and, for public-sector work in the United States, its FedRAMP authorization. The customer’s half is everything else, and the table shows how it shifts.

Layer	IaaS	PaaS	SaaS	Customer evidence to test
Physical, hardware, hypervisor, provider network	Provider	Provider	Provider	Provider’s SOC 2 and ISO reports reviewed; exceptions and CUECs tracked
Operating system, patching, middleware, runtime	Customer	Provider (runtime) / customer (configuration)	Provider	Patch compliance for IaaS; runtime version and configuration for PaaS
Network configuration (segmentation, security groups, exposure)	Customer	Customer (service endpoints, firewall rules)	Provider, with customer settings (IP allow-lists, private connectivity)	Configuration exports; exposure scans; private endpoint usage
Identity and access to the cloud control plane and services	Customer	Customer	Customer	Tenant and account admin inventory; federation and MFA; role assignments; service identities
Data classification, encryption configuration, key management	Customer	Customer	Customer (settings) / provider (mechanism)	Encryption settings; key ownership and rotation; storage exposure; backup and residency
Application code and configuration	Customer	Customer	Customer (configuration only)	Pipeline controls; configuration baselines; secrets management
Logging and monitoring of the customer’s use	Customer (enable, retain, monitor)	Customer	Customer (enable and consume the provider’s logs)	Control-plane logs enabled everywhere; retention; central monitoring; alerting
Exit and portability	Customer	Customer	Customer	Export capability tested; contractual terms; concentration analysis

The map’s practical value is that it stops two arguments in advance: the one where the cloud team says the provider is responsible for something the provider’s own report says is the customer’s, and the one where the auditor asks for evidence of a control that sits on the provider’s side and can only be evidenced by the provider’s report. The cloud computing risk guide covers the risk theory and the governance layer; this program assumes them and tests the controls.

Criteria: which framework to test against

Three families of criteria serve the program, and the audit chooses by what the organization already uses. Provider-agnostic control frameworks: the Cloud Security Alliance’s Cloud Controls Matrix version 4, with 197 control objectives across 17 domains, which is the most widely used cloud-specific control set and the basis of the CSA STAR assurance program that many providers publish against; ISO/IEC 27017:2015, which adds cloud-specific guidance to the ISO/IEC 27002 controls for both providers and customers; and NIST SP 800-210 (July 2020) on access control for cloud systems, alongside the general catalogs of NIST SP 800-53 Rev. 5 and the outcomes of CSF 2.0. Provider-specific configuration benchmarks: the CIS Foundations Benchmarks for each major provider, which state configuration requirements at the level of a specific setting and are what posture-management tools test against; the current CIS Amazon Web Services Foundations Benchmark is version 5.0.0, with 63 recommendations across identity and access management, storage, logging, monitoring and networking, and the AWS audit program on this site uses it. And regulatory expectations: the EU’s DORA for financial entities, with its Article 30 contract terms, exit strategies and register of information described in the DORA guide; the European Banking Authority’s outsourcing guidelines; and, in the United States, the banking agencies’ third-party risk management guidance. The program below is organized by control layer rather than by framework, and each test names the criteria it draws on so the mapping to whichever framework the organization has adopted is mechanical.

First step: the account inventory nobody has

Every cloud control operates within an account, a subscription, a project or a tenant, and a control that is configured in the twelve accounts the cloud team knows about is absent in the seven that a business unit created with a corporate card in 2022. The audit’s first substantive test is therefore the inventory of cloud accounts across all providers, built from the providers’ organization structures (the AWS Organization, the Azure management group hierarchy, the GCP organization) and reconciled to three independent sources: accounts payable and corporate card spend for cloud vendors, the identity provider’s federation and single sign-on application list, and the network’s known egress and peering connections. Accounts found outside the organization structure are the first finding, because none of the organization-level guardrails, logging or posture scanning applies to them. The inventory then classifies each account by environment (production, non-production, sandbox), by the data and services it holds, and by owner, and every subsequent test runs against the full inventory rather than the cloud team’s list. The IT audit plan guide covers where cloud accounts sit in the IT universe; the point here is that the universe entry is the population for this engagement.

Two scoping decisions belong in the planning memo. The first is provider coverage: an organization with a primary hyperscaler, a secondary one for specific workloads and a dozen SaaS platforms holding regulated data has three engagements’ worth of scope, and the memo says which providers this engagement covers and which the cycle covers later, with the SaaS platforms holding regulated data never falling off the list. The second is depth by account class: production accounts holding regulated or financial data at full depth across all six layers, other production accounts at full depth on identity, exposure, posture and logging, and sandboxes at inventory, identity and exposure only, on the argument that a sandbox’s risk is the data someone copied into it, which the exposure and data scans find. The IT audit plan guide shows how the classes map to the universe scoring that sets the cycle.

The governance layer: who owns the controls

Before the six technical layers, the audit establishes who owns them, because cloud controls fail organizationally before they fail technically. In a mature estate a platform team (sometimes a cloud center of excellence) owns the landing zone, the organization structure, the guardrails, the logging configuration and the posture tool, and publishes standards that workload teams must meet; the workload teams own what runs inside their accounts; security owns the detections and the response; and a governance forum decides exceptions and accepts risks. The audit tests that this division exists and is written down, because the alternative, in which the platform team is also the only workload team that follows its own standards, is the arrangement that produced the orphan accounts in the worked example. It tests that the standards exist per provider and are current with the providers’ own changes, which arrive monthly; that the platform team has the authority to enforce (a team that can only recommend is not a control owner); that new accounts are created only through the platform team’s process, with the inventory updated as a by-product; and that the exception process records who accepted what, for how long, and whether the exceptions have expired. Financial operations data, the cloud bills by account and service, is a discovery source the audit should always request, because the finance team sees every account that is being paid for, including the ones the platform team does not know exist.

Layer 1: identity and access

Identity is the perimeter in the cloud, and the control-plane identities, the ones that can create, change and delete the environment itself, are the crown jewels. The audit inventories every identity with administrative rights at the organization, tenant, account and subscription levels, human and non-human, and tests six things. Federation: human access comes through the corporate identity provider with single sign-on, so that leavers lose cloud access when they lose corporate access, and native cloud user accounts with passwords are exceptions with owners and expiry. MFA: enforced for every human identity, phishing-resistant for administrators, and the root or global administrator accounts protected with hardware factors and stored break-glass procedures, which the Active Directory and Entra ID guide covers for Microsoft tenants and the AWS program covers for AWS. Least privilege: role assignments reviewed against job function, with standing administrative rights replaced by just-in-time elevation and permission boundaries or organization-level policies limiting what even administrators can do. Non-human identities: service principals, roles assumed by workloads and pipeline identities inventoried with owners, scoped permissions, short-lived credentials and no long-lived access keys, per the SDLC and DevOps pipeline guide. Access reviews: performed on the cloud identities as on any other system, per the user access review guide. And the privileged pattern generally, which the privileged access guide sets out and which applies unchanged.

Layer 2: network and exposure

The cloud network is software, which means it is both easier to segment well and easier to expose by accident. The audit starts from the landing zone design: the hub-and-spoke or equivalent structure that separates production from non-production, workloads from each other and the organization from the internet, with the design compared to what the configuration exports show. It then tests exposure directly: every resource with a public IP address, every storage container with public access, every security group or firewall rule permitting inbound traffic from any address, every management port (SSH, RDP, database ports) reachable from the internet, reconciled to a list of intended exposures with owners. It tests egress, because data leaves through outbound rules nobody wrote down, and private connectivity, because services that can be reached through private endpoints should not also be reachable through public ones. And it tests change control over network configuration, which in a well-run estate is infrastructure as code reviewed like any other change, with drift between the code and the running configuration detected and reconciled.

Layer 3: data protection and keys

Data protection in the cloud has four questions: where is the data, is it encrypted, who holds the keys, and can it be recovered. Where: the data classification and inventory, mapped to storage services, regions and accounts, with residency constraints (regulatory, contractual, privacy) compared to actual locations, as the data privacy audit guide requires for personal data. Encrypted: at rest by default across storage, database and backup services, and in transit with current protocols, evidenced from configuration rather than policy. Keys: the organization’s choice between provider-managed and customer-managed keys made deliberately for each data class, customer-managed keys for the sensitive classes held in the provider’s key management service with rotation enabled, access to key usage and administration separated, and deletion protected. Recovered: backups configured across accounts or regions so that a compromise of the production account cannot destroy them, with the immutability and restore demonstrations the backup and recovery guide and the cyber resilience guide require. The finding this layer produces most often is a storage container with public access holding data nobody classified, and the test for it is a scan of every storage resource in every account, not a review of the policy.

Layer 4: workload isolation and secrets

Accounts and subscriptions are the cloud’s blast-radius boundary, and the audit tests that the boundary is used: production and non-production in separate accounts, sensitive workloads in their own, and no shared credentials or trust relationships that let a compromise in one reach another. Within an account, it tests the workload controls that the shared-responsibility map assigns to the customer: instance metadata protected against credential theft, container images scanned before deployment and pulled from a controlled registry, serverless functions with scoped roles, and, above all, secrets held in a secrets manager or key vault with access scoped and rotation enabled rather than in environment variables, configuration files or repositories. The pipeline guide covers the secrets scanning of repository history that finds the credentials committed years ago; this layer covers where secrets should live and who can read them at runtime.

Layer 5: misconfiguration scanning and posture management

Misconfiguration is the cloud’s dominant failure mode, and cloud security posture management is the control that finds it continuously: a tool, the provider’s own or a third party’s, that evaluates every account against a benchmark, usually a CIS Foundations Benchmark plus the organization’s own rules, and reports findings by severity. The audit tests four properties. Coverage: the tool is connected to every account in the inventory, including the ones found outside the organization structure, and evaluates all regions. Standard: the benchmark version is current and the organization’s exceptions to it are documented and approved. Response: findings have severity-based SLAs, the aging of open findings is measured and reported, and the trend is used; a posture tool that has reported the same 400 high findings for a year is a metric, not a control. And prevention: the highest-value configurations are enforced by policy at the organization level (service control policies, Azure Policy, organization policy constraints) so that they cannot be misconfigured in the first place, and the audit tests those policies by inspection and by a test of one, as the automated controls testing guide describes. Infrastructure-as-code scanning in the pipeline moves the same checks before deployment, and the audit tests that the two sets of rules agree.

Layer 6: logging coverage and detection

Every action on the cloud control plane is logged by the provider if the customer turns the logging on, keeps it, and looks at it, and the audit tests the three verbs. On: control-plane audit logging enabled for every account and region, configured at the organization level so that a new account inherits it, with log integrity validation and the log store protected from the accounts it records. Kept: retention that meets regulatory and investigative needs, in a central store outside the accounts’ administrators’ reach. Looked at: the logs feed a monitoring platform where detections exist for the events that matter, root or global administrator use, policy changes, logging disablement, public exposure changes, unusual API activity, key deletion, and someone triages the alerts within a stated time. Data-plane logging, for access to sensitive storage and databases, is tested for the sensitive data classes. The incident response audit guide covers the detection-to-response chain the logs feed, and the reconciliation of connected log sources to the account inventory is the completeness test that most cloud monitoring fails.

SaaS: the half of the estate this program forgets

The six layers above are written for infrastructure and platform services, and most organizations run more business on SaaS than on either. The shared-responsibility map assigns the customer four things in SaaS, and the audit tests them per application for the applications that matter, which are the ones holding regulated data, financial reporting data or the organization’s operations. Tenant identity: single sign-on enforced with no local passwords, administrator roles inventoried and minimal, MFA at the identity provider, and the application’s own privileged roles reviewed like any other; the user access review guide applies unchanged. Tenant configuration: the security settings the provider leaves to the customer, external sharing, data export, API access, retention, session controls, compared to a baseline the organization has written and to the provider’s own security recommendations. Integrations: the OAuth grants and API tokens through which third-party applications read the tenant’s data, inventoried and reviewed, because a marketing tool granted read access to the whole mailbox in 2023 is still reading it. And logs: the provider’s audit log enabled, exported to the organization’s monitoring platform before it ages out of the provider’s retention window, and watched for the events that matter. Shadow SaaS, the applications adopted without the platform or security teams’ knowledge, is found the same way orphan accounts are, through spend, through the identity provider’s application list and through network egress, and the end-user computing guide covers the low-code and automation tools that sit at the boundary between SaaS and spreadsheets.

Exit strategy and concentration

Exit is the question asked last and the one a regulator or a crisis asks first. The audit tests whether the organization could leave the provider, or survive the provider’s failure, on a timeline it could tolerate: whether the data can be exported in a usable format and has been, at least in a test; whether the architecture depends on proprietary services that have no equivalent elsewhere, and whether that dependency was a decision; whether the contract provides the termination rights, transition assistance, data return and deletion terms that DORA’s Article 30 makes mandatory for financial entities and that any organization should want; and whether a concentration analysis exists that recognizes the hyperscaler as the organization’s largest single dependency, with the board having accepted that risk knowingly. An exit strategy that is a paragraph in the vendor risk assessment is a finding; one that has been costed, timed and partially rehearsed is a control.

The test program

#	Layer	Test	Pass condition
1	Inventory	Build the account inventory from organization structures; reconcile to AP, card spend, federation list and network connections	Every account known, owned, classified and inside the organization structure; orphans remediated
2	Provider assurance	Review each provider’s SOC 2 Type 2 and ISO 27017/27018 certificates; map CUECs to internal controls	Reports current; exceptions evaluated; CUECs operating
3	Identity: admins	Inventory organization, tenant and account administrators; test federation, MFA (phishing-resistant for admins), break-glass procedures	Administrators few and named; all federated with MFA; root or global accounts protected and unused for daily work
4	Identity: least privilege	Sample role assignments against job function; inspect JIT elevation and organization-level permission limits	Standing admin rights minimal; elevation logged; boundaries enforced
5	Identity: non-human	Inventory service identities and access keys; test ownership, scope, credential age and rotation	No unowned identities; no long-lived keys beyond policy; pipeline identities federated
6	Network	Enumerate public IPs, open management ports, permissive rules and public storage across all accounts; compare to intended exposures	All exposure intended, owned and justified; private endpoints used for internal services
7	Data	Scan storage for public access and encryption; inspect key management ownership, rotation and access separation; verify residency	No unintended public data; sensitive classes on customer-managed keys with rotation; residency as required
8	Backup and recovery	Inspect cross-account or cross-region backups, immutability and the last restore	Backups isolated from production credentials; restore demonstrated
9	Workload isolation	Inspect account separation, trust relationships, metadata protection, image scanning and registry control	Blast radius contained; no shared credentials across environments
10	Secrets	Inspect secrets manager usage, access scoping and rotation; scan configuration for embedded secrets	Secrets vaulted; no plaintext secrets in configuration or variables
11	Posture management	Confirm tool coverage against the inventory; inspect benchmark version, exceptions, SLAs and aging trend	All accounts covered; findings resolved within SLA; trend improving
12	Preventive guardrails	Inspect organization-level policies; test one per policy	Critical misconfigurations prevented, not just detected
13	Logging and detection	Confirm control-plane logging on all accounts and regions with integrity validation; reconcile log sources to inventory; test detections and triage times	Complete coverage; central protected retention; alerts triaged within SLA
14	Exit and concentration	Inspect exit strategy, export test, contract terms and concentration acceptance	Exit costed, timed and tested; terms compliant; concentration accepted by the board

The cloud security controls checklist

One checklist per provider organization, completed by the cloud platform team and used by the auditor as the test template; account-level items are answered per account from the inventory.

Cloud security controls checklist

1. Governance. Cloud accounts inventory with owners and classification; organization structure covering all accounts; landing-zone design document; cloud security policy and standards; provider assurance reports reviewed within the year with CUECs mapped.

2. Identity. Administrator inventory (organization, tenant, account); federation and SSO for all humans; MFA enforced, phishing-resistant for administrators; root or global administrator accounts secured, monitored and unused; JIT elevation; permission boundaries or organization policies; service identities inventoried with owners; no long-lived keys beyond policy; quarterly access reviews.

3. Network. Segmentation per design; intended-exposure register; no unintended public IPs, open management ports or any-source inbound rules; private endpoints for internal services; egress controls; network changes through reviewed infrastructure as code with drift detection.

4. Data. Data inventory mapped to storage and regions; encryption at rest and in transit by default; key management decisions per data class; customer-managed keys with rotation and separated administration; no public storage with data; residency verified; backups cross-account or cross-region, immutable, restore-tested.

5. Workload. Environment separation by account; no cross-environment trust; metadata service protection; image scanning and controlled registry; secrets in a vault with scoped access and rotation.

6. Posture. Posture management covering every account and region; current benchmark; documented exceptions; severity SLAs with aging reported; preventive organization-level policies for critical configurations; IaC scanning aligned with runtime rules.

7. Logging. Control-plane logging on everywhere by organization configuration; integrity validation; central protected retention; data-plane logging for sensitive stores; detections for critical events; triage SLAs measured.

8. Exit. Exit strategy costed and timed; export tested; contract terms (termination, transition, data return and deletion, audit rights); concentration analysis accepted by the board.

Worked example: Lakeshore Bancorp’s hyperscaler estate

Lakeshore Bancorp, the illustrative $9 billion regional bank used across this site, runs its core banking on a hosted platform and its own digital channels (online and mobile banking, described in the pipeline guide) on a hyperscaler, alongside a data and analytics platform and a growing set of business-unit workloads. Internal audit’s cloud security program audit was scoped at 420 hours with a co-sourced cloud specialist for 120 of them, and it began where this guide begins, with the inventory. The cloud team’s list held 48 accounts in the organization structure; the reconciliation to accounts payable, corporate cards and the federation list found 62, the 14 orphans including a marketing analytics account paying $4,000 a month by card since 2022, three data-science sandboxes holding extracts of customer data, and a treasury team’s account running a rates model. None of the 14 had organization-level logging, posture scanning or guardrails, and one of the sandboxes had a storage container with public read access on a 2.1 GB extract that the data privacy audit later evaluated as a reportable incident.

Layer	Result across the 62 accounts	Finding and rating
Inventory	48 known, 62 found; 14 outside the organization structure	High: all 14 brought under the organization or closed; card-based cloud purchasing blocked
Identity	Humans federated with MFA in the 48; native users with passwords in 9 of the 14 orphans; 210 access keys older than 90 days across the estate, 31 for identities with administrative rights; root accounts of the 48 protected with hardware MFA, root credentials present in 11 of 14 orphans; pipeline identities federated (the estate’s strongest control)	High: keys rotated or removed; orphan root credentials centralized; JIT elevation extended to the data platform
Network	19 public IPs against 12 intended; 4 database ports open to the internet in non-production; 14 public storage containers, 2 holding data	High: unintended exposure closed within fieldwork; intended-exposure register created
Data	Encryption at rest default everywhere; 6 of 9 sensitive data stores on provider-managed keys where policy required customer-managed; one key without rotation since 2021; backups in the same accounts as production for the data platform	Medium: key policy enforced; backups moved cross-account with immutability
Workload and secrets	Production and non-production separated for digital channels; the data platform mixed; 6 credentials found in configuration in the orphans (the pipeline guide’s repository findings were separate)	Medium: separation project scheduled; secrets vaulted
Posture	Tool covered 48 of 62 accounts; CIS benchmark two versions behind; 1,240 open high findings with median age 140 days and no SLA; organization policies enforced 9 critical configurations in the 48	High: coverage extended; SLA set at 30 days for high; aging reported monthly to the CISO
Logging	Organization-level control-plane logging on for the 48 with integrity validation and central retention; none for the 14; detections for root use and policy change present; median triage 40 minutes	Medium: extended to all accounts
Exit	A one-page strategy assuming re-platforming in six months; no export test; contract terms adequate; concentration not on the board’s risk register	Medium: concentration accepted by the board with the strategy re-costed at 18 months

Nine findings, four High, and one sentence in the cover note that the audit committee quoted back: every control the cloud team had built worked, and it worked in the 48 accounts the team knew about, which is why the audit’s first test was to find the other 14. The remediation was mostly organizational rather than technical: card-based cloud purchasing was blocked at the expense system, the organization structure became the only route to an account, and the posture tool’s coverage became a reported number. The re-test a year later found 71 accounts, all inside the structure, and 90 open high findings with a median age of 12 days.

Common mistakes

Auditing the accounts the cloud team lists. Reading the provider’s SOC 2 as if it covered the customer’s configuration. Testing identity in the console the cloud team uses and forgetting the orphan accounts’ native users. Accepting “encrypted at rest” as the data answer without asking who holds the keys. Treating the posture tool’s dashboard as the control rather than testing its coverage and the response to its findings. Testing detections in the monitoring platform without reconciling which accounts feed it. Auditing network segmentation from the diagram. Leaving exit strategy to the vendor risk assessment. Producing findings by cloud service rather than by control layer, so that the report reads as a product review. And staffing the engagement without anyone who can read a configuration export, which is the co-sourcing decision the co-sourcing guide covers; the ITGC primer and the SOX ITGC scoping guide cover the general-controls layer that cloud estates inherit and where the SOX-scoped cloud accounts sit.

Comments

Leave a Reply Cancel reply

Dark Towers by David Enrich: Summary and Lessons for Auditors

Blind Spots by Bazerman and Tenbrunsel: Summary and Lessons for Auditors

Black Box Thinking by Matthew Syed: Summary and Lessons for Auditors

The Field Desk Series