DE.CM-01 Network monitoring: requirements and evidence

What DE.CM-01 network monitoring requires and why teams struggle with it

DE.CM-01 asks that networks and network services are monitored for potentially adverse events. It sits in the DETECT Function under the Continuous Monitoring (DE.CM) Category of the CSF 2.0 Core, and it continues the CSF 1.1 monitoring outcome at the same identifier, DE.CM-1. It also absorbs part or all of three CSF 1.1 subcategories, DE.CM-4, DE.CM-5 and DE.CM-7, so a compliance lead mapping an older assessment should not treat the new subcategory as a simple rename. The risks it targets are concrete: an unknown device joining the wired or wireless network, a rogue access point broadcasting a corporate-looking network, hijacked or altered routing announcements, DNS queries used for command and control or data theft, and traffic flows that appear without any business reason.

Teams struggle with this outcome for three reasons, and each one is a gap an assessor will find quickly. The first is an incomplete network inventory. If the organization cannot list its subnets, DNS zones, wireless networks and cloud-facing connections, it cannot say which endpoints or services are unauthorized. The second is sensor coverage: a firewall log or a single span port often sees only north-south traffic, while lateral movement, east-west flows and wireless traffic pass unseen. The third is baselines that exist only in someone's head. Without a written record of expected flows, normal DNS resolvers and approved routing peers, a deviation alert has nothing to be compared against, and the monitoring becomes noise that nobody can act on.

The practical first decision is what counts as a monitored network boundary and which sensors will feed it. Confirm with the network team which segments, wireless controllers and DNS and routing services are in scope, then document the expected baseline for each. Ask your platform or implementation partner to show how sensor output reaches a retained log store and who reviews the alerts. An assessor will expect to see the inventory, the baseline and evidence that alerts were reviewed, not only a list of tools.

Which networks, services and teams fall under DE.CM-01

DE.CM-01 asks whether networks and network services are monitored for adverse events, so the scope you draw determines which sensors, logs and owners you need. The decisions below change the work most, and each one should be settled and recorded in writing before any monitoring tool is selected. The organization owns the control; an implementation partner can help document and build what the agreed scope requires.

Guest and visitor wireless

Decide whether guest wireless is in scope as a network segment, as a rogue-network risk, or both. Corporate wireless is normally in scope for detecting unauthorized access points and endpoints, while guest networks are often monitored only at their boundary with the internal network. Ask who owns the wireless controller logs and whether they reach the same collector as wired switch logs. Confirm which rogue-access-point detection is enabled, since DE.CM-01 Implementation Examples name detection of rogue wireless networks explicitly.

Third-party hosted DNS

Decide whether DNS served by a managed provider or a cloud resolver is watched, or only your internal recursive resolvers. Internal resolver logs show client queries but not what the provider does on its side, so the scope should state which DNS logs you can export and at what fidelity. Name the owner of resolver configuration changes, because a silent change to forwarders is a network event you must be able to see. Written scope should list each resolver and whether its query logs reach your analysis platform.

BGP and routing peers

Decide which routing sessions count as network services under DE.CM-01. Border Gateway Protocol sessions with upstream providers, internet exchanges and cloud interconnects can change routes in ways that affect traffic paths, so their state changes and route announcements belong in scope when you operate your own autonomous system. If a provider runs BGP on your behalf, record who receives its alerts and how fast they reach your team. Confirm that route-change logs are retained for the same period as other network evidence.

East-west and north-south traffic

Decide whether monitoring covers only traffic crossing the perimeter (north-south) or also traffic between internal segments (east-west). Perimeter sensors miss lateral movement between servers, so DE.CM-01 deviations from baseline flows often appear only inside the network. Document which segments carry sensitive workloads and which sensors see traffic between them. Expect east-west coverage to need sensors or flow records at internal boundaries, which affects hardware and storage planning.

Cloud virtual networks

