DE.AE-06 Event information to staff and tools

DE.AE-06 event information to staff and tools: what it asks for

If your SOC has detection running but cannot show that findings reach the right people, in time, with enough context to act, DE.AE-06 is the outcome you are being asked to prove. It is the routing step of the DETECT Function in NIST CSF 2.0: once an adverse event has been recorded, information about it must get to authorized staff and tools, through alerts to the SOC and incident responders, constant access to log analysis findings, and tickets created either automatically or by an analyst. The subcategory does not ask you to detect more. It asks whether detection output has a dependable path to the people who will act on it. The risk sits in the hand-off. A correct detection that sits in a dashboard nobody watches at night, or that reaches a shared mailbox nobody owns, is a missed event for practical purposes. Delays compound when alerts arrive from many sources (endpoint, identity, cloud, network and third-party services), each with its own severity scale and duplicate logic, and when no one has written down who receives what. Ticketing is often the weakest link. Analysts copy indicators into a case tool by hand, tickets are opened for some alerts and not others, and nobody can say later which findings were never escalated. For a reader deciding what to fix first, start with three checks: list every alert source and its recipients, confirm that each high-severity class of alert creates a case or ticket without manual entry, and test the path end to end with a sample event. Record who is authorized to see findings, since the outcome depends on authorized staff and tools specifically. Confirm the exact requirements with your own SOC procedures and with the NIST CSF 2.0 Core text in NIST CSWP 29 before you set targets.

Which recipients, systems and events DE.AE-06 covers

DE.AE-06 is only as useful as the routing behind it. Before any alert leaves the detection stack, the organization has to decide who receives event information, which systems feed it, where it lands as a ticket, and which event classes skip the queue. The organization owns these decisions. An implementation partner can build the routing once they are made, but cannot make them on the organization's behalf.

SOC and on-call responders

Decide which team receives alerts first, which severities page a person outside business hours, and who owns the alert queue when the primary analyst is unavailable. DE.AE-06 expects information about adverse events to reach authorized staff, so the list of authorized recipients must be written down and kept current with the on-call rota. Check that every recipient has an account, a working channel such as email or chat, and a documented escalation path. An unassigned alert is a gap an assessor can test.

Incident response team membership

Decide which incident responders receive escalated events, separate from the SOC, and which of them can act on findings without a further approval. Responders need constant access to log analysis findings, so their access should be tested in advance rather than during a live incident. Confirm who has the authority to declare an event an incident and whether that role is covered when the usual responders are away. Record the membership and the access grants as evidence.

Third-party MSSP handoffs

If an MSSP monitors some or all of the environment, decide which alerts it receives directly, which it only sees after internal triage, and how its analysts reach the organization's staff. NIST's small business guidance cites sharing incident details with an authorized responder such as an MSSP, which shows the handoff is an accepted pattern. The contract, the data-sharing terms and the escalation contacts should match this routing. Ask the MSSP to show its own alert acknowledgement records.

Detection sources feeding alerts

List every source that can raise an event: SIEM correlation rules, endpoint detection and response, cloud audit logs, identity providers, and network devices. Each source needs a known owner, a known log format and a known path into the detection platform. Gaps here are the most common reason an alert never reaches a person. Wazuh, for example, compares collected events against a built-in and custom ruleset, so a silent log source produces no alert at all. Confirm coverage source by source.

Ticketing system and case records

Decide which system is the system of record for an adverse event, such as a case management tool or the ITSM queue, and who may create or close a record there. DFIR-IRIS, for instance, keeps each case as one record with assets, indicators, tasks, evidence and an audit trail, which is the kind of record an assessor can follow. Decide whether duplicate alerts merge into one case. Confirm the ticket history can be exported, because the ticket is often the first evidence shown for this subcategory.

Event classes for automatic tickets

Decide which event classes open a ticket automatically, such as a confirmed malware detection on a server, and which require an analyst to find indicators of compromise and open a ticket manually. NIST's implementation examples describe both paths. Write the criteria as rules, test them against past alerts, and review them when detections change. Events outside the automatic list still need a documented manual route, so no adverse event depends on one person noticing it.

