An infrastructure audit identifies gaps before they become incidents. This checklist covers 30 audit points across five domains: security, performance, cost, reliability, and compliance. Each point includes what to check, how to check it, what "good" looks like, and remediation priority. Run this audit quarterly to maintain infrastructure health.
Based on analysis of 500+ infrastructure audits conducted by cloud consultancies in 2025-2026, the average organization fails 12 of these 30 checks on their first audit. Organizations that run quarterly audits reduce their failure count to 3-4 within a year. Each unresolved audit finding increases the probability of a production incident by 8%.
---
Scoring System
| Score | Rating | Action |
| 27-30 | Excellent | Maintain current practices |
| 22-26 | Good | Address gaps in next quarter |
| 16-21 | Fair | Prioritize remediation this month |
| 11-15 | Poor | Immediate action required |
| 0-10 | Critical | Stop feature work, fix infrastructure |
---
Security (10 Points)
1. TLS Configuration
Check: All public endpoints use TLS 1.2+ with strong cipher suites.
<h1>Verify TLS version and ciphers</h1>
nmap --script ssl-enum-ciphers -p 443 your-app.example.com
<h1>Pass: TLS 1.2 and 1.3 only, no weak ciphers</h1>
<h1>Fail: TLS 1.0/1.1 enabled, RC4 or DES ciphers</h1>
Pass/Fail: Pass = TLS 1.2+ only. Fail = any TLS 1.0/1.1.
2. SSH Hardening
Check: Password authentication disabled, root login disabled, non-standard port optional.
<h1>Check SSH configuration</h1>
grep -E "^(PasswordAuthentication
PermitRootLogin
PubkeyAuthentication)" /etc/ssh/sshd_config
<h1>Expected:</h1>
<h1>PasswordAuthentication no</h1>
<h1>PermitRootLogin no</h1>
<h1>PubkeyAuthentication yes</h1>
Pass/Fail: Pass = key-only auth, no root. Fail = password auth or root login enabled.
3. Firewall Rules
Check: Only required ports open. No 0.0.0.0/0 access except 80/443.
<h1>List open ports</h1>
sudo ufw status verbose
<h1>or</h1>
sudo iptables -L -n
<h1>Pass: Only 80, 443, and SSH (restricted IP) open</h1>
<h1>Fail: Database ports (5432, 3306), Redis (6379) open to internet</h1>
Pass/Fail: Pass = minimal open ports. Fail = database/cache ports publicly accessible.
4. Secrets Management
Check: No secrets in code, environment files, or Docker images.
<h1>Scan for secrets in codebase</h1>
trufflehog filesystem --directory . --only-verified
<h1>or</h1>
gitleaks detect --source .
<h1>Pass: No verified secrets found</h1>
<h1>Fail: API keys, passwords, or tokens in code/config</h1>
Pass/Fail: Pass = zero secrets in code. Fail = any verified secret.
5. Vulnerability Scanning
Check: Container images and OS packages scanned, no critical/high unpatched.
<h1>Scan container image</h1>
trivy image --severity HIGH,CRITICAL your-app:production
<h1>Pass: 0 critical, < 5 high (all with documented exceptions)</h1>
<h1>Fail: Any critical vulnerability without remediation plan</h1>
Pass/Fail: Pass = no critical vulns. Fail = critical vulns without remediation.
6. Access Control
Check: MFA enabled for all users, least-privilege RBAC, quarterly access reviews.
Pass/Fail: Pass = 100% MFA, documented RBAC. Fail = any user without MFA.
7. Audit Logging
Check: All administrative actions logged with user, action, timestamp, and resource.
Pass/Fail: Pass = comprehensive audit trail, 1+ year retention. Fail = gaps in logging.
8. Network Segmentation
Check: Database and cache not directly accessible from internet. Application server is the only ingress point.
Pass/Fail: Pass = database/cache on private network. Fail = direct internet access.
9. Dependency Updates
Check: Application dependencies updated within 30 days of security patches.
<h1>Check for outdated packages</h1>
npm audit # Node.js
pip-audit # Python
<h1>Pass: No high/critical vulnerabilities in dependencies</h1>
<h1>Fail: Known vulnerabilities unpatched for 30+ days</h1>
Pass/Fail: Pass = no known critical/high vulns. Fail = unpatched for 30+ days.
10. Incident Response Plan
Check: Documented incident response plan, tested within last 6 months.
Pass/Fail: Pass = documented and tested. Fail = no plan or untested.
---
Performance (6 Points)
11. Response Time
Check: API p95 response time under 500ms.
| Metric | Good | Acceptable | Poor |
| p50 | < 100ms | < 200ms | > 200ms |
| p95 | < 500ms | < 1000ms | > 1000ms |
| p99 | < 1000ms | < 3000ms | > 3000ms |
Pass/Fail: Pass = p95 < 500ms. Fail = p95 > 1000ms.
12. Database Query Performance
Check: No queries with mean execution time > 1 second.
SELECT query, mean_exec_time, calls
FROM pg_stat_statements
WHERE mean_exec_time > 1000
ORDER BY mean_exec_time DESC;
-- Pass: 0 rows returned
-- Fail: Any query averaging > 1 second
Pass/Fail: Pass = no slow queries. Fail = queries averaging > 1s.
13. Resource Utilization
Check: CPU and memory utilization between 30-70% during normal operations.
Pass/Fail: Pass = 30-70%. Fail = < 20% (over-provisioned) or > 85% (under-provisioned).
14. Connection Pooling
Check: Database connection pooling configured with appropriate limits.
Pass/Fail: Pass = pooling configured. Fail = no pooling or connections at max.
15. Caching Effectiveness
Check: Cache hit rate above 70% for read-heavy endpoints.
Pass/Fail: Pass = > 70% hit rate. Fail = < 50% or no caching.
16. Load Testing
Check: Load tests run within the last 30 days with documented results.
Pass/Fail: Pass = recent test with baselines. Fail = no load testing.
---
Cost Efficiency (5 Points)
17. Right-Sizing
Check: No instances consistently below 30% CPU utilization.
Pass/Fail: Pass = all instances appropriately sized. Fail = wasted capacity.
18. Unused Resources
Check: No orphaned volumes, unattached IPs, or stopped instances running for 30+ days.
<h1>Check for orphaned resources (provider-specific)</h1>
<h1>Look for: unattached storage volumes, unused elastic IPs,</h1>
<h1>stopped instances, old snapshots, unused load balancers</h1>
Pass/Fail: Pass = no orphaned resources. Fail = unused resources costing money.
19. Data Transfer Costs
Check: Cross-region and internet egress costs reviewed and minimized.
Pass/Fail: Pass = data transfer optimized. Fail = unnecessary cross-region traffic.
20. Reserved Capacity
Check: Stable workloads on reserved/committed pricing.
Pass/Fail: Pass = committed pricing for predictable workloads. Fail = all on-demand.
21. Cost Monitoring
Check: Budget alerts configured with monthly review process.
Pass/Fail: Pass = alerts + review. Fail = no cost monitoring.
See Pricing for Arxentra cost optimization options.
---
Reliability (5 Points)
22. Backup Verification
Check: Automated backups with monthly restore testing.
Pass/Fail: Pass = automated + tested. Fail = untested or manual backups.
23. High Availability
Check: No single points of failure for critical services.
Pass/Fail: Pass = redundancy for all critical paths. Fail = SPOF exists.
24. Monitoring and Alerting
Check: Health checks, uptime monitoring, and alerting for all production services.
<h1>Minimum monitoring requirements</h1>
monitoring:
uptime_check: every_60_seconds
health_endpoint: /api/health
alerts:
- service_down: immediate (PagerDuty/Slack)
- high_error_rate: within_5_minutes
- high_cpu: within_15_minutes
- disk_90_percent: within_1_hour
- ssl_expiry: 30_days_before
Pass/Fail: Pass = comprehensive monitoring. Fail = gaps in coverage.
25. Disaster Recovery
Check: DR plan documented with RTO and RPO targets.
Pass/Fail: Pass = documented DR with tested recovery. Fail = no DR plan.
26. Auto-Recovery
Check: Services automatically restart on failure.
Pass/Fail: Pass = auto-restart configured. Fail = manual intervention required.
---
Compliance (4 Points)
27. Data Classification
Check: All data classified (public, internal, confidential, restricted).
Pass/Fail: Pass = classification scheme applied. Fail = no classification.
28. Data Retention
Check: Retention policies defined and enforced for all data types.
Pass/Fail: Pass = automated retention enforcement. Fail = data kept indefinitely.
29. Regulatory Compliance
Check: Infrastructure meets applicable regulatory requirements (GDPR, SOC 2, HIPAA, etc.).
Pass/Fail: Pass = controls verified. Fail = gaps identified.
30. Documentation
Check: Architecture diagrams, runbooks, and operational procedures current (updated within 90 days).
Pass/Fail: Pass = documentation current. Fail = outdated or missing docs.
For compliance-ready infrastructure, see Services Overview.
---
Audit Results Template
<h1>infrastructure-audit-results.yaml</h1>
audit_date: 2026-03-15
auditor: your-name
environment: production
results:
security: 8/10 # Points passed
performance: 5/6
cost: 3/5
reliability: 4/5
compliance: 3/4
total: 23/30 # Rating: Good
critical_findings:
- id: SEC-4
finding: "AWS access key found in .env.production"
priority: P0
remediation: "Rotate key, move to secrets manager"
deadline: 2026-03-17
- id: REL-22
finding: "Database backups never tested"
priority: P1
remediation: "Schedule monthly restore drill"
deadline: 2026-03-22
next_audit: 2026-06-15
---
Frequently Asked Questions
How often should I run an infrastructure audit?
Quarterly for a full 30-point audit. Monthly for a lightweight check of the top 10 critical items (security controls, backups, monitoring). After any major infrastructure change, run the relevant section of the audit.
Who should perform the audit?
Ideally, someone who did not build the infrastructure. A peer review catches blind spots. For small teams, rotate the auditor role each quarter. For critical infrastructure, consider an annual external audit from a cloud security firm.
What is the most commonly failed audit point?
Backup verification (point 22). Teams set up automated backups but never test the restore process. The second most common failure is secrets management (point 4), where credentials are found in code repositories or configuration files. Read Documentation for backup testing procedures.
How do I prioritize audit findings?
Use a P0-P3 system. P0: security vulnerability actively exploitable (fix within 24 hours). P1: security gap or reliability risk (fix within 1 week). P2: performance or cost issue (fix within 1 month). P3: best practice improvement (fix within 1 quarter).
Can I automate this entire audit?
Approximately 70% of these checks can be automated with scripts. Security scanning, TLS verification, resource utilization, and cost monitoring are fully automatable. Documentation currency, DR plan testing, and access reviews require human judgment. Build a script that runs the automatable checks and generates a report for the manual items. Contact Arxentra for infrastructure audit tooling recommendations.
What score should I target?
Aim for 25+ on your first audit and 27+ after two quarters of remediation. A score of 30/30 is ideal but rare in practice. The most important thing is improving your score each quarter, not achieving perfection immediately. Track your score over time and celebrate improvement.