NIST CSF Detect function explained: monitoring and services

What the NIST CSF Detect function requires and when a provider can monitor for you

Detect is the CSF 2.0 Function for finding and analyzing possible cybersecurity attacks and compromises, and it contains 2 Categories and 11 Subcategories. The organization owns the Detect outcomes, meaning it must be able to show that anomalies, indicators of compromise and other adverse events are found and analyzed in time to support response and recovery. A service provider can run much of the monitoring work, but it cannot take over accountability for the outcomes or for the decisions made when an alert fires. If a customer or contract asks for NIST CSF 2.0 alignment and your monitoring coverage is thin, start by separating what your staff already does from what the outcomes require.

The right split depends on four things: how many internal staff can review alerts, what hours of coverage you need, how many systems and facilities are in scope, and what evidence the customer expects to see. A small team that works business hours may find that nights and weekends are the gap that matters most. Ask a provider to state in writing which logs it collects, which systems it watches, how it escalates to named staff, and how quickly it hands off analysis. Ask your customer which artifacts they will request, such as monitoring coverage records, alert procedures or test results. Your own staff still needs to own the Detect outcomes, approve the escalation paths and review the provider's reports, so those tasks should appear in the scope agreement. The NIST SP 1300 Small Business Quick-Start Guide suggests considering a service provider when internal resources are missing, which is a reasonable starting point for that decision.

The two Detect Categories and what each one covers

The Detect Function in CSF 2.0 is split into two Categories that work as a pair: one watches the environment, the other decides what the observations mean. Each card below describes one Category's scope, followed by the size of the Detect Function in the Reference Tool export. Outcomes state what must be true about your environment, not which product must be installed.

Continuous monitoring (DE.CM)

DE.CM asks whether you watch the places where attacks and compromises show up: networks, the physical environment, personnel activity, external service providers, and computing and runtime environments. The Category is about coverage. For each of these areas, check whether someone can name the telemetry source, the owner who reviews it, and the gap that remains, such as a cloud account or a vendor's remote administration path that produces no logs. Coverage gaps are the usual finding.

Adverse event analysis (DE.AE)

DE.AE covers what happens after an event is seen: analyzing and correlating events, estimating impact, distributing event information, integrating threat intelligence, and declaring incidents. Here the question is whether alerts become decisions. Check that someone can connect a login anomaly to a host and a data store, that impact is estimated in terms the business understands, and that a named role has authority to declare an incident and notify the people who need to know.

Detect at a glance

The Reference Tool export lists the Detect Function with 2 Categories, 11 Subcategories and 37 Implementation Examples. Use these counts to size an assessment: each Subcategory needs an answer about current practice, and the Implementation Examples show how other organizations have met it. Treat the counts as a map of scope, not a checklist that proves maturity.

Outcomes, not products

A CSF outcome describes a result, such as that adverse events are analyzed to support incident response. It does not name a SIEM, an EDR agent or a log format. Organizations meet outcomes with a mix of tools, people and procedures. When you review Detect, ask for evidence that each outcome is true today, such as a dated alert, a ticket, or a test result, rather than a list of licensed products.

Where to start: the logging and monitoring NIST suggests first

The starting sequence in NIST SP 1299 turns Detect from a list of tools into a set of working sources, tested procedures and documented escalation paths that an assessor can trace. Each step produces an artifact you can show, so gaps are visible before an incident exposes them.