How an assessor tests DE.AE-06 routing

This table compares the test steps an independent assessor may run against DE.AE-06, the evidence each step asks for, and the gaps that commonly appear. Read each row as a test the auditor performs, while your team prepares the records that let that test be answered. The main takeaway is that routing is judged by traceable samples, not by the existence of an alerting tool.

Test approach	Evidence requested	Common findings
Select sample alerts and trace each to a recipient and ticket	Alert IDs from the SIEM or alert store, recipient records, and linked ticket numbers with timestamps	Alerts fire but no ticket or recipient is recorded, or sampled alerts cannot be traced end to end
Review alert routing rules and their change history	Exported routing rules, approval records for changes, and version history from the configuration repository	Rules changed without approval, stale recipients who have left the team, or no record of who edited a rule
Check that responders can see findings at all times	Access lists for the SOC and incident responders, role assignments, and screenshots or exports showing live dashboard access	Responders depend on a single shared login, access expired for on-call staff, or dashboards are unavailable outside business hours
Confirm manual ticket steps for indicators of compromise	Analyst procedure, examples of tickets opened from analyst findings, and IOC records linked to those tickets	The manual step is documented but not performed, or IOC findings never reach a ticket queue
Test automatic ticket creation for defined alert types	Workflow definitions, run logs for sampled alerts, and the list of alert types that trigger automatic tickets	Automation fails silently, retries are not logged, or alert types covered by automation are not listed
Verify information reaches the designated external responder where one is used	Contract or service description naming the responder, handoff records, and sample shared incident details	Responder contact details are outdated, or handoff depends on an informal message with no record

Evidence that shows adverse event information reaches staff and tools

An assessor testing DE.AE-06 wants proof that the right people and tools received the right event information, at the right time, through a path the organization documented and actually runs. The six artifacts below connect configuration, delivery, access, traces, ticket rules and manual procedures, so that each claim can be followed from the rule to the alert to the responder. Each one needs an owner and a refresh schedule so the evidence is current when an auditor asks for it.

Alert routing configuration exports

Export the routing settings that decide which alerts go to the SOC, which go to incident responders and which go to response tools such as chat or a case manager. Record the detector or rule set each route covers, the severity threshold and any suppression. Store exports with a timestamp and the commit or change reference, and have the named SIEM owner re-export them on a fixed schedule and after every routing change. An assessor will compare the export against the documented routing design, so any gap between the two is a finding to resolve before the audit.

Notification delivery logs

Delivery logs show that an alert was sent, to which channel, and whether the destination accepted it. Keep records for email, chat and webhook notifications, and check for failed deliveries, expired tokens and muted channels. Sampling a set of high severity alerts and tracing each to a delivery record is the most direct test of whether information reached staff. Ask the platform owner which logs are retained, for how long, and whether they can be exported without administrator rights that the assessor cannot verify.

Responder access records to findings

DE.AE-06 includes giving responders access to log analysis findings at all times, so access must be provable. Export the role assignments that grant SOC and incident response staff read access to findings, and the authentication logs that show those accounts actually signed in. Review the list quarterly with the access owner, and remove accounts for people who left or changed roles. Any break-glass or shared account should be listed separately with its approval record.

Sample alert-to-ticket traces

A trace follows one alert from detection through notification to a ticket or case, with timestamps at each step. Build a small set of traces for different alert types, including at least one that was created automatically and one that a staff member escalated by hand after finding an indicator of compromise. Assemble them from the detection engine, the notification log and the case record. Refresh the set before each assessment period and keep the trace method documented so the same steps can be repeated by another analyst.

Ticket rule definitions with change history

Ticket creation rules state which alerts open a ticket automatically, which fields are filled, and who is assigned. Export the rule set and the version history of each rule, including who approved each change and why. Assessors look for evidence that rules were reviewed, not only that they exist, so a rule with no approval or review date is a weak point. Schedule an export and review after each change window and assign one owner to approve rule changes.

Documented manual escalation procedure

