Three Security Engineers, Forty Microservices, Eleven Weeks to Launch

Diagnosis. Three people cannot author 40 threat models, and if they try, the output will be the 40-page document that nobody reads. The only scalable model is squads authoring and security facilitating and sampling. The 60% design-level finding also proves the current review happens too late to change anything cheaply, so the workflow must attach to the decision point, not the delivery point.

Squad owns:

• A short threat-model record (target: one page, or a 60–90 minute session) for any change that crosses a trust boundary, introduces a new data store, adds an external integration, or touches cardholder data or money movement.
• A structured prompt set supplied by security - not a blank page. Question-based framing works better than a taxonomy lecture: what data crosses this boundary, who can call it, what happens if it is called by the wrong principal, what is the blast radius if this credential leaks.
• Disposition of each identified threat: mitigate, accept, transfer, with a named risk owner and a Jira ticket. An unowned risk is not a decision.

Security owns:

• The template, the trigger rules, and the facilitation of high-risk sessions.
• Sampling: review a defined percentage of squad-authored models and all models touching PAN or money movement.
• The risk register and the exceptions process, including expiry dates.

Exit criteria to leave plan: threat model recorded and linked to the epic; every threat has a disposition and an owner; any accepted risk has a dated sign-off; relevant ADRs written. Wire it into the Jira "definition of ready" so it is a gate on the ticket, not a separate ceremony.

Risk to manage: making the template mandatory and heavy recreates the ignored document. Keep it to one page and audit for evidence of real decisions, not completed fields.

Prioritisation logic. Rank by expected loss, not by service count. Four factors, scored simply:

1. Data sensitivity - does the service touch PAN, SAD, balances, or identity credentials?
2. Exposure - internet-facing, partner-facing, or internal only.
3. Change magnitude - is it being rewritten, or is it stable?
4. Prior findings - has it produced penetration-test or incident findings before?

That produces three tiers. Tier 1 (probably 6–8 services): full facilitated model, security in the room. Tier 2: squad-authored with mandatory security review. Tier 3: template only, plus a periodic sample. The point of the tiers is not to skip work on Tier 3 - it is to spend three people's attention where a design flaw is expensive.

The stored value account (11 weeks).

• Week 1: facilitated session on the four services plus the ledger table - not the whole platform. Scope to what changes: the new trust boundaries, who can debit and credit, how idempotency and reconciliation work, what happens on partial failure, how the ledger is authorised.
• Week 2: threats dispositioned, mitigations in the backlog before the sprint that builds them, risk register updated, ADR for the ledger access model.
• Weeks 3–10: security reviews the mitigations at design and code, and the pen test is scoped to the new surface rather than a repeat of the whole platform.
• Week 11: evidence pack handed to the assessor.

Explicit trade-off to state to the head of security: the other 36 services get no new modelling this quarter. Name that as accepted risk with an owner and a date, rather than letting it be discovered later.

Artifacts to retain per change:

• Dated threat-model record with participants and scope (which services, which boundaries).
• The threat list with each disposition, the named risk owner, and the linked mitigation tickets - including their closure state at release.
• Accepted-risk sign-offs with the accountable name, rationale, compensating controls and an expiry date.
• The ADR covering the security-relevant decision (authorisation model, credential scope, ledger access).
• Evidence that the review preceded build: ticket timestamps showing the model was completed before the first implementation commit.

Tie these to the epic so retrieval is one query, not a shared-drive archaeology exercise. The assessor is looking for evidence of a decision process, so the timestamps matter as much as the content.

The failure mode: documentation theatre. A one-page template invites one-line answers, and "we considered injection - mitigated" becomes a field to fill rather than a decision to make. The process then produces perfect evidence of a process that changed nothing, which is worse than no process because it creates false assurance.

Countermeasures that make the lightweight model defensible:

• Security reviews the dispositions, not the prose, and kicks back any threat marked "mitigate" with no linked ticket.
• Track the ratio of threats mitigated at design versus found at test or in production. If design mitigations stay flat while the number of models rises, the process is ceremonial - say so.
• Sample audited models monthly, with feedback to squads.
• Keep a small number of Tier 1 models fully facilitated, so the quality bar is visible and copied.

Residual risk to state honestly: three engineers plus sampling cannot guarantee coverage across 40 services, and the annual assessment should reflect a sampling-based control rather than a claim of universal review.