Continuously monitor networks, systems and facilities
Start by deciding what must be watched: networks, servers, endpoints, cloud accounts and physical facilities that hold or access your systems. Your IT or security team owns this scope, and a service provider can take over monitoring later if you lack staff. Done means you have a written monitoring scope that names each environment, the person accountable for it and the hours or conditions under which it is watched. Confirm with your team which environments are truly covered today, because gaps often sit in cloud and remote administration.
Build a log source inventory
List every system that produces security-relevant logs, such as identity providers, firewalls, endpoints, databases, applications and cloud control planes. Record for each source what it logs, where the logs go, how long they are kept and who can read them. The output is a log source inventory that a reviewer can compare against your asset records. Check that privileged access and administrative actions appear in the list, since these are the events most often needed during an investigation.
Collect logs from multiple sources into one place
Forward logs from the inventoried sources to a central store, using a log platform you host or operate under your own control. Confirm that timestamps are synchronized, that logs cannot be altered by the teams whose activity they record, and that collection failures generate alerts. The output is evidence that a sample of events from each source arrives in the central store with correct times. Ask any vendor or provider to show this for your environment before you rely on it.
Develop and test procedures for spotting incident indicators
Write the detection procedures that tell analysts what a suspicious event looks like, such as repeated failed logins, unexpected administrative changes or traffic to unfamiliar destinations. Test each procedure against recorded or simulated activity to confirm it fires and that the alert reaches a person. The output is a detection procedure register listing each rule, its owner, the log sources it depends on and the date of its last test. Illustrative example: a rule for impossible travel on an account should be tested with a known login pattern before it is trusted.
Deploy anti-malware on all business devices
NIST SP 1300 lists antivirus and anti-malware software on all business devices as a basic Detect action, tied to outcome DE.CM-09. Install it on every endpoint in the inventory, configure it to report to a central console and review its coverage against the asset list. The output is a coverage report showing which devices run the software, which do not and why. Gaps usually appear in unmanaged laptops and servers, so reconcile the report with the asset inventory rather than assuming full coverage.
Analyze the impact and scope of adverse events
When an alert fires, an analyst decides whether it is a real event, which systems, accounts and data it touches, and how far it has spread. Record each triage decision with the evidence used, the affected assets and the severity assigned. The output is an adverse event record for every investigated alert, including closed false positives, so tuning decisions can be traced. Check periodically that these records show consistent reasoning and that scope estimates are updated as new logs arrive.
Pass event information to authorized staff and tools
Route confirmed events to the people and systems that must act on them: the incident response lead, system owners, and your ticketing or response tooling, with access limited to authorized recipients. Define the escalation path and who may declare an incident. The output is an escalation matrix plus a sample of tickets or notifications showing that events reached the correct recipients within the path you defined. Review the matrix whenever staff or tooling changes, since stale contacts are a common reason escalations stall.

What DE.CM-06 asks when a provider already touches your systems

DE.CM-06 sits in the Continuous Monitoring Category of the Detect Function and covers external service providers. Its point is simple: if someone outside your organization administers, maintains or hosts part of your environment, you still need to see what that provider does on your behalf and notice when it departs from what is expected. NIST's CSF 2.0 Reference Tool publishes two Implementation Examples for this Subcategory. The first covers monitoring the remote and onsite administration and maintenance that providers perform on organizational systems. The second covers monitoring cloud services, internet service providers and other providers for deviations from expected behavior. Both examples describe activity you watch, not a control the provider performs for you.

This matters for vendor contracts because the organization keeps ownership of the outcome even when a provider does the work. A managed service or an outsourced platform team can run the tooling, but your leadership, your regulator or your customer will ask what happened on your systems and who knew. Before signing, confirm in writing which remote access paths the provider uses, which accounts and privileged sessions they hold, and whether those sessions are recorded or logged. Ask what the provider logs, where those logs are stored, how long they are kept and whether you can export them without asking permission. Ask how quickly the provider reports anomalous administrative activity, and to whom, using which channel.

Treat the answers as contract terms and as inputs to your own monitoring. Require the provider to forward authentication, privileged-session and change records for the systems it touches into a log store you control, so you can compare provider activity against the expected baseline yourself. Define what counts as a deviation for each provider, such as access outside agreed windows, new accounts or changes to security settings, and agree on who receives the alert. Confirm that the provider's own monitoring coverage is described in its service documentation, and verify that claim during onboarding rather than accepting it as stated. Your staff remain accountable for reviewing these records even when the provider runs the platform day to day.

Who monitors: in-house, a service provider, or both

When the organization already runs a security operations function, the Detect outcomes mostly stay in-house. Staff own the monitoring of networks, systems and facilities, tune alerts, decide which events are adverse, and declare incidents. Monitoring is continuous in the sense the Detect Function describes, so the organization still needs its own procedures for spotting incident indicators and for passing event information to authorized staff and tools.

What the organization keeps: alert triage, incident declaration, detection rules, log source selection and the final decision on impact and scope.
What a provider may take on: surge coverage, after-hours watch, or specialist threat hunting if the contract is written for it.
Contract questions: whether any provider may access internal consoles, how escalation works after hours, and who owns detection content.
Evidence the customer will expect: documented monitoring procedures, log coverage records, alert and case records, and tests showing indicators are actually reviewed.