Some adverse events reach responders only when an analyst finds indicators of compromise during review, so the manual path needs its own written procedure. Describe who may escalate, the threshold for escalation, the form or ticket to use, the time expected for the handoff, and how the escalation is recorded. Keep the procedure under version control with a named owner and an annual review date. Ask staff to confirm they have read it, and keep those confirmations with the procedure.

Implementing DE.AE-06 in sequence

This sequence moves event information from detection tools to the right people and systems in a way that can be tested and shown to an assessor. Each step produces a written artifact, so the routing of adverse event information is owned by the organization and can be reviewed over time.

Inventory alert sources and recipients
The security or platform team lists every tool that produces adverse event information, such as SIEM detectors, EDR consoles, cloud security services and log analysis platforms, along with every recipient that needs it, including the SOC, incident responders, the managed security provider if one exists, and ticketing queues. Owners are named for each source and each recipient. The output is an inventory that shows where alerts originate and where they must arrive, and it is confirmed by the people who run each tool.
Define routing rules per alert class
Alerts are grouped into classes, such as authentication anomalies, malware detections, network indicators and cloud configuration findings, and each class is assigned a recipient, a severity threshold and a response expectation. The organization decides which alerts go to the SOC on arrival, which go to responders only when escalated, and which remain in analysis queues. The output is a routing matrix approved by the incident response lead, with each row tied to a named owner.
Configure channels and access to findings
The platform team sets up the notification channels that match the routing matrix, such as chat, email or paging integrations, and grants responders role-based access to findings and log analysis results so they can look at them at any time. Access is limited to authorized staff and tools, and the configuration is kept in version control where the platform allows it. The output is a configuration record and an access list that a reviewer can compare against the routing matrix.
Set ticket creation rules
The team writes two sets of rules. Automatic ticket creation applies to alert classes the routing matrix marks as always requiring a case, with the fields and priority populated from the alert. Manual ticket creation applies when an analyst finds indicators of compromise during review, and the runbook names who opens the ticket and what details it must carry. The output is a ticketing rule set and a short decision guide that analysts can follow without interpretation.
Test end to end with sample events
The team sends sample events, clearly labeled as test data, through each source and checks that every expected alert reaches the right channel, that responders can open the related findings, and that automatic and manual tickets carry the correct details. Failures are logged with the rule or route that caused them and fixed before the next run. The output is a test record listing each sample event, the expected and observed result, and the sign-off by the responsible owner.
Document and set a review cadence
The organization writes the runbook from the matrix, configuration, ticket rules and test record, then assigns an owner who reviews it on a schedule the organization sets and after significant tool or staffing changes. Each review checks that sources, recipients and rules still match reality. The output is a controlled runbook, a change log and a dated review record, which together give an independent assessor the evidence trail for DE.AE-06.

Open-source tools that route alerts and create tickets

The tools below cover the path an adverse event takes after detection: rule matching, alerting, correlation, case creation and automated routing. Each one produces a different piece of evidence, so an assessor will look for how they connect rather than for any single product. The client owns the design and the decision to rely on each tool.

Wazuh rule matching and alert records

Wazuh decodes collected logs and compares each event against a ruleset of over 3,000 built-in rules and decoders, plus custom rules the client writes. Matching events are written to alerts.log and alerts.json, mapped to MITRE ATT&CK, and forwarded to the Wazuh indexer for review in the dashboard. For DE.AE-06, the alert files and indexer records are the evidence that detections reach the SOC. Confirm which rules are enabled, how alerts are retained, and that forwarding to the indexer works in your environment. The license is GPL-2.0-only.

OpenSearch Security Analytics alerting

Security Analytics runs detectors that match ingested logs from hosts, network devices and cloud services against Sigma rules, prepackaged or custom. Each match is recorded as a finding with its rule, log type and severity. Alerts go to channels such as Slack or email, and a correlation engine links findings across log types in a correlation graph. Check that notification channels reach an on-call queue that someone watches, and keep a record of who received each alert. The license is Apache-2.0.

DFIR-IRIS case records and audit trail

