The Known-Unknown Matrix is a risk analysis framework that classifies uncertainties by whether they are known or unknown to the organisation. It helps security and project teams separate known risks, acknowledged gaps, and blind spots so they can prioritise controls, assumptions, testing and contingency planning.
What the Known-Unknown Matrix does
The Known-Unknown Matrix is a decision aid for separating what an organisation knows from what it does not know, so teams can distinguish visible risk from uncertainty, assumption gaps, and blind spots before they shape plans or controls.
Its value is not in scoring risk numerically, but in forcing a clearer conversation about confidence. By mapping uncertainties explicitly, project and security teams can avoid treating untested assumptions as facts, or ignoring unknowns simply because they are hard to quantify.
Used well, it turns ambiguity into a manageable work item. Known issues can be assigned, unknowns can be explored, and the most consequential unknowns can be tested first so that control decisions are based on evidence rather than optimism.
How to read the matrix in practice
The useful distinction is between known knowns, known unknowns, unknown knowns, and unknown unknowns. Each category points to a different management response: verified facts, acknowledged gaps, hidden knowledge, or blind spots that may only emerge through testing, review, or incidents.
For security work, the matrix helps teams ask sharper questions about assumptions such as asset coverage, identity ownership, logging completeness, dependency visibility, and whether a control is actually proven to work in the environment it is meant to protect.
That makes the framework especially helpful during planning, architecture review, assurance work, and operational readiness exercises, where the real problem is often not a lack of controls but a lack of confidence in what has been observed and validated.
Why the framework matters for security and delivery risk
Unrecognised uncertainty is a common source of avoidable failure. If teams assume a dependency is understood when it is not, they may under-test, overtrust an integration, or miss a failure mode that was never surfaced in design or review.
The matrix is also useful when different stakeholders hold different levels of knowledge. In complex programmes, one group may know a risk exists while another only discovers it late, creating schedule pressure, rework, or control shortcuts that increase exposure.
Because it makes uncertainty visible, the framework supports better prioritisation. A small number of unknowns may matter more than a long list of already understood issues, especially when those unknowns affect resilience, assurance, or incident response planning.
Where the Known-Unknown Matrix is strongest and where it falls short
The matrix is strongest as a thinking tool, not a substitute for evidence. It helps structure discussion, but it does not itself measure likelihood, impact, or control effectiveness, so it should sit alongside testing, inventories, reviews, and incident learning.
It can also be misused when teams stop at classification and do not turn the output into action. A well-formed matrix should lead to specific follow-up, such as validation work, ownership assignments, or decisions about what remains acceptable to leave uncertain.
Its limits are important: the framework is only as good as the honesty of the people using it. If blind spots are politically inconvenient, they may be omitted, which means the value of the matrix depends on disciplined participation and a willingness to surface uncomfortable gaps.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | The matrix helps organisations structure how they identify and prioritise uncertainty in risk management. |
| ID.RA-01 — Asset Vulnerabilities are Identified and Documented | The framework depends on knowing what is understood versus what still needs discovery or validation. | |
| GV.OC-03 — Roles, Responsibilities, and Authorities | Using the matrix well requires clear ownership for closing unknowns and validating assumptions. | |
| Recommendation — Use GV.RM-01 to define how unknowns are surfaced, ranked and tracked in risk decisions. Apply ID.RA-01 to capture known gaps and convert blind spots into documented assessment work. Use GV.OC-03 to assign ownership for resolving high-priority unknowns and assumption gaps. | ||
| CIS Controls v8 | CIS-1 — Enterprise Asset Inventory and Control | Unknowns often persist because inventories are incomplete or untrusted. |
| CIS-18 — Penetration Testing | Testing is a direct way to convert unknowns into knowns before they become incidents. | |
| Recommendation — Use CIS-1 to reduce blind spots by improving asset visibility and scope confidence. Use CIS-18 to validate uncertain assumptions and expose hidden failure modes through testing. | ||
Related resources from NHI Mgmt Group
- What breaks when organisations lack visibility into known and unknown data during M&A?
- What is the difference between known knowns, known unknowns, and unknown unknowns in an application inventory?
- Why do poorly known or unknown users create disproportionate privacy risk in healthcare systems?
- What is the difference between spotting a known fraud pattern and building detection for unknown fraud patterns?