What is an AWS security audit?
An AWS security audit reviews how your cloud account is configured: who has access, what is exposed to the internet, what gets logged and whether your backups survive an attack. It runs with read-only permissions and ends in prioritized findings, each with its fix and evidence that it was actually closed.
AWS frames it with the Shared Responsibility Model. AWS protects the infrastructure that runs its services, the security «of» the cloud. You own security «in» the cloud: your users and permissions, your data and its encryption, the guest operating system on your EC2 instances and its firewall rules. No default setting does that work for you.
What does an AWS security audit check?
A serious review follows the order of an attack: identity first, because it is the key to everything, and your ability to recover last. These are the ten areas the Security OS cloud module covers, 49 controls in total:
| Area | What gets checked | Why it matters |
|---|---|---|
| Root account | MFA on, no root access keys, recovery email and phone under control | Root has full access, billing included |
| Identities and MFA | MFA for every user with a console password, keys not rotated in 90 days, credentials unused for 45 days, full-admin policies | A leaked key is one of the most common ways into an account |
| Detection and logging | Multi-Region CloudTrail with log file validation; GuardDuty, Security Hub and AWS Config on, and someone actually reading the alerts | Without logs there is no way to know what happened |
| Cost alerts | Budgets that alert on actual and forecasted spend | Unexpected spend can be the first sign of abuse, such as cryptomining |
| Storage | S3 Block Public Access, TLS required, EBS encryption by default | A public bucket leaks data without anyone breaking in |
| Databases | RDS not publicly accessible, encrypted, automated backups, deletion protection | The database is what an attacker wants to take |
| Network | No 0.0.0.0/0 on admin ports (22, 3389), IMDSv2, VPC flow logs | An open admin port is a standing invitation |
| Secrets | Passwords and keys in Secrets Manager with rotation, not in environment variables or code | A plaintext secret gets copied along with the code |
| Ransomware-resistant backup | AWS Backup Vault Lock, a copy in another account or Region, a tested restore | Ransomware goes after the backups first |
| Organization policies | AWS Organizations with SCPs that cap what each account can do | They set a ceiling even an admin user can't exceed |
The yardsticks are public. The CIS AWS Foundations Benchmark collects the baseline account settings; AWS Security Hub CSPM supports versions 5.0.0, 3.0.0, 1.4.0 and 1.2.0, and AWS recommends 5.0.0. The AWS Well-Architected Security Pillar gives the design framework, and the AWS Foundational Security Best Practices standard adds per-service controls.
Four details that usually slip through
- CloudTrail event history only keeps the past 90 days of management events. Without a trail or an event data store, what happened four months ago can no longer be investigated.
- AWS recommends you don't create access keys for the root user and requires root MFA on every account type. An old root key inside a script is one of the most serious findings.
- GuardDuty analyzes CloudTrail management events, VPC flow logs and DNS logs to detect compromised credentials, cryptomining or data exfiltration. Turning it on does nothing if nobody acts on what it reports.
- SCPs never grant permissions; they only set the maximum. They also don't apply to the organization's management account, which is why that account shouldn't run workloads.
What access does the auditor need, and how long does it take?
Read-only. AWS ships a managed policy, SecurityAudit, meant for software that audits an account's configuration: it reads security metadata and changes nothing. Security OS works that way. It connects through a read-only role you create and can remove at any time, and it reads configuration and metadata: who has access, what is open, how it is backed up. It does not read the contents of your databases or files.
If someone asks for admin credentials to «audit», treat it as a red flag. Fixing is a separate phase with separate permission, and each change is approved on its own.
Timing depends on size: how many accounts, Regions and resources, and whether you use AWS Organizations. The automated control checks are the fast part. What takes longer is what matters: confirming each finding, ranking it by real risk and preparing a fix that won't break production. With Security OS, scope and timeline are agreed before we start, and the first run becomes your baseline.
What should an AWS security audit deliver?
A PDF with 300 alerts isn't an audit; it's a to-do list. Ask for these four things:
- Findings ranked by risk, not grouped by service. What lets someone in or lets them delete things comes first.
- For each finding, a prepared fix: what changes, why, and how to roll it back if something breaks.
- A before-and-after comparison, control by control, produced by the same audit engine. Without it, a security improvement is just an opinion.
- A baseline to measure the next run against. If someone opens a port on Tuesday, you hear about it on Tuesday.
AWS is the first module. If you also want your repositories, servers and application code reviewed, that's a full IT security audit. And if you run Linux on EC2 or a VPS, the server hardening guide covers the part AWS leaves to you.
How does Security OS run the AWS audit?
- Connect: you grant read-only access to your account. That access can't change anything and you can revoke it whenever you want.
- Audit: the cloud auditor walks the ten areas and records the state of each of the 49 controls. You get prioritized findings and your baseline.
- Fix: the remediator prepares each fix with the before, the change and the rollback. You approve it, it's applied and logged.
- Monitor: the engine reruns the same audit, and the alert analyst translates what the cloud reports into plain language: what happened, who did it and what to do.
What we don't do matters too. Security OS is not a 24/7 SOC with analysts watching screens, it doesn't certify ISO 27001 or SOC 2, and it doesn't do penetration testing. It audits, fixes with your approval and proves it with evidence, which is exactly what a certification auditor will ask for later. To see which vulnerabilities matter this week, check the security alerts, or see Security OS in full.
Tell us how many accounts and Regions you use. We'll reply with the assessment scope and its price before anything starts.
Request an AWS assessmentFrequently asked questions
What is an AWS security audit?
It's a review of your AWS account configuration: identities and MFA, logging and detection, storage, databases, network, secrets and backups. It ends in prioritized findings, each with a fix and evidence that it was closed.
Do you need admin access to my AWS account?
No. The audit runs with a read-only role along the lines of the SecurityAudit managed policy. Fixes are applied one at a time, with your approval, and logged.
Isn't AWS responsible for security?
For security of the cloud, yes: data centers, hardware and virtualization. Security in the cloud, meaning your users, permissions, data, network and servers, is yours under the Shared Responsibility Model.
What is the CIS AWS Foundations Benchmark?
It's a set of baseline security settings for AWS accounts published by the Center for Internet Security. Security Hub CSPM evaluates versions 5.0.0, 3.0.0, 1.4.0 and 1.2.0; AWS recommends 5.0.0.
How long does an AWS security audit take?
It depends on how many accounts, Regions and resources you have. Automated checks are quick; confirming, prioritizing and preparing each fix is what takes time. Scope and timeline are agreed up front.
Does it help with ISO 27001 or SOC 2?
Security OS doesn't certify, but it leaves the technical evidence those audits ask for in order: the state of each control before and after the fix.
What if I already had an incident in AWS?
Move fast: CloudTrail event history only keeps 90 days. The Security OS forensics agent rebuilds the timeline and preserves the evidence before it expires.
Sources
- AWS: Shared Responsibility Model
- AWS Well-Architected Framework: Security Pillar
- AWS Security Hub CSPM: CIS AWS Foundations Benchmark
- AWS Security Hub CSPM: AWS Foundational Security Best Practices
- AWS IAM: Root user best practices
- AWS CloudTrail: Working with event history
- Amazon GuardDuty: What is GuardDuty
- AWS Backup Vault Lock
- AWS Organizations: Service control policies
- AWS Budgets: Managing your costs
- AWS managed policy: SecurityAudit
Written by Samuel Hinojosa and the wITS security team · Updated Oct 25, 2026 · Markdown
