The priority matrix

About 18 min read

On this page

R Pillar 02 of 03

Risk is a structured judgment, not a feeling. One scoring model does the work: ASSURED's Risk-Based Alert Triage Matrix (RATM), read off a three-by-three triage matrix, with MITRE ATT&CK supplying the vocabulary and vulnerability signals (CVSS, KEV, EPSS) supplying input where a vulnerability is in play.

Five moves

Real triage at this phase is five moves. Everything else on this page exists to make them repeatable across analysts.

1. Score impact: if this is real, how bad?
2. Score likelihood and record confidence beside it. Unknown is not Low.
3. Read the matrix for the cell and its priority band.
4. Apply the override rules, and name the one that fired.
5. Recommend the move for the band. The Escalation decision makes the call.

One scoring model, two supporting lenses

A structured assessment makes Risk repeatable across analysts and incidents: it reduces variability from individual judgment, creates a shared vocabulary for handoff, and speeds onboarding. Two of the lenses here are industry standards: MITRE ATT&CK MITRE ATT&CK MITRE's public knowledge base of adversary tactics, techniques and procedures observed in real intrusions, with Enterprise, Mobile and ICS matrices. Enterprise v19 (April 2026) split Defense Evasion into Stealth and Defense Impairment. Triage uses it as a shared vocabulary: map what the evidence shows to technique IDs, record the version, and remember that a mapping names behavior without scoring it. See the ATT&CK Tactic, Technique and Procedure entries. and CVSS Common Vulnerability Scoring System (CVSS) FIRST's standard for scoring a vulnerability's technical severity from 0 to 10; version 4.0 (2023) is current, and 3.1 scores are still common. Severity is not risk: CVSS knows nothing about your exposure or whether the bug is being exploited. Check CISA KEV and EPSS for urgency, and the asset's criticality for impact. . The RATM is this methodology’s own construct. Adapt its rubric to your industry, regulatory requirements Regulatory Requirements The legal and contractual obligations that attach to specific data types, industries and companies, such as GDPR, HIPAA, PCI DSS (a card-industry standard enforced by contract rather than statute), state breach laws such as California's 30-day clock, the SEC disclosure rule for public companies, and EU regimes such as NIS2 and DORA, including breach-notification deadlines. They matter in triage because an incident touching regulated data starts a clock the response has to honor. , and risk tolerance; what matters is that the whole team scores from the same calibrated rubric, whatever its anchors say.

---

Risk-Based Alert Triage Matrix

The RATM scores a case across four dimensions and reduces them to the two axes of the triage matrix further down this page. Asset criticality and business impact make up the impact axis. Threat actor intent and exploitation & scope inform the likelihood axis, which is an estimate, from the evidence, of how probable it is that the activity is malicious or unauthorized. Confidence in that estimate is recorded beside it. Score the dimensions, reduce them to the two axes, read the default action off the matrix.

The reduction is rule-based, so two analysts working the same facts should land on the same cell; regular calibration sessions on shared cases are what make that true in practice:

• Impact is the higher of asset criticality and business impact. A crown-jewel system with no business effect observed yet still scores High, because impact answers “if this is real, how bad,” not “how bad so far.” Footprint reaches impact here: asset criticality scores the highest-value asset in confirmed reach, so spread toward a more valuable asset raises the score.
• Likelihood is an estimate, informed by the evidence and never raised above it. Threat actor intent and exploitation & scope (did it succeed here?) inform the estimate; sophistication is not a substitute for evidence. The calibration factors on the impact + likelihood page may move likelihood by at most one step, and only with the reason written in the case (for example, the observed exploit needs a privilege the account does not hold). They never raise it above what the evidence supports.
• Confidence is its own line. Analytic confidence in the likelihood estimate is scored on the shared confidence rubric and recorded beside the cell. It does not move the cell.
• Unknown is not Low. When the evidence that would decide the question could not be examined (telemetry missing, a source unqueried, a join failed), likelihood cannot read Low: it reads Medium at minimum, confidence reads Low, and the gap is recorded as an open question. A dimension that cannot be assessed scores Medium at minimum on the same rule. “We could not check” never reads the matrix from the same cell as “we checked and it is clean.”

