Direct answer
An infrastructure audit checklist is a preparation tool for defining scope, collecting evidence, and testing whether infrastructure controls work as intended. A useful checklist covers assets, identity, networks, configuration, observability, resilience, performance, cost, and ownership without treating every environment as identical.
1. Define scope and ownership
Start with business services and workloads, not a raw resource export. The audit boundary should identify which production systems, environments, cloud accounts, regions, data stores, third parties, and supporting platforms are included.
- Name the executive sponsor, technical owner, security owner, and evidence coordinator.
- List in-scope workloads, environments, accounts, subscriptions, projects, regions, and on-premises dependencies.
- Document business criticality, data classification, recovery objectives, and regulatory constraints.
- Record explicit exclusions and the reason each item is out of scope.
- Agree how production access, sensitive evidence, and exported configuration data will be handled.
2. Build an asset and dependency inventory
An inventory is useful only when it connects resources to owners, workloads, data, and dependencies. Compare declared inventories with provider APIs, infrastructure-as-code state, DNS, certificates, container registries, and monitoring sources to identify drift or orphaned assets.
- Compute, storage, databases, queues, serverless functions, clusters, and managed services.
- Public endpoints, DNS zones, certificates, load balancers, gateways, and egress paths.
- Repositories, CI/CD systems, registries, deployment identities, and infrastructure modules.
- Data flows between internal systems, cloud providers, SaaS vendors, and customer environments.
- Resource ownership, environment classification, lifecycle status, and deletion policy.
3. Review identity, secrets, and privilege
- Inventory human, workload, service, third-party, and emergency-access identities.
- Identify standing administrative access, dormant credentials, shared accounts, and long-lived keys.
- Review federation, multi-factor authentication, workload identity, and privileged approval paths.
- Trace role-assumption chains and permissions that cross accounts, projects, subscriptions, or tenants.
- Check secret storage, rotation, access logging, repository scanning, and break-glass controls.
Evidence should show both policy and deployed state. A written least-privilege standard does not prove that current identities follow it.
4. Review network design and external exposure
- Map internet-facing services, administrative endpoints, private connectivity, and egress routes.
- Review segmentation boundaries, security groups, firewall rules, service-to-service policy, and default routes.
- Confirm TLS configuration, certificate ownership, renewal processes, and internal encryption requirements.
- Trace exposure from public entry points to sensitive services and data stores.
- Verify that temporary access paths and migration rules have an owner and expiry condition.
5. Test configuration and change governance
- Compare deployed resources with approved baselines and infrastructure-as-code definitions.
- Review code review, deployment approval, policy-as-code, rollback, and emergency-change procedures.
- Check operating-system, container, dependency, and managed-service patch responsibilities.
- Identify unsupported versions, unmanaged exceptions, configuration drift, and unowned resources.
- Confirm that high-impact control changes create reviewable evidence.
6. Evaluate operations, resilience, performance, and cost
- Review monitoring coverage, alert ownership, escalation paths, incident runbooks, and post-incident actions.
- Inspect backup scope, restore evidence, failover design, dependency recovery order, and recovery testing.
- Compare resource sizing and scaling policy with actual utilization, latency, throughput, and demand patterns.
- Identify idle resources, duplicate tooling, unused commitments, expensive data movement, and unclear cost allocation.
- Confirm that reliability, performance, and cost tradeoffs are tied to business requirements.
7. Require decision-ready deliverables
- A current-state architecture and dependency view.
- A findings register with evidence, affected assets, business context, and accountable owners.
- A prioritized remediation roadmap with immediate containment, planned fixes, dependencies, and validation criteria.
- A record of accepted risks, scope limitations, and evidence that could not be obtained.
- An executive summary that distinguishes urgent exposure from longer-term architecture improvement.
Common questions
What is an infrastructure audit?
An infrastructure audit is a structured review of the cloud accounts, networks, identities, configurations, operational controls, and dependencies that support a workload. It documents the current state, identifies material risks and inefficiencies, and turns the findings into an ordered remediation plan.
What evidence is needed for an infrastructure audit?
The evidence depends on scope, but usually includes architecture diagrams, asset inventories, cloud account structure, identity and access policies, network configurations, logging coverage, backup and recovery procedures, infrastructure-as-code repositories, incident runbooks, and recent cost or performance data.
Does an infrastructure audit provide a compliance certification?
No. Vereonix can map observations to relevant control frameworks and identify evidence gaps, but an infrastructure audit is not an independent certification, attestation, or legal determination. Formal certification must be completed by the appropriately qualified assessor for the applicable framework.
Reference frameworks
Audit criteria should be selected for the workload and obligation in scope. These primary sources provide useful control and architecture references; they do not certify a Vereonix engagement.