Decide which cloud accounts, virtual networks, subnets and flow log sources are in scope, and who owns each account. Cloud flow logs and security group changes are often enabled per account or per region, so an unlisted account can leave a blind spot. Confirm that flow records from each in-scope network reach the same collector as on-premises records, and that the scope names the owner of network policy changes. For hybrid estates, record how traffic between on-premises and cloud segments is logged on both sides.

Remote access paths

Decide which remote access paths are in scope: VPN concentrators, zero trust access gateways, jump hosts and remote administration tools used by staff and providers. Each path creates an entry point that DE.CM-01 monitoring should cover, including unexpected endpoints connecting through it. Record who owns the gateway configuration and how its session logs are retained. Include contractor and vendor access paths, since they often bypass the normal user population in dashboards.

Baseline flow documentation owner

Decide who owns the baseline of expected network flows, because DE.CM-01 monitoring can only detect deviations from a baseline someone maintains. The owner should keep current data flow maps, approved service paths and the list of expected endpoints, and should approve changes after network changes. Without a named owner, alerts for new flows become noise or are ignored. Ask the owner to show when the baseline was last reviewed and how changes are recorded for the assessor.

How an assessor tests DE.CM-01 and which evidence they request

This table compares what an assessor examines for each part of DE.CM-01, the evidence they usually request, and the findings that commonly appear. Read each row as a question the assessor will ask and the proof the organization should have ready. NIST does not certify or endorse implementations, so the conclusion rests on the organization's own records.

Assessment area	What the assessor tests	Evidence requested	Common findings
Sensor placement and coverage	Whether monitoring points sit on every network segment, boundary and cloud network in scope, including DNS and BGP-facing services	Network diagram marking sensor locations, asset-to-sensor mapping, and recent coverage reports from the monitoring platform	Diagrams are out of date, cloud VPCs or branch networks lack sensors, and DNS or BGP telemetry is not collected
Alert rule content	Whether detection rules target adverse network events such as scanning, anomalous DNS queries and unexpected routing changes	Exported rule sets with version history, rule-to-threat mapping, and change records for rule tuning	Default rules enabled without review, no owner for tuning, and rules that cannot be traced to a stated risk
Unauthorized endpoint and rogue wireless alerts	Whether new or unknown devices on wired and wireless networks produce alerts and that alerts reach a reviewer	Sample alerts with timestamps, ticket records showing triage, and wireless controller or sensor logs	Alerts generated but not reviewed, wireless monitoring absent from some sites, and no link between an alert and an asset record
Baseline flow documentation	Whether the organization has documented expected traffic flows and can compare live flows against that baseline	Approved flow baseline, data flow maps, and the process used to update the baseline after approved changes	Baseline exists only informally, is older than the network it describes, or is never compared with live data
Handling of deviations	Whether deviations from baseline are investigated, classified and closed with a documented outcome	Deviation register, investigation notes, decisions to accept or remediate, and links to change tickets	Deviations closed without reasons, no escalation path, and repeated deviations that are never tuned out or fixed
Continuous operation	Whether monitoring ran across the full assessment period rather than only during a selected sample window	Platform health and uptime logs, gap reports for sensors and log forwarders, and evidence of alert volume over time	Log forwarding failures with no alert, gaps after upgrades, and evidence drawn only from a short window
Ownership and review cadence	Whether named roles own monitoring, and whether the program is reviewed and improved over time	Role descriptions, review meeting minutes, and metrics such as coverage and open deviation counts	No named owner, reviews that are not recorded, and metrics that cannot be reproduced from source data

How to implement network monitoring in sequence

This sequence turns DE.CM-01 from a Subcategory outcome into a working monitoring program: a confirmed inventory, a documented baseline, sensors placed where they see traffic, tested detections and a review cadence. Each step produces an artifact an assessor can inspect.