Confirm with your own security leads which Detect Subcategories your team already evidences and which gaps remain.

Who does what when a service provider monitors

This table compares who owns each detection activity when an outside provider monitors systems for a smaller organization. Read it as a split of duties: the organization keeps accountability for its outcomes and decisions, while the provider monitors, triages and reports. The main takeaway is that the provider's output is evidence for the organization's controls, not a substitute for them.

Activity	Organization responsibility	Service provider responsibility
Owning the DE outcomes	Accountable for the Detect Subcategories, their scope and whether they meet the organization's risk decisions	Supports outcomes through monitoring services and reports on what was observed
Log source inventory	Maintains the list of systems, cloud accounts and providers that generate logs and confirms it stays current	Connects agreed sources and flags sources that stop sending data
Monitoring coverage	Defines which networks, systems, facilities and external providers must be watched	Monitors the agreed scope and states any gaps or blind spots in writing
Alert triage	Sets severity criteria and reviews triage rules before they go live	Performs first-level triage against those criteria and records the reasoning
Escalation to authorized staff	Names authorized contacts, out-of-hours routes and decision makers	Escalates by the agreed path and confirms receipt within the contract terms
Incident declaration	Decides whether an adverse event is declared an incident and who approves it	Recommends declaration with supporting analysis, but does not declare on the organization's behalf
Evidence retention	Sets retention periods and keeps records needed for assessors and regulators	Retains logs and tickets as contracted and provides exports on request
Periodic review of detection procedures	Reviews detection procedures and tests them at a set cadence	Proposes tuning changes and reports on alert quality over time
Audit reports and certifications	Owns its control statements and decides what to disclose to assessors	Provides monitoring reports only; does not issue audit reports or certifications, which independent assessors and certification bodies do

What to have in place before monitoring is assessed

An assessor or customer reviewing Detect will look for working monitoring, not a policy that describes it. The cards below cover the artifacts that should exist first and the simple check that shows each one is in use.

Documented log source list

Start with a written list of every log source in scope: firewalls, identity providers, endpoints, cloud control planes, applications and key SaaS services. For each source, record the owner, the log types collected and where they are sent. Check it by picking three sources at random and confirming logs from the last few days actually arrive in the central store.

Agreed monitoring scope

Write down which networks, systems, facilities, personnel activity and external providers are monitored, and which are not. Gaps should be named and accepted by the owner, not left implicit. Ask for the approved scope document and compare it against the asset inventory. Any system in the inventory but absent from the scope needs a documented reason.

Tested procedures for spotting indicators

Detection procedures should describe which indicators of compromise matter, how analysts identify them and what triggers escalation. Procedures are only evidence once they have been exercised. Ask for the last test: for example, a simulated suspicious login or a sample malware indicator, and the record showing the procedure caught it.

Named escalation path

Every alert that matters needs a route to a person with authority to act. The path should name roles, not only teams, and state who is reached after hours. Check it with a walkthrough: ask the on-call owner to narrate what they do when a high-severity alert fires, and compare that with the written path.

Anti-malware coverage on business devices

Subcategory DE.CM-09 expects anti-virus and anti-malware protection on business devices, and the evidence is coverage. Compare the endpoint management console against the device inventory to find unmanaged or out-of-date devices. A sample of ten devices, selected across departments, is a practical way to confirm agents are running and reporting.

Records of reviewed alerts

Monitoring without review leaves no trace of diligence. Keep records showing which alerts were triaged, by whom, what was decided and why. Sample a set of closed alerts from a recent period and confirm each has an owner, a disposition and a link to any follow-up ticket. Missing dispositions are the most common weakness an assessor will find.

How to check a monitoring provider before you sign

NIST does not certify, endorse or accredit CSF-related products or services, and it has no plans for a conformity assessment program for the CSF (see the NIST Cybersecurity Framework FAQs). No badge or label will tell you that a monitoring provider performs DE.CM well. You have to test the provider on its own evidence before you sign, and write that evidence into the contract. Start with the operating facts: coverage hours (whether analysts watch your environment around the clock or only during business hours, and who responds outside those hours), log retention (how long the provider keeps your logs, in which tier, and how you retrieve them during an investigation), and data location (the regions and countries where logs, alert data and any copies are stored, and which sub-processors touch them).

