DE.AE-08 says incidents are declared when adverse events meet the defined incident criteria. Two things are required: written criteria, and the habit of using them. Declaring an incident starts the response plan, the clock for notifications, and the record keeping.
CSF is voluntary guidance. There is no CSF certification.
What good looks like
Your criteria say what turns an event into an incident, for example confirmed unauthorized access, malware on a production host, or loss of customer data. Responders apply the criteria to what is known and what is assumed about the activity, and they account for known false positives. A named person has authority to declare.
How to implement it
- Write the criteria on one page, with examples for each severity level.
- Name the incident commander role and a backup who may declare.
- Add a short decision checklist to your alert runbooks: does this match any criteria, yes or no, and who decided.
- Keep a list of known false positives so they do not trigger declarations.
- Practice with a tabletop exercise twice a year.
- After each declaration, review whether the criteria worked and adjust them.
Try it yourself
Click through it at your own pace, or open it full screen.
A worked example
A support engineer reports that a customer received an email that appears to come from the company but was not sent by it. Is that an incident? With written criteria, the answer is quick. The criteria list "evidence that our domain or accounts are being used to impersonate us to customers" as a low severity incident. The on call lead declares it, opens a record, and starts the checklist: review email authentication settings, search for compromised accounts, and notify the customer contact.
Without criteria, the same event might get a long chat thread and no record, and the team would debate whether it counted.
Writing criteria people can use
Keep the criteria concrete. List observable conditions rather than feelings. Examples at a low level: a phishing email reported by a customer that uses your brand. Medium: malware detected on a single non production device. High: confirmed unauthorized access to a production system or customer data. Critical: ransomware or confirmed theft of regulated data. Add a rule for doubt: when two people disagree, the more senior responder decides and the reasoning is recorded.
Known false positives
NIST's examples note taking known false positives into account when applying criteria. Maintain a short list of recurring harmless events, such as a vulnerability scanner that trips intrusion alerts every Monday. Note the reason each is safe and review the list quarterly so that a harmless pattern is not used to hide a real one.
After the declaration
Declaring starts several clocks: internal notification, any contractual or legal reporting deadlines, and evidence preservation. Link this outcome to your response plan so that declaring is not the end of the work but the first step of a known sequence.
Connecting detection to response
DE.AE-08 is the bridge between the DETECT and RESPOND functions. Once an incident is declared, your response plan takes over: assign a lead, open a communication channel, start a timeline, preserve evidence, and decide who must be told. Review the plan alongside the criteria so that every severity level points to a clear set of next steps.
Records an auditor or customer will want
Keep a simple incident register with the date, how the event was detected, the criteria that were met, the severity, who declared it, and the outcome. Include events that were reviewed and not declared, with the reason. After each declared incident, hold a short review without blame, record lessons, and update the criteria if they proved unclear.
Training
People hesitate to declare when they fear blame. Say plainly, in writing, that declaring in good faith is expected and that a false alarm is cheaper than a late one. Run a tabletop twice a year with a realistic scenario, such as a leaked access key or a ransomware message on a shared drive, and watch how long it takes to decide.
Evidence to collect
- The written incident criteria.
- Role assignments for declaring.
- Records of declared incidents and the decision rationale.
- Tabletop exercise notes.
Common gaps
Criteria that exist only in the response plan nobody reads. Fear of declaring, so events linger as "investigations". No record of why something was or was not declared. No backup decision maker.
Quick check
Is it better to declare early or late?
Criteria should settle it. Declaring when criteria are met keeps response consistent and gives you a clean timeline. You can always downgrade later.
Sources
- NIST Cybersecurity Framework 2.0 (NIST CSWP 29), DE.AE-08 and its implementation examples.