Confirm the network and service inventory
Start by listing the networks, segments, perimeter links, wireless controllers and network services in scope, including DNS resolvers, BGP sessions and cloud virtual networks. The organization owns this list, and the asset owners sign off on it. Map each item to its owner and to the asset inventory that DE.AM-style records already hold, so gaps are visible early. The output is a signed scope statement and an inventory extract that names every monitored network and service. The step is done when no in-scope segment or routing peer is missing from the list.
Document baseline traffic flows and expected service behavior
Record which hosts normally talk to which, over which ports and protocols, and how DNS and BGP normally behave, including expected resolvers, expected route announcements and expected upstream peers. Capture this over a period of known-good operation and have the network team review it. Name the people who approve changes to the baseline. The output is a baseline document with dated versions, listing flows, approved endpoints, expected DNS and BGP behavior and known exceptions. The step is done when the network owner has approved the baseline in writing.
Deploy sensors at chosen points
Place sensors where they can observe the traffic that matters: at the perimeter, between internal segments, and at wireless controllers or access points for rogue wireless detection. Where a sensor cannot see east-west traffic, record that gap. Open-source options such as an intrusion detection engine on a firewall platform or a network sensor feeding a log pipeline can serve these roles, but the team should confirm each product's capabilities in its own environment. The output is a sensor coverage map showing each segment, the sensor watching it and any blind spot. The step is done when every in-scope segment appears on the map with a sensor or a documented reason for none.
Define detection rules for adverse events
Write or adopt rules that flag adverse events against the baseline: traffic to unapproved destinations, DNS queries to suspicious domains, unexpected BGP route changes, new hosts on protected segments and unknown wireless networks. Keep each rule tied to a stated purpose and an owner. Store the rule set in version control so each change has an author, a reason and a date. The output is a rule set with version history. The step is done when every rule traces to a baseline item or a threat the organization has documented.
Route alerts to a reviewed queue
Send alerts from the sensors and analytics platform into a single queue that a named team reviews, with severity levels and an escalation path to incident response. Decide who triages, who approves suppression of a noisy rule and how an alert becomes an incident record. Confirm the notification channels, such as email or chat, and check that they reach people during working hours and outside them. The output is a documented triage procedure and a queue configuration record. The step is done when every alert type has a reviewer and an escalation target.
Test detections with controlled events
Generate known, controlled events that should trigger each rule, such as a connection to a test destination outside the baseline, a DNS query to a designated test domain, a host plugged into a test segment or a test access point broadcasting an unapproved network name. Record whether each event produced an alert, how long it took to reach the queue and whether the reviewer acted on it. Run tests from an approved change window and tell the affected teams. The output is a test record with pass or fail results per rule. The step is done when every rule has a recorded test and failed tests have a remediation ticket.
Set a review cadence and retest after change
Agree on a recurring review of the baseline, the rule set, the sensor coverage map and the alert queue metrics, and name who runs each review. Retest affected rules after network changes, new routing peers, new wireless deployments or rule updates. The output is a review calendar and a change log that links each review to its findings. The step is done when the next review date, its owner and its scope are written down and the change log is current. Ask any external assessor to confirm the cadence fits the organization's own risk decisions.

Evidence that shows DE.CM-01 is met and how to keep it current

An assessor testing DE.CM-01 wants to see what is monitored, where the sensors sit, what normal looks like, and that detections are reviewed and tested. The cards below cover one artifact each, with guidance on refreshing it between assessments so the evidence reflects the network as it is today.

Current network and service inventory

A dated inventory of network segments, DNS resolvers, BGP sessions, wireless networks and the services that depend on them. It shows the assessor what the monitoring is supposed to cover. Check that every segment in the inventory appears in the sensor coverage map and that unknown or retired services are removed. Export the inventory from your network management or IPAM tooling on a fixed schedule and keep the exports with the assessment file.

Sensor coverage map

A diagram or table showing which network points carry sensors, such as firewall IDS/IPS, span ports or DNS logging, and which segments have no visibility. Gaps should be recorded with a reason and an owner. Review the map after every network change, because a new VLAN or cloud subnet without a sensor is the most common reason monitoring claims fail in testing.

