AWS is the cloud most internal auditors will meet first, and the one on which a provider-agnostic program stops being enough at the point where the auditor has to name the artifact to request. This guide is that specific: it sets out an AWS audit program organized the way the estate is organized, from the organization and its guardrails down to accounts, identities, storage, networks, logging and keys, with the exact evidence to ask for at each step, the configuration facts the tests depend on, and the CIS Amazon Web Services Foundations Benchmark as the reference. It is written for IT auditors who can read a policy document and a configuration export and who need to know which ones matter, and it ends with an evidence request template and a worked example at a bank’s AWS organization. The cloud security audit program is the provider-agnostic layer above this one; the same structure will serve for Azure and Google Cloud with their own artifacts.
In this guide
- The AWS estate and where its controls live
- Organizations, guardrails and account vending
- Root users and the credentials that must not exist
- IAM: identities, policies, keys and roles
- Reading the artifacts: the credential report and the trust policy
- S3: exposure, encryption, versioning and immutability
- VPC, security groups and the metadata service
- CloudTrail, Config, GuardDuty and Security Hub
- KMS: keys, rotation and deletion
- Sampling across accounts: sweep everything, sample the depth
- The evidence artifacts to request
- The test program
- The AWS evidence request template
- Worked example: Lakeshore Bancorp’s AWS organization
- Common mistakes
- Related guides
The AWS estate and where its controls live
An AWS estate is a tree. At the top is an organization, managed from a management account, with organizational units that group member accounts, and policies attached at any level that flow down. Each account is a hard boundary for resources, identities and billing, and most controls are configured per account, per region, which is why “is CloudTrail on” is not a yes-or-no question but a question about every account and every region. Inside an account, identity is IAM (users, groups, roles, policies) supplemented by IAM Identity Center for federated human access; storage is S3 and the block and database services; networking is the VPC with its security groups, network ACLs, route tables and flow logs; logging is CloudTrail for API activity, Config for resource configuration history and compliance, GuardDuty for threat detection and Security Hub for aggregated findings against standards; and encryption keys live in KMS. The audit follows that structure, testing the organization-level controls once and the account-level controls across the population the cloud program‘s inventory established, using a handful of console exports and command-line outputs that the platform team can produce in an hour if asked precisely.
A note on what changes. AWS changes defaults, adds services and retires recommendations continuously, and a program written against last year’s console is partly wrong by the time it is used. The auditor confirms three things at planning: the current CIS benchmark version and what changed in it; the provider’s current defaults for the settings the program relies on (root MFA, S3 public access, encryption, metadata service); and whether the organization has adopted newer organization-level capabilities, such as centralized root management, that change what the right answer is. The facts in this guide are current at its writing in September 2026 and are the kind that should be re-checked, not remembered.
Organizations, guardrails and account vending
Service control policies are the organization’s preventive guardrails: policies attached to the organization root, an organizational unit or an account that set the maximum permissions any identity in the affected accounts can have, regardless of their IAM policies. A mature estate uses them to make the critical misconfigurations impossible: deny leaving the organization; deny disabling or altering CloudTrail, Config, GuardDuty and Security Hub; deny actions by the root user other than the few that require it; restrict regions to those approved; deny creating IAM users or access keys where federation is mandated; and protect the log archive and security tooling accounts. The audit exports the SCPs and their attachments, reads each against the intended guardrail list, tests one per guardrail by attempting the denied action in a sandbox (the automated-control test of one described in the automated controls guide), and checks that no account or OU is exempt without a documented reason. It then tests account vending: new accounts are created only through the platform team’s process (AWS Control Tower or an equivalent), land in the right OU with baseline configuration applied automatically, and appear in the inventory as a by-product. Delegated administration for the security services (a designated security account administering GuardDuty, Security Hub, Config aggregation and Access Analyzer across the organization) is the pattern to look for, and its absence is why coverage gaps appear.
Root users and the credentials that must not exist
Every AWS account has a root user with unrestricted power, and the root user is the single most important control in the estate. The facts an auditor needs are recent. AWS began requiring multi-factor authentication for the root users of Organizations management accounts in May 2024, extended the requirement to standalone accounts in June 2024, introduced centralized root access management for organizations in November 2024, and, as announced on 17 June 2025, now enforces MFA for root users across all account types, including member accounts. AWS’s recommended posture for organizations goes further than MFA: manage root access centrally from the management account and remove root user credentials from member accounts altogether, so that there is no root password or key in a member account to protect. The audit tests, for every account in the inventory: whether root credentials exist in member accounts or have been removed under central management; where they exist, that MFA is a hardware or virtual device registered and that no access keys exist for root (the IAM credential report shows both); that root has not been used for routine activity (CloudTrail events by the root identity in the period, each explained); that the root email addresses are organization-controlled distribution lists rather than individuals’ mailboxes, with the account recovery phone numbers current; and that a break-glass procedure for root exists, is stored securely and has been exercised. A member account with a root password in a departed engineer’s password manager is the most common High finding in first-year AWS audits, and centralized root management is the remediation that removes the class of problem.
IAM: identities, policies, keys and roles
Human access to AWS should arrive through federation, with IAM Identity Center (or an external identity provider through SAML or OIDC) issuing temporary credentials to roles, so that the corporate identity provider’s joiner-mover-leaver process governs cloud access and no long-lived passwords or keys exist for people. The audit’s first IAM artifact is therefore the IAM credential report for every account, which lists every IAM user with the age of their password and access keys, MFA status and last use; a well-run estate has few IAM users, all with a documented reason (a legacy integration, a break-glass), and the report is where the 200 forgotten keys live. The second artifact is the set of roles and their trust policies, tested for who can assume them: cross-account trusts to accounts outside the organization, wildcard principals, and third-party access without an external ID condition are the findings. The third is the policies themselves, tested for least privilege: administrator-equivalent policies attached to identities that do not need them, wildcard actions and resources, and inline policies that escape review; the IAM Access Analyzer’s findings for external access and its unused-access analysis do much of this work if enabled organization-wide. Permission boundaries and the SCPs above set the outer limits; the audit confirms that the boundaries apply to the identities that can create other identities, which is the escalation path an attacker uses. The IAM audit guide covers the identity program that federation plugs into, and the privileged access guide the administrative pattern that applies to AWS administrators as it does to domain administrators.
| Identity test | Artifact | What passes | What fails |
|---|---|---|---|
| Human access federated | IAM Identity Center configuration; IAM credential report per account | Humans on federated roles; IAM users limited to documented exceptions | IAM users with console passwords for staff; shared IAM users |
| MFA | Credential report (mfa_active); Identity Center MFA settings; root MFA status | MFA on every human identity; phishing-resistant for administrators; root on hardware or virtual MFA | Any console user without MFA; root without MFA in a member account still holding credentials |
| Access keys | Credential report (access_key_1_active, last_rotated, last_used_date) | Keys only for documented service uses; rotated within policy; unused keys removed | Keys older than the policy age; keys on administrative identities; unused keys active |
| Role trust | Trust policies for all roles (export); Access Analyzer external access findings | Trusts limited to organization accounts and named third parties with external ID conditions | Wildcard principals; trusts to unknown accounts; third-party roles without conditions |
| Least privilege | Policies attached to identities; Access Analyzer unused-access findings; policy simulator on samples | Administrator policies on a few break-glass roles only; wildcards absent from workload roles | AdministratorAccess on daily-use identities; service roles with wildcard actions |
| Boundaries and guardrails | Permission boundaries; SCPs | Identity-creating identities bounded; guardrails deny escalation paths | Any identity that can grant itself administrator rights |
Reading the artifacts: the credential report and the trust policy
Two artifacts repay a close read because they answer most of the identity questions on their own. The IAM credential report is a CSV with one row per IAM user plus the root row, and the columns tell the story: password_enabled and password_last_used show which users are humans with console access and whether they still use it; mfa_active shows whether they should have been allowed to; access_key_1_active with access_key_1_last_rotated and access_key_1_last_used_date (and the same for key 2) show every long-lived credential, its age and whether anything has used it in months; and the root row’s access-key columns should read false, because a root access key is a credential with unrestricted power stored somewhere on someone’s disk. The auditor sorts by key age, filters by last use, and has the access-key finding in ten minutes. A role’s trust policy is a short JSON document stating which principals may assume the role; the reading is for principals that are wildcards, accounts outside the organization, or services that should not need the role, and for third-party access whether the condition block requires an external ID and, ideally, restricts the source. A trust policy that permits a whole account to assume an administrative role, without a condition, has delegated that role to every identity in that account, and the finding writes itself once the auditor knows to look.
S3: exposure, encryption, versioning and immutability
S3 is where public exposure happens, and AWS has changed its defaults to make the accidental case harder: since April 2023 new buckets have Block Public Access enabled and access control lists disabled by default, and since January 2023 all new objects are encrypted at rest with server-side encryption by default. The defaults protect new buckets; the audit tests old ones and deliberate exceptions. Account-level Block Public Access enabled in every account, which overrides bucket settings and is the single control worth checking first; bucket-level settings for any account where the account-level setting is off, with the reason; bucket policies read for public or cross-account grants (Access Analyzer reports these); ACLs disabled or, where enabled, without public grants. Encryption tested for the key choice rather than the fact: sensitive data on customer-managed KMS keys where policy requires, with bucket policies denying unencrypted uploads. Versioning enabled on buckets whose data matters, with lifecycle rules that do not silently expire it. Object Lock in compliance mode on the buckets that hold backups and logs, which is AWS’s mechanism for the immutability the cyber resilience guide requires, with retention periods that exceed the plausible dwell time. Server access logging or CloudTrail data events for the sensitive buckets. And replication, where used, to a separate account so that a compromise of the source account cannot reach the copy. The scan is run across every bucket in every account, and the intended-exposure register from the cloud program is the comparison.
VPC, security groups and the metadata service
The VPC tests are configuration reads with a clear pass condition. Security groups: no rules permitting inbound traffic from any address to management ports (22, 3389) or database ports, and the default security group in every VPC restricting all traffic, which the CIS benchmark requires because resources launched without an explicit group inherit it. Network ACLs consistent with the segmentation design. VPC Flow Logs enabled on every VPC in every region, delivered to the central log archive. Internet and NAT gateways attached only to the subnets that need egress, with private subnets for everything else. VPC endpoints for AWS services so that traffic to S3, KMS and the control plane stays off the internet. And the instance metadata service: IMDSv2 required on EC2 instances, because the older version is the path by which an application vulnerability becomes stolen role credentials; the audit reads the metadata options across instances and treats IMDSv1-permitted instances holding roles as a finding. Where the organization runs containers and serverless, the same questions apply to task roles and function roles, and the pipeline guide covers how workloads get their identities without long-lived keys.
CloudTrail, Config, GuardDuty and Security Hub
CloudTrail is the audit log of the control plane, and the configuration that matters is an organization trail: created in the management account (or a delegated administrator), applying to all accounts including new ones, multi-region, with log file validation enabled, delivering to an S3 bucket in a dedicated log archive account whose bucket policy denies deletion and whose Object Lock protects retention, with the trail’s own configuration protected by an SCP against being stopped or altered. The audit reads the trail configuration, confirms it in a sample of member accounts, tests that a new account inherits it, and checks the archive bucket’s protection. CloudWatch metric filters and alarms on the trail for the events the CIS benchmark names (root use, unauthorized API calls, policy changes, CloudTrail configuration changes, console sign-in without MFA, security group and network ACL changes, KMS key deletion) are the detection layer, unless the organization has replaced them with a monitoring platform that ingests the trail, in which case the audit tests the platform’s detections instead. AWS Config, with the recorder enabled in all regions and an organization aggregator, supplies configuration history and conformance packs that continuously evaluate rules; it is the posture tool’s data source. GuardDuty enabled organization-wide with the delegated administrator, findings routed to the response process. And Security Hub, aggregating findings and evaluating accounts against standards, with the CIS AWS Foundations Benchmark standard enabled; the current benchmark is version 5.0.0, with 63 recommendations across identity and access management, storage, logging, monitoring and networking, and Security Hub’s control-by-control results, exported per account, are the fastest route to the estate-wide configuration picture the audit needs. The incident response audit guide covers the response chain that GuardDuty and Security Hub feed.
KMS: keys, rotation and deletion
Customer-managed KMS keys are where the data-protection decisions become testable. The audit lists every customer-managed key across accounts and regions and tests: automatic rotation enabled for symmetric keys; key policies that separate administration (who can change the policy or schedule deletion) from use (who can encrypt and decrypt), with the root-account default administrator statement understood; grants and cross-account usage explained; aliases and tags that map keys to data classes; and deletion protection, since scheduling a key’s deletion makes every object encrypted under it unrecoverable after the waiting period, which is a ransomware technique. CloudTrail events for key deletion scheduling and policy changes are among the alarms tested under logging, and the backup and recovery guide covers the recovery consequence when a key is lost.
Sampling across accounts: sweep everything, sample the depth
An estate of sixty accounts in two regions cannot be audited account by account in the hours available, and it does not need to be, because most of the tests are configuration reads that the platform’s own services perform across the whole population. The program therefore sweeps everything and samples the depth. The sweep is Security Hub’s control results, Config’s compliance history and Access Analyzer’s findings across all accounts, plus the organization-level artifacts, which give a complete configuration picture for the benchmark’s recommendations with no sampling at all; the auditor’s work is to confirm the sweep’s coverage (every account, every region, the current standard) and then read the results. The depth is a sample of accounts, always including the production accounts holding regulated or financial data and a few of the least-governed ones, in which the auditor reads the raw artifacts (credential report, trust policies, bucket settings, security group rules, trail configuration as seen from inside the account) to confirm the sweep is telling the truth and to find what the benchmark does not test, such as a trust policy to a former consultancy. Where the sweep and the raw artifacts disagree, the sweep’s coverage is the finding. SCPs and other preventive guardrails are tested by a test of one each, in a sandbox, because they are automated controls; the account-vending process is tested by tracing the newest three accounts through it; and the orphan search is a reconciliation, run once, across the whole population, as the cloud program describes.
The evidence artifacts to request
The engagement moves quickly when the request list names artifacts the platform team can generate mechanically, and slowly when it asks for “evidence of access controls”. The table lists the artifacts by area, all of which are exports from the console, the command line or the security services rather than documents someone writes for the auditor.
| Area | Artifact | Scope | What the auditor does with it |
|---|---|---|---|
| Organization | Organization structure export (accounts, OUs); SCP documents and attachments; Control Tower or account-vending configuration; delegated administrator settings | Organization | Reconcile to the inventory; read guardrails; test one per guardrail |
| Root | Centralized root management status; per-account root MFA status; credential report root rows; CloudTrail root-user events for the period | Every account | Confirm credentials removed or MFA present; explain each root use |
| IAM | IAM credential report (CSV) per account; role list with trust policies; attached and inline policies; Access Analyzer findings (external and unused access); Identity Center assignments | Every account | Users, keys, MFA, trusts, least privilege |
| S3 | Account-level Block Public Access status; bucket list with public-access settings, encryption configuration, versioning, Object Lock and logging; Access Analyzer public-bucket findings | Every account and region | Exposure, encryption key choice, immutability, logging |
| Network | Security group rules (all VPCs); default security group rules; NACLs; flow log status per VPC; EC2 instance metadata options; VPC endpoints | Every account and region | Exposure, segmentation, IMDSv2, egress |
| Logging | Organization trail configuration; log archive bucket policy and Object Lock; Config recorder status per region and aggregator; GuardDuty organization status; Security Hub enabled standards and control results per account | Organization and every account | Coverage, integrity, detection, benchmark results |
| KMS | Customer-managed key list with rotation status, key policies, grants, pending deletions | Every account and region | Rotation, separation, deletion protection |
| Change and drift | Infrastructure-as-code repositories for the landing zone; drift detection reports; Config compliance history | Platform | Change control over the estate’s own configuration |
The test program
| # | Test | CIS v5.0.0 section | Pass condition |
|---|---|---|---|
| 1 | Every account in the organization structure; vending process enforced; inventory reconciled to spend and federation | — | No orphan accounts; new accounts baseline automatically |
| 2 | SCP guardrails present, attached without gaps, tested one per guardrail | — | Critical misconfigurations denied at the organization level |
| 3 | Root credentials removed under central management or MFA present with no access keys; root use explained; recovery contacts controlled | Identity and Access Management | No unmanaged root; no routine root use |
| 4 | Human access federated; IAM users limited and justified; MFA universal | Identity and Access Management | Credential report clean except documented exceptions |
| 5 | Access keys within rotation policy; unused keys removed; none on administrative identities | Identity and Access Management | Credential report ages within policy |
| 6 | Role trust policies limited; external ID on third-party trusts; Access Analyzer external findings resolved | Identity and Access Management | No wildcard or unknown-account trusts |
| 7 | Least privilege on sampled identities and workload roles; permission boundaries on identity-creating roles | Identity and Access Management | Administrator rights confined to break-glass roles |
| 8 | Account-level Block Public Access on; public buckets reconciled to intended exposures; ACLs disabled | Storage | No unintended public data |
| 9 | Encryption key choice per data class; deny-unencrypted policies; versioning and Object Lock on backup and log buckets | Storage | Sensitive data on customer-managed keys; immutability where required |
| 10 | Organization trail multi-region with validation; archive bucket protected; new account inherits | Logging | Complete, tamper-evident, centrally retained |
| 11 | Config recorder and aggregator all regions; GuardDuty organization-wide; Security Hub with CIS standard enabled | Logging / Monitoring | Coverage complete; findings routed and aged |
| 12 | Metric filters and alarms (or platform detections) for the benchmark’s monitored events; triage evidence | Monitoring | Detections exist and are acted on within SLA |
| 13 | Security groups and default groups; NACLs; flow logs on all VPCs; endpoints; IMDSv2 required | Networking | No open management or database ports; default groups closed; IMDSv2 enforced |
| 14 | KMS rotation, key policy separation, deletion protection, cross-account grants explained | Storage | Keys rotated; administration separated; no unexplained deletions scheduled |
| 15 | Landing zone under infrastructure as code with review; drift detected and reconciled | — | Estate configuration under change control |
The AWS evidence request template
AWS audit evidence request
Scope. Organization ID; management account; list of all member accounts with OU, environment class and owner (from the platform team, to be reconciled by the auditor); regions in use; period covered; date of extraction for each artifact.
Organization artifacts. Organization structure export; all SCPs with attachment targets; account vending configuration; delegated administrator assignments for Security Hub, GuardDuty, Config, Access Analyzer and CloudTrail.
Per-account artifacts (every account, every region where applicable). IAM credential report (CSV); role list with trust policies; policies attached to users, groups and roles (managed and inline); Access Analyzer findings; account-level Block Public Access status; bucket inventory with public-access, encryption, versioning, Object Lock and logging settings; security group and default security group rules; NACLs; VPC flow log status; EC2 metadata options; VPC endpoints; CloudTrail configuration as seen in the account; Config recorder status; GuardDuty status; Security Hub CIS control results; KMS key list with rotation, policies, grants and pending deletions; CloudTrail root-user events.
Platform artifacts. Organization trail configuration; log archive bucket policy and Object Lock configuration; Config aggregator and conformance packs; monitoring platform detection rules for control-plane events; landing zone infrastructure-as-code repositories and drift reports; the intended-exposure register; the exception register.
Handling. Artifacts to be provided as exports with extraction timestamps, not screenshots where an export exists; delivered to the audit evidence store; credential reports and key material treated as restricted.
Worked example: Lakeshore Bancorp’s AWS organization
Lakeshore Bancorp, the illustrative $9 billion regional bank used across this site, runs its digital channels, data platform and a set of business-unit workloads on AWS, and the cloud security program audit found 62 accounts where the platform team knew of 48. The AWS-specific work in that engagement, 160 of its 420 hours, followed this program, and its results are the detail behind the cloud audit’s findings. The organization structure held the 48 in five OUs with 14 SCPs, including the guardrails that mattered: deny leaving the organization, deny CloudTrail and GuardDuty changes outside the security account, region restriction to two, and deny IAM user creation in the production OU. Each was tested with a denied action in a sandbox and held. The 14 orphan accounts were outside the organization and therefore outside every guardrail.
| Area | Result | Finding and rating |
|---|---|---|
| Root | The 48 organization accounts under centralized root management with member-account root credentials removed; the 14 orphans each holding a root password, three without MFA, two with root access keys, and 27 root sign-in events in the period across them | High: orphans brought into the organization and root credentials removed; the two access keys deleted the day they were found |
| IAM | Humans federated through Identity Center in the 48; 41 IAM users with passwords in the orphans; 210 access keys older than 90 days estate-wide, 31 on identities with administrator policies; 6 cross-account role trusts to accounts not in the organization, two to a former consultancy | High: keys rotated or removed within fieldwork; trusts to unknown accounts deleted; Access Analyzer enabled organization-wide with the security account as delegated administrator |
| S3 | Account-level Block Public Access on in the 48, off in 9 orphans; 14 public buckets, two holding data (one the 2.1 GB customer extract in a data-science sandbox); backup buckets without Object Lock; 6 of 9 sensitive buckets on provider-managed keys | High: exposure closed; Object Lock in compliance mode on backup and log archive buckets; key policy enforced by a deny-unencrypted bucket policy |
| Network | 4 database ports open to the internet in non-production; default security groups open in 11 VPCs; flow logs on 40 of 58 VPCs; IMDSv1 permitted on 62 percent of instances | Medium: rules closed; default groups locked by an SCP-backed Config rule; IMDSv2 required through instance settings and launch templates |
| Logging | Organization trail multi-region with validation to a log archive account with Object Lock; not applied to the orphans; Config aggregator and GuardDuty covering the 48; Security Hub running CIS v3.0 rather than the current standard; 1,240 open high findings, median age 140 days | High: coverage extended to all accounts; standard updated; a 30-day SLA for high findings with monthly aging to the CISO |
| KMS | One customer-managed key without rotation since 2021; key policies separated administration and use; no pending deletions | Low: rotation enabled |
The AWS detail changed one thing in the report’s narrative. The cloud program audit had described the platform team’s controls as working in the accounts they knew about, and the AWS evidence showed why: centralized root management, the SCP set, the organization trail and the delegated security account were sound engineering, and every High finding traced to the 14 accounts that had been created outside the process the engineering assumed. The remediation was therefore the account vending control and the block on card-based purchasing, not a rebuild of the estate, and the re-test a year later, with 71 accounts all inside the organization, found the same controls applying to all of them.
Common mistakes
Testing the management account’s configuration and assuming it applies everywhere. Asking for screenshots when the credential report, the trail configuration and the Security Hub results are exports. Checking root MFA and not checking whether root credentials should exist at all. Reading IAM policies without reading the SCPs that limit them, or reading the SCPs without testing one. Treating Block Public Access at bucket level as sufficient when the account-level setting is off. Testing encryption as on or off rather than asking who holds the key. Accepting an organization trail as complete without confirming it in a member account and a new account. Running the CIS benchmark two versions behind and reporting the pass rate. Forgetting the regions the organization does not use, where an attacker’s resources would run unobserved unless the SCP denies them. And auditing AWS without the inventory work the cloud program describes, which is how the 14 accounts stay invisible. The ITGC primer covers the general-controls framing that a SOX-scoped AWS estate inherits, and the SOX ITGC scoping guide how the in-scope accounts are chosen.
Related guides
- How to audit cloud security: a control-by-control program
- How to audit the SDLC and DevOps pipeline
- How to audit identity and access management
- How to audit privileged access
- How to audit Active Directory and Entra ID
- Testing automated controls
- How to audit backup and recovery
- Auditing cyber resilience
- How to audit incident response
- How to audit patch and vulnerability management
- Auditing cloud computing: risks and governance
- IT general controls: the complete primer
Leave a Reply