DFIR-IRIS keeps each case as one record of assets, IOCs, tasks and evidence, with a full audit trail. It triages alerts from SIEM, EDR and REST sources into cases and builds a consolidated investigation timeline. Its evidence logging uses SHA-256 verification and chain of custody, and it generates reports from case data. For DE.AE-06, the case audit trail shows when an alert reached a responder and what was done next. Confirm which alert sources you connect and who holds case roles. The license is LGPL-3.0-or-later.

Shuffle automated ticket creation

Shuffle runs event-driven workflows started by a webhook, a schedule or a manual run. App nodes perform actions such as posting to chat or scanning a file, and the workflows can connect a SIEM to a ticketing system or firewall without custom code. For DE.AE-06, a workflow can open a ticket automatically for certain alert types, while analysts open tickets by hand when they find indicators of compromise. Test each workflow's failure path, since a broken automation can drop alerts silently. Keep workflow definitions under change control. The license is AGPL-3.0-only.

What meeting DE.AE-06 costs in money and effort

This table breaks the cost of meeting DE.AE-06 into components, showing who is paid, whether each cost is one-time or recurring, what drives it and how to contain it. Use it to structure a written quote, since no supplied figures establish prices or durations for this work. The main takeaway is that removing license spend does not remove the staff time needed to route alerts, write ticket rules and keep evidence current.

Cost component	One-time or recurring	What drives it	How to keep it down
Tooling and licenses	Recurring if commercial; none for license fees on self-hosted open source	Commercial SIEM, SOAR or case management licenses, and the number of log sources and users they cover	Confirm each platform's license terms in writing, and count only the infrastructure and staff time that remain
Infrastructure to host the stack	Recurring	Log volume, retention period, alert and case storage, and high availability requirements	Size retention to the evidence your assessor will sample, and separate hot and archived log storage
Engineering time for routing and ticket rules	One-time build, then recurring tuning	Number of alert sources, the SOC and responder channels involved, and how many ticket triggers are automated versus manual	Start with a short list of high-confidence alerts, document each routing rule, and add rules only after review
Integration work with ticketing and chat tools	One-time, with recurring maintenance after upgrades	Number of systems connected and whether APIs are stable and documented	Limit integrations to the systems named in the response plan, and test each connection after every upgrade
Evidence upkeep	Recurring	How often rules, routing lists, ticket samples and access records change, and whether evidence is collected by hand	Export alert routing configuration, ticket logs and access lists on a fixed schedule, and automate collection where possible
External testing or review	Recurring or per engagement	Scope of the review, whether it tests alert delivery end to end, and how many systems are in scope	Agree a written scope that covers DE.AE-06 alert paths only, and ask for a fixed-scope quote
Auditor sampling time	Recurring, per assessment cycle	Number of alert-to-ticket samples requested, and how easily the organization can produce timestamped records	Keep ticket creation timestamps, acknowledgement records and responder access logs in one searchable location before the assessment begins

Who owns DE.AE-06 and what is worth outsourcing

Your organization owns DE.AE-06. The Subcategory asks that information about adverse events reaches authorized staff and tools, so someone inside the organization must decide who those people and tools are, what they receive, and when a ticket must be opened. No outside party can make those decisions on your behalf, and no auditor will accept a partner's configuration as evidence of your intent unless your own staff approved it.

Recipients and authority: Name the SOC analysts, incident responders and any managed provider who may receive alerts, and record who approved each recipient.
Routing rules: Decide which alert severities or detector types go to the SOC, which go to incident responders, and which are only logged.
Ticket policy: Define which alerts open tickets automatically and which require an analyst to open one after finding indicators of compromise.
Sign-off and review: Approve the routing design, review alert volumes, and retain records of changes to recipients and rules.
Operation: Staff the queues and act on the alerts day to day.

Before engaging any partner, confirm that these decisions already exist in writing, because a partner can only build what you have specified.

Where organizations fall short on DE.AE-06 and how to close it

DE.AE-06 is met only when the right people and tools receive adverse event information in time to act on it. The gaps below are the ones that most often break that chain between detection and response, and each one has a closure step an assessor can check. Work through them in order, because a routing gap hides every later gap.