Documented baseline flows and DNS and BGP expectations

The expected traffic patterns between zones, the DNS resolvers clients should use, and the BGP prefixes and peers an organization announces or accepts. Deviations from these baselines are what DE.CM-01 asks you to detect. Tie every baseline update to a change management record so the assessor can see why the expected pattern changed and who approved it.

Detection rule inventory with change history

A list of the rules that generate network alerts, including IDS signature sets, Sigma rules and custom correlation logic, with the version and date of each change. Rulesets are updated by their publishers, so record which set was active on which date. Export the rule configuration from the sensor or SIEM on a schedule and diff it against the previous export to show what changed and when.

Sample alerts for unauthorized endpoints and rogue wireless

Preserved alerts showing the platform detecting an unknown device on a wired segment and an unauthorized wireless network. Keep the raw event, the rule that matched and the timestamp, not only a screenshot. For a current assessment, run a controlled test with an approved device to produce fresh samples, and record the test so it is clearly separate from production events.

Review tickets showing triage

Tickets or case records showing that network alerts were reviewed, classified, escalated or closed with a reason. Assessors look for evidence that alerts are read by people, not only generated. Sample tickets across the review period, including low-severity closures, and confirm each one links to the alert it addresses. Keep the ticket export with the alert samples so the chain from event to decision is visible.

Periodic test results

Records from scheduled tests that confirm monitoring still works, such as a planted unknown host, a DNS query to a disallowed resolver or a simulated route change. Each test should state the expected alert, the observed result and the remediation for any miss. Repeat the tests after major network changes as well as on the regular schedule, and file the results with the coverage map they validate.

What meeting DE.CM-01 costs in money and effort

This table compares the main cost components of meeting DE.CM-01 Network monitoring, showing who is paid, whether each cost is one-time or recurring, and what pushes it up or down. Use it to frame a request for an itemized written quote, since no price or duration is published for this work. The main takeaway is that open-source tooling removes license spend but not the integration, tuning and staffing effort that usually dominates.

Cost component	One-time or recurring	Who is paid, and what drives it
Monitoring tooling or licenses	Recurring if commercial; none for core open-source components	Vendor license fees for commercial sensors or SIEM tiers. Driven by data volume and feature tier. Open-source options such as Suricata, Wazuh and OpenSearch Security Analytics remove license spend but not support contracts.
Sensor hardware or virtual appliances	One-time, plus refresh over time	Hardware or cloud instances for taps, span ports, firewalls or sensors. Driven by network size, number of sites, and throughput of traffic inspected.
Engineering time for deployment and tuning	One-time, with recurring tuning	Internal staff or an implementation partner placing sensors, configuring log flows and tuning rules. Driven by the number of network segments, device types and existing logging maturity.
Baseline documentation effort	One-time, updated on change	Documenting expected flows, approved endpoints, authorized wireless networks and DNS and BGP peers. Driven by how many sites and network changes the baseline must cover.
Rule tuning and alert triage	Recurring	Staff time reviewing alerts from rulesets such as Emerging Threats, and suppressing false positives. Driven by wireless footprint, rule count and log volume.
Evidence upkeep	Recurring	Retaining alert logs, baseline versions, change records and review sign-offs for the assessor. Driven by retention periods set by the organization and the frequency of required reviews.
External testing or review	Recurring or periodic	Independent testing of sensor coverage, rogue wireless detection or flow comparisons. Driven by scope and the number of sites included.
Auditor sampling	Recurring, per assessment cycle	Time the independent auditor spends sampling alerts, baselines and reviews. Driven by the assessment scope and how well evidence is organized in advance.

Self-hosted open-source tools that can produce DE.CM-01 evidence

The four tools below cover different links in the network monitoring chain: sensor, event format, correlation and alert storage. Each can produce records an assessor may ask to see for DE.CM-01, but none of them satisfies the Subcategory alone. Confirm the capabilities of your chosen versions and configurations in your own environment before you rely on them.

