Every security decision should be explainable

A signal starts in one queue. The evidence lives in a search tool. The response happens in another system. The record of who decided what is assembled later, usually when someone asks for it.

The cost of that is not a few extra clicks. It is a decision that cannot be explained afterwards, because the trail behind it was never continuous.

We think every security decision should be explainable: what was seen, what was concluded, who approved the action and on what evidence. Not reconstructed from memory and screenshots. Recorded as it happens.

Why reconstruction fails

Reconstruction has three weaknesses.

• It is selective. Whoever writes the summary decides what mattered. The evidence that did not fit the final story quietly disappears.
• It is late. The people involved have moved on to the next incident. Timestamps come from chat logs and tickets that were never meant to be evidence.
• It is unverifiable. If a record can be edited without trace, nobody can show that what the report says is what happened.

When an auditor, a board or a regulator asks "who decided, and on what basis?", a reconstructed answer is an opinion. A recorded one is evidence.

Three conditions for a defensible decision

Context survives. Priority, ownership, scope and response state stay attached to the incident as it moves between people and shifts. The analyst who picks it up at 3 a.m. should not have to rebuild them.

Evidence is explainable. The records behind a detection, and the reasoning that connected them, can be reviewed inside the case. If AI contributed, its reasoning sits next to the evidence it used, and you can tell which records it relied on.

Approval stays human. Automation can make a team faster. It should not make the team less accountable. Every action should carry its risk, its approval requirement and a record of who approved it.

A checklist for your own SOC

You can test any SOC, on any platform, against these questions.

1. Can one incident be followed from first signal to final sign-off without leaving the record? If the answer involves exporting to a spreadsheet, the trail is broken.
2. Is the case history append-only? Notes, status changes and decisions should be added, never rewritten.
3. Is the audit log tamper-evident? It should be possible to show that no record was deleted, reordered or altered.
4. Does every response action carry a risk level? "Send a notification" and "isolate a host" should not be governed the same way.
5. Do destructive actions need a second person? And can the person who started the action approve it themselves? They should not be able to.
6. Can you rehearse an action before it is real? A dry run shows what a playbook would do without doing it.
7. Is AI advisory, and does it cite its evidence? You should be able to see what the model was given, and claims without evidence should not survive.
8. Can you search the trail later? By who acted, what they did, the outcome and when.

If you answer "no" to more than two of these, the gap is not a tooling detail. It is a governance gap, and it will surface at the worst possible time.

Start with the decisions that matter most

You do not need to fix everything at once. Start with the decisions that carry the most risk:

• containment actions that take a host, account or service offline
• decisions that an incident is, or is not, reportable to a regulator
• changes to detection logic and retention

Make sure each of these leaves a record that would satisfy a sceptical reader. Then work outwards.

How kymeer approaches this

kymeer is built around one evidence trail, from first signal to final approval.

Cases keep an append-only activity timeline next to the evidence, so the story of the decision is recorded as it is made. The audit log is per tenant, append-only and linked by SHA-256 hashes, so a deleted, reordered or altered record breaks the chain.

Every response action has a danger level. Safe actions have no external side effect. Sensitive actions have side effects but are scoped or reversible, and can require approval per action. Destructive actions always need approval, and the approver must be a different person from whoever started the run; the database refuses an approval by the maker. A level can be raised for a specific action, never quietly lowered. Any playbook run can start as a dry run, which validates and plans each step but takes no action. Each approval or rejection is written to the audit log, and the log can be searched by actor, action, outcome, resource and time within your own tenant.

The kymeer AI analyst is advisory. It explains what it sees and recommends next steps beside the evidence. In incident analysis, only citations the model selects from the evidence it was given are kept, and claims without a citation are rejected.

See how this works in practice on the governed response page, or read the response guide.