Killing a Tool: The Murder Board Nobody Runs

Every security stack that reached thirty tools got there one defensible purchase at a time. The asymmetry is not in buying. It is that nothing in the organization is structured to remove anything.

Buying has a process, a committee, a budget line, and an owner. Retiring has none of those. It has one nervous person proposing to remove a control, and an implicit rule that if anything goes wrong afterward it is their fault.

A murder board fixes the asymmetry by giving retirement the same formality that purchase already has.

What a murder board is

A single two-hour session with a named adversary whose job is to argue that removing this tool is dangerous. Borrowed from the practice of red-teaming a decision before committing to it.

Three roles:

• The proposer presents the case for retirement, including what covers the function afterward.
• The adversary argues the retirement will cause harm, and is expected to find the strongest version of that argument rather than a polite one.
• The decider rules at the end of the session, in the room, and records the reasoning.

The output is a written decision with the adversary's objections recorded next to it. That record is the entire point. When something goes wrong six months later, and something eventually will, the question asked is whether the decision was reasonable given what was known. A recorded murder board answers that question. A hallway conversation does not.

When to run one, and how often

Not for every tool. Three triggers are enough.

Ninety days before any renewal above a cost threshold you set. This is the main one and it should be automatic. The renewal is the only moment when the alternative is genuinely available and the money is genuinely in play.

When a rationalization pass flags an overlap as a retire candidate. The murder board is the decision step that program hands off to.

When a platform absorbs the function. The moment your existing platform ships the capability you buy separately, the standalone tool goes to a board, whether or not a renewal is near.

Three to six sessions a year at a mid-size organization. Below that, retirement is not happening. Much above it and the ceremony is being applied to decisions too small to deserve it.

Preconditions

• The tool has a named owner willing to be the adversary, or someone credible has agreed to play it.
• Coverage after retirement is written down, specifically, not as "the platform handles it."
• The renewal date is more than sixty days out, so the decision is not being made under contract pressure.

Phase table

Why the formality is the point

An objection raised in a meeting with a named adversary and a written record is a different object from the same objection raised in a corridor.

In a corridor, the objection is a personal disagreement between two colleagues, and resolving it depends on who is more senior or more persistent. In a murder board, it is a recorded input to a decision, and the person raising it has done their job whether or not they win. That distinction is what lets people argue hard without it becoming political, and it is why the ceremony matters more than the ninety minutes it costs.

It also protects the proposer. Retirement is the only security activity where doing it well and doing it badly look identical for months and then diverge sharply. The murder board is the artifact that separates "we removed a control after examining the consequences" from "somebody removed a control", and those two sentences have very different careers attached to them.

The four questions the adversary must ask

A weak murder board is one where the adversary is polite. These four questions are the minimum.

What does this tool see that nothing else sees? Not what it does. What it observes. Tools accumulate value as sensors long after their primary function has been absorbed elsewhere, and a log source that quietly feeds three detections is easy to miss on a capability map.

Who consumes its output, and have you asked them? Detection content, compliance evidence, and executive reporting all create dependencies that do not appear in an architecture diagram. The audit team is the most commonly missed consumer.

What breaks in the first week, and who is on call? A retirement is an operational change. If the answer is "nothing should break", the adversary should ask what the plan is for the case where something does.

What is the reinstatement cost if we are wrong? Data does not survive most retirements. If reinstating means starting from zero history, the decision carries a cost that a savings figure alone does not capture.

What the record should contain

The written output is the deliverable, and a thin record provides none of the protection the exercise exists to give. Six items, on one page:

1. The tool, its annual cost, and its renewal date. Facts, so the reader a year later does not have to reconstruct them.
2. The function being retired, and specifically what covers it afterward. Named systems, not categories. "The EDR covers that" is not a coverage statement; "endpoint process telemetry moves to the EDR, which already ingests it from the same agents" is.
3. Every objection the adversary raised, in their words. Not summarized, not softened. The value of the record is that a future reader can see the strongest case against the decision and judge whether it was answered.
4. The response to each objection, marked answered, deferred, or conceded. Conceded objections that did not change the outcome are the most important line in the document, because they are where the decision knowingly accepted risk.
5. The ruling and who made it.
6. The rollback trigger.

Store it wherever your audit evidence lives rather than in a personal drive. The audience for this document is a person you have not met, reading it under pressure, after something has gone wrong.

What happens after

The retirement date is not the end of the exercise, and treating it as one is how organizations end up unable to reverse a decision they explicitly designed to be reversible.

Keep the data. Export whatever the tool holds before the contract ends, in whatever open format it offers. Historical detection data and audit evidence are the two categories that hurt most when they vanish, and they vanish at contract end regardless of what the vendor said verbally.

Watch the rollback trigger for a defined period. Sixty days is a reasonable default. Assign the watching to a named person and put an end date on it, because an open-ended watch is one nobody does.

Record the outcome. Whether the trigger fired, and what happened. Three sentences appended to the murder board document. This is what turns a series of retirements into an organizational capability rather than a series of individual gambles, and it is the step every team skips.

A worked session

Compressed from a real one. The tool is a standalone vulnerability scanner, in place six years, roughly ninety thousand a year, with the cloud platform now covering most of the same function.

