The five stages of cyber mission analysis

Every stage of this exists to reduce uncertainty around a decision. That sentence is worth holding onto, because it is the thing that tells you when a stage is finished and when a piece of work has quietly stopped being intelligence and become research.

Each stage produces a named output. If you cannot name the output, the stage is not done, and moving on means the next stage is standing on something that does not exist yet.

1. Mission analysis

Output: the mission and the problem.

What are we trying to accomplish, and what problem must leadership solve? Two questions, and they are not the same one. The mission is the thing that has to keep working. The problem is what stands between leadership and a decision about it.

A program that starts at stage two instead produces environmental assessments that are accurate and unusable, because there is no stated mission to judge relevance against. Everything looks somewhat relevant when nothing is the point.

2. IPOE

Output: an environmental and adversary assessment.

What environment do we operate in? Who can affect us? What are they able or likely to do? What constraints limit our options?

Four movements inside this one, in order: define the environment, describe its effects, evaluate the adversary, and determine their likely courses of action. The order matters. Evaluating an adversary before describing the environment produces an assessment of what they can do in general rather than what they can do here, and general capability is not a threat until it meets your terrain.

The constraints question belongs here rather than later, which people find counterintuitive. Knowing what limits your options changes what is worth asking, and discovering a constraint at collection time means the requirement was written for an organization you do not have.

3. Intelligence requirements

Output: decision-linked requirements.

What do we need to know to support a decision?

Note the phrasing of the output. Not "requirements" but decision-linked requirements. A requirement whose answer changes nothing is the most common defect in the whole process, and it is expensive precisely because it is invisible: the work gets done, the answer arrives, it is accurate, and nothing happens.

Stage three is also where the honest failure happens. If you cannot write a decision-linked requirement, that usually means stage one was skipped, and the fix is to go back rather than to write a broader question.

4. Collection planning

Output: a collection plan.

Where will the answers come from, and can your collection assets actually provide them?

The chain runs: requirement, specific information requirement, indicator, source, threshold, recipient, decision. Written out like that it looks laborious, and the reason to write it out is that every break in the chain is silent. A source with no threshold produces data nobody acts on. A threshold with no recipient produces an alert nobody receives. Each link failing looks exactly like the intelligence not mattering.

Then each collection asset gets assessed on ARSC: availability, reliability, suitability, connectivity. The last one is the one most often assumed. An asset that produces a perfect answer with no path to the decision maker has not answered anything.

5. Decision brief

Output: decision-ready intelligence.

What does leadership need to understand and decide?

Decision-ready is a higher bar than accurate. It means the recipient can act on it without going back for translation: what is happening, what it means for the mission, what the options are, and what is still uncertain. Confidence and uncertainty belong in the brief, not left out to make it read more strongly. A decision maker who is not told what is assumed cannot weigh it, and will discover the assumption at the worst possible time.

What restarts the cycle

This is the part most often left off a process diagram, and it is where most of the real work lives. Five things restart it: a change in the mission, the environment, the adversary, your collection capability, or the decision.

Two of those are unwelcome news. A change in your own collection capability restarts the cycle even if nothing about the threat changed, because a requirement that was collectable last quarter may not be now. And a change in the decision restarts it even when the threat picture is stable, because the requirements were linked to a decision that no longer exists in that form.

Programs that treat this as a one-time exercise tend to notice the first three and miss the last two, and then cannot work out why a mature process is producing intelligence that lands flat.

The short version

Establish what must succeed. Understand the environment and who can affect it. Turn the important uncertainty into decision-linked questions. Plan collection that can actually answer them and reach someone. Deliver something a leader can decide on.

It scales. The same five stages carry a quarterly strategic assessment and a Monday morning incident, and the difference between those is how long each stage takes, not whether it happens.

What does not work is entering at stage four, which is where a great deal of threat intelligence begins in practice. Collection without a requirement produces a pile, and a pile is not a shortcut to a decision. It is a thing somebody now has to triage.

Drawn from the Cyber Mission Analysis Process Map by Christopher G. Ruel and Ajay Menendez, authors of Cyber Threat Intelligence Planning: A Special Forces Approach.