Walkthroughs

How an engagement runs

How we scope, what we ship, and what you own at the end — walkthroughs of two common situations. The scenarios are illustrative; the method is the one every engagement runs.

Illustrative — not a real client

Reality-Check for a scaling fintech

Context

A scaling fintech had grown its AWS footprint fast and bolted on a CSPM tool to keep up. The tool now produced several hundred “High” and “Critical” findings. The security lead could not answer the board’s question — are we actually exposed? — because the list was sorted by severity, not by anything an attacker could use.

Constraints

A fixed two-week window; no appetite for an open-ended “assessment.”
Read-only access only, via a role the client created and could revoke.
Production accounts; no changes without review.

What we shipped

We took the existing findings and overlaid the data the scanner ignored: which resources were reachable from an untrusted entry point, which IAM roles those resources carried, and what those roles could reach next. That turned a flat list into a small set of concrete attack paths.

Most of the “criticals” were unreachable and dropped to a backlog. A handful of Medium-rated findings — an SSRF-prone service with a broad instance role, a public bucket fronting an internal dataset — turned out to be the first hops of real paths, and moved to the top. For the top-ranked paths we wrote Terraform pull requests that tightened the IAM, removed the public exposure, and closed the logging gaps, ready to merge in the client’s own repo.

What the client owns

A prioritized exposure register tied to attack paths, not scanner scores.
A threat model of the reviewed environment.
Terraform PRs that remediate the top paths, in their repo.
A ranked backlog for the rest, written so their team can execute it.

Outcome

The security lead could finally describe exposure as a short list of paths the team understood, with fixes already written for the worst. The engagement surfaced enough structural work (account guardrails, identity baselines) that the client moved on to a landing-zone engagement next — the cost of the Reality-Check rolled into it.

Illustrative — not a real client

Landing zone for a scaling SaaS

Context

A SaaS company had started in a single AWS account and grown inside it. New teams negotiated security from scratch, much of it clicked in by hand. They were about to onboard several new engineering teams and knew the single-account model would not survive it — but they were wary of a consultant building a bespoke platform they could never maintain.

Constraints

A real foundation needed before the next hiring wave; a fixed, predictable scope.
It had to be plain Terraform on standard tooling — no proprietary abstraction.
Existing workloads could not be disrupted during the migration.

What we shipped

We designed a multi-account structure with an account-vending pattern: a Terraform module that stamps out a new account already inside the org’s guardrails, with baseline roles, logging, and network scaffolding applied automatically. Service Control Policies enforced the non-negotiables. Identity was federated through the client’s existing IdP with least-privilege baseline roles. Everything landed as reviewable pull requests against the client’s CI, so their team absorbed it as it went in rather than receiving a black box.

The handover was not a presentation. We sat with their engineers while they vended a fresh account from the repo, changed a guardrail, and ran the break-glass path — and then we left.

What the client owns

A Terraform monorepo for the org/account structure, in their version control.
An account-vending module their team runs to create new accounts.
A guardrail set (SCPs) they can read, change, and PR.
Centralized logging and audit, as code, plus runbooks and ADRs.

Outcome

New teams now land in accounts that are secure and auditable by default, and the client’s own engineers create them without calling anyone. The foundation is boring, standard, and theirs — which was the entire point.