DE.AE-08 incident declaration: requirements and evidence

What DE.AE-08 incident declaration asks for in plain terms

A security operations center can have thousands of alerts a day and still have no agreed point where an event becomes an incident. DE.AE-08 asks the organization to close that gap. In NIST Cybersecurity Framework (CSF) 2.0, it is the Subcategory in the Adverse Event Analysis (DE.AE) Category of the Detect Function that sets the handoff from detection to response: an incident is declared when adverse events meet the incident criteria the organization has defined. In the CSF 1.1 to 2.0 Core Transition Changes spreadsheet, NIST shows that DE.AE-08 takes over CSF 1.1 DE.AE-5 under a new identifier, so teams with an older assessment should re-map their existing evidence rather than assume the outcome is new.

The outcome is simple to state and hard to run. The organization must decide, in advance, what counts as an incident, who makes the call, and how known false positives are treated so that the same noisy rule does not open a case every night. NIST's Implementation Examples for DE.AE-08 point to applying incident criteria to both known and assumed characteristics of the activity, and to accounting for known false positives. The criteria, thresholds and decision rights are the organization's to own. An implementation partner can help write them down, wire them into tooling and test them, but the decision to declare stays with the organization's incident owner.

The NIST CSF 2.0 Reference Tool lists informative references that show where this outcome connects to other frameworks. For SP 800-53 Rev. 5.2.0, the references are IR-4 (Incident Handling) and IR-8 (Incident Response Plan). For ISO/IEC 27001:2022, they are Annex A controls 5.25 (assessment and decision on information security events) and 5.26 (response to information security incidents). For SP 800-171 Rev. 3, the reference is requirement 03.06.05. Read these as starting points for your own mapping, and confirm the current mapping in the Reference Tool before you cite it to an auditor or customer, since informative references are updated separately from the framework document.

How an assessor tests incident declaration and which evidence passes

This table compares the assessor's test approach, the evidence requested and the common findings for each part of DE.AE-08. Read each row as a test an assessor can run against your records, and use the findings column to check your own program before an assessment starts.

Test area	Evidence requested	Common findings
Written incident criteria exist and are approved	Approved incident declaration criteria, the version history, the approver and the date of approval, and the link from criteria to the incident response plan	Criteria exist only as informal practice, have no owner, or were approved for an older version of the detection stack
Sampled closed events followed the criteria	A sample of closed alerts and events with the triage notes, the declare or close decision, and the criterion applied to each	Closure notes give no reason, or the decision cannot be traced to any written criterion
Known false-positive rules have documented rationale	Register of suppressed or tuned rules with the reason, the scope of suppression, the owner and the approval record	Suppressions were added during tuning with no rationale, or they cover broader activity than the original justification
False-positive rationale is reviewed on a set date	Review schedule, the most recent review record, and evidence that the review changed or retained each suppression	No review date is recorded, or reviews are overdue and nobody can show what was re-examined
Events that met criteria were declared on time	Timestamps from first alert, triage, the declaration decision and case creation, compared against the time limit set in the criteria	Declarations are logged without timestamps, or qualifying events sat in triage with no declaration
Declaration handoff to Respond is recorded	Case records showing declaration, assignment to responders and the link to the response plan or ticket	Cases exist, but the declaration step is missing, so the assessor cannot show when response began
Illustrative example for the on-time test	Hypothetical: an alert matched a criterion at 09:10 and the case opened at 15:40, so the assessor records a gap against the criteria's time limit	Gaps like this appear when declaration depends on one analyst and no escalation path exists

Implementing incident declaration step by step

This sequence turns DE.AE-08 from a sentence in the framework into a working decision path, with written criteria, a documented false-positive register, a case record for every declared incident, a tested handoff to Respond, and a scheduled review.