Where the likelihood calibration factors land in the RATM

Calibration factor (impact + likelihood page)	RATM dimension it feeds
Threat actor sophistication	Threat actor intent
Exploitability	Exploitation & scope (could it work on this target, and did it?)
Control coverage	Exploitation & scope (did a control stop it?)
Base rates and history	No dimension: a prior, noted in the likelihood rationale with counts from case records. It never substitutes for this case’s evidence.

Scoring rubric: how to convert observations into High / Medium / Low

The four scoring dimensions above are the categories. The table below is the operational rubric: what counts as High, Medium, or Low for each. Calibrate the thresholds to your environment, but start from these defaults so two analysts working the same case land at the same score.

Calibrating the rubric. The thresholds above are starting defaults. Most teams make two adjustments:

1. Anchor asset criticality High to your actual regulated-asset inventory, not a textbook one. If you have no PCI footprint, “regulated-data store” needs a different anchor.
2. Treat threat actor intent High as a confidence-gated upgrade: if attribution is speculative, score Medium and record the upgrade path in the RATM record.

Then check that the rubric holds in practice: have two analysts score the same sampled cases each month, track how often they land on the same cell, and talk through every disagreement.

---

The triage matrix in practice

The triage matrix is the practical output: impact and likelihood combine into a priority band and a recommended move. Likelihood here means what Impact + likelihood defines: how probable it is, given the evidence, that the activity is malicious or unauthorized. Confidence is recorded beside the cell. Whether an attack will continue or spread is not a likelihood question: footprint reaches the matrix through impact (the confirmed-reach rule) and through the lateral-movement escalation criterion. This page owns the band definitions: the cell-to-band mapping, the override rules and the default clocks for each band. The priority levels on the Escalation criteria page explain only what each band means for the close-or-escalate decision.

Risk recommends; the Escalation decision decides, by one rule:

The override rules: when the matrix is not the last word

The matrix cell is the default action. Exactly three overrides can modify it, applied in this order, and the case record names the rule that fired. These are the same rules the Escalation criteria page enforces; there is one contract, stated here, consumed there.

Run the hardest case through the contract to see it hold: a domain controller alert with weak, incomplete evidence. Impact is High (asset criticality). The evidence is missing, not benign-leaning, so likelihood reads Medium with confidence Low; the cell is High/Medium and the action is P2, escalate within 4 hours, on every page of this site. If instead the evidence is present and points benign, it is High/Low: P3 on the tightened clock. Neither branch waits 24 hours, and neither branch pages IR at 3 a.m. on asset value alone.

Default clocks for each band

The clocks are written for a shifted, multi-analyst SOC. On a small or single-person team, translate them without loosening them: “escalate” means engaging whatever your escalation path is (an on-call engineer, an MSSP, an IR retainer), “within 4 hours” still means hours, not tomorrow, and “within 24 hours” means before the case goes stale. What must survive the translation is the ordering: P1 interrupts whatever you are doing, P2 moves within hours, P3 waits its turn against a named trigger.

Try it: score a case through the matrix

Score a case of your own, or one from the worked examples, and watch the rules on this page act on it. The exercise reads the cells, clocks and definitions from the same source as the matrix above. It reads likelihood the way the worked cases do: exploitation & scope sets it, a higher threat actor intent can raise it by one step (with the reason written in the case), and a lower intent never drags it down. In a real case the likelihood estimate is the analyst’s judgment, written with a rationale; the exercise shows how the rules bound that judgment, not a substitute for it.

Asset criticality

The highest-value asset in confirmed reach.

HighMediumLow

Business impact

Downstream effect if the activity is real.

HighMediumLow

Threat actor intent

Targeting, tooling and corroborated attribution.

HighMediumLow

Exploitation & scope

What is confirmed to have happened here.

HighMediumLow

Evidence and confidence

The evidence that would decide likelihood could not be examined (telemetry missing, a source unqueried, a join failed).

Analytic confidence in the likelihood estimate, on the shared rubric: HighMediumLow

Escalation criteria and controls