Case, 20 minutes. The proposer shows the coverage map: eight of the nine functions the scanner claims are also claimed by the platform, which is already paid for. The ninth is authenticated scanning of on-premise Windows hosts, of which there are now forty, down from six hundred. Savings ninety thousand, migration effort about two weeks.

Attack, 45 minutes. The adversary, a detection engineer, raises four things:

1. The scanner is the source for three detections in the SIEM, and one of them is referenced in a control the auditor tested last year. Nobody on the coverage map knew this.
2. The platform's authenticated scanning on Windows is documented but has never been run in this environment.
3. Compliance reporting for the on-premise estate is exported from the scanner in a format the GRC tool ingests directly. The platform's export shape is different.
4. The forty Windows hosts are the oldest and most fragile machines in the estate, which is exactly why they are still on-premise.

Response, 20 minutes. Objection 1 is conceded and changes the plan: the detections move first, before anything is retired. Objection 2 is answered by a test rather than an argument, scheduled for the following week. Objection 3 is deferred with an owner. Objection 4 is conceded and does not change the outcome, but goes into the record.

Ruling. Retire, conditional on the detection migration completing and the authenticated scan test passing. New date, eleven weeks out rather than four.

Rollback trigger. "If authenticated scan coverage on the Windows estate drops below the current 94% for two consecutive weeks, reinstate."

That session cost seven people two hours. It also found a control dependency that would have produced an audit finding, and it moved the date by seven weeks, which is precisely the kind of thing that looks like the process slowing you down and is actually the process working.

When the answer is keep

Worth saying plainly, because a murder board that always ends in retirement is a rubber stamp pointed the other way.

Roughly a third of the sessions I have seen end in keep, and the good ones end in keep for a reason nobody had articulated before. The tool turns out to be the only source for an audit artifact. It is the only thing that covers a platform's blind spot on one operating system. It has an integration that three teams silently depend on.

A keep ruling is a successful murder board. The organization now knows why it pays for that tool, which it did not know an hour earlier, and the reason goes in the register so the next person does not have to rediscover it.

The failure is not keeping. The failure is never asking, which is the default state for most of a stack.

Failure modes

The adversary is the proposer's report. Nobody argues hard with their manager's proposal. Pick someone outside the reporting line or the session is theatre.

The decision is deferred without a date. "Let us revisit next quarter" is how the tool renews. Every deferral gets a date and an owner in the same sentence.

Coverage is asserted rather than demonstrated. "The EDR covers that" needs to survive one follow-up question about a specific case. If it cannot, the coverage claim is not ready and the retirement is not ready.

No record is kept. An unrecorded murder board provides all of the effort and none of the protection. Write the ruling and the objections into the same document, dated, with names.

Adapting it for a platform migration

The same structure works when the question is not "retire this" but "move this function into that platform", which is the more common shape in a consolidation.

Two changes. The adversary argues against the migration rather than against the removal, which is a broader brief and needs a longer attack phase, closer to an hour. And the ruling has an extra option beyond retire, keep, or defer: migrate partially, keeping the original for the subset the platform does not cover well.

Partial migration is the outcome people avoid because it feels like failure, and it is frequently the correct answer. A platform that covers eighty percent of a function at acceptable quality and twenty percent badly is worth adopting for the eighty, and the murder board is exactly the forum for establishing where that boundary sits.

The trap to watch: partial migration is also how you end up paying for both tools indefinitely while telling yourself it is temporary. Whatever partial outcome the board rules, it gets a review date and an owner in the same sentence, or it becomes permanent by default.

The register this builds over time

After four or five sessions you have something more valuable than the individual decisions, which is a written record of why your stack looks the way it does.

That record answers questions that otherwise cost weeks: why do we have two things that do vulnerability scanning, why did we keep the old vault, what did we conclude about the platform's coverage of endpoint telemetry. A new head of security reading five murder board records understands the estate faster than they would from any architecture diagram, because the diagram shows what exists and the records show what was decided and why.

It is also the artifact that makes rationalization repeatable. The second annual pass starts from the previous register rather than from scratch, and the conscious keeps from last year come up for review with their original reasoning attached, which is exactly the input needed to decide whether the reasoning still holds.

Skip this if

• The tool costs under roughly one percent of the security budget. The session costs more than the decision is worth. Retire it and move on.
• The vendor has already announced end of life. The decision is made; you are sequencing, not deciding.
• The tool has been unused for over a year with no consumers identified. That is not a retirement, it is cleanup.
• You are inside an audit window. Defer to after the report.

What this changes over a year

The measurable outcome is not savings. It is that retirement stops being a personal risk.

Before, proposing to remove a control is an individual sticking their neck out, and the rational move for everybody is to renew. After, it is a scheduled decision with a named adversary and a written record, and the rational move is to bring things to the board.

That shift is what actually reduces a stack, and it shows up in a way nobody predicts: people start proposing retirements unprompted. Once the process exists and has visibly protected someone, engineers and analysts volunteer the tools they think are dead weight, because there is now a safe way to say so.

What to cut if you only have thirty minutes

Run the attack phase and nothing else. Circulate the coverage map beforehand, put the adversary in a room with the proposer for half an hour, and record the objections.

The ruling can happen asynchronously afterward. The recorded objections are what makes the decision defensible later, and they are the part that cannot be reconstructed after the fact.