The AWS Security Checklist Every Startup CTO Should Complete Before Their First Enterprise Deal

You built your product on AWS. It works. It scales. Customers are happy. Then an enterprise prospect's security team sends over their review checklist, and half the items are about your AWS configuration.

"How are your IAM policies structured?" "Is VPC flow logging enabled?" "What's your encryption key management strategy?"

You've been focused on shipping features, not cloud security posture. That's normal. Here's the checklist I run through with every startup CTO preparing for an enterprise security review — organized by what buyers actually check and what actually prevents breaches.

IAM: The Most Important Section

Identity and Access Management is where enterprise security reviews spend the most time, and where the most damaging breaches originate. Get this right first.

Root Account

• [ ] Enable MFA on the root account. Use a hardware security key (YubiKey), not SMS. The root account can bypass every other control you set up.
• [ ] Don't use the root account for daily work. Create IAM users or use SSO. The root account should be used only for account-level operations (billing changes, closing the account).
• [ ] Set up a root account email alias that multiple trusted people can access. If the one person with root access leaves and you can't get in, you're locked out of your own infrastructure.
• [ ] Enable AWS CloudTrail to log root account activity. Alert on any root login.

IAM Users and Roles

• [ ] Enforce MFA for all IAM users with console access. No exceptions.
• [ ] Use IAM roles for applications, not long-lived access keys. EC2 instance profiles, ECS task roles, and Lambda execution roles should be how your services authenticate — not access keys hardcoded in environment variables.
• [ ] Apply least privilege. Every IAM policy should grant only the permissions the user or service actually needs. "Action": "*", "Resource": "*" should exist nowhere in your account.
• [ ] Delete unused access keys and users. Run aws iam generate-credential-report monthly. Any access key older than 90 days that hasn't been used should be deactivated and deleted.
• [ ] Use permission boundaries for delegated administration. If team leads can create IAM roles, boundaries prevent them from creating roles more powerful than their own.

AWS Organizations and Accounts

If you're past 10 engineers, consider AWS Organizations with separate accounts:

• Production account — Customer-facing workloads only
• Development account — Dev and staging environments
• Security/logging account — Centralized CloudTrail, Config, and GuardDuty findings

Account isolation is the strongest security boundary AWS offers. A compromised development credential can't touch production if they're in different accounts.

Networking: Keep the Blast Radius Small

VPC Configuration

• [ ] Production databases should not have public IPs. RDS, ElastiCache, and DynamoDB (VPC endpoints) should be in private subnets, accessible only from your application layer.
• [ ] Use security groups as allowlists, not blocklists. Every security group should start with zero inbound rules and add only what's needed. "Allow 0.0.0.0/0 on port 22" should not exist in production.
• [ ] Enable VPC flow logs on your production VPC. Ship them to CloudWatch or S3 with 90-day retention. Enterprise security reviews ask for this specifically.
• [ ] Use VPC endpoints for AWS services (S3, DynamoDB, Secrets Manager, STS). Traffic stays on the AWS backbone instead of traversing the public internet.

Load Balancers and Edge

• [ ] Terminate TLS at the load balancer with a certificate from ACM. TLS 1.2 minimum. Remove support for TLS 1.0 and 1.1.
• [ ] Use AWS WAF on your ALB or CloudFront distribution. At minimum, enable the AWS managed core rule set and the known bad inputs rule set. This blocks the most common web attacks (SQL injection, XSS) with zero configuration.
• [ ] Enable CloudFront access logs if you're using CloudFront. These become forensic evidence during incident investigations.

Encryption: What Enterprise Buyers Check

At Rest

• [ ] S3: Enable default encryption (SSE-S3 or SSE-KMS) on every bucket. Enable "Block Public Access" at the account level, not just per-bucket.
• [ ] RDS: Enable encryption at creation time (you can't add it to an existing unencrypted instance — you'd need to create an encrypted snapshot and restore). Use AWS-managed or customer-managed KMS keys.
• [ ] DynamoDB: Encryption at rest is enabled by default. Verify you haven't disabled it.
• [ ] EBS volumes: Enable default encryption for EBS in your account settings. All new volumes will be encrypted automatically.
• [ ] Secrets Manager or Parameter Store: Store all secrets here. Never in environment variables, .env files, or code. Rotate database credentials automatically using Secrets Manager's built-in rotation.

In Transit

• [ ] HTTPS everywhere. No HTTP endpoints in production. Redirect HTTP to HTTPS.
• [ ] Enforce HSTS with a minimum 1-year max-age.
• [ ] Internal service communication should also use TLS. "It's on a private network" is not sufficient for enterprise buyers — they want TLS between services too.

Key Management