OPNsense intrusion detection

OPNsense includes a built-in intrusion detection and prevention system that runs Suricata with rulesets such as Emerging Threats and Abuse.ch. It can alert on or block matching traffic at the perimeter, which gives you a network sensor at the edge rather than a log from a host. Check which interfaces the sensor inspects, which rulesets are enabled and whether alerts are forwarded to syslog in EVE JSON format. Keep the rule update and alert retention settings documented, because an assessor will ask how current the detection logic was during the review period. BSD-2-Clause licensing permits reuse of the platform, but the rulesets you enable carry their own terms.

Suricata EVE JSON output

Suricata's EVE output writes structured JSON records for rule alerts, anomalies, flows, and protocol transactions such as DNS, TLS, SSH and SMB. These records cover the baseline flow comparison that DE.CM-01 describes, and DNS transactions give you evidence of name resolution monitoring. You can split the output into separate files so a log management tool can ingest flows and alerts independently. Confirm which event types are enabled, because flow and protocol logging add storage cost that should be sized before deployment. Suricata is licensed under GPL-2.0-only, so review what that means for any modifications you distribute to third parties.

OpenSearch Security Analytics findings

OpenSearch Security Analytics runs detectors against ingested logs from hosts, network devices and cloud services, using prepackaged or custom Sigma rules. Each match is recorded as a finding with its rule, log type and severity, which gives an assessor a traceable record of what was detected and when. Its correlation engine links findings across log types in a correlation graph, which helps show that network events were reviewed alongside related host activity. Confirm that your detectors cover the network log sources you claim, and document who receives alerts through channels such as Slack or email. The project is licensed under Apache-2.0.

Wazuh ruleset and alert files

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 write. Matching events are written to alerts.log and alerts.json, mapped to MITRE ATT&CK, and forwarded to the Wazuh indexer for dashboard review. The alert files are a durable record that can be exported as audit evidence, so keep them under retention and integrity controls. Confirm which rule groups are active for your network devices, since default coverage varies by log source. Wazuh is licensed under GPL-2.0-only, and the same distribution caveats apply as for Suricata.

What your team, an implementation partner and the auditor each own

Your organization remains accountable for DE.CM-01. Accountability means deciding what normal traffic looks like on your networks, which alerts matter, who responds to them, and which gaps you accept or fund. No outside party can make those decisions on your behalf, and an assessor will ask who made them and when.

Control ownership: Name an accountable owner for network monitoring who can approve scope, sensor placement and changes to alerting thresholds.
Network baseline: Maintain the approved inventory of subnets, DNS resolvers, BGP peers, wireless networks and expected flows that monitoring compares against.
Risk decisions: Decide which adverse events are high priority, how long alerts are retained, and which unauthorized endpoints or rogue wireless networks trigger immediate action.
Operational response: Staff the triage queue and document how alerts move into incident handling in line with your response procedures.
Review cycle: Confirm on a set schedule that baselines and rules still reflect your environment after network changes.

Before engaging anyone, confirm that a named person can sign off on the baseline and the risk decisions behind it.

Where organizations usually fall short on network monitoring and how to close each gap

The gaps below share a root cause: monitoring exists, but nobody can say what the network should look like, who reviews what the sensors see, or whether the detections work. Each card names one gap, one closing action, and the artifact an assessor would ask to see.

No authoritative network inventory

Monitoring can only flag unauthorized endpoints if the organization knows which endpoints are authorized. Many teams monitor traffic without a current list of subnets, DNS zones, wireless networks and BGP peers that the business owns. Close the gap by building an inventory from DHCP leases, switch and firewall configurations, and cloud network records, then reconciling it against what sensors observe. The artifact is the reconciled inventory with a named owner and a dated review record.

Sensors covering only the perimeter

