What an infrastructure audit actually checks

When we assess an AWS estate, the work runs against a fixed catalogue of checks — 51 of them in the current version, grouped into twelve domains, versioned like the code they describe. This page publishes the catalogue in full.

Publishing it costs us nothing, because the list was never the hard part. Anyone can type “root MFA is enabled” into a spreadsheet. The work is in three places a list does not reach: collecting evidence that proves an answer rather than asserting it, being honest about what the evidence does not cover, and judging what a finding means for this estate rather than for estates in general. Each of those gets a section below the list.

If what you actually want is to take the list and run it against your own accounts: please do. That is why it is here.

The shape of a check

Each check is a small versioned document, not a spreadsheet row. Stripped to the parts that matter, one of them — the restore check — looks like this:

• What must be true. Restore has been tested, with evidence.
• Why. Untested backups are a hope, not a control.
• What proves it. A restore actually run: when, by whom, what came back, how long it took. A screenshot of the backup console proves a different, weaker claim.
• What moves it. For the production database this is high severity. For a sandbox nobody would bother rebuilding, it barely registers.

Three of those fields do the real work across the whole catalogue. Evidence: every check names what would prove it and where that comes from — an API read, a state file, or an interview answer, which is recorded as an interview answer and never dressed up as telemetry. Completeness: a check may pass on partial evidence only if the gap is stated; a quiet pass over the unexamined half of an estate is worth less than a loud “we could not see”. Context: the same finding carries different weight in a production account and a sandbox, and a list that scores both the same is noise.

The checklist

The severity shown is the default, before context moves it. The order within each domain is roughly the order the findings tend to matter.

Identity and access

• Root user MFA is enabled. Root without MFA is a single point of total account takeover. critical
• The root user has no access keys. Root access keys are almost never justified, and they bypass most other controls. critical
• Standing administrator access for humans is tightly controlled. Broad standing admin turns every laptop compromise into an estate compromise. high
• Workforce access uses IAM Identity Center, or equivalent federated SSO. Federated SSO with permission sets scales — and revokes access when people leave. high
• Deployment uses OIDC or equivalent short-lived federation, not long-lived keys. Long-lived CI keys are a common breach path, and they contradict review-before-apply discipline. high
• Long-lived IAM users are exceptional and reviewed. Standing IAM users accumulate stale keys and survive offboarding failures. high
• Unused or stale credentials are removed. Stale credentials outlive the people and workloads that needed them. medium

Account structure

• AWS Organizations is in use. Without it, guardrails, consolidated billing and account isolation cannot be applied consistently. high
• Production workloads are isolated from non-production. Shared accounts collapse blast radius and make least privilege and change control largely theoretical. critical
• Organisation guardrails exist for production. Account-level IAM alone cannot stop a compromised admin disabling logging or leaving regions unconstrained. high
• Every in-scope account has a named owner. Orphan accounts accumulate risk and block incident response. high
• Security and logging have dedicated accounts where scale warrants it. Central security and log accounts support investigation and retention a workload admin cannot override. medium

Terraform and state

• Infrastructure definitions are version-controlled. Without version control there is no review, no rollback and no handover. critical
• Material production resources are defined in code. Console-only estates cannot be reviewed, rebuilt or safely changed. high
• Terraform state uses a remote backend. Local state gets lost, duplicated and leaked. high
• Terraform state is encrypted at rest. State often contains secrets and resource identifiers. high
• Terraform state locking is enabled. Two applies racing on the same state corrupt estates and hide drift. high

The delivery pipeline

• There is one controlled path to change production infrastructure. Side-channel applies defeat review, logging and recovery. high
• Terraform plan runs on pull requests. Review without a plan is theatre. high
• Changes to infrastructure require review. Unreviewed mainline is how accidental and malicious changes ship. high
• Production apply requires an explicit approval gate. A change to production should end at a person, not at an automatic merge. critical
• CI does not hold long-lived cloud access keys. Static CI keys are exfiltrated from logs and forks regularly. high

Security baseline

