NIST CSF 2.0Implementation GuideJune 13, 2026· 12 min read
How to Implement the NIST CSF 2.0 Detect Function: A Practitioner's Guide
The Detect function is how you find out something is wrong before it becomes catastrophic. The average attacker dwell time - the time between initial compromise and detection - has historically been measured in weeks. Detect is the function that closes that window. This guide breaks down both DE categories with practical steps for building detection capabilities that work in practice, not just on paper.
What the Detect Function Covers
In CSF 2.0, the Detect function has two categories: DE.CM (Continuous Monitoring) and DE.AE (Adverse Event Analysis). CSF 2.0 significantly updated the Detect function from CSF 1.1 - the old Anomalies and Events (DE.AE) and Security Continuous Monitoring (DE.CM) categories were retained but substantially expanded, and the old Detection Processes (DE.DP) category was eliminated and its content distributed across the other two.
The Detect function is dependent on the Identify function - you can only monitor what you know you have (ID.AM), and you can only recognize anomalies if you understand your baseline. Organizations with weak Identify implementations will struggle to build effective detection.
Implementation principle: Detection without response is noise. Before building extensive detection capabilities, make sure your Respond function (RS) has a defined process for what happens when something is detected. Alerts with no response process create alert fatigue - which is worse than no alerts at all. (Alert fatigue is how you end up with a SOC that treats real incidents like car alarms: everyone hears them, nobody moves.)
DE.CM - Continuous Monitoring
The goal is to find threats faster than they find you. The industry average is still 197 days. Set the bar higher.
DE.CM requires the organization to monitor its assets, networks, and personnel activity on an ongoing basis for signs of adversarial activity, anomalies, and other indicators that security controls may be failing. This is the surveillance layer of your security program.
DE.CM-01 through DE.CM-09
Monitor networks, endpoints, personnel, and external providers
DE.CM covers monitoring networks (DE.CM-01), physical environments (DE.CM-02), personnel activity (DE.CM-03), external service providers (DE.CM-06), vulnerability scanning (DE.CM-07 and DE.CM-08), and monitoring for unauthorized use of personnel credentials (DE.CM-09). DE.CM-04 covers malicious code detection and DE.CM-05 covers unauthorized mobile code.
How to implement:
Deploy endpoint detection and response (EDR) on all managed devices - EDR provides both malicious code detection (DE.CM-04) and behavioral monitoring of endpoint activity. Microsoft Defender for Endpoint, CrowdStrike Falcon, and SentinelOne are the most common choices
Implement network monitoring: at minimum, collect and analyze firewall logs, DNS query logs, and proxy logs. Detect DNS-based C2 communications, unusual outbound connections, and lateral movement. IDS/IPS on perimeter and internal critical segments adds depth
Monitor personnel activity (DE.CM-03): this doesn't require surveillance of every employee action, but does require visibility into anomalous patterns - logging of privileged activity, alerts on access to sensitive data outside normal working hours, and monitoring of service account usage
Monitor external service providers (DE.CM-06): your EDR and SIEM should generate alerts when vendor-managed accounts take unusual actions. Your cloud provider's activity logs should capture API calls made by third-party integrations
Run authenticated vulnerability scans against all in-scope systems on a defined cadence (DE.CM-07). Monthly for internal systems, after significant changes, and immediately after major vulnerability disclosures affecting your stack
Configure alerting for unauthorized use of credentials (DE.CM-09): impossible travel alerts in Entra ID, sign-in from new country alerts, and alerts on credential stuffing patterns in authentication logs
Centralize your log collection: whether you use a SIEM (Splunk, Microsoft Sentinel, Elastic), an MDR service, or a managed SIEM with an MSSP, logs need to be in one place where correlation and alerting can happen
Common mistake: Organizations deploy EDR on endpoints but don't collect network or identity logs. An attacker who compromises credentials and logs in through normal VPN channels - creating no endpoint-level malware detection events - can operate indefinitely without being detected. Defense in depth requires monitoring across all three: endpoint, network, and identity.
DE.AE - Adverse Event Analysis
Where you figure out whether the 3am alert is a real attack or Dave from accounting trying to log in from a hotel in a different timezone again.
DE.AE is what happens after something is detected. It requires the organization to analyze detected events to determine their scope, impact, and whether they constitute a cybersecurity incident requiring a formal response. This is the triage layer - where raw detection signals become actionable intelligence.
DE.AE-01 through DE.AE-08
Correlate events, determine scope, and decide when to escalate
DE.AE covers: establishing baselines of expected network activity (DE.AE-01), analyzing events to detect adverse events (DE.AE-02), correlating events across sources (DE.AE-03), estimating the impact of events (DE.AE-04), identifying and documenting incidents (DE.AE-05), establishing incident alert thresholds (DE.AE-06), evaluating effectiveness of detection activities (DE.AE-07), and receiving cybersecurity intelligence from external sources (DE.AE-08).
How to implement:
Establish baselines (DE.AE-01): document what normal looks like in your environment - typical login times, typical data transfer volumes, typical network connections by system type. Baselines make anomalies visible. Without them, everything looks equally suspicious or unsuspicious
Implement event correlation (DE.AE-03): a single failed login is noise; 500 failed logins across 50 accounts in 10 minutes is a credential stuffing attack. SIEM correlation rules, EDR behavioral detection, and identity protection policies (Entra ID Protection, for example) all contribute to correlation
Define incident alert thresholds (DE.AE-06): what constitutes a security event vs. a security incident? Document the criteria so your team isn't making judgment calls under pressure. Examples: any confirmed malware execution is an incident; more than X failed logins in Y minutes is an incident; any access from a sanctioned country is an incident
Integrate external threat intelligence (DE.AE-08): subscribe to CISA advisories, sector-specific ISACs, your EDR vendor's threat intelligence feeds, and your cyber insurer's threat notifications. External intelligence provides context for your internal detections
Document your incident identification process: when does a detected event become a declared incident? Who makes that decision? How is it documented? The handoff from DE.AE to RS (Respond) needs a clear trigger and a clear process
Regularly evaluate detection effectiveness (DE.AE-07): conduct purple team exercises or threat hunting activities to test whether your detection capabilities would catch the attacks most relevant to your threat profile. If the answer is no, that's a gap to address in ID.IM
Common mistake: Alert thresholds are set too high to reduce alert volume, resulting in genuine incidents being dismissed as noise. Or thresholds are set too low, resulting in alert fatigue where analysts stop investigating because most alerts are false positives. Tuning detection requires iterative adjustment - start with documented thresholds and refine them based on operational experience.
Building Detection That Scales
Small organizations often struggle with the Detect function because effective detection requires either significant tooling investment, dedicated staff to monitor alerts, or both. The practical options depend on your size and budget.
For organizations without a dedicated security team, a managed detection and response (MDR) service is often the most cost-effective path to DE.CM and DE.AE coverage. MDR providers supply the tooling, the threat intelligence, and the 24/7 analyst coverage that most small organizations can't build internally. Your responsibility becomes defining the escalation process when the MDR provider identifies an incident and ensuring your team can execute the response.
For organizations building in-house capability, Microsoft Sentinel (if you're in the Microsoft ecosystem) provides SIEM and SOAR functionality with native integration across Defender products, Entra ID, and Azure services - with relatively lower barrier to entry than traditional SIEM platforms.
Evidence tip: For DE.CM, evidence includes your monitoring tool configurations, log source inventory, and alert rules. For DE.AE, it's your documented baseline, incident thresholds, and records of how detected events were triaged and classified. Documented decisions matter - an analyst judgment call with no written record doesn't demonstrate that DE.AE is implemented.
Policy Documentation for Your CSF 2.0 Detect Program
Your detection processes need written policy backing - monitoring scope, log retention requirements, alert thresholds, and incident classification criteria all belong in policy documents that GV.PO requires. Our NIST CSF 2.0 Full Policy Bundle includes Detect function policy language alongside all five other CSF 2.0 functions.
CSF 2.0 is outcome-based with no minimum control prescription. However, DE.CM-01 requires monitoring networks for adverse events, DE.CM-03 requires monitoring personnel activity, and DE.CM-06 requires monitoring external providers. At minimum: EDR on all managed devices, centralized log collection from network devices and servers, alerting for known-bad indicators and anomalous behavior, and a defined process for who receives and triages alerts. A SIEM or MDR service is the common implementation path.
DE.CM describes the outcomes a Security Operations Center is designed to achieve - monitoring networks, endpoints, personnel activity, and external providers for adversarial or anomalous behavior. A staffed internal SOC is one implementation; others include a managed detection and response (MDR) service, a co-managed SIEM with an MSSP, or a combination. The framework doesn't require a SOC specifically - it requires the monitoring capabilities and adverse event detection outcomes that a SOC typically provides.
DE.CM (Continuous Monitoring) is the ongoing surveillance capability - collecting logs, monitoring networks and endpoints, and detecting indicators of compromise in real time or near-real time. DE.AE (Adverse Event Analysis) is what happens when something is detected - correlating events, estimating scope and impact, and determining whether a detected event constitutes an incident requiring formal response. DE.CM is the detection layer; DE.AE is the analysis and triage layer.
Core log sources: endpoint logs (Windows Security Event Log, EDR telemetry), network logs (firewall, DNS queries, proxy, VPN authentication), identity logs (Entra ID / Active Directory sign-in logs, MFA events, privilege escalation), cloud platform logs (Azure Activity Log, AWS CloudTrail, GCP Audit Logs), and critical application logs. Prioritize the sources most relevant to your highest-risk scenarios first and expand from there.
CSF 2.0 doesn't prescribe a specific retention period. Requirements are typically driven by regulatory context - CMMC requires 90-day retention with one-year archival, PCI DSS requires one year. In the absence of specific requirements, 90 days of hot storage and 12 months of cold storage is a reasonable baseline. The key is that logs must be available for the investigation period relevant to your threat profile - sophisticated adversaries may dwell in an environment for months before detection.