What it means
Residual risk is what remains after the safeguards you have actually implemented and assessed. It is different from the risk before treatment and from the lower risk you hope to reach after unfinished work. Controls can reduce the chance of an event, its consequences, or both, without removing every possibility of harm.
Record the remaining scenario in ordinary language. Include control coverage, known bypasses, dependencies, and uncertainty. Someone with appropriate authority must decide whether the remainder is acceptable, needs further treatment, or requires stopping the activity. That decision should have review conditions rather than last forever.
The idea at a glance / Risk
Count safeguards that actually work.
Restricting exports to one store closes one path. Own-store misuse and untested routes still need a risk decision.
Fictional MetroMart R61, 25 September 2026 at 10:30 UTC. W9 is now operating on the export API; SV-4 belongs to Store A. Tests use synthetic records.
READ THE PICTURE
Read the evidence and limits
W9 refuses Store B and still permits Store A. A stolen session could misuse that remaining access. Unfinished sign-in changes contribute no protection; Morgan’s decision is pending.
Keep in mindThese tests cover one account and one API. Other clients, policy bypasses, theft frequency, and real harm need assessment. No acceptance or zero-risk claim is shown.
Read the complete example
- Read the evidence and limits. W9 refuses Store B and still permits Store A. A stolen session could misuse that remaining access. Unfinished sign-in changes contribute no protection; Morgan’s decision is pending. This is a later state of the R61 case, not a control silently added to its original 09:00 assessment. At 10:00 UTC on 25 September 2026, MetroMart implements W9 on the export API so SV-4 can export only its assigned Store A records. At 10:15, independent controlled tests T62 and T63 use the same ordinary authenticated account: T62 refuses a Store B export before any record is returned; T63 returns synthetic Store A records. These observations support the changed store scope for this chosen account, request path, and configuration. The original all-store permission is no longer the observed state on that API. A stolen equivalent session could still misuse the allowed Store A export, so possible own-store disclosure and response effort remain. Existing stolen-session risk is not erased by narrowing permission. Other accounts, export clients, ownership mappings, failure modes, and deployment coverage have not been tested in this picture. The frequency of session theft and magnitude of a real disclosure also remain unresolved. A proposed stronger sign-in design is unfinished and provides no protection to count at this snapshot; its effect on future sign-ins and already-issued sessions would require separate design and tests. Morgan owns the remaining-risk decision, which is pending at 10:30; review is due 28 September and should reopen sooner if W9 changes or a scope test fails. No formal acceptance, automatic subtraction of scores, or risk-free outcome is depicted.
These tests cover one account and one API. Other clients, policy bypasses, theft frequency, and real harm need assessment. No acceptance or zero-risk claim is shown.
Diagram references: NIST SP 800-30 Rev. 1 - risk factors, assumptions and assessment limits
AN ILLUSTRATIVE SCENARIO
A factory supplier connection
A manufacturer restricts a supplier's remote maintenance connection to one production cell and requires time-limited approval. This reduces the opportunity for unattended access and limits reachable equipment. Remaining risk includes misuse during an approved session, a compromised maintenance endpoint, and disruption within the permitted cell. Operations and security document those possibilities, arrange session monitoring, and agree to reassess after a supplier change or a failed access review. The new controls improve the position without making the connection risk-free.
Put it to work
- Revisit the original risk scenario using evidence that each selected safeguard is implemented, covers the intended systems, and works.
- Describe what can still go wrong, its plausible consequences, and any assumptions that materially influence the assessment.
- Record the authorized decision, owner, review date, and triggers for reopening it; track unfinished improvements separately from operating controls.
How to check your work
Ask the owner to explain the remaining exposure and acceptance conditions. Compare that explanation with test evidence, open actions, and the current environment rather than the planned design alone.
Connect the ideas
- Risk
The potential for harm, assessed using what could happen, how likely it is, its impact, and what remains uncertain.
- Control
A process, configuration, or technology meant to reduce a named risk or detect a named failure.
- Uncertainty
What you still do not know, written explicitly so it is not filled with false precision.
- Compensating control
An alternative safeguard used in place of a specified control, with evidence that it provides comparable protection for the intended security objective.