Define declaration criteria with the incident response owner
Work with the person who owns incident response to write the conditions under which an adverse event becomes a declared incident. Cover the characteristics of activity that count as incident-level, such as confirmed unauthorized access, data exposure, or disruption to a critical service, and state who has authority to declare. Include how the team applies criteria to assumed characteristics when evidence is still incomplete. The output is an approved criteria document with a version number, an owner, and the approver's sign-off recorded in your governance system.
Build the false-positive register with rationale
List the alert sources, detection rules, and activity patterns that repeatedly produce benign results, such as scheduled scans or known backup jobs. For each entry, record the evidence that shows it is benign, the conditions under which it stops being benign, the person who approved it, and the date of approval. Reviewers should be able to see why an event was excluded from declaration without reconstructing the analysis. The output is a controlled register that the detection team and the incident response owner both reference.
Configure the case tool to open a case per declaration
In your case management platform, set up a declaration step so each declared incident creates one case with a unique identifier, a timestamp, and a named owner. Link the originating alerts and findings to the case so the record shows what was declared and on what basis. Confirm with your platform's documentation which fields, workflows, and audit logging are available in your version. The output is a declared-incident record that a reviewer can open from the alert without consulting another system.
Test the path with a tabletop or simulated alert
Run a tabletop exercise or inject a simulated alert into a test environment and follow it from detection through declaration to the Respond handoff. Check that the criteria are applied as written, that a known false positive is recognized and not declared, and that the case opens with the correct owner and timestamp. Record the gaps, assign fixes, and retest the changed steps. The output is a test record with results, gaps, and corrective actions signed off by the incident response owner.
Set a review cycle for criteria and register entries
Schedule periodic reviews of the criteria document and the false-positive register, and trigger an extra review after a major incident, a significant change to monitored systems, or a material change in the threat landscape. Compare declared incidents against the criteria to find cases that were declared too late, declared unnecessarily, or missed. Remove or update register entries whose rationale no longer holds. Confirm the review frequency that your own policy or any contract or regulator requires. The output is a dated review log with changes tracked against the document versions.

Evidence that shows incidents were declared against defined criteria

An assessor testing DE.AE-08 will want proof that the incident criteria exist, that they were applied consistently, and that known false positives were handled on purpose. The cards below cover the artifacts that show this, who owns each one, and how to keep them current between audits.

Approved incident criteria with version history

This is the written standard that decides when an adverse event becomes an incident. It should name the characteristics that trigger declaration, the severity or impact thresholds, and the role authorized to declare. Keep every prior version with its approval date, the approver and a short change summary, so an assessor can see which criteria applied to any incident on a given day. Confirm with the business owner of incident response, usually the CISO or head of the SOC, that the document is approved and stored under change control. Review it at least once a year and after any major incident.

False-positive register with rationale

A false-positive register records each known benign pattern that the detection stack raises, such as a scheduled backup job tripping a rule for mass file reads. Each entry needs the rule or detector it affects, the conditions under which it applies, the rationale, the expiry or review date, and the approver. Without this register, an assessor cannot tell whether a suppressed alert was a sound decision or an unrecorded gap. Ask the SOC lead to show that entries expire and are re-reviewed when the environment changes.

Sample declared-incident records

Declared incidents should show the event data, the specific criterion that was met, the time of declaration, the declaring person and the first response action. Pull a sample across different categories and severities, not only the most serious cases, so the assessor sees consistent application. In a case management tool such as DFIR-IRIS, the case record and its audit trail can carry this link between alert and declaration. Confirm that each record cites the criterion by its version, so the reasoning can be traced to the approved document.

Events closed as non-incidents

Most adverse events never become incidents, and the assessor will want to see that the closures were reasoned. Each closed event should record the alert source, the analyst, the criteria checked, the disposition reason and whether a false-positive entry applies. Sample closures from the high-severity queue, since a pattern of quick dismissals there is the first thing an assessor looks for. Confirm that the SOC can search closed events by reason, so the sample can be drawn without manual effort.

Review minutes showing criteria updates

Minutes from periodic reviews show that criteria are maintained, not written once and forgotten. They should list the attendees, the incidents and false-positive entries reviewed, the changes agreed and the owner for each follow-up action. Link each change back to the version history of the criteria document. Minutes from the review after a missed or late declaration are especially useful, because they show the organization learned from the gap. Confirm who chairs the review and who signs the minutes, usually the incident response owner with a security governance representative.

What meeting DE.AE-08 costs in money and staff time

This table breaks down the work behind declaring incidents under DE.AE-08 by cost component, showing who is paid, whether each cost is one-time or recurring, and what pushes it up or down. Use it to build a quote request and to separate internal effort from work you may choose to outsource. No prices are stated because none are supplied for this topic.

