Cloud audits have a way of exposing gaps that teams never knew existed. If your organization runs workloads on Amazon Web Services, preparing for a security audit is not a one-day task. It requires a structured review of your environment across multiple domains - identity, visibility, network boundaries, and data protection.
This post walks through the four key areas every AWS team should examine before stepping into an audit, along with the specific checklist items that matter most in each area.
AWS makes it easy to spin up infrastructure. That same speed, however, makes it easy to carry forward misconfigured defaults, forgotten roles, and open ports that nobody remembers creating.
Security reviews often fall between the cracks because they sit at the intersection of development, operations, and compliance. No single team fully owns them. That is exactly why having a structured checklist matters. It removes ambiguity and gives every stakeholder a shared starting point.
Identity and Access Management is where most cloud breaches begin. Excessive permissions, unused accounts, and missing multi-factor authentication are among the most common findings in AWS audits.
A solid IAM review looks at who has access, what level of access they hold, and whether that access is still necessary. The principle of least privilege is not just a best practice - in most compliance frameworks, it is a requirement.
Item 1: Disable or restrict root account usage The root account has unrestricted access to everything in your AWS environment. Auditors will check whether it is being used for day-to-day tasks. It should not be. Verify that root account login activity is minimal, that no access keys are attached to it, and that MFA is enabled on the account.
Item 2: Enable MFA for all IAM users with console access Any human user who can log into the AWS Management Console should have multi-factor authentication enabled. This is one of the first things an auditor looks for and one of the most straightforward controls to verify. Check your IAM user list and flag any accounts without MFA enforced.
Item 3: Review and remove inactive IAM users and roles Dormant accounts are a security liability. Users who have left the organization, contractors whose engagements have ended, and service roles tied to decommissioned applications all represent unnecessary access. Review last activity timestamps and remove or disable anything that has not been used within a defined period.
Item 4: Audit IAM policies for overly permissive access Policies that grant broad permissions - particularly anything resembling administrator access assigned to users or roles that do not require it - are a consistent audit finding. Review attached policies, look for wildcard actions and resources, and tighten permissions to match actual operational needs.
Visibility is the foundation of cloud security. Without proper logging in place, there is no reliable way to detect suspicious activity, investigate an incident, or demonstrate compliance to an auditor.
AWS offers several native logging services that cover API activity, resource configuration changes, and network traffic. The question is not whether these services exist - it is whether they are enabled, configured correctly, and protected from tampering.
Item 5: Confirm AWS CloudTrail is enabled across all regions CloudTrail records API calls made in your AWS account. If it is not enabled in every region, activity in uncovered regions goes unlogged. Verify that a multi-region trail exists, that it is actively logging, and that management events are being captured. This is a baseline expectation in virtually every compliance audit.
Item 6: Ensure CloudTrail logs are stored in a protected S3 bucket Logs are only useful if they have not been altered or deleted. The S3 bucket storing your CloudTrail logs should have versioning enabled, public access blocked, and an access policy that prevents log deletion — including by administrators. MFA delete adds an additional layer of protection.
Item 7: Enable AWS Config to track resource configuration changes AWS Config records the configuration state of your resources over time and flags changes that fall outside defined rules. This gives auditors a historical record of your environment and demonstrates that configuration drift is being monitored. Confirm that Config is enabled in all active regions and that relevant rules are in place.
Network misconfigurations are a reliable source of audit findings. Security groups, public subnet exposure, and unrestricted traffic rules are all worth reviewing before an audit surfaces them first.
A thorough network security review looks at how traffic flows in and out of your environment, which resources are publicly accessible, and whether your architecture reflects deliberate design decisions.
Item 8: Review security group rules for unrestricted inbound access Security groups that allow inbound traffic from 0.0.0.0/0 on sensitive ports - such as SSH on port 22 or RDP on port 3389 - are among the most common and most cited findings in cloud audits. Review all security groups and confirm that open access is intentional, documented, and limited to only the ports and protocols that are operationally required.
Item 9: Identify and assess publicly accessible resources EC2 instances, RDS databases, S3 buckets, and Elasticsearch domains that are unintentionally exposed to the public internet represent significant risk. Use AWS Trusted Advisor and AWS Config rules to identify resources with public access enabled and verify that each one is deliberately and appropriately configured.
Item 10: Verify VPC flow logs are enabled VPC Flow Logs capture information about the IP traffic going to and from network interfaces in your VPC. They are an important source of evidence during incident investigations and a control that auditors increasingly expect to see in place. Confirm that flow logs are enabled for your production VPCs and that the data is being retained in a queryable format.
Encryption is one of those controls that auditors expect to see applied broadly and consistently. Data stored across AWS services and data moving between them should both be covered.
Common gaps found during audits include storage resources with encryption disabled, outdated configurations, and key management practices that are loosely controlled or poorly documented.
Item 11: Confirm encryption at rest is enabled for critical storage services S3 buckets, EBS volumes, RDS instances, and other storage services all support encryption at rest. Review whether encryption is enabled on your critical data stores, whether AWS-managed or customer-managed KMS keys are being used, and whether your key usage aligns with your data classification policy. Unencrypted storage containing sensitive data is a finding that is difficult to explain in an audit.
Item 12: Enforce encryption in transit across services and endpoints Data moving between services, between users and applications, and between your environment and external systems should be encrypted in transit. This means enforcing HTTPS on load balancers and APIs, disabling older TLS versions, and ensuring that internal service-to-service communication is not passing data in plaintext. Review your load balancer listeners, API Gateway configurations, and any custom application endpoints.
A checklist reviewed once before an audit is useful. A checklist reviewed on a regular cadence is a security program.
The most mature AWS environments treat these reviews as an ongoing practice rather than an emergency measure. Automated monitoring, scheduled configuration reviews, and clear ownership of each control area all contribute to an environment that stays audit-ready rather than scrambling to become audit-ready.
Building that muscle takes time, but the starting point is always the same - knowing what to look at and making sure nothing important is being skipped.
AWS security does not have to be overwhelming, but it does require structure. These 12 checklist items across IAM, logging, network security, and encryption cover the areas where gaps most commonly appear and where auditors most consistently look.
Some of these items take minutes to verify. Others may surface findings that require remediation work. Either way, the value of running through this checklist before an audit is that your team is in control of the discovery process - not the auditor.
Start with the checklist. Work through each item deliberately. Build it into your routine. The audit will take care of itself.
At Thirty11 Solutions, I help businesses transform through strategic technology implementation. Whether it's optimizing cloud costs, building scalable software, implementing DevOps practices, or developing technical talent. I deliver solutions that drive real business impact. Combining deep technical expertise with a focus on results, I partner with companies to achieve their goals efficiently.
Let's discuss how we can help you achieve similar results with our expert solutions.
Our team of experts is ready to help you implement these strategies and achieve your business goals.
Schedule a Free Consultation