Next, test how the provider works when something happens. Ask for the written alert escalation path, including severity definitions, response timelines the provider commits to, who you are called at night, and how the provider decides that an event is an incident you must act on. Ask what reports you receive, how often, and whether they include the monitored sources, the alerts closed as false positives and the tuning changes made to detection rules. Ask how the provider's own privileged access to your systems is monitored and logged, who reviews that activity, and whether you receive those records. A monitoring provider with broad administrative access to your estate is itself part of your attack surface, and DE.CM-06 names monitoring of providers' remote administration for exactly this reason.

Finally, make verification a contract term. Require the right to request evidence of the controls behind these answers, such as sample reports, log retention settings, access review records and incident drill results, and the right to audit or observe where your risk justifies it. If a regulator, customer or insurer requires independent proof, plan for an assessment by an independent assessor or certification body, since only those bodies issue reports or certificates. A provider can help you prepare evidence for that work, but it cannot issue the result. Confirm the scope, the assessed period and the report type in writing before work starts, and check the contract's termination and exit terms for log export, so you can keep your monitoring history if you change providers.

What usually delays Detect work or inflates its cost

Most Detect delays trace back to unclear scope: which logs exist, who acts on alerts, and what a provider must do when something goes wrong. The cards below cover the problems that most often stretch timelines or add cost, with the step that avoids each one and what to ask for in a quote.

Incomplete log source inventory

Monitoring can only cover sources someone has listed. When the inventory of servers, endpoints, network devices and facilities is incomplete, the first months of a project go to discovery, and gaps surface later as blind spots. Start from the asset inventory that Identify produces, mark which assets emit logs, and record the owner of each source. Ask any quote to name the sources it assumes and to price discovery separately if the inventory is not yet complete.

Alerts without triage ownership

A monitoring feed that nobody is assigned to review produces alerts that age unread, which makes the monitoring effort look wasted. Assign a named role for triage, define what gets escalated to incident response, and set the hours that role covers. Ask a quote to state whether the provider triages alerts, escalates them, or only forwards them to your staff, because those are different services with different costs.

Provider contract without escalation terms

A managed monitoring contract that does not define who is told, how fast, and in what format leaves each adverse event to be negotiated during an incident. Write escalation paths, notification content, reporting cadence and the handover into your response process into the contract before signing. Ask for the escalation matrix and sample reports in the quote, so you can judge whether they meet your own incident obligations.

Cloud and SaaS logs left out

Teams often monitor on-premises servers and leave cloud control planes and SaaS applications out of scope, even though identity changes, storage access and administrative actions happen there. Include tenant audit logs, cloud service provider activity logs and key SaaS admin logs in the initial scope, and confirm retention for each. Ask the quote to list which cloud and SaaS sources are ingested and whether ingestion or log volume changes the price.

Untested detection procedures

Procedures for spotting indicators of compromise are often written once and never exercised, so they fail when an alert first fires. Test each detection use case with a known benign trigger, record the result, and fix the gaps before go-live. Ask whether the quote includes testing of detection rules and a documented test result for each use case, since testing effort varies with the number of rules.

Unmonitored provider administrative access

A provider with remote administrative access to your systems is itself a source of risk, and monitoring that ignores its sessions leaves that path unobserved. NIST's Detect implementation examples call for monitoring remote and onsite administration performed by providers, and for watching cloud and other providers for deviations from expected behavior. Require session logging for provider accounts, route those logs to your monitoring, and ask the quote to state how provider activity is recorded and reviewed.

Questions buyers ask about the Detect function and monitoring services

Is the Detect function a certification requirement?

No. Detect is one of six Functions in the CSF 2.0 Core, and nothing in it is a certification requirement. NIST is not a regulatory agency, most organizations use the Cybersecurity Framework voluntarily, and NIST states that it does not offer certifications or endorsements of CSF-related products, implementations or services. Some customers or contracts may ask you to show alignment with the CSF, and in that case the requirement comes from the customer or contract, not from NIST. Ask the requesting party what form of evidence they expect, and whether they want an independent assessment or a self-assessment against the Detect Categories, Continuous Monitoring (DE.CM) and Adverse Event Analysis (DE.AE).

What drives the effort required to run Detect?

