Engagements

How an engagement goes

These are illustrative scenarios — not real client engagements. We wrote them to show how we approach common situations; any artifacts referenced are from our own public reference work, never a client's environment.

Illustrative — not a real client

Reality-Check for a scaling fintech (illustrative)

This is an illustrative scenario — not a real client engagement. We wrote it to show how we approach a common situation; any artifacts shown are from our own public reference work, not a client’s environment.

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 (illustrative)

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.