Cost component	One-time or recurring	What drives it up	What keeps it down
Staff time to draft incident criteria and the false-positive register	One-time to draft, recurring to maintain	Number of teams and business units that must agree on what counts as an incident; many distinct alert types	A short criteria set tied to existing incident categories; one named owner for the register
Engineering time to wire declaration into the case workflow	One-time	Number of alert sources feeding the case tool; custom integrations for each SIEM or EDR	Reusing the existing SIEM and case tool, and standard connectors where they exist
Licenses or hosting for the SIEM and case tool	Recurring	Alert and log volume; number of log sources; high-availability requirements; hosted versus self-managed deployment	Reusing an existing SIEM; self-hosted open-source platforms such as DFIR-IRIS, OpenSearch or Wazuh, with licensing set by the chosen license terms and your own hosting
Recurring review and tuning of declaration thresholds	Recurring	Alert volume and false-positive rate; frequent changes to detection rules; new cloud or SaaS log sources	Scheduled quarterly reviews of the false-positive register; automated suppression only where documented and approved
Analyst time to record declaration decisions and rationale	Recurring	Number of adverse events triaged per shift; manual steps between alert and case	Automatic case creation from matched alerts, with a fixed record of each declaration decision
Auditor sampling and evidence review	Recurring per assessment cycle	Number of declared and non-declared decisions the assessor samples; scattered evidence across tools	Consistent case records, dated criteria versions and an exported register the assessor can read without staff walkthroughs
Outside help for criteria design, integration or readiness review	One-time or periodic, by written scope	Scope breadth; number of frameworks mapped to the same process; gaps in current logging	Fixed scope agreed in writing before work starts; limiting the first phase to one incident category

Open-source tools that produce declaration records

A declaration record is only as good as the systems that produced its inputs and held its case. The tools below cover three links in that chain: a case management platform that records the declaration, a detection layer that produces findings from adverse events, and a host and log monitoring layer that generates alerts for triage. Each card notes the license and what you must confirm before relying on it.

DFIR-IRIS case records

DFIR-IRIS (LGPL-3.0-or-later) keeps each case as one record holding assets, IOCs, tasks and evidence, with a full audit trail. For DE.AE-08, the case is where the declaration decision, its timestamp and the criteria applied can be written down and tied to the alerts that triggered it. It also triages alerts from SIEM, EDR and REST sources into cases and generates reports from case data. Confirm that its triage and case-opening workflow matches your written incident criteria, and that your analysts record the declaration decision in a field your assessor can read.

OpenSearch Sigma findings

OpenSearch Security Analytics (Apache-2.0) runs detectors that match ingested logs against prepackaged or custom Sigma rules and records each match as a finding with its rule, log type and severity. Its correlation engine links findings across log types in a correlation graph, which helps analysts judge whether related events form one adverse event. Findings and alerts are the evidence that an event was observed; the declaration itself still needs a documented decision. Confirm which Sigma rules you have reviewed for false positives before a finding is allowed to count toward declaration.

Wazuh rule-based alerts

Wazuh (GPL-2.0-only) decodes collected logs and compares each event against a ruleset of over 3,000 built-in rules and decoders plus custom rules. It writes matching alerts to alerts.log and alerts.json, maps them to MITRE ATT&CK and forwards them to the Wazuh indexer for review. Those files give you a timestamped alert trail that can be quoted in a declaration record. Confirm which built-in rules you have tuned or disabled for known false positives, and document each change, because a suppressed rule can hide an event that should have met your declaration criteria.

Linking findings to declarations

No single tool produces a declaration. The record is assembled from the alert or finding, the analyst's assessment against the incident criteria, the known false positives considered, and the case opened in your case manager. Keep the alert identifiers, the criteria version and the approver's name in the case so that each declaration can be traced back to its source events. Ask your implementation partner to map which fields each tool writes and where a human decision is recorded, and confirm with your assessor that this chain meets your own documented process.

Who owns the declaration decision, who prepares the evidence and who assesses it

Your incident response owner holds the decision. The organization approves the incident criteria, decides whether each adverse event meets them, and records who declared what and when. NIST's framing of DE.AE-08 is that declaration follows the defined criteria and accounts for known false positives, so the owner must be able to explain both the criteria and the exceptions they accept.

Criteria approval: Leadership or the incident response owner signs off on the incident criteria, the known false positive list and each change to either.
Declaration decisions: Analysts escalate events, and an accountable role makes the declare or do-not-declare call, with the rationale written in the case record.
False positive ownership: Someone internal reviews and approves each suppression or known benign pattern, with an expiry or review date.
Records of decisions: Keep declaration logs, timestamps and approver identities in the system of record, not only in chat threads.
Staffing coverage: Confirm who declares outside business hours and who substitutes when the owner is unavailable.

Before engaging anyone, check that a named role in your organization can point to a signed criteria document and a log of past declarations.

Questions buyers ask about DE.AE-08 incident declaration

How much effort does it take to define incident declaration criteria?

