AWS Security Review Process: What Happens Step by Step

You've decided your AWS environment needs a professional security review. Maybe you've already booked a call, or maybe you're comparing providers and want to understand the AWS security review process before committing. Either way, here's exactly what happens, step by step, day by day, so there are no surprises.

Whether you call it a security review, a security audit or assessment, the goal is the same: identify what's misconfigured, what's missing, and what needs to change. Having reviewed 200+ AWS accounts, I can tell you that the same misconfigurations appear in 90% of environments. The difference between a good review and a great one is how findings are prioritized and presented so you can actually act on them.

By the end of this guide, you'll know exactly what to prepare, what happens during each phase, what you'll receive, and what your options are afterward.

Before the Review: How to Prepare

Security review preparation on your end is minimal. Most clients spend less than an hour total across the entire engagement. Here's what helps the review go smoothly.

What I Need from You (Access and Documentation)

The most common preparation mistake is granting full admin access. I don't need it and don't want it. Here's what's actually required:

• Read-only IAM role: A role with the SecurityAudit AWS managed policy attached. This provides read-only access to security configurations without any ability to modify your environment. I provide a CloudFormation template to set this up in minutes.
• Architecture documentation (if available): Diagrams, service maps, or even a rough sketch of how your environment is structured. Helpful but not required.
• Compliance requirements: If you need to align with specific frameworks (SOC 2, HIPAA, PCI-DSS, CIS), let me know upfront so the review covers those controls. For SOC 2 specifically, see how AWS SOC 2 compliance requirements map to your controls.
• Known concerns: Anything keeping you up at night. Recent incidents, areas you suspect are misconfigured, or services you've outgrown.

Who Should Be Involved

You don't need to assemble a large team. Three people typically cover it:

1. AWS account owner or administrator - to provision the read-only IAM role
2. Technical lead or CTO - for 30 minutes of architecture context during the discovery call
3. Compliance or security lead (if applicable) - to confirm framework alignment requirements

Total time commitment from your team: roughly 30-60 minutes across the entire engagement. The rest happens on my side.

Day 1: Discovery Call and Access Setup

Once you've set up the read-only role, the engagement kicks off with a discovery call. This is where I learn what matters most to you.

What We Cover in the Discovery Call

The discovery call runs 30-45 minutes and covers:

• Your environment: How many accounts, which regions, what services you're running, and how your architecture is structured
• Business context: What workloads are business-critical, what compliance obligations you have, and what triggered the review
• Scope alignment: Confirming which accounts and regions to assess, and which compliance frameworks to evaluate against
• Known risk areas: Any services or configurations you're already concerned about

This conversation is important because it determines focus. A startup with a single account running a SaaS application gets a different emphasis than a company with 20 accounts preparing for a SOC 2 audit. The AWS shared responsibility model defines what falls under your responsibility, and the discovery call ensures I'm reviewing the parts that matter most to your business.

Setting Up Secure Read-Only Access

If you haven't provisioned the IAM role beforehand, we handle it during this step. The role uses:

• Minimal permissions: The SecurityAudit managed policy, nothing more
• No write access: I cannot create, modify, or delete any resources in your environment
• Trust relationship scoped: The role is only assumable from a specific external account ID

Access setup takes about 10 minutes using the CloudFormation template I provide. Once confirmed, the analysis begins, typically on the same day.

Days 1-2: The Security Analysis Process

This is the core of the engagement. The assessment combines automated scanning with manual expert review, aligned with the AWS Well-Architected Security Pillar and its seven best practice areas. For the detailed checklist behind this process, see our complete AWS security review checklist.

What I Review (The Seven Security Domains)

Every review covers these seven domains systematically:

Tools and Methodology

I use a combination of native AWS security services and open-source tools:

• AWS Security Hub - Centralized security scoring with automated checks against FSBP and CIS benchmarks. Security Hub aggregates findings from multiple sources and provides exposure findings with attack path analysis.
• Amazon Inspector - Automated vulnerability scanning of EC2 instances, container images, and Lambda functions, including both package vulnerability and code vulnerability detection
• IAM Access Analyzer - Identifies external access to your resources, unused permissions, and validates policies using automated reasoning
• AWS Config - Evaluates resource compliance against managed rules and conformance packs
• Amazon GuardDuty - Reviews threat detection status across CloudTrail, VPC Flow Logs, and DNS, including Extended Threat Detection for multi-stage attack identification
• Prowler - Open-source CIS benchmark assessment that complements native AWS tools
• Manual expert review - Architecture analysis, policy review, and business-context evaluation that automated tools cannot perform

