Reopen a legacy system exception whenever a fact it depends on changes: a vulnerability in the system is actively exploited, a new connection appears, the owner changes, a control fails a test, the vendor status changes, data sensitivity rises, an incident happens nearby, or the retirement date slips. Calendar reviews alone miss these.
Why events beat calendars
An annual review catches drift slowly. A legacy exception is built on assumptions: the system is isolated, the owner knows it, the flaws are understood. When an assumption breaks, the exception is wrong until someone checks it. NIST's plan of action and milestones control describes updating plans based on control assessments, independent audits or reviews, and continuous monitoring activities. That is event driven thinking: new findings change the plan.
Eight triggers
| Trigger | Why it matters | First action |
|---|---|---|
| A vulnerability in the system is added to CISA's Known Exploited Vulnerabilities catalog | Exploitation in the wild raises urgency | Check exposure and controls within a day |
| New inbound or outbound connection requested | The isolation assumption changes | Treat as a change request with security sign-off |
| A compensating control fails a test or alert | The protection may not hold | Fix or add a control, record the gap |
| Owner leaves or role changes | No one is accountable | Name a new owner before the handover ends |
| Vendor or support status changes | Patches, support or the vendor may disappear | Reassess alternatives and the plan |
| Data sensitivity increases | Same flaw, higher stakes | Rescore risk |
| Incident or near miss on a neighbouring system | The segment may not be as isolated as thought | Review logs and rules |
| Retirement milestone slips | The exception lasts longer than planned | Record why, decide on controls for the extension |
CISA describes the KEV catalog as the authoritative source of vulnerabilities that have been exploited in the wild, and advises using it as one input when prioritizing fixes. Matching your inventory against it is a cheap, automatable trigger.
Make the triggers real
- Write them in the exception record. A list of triggers in the record turns them from good intentions into obligations.
- Automate what you can. Match component versions against advisories and the KEV list, and alert the owner.
- Tie change management to the exception. Any change ticket touching the system or its firewall rules should flag the linked exception.
- Give owners a shortcut. A one-line way to say "something changed" should exist.
What a triggered review looks like
Keep it small. Confirm the facts, check each compensating control still works, update the risk statement, decide to continue, strengthen or end the exception, and record the decision and date. Most triggered reviews take under an hour.
What to avoid
- Reviewing only the paperwork. Test the controls.
- Treating a trigger as noise because the last one was nothing.
- Letting the person who approved the exception be the only reviewer when the trigger is their own change.
Try it yourself
Click through it at your own pace, or open it full screen. Step through it to see how a newly disclosed issue can be surfaced against what you run.
Quick check
How many triggers should I list?
Five to eight that people will remember. Too many and nobody uses the list.
Does a calendar review still matter?
Yes. It catches slow drift that no single event reveals. Use both.
Sources
- NIST SP 800-53 Rev 5 control catalog (OSCAL JSON, NIST oscal-content repository) (CA-5 Plan of Action and Milestones)
- CISA Known Exploited Vulnerabilities Catalog
Last reviewed: 19 October 2026.
