How we approach a security review
A structured review of access, network configuration, and data handling — assessed systematically rather than by checking a few obvious things and calling it done.
The situation
An AWS account set up early by a small team, and never formally reviewed since. A new customer contract had introduced a compliance requirement, and nobody could say with confidence what state the account was actually in.
What we did
A structured review of the account against a recognized security baseline — identity and access, network configuration, encryption, and logging — with every finding ranked by risk rather than fixed in the order they were found.
What we typically find
- Root account credentials still in active use, without the additional protections a root account warrants.
- Broad network access rules left open from an earlier debugging session and never closed.
- Database credentials or API keys stored in application configuration rather than a dedicated secrets service.
- Access keys still active for people who no longer work on the account.
- No centralized logging, so a question about what happened on the account cannot be answered after the fact.
What we changed
Credentials and access narrowed to what each role actually needs. Secrets moved into a managed service with rotation enabled. Logging extended across the account so activity is visible and auditable going forward.
Result
A documented, current picture of the account's security posture, with the highest-risk issues closed first and a clear plan for the rest.
- IAM
- Secrets Manager
- CloudTrail
- GuardDuty
- VPC
These describe our approach to each type of engagement, illustrated by the kind of situation and findings we see repeatedly. They are not attributed to a named client.