Six questions before you assess a threat

A threat assessment written without context is a description of an adversary. It reads well, it is often accurate, and it does not tell anyone what to do, because it never established what was at stake or who was waiting.

MATATC is the structure that comes first. Six elements, and for most problems each one is a sentence or two. It is not a template to be filled in for its own sake; each element exists to catch a specific failure that turns up over and over in assessments that went sideways.

Mission: what must succeed?

What outcome, service, or business function matters here? What has to be protected, maintained, or accomplished, and what would failure actually look like?

Starting anywhere else is the most common error in the whole field. An assessment that opens with the adversary ends up ranking threats by how interesting they are rather than by what they would cost, and those two orderings are rarely the same. Naming the mission first fixes the yardstick before anything gets measured against it.

The failure question is worth answering literally. "Payroll does not run on Friday" is a different problem from "customer payment data is exposed," and a control that helps one may do nothing for the other.

Adversary: who can affect the mission, and what can they do?

Which actors are relevant here. What capability, access, knowledge, or intent matters. And what they are realistically able or likely to accomplish in this environment, which is the qualifier that does the work.

A capability an adversary has demonstrated somewhere else is not a capability against you until it meets your terrain. The point of putting adversary second rather than first is that it is now bounded by a mission, so the question is not "what can they do" in the abstract but "what can they do to this."

Terrain: where does the activity occur?

Which systems, identities, networks, cloud services, vendors, and dependencies matter. Where an adversary could enter, move, hide, persist, or be observed. And what counts as cyber key terrain for this particular mission.

Two things fall out of this that nothing else in the process produces. The first is that key terrain is mission-specific: the systems that matter for keeping payroll running are not the ones that matter for protecting product designs, and an organization-wide list of critical assets tends to be so long it stops discriminating.

The second is the phrase "or be observed." Terrain is not only where an adversary can act, it is where you can see. Working out the two together is what makes the collection step realistic later on, instead of producing questions that depend on visibility nobody has.

Assets: what can we use, and what constrains us?

People, processes, technologies, information, and collection assets. Then, for the collection assets that matter, their ARSC:

• Availability. Can we actually get to it, now, for this?
• Reliability. Does it produce consistent, trustworthy results?
• Suitability. Does it answer this kind of question, or just some question?
• Connectivity. Can what it produces reach the person who needs it, in time?

And the constraints, honestly: legal, policy, technical, resource, visibility, access. This is the element most often filled in optimistically, and optimism here is expensive, because every requirement written afterwards inherits it. A logging platform that holds seven days of data is a different asset from one that holds a year, and the difference only shows up when someone asks a question about last month.

Time: when must we know?

What decision deadline or operational window exists. How fast the relevant conditions could change. And how much lead time collection, analysis, and reporting actually need.

The gap between the second and third is the whole answer. If conditions change in minutes and your reporting path takes a day, no amount of analytical quality closes that, and the right response is to change the path rather than to write a better assessment into an empty room.

Customer: who needs the answer?

Who the intelligence customer and decision authority is. What decision they own. What format, level of detail, delivery method, and timing they need.

Format is not a courtesy. An assessment written at the wrong level of detail for the person receiving it does not get read, and an unread assessment supports no decision no matter how good it is. This is also the element that catches work with no customer at all, which is more common than anyone likes to admit and is best caught at the start rather than at the delivery.

Then say what it revealed

The six elements are input. The output is four short statements, and this is where the analysis actually happens:

• The most significant finding. What matters most to mission success or failure.
• The critical intelligence gap. What must be known to reduce uncertainty around the decision.
• The key assumption to monitor. What you are treating as true, and what would invalidate it.
• The decision this must support, and who owns it.

The assumption line is the one to resist skipping. Every assessment rests on things taken as given, and the difference between a robust one and a brittle one is usually not the quality of the analysis but whether anybody wrote down what it was standing on. An assumption you have named can be watched. One you have not is simply a surprise that has not happened yet.

Done properly this takes minutes, not days, and it is the cheapest step in the process. The gap it exposes is what the intelligence requirement gets written about, and a requirement written without it tends to be a question about the adversary when the organization needed a question about itself.

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