A cloud estate is a control environment that one API call can rebuild, expose or delete, and most of it never passed through a change ticket. Forty AWS accounts, two Entra ID tenants and two hundred SaaS subscriptions is a normal footprint for an 800-employee company, and the audit plan usually carries one line for all of it. The incidents that reach the board are rarely exotic: a bucket left public, an access key that outlived the contractor who created it, a security group opened “temporarily” in 2023, a backup nobody ever restored. Each is a customer-side failure the provider’s SOC 2 report will never mention. A cloud audit tests the shared responsibility line and everything on your side of it, with evidence pulled from the platform rather than a policy binder.
This guide gives you five artifacts: a shared-responsibility matrix by IaaS, PaaS and SaaS with the assurance source for each layer; an eight-domain work program; a 20-check misconfiguration catalog with an exception condition for every check; a SOC 2 Type II reading checklist; and a worked AWS review with populations, hours and two findings. It was rewritten in September 2026 to reflect the Global Internal Audit Standards, the IIA’s Cybersecurity Topical Requirement (effective 5 February 2026) and Third-Party Topical Requirement (effective 15 September 2026), the July 2026 edition of ISO/IEC 27017, and current provider tooling. It sits alongside the site’s guides to auditing cybersecurity programs and IAM audits.
In this guide
- What a cloud audit covers, and the criteria to audit against
- Shared responsibility done properly: who tests what
- The cloud audit work program: eight domains
- Misconfiguration test catalog: 20 checks
- Getting evidence from consoles and APIs
- Reading a SOC 2 Type II report
- Worked example: Tallgrass Freight Software’s AWS review
- Common failures in cloud audits
- Adapting the program
What a cloud audit covers, and the criteria to audit against
NIST SP 800-145 defined cloud computing in 2011 by five characteristics, and three of them change the audit. On-demand self-service means anyone holding a role can create infrastructure without a ticket, so provisioning control lives in identity. Measured service means consumption is billed by the second, so cost is a control domain. Resource pooling means you inherit physical, hypervisor and network controls you will never test directly and must obtain assurance over another way.
“Cloud audit” is three engagements wearing one name. A platform review covers the accounts, subscriptions or projects and the guardrails around them: organization structure, federation, logging, region restrictions, cost governance. A workload review takes one application on the platform and tests its architecture, configuration and resilience against those guardrails. A SaaS tenant review tests one vendor’s product as configured for you: administrator roles, sharing settings, integrations, log retention, data export. Pick one shape per engagement and write it into the objective; the planning memo template has a scope table built for that decision.
Standard 13.4 of the Global Internal Audit Standards requires evaluation criteria for every engagement. Two are mandatory for IIA-conformant functions: the Cybersecurity Topical Requirement applies whenever cybersecurity is in scope, which is every platform and workload review, and the Third-Party Topical Requirement applies when the engagement covers oversight of the provider relationship; the site’s overview of the IIA Topical Requirements explains how conformance is evidenced, and the Domain V guide covers the engagement standards. The rest of the criteria set, as of September 2026: the CSA Cloud Controls Matrix v4.1 (17 domains, 207 controls; CAIQ v4.1 has 283 questions); ISO/IEC 27017:2026 (published July 2026, replacing the 2015 edition) and ISO/IEC 27018:2025 for cloud-service and PII-processor controls; NIST SP 800-144, SP 800-210 and CSF 2.0 for regulated-entity language and committee presentation by function; the CIS Foundations Benchmarks for AWS, Azure and Google Cloud as the source of configuration checks, with the version pinned in the workpaper because they move roughly annually; the FinOps Framework and the FOCUS 1.3 billing specification for domain 7; and the AICPA 2017 Trust Services Criteria with the 2022 revised points of focus.
Shared responsibility done properly: who tests what
AWS calls it security “of” the cloud versus security “in” the cloud; Microsoft draws a stacked diagram by service model; Google says “shared fate.” All three summarize a contract; three facts decide whether your audit is worth anything. The line moves with the service, not the provider: a database on a self-managed EC2 instance and the same database on Amazon RDS sit in one account under two different splits. The cells marked “shared” are where failures live, because each party assumes the other has it; logging and backup are the classic cases. And the provider’s side is not unauditable: its service auditor tests it, the results are in a SOC 2 Type II report, and that report lists complementary user entity controls that are yours.
“Provider” cells are covered by reading the provider’s reports, “Customer” cells are tested directly against platform evidence, and “Shared” cells need both. The backup row is where SaaS contracts surprise people: many vendors exclude recovery of data the customer deleted, so tenant backup is a control nobody owns until an audit asks.
| Layer | IaaS (EC2, Azure VMs, Compute Engine) | PaaS (RDS, Azure SQL, managed Kubernetes) | SaaS (Microsoft 365, Salesforce, Workday) | Assurance source and who tests |
|---|---|---|---|---|
| Facilities, hardware, hypervisor, provider network and edge | Provider | Provider | Provider | Provider SOC 2 Type II and ISO/IEC 27001 certificate; you read, you do not test; confirm your services and regions are in scope |
| Managed service software (database engine, queue, the SaaS application code) | Customer (you run the OS and runtime) | Provider, with customer choices (engine version, maintenance window, auto-upgrade) | Provider | Provider SOC 2; you test version and upgrade choices against policy |
| Guest operating system: patching and hardening | Customer | Provider, except customer-managed node pools | Provider | Customer: vulnerability scans, patch SLA, IMDSv2 enforcement |
| Network configuration: VPCs, security groups, firewall rules, private endpoints, allowlists | Customer | Shared: provider runs the service network, customer configures exposure | Shared, limited to IP allowlists and conditional access | Customer: full-population export of rules and endpoints; provider report for the service side |
| Identity: accounts, roles, MFA, federation, keys | Customer | Customer | Customer | Customer, every time; the provider’s report covers only that its IAM service works as described |
| Application code and tenant configuration | Customer | Customer | Shared: vendor code, customer settings (admin roles, sharing, integrations, API tokens) | Customer: change management, configuration baseline, admin-setting review; vendor SOC 2 for the code |
| Data: classification, encryption keys, residency, retention, deletion | Customer | Customer | Customer | Customer; the provider report covers the encryption implementation, not whether you enabled it or chose the region |
| Logging and monitoring | Shared: provider generates control-plane logs; customer enables, retains, monitors | Shared | Shared: retention depends on license tier | Both: provider report for log integrity; customer test of enablement, retention and alerting |
| Backup and recovery of customer data | Customer | Shared: automated backups exist; retention and restore testing are yours | Shared: platform DR is the vendor’s; recovery from your own deletions is usually yours | Customer: restore evidence; contract terms for SaaS data recovery |
| Endpoints, cost, regulatory obligations (controller duties, breach notification, DPAs) | Customer | Customer | Customer | Customer; the provider acts as processor under the data processing agreement |
Write the split into the planning memo in language like this:
Responsibility split. The engagement tests controls operated by the company over its AWS Organization (38 accounts) and its Microsoft 365 tenant. Controls operated by Amazon Web Services and Microsoft over facilities, hardware, hypervisors, provider networks and managed-service software are outside direct testing; assurance over those layers is obtained by reading the providers’ current SOC 2 Type II reports and ISO/IEC 27001 certificates, evaluating their complementary user entity controls, and confirming that the services and regions used are within scope.
Shared layers. Logging, network exposure of managed services and backup of customer data are shared. For each, the engagement tests the customer-side configuration directly and records the provider-side control from the report, so that no layer is assumed to be covered by the other party.
The cloud audit work program: eight domains
The program is built for a platform review of one provider organization and adapts to the other shapes by dropping rows. Run domains 1, 2 and 5 first: inventory, identity and logging determine whether the remaining evidence is complete. The mechanics are in the site’s audit work program guide; the free RCM Workbench turns these objectives and tests into a risk and control matrix.
| Domain | Objective | Key tests | Evidence |
|---|---|---|---|
| 1. Governance and inventory | Every account, subscription, project and tenant is known, owned, funded and inside enforced guardrails | Reconcile the organization’s account list to the CMDB and to billing; spend with no owner is shadow IT. Read the service control policies or organization policy constraints for region denial, root restrictions and required logging. | Account export, billing list, SCP or org-policy JSON |
| 2. Identity and access | Human access is federated, MFA-protected, least-privilege and reviewed; machine identities are short-lived; privileged access is sealed | Pull the full credential population and test MFA, key age, unused credentials and local users against the federation policy. Compare role assignments to the approved role matrix. Test the last user access review, the break-glass accounts and the external trusts, and apply the privileged access audit steps to organization-level administrators. | Credential report, Identity Center or PIM exports, Access Analyzer results, UAR workpapers |
| 3. Configuration and network | Resources are built to a hardened baseline, exposure is intentional, drift is detected and corrected | Run catalog checks 9 to 13, 18 and 19 against the full population. Measure infrastructure-as-code coverage of production and read the drift results. Confirm a CSPM standard is enabled in every account and read the score trend, disabled controls and exception register. | CSPM exports, Config compliance, IaC state inventory, exception register |
| 4. Data protection and residency | Confidential data is classified, encrypted under managed keys, located only in approved regions and retained per policy | Reconcile classification tags to discovery results (Macie, Purview, Sensitive Data Protection). Test encryption defaults and every store tagged confidential; read customer-managed key policies and rotation. Test the region guardrail and list every resource outside approved regions, including replication and backup targets. | Tag inventory, discovery reports, key inventory, region policy |
| 5. Logging, monitoring and response | Control-plane and data-plane events are captured, retained immutably, monitored and acted on | Run catalog checks 14 to 17. Test that alerts fire for root use, IAM policy changes, security group changes and trail disablement. Compare the SIEM source list to the account list. Trace 10 cloud-originated alerts to tickets and closure within SLA. | Trail settings, retention, SIEM source list, alert export, tickets |
| 6. Resilience and backup | Production workloads meet recovery objectives; backups are complete, immutable and proven restorable | Compare each tier-1 workload’s architecture (single zone, multi-zone, multi-region) to its RTO and RPO. Reconcile backup coverage to the tagged production population and test vault immutability. Compare the last restore test and DR exercise to objectives. | Backup coverage, restore job logs, DR report, architecture diagrams |
| 7. Cost governance (FinOps) | Spend is visible by owner, bounded by budgets and alerts, reviewed on a cadence and protected against anomalies | Measure tag coverage by spend. Confirm every account has a budget with live alert recipients and that anomaly detection is enabled with 90 days of dispositions. Read commitment coverage and utilization. Trace the monthly cost review as a management review control. | Cost exports, FOCUS billing export, budgets, anomaly history, review minutes |
| 8. Vendor assurance and contracts | Reliance rests on current independent reports whose user-entity controls are implemented; contracts carry required terms | Apply the SOC 2 reading checklist and obtain bridge letters for gaps. Map every complementary user entity control to an owner and a test in domains 2 to 6. Test contract terms: data location, breach notification window, exit and data return, subprocessor notice, audit rights. | SOC 2 reports, bridge letters, CUEC mapping, certificate scopes, contracts |
Identity in the cloud: roles, keys, MFA and federation
Domain 2 carries the most findings because cloud identity has three populations where on-premises access has one. Humans should reach the console through a federated identity provider, so the count of local console users should be near zero and each one needs a documented reason. Machine identities (workload roles, service accounts, pipeline credentials) outnumber humans ten to one and are the ones that leak. Organization-level administrators can undo every other control, so their count, MFA method and activity are tested individually, never sampled; Microsoft’s own guidance is fewer than five Global Administrators, and a tenant with 14 is a finding before you look at anything else.
Long-lived access keys are the specific failure to hunt. A key created for a script in 2022 does not expire, is not covered by MFA, and is often pasted into a build pipeline where it survives its creator’s departure. Generate the credential report, filter to active keys, compute age from the last rotation date and days since last use, and compare both to policy. The fix is structural: workloads on roles, pipelines on short-lived federated credentials (GitHub Actions can assume a cloud role through OpenID Connect with no stored secret), and a rule that disables aged keys. The segregation of duties guide covers the conflict when one role can deploy code and approve its own change.
Data protection and residency
Residency is a configuration fact, not a contractual one. The data processing agreement may name Frankfurt, but the auditable evidence is the region guardrail (an AWS service control policy denying non-approved regions, or Google’s resource-locations organization policy), the region attribute on every store holding regulated data, and the replication and backup targets, which are where EU data quietly ends up in Virginia. The AWS European Sovereign Cloud launched in January 2026 as a separate partition, and if management cites it, confirm the workload actually runs there. Encryption at rest is now mostly on by default, so the test is “who controls the key,” and discovery tools change the population: if Macie or Purview reports 31 buckets containing personal data and classification tags cover 19, the untagged 12 are your finding.
Cost governance as an audit area
Cost is an audit domain because measured service turns every engineer into a spender with no purchase order, and the failure modes are control failures, not negotiation failures. Look for spend without an owner: accounts with no budget, resources with no cost-center tag, commitments bought against a workload later decommissioned. Measure tag coverage by dollars, not resource count; the 60 largest resources typically carry half the bill. The monthly cost review is a management review control: what threshold triggers investigation, who investigates, and where is the evidence that anything changed.
Misconfiguration test catalog: 20 checks
The 20 checks below cover the configurations behind most publicly reported cloud incidents of recent years, with where to look on the three major platforms and the exception condition that turns an observation into a finding. Run every check against the full population; it exports in seconds, so sampling it is a choice to know less than you could. Thresholds such as 90 days for key age are CIS and common-policy defaults; substitute the company’s policy where stricter.
| # | Check | Where to look (AWS · Azure · Google Cloud) | Exception condition |
|---|---|---|---|
| 1 | Root and organization-admin protection | Root MFA flag in IAM account summary; centralized root access · Global Administrators and auth methods · organization admin bindings | Any root or organization admin without phishing-resistant MFA; more than five Global Administrators; member accounts still holding root credentials |
| 2 | Root and superuser activity | CloudTrail Root events · Global Administrator sign-ins · Cloud Audit Logs for organization admins | Any root use without a documented root-only task and ticket |
| 3 | Human users without MFA | Credential report: password on, MFA off · Conditional Access coverage and MFA registration report · 2-step verification enforcement | Any console-capable human without MFA; any Conditional Access exclusion without an expiry |
| 4 | Access key and secret age and use | Credential report: key last rotated, last used · app registration secret expiry · service account key dates | Active key older than 90 days or unused for 45; any key of an identity not on the HR roster |
| 5 | Local users where federation is mandated | IAM users with passwords versus Identity Center users · cloud-only Entra admins · non-federated Google accounts with roles | Any human local account outside the break-glass list |
| 6 | Wildcard administrative policies | All-actions-on-all-resources policies and attachments · Owner and Contributor at subscription scope · Owner and Editor at organization level | Any full administrator not on the approved list; any wildcard policy on a workload role |
| 7 | External and cross-account trust | Access Analyzer external findings; trust policies naming other accounts or any principal · guest users with roles · bindings to external domains or allUsers | Any external trust without owner, reason and expiry; any role trusting any principal |
| 8 | Unused roles and over-provisioned permissions | Access Analyzer unused access; role last-used data · access reviews; PIM eligible assignments never activated · IAM recommender insights | Role or permission unused 90 days with no review and no break-glass tag |
| 9 | Public object storage | Account and bucket Block Public Access; bucket policy status · anonymous blob access setting · allUsers bindings; public access prevention | Account-level block off; any public bucket not on the approved list; prevention not enforced at organization level |
| 10 | Encryption at rest and key management | EBS default encryption; RDS encryption; KMS rotation and key policies · disk and storage encryption; Key Vault purge protection · CMEK where mandated | Any confidential store unencrypted; customer-managed key with rotation off; key policy allowing any principal |
| 11 | Administrative ports open to the internet | Security groups open to 0.0.0.0/0 or ::/0 on 22, 3389 and database ports, joined to running instances · NSG rules with Any source · VPC firewall rules from 0.0.0.0/0 | Any internet-open management or database port attached to a running resource |
| 12 | Publicly reachable databases | RDS publicly accessible flag; public subnet groups · public network access on Azure SQL and PostgreSQL · Cloud SQL public IP with open authorized networks | Any production database reachable from the internet |
| 13 | Region guardrails | SCP denying non-approved regions; resources by region · allowed-locations policy · resource locations constraint | No enforced guardrail; regulated data outside approved regions, including backup and replication targets |
| 14 | Control-plane audit logging coverage | Organization trail: multi-region, log validation, data events for confidential buckets · Activity Log diagnostic settings per subscription · Data Access logs for regulated services | Any account without control-plane logging; any confidential store without data-plane logging; validation off |
| 15 | Log retention and immutability | Log bucket retention, Object Lock and policy; log group retention · Log Analytics retention; immutability policy · log bucket retention and lock | Retention below policy (commonly 365 days); log store deletable by non-logging principals; console history treated as the archive |
| 16 | Network flow logging | VPC flow logs per production VPC · NSG or virtual network flow logs · flow logs per production subnet | Any production network without flow logs or with retention under 90 days |
| 17 | Threat detection coverage and finding age | GuardDuty per account and region; Security Hub CSPM standards · Defender for Cloud plans · Security Command Center coverage | Any production account or region uncovered; High or Critical finding open beyond SLA (30 days if none is defined) |
| 18 | Compute hardening | IMDSv2 required; public IPs; Systems Manager patch compliance · VM public IPs; Update Manager compliance · OS Login; public IPs; patch compliance | Legacy metadata service allowed in production; internet-facing instance without a reason; critical vulnerability open beyond 30 days |
| 19 | Secrets exposure | Plaintext credentials in Lambda variables, user data and plain-string parameters · secrets in app settings rather than Key Vault · secrets in environment variables rather than Secret Manager; repository scanning | Any plaintext credential in configuration or code; secret-scanning alert open beyond seven days |
| 20 | Backup coverage and restore proof | AWS Backup coverage versus tagged production; vault lock; last successful restore · Backup center coverage; immutable vaults · backup plans on Cloud SQL and disks | Any tier-1 store without a backup plan; no immutable copy; no successful restore test in 12 months |
Every check produces a number, and the numbers are what the report needs: “26 of 1,873 security groups allow internet access to port 22, 11 are attached to running instances, and 4 of those are in production” is a finding with a defensible severity. Keep the raw exports, the filter logic and the counts in the workpaper so a reviewer can re-perform the check. CSPM tools will run most of these checks, and relying on them is sound if you test which accounts the tool covers, which controls are enabled, and which controls management suppressed; the IPE testing guide covers that step, and the audit evidence guide covers why an export you generated outranks a screenshot management sent you.
Getting evidence from consoles and APIs
Ask for a read-only audit role before fieldwork starts, not for screenshots during it: on AWS, a role in every in-scope account carrying the managed SecurityAudit and ViewOnlyAccess policies, assumed through the identity provider with MFA; on Azure, Reader plus Security Reader at management-group scope; on Google Cloud, Viewer plus Security Reviewer at the organization node. Where management will not grant access, the fallback is a screen-shared session in which the engineer runs your commands while you capture the output, labeled as inquiry plus observation.
Prefer API and CLI exports to console screenshots; an export carries the whole population and can be re-performed, while a screenshot shows the first page of a paginated list. The exports that generate most findings are few: the IAM credential report per account; the account summary for the root MFA flag; the public access block and bucket policy status; the security group export joined to network interface attachments, because unattached open rules are hygiene and attached ones are the finding; the trail configuration and log bucket lock; the CSPM findings export; the restore job history; and the FOCUS-format billing export, reconciled to the invoice. For every file, capture account, region, timestamp, the identity that ran the query, the exact command or console path, and a hash.
Infrastructure as code changes the change population. Where production is deployed from Terraform or CloudFormation through a pipeline, merged pull requests are the population, the pipeline’s approval gate is the control, and the drift report (resources that differ from the code) is the population of unauthorized changes. Select from merged pull requests, test for review by someone other than the author and a passing security scan, then test the drift report. The sample size guide and the free mySampler tool cover selection for the tickets and pull requests you still sample; document walkthroughs on the site’s walkthrough template.
Reading a SOC 2 Type II report
A SOC 2 Type II report is an AICPA attestation examination (AT-C section 205) in which a service auditor opines on the description of the provider’s system and on the design and operating effectiveness of its controls over a period, against the Trust Services Criteria. As of September 2026 the criteria remain the 2017 TSC with the 2022 revised points of focus; the AICPA has exposed revisions to the attestation standards with a proposed 2029 effective date. A Type I report covers design at a point in time and supports almost no reliance. A SOC 1 report covers controls over financial reporting and is what your external auditor wants for the ITGC reliance in the site’s SOX ITGC scoping guide; neither substitutes for the other.
The providers publish reports under nondisclosure through AWS Artifact, the Microsoft Service Trust Portal and Google Cloud’s Compliance Reports Manager; download the report yourself and record the version and date.
| Section | What to check | Red flag | Record in the workpaper |
|---|---|---|---|
| Section 1: Service auditor’s report | Firm; opinion type; period; categories in scope (Security is mandatory; Availability, Confidentiality, Processing Integrity and Privacy are optional); carve-out or inclusive method | Qualified opinion; period under six months; Availability or Confidentiality missing when your reliance needs them | Firm, opinion, period, categories, report date |
| Section 2: Management’s assertion | Matches the opinion’s scope and period; signed by an officer | Assertion narrower than the claims made in sales material | Any difference between assertion and opinion |
| Section 3: System boundaries | In-scope services, regions and products; changes during the period; incidents disclosed | A service or region you rely on is absent; a preview service you run in production is excluded | Your services mapped to the report’s list, gaps flagged |
| Section 3: Subservice organizations | Carved-out functions (colocation, network, identity) and the subservice controls relied on | Carved-out functions the provider does not visibly monitor | Whether you need the subservice organization’s own report |
| Section 3: Complementary user entity controls | Every control the provider assumes you operate: MFA, key management, configuration, logging, access reviews, incident notification | CUECs never mapped to an owner; CUECs describing controls the company does not have | Each CUEC mapped to an owner and a work program test |
| Section 4: Controls, tests and results | Exceptions and deviations, their nature and management’s response; inquiry-only tests; sample sizes | Exceptions in access removal, change management or logging; repeated exceptions across consecutive reports; a control tested by inquiry alone | Exceptions relevant to your reliance and how they change your testing |
| Section 5: Other information | Management’s responses, roadmap statements, certifications listed | Any reliance placed on this section; it is unaudited | Note that nothing here supports reliance |
| Period coverage and bridge letter | Gap between the report period end and your period end; bridge letter stating no material changes | Gap over three months with no bridge letter; a bridge letter that discloses changes | Gap in days, bridge letter date, reliance conclusion |
| Mapping to your risks | Which of your risks are addressed by which provider controls, and which by nothing in the report | Risks with no provider control and no customer control: the shared-cell failure | The mapping table and the residual list |
Two other sources carry assurance, with limits. An ISO/IEC 27001:2022 certificate proves a management system was certified, not that specific controls operated; read the scope statement and ask for the Statement of Applicability. ISO/IEC 27017 or 27018 certification adds cloud-specific and PII-processor coverage and matters most for SaaS vendors without a SOC 2. CSA STAR Level 1 is a self-assessment against the CAIQ, useless for reliance; Level 2 is a third-party certification or attestation against the Cloud Controls Matrix and supports reliance the way a SOC 2 does. Record the conclusion in language that separates reliance from confirmation:
Reliance conclusion. We obtained the provider’s SOC 2 Type II report for the period 1 October 2025 to 31 March 2026 (unqualified opinion; Security, Availability and Confidentiality) and a bridge letter dated 15 May 2026 covering the period to 30 April 2026. All 23 services and three regions the company uses appear in the in-scope list. Section 4 reports two exceptions, both in the provider’s employee access removal control; neither affects customer-side controls. Of 17 complementary user entity controls, 14 map to controls tested in this engagement; three (customer notification of compromised credentials, customer key rotation, customer log retention) had no assigned owner and are reported as an observation.
Worked example: Tallgrass Freight Software’s AWS review
Tallgrass Freight Software sells a transportation management platform to mid-size shippers: $184 million in revenue, 720 employees, 41 engineers with production access, an AWS Organization of 38 accounts (9 production, 17 non-production, 3 security and logging, 9 sandbox) in three regions, $4.2 million of annual AWS spend, and Microsoft 365 for the corporate estate. The FY26 engagement was a platform review with a workload deep-dive on the customer-facing product, covering all eight domains over six weeks against a configuration snapshot of 16 March 2026 and an activity period of 1 October 2025 to 15 March 2026. The team was one IT audit senior, a co-sourced cloud specialist for two weeks and a manager at 20 percent, for 380 budgeted hours.
| Population | Count | Result of full-population test |
|---|---|---|
| AWS accounts | 38 | All owned and funded; region SCP limits to three regions; root centrally managed for 35 of 38 |
| Local IAM users | 246, of which 41 human | 9 humans without MFA; 9 users matched to employees terminated in the period |
| Active access keys | 318 | 121 older than 90 days; 47 older than a year; 23 unused for 90 days; 6 owned by terminated employees, 2 used after termination |
| IAM roles (excluding service-linked) | 2,940 | 611 unused for 90 days; 14 external trusts, all with documented owners |
| Security groups | 1,873 | 26 open on 22 or 3389; 11 attached to running instances; 4 in production |
| S3 buckets | 412, of which 31 tagged confidential | Account-level block off in 3 sandbox accounts; 7 public buckets, 5 approved, 2 not; data events on 0 of 31 confidential buckets |
| RDS instances | 64 | 0 public; 2 unencrypted (non-production); 58 covered by AWS Backup, 6 non-production not |
| GuardDuty coverage and findings | 38 accounts, 3 regions | Enabled in 36 of 38 accounts; 14 High findings open over 30 days against a 7-day SLA |
| Restore and DR evidence | 1 restore test, 1 DR exercise | Restore test 11 months old; DR exercise achieved 6 hours 10 minutes against a 4-hour RTO, unremediated |
| Annual spend | $4.2 million | Tag coverage 71 percent of spend; 212 unattached volumes and 9 idle load balancers ($412,000 annualized); no anomaly detection; 3 sandbox accounts at $18,000 a month with no budget |
The report carried two findings and three observations. Finding 1 was rated High on the site’s severity scale because a policy breach at scale coincided with a demonstrated control failure: former employees’ credentials had been used after termination. The two post-termination uses turned out to be build pipelines that had inherited their creators’ keys, an offboarding design gap rather than an intrusion, but the rating stood because the company could not have told the two apart from its own logs. It was written in the five Cs structure:
Condition. Of 318 active IAM access keys across 38 AWS accounts on 16 March 2026, 121 (38 percent) were older than the 90-day rotation limit in the Cloud Security Standard, 47 were older than one year, and 6 belonged to employees terminated between 1 October 2025 and 15 March 2026. Two of those keys called AWS APIs after the owner’s termination date, on 214 occasions, from the build pipeline. Nine of 41 human IAM users held console passwords without MFA.
Criteria. Cloud Security Standard sections 4.2 (programmatic credentials rotated within 90 days and removed at termination) and 4.4 (MFA on all human identities); complementary user entity control 6 in the AWS SOC 2 Type II report.
Cause. The offboarding checklist removes IAM Identity Center access but not local IAM users and their keys; no detective rule disables aged keys; pipelines were configured with personal keys rather than federated roles.
Consequence. Credentials outside the company’s control could reach production accounts holding shipment and rate data for 1,900 customers, and the company could not tell a former employee’s use from a pipeline’s use.
Corrective action. Disable all keys older than 90 days by 30 June 2026; migrate the 11 pipelines to OpenID Connect role assumption by 31 July 2026; add local IAM users to the offboarding checklist; deploy an AWS Config rule that disables keys at 90 days. Owner: VP Platform Engineering. Internal audit will validate in Q3 FY26.
Finding 2, rated Moderate, covered detection and logging over confidential data. None of the 31 buckets tagged confidential had S3 data-event logging, so object-level reads could not be reconstructed even though data processing agreements with 62 enterprise customers required access logging; GuardDuty was off in 2 sandbox accounts; and 14 High findings had sat beyond the 7-day SLA for a median of 61 days. It stayed Moderate because bucket policies restricted access to named production roles, all confidential buckets sat behind VPC endpoints and nothing was public; the site’s guide to control deficiency evaluation describes that compensating-control reasoning. Management agreed to enable data events by 31 May 2026, extend GuardDuty to every account by SCP, and report finding aging weekly to the CISO. The observations covered the two unapproved public buckets, the DR exercise miss, and cost governance.
| Phase | Budgeted hours | Actual hours | Notes |
|---|---|---|---|
| Planning, scoping, audit-role provisioning | 40 | 46 | Six hours lost waiting for the role in three acquired-team accounts |
| Provider assurance (SOC 2, ISO scope, CUECs) | 24 | 22 | 17 CUECs mapped |
| Walkthroughs (platform, identity, pipeline, backup) | 36 | 34 | Four recorded sessions |
| Identity testing (domain 2) | 64 | 78 | Pipeline investigation added 14 hours |
| Configuration and logging (domains 3 to 5) | 96 | 92 | All 20 checks across 38 accounts by scripted export |
| Resilience and backup (domain 6) | 32 | 30 | Six tier-1 workloads compared |
| Cost governance (domain 7) | 24 | 26 | Idle valuation agreed with FinOps |
| Reporting, responses, QA | 64 | 68 | Draft day 27; final day 33 |
| Total | 380 | 396 | 4 percent over, within plan contingency |
The committee summary was four sentences: guardrails sound and provider assurance current; machine-credential hygiene failed and is fixed at the design level; detection over customer data incomplete and closing within a quarter; cost governance needs an owner. Guardrails first and money last is deliberate, because committees that hear about $412,000 first spend the meeting on it. The report followed the site’s report template; the findings went into the issue log with validation dates.
Common failures in cloud audits
Most of these failures come from importing a data center audit mindset into an environment that does not reward it.
| Failure | What it looks like | Why it matters | Fix |
|---|---|---|---|
| Treating the provider’s diagram as evidence | The workpaper pastes the AWS or Microsoft diagram and concludes provider layers are “covered” | The diagram summarizes a contract; the only evidence for the provider layer is the SOC 2 and its CUECs | Use the matrix above, with assurance source and tester named per cell |
| Reading only the SOC 2 opinion page | Reliance recorded as “unqualified opinion obtained” | Section 4 exceptions, missing services and unmapped CUECs are where the risk sits | Apply the nine-row checklist; map every CUEC to an owner |
| Sampling exportable populations | 25 of 1,873 security groups selected at random | The full population exports in seconds; a sample cannot say how many are open | Full-population configuration tests; sample only tickets and pull requests |
| Scoping one account when the organization has forty | Fieldwork limited to the production account named in the plan | Sandbox and acquired-company accounts are where public buckets and unbudgeted spend live | Start from the organization’s account list; write exclusions down |
| Testing humans and ignoring machines | MFA tested for 41 console users; 318 access keys not examined | Machine credentials outnumber humans and never expire on their own | Credential report and role analysis for the full machine population |
| “It is SaaS, the vendor handles it” | Microsoft 365 or Salesforce excluded on the strength of the vendor’s SOC 2 | Admin roles, sharing, integrations, tokens and log retention are all customer controls | SaaS tenant review for every tier-1 vendor on a rotating cycle |
| Confusing backup existence with restorability | Workpaper records that backup jobs succeeded nightly | Restore failures are found during incidents | Restore job evidence and a DR exercise within 12 months, compared to RTO and RPO |
Adapting the program: SaaS-only, multi-cloud, regulated, small functions
SaaS-only estates
A company with no IaaS still has a cloud audit to do; the domains shift rather than disappear. Domains 3 and 6 collapse into tenant configuration and data-recovery terms; domains 2, 5 and 8 grow. For each tier-1 tenant, test the administrator population and its MFA method, sharing and external-access settings, connected applications and API tokens with their scopes, audit log retention against what an investigation would need (Microsoft Purview Audit keeps 180 days at the Standard tier as of September 2026), and the contract’s export and deletion terms. The vendor master audit and procurement guides cover the intake side, where unapproved SaaS arrives on a corporate card.
Multi-cloud, Kubernetes and serverless
Multi-cloud doubles the identity and logging work and rarely doubles the team, so give the platform holding the highest-tier workloads the full program and run domains 1, 2 and 5 on the second. Kubernetes adds a control plane inside the control plane: cluster role bindings, namespace isolation, image provenance and admission policies are the identity and configuration tests at that layer, and the managed-service split (provider runs the control plane, you run the node pools) is a shared-responsibility matrix in miniature. Serverless moves the risk into execution roles and environment variables, so catalog checks 6, 8 and 19 matter most there.
Regulated financial services
Banks and insurers carry two more criteria sets, and the Third-Party Topical Requirement applies in full. In the United States, the June 2023 interagency guidance on third-party relationships from the Federal Reserve, FDIC and OCC frames the provider as a third party across planning, due diligence, contracting, monitoring and termination, and examiners expect domain 8 to show all five stages. In the EU, DORA (Regulation (EU) 2022/2554, applicable since 17 January 2025) requires a register of information on every ICT third-party arrangement, contractual audit and exit clauses, and resilience testing, so domain 6 evidence must include the register entry and exit plan for each critical provider; the site’s guide to internal audit in financial services covers the surrounding program.
SOX overlap
Where a financially significant application runs in the cloud, the ITGC layer for SOX 404 sits partly with the provider (its SOC 1 Type II and that report’s CUECs) and partly with the company (access, change and operations controls over the account and application), and the two must join without a gap. The usual failure is that the external auditor relies on the SOC 1 for the hypervisor while the company assumes it covers its own security groups. Draw the line with the matrix, then run the company-side tests from the site’s ITGC primer and its guide to ITGCs versus application controls.
A two-person audit function
A small function cannot run 380 hours of cloud fieldwork and does not need to. A minimum viable program is domains 1, 2 and 5 plus catalog checks 1, 3, 4, 9, 11, 14 and 20, run against the full population through a read-only role with the security team’s CSPM output as the starting point, which fits in 80 to 100 hours including the report. Two weeks of a co-sourced cloud specialist costs less than one incident; the site’s guide to co-sourcing covers contracting for knowledge transfer. The cloud belongs in the annual risk assessment as its own auditable entity with a named owner; the By Role hub has reading paths for IT auditors and CAEs, and the Risk Library lists cloud risks in risk-register form.
Related guides
- Auditing cybersecurity programs — the enterprise program this engagement reports into.
- IAM audit — the full identity engagement; domain 2 is its cloud slice.
- Privileged access audit — organization-level administrators and break-glass.
- User access review — the periodic review cloud roles rarely get.
- Third-Party Topical Requirement — mandatory for provider oversight from 15 September 2026.
- SOX ITGC scoping — cloud-hosted financial systems and SOC 1 reliance.
- ITGC primer for non-IT auditors — access, change and operations controls explained.
- IPE testing — relying on CSPM exports and credential reports.
- Topics — every guide on the site by subject.
Leave a Reply