The automated tools identify what's misconfigured. The manual review determines what actually matters for your environment and what the tools miss. That combination is the difference between running AWS Security Hub yourself and hiring someone who knows how to interpret the results.

The Deliverable: Your Security Report Walkthrough

Once the analysis is complete, everything gets compiled into a prioritized security posture assessment and report. Here's what that report contains, because "you'll receive a detailed report" tells you nothing.

How Findings Are Classified

Every finding is classified by severity, following the same model used by AWS Security Hub and Inspector:

• Critical: Immediate risk to data or operations. Active exposure, public access to sensitive resources, or exploitable vulnerabilities. Fix within days.
• High: Significant risk requiring prompt action. Missing MFA on privileged accounts, overly permissive IAM policies, or disabled logging. Fix within 2 weeks.
• Medium: Moderate risk to address in normal development cycles. Non-optimal encryption settings, missing tags, or security group refinements. Fix within 1-3 months.
• Low: Best practice improvements that strengthen your overall posture. Documentation gaps, minor configuration optimizations. Address during regular maintenance.

Each finding includes: what was found, why it matters (business impact, not just technical risk), how to fix it (specific remediation steps), and estimated effort so you can plan resources. On average, a review identifies 15-30 findings per account, with 2-5 classified as critical or high.

What the Remediation Roadmap Looks Like

The report doesn't just list problems. It organizes them into a prioritized roadmap:

• Quick wins (0-30 days): Enabling MFA, removing overly permissive security group rules, enabling CloudTrail across all regions, rotating old access keys
• Short-term (1-3 months): Implementing least-privilege IAM policies, deploying GuardDuty, configuring CloudWatch alarms, establishing automated backups
• Long-term (3-6 months): Centralizing logging to a dedicated account, implementing automated remediation, completing compliance framework alignment

After the report is ready, I walk you through every finding on a call. You can ask questions, challenge priorities, and discuss remediation approaches. This isn't a document dump. It's a conversation about what to fix and in what order.

After the Review: Your Options

The report walkthrough call is included in every engagement. After that, you have three options. No pressure, no upsell. The report stands on its own regardless of what you choose.

Remediation Support

Option 1: Self-remediation. You take the report and fix findings using the step-by-step guidance included with each finding. Many teams handle quick wins and short-term items internally. The remediation roadmap tells you exactly what to do.

Option 2: Guided remediation. I help you implement the fixes, especially for complex changes like IAM policy refactoring, network segmentation, or multi-account security architecture. This is common for teams that want to move fast without risk of breaking production workloads.

For a broader understanding of what good security looks like, AWS security best practices covers the foundational patterns behind these remediations.

Ongoing Security Monitoring

Option 3: Continuous security partnership. Security isn't a one-time activity. For organizations that want ongoing monitoring, this includes periodic reviews (quarterly is the most common cadence), drift detection, and new-finding triage. AWS recommends a continuous monitoring approach with daily Security Hub reviews, weekly Inspector findings analysis, and quarterly Well-Architected reassessments.

The right option depends on your team's capacity and expertise. Most clients start with guided remediation for critical and high findings, then handle the rest internally.

Sample Timeline: From Booking to Deliverables

The most common question I get is "how long does this take?" Here's the typical timeline for a standard AWS security review.

Total: approximately 1 week from kickoff to deliverables for a standard single-account or small multi-account environment.

Larger environments with 10+ accounts, multiple regions, or complex architectures may take longer. Timelines vary based on organization size and scope, which is exactly why the discovery call happens first. I'll give you a specific estimate after understanding your environment.

Common Questions About the AWS Security Review Process

Ready to Start Your AWS Security Review?

Now you know exactly what the AWS security review process involves: minimal preparation on your end, a focused analysis across seven security domains, a prioritized report with clear remediation steps, and a walkthrough call to discuss every finding.

The entire process takes approximately one week. Your team's time commitment is roughly an hour total. You receive actionable findings, not vague recommendations, and you choose what happens next.

The first step is a discovery call to understand your environment and confirm scope. If you want to self-assess before booking, start with our complete AWS security review checklist. If you're still evaluating providers, here's how to choose an AWS security partner using a structured framework.