The AWS Security Checklist Every Startup Should Run Before It Scales

Most startups don't have a security gap because nobody cares. They have one because nobody had a spare afternoon. Shipping features and closing customers wins out over reviewing IAM policies almost every time, until something forces the issue.

This is the checklist we run at the start of every AWS Startup Security Baseline sprint, before we touch anything else. It takes about twenty minutes to run yourself, and it catches most of what actually causes problems later.

1. Root account and MFA

Start here because root access can do anything. Log into the AWS account as root exactly once, just to check two things: is MFA turned on, and when was root last used for something other than confirming it exists?

• If MFA is off on root, turn it on today. Not this sprint, today.
• If root has been used recently for day-to-day work, that's a sign your team is relying on it instead of scoped IAM users or roles.
• Check whether anyone besides the original account owner knows the root credentials exist, let alone has access to them.

2. IAM users and roles

Pull up your full list of IAM users and roles. In most growing AWS accounts, this list is longer than anyone expects, and a chunk of it shouldn't exist anymore.

• Look for users tied to former contractors or employees who no longer need access.
• Look for policies using a wildcard resource or action where a specific one would work. Wildcards are usually there because someone was in a hurry, not because the access is actually needed.
• Check access key age. A key that's been active for over a year and never rotated is a common finding.

3. CloudTrail coverage

CloudTrail usually looks fine in the account and region someone checks most often. The gaps show up in the regions and accounts nobody thinks about.

• Confirm CloudTrail is enabled account-wide, not just in one region.
• If you run multiple AWS accounts, check each one individually. A logging setup that only covers your primary account leaves the rest dark.
• Verify log file validation is on and that logs are actually going somewhere you'd notice if they stopped.

4. S3 public access

Public S3 buckets are one of the most common causes of real, public incidents, and one of the easiest things to check.

• Use S3 Block Public Access at the account level unless you have a specific, intentional reason not to.
• Check every bucket individually for public read or write access, including buckets that were only ever meant to be temporary.
• Confirm encryption at rest is enabled, and check whether sensitive data is sitting in a bucket with no encryption at all.

5. Backup existence and testing

Backups being configured and backups actually working are two different things. The second one only gets confirmed by testing a restore.

• Confirm automated backups are actually running for your production databases and critical storage.
• Check when a restore was last tested. If the honest answer is never, that's the finding.
• Make sure someone besides you knows where backups live and how to restore from them.

If you run through this and find more than a couple of gaps, that's normal, not alarming. It's also usually the point where a fixed-scope sprint is faster than trying to fix everything piecemeal between other work. The AWS Startup Security Baseline sprint covers all five of these areas in a fixed 7 to 14 day engagement, with two live working sessions where we fix what we can together instead of just handing you a list.