The Infrastructure Audit Checklist

An infrastructure audit should not be a slide deck of vague “best practices.” Done well, it gives you clarity and sequencing: what’s risky right now, what’s wasting money, what will break at the next scale step, and what to do first.

This is the high-level checklist we use to assess cloud infrastructure, security posture, and operational practices for teams running real production workloads.

What a good audit answers

An audit should tell you, clearly:

• What’s risky right now (and why)
• What’s wasting money
• What will break at the next scale step
• What to do first, second, and third (with owners and effort estimates)

What you should get as deliverables

Even for a lightweight audit, expect:

• A prioritized backlog (quick wins + strategic work)
• A risk register (severity, likelihood, blast radius)
• Cost opportunities (by service, environment, and category)
• A practical “next 30/60/90 days” implementation plan

If you can’t act on the output, it’s not an audit—it’s research.

The checklist (high level)

• Identity & access: SSO, least privilege, break-glass, audit trails
• Network boundaries: segmentation, ingress/egress controls, firewall policy hygiene
• Data protection: encryption, key management, backups and restore testing
• Runtime & supply chain: images, SBOMs, scanning, secrets management
• Observability: SLOs, logging, alerting, on-call, incident response
• Cost: right-sizing, idle spend, reserved capacity, storage lifecycle

The checklist (expanded)

1) Identity & access (IAM)

The fastest way to reduce cloud risk is to fix identity.

• SSO + MFA for cloud consoles and critical SaaS
• Role-based access with least privilege (no “admin for everyone”)
• Break-glass access: a controlled emergency path with strong logging
• Offboarding: revoke access reliably across cloud + SaaS + Git
• Service-to-service identity: avoid shared static credentials
• Audit trails: centralized logs for authentication and policy changes

2) Network boundaries

Network controls won’t save you from everything, but lack of boundaries increases blast radius.

• Segmentation between prod, staging, and dev
• Ingress/egress controls (what can talk to what, and why)
• Public exposure inventory (load balancers, gateways, open ports)
• Firewall/WAF policy hygiene (no stale allowlists)

3) Data protection and recovery

Backups are only real if restore is tested.

• Encryption at rest and in transit
• Key management (ownership, rotation, access controls)
• Backup strategy (RPO/RTO expectations)
• Restore testing (schedule and evidence)
• Data retention and deletion (especially for regulated data)

4) Runtime, containers, and supply chain

This is where operational and security failures often meet.

• Base image hygiene and patch cadence
• Image scanning with owners (not “scan and ignore”)
• Secrets management (no secrets in repos, images, or logs)
• Artifact integrity (build once, promote; no “mystery rebuilds”)
• SBOM/provenance approach that fits your stage

5) Observability and incident readiness

The goal is fast detection and recovery—not dashboards for their own sake.

• Clear health signals for customer-critical flows
• SLOs (or at least “golden signals” and error budget thinking)
• Alert quality (actionable, owned, and non-noisy)
• On-call rotations and escalation paths (even if lightweight)
• Incident docs, timelines, and postmortems

6) Change management and delivery

Audit for how changes reach production.

• CI/CD reliability, rollback, and environment protections
• Infrastructure-as-code coverage and review practices
• Release safety (feature flags, progressive delivery, canaries where appropriate)
• “Who can deploy what” access model

7) Cost and capacity

Cost problems are usually governance problems.

• Right-sizing compute (requests/limits for Kubernetes, instance sizes for VMs)
• Idle spend (unused environments, orphaned volumes, forgotten snapshots)
• Storage lifecycle policies (hot vs cold, retention limits)
• Commitment strategy (reserved instances/savings plans where appropriate)
• Unit economics: cost per customer / per request / per environment

Common findings (patterns we see repeatedly)

• Overly broad IAM roles and shared credentials
• No tested restore process
• Too much spend in non-prod and logging/metrics retention
• CI/CD with fragile rollbacks and inconsistent environments
• Alerting that pages people for things they can’t fix

When to run an audit (and how often)

Good trigger points:

• Before enterprise sales (security and compliance expectations rise fast)
• After a major migration or architecture change
• When incidents or spend start trending upward
• When you’re scaling the team and need consistent standards

For many teams, a lighter “health check” quarterly and a deeper audit annually is plenty.

If you want a structured review with prioritized recommendations, see Infrastructure Audit.