What DE.AE-02 adverse event analysis requires in practice
DE.AE-02 asks that potentially adverse events be analyzed so the organization understands the activity behind them. If a customer questionnaire or CSF 2.0 assessment asks how your alerts are analyzed, the honest answer is a named process: which sources feed the monitoring platform, who reviews the resulting findings, how threat intelligence is applied to those findings, and where manual review covers what automation cannot. The risk this Subcategory addresses is familiar: logs and alerts are collected, retained and even reported on, yet nobody interprets them, so a compromise that left traces in the data goes unrecognized. NIST's Implementation Examples describe four practices in plain terms: continuously monitor log events with a SIEM or other tools, use current threat intelligence when analyzing logs, manually review logs from technologies that automation cannot cover, and report the findings. Each of these should map to a runbook, a tool configuration or a named role that you can show an assessor.
The difficulty lies in volume, tuning and blind spots. A detection pipeline can generate far more alerts than analysts can read, so rules must be tuned to separate adverse activity from routine noise, and that tuning needs a documented owner and a review cycle. Some systems, such as legacy applications, appliances or certain cloud services, may not export logs in a usable form, and the gap has to be recorded and covered by scheduled manual review rather than assumed away. Confirm with your own environment which log sources are actually ingested, not merely which ones are documented. Remember also that the CSF Core is an outcome framework: it states what should be achieved and does not prescribe a product, a log retention period or a staffing model. NIST does not certify implementations of the framework or endorse products, so no tool or partner can make your DE.AE-02 status official. Only your own evidence and, where a customer or regulator requires it, an independent assessment can establish it. The Subcategory continues CSF 1.1 DE.AE-2 at the same identifier, so existing evidence from a 1.1 program can usually be carried forward and checked against the 2.0 wording.
Which log sources, teams and providers fall inside DE.AE-02 scope
DE.AE-02 asks an organization to analyze potentially adverse events, which only works when the right logs reach the right reviewers. The decisions below set what the SIEM sees, who reviews it and how outside providers are handled, and each one changes the evidence an assessor will ask to see.
Hosts and endpoints feeding the SIEM
Start with a written list of servers, workstations and container hosts whose logs reach the SIEM, and compare it with the asset inventory. Gaps usually sit in legacy systems, developer machines and hosts added outside change control. For each host class, record which events are forwarded, such as authentication, process execution and service changes, and who approved any exclusion. An assessor testing DE.AE-02 will often pick a host at random and ask whether its events were analyzed.
Network devices and security appliances
Firewalls, load balancers, VPN concentrators and intrusion detection sensors produce events that show how an adverse event moved across the environment. Decide which devices forward logs in real time, which only retain them locally, and how time synchronization is verified so events from different devices can be ordered. Confirm that the SIEM receives the deny and error events that matter, not only summary counts, because thin feeds leave analysts with incomplete context.
Cloud services and SaaS audit trails
Cloud control plane logs, storage access logs and SaaS administrative audit trails often sit outside the organization's own hosts and need explicit onboarding. Confirm which provider log categories are enabled, where they are stored, and how long they remain available to the SIEM. Self-hosted applications can also write their own audit logs; for example, Nextcloud's admin_audit app writes to a file that must be collected deliberately. Record each source as a line in the scope register.
Identity and privileged access logs
Directory sign-ins, multi-factor events, role assignments and privileged session records are among the most useful inputs for analyzing a potentially adverse event, because attackers usually reach systems through credentials. Decide whether administrative actions in secrets managers, such as OpenBao audit devices that record each API request and response, are forwarded in full or summarized. Check that sensitive values remain protected in the collected logs and that the retention period covers the look-back window your investigators use.
Who performs the review: SOC staff or an MSSP
Whether the organization's own SOC or a managed security service provider reviews alerts changes who owns the DE.AE-02 outcome, not the outcome itself. The organization remains accountable for its controls, so the contract should name the review hours, escalation paths, the alert categories the provider handles and the evidence of each analysis that will be returned. Ask who performs manual review of sources that automation cannot cover, because that work is the part most often left undefined.
Logs from external service providers
Logs held by outsourced operators, including hosting, payroll, managed backup and the MSSP itself, fall inside the organization's risk picture even when the organization cannot run the SIEM on them. Define in the contract which provider logs are delivered to the organization, in what format and how quickly, and who analyzes them. Where a provider will not share raw logs, record that as a documented gap with a compensating review, so the assessor sees a decision rather than an omission.
How the SIEM, threat intelligence and manual review fit together
This component is the automated layer. Logs from hosts, network devices and cloud services are collected and matched against detection content on a continuous basis, using a SIEM or other monitoring tools. The output is a set of matches that someone must triage, not a finished analysis. Open-source options such as OpenSearch Security Analytics and Wazuh both ingest logs and compare events against rules, so the platform choice mainly affects how rules are written, stored and reviewed.
- Inputs: Log sources in scope, the detection rules or ruleset in use, and the decoders or parsers that normalize each log type.
- Outputs: Findings or alerts with the rule that matched, the log type, the severity and the affected asset, written to a store such as
alerts.jsonin Wazuh or detector findings in OpenSearch. - Analyst records: Which rules are enabled, how severity was assigned, the disposition of each alert (benign, suspicious or escalated) and any tuning changes with the reason for them.
- Coverage evidence: A list of log sources that feed the monitoring tool, with gaps identified, since monitoring cannot analyze events it never receives.
- Recurring work: Rule updates, source onboarding and review of alert volumes, which should be scheduled and recorded.
Confirm with your platform vendor which rule formats and alert outputs your chosen version supports before designing the evidence trail around them.
This component applies current threat intelligence to the log analysis, so that an event is judged against known attacker activity rather than only against static rules. Indicators, techniques and campaign context are brought into the review of matched events. The output is a more informed classification of each event and, where relevant, a link to a known technique or actor. Wazuh maps its alerts to MITRE ATT&CK, which gives analysts a common vocabulary for relating events to techniques, but the intelligence itself must be sourced and kept current by the organization.
- Inputs: Threat intelligence feeds or reports the organization has approved, the indicators or techniques they contain, and the alerts or events under review.
- Outputs: Enriched alert records showing matched indicators, ATT&CK technique references and the feed or source used.
- Analyst records: The intelligence source, its date of collection, which indicator or technique was matched, and whether the match changed the event's classification.
- Feed governance: Documented criteria for adding or retiring sources, since stale intelligence can produce both missed events and misleading matches.
- Limits: A record that no match was found is also evidence, so analysts should note when a source was checked and returned nothing.
Check which intelligence sources are licensed for your use and how they are refreshed, because the assessor will ask whether the intelligence was current at the time of analysis.
This component covers the logs and technologies that automated monitoring cannot reliably analyze. NIST's Implementation Examples call for manual review of those sources, which typically include systems with unsupported log formats, legacy or specialized devices, and applications whose logs require context to interpret. A human reviews these logs at defined points and reports what was found. The output is a documented review, not an absence of alerts.
- Inputs: A list of systems excluded from automated analysis, their log locations and the review frequency or trigger agreed for each.
- Outputs: Review notes, identified anomalies and any events referred into the normal alert and incident process.
- Analyst records: The reviewer, the date, the log period covered, the method used and the result, including when nothing was found.
- Application logs: For self-hosted platforms, audit trails such as the Nextcloud
admin_auditlog inaudit.logor OpenBao audit device output can be reviewed manually where no parser is configured. - Escalation path: A defined route for converting a manual finding into a tracked alert or ticket.
Document the exclusion decision for each technology, because an assessor will look for both the reason automation was not used and evidence that the manual review actually happened.
How an assessor tests DE.AE-02
This table compares what an assessor typically checks for DE.AE-02, the evidence they ask to see and the gaps they most often record. Read each row as a test: the left column is the question, the middle column is how it is run, and the right column is where programs usually fall short.
| Test area | Evidence an assessor requests | Common findings |
|---|---|---|
| Continuous monitoring of log sources | Inventory of log sources feeding the SIEM or detection tooling, ingestion status over the review period, and documented gaps for sources that do not send logs | Log sources exist on paper but stopped sending logs months earlier, with no alert when ingestion fails |
| Sampling analyzed events | A sample of alerts or findings with the analyst notes, triage decision, related events and the time it was closed | Alerts are raised but triage notes are missing, so the analysis trail cannot show what was understood about the activity |
| Threat intelligence in log analysis | Feed list with source and update dates, rules or detectors tied to current intelligence, and records of when rules were last reviewed | Feeds were configured once and never refreshed, or intelligence is loaded but no detector uses it |
| Manual review for unsupported technologies | Register of technologies that automation cannot cover, the review procedure, reviewer assignments and completed review records | Legacy systems, OT devices or niche applications have no named reviewer and no record of any review |
| Reporting of findings | Findings reports or tickets, distribution records showing who received them, and evidence that reported findings led to follow-up | Findings stay in the tool dashboard with no documented recipient or follow-up action |
| Cross-reference to SP 800-53 Rev. 5.2.0 controls | Mapped evidence for AU-6 (audit record review), CA-7 (continuous monitoring), IR-4 (incident handling) and SI-4 (system monitoring), where the organization uses those controls | Mapping exists in a spreadsheet, but the underlying logs, reviews and reports it points to cannot be produced on request |
Implementing DE.AE-02 step by step
This sequence turns DE.AE-02 from a statement of intent into a working analysis process: every log source is known, feeds a central platform, is covered by owned detection rules, and has a documented manual fallback that an assessor can sample.
Inventory log-producing systems and sources
Start by listing every host, network device, application and cloud service that produces security-relevant logs, and record who owns each one. The inventory should come from the asset records you already keep under ID.AM, checked against what is actually sending logs today. Assign a priority to each source based on how much it matters to your critical services. The output is a log source register with owner, log type, retention location and collection status for each source. The step is done when the register accounts for every system in scope and each gap has a named owner.
Onboard sources to a central log platform
Forward the registered sources to one central platform, such as an OpenSearch Security Analytics deployment or a Wazuh manager with its indexer, within your own infrastructure. Confirm that timestamps are synchronized, that transport is encrypted, and that the platform can hold logs for the retention period your policies require. Where a source cannot forward logs natively, record the workaround in the register. The output is a collection health check showing which sources are reporting, with the date of the last event received from each. Confirm the exact collection options for each product in its current documentation before you commit to a design.
Define detection rules and rule owners
Select the detection content that matches your log sources and the activity you need to see, such as authentication failures, privilege changes and unusual administrative actions. Use the prepackaged rules that the chosen platform ships with as a starting point, then add custom rules for your own applications. Give each rule a named owner who is responsible for tuning it and for documenting known false positives. The output is a rule catalog listing each rule, its log source, its severity, its owner and the review date. Record which rules map to the SP 800-53 controls and CIS Safeguards you are relying on, so an assessor can trace the coverage.
Wire threat intelligence into log analysis
Connect current threat intelligence to the detection rules so that indicators and techniques known to be in use are matched against your logs. Decide which feeds are trusted, who reviews them, and how often they are refreshed, and document the source of each feed. Test that an indicator from the feed produces a finding in the platform when it appears in a sample log. The output is a threat intelligence source list and a short test record showing that matching works end to end. This step connects to DE.AE-07, which covers integrating intelligence more broadly.
Document manual review for uncovered systems
List the systems that automation cannot cover, such as legacy equipment, systems that cannot export logs, or processes that depend on human judgment. For each one, write a manual review procedure that states what is reviewed, how often, by whom, and what a finding looks like. Assign a reviewer and a backup reviewer. The output is a manual review procedure set and a schedule, which together show that the uncovered systems are reviewed by people rather than left unmonitored. Confirm the review frequency with your own risk owners, since no fixed interval is set by NIST for this activity.
Set the reporting cadence and escalation paths
Agree how findings from automated detection and manual review reach the people who analyze them and who report them onward. Define the cadence for routine reporting to the security operations team and to leadership, and define the trigger for an immediate escalation. Make sure findings can be handed to ticketing or incident tools without re-keying. The output is a reporting calendar and an escalation matrix that name the recipients and the channel for each type of finding. Check that the matrix matches the handoff points used later in incident declaration.
Run a sample review and record the results
Pick a sample of findings from the past period, including automated alerts and manual review entries, and have an analyst work through each one. The analyst records what the activity was, which logs and intelligence were used, whether the rule behaved as intended, and what action was taken. Use the results to tune rules, close gaps in the register, and correct procedures. The output is a review log that shows the analysis performed for each sampled event. This log is the evidence an independent assessor will most likely ask to see, so keep it complete and dated.
Evidence that passes a DE.AE-02 review
An assessor testing DE.AE-02 looks for proof that potentially adverse events are actually analyzed, not just collected. The six artifacts below form one chain: what is monitored, how it is detected, what was found, what intelligence informed the analysis, what automation could not reach, and what was reported. Each needs a dated record and a named owner to stay credible between audits.
Log source inventory
A current list of every host, network device, cloud service and application that feeds the SIEM, with the log types each one sends and the date the feed was last confirmed. An assessor will pick a system from the asset inventory and ask whether its logs reach the analysis platform. Check that the inventory matches what the SIEM actually receives, since a silent feed failure leaves a gap that the detectors never report. Review the list whenever a new system is onboarded or retired.
SIEM detector and rule configuration
Exports of the detectors, their enabled state, and the rule versions they run, such as Sigma rules in OpenSearch Security Analytics or the ruleset and custom rules in Wazuh. Keep these under version control so an assessor can see what was active on a given date. Confirm that rule changes went through a documented review, and that disabled rules have a recorded reason. Changes that were never reviewed are the first thing a sampling test exposes.
Alert and finding records
Exported alerts and findings with timestamps, source system, rule identifier, log type and severity, retained for the period the assessor selects. These records show that events were analyzed, not merely generated. Store the original alert files alongside the platform index so the record survives a platform upgrade or index rotation. Verify that retention settings cover the audit period before the assessor asks for samples.
Threat intelligence feed records
Records showing which threat intelligence sources were ingested, when they were updated, and how indicators were matched against log data during analysis. DE.AE-02 expects current intelligence to inform log review, so an assessor will ask for the update history. Keep the feed list, subscription terms and update logs together. Note where a feed was paused or failed, and what compensating review was done in the meantime.
Manual review logs for uncovered systems
Dated logs of manual log reviews for systems that automation cannot cover, such as legacy equipment, isolated segments or devices without log export. Each entry should name the system, the reviewer, the logs examined, the frequency and any findings. Maintain the list of uncovered systems as a controlled document with an owner who reviews it on a schedule. A gap without a documented manual process is a finding in itself.
Analysis and reporting records
Tickets, investigation notes and summary reports showing that findings were analyzed, reported to the responsible team, and escalated where needed. The Reporting Implementation Example for DE.AE-02 expects findings to be communicated, so an assessor will trace a sample alert through to a closed record. Make each entry state the analyst's conclusion and the next step. Confirm that the reporting path works by testing it, not only by documenting it.
What meeting DE.AE-02 costs in money and effort
This table lists the cost components behind DE.AE-02 by who is paid, whether each cost is one-time or recurring, and what drives it up or down. Use it to structure a quote request, since no price is published here and figures depend on your log volume, environment and scope. The main takeaway is that removing license spend from a self-hosted log platform still leaves infrastructure, analyst time and evidence upkeep as ongoing costs.
| Cost component | One-time or recurring | Main cost drivers and how to reduce them |
|---|---|---|
| SIEM or log platform tooling | Recurring (infrastructure), one-time (setup) | Log volume, retention period and number of sources. Self-hosted open-source options such as OpenSearch Security Analytics or Wazuh can remove license spend, but storage, compute and upgrades remain. Ask for a sizing estimate tied to your source count. |
| Engineering time for onboarding and rules | One-time, with recurring tuning | Number of log sources, parser work and custom Sigma or Wazuh rules. Reduce it by starting with prepackaged rulesets and onboarding high-value sources first. Confirm who writes and maintains detection content. |
| Threat intelligence subscriptions | Recurring | Number of feeds, their coverage and whether they are commercial or open. Open feeds lower spend but need someone to validate and feed them into log analysis. Ask which feeds the quote assumes. |
| Analyst review time | Recurring | Alert volume, false positive rate and the share of logs needing manual review where automation falls short. Reduce it through tuning, severity thresholds and clear triage steps. Ask the partner how review hours scale with alert volume. |
| Evidence upkeep | Recurring | Retention of alert records, audit logs and review notes, plus periodic exports for assessors. Reduce it by automating evidence collection and fixing retention rules in advance. Ask who produces and stores the evidence. |
| External testing or review | Recurring or periodic | Scope of detection testing, such as checking that DE.AE-02 alerts fire on simulated activity. Reduce it by scoping tests to critical log sources. Confirm whether the quote includes testing or only configuration. |
| Assessor sampling | Periodic, set by the assessor | Number of samples the independent assessor selects and the depth of review. Reduce it by keeping alert and review records organized by date and source. Confirm sampling expectations with your assessor before fixing a scope. |
Open-source platforms that produce DE.AE-02 evidence
OpenSearch Security Analytics is a log analysis component for the OpenSearch project, licensed under Apache-2.0. Its detectors ingest logs from hosts, network devices and cloud services and match them against prepackaged or custom Sigma rules. Each match becomes a finding that records the rule, the log type and a severity, which gives an assessor a dated trail of what the monitoring flagged and when.
- Finding records: Each finding carries the matched rule, log type and severity, so you can show which analytic produced each adverse event candidate.
- Alert routing: Alerts can be sent to channels such as Slack or email, which is useful evidence when you show that analysis reaches the people who act on it.
- Correlation graph: The correlation engine links findings across log types, supporting the analysis of related activity rather than isolated events.
- Custom Sigma rules: Rules you write or adapt from your own threat intelligence can show how current intelligence feeds log analysis, which matches the Implementation Example on threat intelligence.
- Open-source scope: The Apache-2.0 license permits broad internal use, but confirm the distribution and support model you need with your provider before you commit.
Confirm with your team whether the detector coverage, log sources and rule set match the systems in your DE.AE-02 scope, and whether the features you rely on are present in the version you deploy.
Wazuh decodes collected logs and compares each event against a ruleset of over 3,000 built-in rules and decoders, plus any custom rules you add. The platform is licensed under GPL-2.0-only, which carries copyleft obligations that your legal team should review before you modify or redistribute it. Its alert output is one of the more direct records of event analysis, because each matching event is written down with its rule.
- Alert files: Matching alerts are written to alerts.log and alerts.json, giving you a machine-readable record of each analysis result.
- ATT&CK mapping: Alerts map to MITRE ATT&CK, which helps you explain to an assessor how each detection relates to documented adversary behavior.
- Dashboard review: Alerts are forwarded to the Wazuh indexer for review in the dashboard, so you can show the manual review step that DE.AE-02 expects where automation falls short.
- Custom rules: Local rules capture the events that matter to your own environment, and their version history is evidence of how monitoring changed over time.
- License review: The GPL-2.0-only license affects how you may modify and distribute the software, so confirm the terms with counsel before you build on it.
Check that the built-in ruleset covers your critical log sources, that alert retention meets your own policy, and that someone reviews the dashboard and documents the outcome of each review.
Nextcloud is a self-hosted file and collaboration platform licensed under AGPL-3.0-only. Its admin_audit app writes additional event information to audit.log in the data directory, or to a path you set with logfile_audit. This is an audit record of activity in the platform, which can feed the analysis of potentially adverse events affecting shared files and user accounts.
- Log location: The default is audit.log in the data directory, and the logfile_audit setting changes the path, which matters when you protect or forward log files.
- Event detail: The app records additional event information beyond the server defaults, so confirm which events it captures for your configuration.
- Forwarding: Logs in a file are not analysis by themselves, so you need a collector or SIEM that reads audit.log and correlates it with other sources.
- Retention and integrity: Set file permissions and retention so that an auditor can trust the record, and document where copies are kept.
- License caveat: The AGPL-3.0-only license has network-use obligations if you modify the software and offer it to users, so review that with counsel before you change the code.
Verify the logging configuration in your deployment, confirm that the audit log reaches your analysis tooling, and test that a sample event appears where you expect it.
OpenBao is an open-source secrets management platform licensed under MPL-2.0. Its audit devices keep a detailed JSON log of every API request and response, including errors, and most sensitive values are hashed with HMAC-SHA256. For DE.AE-02, this matters because access to secrets is one of the activities most often worth analyzing for adverse events.
- Complete request trail: Every API request and response is logged, including failed calls, which supports reviewing unusual access attempts.
- JSON format: Structured records are easier to ingest into a SIEM or log analytics tool than free text.
- Hashed sensitive values: HMAC-SHA256 hashing keeps secret values out of the log while still allowing you to correlate repeated values.
- Device configuration: Each enabled audit device is a configuration decision, so record which devices are active and where they write.
- License posture: The MPL-2.0 license is file-level copyleft, so changes to OpenBao source files carry obligations that your counsel should review.
Confirm which audit devices are enabled in your deployment, that log destinations are protected, and that the analysis team receives and reviews these logs under your documented process.
Where DE.AE-02 programs usually fall short
Most DE.AE-02 programs have log collection and monitoring tools in place, yet the analysis itself is thin. The gaps below share one pattern: events are gathered but no named owner reviews them, decides what they mean, and keeps a record that an assessor can follow. Each card names a check you can run this quarter.
Logs collected but never reviewed
Log sources feed a SIEM or log platform, yet nobody reviews the output on a defined cadence, so the subcategory's core question of whether potentially adverse events are analyzed goes unanswered. Assessors often ask for proof of review, not proof of collection. Close the gap by listing each log source, assigning a reviewer or alert queue, and setting a review frequency that the team actually keeps. Ask for a sample of recent triage tickets that trace back to specific log events.
Unowned detection rules
Detection rules, whether prepackaged Sigma rules or custom rules written for a local application, often exist without an owner who knows why they fire, what they cover, or when they were last tuned. Rules that nobody maintains drift into noise and get silenced. Closure means keeping a rule register with an owner, a purpose, the log types each rule depends on, and a review date. Check whether disabled or suppressed rules are logged with a reason.
Stale threat intelligence
DE.AE-02 expects analysis to draw on current threat intelligence, yet many teams load a feed once and never revisit it. Indicators age, sources go quiet, and detection logic built on last year's campaigns misses today's tradecraft. Check when each feed was last updated, which rules consume it, and whether a named person reviews feed relevance on a set schedule. Record the source and date used for each analysis so the intelligence input can be shown to an assessor.
No record of manual review for unsupported systems
Some systems cannot send logs to automated tooling, such as legacy appliances, air-gapped segments or specialized OT equipment. NIST's Implementation Example calls for manual review of logs from these technologies, but many programs skip it and leave no trace. Write a short procedure that lists each unsupported system, the person who reviews its logs, the method (export, console review or file check), and the frequency. Keep signed or dated review records so the manual step is visible.
Findings that never reach a report
Analysts may identify suspicious activity, close it in a chat thread, and never record the result where leadership, incident responders or auditors can see it. Without a findings log, the reporting part of the Implementation Examples has no evidence behind it. Close the gap by giving each finding a unique reference, a disposition (benign, escalated or declared), and a link to the ticket. Set a recurring summary report to the security owner so that patterns in findings are reviewed, not lost.
DE.AE-02 questions buyers ask before hiring help
How much effort does DE.AE-02 take to meet?
The effort depends on how many log sources you already collect, how many of them reach a central place, and how much analyst review you expect to run. DE.AE-02 asks you to analyze potentially adverse events, so the work has three parts: getting logs into a monitoring tool, writing or tuning detection rules, and setting up a review routine for sources automation cannot cover. Each part is a recurring cost, not a one-time task, because rules drift and new systems appear. No public figure for hours or cost is available for this Subcategory, so ask any provider for a written breakdown by log source, rule set and review cadence before accepting a number.
Can we meet DE.AE-02 in-house without outside help?
Yes, many organizations do. The outcome is about analysis of adverse events, and NIST describes it through implementation examples rather than prescribing tools. The practical question is whether your team has people who can write detection logic, triage findings, and keep a manual review of systems that do not send logs. Outside help usually makes sense when you lack that skill set, need a fixed-scope build of the monitoring stack, or need an independent view before an assessment. DeployOpen plans, implements and documents self-hosted platforms in your own environment, but your organization still owns the control and its operation.
How long does it take to produce usable DE.AE-02 evidence?
Evidence becomes usable once monitoring is running on real logs, rules have fired and been reviewed, and the review records exist. Timing depends on how many log sources must be onboarded, whether your SIEM or detection platform is already in place, and how long you run before an assessor samples the records. NIST does not publish a duration for this Subcategory, so ask any partner to tie the timeline to a written scope and to name the evidence it will produce, such as alert samples, rule change history and analyst notes. Be wary of promises that skip a period of live operation.
What does DE.AE-02 require from our staff day to day?
Staff need to do four things regularly: review alerts that the monitoring tool raises, use current threat intelligence when they judge a log event, manually review logs from technologies automation cannot cover, and report findings to the people who act on them. The NIST implementation examples describe these activities without naming roles, so you must assign them. Expect analysts who understand your environment, a named owner for detection content, and a clear path for escalating findings to incident handling. Confirm with any partner which of these tasks they hand over and which remain with your team.
Does NIST certify DE.AE-02 implementations?
No. NIST states that it does not offer certifications or endorsements of CSF-related products, implementations or services, and it has no plans for a conformity assessment program. A vendor or consultant can help you prepare, but no one can issue an official NIST certificate for DE.AE-02. If a customer or regulator asks for proof, ask for an independent assessment report from a qualified assessor, and confirm that the scope of that assessment covers the detection sources and review records you actually use. Only independent auditors and assessors issue reports; implementation partners prepare the systems and evidence.
How does DE.AE-02 relate to CSF 1.1 DE.AE-2?
DE.AE-02 continues the CSF 1.1 subcategory DE.AE-2 at the same identifier, according to NIST's transition spreadsheet. The core intent carries over: analyze potentially adverse events to understand the associated activity. The change is mainly in how the identifier is written and in the framework around it, since CSF 2.0 added the Govern Function and broadened the audience to all organizations. If you already mapped DE.AE-2 in a CSF 1.1 assessment, your existing evidence is a starting point, but check it against the four CSF 2.0 implementation examples and the informative references NIST publishes.
Which open-source tools can produce DE.AE-02 evidence?
Several self-hosted platforms can produce the records this Subcategory points to, but none satisfies it alone. OpenSearch Security Analytics runs detectors against ingested logs using Sigma rules and records findings with rule, log type and severity. Wazuh decodes collected logs, compares events against a ruleset of over 3,000 built-in rules and decoders plus custom rules, and writes alerts to files and to its indexer for review. Application logs, such as the admin_audit output in Nextcloud or the audit devices in OpenBao, add evidence for systems that generate their own records. Confirm each tool's current capabilities and licensing directly with its documentation before you rely on it.
How DeployOpen prepares DE.AE-02 evidence
DeployOpen plans, implements and documents the log pipeline and detection layer that DE.AE-02 depends on, inside your own cloud accounts, data centers or air-gapped network. In practice that means agreeing which log sources feed the analysis (identity, endpoint, network, and the self-hosted applications such as Nextcloud and OpenBao whose audit trails are enabled and forwarded), deploying a SIEM such as Wazuh or OpenSearch Security Analytics against them, and writing down how each detector maps to the DE.AE-02 Implementation Examples. The written record should show who owns each rule, how threat intelligence updates reach the rule set, and where manual review covers sources automation cannot reach. Your organization owns the controls and the decisions about what counts as adverse. DeployOpen prepares the systems and the evidence trail that lets your own team, and any independent assessor, follow an event from ingestion to analysis.
Detection that has never fired on a realistic test tells an assessor very little, so DeployOpen runs security testing against the same pipeline to confirm that known attack patterns produce findings, alerts and reviewable records. Test results, rule change history, sample alert exports and the analyst review log are the artifacts most often requested when an assessor examines whether events are actually analyzed. Ask any implementation partner to show which of these artifacts they will hand over, in what format, and who keeps them current after handover. Ask also whether the test plan covers the four Implementation Examples and the SP 800-53 Rev. 5.2.0 controls the NIST CSF 2.0 Reference Tool lists for DE.AE-02.
Every engagement is fixed-scope, so the scope, deliverables, environments and timelines are agreed in writing before work starts, and a quote follows from that written scope. DeployOpen does not issue audit reports, attestations or certifications, and NIST does not offer certifications for CSF implementations either. Independent auditors, assessors or certification bodies determine whether your evidence meets the requirements you are assessed against. Ongoing tuning, upgrades and continuous testing of the detection layer are available as retainers, which is where recurring effort usually sits after the initial build. Before signing, confirm who receives the source code and configuration, who holds administrative credentials, and what remains operable if the engagement ends.
