Short · Governance and risk · 1 min read

The Security Exception That Became Permanent

By Dr. Lin Clark

Exceptions are unavoidable. A legacy system cannot support a control, a vendor needs unusual access, or a deadline makes a proper fix inconvenient. What concerns me is the exception that stays open after its owner leaves and the original justification disappears.

The operational question

The Risk Management Framework treats authorization and monitoring as continuing decisions (Joint Task Force, 2018). An exception needs a named owner, a reason, compensating measures, and a review date. “Business accepted” is not a name.

What the guidance actually says

NIST permits control tailoring to organizational needs (Joint Task Force, 2020). That does not make every deviation irresponsible. It does mean somebody should know what protection was traded away and what would make the trade unacceptable.

Where the plan breaks

Risk assessment considers threats, vulnerabilities, likelihood, and impact (Joint Task Force Transformation Initiative, 2012). An exception approved for one system may spread through shared credentials or new integrations. The old approval does not cover every future dependency.

The evidence I would ask for

The Govern function of CSF 2.0 connects technical risk to oversight (Pascoe et al., 2024). I would give leadership three clear choices: remove the exception, narrow it, or accept the remaining exposure with a review date. Each choice needs a consequence.

The decision that matters

Incident response should be integrated into risk-management activities (Nelson et al., 2025). Put the exception into a tabletop exercise. If it prevents containment or delays recovery, that cost should be visible before the incident.

If your exception register is growing faster than your actual protection, I can help sort out what needs a decision.

References

  • Joint Task Force. (2018). Risk management framework for information systems and organizations (NIST SP 800-37 Rev. 2). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-37r2
  • Joint Task Force. (2020). Security and privacy controls for information systems and organizations (NIST SP 800-53 Rev. 5). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-53r5
  • Joint Task Force Transformation Initiative. (2012). Guide for conducting risk assessments (NIST SP 800-30 Rev. 1). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-30r1
  • Pascoe, C., Quinn, S., & Scarfone, K. (2024). The NIST cybersecurity framework (CSF) 2.0 (NIST CSWP 29). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.CSWP.29
  • Nelson, A., Rekhi, S., Souppaya, M., & Scarfone, K. (2025). Incident response recommendations and considerations for cybersecurity risk management: A CSF 2.0 community profile (NIST SP 800-61 Rev. 3). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-61r3