RS.MA-04 says incidents are escalated or elevated as needed. A small team should be able to say what makes an incident bigger than the person handling it, and who gets called when that happens.
What good looks like
Escalation triggers are written down and specific. Examples: customer data confirmed exposed, an incident open longer than a set number of hours, a legal or contractual notification clock starting, or a critical system down. The contact list for leadership, legal, your insurer and key suppliers is current and reachable at night.
All open incidents sit on one status list that is reviewed on a schedule, so nothing quietly stalls.
How to implement it
- Add an escalation section to your incident plan with triggers mapped to severity levels.
- Name who is told at each level and how (phone first, not email).
- Keep one tracker of open incidents with status, owner and last update time.
- Agree who can pull in outside help such as an incident response retainer firm.
- Test the call tree twice a year.
Evidence to collect
- The escalation criteria and contact list with a review date.
- Tracker export showing status updates.
- One or two past incidents showing the escalation timestamp.
- Tabletop notes showing the call tree was tested.
Common gaps
- Phone numbers out of date after staff changes.
- No trigger based on time, so slow incidents never escalate.
- Executives learn about incidents from customers first.
Quick check
Who should be able to escalate?
Any responder. If only the incident lead can escalate, a stuck lead becomes a stuck incident.
Sources
- NIST, The NIST Cybersecurity Framework (CSF) 2.0, NIST CSWP 29, February 2024: https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf
- NIST CSF 2.0 implementation examples for RS.MA-04, as listed in the CSF 2.0 Reference Tool: https://www.nist.gov/cyberframework
CSF is voluntary guidance. There is no CSF certification, so use it to organize and show your own work.
