One threat intelligence finding must reach the board, the IR lead and a detection engineer — one product or three?
answer
- one judgement, three derivations
- each reader has a different authority
- strip what the other two readers need
- one judgement of record prevents drift
- delivery channel is part of the product
basics
~20 sThree products from one judgement. Each reader takes a different decision at a different abstraction and on a different clock, so a single combined document forces every reader through the other two readers' material and gets skimmed by all of them.
solid answer
~50 sOne analytic judgement, three derived artefacts. Take the finding that an extortion crew hitting retailers has abandoned encryption for exfiltration-and-publish, supported by a peer's disclosure, a regulator's sector letter and two of our closed cases. The **board note** is one page: the loss model moved from downtime to disclosure, our merchandising file share holds exactly what that model monetises, and we ask the divisional VP to fund volume monitoring on it this quarter. The **operational brief** for the IR lead changes the playbook: there will be no encryption event to trigger on, restoring from backup does not end anything, and the case closes only when we can say what left and argue there is no way back in. The **tactical list** for the detection engineer is a list — staging data into archives, transfer utilities brought in, one account reading unusual breadth of a share — with technique identifiers and artefacts. Keep one judgement of record so the three cannot drift apart.
go deeper
Know that the same finding is written differently for different readers, and be able to say what an executive needs versus what a detection engineer needs. You are not expected to run the derivation yourself yet.
Explain what each of the three products contains and what you cut from each. Be able to describe why artefacts and judgements cannot share a document comfortably: they go stale at completely different rates.
This is your question. Walk through a real finding and produce the three artefacts out loud, naming the decision behind each, and describe how you keep them consistent as the judgement moves. Bring a failure you have seen.
Own the production model: who is entitled to a product, how many recurring products the team can sustain, and whether a reader who never acts should keep receiving one. Deciding what the team stops writing is as much your call as what it writes.
## Why one document fails all three readers The combined document is the default because it is cheaper to write, and it fails predictably. The executive hits technique detail on page two and stops. The incident lead has to reverse-engineer what changes in their playbook from prose written for someone else. The detection engineer has to read four pages of narrative to extract nine behaviours that should have arrived as a list. Each reader pays a cost imposed by the other two, and the author pays none. **The cost of the split is one author's afternoon; the cost of not splitting is three readers not acting.** ## Derivation, not three separate research efforts The three products share one analytic judgement. You write the judgement once — including how confident you are and what would change it — and then derive each artefact from it. Concretely: | Reader | Decision they take | Artefact | Shelf life | |---|---|---|---| | Divisional VP / risk committee | Fund a control, accept a risk, reprioritise | One-page note, briefed in the slot you have | Quarters | | Incident response lead | Change a playbook, stand up readiness | Two-page brief plus what to be ready for | Weeks to months | | Detection engineer / hunter | Write a rule, run a hunt | A list of behaviours and artefacts | Behaviours months, artefacts days | ### The board note The substance is the change in the **loss model**. It used to be that this class of crew took your systems away and your defence was recovery speed; backups were the control that mattered and they were funded. That is no longer the shape of the harm. The harm now is publication of data you hold, which recovery does not touch. That is a sentence a risk owner can act on. Then the ask, sized to what the forum can actually approve — a budget line, not a control design — with a named owner and a date. ### The operational brief Written for the person who owns the response. The content is what is different this time: no encryption event means the loud, obvious trigger the playbook assumes is simply absent; the first sign may be the crew making contact, or a peer telling you, or a hunt. Restoration is not eradication and it is not the end of the incident — this case ends when you can account for what left and can argue the crew has no remaining path back. It should also say what evidence to preserve early, because the questions that arrive later are about what left, and answering those requires records nobody thinks about at hour one. ### The tactical list Written as a list because its reader turns it into rules and hunts. Behaviours first, because they last: staging collected data into archives before moving it, bringing a file-transfer utility onto a server that never needed one, a single account reading a breadth of a file share that no role justifies. Technique identifiers such as `T1560` for archiving collected data let the engineer map to what already exists. Artefacts last, dated, with an honest note that they are the perishable half. ## Keeping the three from drifting The practical failure is version drift: six weeks later the tactical list has been updated twice, the board note still asserts something you no longer believe, and someone finds both. Hold one judgement of record — a single internal statement of what you believe and why — and regenerate the derived products from it. When the judgement changes, all three are reissued or explicitly withdrawn. Give them the same identifier with different suffixes so a reader holding one can find the others. ## Delivery is part of the product The board note is not emailed and hoped for; it is briefed, and briefed to someone who has already seen it. The operational brief lands in a conversation with the IR lead where the playbook is edited in front of you. The tactical list goes to the engineer in whatever form they can consume without retyping. **A product delivered into a channel the reader does not read has not been delivered.** ## Where senior candidates separate themselves Weak answers describe three lengths of the same text. Strong answers name the decision behind each product, say what they deliberately strip out of each, and show the discipline that keeps the three consistent. The strongest answers add the failure they have actually seen: the board note that quoted technique identifiers and lost the room, or the operational brief that told the IR lead things he already knew because it was written at the abstraction of the board note.
- Six weeks later the board note and the tactical list contradict each other — how did that happen?They were forked rather than derived. Somebody updated the list as new cases came in and nobody reissued the note. The fix is a single judgement of record that the products are generated from, plus a rule that a change to the judgement means all derived products are reissued or explicitly withdrawn.
- The IR lead says your operational brief told him nothing he did not know — what went wrong?You wrote at the board's abstraction and handed it to him. An operational product has to change something concrete: a playbook step, a readiness gap, evidence to preserve early. If nothing in it changes his behaviour, it was a strategic product with a different cover page.
- Is there ever a case for a single combined document?When the readers are the same handful of people — a small team where the risk owner, the responder and the engineer are three seats away from each other. Even then, separate the ask for the decision-maker from the list for the engineer, because those two decay on completely different clocks.
saying these in an interview costs you the question
- Writes one long document with an executive summary bolted on
- Puts technique identifiers and artefact tables in the board note
- Hands the detection engineer prose with the behaviours buried in it
- Treats the three products as three lengths of the same text
- Never names the decision each reader is being asked to take
- Lets the three products drift apart with no single judgement of record