Effort follows the number of places you must watch and how well you can act on what you see. The main drivers are the count and type of log sources, the size of the network and cloud estate, how many systems and providers must be covered by DE.CM monitoring, and whether you already have documented procedures for spotting incident indicators. Alert volume matters too, because tuning rules and triaging events is recurring work. Ask any provider to break the quote into initial setup (source onboarding, collection, first detection rules) and ongoing monitoring and analysis, and to state which log sources and environments are included.

Can a small organization run Detect without an outside provider?

Yes, a small organization can start Detect in house, but it needs people who can watch and act on the signals. NIST's Small Business Quick-Start Guide, SP 1300, suggests that businesses without internal resources consider engaging a service provider to monitor computers and networks for suspicious activity. It also recommends antivirus and anti-malware software on all business devices (DE.CM-09). A practical starting point is to collect logs from your main systems, define who reviews them and how often, and write down what a suspicious event looks like. If nobody can review those logs on a reliable schedule, that gap is the signal to consider a provider.

What does a monitoring engagement need from our staff?

A monitoring engagement needs accurate information from your side before any detection rules can be written. Expect to provide an asset inventory or list of systems in scope, the log sources you want collected and how they are reached, network and cloud account access granted under least privilege, and named contacts for technical decisions, escalation and after-hours questions. Your team should also confirm which events are expected maintenance, such as remote administration by an IT provider, so that legitimate activity is not treated as a threat. Agree on these contacts and access paths in the written scope before work starts.

How long does it take to set up Detect monitoring?

The duration depends on scope, and the written scope sets the timeline. The number of environments, the number of log sources that need onboarding, the readiness of your asset inventory, and how quickly your team can grant access all change the schedule. Engagements are typically fixed-scope, so the agreed deliverables and dates are written down before work starts. Ask for a timeline that separates onboarding, first detection rules and steady-state operation, and ask what your team must provide and by when. DeployOpen does not publish fixed durations, so the proposal for your environment is the source of the schedule.

What is the provider responsible for and what stays with us?

The split should be written into the scope, and it is the most important part of the agreement. Typically a provider collects and analyzes the agreed log sources, runs the monitoring and analysis procedures, estimates the impact and scope of events, and passes event information to the people and tools you name. Your organization still owns its controls, its risk decisions, its incident declarations, its response authority and any reporting obligations to regulators or customers. DeployOpen plans, implements and supports self-hosted open-source monitoring inside your infrastructure and prepares evidence, but it does not issue audit reports or certifications, and independent auditors do that work.

Does hiring a monitoring provider guarantee that we will detect every attack?

No. Hiring a provider improves your coverage, but it does not guarantee that every attack or compromise will be detected. Monitoring depends on the log sources you collect, the quality of detection rules, the visibility the environment allows, and how quickly alerts are acted on. Attackers can use techniques that generate no useful signal in the data you collect, and no engagement removes that risk entirely. Treat the provider as one part of your Detect capability, test it through exercises, and ask how coverage gaps are reported and tracked over time.

How DeployOpen scopes and prepares Detect evidence

DeployOpen plans, implements and documents self-hosted open-source monitoring and logging inside your own cloud accounts, data centers or air-gapped networks. We prepare the systems and evidence that show Detect outcomes are operating, while your organization keeps ownership of its controls and any independent assessment remains with an auditor or assessor.

How we scope

Agree in writing which Detect Subcategories in DE.CM and DE.AE the engagement covers before work starts.
Confirm which networks, systems, cloud services and external providers fall inside the monitored boundary.
Identify the log sources, owners and retention expectations your organization needs to document.
Engagements are fixed-scope, and ongoing monitoring support can be added as a retainer.

How we build

Deploy self-hosted open-source collection and monitoring components within your own infrastructure.
Configure log collection from endpoints, servers, network devices and cloud services in scope.
Set up alert rules and procedures for spotting indicators of compromise, then test them against known scenarios.
Integrate event information with the ticketing and escalation paths your staff already use.

How we hand over

Document each in-scope Detect outcome with its configuration, owner and the evidence it produces.
Provide runbooks for triage, impact analysis and passing event information to authorized staff.
Record test results showing that alerts fire and that logs reach the central platform as designed.
Hand over administration access and knowledge transfer so your team can operate the platform.

How we support

Review monitoring coverage when systems, cloud services or third-party providers change.
Upgrade and back up the monitoring platform on a schedule agreed in the retainer.
Support your independent assessor by organizing Detect evidence in a consistent, traceable format.
Confirm with your assessor which evidence formats and sample periods they expect before collection begins.