After you implement a control, is the risk gone?
Short answer
No. Controls reduce risk; they rarely eliminate it. NIST defines residual risk as the portion of risk remaining after security measures have been applied. That leftover must be measured, recorded in the risk register, and either formally accepted by the risk owner or reduced further. Calling a risk closed because a control exists hides control failures, gaps, and new threats.
New GRC analysts often mark a risk as closed the moment a mitigation ships. The register should say something more careful.
The definition
The NIST glossary, citing NIST SP 800-30 Rev. 1 among others, defines residual risk as the portion of risk remaining after security measures have been applied. NISTIR 8286 phrases it as the risk that remains after risk responses have been documented and performed.
What you do with it
- Re-assess likelihood and impact assuming the control works as designed.
- Record the residual value next to the inherent value in the risk register.
- Decide: the accountable owner accepts it formally, or you apply further treatment (more controls, transfer, avoidance).
- Review it periodically, since controls decay and threats change.
Why the distractors fail
Risk does not drop to zero just because a control exists, and the type of control (technical, policy, process) is not what determines that. Saying the risk doubles is an unsupported exaggeration: a well-designed control reduces risk.
What interviewers want
A clear "no, residual risk remains", paired with the habit of documenting and getting it accepted by an owner.
Likely follow-ups
- How do inherent risk and residual risk differ, and when do you assess each?
- Who has authority to accept residual risk, and what should the record contain?
- How would you test whether a control really reduces risk as assumed?