DE.AE-08: Incidents are declared when adverse events meet the defined incident criteria

To meet the de.ae-08: incidents are declared when adverse events meet the defined incident criteria requirement, you must define clear incident declaration criteria, train your operations teams to apply them consistently, and enforce a time-bound workflow that converts qualifying adverse events into formally declared incidents with documented approval, severity, and notifications. The control passes only if it is repeatable and evidenced.

Key takeaways:

• Maintain a written, measurable “incident criteria” standard that separates events from incidents and maps to severity.
• Route every qualifying adverse event through a documented declaration workflow with accountable decision-makers.
• Retain evidence that criteria were applied consistently (tickets, timelines, approvals, comms, and post-incident records).

DE.AE-08 sits in the “Detect – Adverse Events” space of NIST CSF 2.0. It is a deceptively operational requirement that often fails during audits for a simple reason: teams detect lots of security “events,” but they cannot prove when and why those events became “incidents.” That gap creates downstream failures: delayed response, missed notifications, inconsistent escalation, and poor executive visibility.

For a Compliance Officer, CCO, or GRC lead, the fastest path to operationalizing DE.AE-08 is to treat “incident declaration” as a governed decision with objective criteria, not as an informal judgment call by whoever is on-call. You need (1) defined incident criteria, (2) a workflow that forces a declare-or-not decision, (3) documented ownership, and (4) evidence that the workflow is used in real operations.

This page gives requirement-level implementation guidance you can hand to your SOC lead, IR lead, or IT operations manager and then audit internally. It also highlights the exam hangups: unclear definitions, inconsistent severity scoring, “shadow incidents” handled in chat, and missing timestamps.

Regulatory text

Requirement (excerpt): “Incidents are declared when adverse events meet the defined incident criteria.” (NIST CSF 2.0; NIST CSWP 29; NIST CSF 1.1 to 2.0 Core Transition Changes)

What the operator must do

You must:

1. Define “incident criteria” (what properties of an adverse event require formal incident declaration).
2. Ensure the criteria are used in operations so that adverse events that meet the criteria are consistently and promptly declared as incidents.
3. Make incident declaration auditable by capturing who declared it, when, based on what criteria, at what severity, and what actions/notifications were triggered.

Auditors will not accept “we know an incident when we see one.” They will look for a documented decision framework and proof it is followed in tickets and timelines.

Plain-English interpretation

An “adverse event” is a negative security-relevant occurrence (alert, anomaly, suspicious activity, system failure with potential security impact). DE.AE-08 requires you to draw a bright line: when an adverse event crosses a threshold you define, it becomes an incident, and your formal incident response process starts.

Operationally, this is a classification and escalation control:

• Before declaration: you may be investigating, triaging, enriching, and validating.
• At declaration: you commit the organization to a governed response posture (roles, SLAs, communications, evidence preservation, executive visibility).
• After declaration: you manage it as an incident through containment, eradication, recovery, and lessons learned.

Who it applies to

DE.AE-08 applies to any organization operating a cybersecurity program, including:

• Critical infrastructure operators where operational disruption and safety risk drive low tolerance for ambiguity.
• Service organizations (including SaaS and managed service providers) where incident declaration triggers customer communications and contractual obligations.
• Enterprises with SOC/IR functions where volume makes “informal handling” likely.

Operational contexts where this requirement is most tested:

• SOC alert triage and escalation
• IT operations outages with possible security root cause
• Third party incidents (supplier compromise, SaaS breach, MSP tooling compromise)
• Identity and access anomalies (credential theft, impossible travel, privilege misuse)
• Data exposure scenarios (misconfigurations, exfiltration indicators)

What you actually need to do (step-by-step)

Step 1: Define incident declaration criteria (write it like an operator will use it)

Create a short standard that answers: “What must be true for an adverse event to be declared an incident?”

Include, at minimum:

• Scope triggers: types of assets or data involved (production systems, regulated data, privileged identities).
• Impact triggers: confidentiality/integrity/availability impact, customer impact, safety impact.
• Threat triggers: confirmed malware execution, confirmed unauthorized access, exfiltration indicators, lateral movement.
• Control-failure triggers: loss of logging for critical assets, EDR disabled on critical endpoints, key security services outage.
• Third party triggers: credible notice from a third party that your data or access is implicated.