Boundary sensors miss lateral movement, east-west traffic between segments and traffic inside cloud virtual networks. DE.CM-01 asks for monitoring of networks as a whole, so a perimeter-only design leaves most internal paths unobserved. Place sensors or flow collection at segment boundaries, data center cores and cloud subnets, then confirm coverage with a test flow that should generate a visible record. The artifact is a sensor placement diagram that matches the network map.

Wireless networks left unwatched

Wireless access points are often managed by a separate team and absent from the security monitoring plan, which leaves rogue access points and evil twin networks undetected. The CSF Implementation Examples for DE.CM-01 specifically call out watching wired and wireless networks for unauthorized endpoints and detecting rogue wireless networks. Close the gap by scanning for access points from a fixed sensor or controller, comparing SSIDs and BSSIDs against an approved list, and alerting on unknown ones. The artifact is the approved access point list and scan alert records.

No written baseline for DNS, BGP and flows

Detecting a deviation requires a documented definition of normal. Without one, an unexpected DNS resolver, a new BGP announcement or a new flow to an unfamiliar country looks like noise. Write baselines for DNS resolver use, expected BGP peers and prefixes, and standing flows between segments, and review them after each network change. The artifact is a signed baseline document with version history and the change records that update it.

Alerts with no documented review

Sensors that generate alerts nobody reviews provide no monitoring in practice, and an assessor will look for proof that someone acted on them. Define who triages network alerts, the severity levels that require escalation, and the time window for first review, then record each disposition. Suricata's EVE JSON output and Wazuh's alert files can feed a review queue, but the queue only counts once triage notes exist. The artifact is the triage log showing each alert's disposition and the escalation path taken.

Rules never tested

Detection rules drift out of date, get disabled after noisy periods, or never fire against the traffic they were written for. Test each network rule by replaying a known benign or simulated malicious event, such as a DNS query to a test domain or an unapproved access point in a lab, and confirm the alert appears. Repeat after rule updates and record the result. The artifact is a test log that links each rule to a dated pass or fail and the fix applied.

Evidence collected only at audit time

When teams gather logs, scan results and review records just before an assessment, the evidence often has gaps, missing timestamps and no proof of continuous operation. An assessor testing DE.CM-01 generally expects records across the assessment period, not a snapshot. Schedule automated exports of alert logs, baseline reviews and access point scans into a retained store, and check the store monthly. The artifact is a retained evidence set covering the full review period with a documented retention setting.

Questions buyers ask about DE.CM-01 cost, effort and outside help

How much effort does DE.CM-01 take and what drives it?

Effort depends mostly on how many network segments, network services and wireless networks you must watch, how many devices sit on them, and how much baseline traffic data already exists. DE.CM-01 asks you to monitor networks and network services such as DNS and BGP for adverse events, spot unauthorized endpoints and rogue wireless networks, and compare flows against baselines. The first phase is usually inventory and baseline work: you cannot flag a deviation from a baseline you never recorded. Ongoing effort then rises with alert volume, tuning of detection rules and the number of log sources feeding your analysis platform. Ask any partner to break effort down by segment, sensor, log source and rule tuning, and to state which items are one-time and which recur.

Can we meet DE.CM-01 in-house with open-source tools?

Often yes, if you have the staff time and skills to run the tools continuously. Open-source options can cover the evidence side: OPNsense includes an intrusion detection and prevention system built on Suricata, and Suricata's EVE JSON output records alerts, flows and protocol transactions such as DNS and TLS that can be sent to log management tools. Wazuh and OpenSearch Security Analytics can analyze ingested logs against rules and record findings. The software is only part of the work. You still need to define baselines, decide which unauthorized endpoints and rogue networks matter, tune rules to cut false positives and retain records that show the monitoring ran. Confirm with your own engineers whether they can staff those tasks on an ongoing basis.

What does DE.CM-01 need from our internal staff?