Alerts routed to an unwatched mailbox

Many programs send SIEM or EDR alerts to a shared mailbox that no one monitors on a fixed schedule, so the alert exists but nobody acts on it. For DE.AE-06, the test is whether the alert reaches a person or a tool that can respond. Check the mailbox owner, the read rate, and whether each alert channel, such as Slack or email, has a named owner. Replace the shared mailbox with a channel tied to an on-call queue and record who is accountable for it.

No defined recipient after hours

Adverse events do not stop at the end of the business day, yet many organizations route alerts only to daytime staff. Without a documented after-hours recipient, a high-severity alert can sit until the next morning. Confirm that the escalation path names a primary and backup responder for every hour of the week, and that the contact details are current. Write the after-hours escalation path into the incident response plan and test it with a sample alert outside business hours.

Ticket rules that duplicate or miss

Automatic ticket creation often produces two failure modes at once: the same event opens several tickets, while events that matter never open one. DE.AE-06 expects tickets to be created automatically for certain alerts and manually when staff find indicators of compromise, so both paths need explicit rules. Review the matching logic, the deduplication key, and the severity threshold. Define one deduplication key per alert type and confirm that each rule has a documented owner.

Responders without access to findings

Responders often receive an alert but cannot open the log analysis findings behind it, which forces them to rebuild context from raw logs. NIST's Implementation Examples for DE.AE-06 describe giving responders access to log analysis findings at all times. Check that incident responders hold read access to the findings store and the case platform, and that access is granted through the same identity process as other staff. Grant read-only findings access to the responder group and verify it with a test account.

Manual ticket steps left undocumented

When ticket creation depends on an analyst recognizing an indicator of compromise, the steps often live in one person's memory. An assessor will ask what the analyst does, which fields they fill in, and where the evidence is stored. Write a short runbook covering the trigger, the required ticket fields, the chain of custody steps for evidence, and the handoff. Document the manual ticket runbook and keep it under version control so changes leave a record.

No evidence of tests after rule changes

Detection rules, routing rules and ticket integrations change over time, and a change that breaks alert delivery is easy to miss. DE.AE-06 is evidenced by showing that information still reaches staff and tools after each change, not only at go-live. Keep a test log that records each rule change, a test alert, the receiving channel, and the ticket created. Run and record an end-to-end alert test after every rule or integration change and keep the results with the change record.

Questions buyers ask before bringing in help with DE.AE-06

How much effort does DE.AE-06 implementation take, and what drives it?

The effort depends mainly on how many log sources feed detection, how many alert channels and responders need to receive information, and how much ticketing and case tooling already exists. Teams that already run a SIEM with defined alert routing usually need less work than teams starting from scattered logs. The main cost components are the implementation partner's time for design, configuration and testing, the internal time spent by the SOC, incident responders and system owners who confirm routing rules and approve alerts, and any licensing for commercial tools if they are used. Ask any provider for a written breakdown of these components, the number of log sources and integrations in scope, and the testing included before handover.

How long does a DE.AE-06 project take to complete?

NIST's CSF 2.0 documents do not give a duration for implementing DE.AE-06, so no fixed timeline can be taken from the framework itself. The timeline depends on the number of integrations, the readiness of the logging pipeline, and how many approvals are needed for alert routing and ticket workflows. Agree a timeline in writing as part of the fixed scope, with milestones for design, build, testing and handover, and name the client staff who must be available at each milestone. Any date given before the scope is written down should be treated as an estimate.

What does the work need from our own staff?

Your staff own the decisions that the tooling cannot make for them. The SOC lead needs to define which events go to which channel and at what severity. Incident responders need to confirm what information they need in each alert and ticket. System owners need to provide log sources, access and change approvals, and someone must own the ticket queue after go-live. Security leadership should confirm who may receive which information, since DE.AE-06 concerns authorized staff and tools. Plan for a few working sessions for each of these roles and a named contact who can make decisions quickly during testing.