Practical format: a decision matrix. Example:

Criterion category	Declare an incident when…	Evidence examples
Unauthorized access	Access is confirmed or strongly suspected on a production system or privileged account	IAM logs, EDR telemetry, forensic notes
Data exposure	Sensitive data is confirmed exposed outside authorized boundary	DLP alert, cloud access logs, screenshots
Malware	Malware execution is confirmed on a server or multiple endpoints	EDR detections, hash analysis
Service disruption	Outage is plausibly security-driven or affects critical service	monitoring, incident bridge notes

Keep the criteria binary where possible (“declare if X”) and avoid vague language (“significant,” “material”) unless you define it internally with examples.

Step 2: Align criteria to severity levels and response playbooks

Declaration criteria should map to:

• Severity level (how fast you mobilize, who must be paged)
• Minimum response actions (containment steps, evidence preservation)
• Notification decision points (internal stakeholders, customers, regulators, insurers)

This mapping prevents teams from declaring an incident but then responding ad hoc.

Step 3: Implement a single declaration workflow (no “shadow incidents”)

Build a workflow in your ticketing/IR platform with required fields:

• Adverse event ID / alert ID
• “Meets incident criteria?” (yes/no) plus criteria met (multi-select)
• Declared by (name/role)
• Declaration timestamp
• Initial severity
• Incident commander assignment (if applicable)
• Required notifications checklist (internal at minimum)

Force the workflow: if the event meets criteria, the system must create or convert to an incident record. If it does not meet criteria, require a brief rationale and a review path for borderline cases.

Step 4: Establish accountable roles and escalation paths

Define decision authority:

• Primary: SOC lead / IR lead / on-call incident commander
• Backup: IT operations duty manager (for availability-driven adverse events)
• Consulted: Legal/privacy, communications, third party risk, business owner (as needed)

Write a RACI for:

• Declaring the incident
• Approving severity changes
• Approving closure
• Approving external communications

Step 5: Train and test against real examples

Run short tabletop exercises using your own historical alerts:

• Take 10 real adverse events.
• Ask the on-call team to classify them using the criteria.
• Compare results for consistency.
• Adjust criteria where disagreement is frequent.

Training objective: reduce “depends who is working” outcomes.

Step 6: Measure control performance and review exceptions

DE.AE-08 benefits from simple operational metrics (kept internal, used for improvement):

• Volume of adverse events reviewed vs. incidents declared
• Time from detection to declaration (trend, not a published KPI unless you can defend it)
• Overrides and exceptions (who overrode criteria and why)
• Post-incident findings: incidents that should have been declared earlier

Run periodic reviews and document remediation actions (NIST CSF 2.0).

Step 7: Maintain an evidence bundle per review cycle

Package proof so you can answer audits fast:

• Current incident criteria standard
• Workflow screenshots/config exports
• Sampled tickets showing application of criteria
• Training completion records
• Review meeting notes and remediation tracking

Daydream (as a GRC system) becomes relevant when you need to map DE.AE-08 to owners, track review cadence, store evidence bundles, and show auditors a clean lineage from requirement → control → operation → evidence.

Required evidence and artifacts to retain

Keep artifacts that prove both design and operation:

Design evidence

• Incident Response Policy and Incident Declaration Standard (criteria + severity mapping)
• RACI and on-call escalation documentation
• Tool/workflow configuration showing required fields and routing
• Playbooks linked to severity (IR runbooks)

Operational evidence (audit sampling friendly)

• Adverse event tickets with documented decision (“meets criteria” + rationale)
• Incident records with declaration timestamp, declared-by, severity, assignments
• Chat/bridge records or incident timeline notes that corroborate timestamps
• Post-incident review reports showing whether declaration timing was appropriate
• Control performance review notes and tracked exceptions/remediation

Common exam/audit questions and hangups

Auditors tend to focus on consistency and proof. Expect questions like:

1. Show the written criteria. Where is it approved, and who owns it?
2. Show three examples where adverse events met criteria and were declared as incidents. Provide timestamps and who authorized.
3. Show three examples where adverse events did not meet criteria. How did you document the decision?
4. How do you prevent “off-system handling”? (Incidents managed only in chat/email.)
5. How do you handle third party notifications? If a third party reports a compromise, what criteria apply and who declares?

Hangups:

• Criteria exist but are too vague to apply.
• Teams declare incidents inconsistently across regions or business units.
• Incident severity is assigned but not tied to the criteria.
• Event-to-incident conversion lacks an auditable timestamp.

Frequent implementation mistakes and how to avoid them

1. Mistake: Treating declaration as optional.
   Fix: Make “declare vs. don’t declare” a required field for adverse events above a triage threshold.

2. Mistake: Criteria are a paragraph, not a tool.
   Fix: Convert the criteria into a matrix with explicit triggers and examples.

3. Mistake: No evidence of non-incidents.
   Fix: Require a short rationale for “not an incident” decisions on significant adverse events.

4. Mistake: Third party incidents handled outside the same workflow.
   Fix: Route third party notifications through the same declaration process and record them as adverse events that may become incidents.

5. Mistake: Severity inflation or deflation for optics.
   Fix: Tie severity to objective attributes (data type, asset criticality, confirmed access, spread).

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite specific actions.

Risk-wise, weak incident declaration controls lead to predictable outcomes:

• Delayed containment because responders are not mobilized early.
• Missed contractual and customer commitments because “incident” status is unclear.
• Poor governance because executives and Legal learn late or inconsistently.
• Audit findings that cascade into incident response, communications, and risk management deficiencies.

Practical 30/60/90-day execution plan

First 30 days (stabilize and define)

• Draft incident declaration criteria and severity mapping aligned to your business services and data types.
• Assign a single owner for the criteria (usually IR lead with GRC support).
• Implement required fields in your case management tooling (or a stopgap form if tooling changes take time).
• Start collecting a small evidence bundle from live triage decisions.

Days 31–60 (operationalize and train)

• Train SOC/IT on-call and business escalation owners using real internal scenarios.
• Run a calibration session: multiple analysts classify the same adverse events; resolve inconsistencies.
• Put a lightweight governance loop in place: periodic review of declaration decisions, exceptions, and root causes of late declarations.
• Connect criteria to playbooks and notification checklists.

Days 61–90 (prove it works and harden)

• Perform an internal control test: sample adverse events, verify declaration decisions match criteria, verify timestamps and approvals.
• Tune criteria based on false positives/negatives and business impact.
• Formalize evidence packaging: a repeatable folder structure, naming conventions, and reviewer sign-off.
• Consider centralizing control mapping, ownership, and evidence retention in Daydream to reduce audit scramble and improve traceability across teams.

Frequently Asked Questions

What’s the difference between an adverse event and an incident for DE.AE-08?

An adverse event is any negative security-relevant occurrence worth evaluating. An incident is an adverse event that meets your written criteria and triggers your formal incident response workflow and governance.

Who should have authority to declare an incident?

Put declaration authority with an operational leader on the response path (SOC lead or incident commander) and document backups. GRC should not be the runtime decision-maker, but should own governance, review, and evidence.

Do we need to declare an incident for every malware alert?

No. Your criteria should distinguish between routine detections (blocked, no execution, no impact) and conditions that require incident governance (execution, spread, high-value assets, confirmed access).

How do we handle third party notifications that “might” involve us?

Log the notification as an adverse event, apply the same criteria, and document the decision. If you lack facts, declare based on credible indicators plus risk thresholds you define, then adjust severity as evidence improves.

What evidence is most persuasive in an audit?

Time-stamped records showing the adverse event, the criteria checked, who made the declare decision, and the resulting incident record with severity and actions. Auditors want a traceable chain from detection through declaration to response.

We manage incidents in chat during outages. Is that a problem?

Chat can support coordination, but DE.AE-08 requires an auditable declaration record. Create or update an incident ticket at declaration time and link chat/bridge artifacts back to that record.