Security operations designed as one system, not five silos
UTIOM stands for the Unified Threat-Informed Operations Model. It is a lifecycle framework for cybersecurity and security operations centers (SOCs), connecting business strategy, threat-informed detection engineering, and incident response into a single, measurable system focused on real-world adversary behavior. It unifies management intent, engineering discipline and operational execution into one coherent model.
Governance and operations belong in the same place. In most organisations, strategy is written in one room and executed in another. Policy sits with governance; detection sits with engineering; containment sits with operations. UTIOM puts them on one lifecycle, so a board-level risk decision and a detection rule are two ends of the same traceable thread.
Incident Response is not a phase. It is the operating mode of security operations. Threat intelligence, hunting, detection engineering, monitoring and containment are not separate functions. They are expressions of incident response at different distances from impact. UTIOM unifies them into one continuous lifecycle instead of fragmented workflows and teams.
UTIOM treats the SOC as a living product, and security operations as a system — not a collection of tools, teams and processes. A SOC is socio-technical: leadership, people, process, telemetry, detection, analysis, response, technology, automation and feedback are interdependent. If the system is not designed as a coherent whole, improving individual components cannot reliably produce better security outcomes — poor system design creates recurring fragility, blind spots, delays, noise and predictable failure modes. UTIOM brings system design into security operations: Vision → Strategy → Crown Jewels → Threat Visibility → Threat Detection → Response → Continuous Improvement.
Version 1.4 · Released September 2026 · Framework content CC BY-SA 4.0 · software, toolkit and assessment instruments under separate terms
Start here
New to the framework? These two pages answer the basics before you dig into the lifecycle or run an assessment.
One operating model, three capability models that measure parts of it in depth, and a
management foundation underneath. They are not four equal frameworks: the models below exist to answer
questions UTIOM raises but does not itself measure.
Main operational framework
UTIOM
Unified Threat-Informed Operations Model
The full threat-informed lifecycle, from leadership intent through to proven
response. Seven phases across three pillars — Leadership & Governance, Engineering &
Enablement, Operations & Analysis — held in one vocabulary so a board decision and a
detection rule are two ends of the same thread.
All are free, vendor-neutral, and built on the same premise: everything a security
operations function does is incident response.
Evidence layer · not a pillar, phase or enabler
UTIOM Security Assurance
Where the assessment asks what you have built, Security Assurance asks what you can
demonstrate. It collects the evidence behind a claim — emulation results, validation records,
response exercises — and produces an Assured Maturity view. Assured Maturity is never higher
than Governed UTIOM Maturity: evidence can confirm a claim or reduce it, never raise it.
v0.1 · Practitioner Preview · separate methodology, not part of the v1.4 assessment
A refinement of People, Process and Technology into six dimensions. It describes
the organisational capability that makes the operating model above possible — it does not measure
the lifecycle itself.
Four browser-based instruments that make the framework usable rather than theoretical. Each answers a different question, and the roadmap combines them.
Your answers stay in your browser. No backend, no database, no analytics, no signup. Nothing you enter is transmitted anywhere. Results are saved in this browser only, on this device, so the roadmap can combine them. Clearing site data removes everything.
UTIOM operational tools
The models above define and measure the operating system. These do the work: things a
practitioner opens, uses, and closes. They are not frameworks and not part of the assessment model.
UTIOM public tools provide practical, vendor-neutral capabilities for individual use.
Organisation-specific context, integrations, continuous assurance and enterprise automation remain a
separate capability layer.
How UTIOM makes you more mature in TID-CMM and TIR-CMM
The relationship is directional. UTIOM produces the inputs the two maturity models measure, which is why organisations that adopt UTIOM first tend to score better on both without targeting them.
Crown jewels → scoping
TID-CMM derives its in-scope ATT&CK set from what you run, what you protect and who targets you. UTIOM's Crown Jewels phase produces exactly that: a registry with named business owners, business impact mapping and threat models per asset. Without it, scoping is guesswork and the model has nothing to narrow against.
Threat profiling → adversary prioritisation
TID-CMM's first domain asks who you are defending against and how you know. UTIOM's Strategy phase makes threat profiling a mandatory activity, producing the documented adversary set that domain scores.
Threat visibility → telemetry assurance
TID-CMM computes which behaviours are structurally undetectable given the telemetry you actually collect. UTIOM's Threat Visibility phase engineers telemetry outward from crown jewels and produces an accepted gap report, which is the raw material that computation needs.
Detection-as-code → detection engineering
TID-CMM's heaviest-weighted domain asks whether you build, test and maintain detection like engineers. UTIOM's Threat Detection phase requires version control, CI/CD, three levels of testing and traceability from rule to crown jewel.
Validation → adversarial validation
TID-CMM asks whether you have proven any of it works, and applies constraints that cap your score if you have not. UTIOM makes validation a first-class domain: purple team exercises emulating profiled adversaries, failed detections raised as engineering defects.
Response and improvement → TIR-CMM
TIR-CMM measures whether containment authority exists before the incident, whether playbooks have been executed under a clock, and whether you move faster than the adversary. UTIOM's Response phase produces exactly those: pre-engineered escalation thresholds with named individuals, crown-jewel playbooks, and decision gates defined in advance. Its Continuous Improvement phase closes the loop that TIR-CMM scores.
The order matters. TID-CMM and TIR-CMM measure depth in one pillar each. UTIOM decides what that pillar should be pointed at. Running a detection maturity assessment without a crown jewel registry or a threat profile produces a precise score for an undirected capability — you learn how well you detect, without knowing whether you are detecting the right things.
From building a SOC to improving one
UTIOM supports security operations at different stages of their journey. It can be used when building an operation from scratch, where the organisation needs to define its purpose, operating model, crown jewels, threat priorities, visibility requirements, detection engineering, response capability and measurement system before technology begins to drive the design. The same model applies to an existing operation, whether internal, outsourced or hybrid, and regardless of whether it is still reactive or already relatively mature.
The intention is not to replace the technology, teams, processes or standards an organisation already has. UTIOM provides the operating logic that connects them, identifies what is missing or misaligned, establishes what should be improved first, and creates a continuous cycle.
Used this way, UTIOM is both a blueprint for designing security operations in the right direction from the beginning and an improvement system for an operation already running. TID-CMM and TIR-CMM then provide deeper measurement of detection and response capability within the same threat-informed ecosystem.
Building from scratch
Start at Vision and work forward. The lifecycle order is the build order: purpose, then strategy and threat profile, then crown jewels, then the telemetry and detection those decisions imply, then response, then the measurement that proves any of it worked. Technology choices come last, because they are consequences rather than starting points.
Improving what exists
Start with the assessments instead. The maturity assessment shows where you actually are, the capability assessment ranks where effort buys the most risk reduction, and the roadmap sequences the work. Many established operations find their gap is not detection coverage but the absence of the governance decisions that should have directed it.
Outsourced or hybrid
The model does not require one organisation to own all three pillars. A provider may run Operations and Analysis while Leadership and Governance stays internal. What it insists on is that the connections exist: that the provider detects against your crown jewels and your threat profile, and that operational reality reaches the people setting direction.
How the framework is put together
Five structures, each answering a different question. They are complementary views of one system, not competing models.
3 Pillars
Operating structure. Leadership & Governance, Engineering & Enablement, Operations & Analysis. Leadership & Governance is the management and control plane: it sets vision, strategy, crown jewel priorities, decision authority, investment and governance, and takes operational evidence back through the feedback loop to adapt the system.
7 Lifecycle phases
How value flows. Vision → Strategy → Crown Jewels → Threat Visibility → Threat Detection → Response → Continuous Improvement.
3 Cross-cutting enablers
Talent, Validation, Threat Hunting. Not lifecycle phases. They run across multiple phases and pillars, each with a primary operational home so it can be assessed.
3 Assessment tiers
System-integrity view of results. Strategic & Governance Foundation, Engineering & Operational Capability, Assurance & Evolution. They do not replace the pillars, phases or enablers — they add a view that stops a strong area concealing a hollow foundation.
STRATA
Organisational enabling lens. Strategy, Talent, Resilience, Automation, Telemetry, Adaptability. Explains why a capability is strong or weak. Not a maturity score, and it never changes a UTIOM result.
Follow the project, explore the public framework resources, share feedback, open discussions and contribute to the evolution of UTIOM.
The repository holds the publicly released UTIOM framework resources. The hosted tools are free to use; that is not the same as the entire codebase being open source.
Continuous improvementKaizen loops feeding back into the whole lifecycle
Every design decision on the left has a matching validation activity on the right. Purple team exercises prove the attack paths were real. Detection QA proves the telemetry delivers. Response outcomes prove the threat profile picked the right adversaries. Remove the right arm and the left arm is just opinion.
The same lifecycle drawn as an architecture: three pillars, the services each delivers, and the feedback loops that convert fragmented operations into an adaptive control system.
Click to enlargeThe operating model in full. Three pillars, seven phases, and the two feedback loops that keep them aligned: a decision-making loop carrying operational reality back to leadership, and an OODA loop running between engineering and operations at incident tempo. The engineering pillar is measured by TID-CMM, the Threat-Informed Detection Capability Maturity Model, which scores visibility and detection depth against the threat profile rather than against technique counts.
Seven laws defining how security operations must function in an era of cloud complexity, adversary sophistication and regulatory pressure.
01
Business survival defines security
Every material security capability must be justified by business consequence, relevant threat or operational resilience. Crown jewels are the primary consequence and prioritisation anchor, together with the dependencies, identities, shared infrastructure, trust boundaries and realistic attack paths through which business impact can occur.
02
Strategy before sensors
Telemetry and tools must follow strategy. Architecture is driven by intent, not by vendor capability.
03
Crown jewels drive prioritisation
Security resources are finite. Crown jewels determine where visibility, detection and response must be strongest.
04
Threats shape architecture
Detection engineering must be informed by real adversary behaviour, designed around realistic attack paths.
05
Visibility is a design decision
Blind spots are not accidents. They are architectural choices.
06
Operations is continuous response
Incident response is not a phase. It is the operating state of modern security operations.
07
Improvement is mandatory
Every incident must refine the system, through measurable feedback loops.
One discipline, many expressions
What the industry calls separate functions are different expressions of incident response across time. This is why UTIOM removes the silos rather than coordinating between them.
Threat intelligence
Incident response before impact. It defines assumptions, priorities and threat relevance.
Threat hunting
Incident response without alerts. Hypothesis-driven investigation in advance of detection.
Detection engineering
Incident response encoded into logic. Lessons learned turned into repeatable sensing.
Monitoring and triage
Continuous incident response. Systems are never idle, only partially engaged.
Response and containment
The most visible expression of incident response, not the beginning of it.
In cloud environments the separation collapses entirely. Identity design defines containment. Architecture defines blast radius. Telemetry defines future investigations. When those decisions are made during an incident, response becomes improvisation. UTIOM treats design as the first act of incident response.
Well-designed security operations are not loud. They are deliberate, predictable and boring. Noise decreases because intent is clear, response accelerates because paths are predefined, and learning compounds because detection and response are connected. That is what maturity looks like.
The framework
The complete model, free and open.
Book · new edition
UTIOM Framework Book v1.2 is now available online
The new edition of the UTIOM Framework Book is now available to read directly on
utiom.de. It includes the current framework family, the Response Horizon, the UTIOM V-Model,
updated standards alignment and the consolidated UTIOM philosophy.
UTIOM does not replace established standards. It operationalises them. The full domain-by-domain mapping table covers NIST CSF 2.0 categories, ISO/IEC 27001:2022 + Amd 1:2024 clauses and Annex A controls.
NIST CSF 2.0
CSF defines what good cybersecurity looks like. UTIOM defines the operating model that delivers it, with Vision and Strategy mapping to Govern, Crown Jewels to Identify, and the engineering phases to Detect and Respond.
SOC-CMM
SOC-CMM measures how mature a SOC is. UTIOM provides the mechanism to become mature, across people, process, technology and governance.
DORA
DORA mandates operational resilience. UTIOM operationalises it through crown-jewel-driven risk management, tiered response and structured incident classification.
MITRE ATT&CK and DeTT&CT
ATT&CK describes adversary behaviour and DeTT&CT measures detection coverage against it. UTIOM anchors both to crown jewels so coverage is prioritised by business consequence rather than technique count.
TID-CMM
The Threat-Informed Detection Capability Maturity Model measures the engineering pillar specifically: telemetry coverage per modelled threat, detection traceability, and validation depth. Where SOC-CMM scores the whole SOC, TID-CMM scores whether detection is genuinely threat-informed. Eight domains, 58 sub-capabilities, aligned to MITRE ATT&CK Enterprise v19.2 and crosswalked to NIST CSF 2.0 and SOC-CMM. Published separately at tid-cmm.com.
TIR-CMM
The Threat-Informed Response Capability Maturity Model measures the operations pillar: whether containment authority exists before the incident, whether playbooks have been executed under a clock, and whether the operation moves faster than the adversary. Introduces the Containment Lattice and the Containment Margin metric, and measures decision latency separately rather than burying it inside MTTR. 58 sub-capabilities across three assessment tiers. Published separately at tir-cmm.com.
STRATA
A refinement of People, Process and Technology into Strategy, Talent, Resilience, Automation, Telemetry and Adaptability. Feeds the Vision, Strategy and People dimensions of the operating model.
ISO 27001, TOGAF Standard, 10th Edition, COBIT
Governance, architecture vision and control objectives feed the Vision and Strategy phases, keeping the operating model traceable to existing certification work.
Questions
Does “Strategy” in UTIOM mean business strategy?
No. Strategy in UTIOM means the security operations strategy, which is distinct from the business strategy. Business strategy is an input: it tells you what the organisation is trying to achieve and therefore what must not fail. The security operations strategy is the answer to that — which adversaries are realistic, which assets carry the consequence, what capability gets built in what order, and how success is measured. The two must align and support each other rather than run in parallel or in conflict.
Who is UTIOM for?
CISOs and security leaders defining operating models and governance. SOC architects and detection engineers building capability with real constraints. Incident responders who need consistent, threat-aligned execution. Organisations moving from alert-driven security to outcome-driven operations.
Is any data sent to a server?
No. The tools have no backend, no database and no analytics. Everything runs in your browser, and nothing you enter is transmitted or stored remotely. Results are kept in this browser only so the roadmap page can combine them, and clearing site data removes them. The toolkit is also downloadable to run entirely inside your own network.
Does this replace NIST CSF, ISO 27001 or SOC-CMM?
No. UTIOM is an operating model that connects those standards to daily execution. NIST CSF says what good looks like, SOC-CMM measures maturity, and UTIOM provides the lifecycle that delivers both.
Why is incident response treated as the operating mode?
Because by the time an alert fires, almost every decision that determines the outcome has already been made: whether the telemetry exists, whether the detection was tuned, whether a playbook exists, who can authorise containment. Those are incident response decisions made in advance. Treating IR as a downstream phase hides where the leverage actually is.
Is it free?
Yes, at the free tier. Licensing is split. The framework, Book and diagrams are CC BY-SA 4.0 — share and adapt, including commercially, with attribution and under the same licence. The software and self-hosting toolkit are under separate terms. The assessment instruments are free under the UTIOM Free Assessment Use Terms for personal, internal organisational and business, educational and research use; your answers and results are yours. Commercial redistribution, white-labelling, competing hosted or managed services and separately offered enterprise functionality sit outside the free grant. Full licensing →
About
UTIOM was created by Reza Adineh, a Germany-based cybersecurity architect with over fifteen years of experience designing and leading security operations centres across banking, cloud and hybrid environments. It emerged from a recurring observation: technology scales quickly, understanding rarely does, and the gap between strategy and execution is the real vulnerability of modern defence.
Also the creator of the STRATA, TID-CMM and TIR-CMM frameworks, and of the Realistic SIEM Maturity Model. Further writing and the framework's supporting material are published on LinkedIn.
Join the UTIOM community. Discuss, contribute evidence and share implementation experience. About the community →