Can our internal team implement DE.AE-06 without outside help?

Yes, an internal team can implement DE.AE-06 if it has engineers who can run the logging, detection and ticketing platforms, and if it has time to design and test alert routing. The questions to answer honestly are whether the team has done this before, whether it can test alerts end to end without disrupting operations, and who will maintain the rules after go-live. Outside help is most useful when the team lacks capacity or experience with the chosen platforms, or when it wants an independent check of the design. DeployOpen works in the client's own infrastructure and prepares systems, configuration and evidence, so the client keeps operational control either way.

Does NIST certify that our DE.AE-06 implementation complies with CSF 2.0?

No. NIST states that it does not offer certifications or endorsements of CSF-related products, implementations or services, and it has no plans to develop a conformity assessment program. The CSF is a voluntary framework, so claims of alignment are statements the organization makes and can support with evidence. If a customer or contract asks for proof, the organization should explain how it tested DE.AE-06, which evidence it keeps, and which independent assessor reviewed it, if any. Avoid describing any provider's work as NIST certified.

Who issues the audit or assessment result for DE.AE-06?

Only an independent assessor, auditor or certification body issues an assessment result or report. An implementation partner, including DeployOpen, prepares systems, controls and evidence for that review but does not issue audit reports, attestations or certifications. If your organization wants an independent view of its CSF alignment, identify the assessor separately, agree its scope, and confirm what it will test. The organization owns the conclusions it reports to customers, regulators and its board.

What does a fixed-scope DE.AE-06 engagement cover?

A fixed-scope engagement covers the scope, deliverables and timeline agreed in writing before work starts. For DE.AE-06, that typically means defining the events and sources in scope, designing alert routing to the SOC and incident responders, configuring the chosen detection and case tools, testing that alerts and tickets reach the right people, and handing over documentation and evidence of the configuration. Work outside the written scope, such as adding log sources or new integrations, should be handled as a change to the agreement. Ask for the list of deliverables, the test cases, the acceptance criteria and what support follows handover. Ongoing support, upgrades and continuous testing are available as separate retainers.

Which open-source tools can route DE.AE-06 alerts into tickets?

Several self-hosted open-source platforms address parts of DE.AE-06. OpenSearch Security Analytics runs detectors against ingested logs using Sigma rules and sends alerts to channels such as Slack or email. Wazuh compares collected events against a ruleset and writes alerts that can be forwarded for review. DFIR-IRIS triages alerts from SIEM, EDR and REST sources into cases with an audit trail. Shuffle can automate the handoff between these tools, including ticketing systems, without custom code. Confirm each product's current capabilities, licensing terms and integrations in your own environment before selecting a design.

How DeployOpen works on this

DeployOpen treats DE.AE-06 as an engineering problem with an evidence trail: the right people and tools receive adverse event information through routes you can show an assessor. We prepare and document those routes inside your own infrastructure, while your organization keeps ownership of the control and the assessor issues any report.

How we scope

Written scope names which log sources, alert channels and responder groups are in DE.AE-06 before work starts.
We map each alert route to the SOC, incident responders and response tools your organization already uses.
Engagements are fixed-scope, so deliverables and timelines are agreed in writing before any configuration begins.

How we build

We configure alerting in self-hosted platforms such as Wazuh, OpenSearch Security Analytics and Shuffle inside your environment.
We set up case creation in DFIR-IRIS so alerts can open tickets automatically or manually when staff find indicators of compromise.
We test each route with sample events and record which alerts reached which recipient, so the results can be reviewed.

How we hand over

You receive documentation of alert routes, rule sources, ticket triggers and the owners responsible for each step.
Evidence packages include alert logs, test records, configuration exports and sample tickets, indexed to DE.AE-06.
Your staff are walked through how to review routing, change rules and produce evidence for an independent assessor.

How we support

Ongoing support, upgrades and continuous testing of alert routes are available as a retainer, scoped separately.
Retainers can cover periodic checks that responders still receive findings after platform or staffing changes.
Confirm with your auditor which evidence formats and sampling periods they expect before the scope is signed.