Methodology — how I work.
A repeatable four-step method behind every engagement, and the editorial standards behind everything published on this site.
A repeatable method, not improvisation
Every engagement runs the same four-step method so outcomes are predictable and evidence is defensible.
1. Diagnose
- Assess the AWS environment against your target framework
- Produce a prioritised control-gap register
- Give a go/no-go readiness verdict, not a vague opinion
2. Architect
- Design the fix as code — Terraform, GitOps, policy gates
- Map every control to the framework requirement it satisfies
- Choose boring, proven solutions over complexity
3. Harden
- Implement controls in the account: IAM, KMS, logging, change control
- Automate evidence collection on every change
- Remediate drift on a defined SLA
4. Attest
- Prepare organised evidence and liaise with your auditor/QSA
- Support the observation window through to a clean report
- Hand over documentation your team can run
How the content on this site is written
Everything published here is written from first-hand engagement experience by a named, credentialed author (see About). Technical and compliance claims reference specific frameworks, control IDs and named tools rather than generic marketing language. I do not publish scaled, AI-generated pages without editorial review.
Accuracy: compliance guidance reflects the frameworks as I apply them in real audits; I never claim an outcome I can't defend to a CISO or an assessor. Corrections: if something here is out of date or wrong, email hi@sahildubey.us and I'll fix it and note the update. Confidentiality: client examples are anonymised and used only within NDA terms.