IriusRisk returns 300 countermeasures for one regulated payments design. How do you turn that into work a team will do?

## Where the number comes from IriusRisk is pattern-driven. You describe the architecture — most often by answering a questionnaire about the components, their properties and the compliance context, sometimes by drawing it — and a rules engine matches that description against a library of components and patterns. Each match contributes its threats *and* its associated countermeasures: prescribed controls, risk-rated, mapped onto recognised control standards, and pushable into an issue tracker where each carries a state such as required, implemented or rejected. The volume is therefore structural, not accidental. Three hundred countermeasures for a payments design means the model touched enough component types that the library had three hundred controls to offer. It is the union of everything the library knows about those components. That is genuinely valuable — it is coverage no human recalls under time pressure — and it is genuinely not a backlog, because the library applied every control uniformly without knowing which of your assets matter. ## The failure mode to avoid The worst outcome is not ignoring the list. It is accepting it whole. Push 300 items into the tracker and four things happen: the team's sprint fills with hardening chores whose relative importance nobody set, the two threats that actually endanger transaction integrity sit at the same priority as a header configuration, engineers learn that threat modeling means paperwork, and — the expensive one — the organisation now has a written record that it *knows about* 300 controls it has not implemented. In a regulated payments context that record has consequences, and it was produced without a single judgment call. The second-worst outcome is closing them in bulk with no reason. That destroys the only durable asset the exercise produces. ## What to do instead **Re-rank against your own assets.** The library's ratings are generic; yours are not. For a payments product the ordering questions are: what lets money move that should not, what lets a transaction be altered or repudiated, what exposes cardholder or account data, what breaks the audit trail that proves what happened. Controls that touch those come first, whatever the library scored them. Everything else is hygiene with a schedule. **Use the states as an assumption register.** Marking a countermeasure not applicable or already implemented should require a sentence naming *why*: which platform control covers it, which component is not in scope, which team owns it elsewhere. Those sentences are the highest-value output of the whole run, for two reasons. They are reusable — the next model of a similar service inherits them — and they are falsifiable: when the claimed platform control turns out not to exist, you can find every countermeasure that was dismissed on it and reopen the set. A claim of 'implemented' with no evidence is the same defect as a control that was never built, just harder to see. **Separate the design-changing few from the operational many.** Out of 300, a small number will say something that changes the architecture — a boundary in the wrong place, a service holding data it should not, an integration with no authentication story. Those go to the design review this week. Ordinary hardening becomes standing work with an owner and a due date, not sprint-blocking tickets. **Feed the tuning loop.** If the same twenty countermeasures are marked not applicable in every model your organisation produces, that is a defect in your library configuration, not in the teams. Adjust the rules, or record the platform control as a shared implemented countermeasure so it never appears again. A pattern-driven platform earns its licence in the second year, when its output is shaped to your architecture; if year two looks like year one, you are paying for a generic checklist. **Keep the standards mapping in its lane.** The mapping of countermeasures to control standards is evidence for an auditor that a control exists and is owned. It is not a priority order, and 'the library says required' is not a risk argument. Be able to defend every ranking in your own words, because the interview question behind this scenario — and the audit question — is the same: *why this order?* ## The judgment being tested A platform like this shifts the bottleneck. Enumeration stops being the hard part; triage becomes the hard part, and triage is where the human judgment about assets, business impact and organisational capacity actually lives. The lead's job is to decide how much of the library becomes the organisation's control baseline, who owns tuning it, and what the team is allowed to say no to — not to shepherd 300 tickets.