Use cases
Four teams reading the same report produce four different truths, each in its own tool and vocabulary. The use cases below are consumers of one governed model. Every team keeps its tools, the knowledge stays one, and each use case names the regulation or programme it serves, DORA, NIS2, KRITIS, TIBER-EU, or CTEM.
01–02 · Know the threat
More feeds do not make a SOC safer. Knowing which actors matter to you and holding a model of their behaviour that your analysts stand behind does.
Generic actor lists leave the question of relevance to the reader. The platform scores a curated library against your business parameters, scenarios and the events you track, and returns the actors relevant to you ranked by risk, each with a rationale that can be checked.
A report refined by hand takes weeks and a report refined by a model alone cannot be trusted. Here the AI builds the attack graph, every claim keeps its evidence and confidence, and an analyst validates before anything leaves the model.
03–06 · Run defence operations
Intelligence that does not change a detection, a hunt, or a response is not readiness. These four use cases are driven by the same model and keep the path back to the claim.
Rules written on request from a language model are claims without context. The platform derives detection logic from validated techniques, binds it to the log sources you have, and emits native rules for your SIEM and EDR, with coverage counted per adversary.
Hunting without a hypothesis is browsing. Hypotheses are read off the adversary's procedure in the model, linked to investigative questions and to the data that can answer them, so hunters start where the adversary would be rather than where the noise is.
Containment that starts before the campaign is understood leaves gaps. Scope is taken from the observable layer of the model, infrastructure, ports and verified indicators, and the graph guides responders in the attacker's order, from technique to log source to event.
A CVSS score says nothing about whether an adversary can reach the weakness. Weaknesses and attack paths are ranked by adversary relevance based on motivation and intent per critical business function, from the same model the SOC and the red team use, so there is no parallel truth.
07–08 · Test and prove
Regulators ask for threat-led tests and an auditable line from intelligence to control. Both come out of the model rather than from a blank page.
Every test cycle that starts from scratch repeats the research of the last one. Threat profiles, scenarios, and attack paths per critical business function are generated from the model as the data behind the Targeted Threat Intelligence Report, traceable to the sources and repeatable at the next cycle.
Auditors want to see which claim led to which control, not a policy document. The model keeps that lineage per critical business function, who threatens it and how, what is detected and what is tested, and the reporting engine turns it into reviewed, TLP-marked documents.
09 · Towards the agentic SOC
SoonAgents are only as good as the context they act on, and that context is usually embedded in one vendor's ecosystem, hard to share and reuse across a diverse security stack. Your own agents, or the agents shipped with your platforms, read validated claims from the governed model over APIs and MCP. Change the platform, keep the knowledge.
Compliance evidence
Critical business functions are modelled the way the regulations describe them, and every detection and every test scenario is traceable from the intelligence it came from to the control it became.
Start with two of them
Detection coverage and hunting are the usual first pair. Response, exposure and threat-led testing follow on the same model.
Contact
Turn the reports and feeds you already receive into a governed Cyber Threat Model that your SOC and risk and management teams can act on. Tell us where you want to start.