An escalation criterion is supported by the evidence (malicious activity not fully contained, a business-critical asset touched, lateral movement or exfiltration, or an active campaign).

A control blocked or quarantined the activity, with no execution or follow-on evidence.

What the rules produce for this case

Impact axis
Likelihood axis
Confidence
Matrix cell
Priority
Clocks
Overrides and rules that fired
Recommended move

Recommending identity containment

For a compromised identity, the recommended move names the order, because the instinctive step is the wrong one. Whether a password reset ends existing sessions depends on the identity provider and how the reset is done, and it never removes an OAuth consent grant or an MFA method the attacker registered. Preserve before you contain, cut access with reversible actions, then verify:

1. Preserve: the sign-in and session records, the relevant audit logs, mailbox rules, app grants, and a snapshot of the account’s MFA methods and devices.
2. Contain, reversibly (pre-authorized): block sign-in, revoke all sessions and refresh tokens, disable sign-in for any app the session consented to, and disable hiding or forwarding rules. A session that a downstream platform already issued behind SSO needs that platform’s owner to end it there.
3. Verify: the attacker’s session stops presenting. Access tokens already issued can stay valid for an hour or more (a random 60 to 90 minutes by default on Microsoft Entra ID) where continuous access evaluation is not enforced, so check, do not assume.
4. With IR or owner approval: reset the password, remove the app’s grants, and remove MFA methods or devices the user did not register. These cannot be undone, so they are not on the pre-authorized list unless the protocol names them for the scenario.

Any user who reached the credential step of a phishing kit is credential-exposed until the password is reset, sessions are revoked and MFA methods are reviewed. The identity-persistence sweep lists the eight places an attacker leaves a way back in (MFA methods, registered devices, app grants, mailbox rules and more) and where each is logged. Case C runs this order with its timestamps.

Score the case, and watch the entity

The case, not the alert, is the unit of work. Alerts on the same entity and window, or under one vendor incident ID, form one case, and the riskiest member sets its level (see correlated cases). Across cases, watch the entity too. Several P4 closes on the same identity or host within days are a signal in their own right, and slow attacks live in exactly that gap. A practical default: three Low/Low closes on the same account in seven days trigger a re-score of the entity’s recent activity as one case before the next alert on it closes alone, with the earlier cases it folds in named in the record. The fast path applies the same idea at Level 0: three pattern closes on one entity in seven days force a Level 1 review.

When the activity verdict stays undetermined

Some cases end the loop without an answer: the vendor’s logs have not arrived, the owner has not replied, the one source that would decide it is out of retention. Undetermined is a legitimate activity verdict, but it is not a benign close and not a place to park a case. Score it like any other case, with the evidence rules applied:

• Score the gap, not a guess. Likelihood reads Medium at minimum and confidence reads Low, because unknown is not Low. The cell, and so the band and its clock, follow from that: a High-impact undetermined case is P2.
• Name the gap and the re-score trigger. Record which question is open, what evidence would answer it, and a named trigger with a time: the log delivery, the end of a forward watch, the owner’s answer, or a fixed re-score time when nothing better exists.
• At the trigger, re-score. If the new evidence decides it, the case reads its new cell. If it is still undetermined, the Escalation decision applies the E rule to the band: escalate at P1 or P2; at P3 or P4, a documented close is allowed only with the gaps named and a reopen trigger written, or the case moves up a level of depth.

Undetermined is never closed silently, and never held open without a named trigger. Case D runs this rule end to end.

---

MITRE ATT&CK as a risk lens

