Antares
Framework / Methodology
MODEL / 02

The Antares Decision Model

A framework for making better cybersecurity decisions under uncertainty — connecting risk, accountability, governance, and operational execution as one decision system.

Premise

Cybersecurity is a decision problem.

Organizations operate in environments where risks evolve, priorities compete, and decisions must be made with incomplete information. Leadership is asked to evaluate exposure, commit resources, accept risk, and defend those calls — often without a clear structure for how the decision was arrived at in the first place.

Cybersecurity is often framed as a technology or compliance challenge. Both matter, but neither is the actual problem. The actual problem is decision-making: how risk is understood, how ownership is assigned, how authority is exercised, and how the resulting call is translated into practice across the organization.

The Antares Decision Model (ADM) provides a structured approach for connecting security decisions with business context, accountability, and execution. It is the underlying framework that Antares uses to organize advisory, governance, risk, and operational work.

Why ADM exists

The gap is not tools. It is decisions.

Many security programs struggle not because organizations lack tools, frameworks, or budget. They struggle because decision-making — what is being decided, by whom, against what standard, with what authority, and with what record — becomes fragmented across leadership, IT, operations, vendors, and compliance.

The result is rarely a tooling problem. It is a coordination problem that shows up as unclear ownership during a vendor review, audit evidence that does not match the team’s understanding of what is in place, fragmented response when an incident hits, and board questions that no one in the room can answer cleanly.

ADM was developed to give that problem a name, a structure, and a way for advisory work to be evaluated against it. The question ADM asks of every security program is the same: are the decisions that need to be made actually getting made — and are they being made well?

Core principle

Security outcomes are a property of decisions.

Security outcomes depend on the quality of organizational decisions — over time, under pressure, and in the absence of complete information.

A control that was decided well and documented, but assigned without a clear owner, will degrade. A vendor evaluation that was thorough but lacked authority to commit will stall. An incident response plan that exists in policy but has never been exercised will fail under the conditions it was written for.

ADM treats the decision — not the policy, the toolset, or the framework — as the unit that determines whether a security program actually functions. The model is structured around making those decisions visible, ownerable, and executable across functions.

The quality of a security program is not a function of how many controls are in place. It is a function of how well the decisions behind those controls are made — and how well they survive contact with the next quarter.

Lifecycle

The decision lifecycle.

ADM treats every security decision as an instance of a four-stage lifecycle. The same cycle repeats at the program level, at the engagement level, and within individual decisions — Understand, Decide, Execute, Improve.
Stage / 01
Understand
Establish context.

Establish the business, technology, and risk context a decision has to be made within. Surface what leadership is accountable for, what the operational environment actually looks like, and what assumptions are baked into the current posture.

Stage / 02
Decide
Choose with ownership.

Evaluate priorities, tradeoffs, and ownership. The decision is the unit of work here — who decides, against what standard, with what authority, and with what record so the decision survives turnover and scrutiny.

Stage / 03
Execute
Translate into practice.

Translate the decision into operational security practices. Execution lives across engineering, vendors, operations, and compliance — and the decision has to remain coherent as it moves through each of them.

Stage / 04
Improve
Measure and adapt.

Measure outcomes against what the decision was supposed to produce. Feed what is learned back into context so the next decision starts from a more accurate picture than the last one did.

Reading the cycle

The lifecycle is not a checklist that completes once. It is a loop. A risk register that is established but never re-scoped against what the organization has learned is governance that has stopped at Understand. A compliance program that ships controls but does not measure what they produce is a cycle that stops at Execute. The improvement step is what keeps the loop closed — and is the step most often missing.

ADM is used to evaluate where in the cycle a program’s discipline is strong, where it has stalled, and what work is required to keep the loop functional.

Audience

Who ADM is written for.

ADM is a framework for the people whose decisions shape a security program's actual behavior — not the people configuring the tools.

  • CIOs, CISOs, and security leaders accountable for program direction
  • CEOs, CFOs, and boards making security decisions under business pressure
  • Legal and compliance leadership sitting at the seam between regulation and operations
  • Security operations and engineering leads translating decisions into practice

ADM is written to be useful to all of them — without requiring alignment to a particular framework, toolset, or organizational structure.

Forthcoming

A deeper ADM research brief.

A forthcoming ADM research brief will provide a deeper exploration of the model — applying the decision lifecycle to specific contexts (vCISO engagement, AI governance, incident response) and documenting the failure modes ADM predicts in each.

The brief is positioned as a thought-leadership asset for security leaders, boards, and policy stakeholders interested in how cybersecurity decisions are actually made at mid-market scale.

For a working view of an Antares structural framework already in publication, see the AI Governance Failure Model.

Bring ADM into the conversation.

A 30–45 minute advisory call covers the decisions your organization is currently making, where decision discipline is breaking down, and how ADM would be applied to your operating context. No sales process — a focused conversation about where coordination is producing the most exposure.