The effort depends on how many event sources you have, how many systems fall under the criteria, and how much existing incident response material you can reuse. Defining criteria means agreeing which adverse events count as incidents, which characteristics of activity (known and assumed) trigger a declaration, who has authority to declare, and how known false positives are recorded and excluded. Most of the work is decision-making with leadership, legal and operations staff, not writing code. The one-time part is the criteria document and its approval. The recurring part is reviewing criteria after major changes, new detections or repeated false positives. Ask any partner to list the workshops, reviewers and documents in its written scope before agreeing to a price.

Can a small team declare incidents in-house without outside help?

Yes, a small team can usually do this in-house if one person owns the criteria, a second person reviews them, and someone has written authority to declare. NIST's Implementation Examples for DE.AE-08 focus on applying incident criteria to known and assumed characteristics of activity and on accounting for known false positives, which a small team can document in a short procedure. Outside help is most useful when the team lacks time to test criteria against real alerts, or when no one has checked the criteria against a regulator's or customer's reporting expectations. Whichever route you choose, the organization keeps ownership of the decision to declare.

What does DE.AE-08 need from security and IT staff day to day?

Security analysts need to triage alerts against the written criteria, record whether each adverse event was declared, and log why it was not declared when it was dismissed. IT staff need to keep asset and log source information current, because declaration decisions depend on knowing which systems are affected. Incident commanders or on-call leads need a clear handoff into the response process, which connects DE.AE-08 to the Respond Functions. Staff also need a current list of known false positives with owners and review dates. The work is mostly routine, but it fails quietly when the false positive list is never reviewed, so assign that task explicitly.

How long does it take to put DE.AE-08 in place?

The duration depends on scope: the number of log sources, the number of teams that must approve criteria, the state of existing runbooks, and whether detection tooling already exists. No supplied fact gives a standard duration, so do not accept a generic timeline. Ask for a written scope that lists deliverables, dependencies, review cycles and the dates each depends on, and confirm that the timeline is stated in the signed quote. Most engagements are fixed-scope, so the written scope is where the timeline is agreed before work starts.

Does NIST certify that an organization complies with DE.AE-08?

No. NIST does not offer certifications or endorsements of CSF-related products, implementations or services, and it has no plans for a conformity assessment program. The CSF is voluntary for most organizations, although some customers or suppliers may require it. Evidence that an organization declares incidents against its criteria comes from its own records, which an independent auditor or assessor may test. An implementation partner can prepare the criteria, systems and evidence, but only an independent assessor or certification body issues reports or certificates. Confirm with your customer or regulator which form of assurance they expect.

Can DE.AE-08 be evidenced without a SIEM?

Yes, the Subcategory describes an outcome, not a specific tool, so it can be evidenced without a SIEM if the organization can show that adverse events were assessed against written criteria and declarations were recorded. A SIEM makes this easier because it centralizes alerts and findings, but a documented process, a case record and consistent logs can also serve. Open-source options such as Wazuh or OpenSearch Security Analytics produce alerts and findings that can feed declaration decisions, and DFIR-IRIS can hold each case with its audit trail. Confirm with the assessor which records they will sample, because a missing audit trail is usually the gap that matters most.

How DeployOpen scopes and prepares incident declaration evidence

DeployOpen works on DE.AE-08 as the handoff between detection and response: we define the incident criteria your organization owns, configure the open-source platforms that apply them, and prepare the records that show declarations were made consistently. The organization keeps ownership of its criteria and decisions, and an independent assessor reviews the evidence.

How we scope

The written scope lists which log sources, detectors and alert queues feed the declaration decision for DE.AE-08.
We agree in writing which incident criteria the organization has approved and which are still to be defined by its own owners.
Known false positives to exclude are listed in scope with the owner who approves each suppression and its review date.

How we build

We configure detection rules in OpenSearch Security Analytics or Wazuh so that matched alerts route to a defined triage queue.
We set up DFIR-IRIS so that alerts from SIEM, EDR and REST sources become cases only after the declaration criteria are met.
We test declaration paths with recorded sample events, including a suppressed false positive, and keep the results as test evidence.

How we hand over

You receive the written criteria, rule configuration exports, suppression register and the case workflow documentation for DE.AE-08.
Declaration records include the criteria applied, the decision, the decision maker and the timestamp, kept in the case audit trail.
Documentation names the control owners and states which evidence an independent assessor will ask to sample.

How we support

Fixed-scope engagements have deliverables and timelines agreed in writing before work starts, and a quote follows from that scope.
Ongoing support, upgrades and continuous testing of the declaration workflow are available as a retainer.
Ask any implementation partner to confirm which evidence the assessor accepts before the scope is signed, since DeployOpen does not issue audit reports or certifications.

DE.AE-08 Incident declaration