Your organisation starts treating threat models as both audit evidence and its risk register. How do you respond?

### The request is usually reasonable; the framing is not When an organisation starts reaching for threat models as audit evidence and as a risk register, it is rarely being lazy. It is usually short of assurance artifacts, and the threat models are the most thoughtful security documents in the building. The correct response is not a flat refusal but a clear statement of what each instrument asserts, followed by an offer of what the model can legitimately feed. ### Three instruments, three assertions **A threat model** asserts intent about a design. It is scoped to one system or one change, produced at a point in time, and written in technical terms by the people building the thing. Its claims are of the form "this design permits X, and we intend to do Y about it". **An audit** asserts something about operation. Its characteristic question is whether a control that was described as existing was in fact designed appropriately and operated effectively across a defined period, and it answers by examining evidence — records, samples of transactions, configuration as it stood on given dates. Nothing in a threat model is that kind of evidence. The model may say "off-cycle payroll corrections above a threshold require a second approver". It cannot say whether, over the last six months, any correction was pushed through without one. Those are different claims, and the second requires looking at what happened. **A risk register** asserts an organisation's current view of its risks. It is maintained continuously rather than produced once, spans systems rather than sitting inside one, and is expressed at a level a business owner can make decisions about, with an owner and a treatment status per entry. A threat model is a snapshot of a design's technical exposure. Individual threats from it may be worth promoting into the register — usually the few that cannot be fixed inside the team — but the model is not the register and does not behave like one. ### A worked case Take a payroll-correction admin tool. The threatening actor is not an anonymous outsider; it is a payroll clerk with legitimate access issuing off-cycle corrections, and the assets are money and the non-repudiation of pay records. A model of that tool produces genuinely valuable statements: a clerk can issue and then amend a correction, the amendment overwrites rather than appends, so the record of who was paid what and on whose authority can be rewritten by the person who benefits. Hand that to the compliance team as audit evidence and see what happens. The auditor's question is whether segregation of duties operated over the period. The model's statement is an assertion about the design's intent, made by the team that built it, with no sampling of actual corrections behind it. It is a good input to deciding what to test. It is not the test. Hand the same model over as the risk register and a different failure appears: it will not be updated when the design changes, it covers one tool out of many, and its items are phrased for engineers rather than for the person who has to decide how much this matters relative to everything else. ### What you offer instead - **Control objectives.** The threats the model names are an excellent source of what ought to be tested for operating effectiveness. Let the model shape the audit programme's scope without pretending to be its evidence. - **Escalation of specific items.** A threat the team cannot resolve alone — one that needs budget, a vendor change, or a decision above the team — belongs in the register, promoted as a single entry with an owner, phrased in business terms. - **A pointer to real evidence.** Where the model asserts a control, name the artifact that would actually demonstrate it operated: the approval records, the immutable log, the access review. That is the genuinely useful bridge, and it often exposes that the evidence does not exist yet. ### The cost of saying yes, which is the real argument The reason to hold this line is not taxonomy pedantry. It is candour. A threat model works because a room of engineers will say out loud that their own design has a hole in it. The moment those documents are filed as evidence to an external reader who can penalise the team for their contents, the incentive inverts. Sessions get sanitised, findings get softened into things that sound like controls, and the uncomfortable threat — the one about the clerk who can rewrite the record of their own correction — is the first thing to disappear. You will still have documents. They will no longer be worth reading. So the position to take is: the model informs both instruments, and stays owned by the team that produced it. If the organisation needs assurance artifacts and a maintained register, build those as themselves, with the model as one of their inputs.