Illustrative example
What a Health Check report looks like
This is the shape of the written report you receive. The company, findings and structure below are fictional and simplified. They are not taken from a real client.
1. Summary
Example company: a fictional B2B software firm running one production AWS account, a managed Kubernetes cluster and a hosted CI system. The review was read-only. Findings are ranked by risk and by the effort to fix them.
Fix first
High risk, low effort: access keys (F1).
Plan next
High risk, medium effort: restore testing (F2).
Schedule
Drift, paging and cost controls (F3 to F5).
2. Findings ranked by risk and effort
- F1 Risk: High Effort: Low Access and identity
Long-lived access keys in pipeline settings
Deployment credentials are stored as static keys in the CI settings, shared across repositories and not rotated.
Recommended fix: Replace with short-lived federated credentials per pipeline. Remove the old keys after one clean release.
- F2 Risk: High Effort: Medium Reliability and recovery
Backups exist but have never been restored
Database snapshots are taken nightly. No restore has been tested, so the real recovery time is unknown.
Recommended fix: Run a timed restore into an isolated account, record the result and schedule it quarterly.
- F3 Risk: Medium Effort: Medium Infrastructure as code
Console changes have drifted from the code
Part of the network and several security groups were edited by hand and no longer match the repository.
Recommended fix: Import drifted resources, add a scheduled drift report and restrict console write access.
- F4 Risk: Medium Effort: Low Observability
Alerts reach a shared channel, not a person
Paging alerts post to a chat channel with no rota, so nobody is clearly responsible out of hours.
Recommended fix: Define a rota, route only actionable alerts to the pager and delete the noisy ones.
- F5 Risk: Low Effort: Low Cloud cost
No budgets or anomaly alerts
Spend is reviewed monthly after the fact and there are no budget thresholds.
Recommended fix: Add budgets per account and a cost anomaly alert to the engineering channel.
3. The 30, 60 and 90 day roadmap
Days 1 to 30
- Replace long-lived keys (F1)
- Define the on-call rota and clean up alerts (F4)
- Add budgets and anomaly alerts (F5)
Days 31 to 60
- Run and record a timed restore (F2)
- Import drifted resources (F3)
Days 61 to 90
- Schedule drift and restore checks
- Review results at a follow-up call
4. What else is in a real report
- A current-state architecture diagram of your own environment.
- A security baseline mapped to recognised benchmarks such as the CIS benchmarks.
- A readout call with your engineering leads.
- An optional scoped proposal for any work you want help with. The report is yours either way.
This page is an illustration of format only. Your report reflects your own environment and the scope agreed in writing.
Book a working session