The work spans three internal roles. Network owners must confirm the topology, approved endpoints, wireless networks, DNS and routing dependencies and the traffic patterns considered normal. Security analysts must review alerts, decide which events are adverse, and escalate them into your incident process. Change managers must record when network changes alter the baseline, so that new flows are not treated as attacks or real attacks are not dismissed as planned changes. Because these people are needed for scoping and recurring review, plan their time before you commit to a tool or a partner. Ask any implementation partner to name which of these tasks it performs and which remain with your staff.

How long does a DE.CM-01 implementation take?

No general duration is supplied for this work, so treat any figure you hear with caution. The timeline depends on the number of network segments, the state of existing logging, the availability of your network owners and whether baselines must be built from scratch. The reliable way to get a timeline is a written scope that lists the in-scope networks, sensors, log sources, deliverables and the testing or review steps. DeployOpen works on fixed-scope engagements, with scope, deliverables and timelines agreed in writing before work starts. Ask any provider to tie its timeline to that written scope and to name the dependencies on your side.

Does NIST certify anyone for CSF 2.0 compliance?

No. NIST states that it does not offer certifications or endorsements of CSF-related products, implementations or services and has no plans to develop a conformity assessment program. The CSF is a voluntary framework, so a claim of CSF 2.0 alignment is not a certificate. Be cautious with any vendor or consultant that claims NIST certification or endorsement of its CSF work. If a customer or regulator asks for evidence, you will need to show your own controls, monitoring records and assessment results, and confirm with the requesting party which form of evidence it accepts.

What will an auditor do for DE.CM-01 and what will an implementation partner do?

The organization owns its controls. An implementation partner, such as DeployOpen, plans, implements, configures, hardens and documents the monitoring platform and prepares systems and evidence for review. It does not issue audit reports, attestations or certifications. An independent auditor or assessor, where one is engaged, tests the control against the evidence you provide and issues any report or opinion. Note that CSF 2.0 has no formal conformity assessment program, so any independent review is set up by your customer, regulator or contract, and its scope is defined there. Ask your auditor which evidence it expects for DE.CM-01 before the implementation starts.

What should we confirm in our own environment before asking for a quote?

Gather the facts that drive scope before you request a price. Confirm the list of networks, wireless access points, DNS resolvers and any BGP sessions you operate, and whether your firewalls already produce logs in a usable format. Identify the approved endpoint inventory and the network services that must be watched. Note which cloud or hosted networks sit outside your direct control. Determine who will own alert review, and whether you need the work done inside your own cloud accounts, data center or air-gapped network. A quote is then based on a written scope that names these items, which makes competing proposals comparable.

How DeployOpen scopes, implements and prepares DE.CM-01 evidence

DeployOpen plans and implements self-hosted open-source monitoring inside the client's own infrastructure, so network monitoring for DE.CM-01 runs in systems the organization controls. The organization keeps ownership of its controls, and an independent auditor or assessor decides what the evidence shows.

How we scope

Written scope names the networks, segments, DNS resolvers, BGP sessions and wireless networks in view for DE.CM-01.
Scope records which baselines of expected flows and endpoints the organization has agreed to compare traffic against.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before implementation starts.

How we build

Sensor placement, log forwarding and alert routing are configured in the client's cloud accounts, data centers or air-gapped networks.
Intrusion detection rulesets are tuned for the environment, with suppressions and custom rules documented and approved by the client.
Detection content is tested against known-benign and sample malicious traffic before the client relies on its alerts.

How we hand over

Handover documents show which sensors, rules and alert paths map to each DE.CM-01 Implementation Example in scope.
Evidence packages include rule versions, alert samples, baseline records and change logs that an assessor can sample.
Runbooks explain how the client's staff triage alerts, tune rules and escalate network events to incident response.

How we support

Ongoing support, upgrades and continuous testing of the monitoring stack are available as a retainer.
Rule updates and platform upgrades are scheduled and recorded so the evidence trail stays accurate over time.
Confirm with DeployOpen which assessment readiness activities, such as pre-assessment walkthroughs, are included in the written scope.