ATT&CK enters Risk as a structuring vocabulary, not a scoring tool. Mapping to MITRE ATT&CK MITRE ATT&CK MITRE's public knowledge base of adversary tactics, techniques and procedures observed in real intrusions, with Enterprise, Mobile and ICS matrices. Enterprise v19 (April 2026) split Defense Evasion into Stealth and Defense Impairment. Triage uses it as a shared vocabulary: map what the evidence shows to technique IDs, record the version, and remember that a mapping names behavior without scoring it. See the ATT&CK Tactic, Technique and Procedure entries. names what was observed, so the assessment aligns with the broader threat Threat Any circumstance or event with the potential to harm the organization's operations, assets, or people (NIST, from CNSSI 4009). The actor behind it is the threat actor; the weakness it uses is a vulnerability. Classical risk models multiply threat, vulnerability, and impact. ASSURED's RATM does not multiply. It scores threat actor intent and exploitation & scope as their own dimensions and lets them inform likelihood, which never rises above what the evidence supports. Risk is then read from the impact-by-likelihood matrix. landscape; it does not say how much the activity matters in this environment for this asset. Pair the mapping with the RATM rubric to turn technique-level observations into a business-level priority, and record the ATT&CK version you mapped against.

---

Vulnerability signals: CVSS, KEV, EPSS and SSVC

CVSS Common Vulnerability Scoring System (CVSS) FIRST's standard for scoring a vulnerability's technical severity from 0 to 10; version 4.0 (2023) is current, and 3.1 scores are still common. Severity is not risk: CVSS knows nothing about your exposure or whether the bug is being exploited. Check CISA KEV and EPSS for urgency, and the asset's criticality for impact. scores the technical severity of a vulnerability, not the risk of an alert that involves it, and FIRST, which maintains it, says it should not be used alone to assess risk. Scanners and feeds carry a mix of v3.1 and v4.0 vectors; a v4.0 score should say which metric groups it uses (CVSS-B, CVSS-BT, CVSS-BE, CVSS-BTE), and a bare CVSS-B score is worst-case severity with no threat or environmental context. Expect gaps in the score itself, too: since April 2026 the National Vulnerability Database ( NVD NVD / EUVD Public vulnerability databases: the U.S. National Vulnerability Database (NIST) and the EU Vulnerability Database (ENISA). Both enrich CVE records with severity scores, affected products and references. ) no longer routinely adds its own CVSS score where the CVE Numbering Authority (CNA) that published the record supplied one, and many lower-priority CVEs are not enriched at all, so a feed may carry a CNA-only score, mixed v3.1 and v4.0 vectors, or no score.

Read the score beside three exploitation signals: membership in CISA’s Known Exploited Vulnerabilities (KEV) Known Exploited Vulnerabilities (KEV) Catalog CISA's list of vulnerabilities with reliable evidence of exploitation in the wild, each with a remediation due date for US federal agencies. A CVE on KEV is being exploited somewhere now, which makes it a stronger urgency signal than a high CVSS score. Check KEV first, then EPSS. catalog (CISA), the EPSS Exploit Prediction Scoring System (EPSS) FIRST's model that estimates the probability a published CVE will be exploited in the wild in the next 30 days. An urgency input, not a risk score: it knows nothing about your assets, exposure or controls. Check CISA KEV first, then EPSS. See the priority matrix. (FIRST, v4) estimate of the probability of exploitation in the next 30 days, and the SSVC decision points (exploitation, exposure, automatability, technical impact) that CISA’s BOD 26-04 (June 2026) now uses to set federal remediation timelines; it supersedes BOD 22-01 and BOD 19-02. KEV membership or a high EPSS score usually outranks the base score: a 9.8 nobody exploits matters less today than a 7.2 being actively used.

Know EPSS’s limits: it is not a risk score, it scores only published CVEs, it knows nothing about your assets, exposure or compensating controls, and NIST’s CSWP 41 (2025) notes it underestimates vulnerabilities already observed being exploited. Check KEV first, then EPSS. Absence from KEV is not evidence of safety, though: unknown is not Low.

For an alert that names a CVE, the decisive questions are about this target, not the score:

1. Is the target vulnerable? It runs an affected version and configuration.
2. Is it reachable? The vulnerable surface is exposed to where the attempt came from.
3. Is the CVE in KEV, or high on EPSS?
4. Did the attempt succeed? Execution, a new process, an outbound callback.

Score exploitation & scope from question 4, not from the CVSS score. An intrusion detection system (IDS) hit for a CVE against a patched host is an attempt, scored Low, whatever its base score; questions 2 and 3 set how fast the patch or block should follow elsewhere.

Next up

What a benign close teaches

Read about benign closes