• S3 public access is blocked by default. Public buckets remain a frequent cause of data leaks. critical
• Critical data stores encrypt at rest. Unencrypted critical data magnifies breach and loss impact. high
• Secrets are not stored in plaintext configuration. Plaintext secrets get copied into tickets, logs and backups. high
• GuardDuty is enabled. Runtime threat detection is a basic production expectation on AWS. high
• Security Hub is enabled in production accounts. Without a central findings plane, material misconfigurations stay local and untracked. medium

Network exposure

• Administrative ports are not open to the world. World-open admin ports are routinely scanned and exploited. critical
• Material public exposure is intentional and owned. Unplanned public exposure is a common breach path. high
• Production VPCs emit flow logs. Without them, network incident investigation is largely guesswork. medium

Audit logging

• CloudTrail is actively logging. A disabled trail is indistinguishable from no trail during an incident. critical
• Organisation-wide, or equivalent multi-account, CloudTrail exists. Per-account trails that nobody aggregates leave investigation gaps. high
• Audit logs are retained centrally for a defined period. Short local retention prevents forensics — and fails customer security questionnaires. high
• Audit coverage gaps are explicit. A pass that is quiet about what it could not see is not a pass. medium

Backups and restore

• Critical resources are covered by backups. Unbacked critical state is an existential risk for a SaaS business. critical
• Restore has been tested, with evidence. Untested backups are a hope, not a control. high
• Backup retention matches recovery needs. Seven-day defaults are often wrong for customer or regulatory expectations. medium
• Backup and restore ownership is named. Orphan backup plans fail silently. medium

Resilience

• Customer-facing compute has redundancy. Single-instance production web tiers fail loudly. high
• Critical data stores use Multi-AZ, or equivalent HA. A single-AZ critical database turns AZ impairment into a full outage. high
• Recovery objectives are written down. You cannot design backups or HA without stating what “recovered” means. medium

Observability

• Critical user journeys have alarms. Without alarms, customers become the monitoring system. high
• Alarm destinations reach an accountable owner. Alarms without owners create false confidence. medium
• Application logs have defined retention. Missing retention either burns cost or deletes evidence before an investigation finishes. low

Operations

• Services have named owners. Unowned services do not get patched, backed up or incident-managed. high
• Critical operational paths have runbooks. Tribal knowledge evaporates on holiday and at hiring transitions. medium
• Architecture documentation exists and is roughly current. Diligence, handover and incident response all need a shared map. medium
• Material operational decisions are recorded. Without decision records, the next engineer re-litigates or undoes deliberate trade-offs. low

Cost

• A cost-allocation tagging baseline exists. Untagged estates cannot attribute spend or ownership. medium
• Spend has budgets or anomaly alerts. Silent spend growth is a common Series A surprise. low
• Idle or obviously wasted resources are reviewed. Unowned environments accumulate cost without product value. info

What the list will not do on its own

It will be answered instead of evidenced. Run as a meeting agenda, every item above collects a confident yes. Most of the value of an assessment is the distance between “we believe backups run” and a restore log with timings in it — and that distance only shows up when each answer has to arrive with the thing that proves it.

It will be quiet about coverage. A checklist result rarely says which accounts, regions and resources were actually examined. Ours is required to: one of the checks above exists purely to force that statement. An estate that scores well across a third of itself has not scored well.

It will score a sandbox like production. Severity without context produces reports where an open port on a demo box outranks a production database nobody can restore. Every check in the catalogue carries modifiers — production raises it, sandbox caps it — so the ranked findings are a to-do list rather than a word cloud.

Run it yourself

An afternoon with this page, the AWS CLI and your Terraform repositories covers a good share of the catalogue, and the gaps you find are yours to fix in whatever order you like. The catalogue is versioned; this page describes v0.1 and will say so when that changes.

Where it stops being a self-serve job is usually one of three things: nobody has the afternoon; the answers need to arrive as evidence a customer’s security review or an investor’s diligence will accept; or the fixes themselves are the point and need to land as reviewed changes in your repository rather than as a report. That is the shape of the work we sell — and if an afternoon with the list is all you needed, the list has done its job.