• [ ] Use AWS KMS for key management. Customer-managed keys give you more control and better audit trails than AWS-managed keys.
• [ ] Enable key rotation on customer-managed KMS keys (automatic annual rotation).
• [ ] Restrict key policies so only specific IAM roles can use each key. Don't give every service access to every key.

Logging and Monitoring: Your Audit Trail

Enterprise buyers want to see that you can detect and investigate security events. This section is also the foundation of your incident response capability.

CloudTrail

• [ ] Enable CloudTrail in all regions. Not just the one you use. Attackers create resources in regions you're not watching.
• [ ] Enable CloudTrail log file integrity validation. This proves your logs haven't been tampered with.
• [ ] Ship CloudTrail logs to a separate account or S3 bucket with restrictive access. If an attacker compromises your production account, they shouldn't be able to delete your audit trail.
• [ ] Retain logs for at least 1 year. 90 days is a minimum for SOC 2; 1 year is what most enterprise buyers expect.

GuardDuty

• [ ] Enable GuardDuty. It's AWS's managed threat detection service. It costs pennies per GB of data analyzed and catches compromised credentials, cryptocurrency mining, unusual API calls, and other threats with zero configuration.
• [ ] Route GuardDuty findings to Slack, PagerDuty, or your alerting system via EventBridge. A finding nobody sees is a finding nobody investigates.

AWS Config

• [ ] Enable AWS Config with conformance packs for your compliance needs. Config continuously evaluates your resource configurations against rules — "all S3 buckets must have encryption enabled," "all security groups must not allow unrestricted SSH access."
• [ ] Use Config rules to detect drift from your security baseline. When someone manually opens a security group or disables encryption, you'll know.

CloudWatch Alarms

Set up alarms for:

• [ ] Root account login
• [ ] IAM policy changes
• [ ] Security group changes
• [ ] Network ACL changes
• [ ] CloudTrail configuration changes (someone trying to disable logging)
• [ ] S3 bucket policy changes
• [ ] Failed console login attempts (threshold: 5+ in 5 minutes)

S3: The Most Common Misconfiguration

S3 deserves its own section because S3 misconfigurations are the single most common finding in startup security reviews and penetration tests.

• [ ] Enable S3 Block Public Access at the account level. This prevents any bucket in the account from being made public, even accidentally.
• [ ] Audit existing bucket policies and ACLs. Run aws s3api get-bucket-acl and get-bucket-policy on every bucket. Look for principals that include "*" or "AWS": "*".
• [ ] Enable S3 access logging on buckets that store customer data. Ship logs to a separate logging bucket.
• [ ] Use S3 Object Lock for compliance-relevant data that must not be deleted (audit logs, compliance evidence).
• [ ] Enable versioning on buckets storing critical data. It's your defense against accidental deletion and ransomware.

The One-Day Sprint

If you have a security review next week and need to harden your AWS account fast, here's the priority order:

Hour 1–2: Identity

• Enable MFA on root and all IAM users
• Delete unused IAM users and access keys
• Review and tighten IAM policies

Hour 2–4: Data Protection

• Enable S3 Block Public Access at account level
• Verify encryption on all databases and storage
• Move any hardcoded secrets to Secrets Manager

Hour 4–6: Visibility

• Enable CloudTrail in all regions
• Enable GuardDuty
• Set up CloudWatch alarms for the critical events listed above
• Enable VPC flow logs

Hour 6–8: Documentation

• Document your AWS architecture (a simple diagram showing VPC, subnets, databases, and data flows)
• Write down your IAM approach (who has access to what and why)
• List your encryption configuration (what's encrypted, with what keys)

This won't pass a full SOC 2 audit, but it will get you through most enterprise security reviews and show that you're managing your cloud infrastructure deliberately.

Automating Compliance Checks

Once you have the baseline in place, automate the checking:

• AWS Security Hub aggregates findings from GuardDuty, Config, and other services into a single dashboard. Enable the CIS AWS Foundations Benchmark to get a compliance score.
• Infrastructure as Code (CloudFormation, CDK, Terraform) prevents configuration drift. If your security groups are defined in code, they can't be silently changed in the console.
• Compliance platforms (Vanta, Drata, Secureframe) integrate with AWS to continuously monitor your configuration against SOC 2 and ISO 27001 controls. They save you from manual evidence collection.

The Bottom Line

AWS gives you the tools to build a secure infrastructure. The problem is that none of them are enabled by default — and most startups don't enable them until an enterprise buyer asks why.

Fix that before the question comes up. The checklist above takes one day to implement and indefinitely protects you from the most common cloud security failures that lose enterprise deals.

Book a free discovery call — I'll run through your AWS configuration with you and flag the gaps that enterprise security reviewers will find.

— Sean, Founder at Wizbang