DE.CM-09 Computing and runtime monitoring: evidence and audit

What DE.CM-09 asks for and why teams struggle with it

When an audit or customer questionnaire asks how your computing and runtime environments are monitored, the question is really whether you can show that adverse events on servers, endpoints, runtime environments and their data are noticed in time. DE.CM-09 sits in the DETECT Function, inside the Continuous Monitoring (DE.CM) Category, and its outcome, paraphrased, is that computing hardware and software, runtime environments and their data are monitored for potentially adverse events. The risks behind it are familiar: malware running on a device, access gained through phishing and then used quietly, data leaving through email, web or file sharing services, configuration drift away from an approved baseline, tampering with files or binaries, and endpoints that are unhealthy or unpatched but still reach business systems.

NIST does not certify anyone against the CSF, and it has no conformity assessment program for CSF 2.0. Your organization therefore decides what "monitored" means for its own estate, and an assessor will judge whether that monitoring is in place and operating over time. Evidence that a sensor exists is weak on its own. Stronger evidence includes alert records, baseline comparisons, tickets raised from monitoring output and proof that someone reviewed and acted on them. Confirm with your assessor or customer exactly which period of evidence they expect to see.

Teams usually struggle for three reasons. Scope is unclear, so nobody can say which endpoints, servers, containers, SaaS collaboration tools and email gateways are supposed to report. Tooling is split across security, IT operations and cloud teams, so no single owner can show the whole picture. And the monitoring produces output that nobody triages, which an assessor will read as no monitoring at all. Before you write a response, decide who owns each data source, which baselines are authoritative, and where the alerts go. The NIST CSF 2.0 publication gives the outcome language, and your own asset inventory should define the population it applies to.

Which systems and teams fall inside DE.CM-09 scope

DE.CM-09 covers computing hardware, software, runtime environments and their data, so the scope question is less about which tools to buy and more about which assets and teams the monitoring must reach. The cards below mark the decisions that change the work most, from endpoints and identity systems to cloud workloads and managed devices. Confirm each one in writing before you size the monitoring build.

Endpoints and servers

Start with the full inventory of workstations, laptops, servers and virtual machines that run business software. DE.CM-09 asks whether these systems are monitored for adverse events, so the decision is which hosts receive an agent, which operating systems are covered and how offline machines report back when they reconnect. Tools such as osquery and Velociraptor can query fleets, but each host you leave out is a monitoring gap an assessor will ask about. Confirm the list against your asset inventory, not against memory.

Email, web and collaboration services

NIST's implementation examples for DE.CM-09 name email, web and file sharing and collaboration services as places to watch for malware, phishing and exfiltration. The decision is whether monitoring stops at the mail gateway and browser, or extends to the file sharing and chat tools staff use daily. Ask which services are SaaS (monitored through vendor logs or APIs) and which are self-hosted (monitored on your own hosts), because the two need different collection paths.

Identity and authentication systems

The DE.CM-09 implementation examples include monitoring authentication attempts, so directory services, single sign-on, VPN gateways and privileged access tools all fall in scope. The decision is which authentication sources feed the monitoring and who reviews failed and unusual attempts. Confirm that log forwarding from these systems is tested, since a monitored endpoint that never reports a failed login does not satisfy the outcome.

Configuration baselines and change tracking

Checking configurations against baselines and watching for tampering are both named in DE.CM-09. The scope decision is which baselines exist, which files and registry keys or settings matter most, and whether changes are tracked in real time or on a schedule. Wazuh file integrity monitoring and Bareos Verify jobs are two ways to compare current state with a cataloged record. Document which baselines are approved and who may change them, because drift without an approved owner is hard to explain to an assessor.

Critical data stores and backups

DE.CM-09 covers data inside runtime environments, so databases, file shares holding regulated data and backup repositories can all fall in scope. The decision is which stores get integrity or access monitoring, since full monitoring of every store is rarely practical. Prioritize the stores whose tampering would affect operations or regulatory duties, and confirm that backup catalogs are protected from the same accounts that manage production systems.

Cloud workloads and third-party managed devices

Cloud virtual machines, containers and serverless runtimes change the monitoring model, and devices run by a managed service provider add ownership questions. The decisions are whether cloud workloads report to the same monitoring platform, who holds the agent credentials, and whether the provider's own tooling satisfies part of the outcome. Write these responsibilities into the contract and the shared responsibility matrix. If a provider monitors devices you own, ask for evidence you can hand to an auditor.

How NIST's five implementation examples map to working monitoring

NIST publishes five Implementation Examples for DE.CM-09, and each one names a monitoring job you can assign to a team, a tool and an evidence source. The first covers email, web and file sharing and collaboration services, where the goal is to spot malware, phishing and data exfiltration. The second covers authentication attempts, so failed and unusual logons are logged and reviewed. The third checks configurations against baselines, the fourth watches for tampering with files and settings, and the fifth uses endpoint agents to find health problems before a device is granted access. Read as a set, they describe a monitoring program that covers the collaboration and identity paths attackers use, not only the servers they reach.

Working monitoring for these examples usually depends on a few open-source components that you run inside your own environment. osquery can schedule SQL queries across a fleet to report running processes, open network connections and file hashes, which supports the endpoint health and configuration checks. Wazuh file integrity monitoring records a baseline of checksums and attributes and alerts when a monitored file changes, which addresses tampering and drift. Bareos Verify jobs compare files against previously cataloged attributes, which helps with change detection after an incident. Velociraptor hunts collect artifacts across groups of systems, which helps when you need to confirm a finding everywhere. Confirm which of these fit your stack, because the email and collaboration examples often need a mail or cloud connector that these tools do not provide on their own.

The DE.CM-09 mapping also absorbs parts of several CSF 1.1 Subcategories: PR.DS-6, PR.DS-8, DE.CM-4, DE.CM-5 and DE.CM-7. Treat that as a transition aid and check the NIST CSF 1.1 to CSF 2.0 Core transition spreadsheet for the exact overlap before you move an old assessment across. The informative references are another point to verify. The Reference Tool lists SP 800-53 Rev. 5.2.0 controls including AC-4, AU-12, CA-7, CM-6, SI-4 and SI-7, and maps DE.CM-09 to ISO/IEC 27001:2022 Annex A controls 8.6 and 8.16, along with SP 800-171 Rev. 3 and CIS Safeguard 10.1. These are informative, not requirements, and the mappings can change, so confirm each one against the current Reference Tool before you cite it to an auditor or customer.

How an assessor tests DE.CM-09 and what they ask for

This table compares each monitored area under DE.CM-09 by how an assessor tests it, the evidence they request and the gaps they most often find. Read it as a checklist to prepare evidence before fieldwork, since an assessor will sample across each row rather than accept a tool description alone.

Monitored area	Test approach and evidence requested	Common findings
Endpoints and computing hardware	Assessor selects a sample of endpoints from the asset inventory and checks that the monitoring agent is installed, reporting and covered by alert routing. Expect agent deployment reports, console screenshots and a sample alert traced to a ticket.	Agents missing on servers or laptops outside the standard build; inventory and agent console counts do not match.
Configuration drift and baselines	Assessor compares current configuration against the approved baseline for a sample of systems, then asks how deviations are detected and who reviews them. Expect baseline documents, drift scan output and change records that explain each deviation.	Baselines exist but are not enforced; drift alerts are generated with no documented review or closure.
Authentication attempts	Assessor reviews logs of failed and successful authentication on a sample of systems and checks thresholds and alerting for repeated failures. Expect log source lists, alert rules and examples of investigated failures.	Authentication logs are collected from some systems but not privileged or remote access paths.
Email, web and collaboration vectors	Assessor checks that malware, phishing and data exfiltration signals from email, web and file sharing services are monitored and acted on. Expect gateway or sensor configuration, detection rules and a sample of blocked or quarantined events with follow-up.	Monitoring covers email but not file sharing or collaboration tools; no evidence of tuning or review.
Tampering and file integrity	Assessor selects critical files and directories, confirms a baseline exists and asks for a recent alert or a scheduled verification result. Expect integrity monitoring policy, baseline records and an example of a change investigated.	Monitored paths are incomplete; integrity alerts go unreviewed or are suppressed without a record.
Endpoint health before access	Assessor checks whether health signals such as patch level, protection status and agent state are evaluated before a device is granted access, and how failures are handled. Expect access policy settings, posture check logs and exception approvals.	Health checks apply only to managed devices, leaving unmanaged or bring-your-own devices unchecked.
Sampling and retained records	Assessor uses a sample across the areas above and asks for records from several months to show the control operated over time, not only at the test date. Confirm with the assessor how many samples and what period they expect.	Evidence exists for the audit date only; no records showing ongoing review.

Implementing DE.CM-09 in seven steps

This sequence turns DE.CM-09 from a policy statement into monitoring that covers each computing and runtime asset, alerts a named team, and leaves evidence an assessor can sample. Each step produces an artifact that the next step depends on.

Inventory computing assets and runtime environments
The organization lists the endpoints, servers, cloud workloads, containers, collaboration and email services, and browsers in scope, and records the owner and operating environment for each. An implementation partner can help build the list from existing CMDB, directory and cloud account exports, but the organization owns the final scope. The step is done when every in-scope system has an owner and no monitored system appears without a record.
Define configuration and integrity baselines
Security and platform engineers document the approved configuration for each system class, including the monitored file paths, installed software expectations and key runtime settings. These baselines become the reference that configuration drift and file integrity checks compare against. The step is done when each baseline is version controlled, approved by the control owner, and linked to the system inventory.
Deploy monitoring agents across the fleet
The platform team installs the chosen open-source agents or daemons, such as osquery for scheduled host queries, Wazuh for file integrity monitoring, or Velociraptor for artifact collection, on the systems in the inventory. Deployment is usually done through the organization's existing configuration management or endpoint tooling inside its own infrastructure. The step is done when a coverage report shows which inventoried systems report, and the team has documented each gap.
Route authentication and email alerts to responders
Security operations staff define which signals matter, including failed or unusual authentication attempts, suspicious email and web events, and unexpected changes to monitored files, then map each to a named queue and escalation path. Alert thresholds are tuned against the baseline to reduce noise before go-live. The step is done when a test event from each alert source reaches the correct responder and the routing rules are recorded.
Run scheduled baseline and integrity checks
The team schedules integrity and configuration comparisons against the approved baselines, using real-time or scheduled file integrity monitoring and verification jobs where the platform supports them. Each detected change is classified as authorized, unauthorized or unknown, and unknown results are investigated. The step is done when a sample change has been introduced in a test environment, detected, and traced to the user or process responsible.
Gate access on endpoint health
Where the architecture allows, the organization defines the health attributes an endpoint must report before it can reach sensitive resources, such as current anti-malware status, patch level and agent presence, and configures the access control system or network policy to enforce them. Exceptions require a documented owner and approval. The step is done when a non-compliant test device is denied access and the denial is logged.
Review findings and capture evidence
The organization sets a review cadence for alert trends, coverage gaps, baseline exceptions and tuning decisions, and retains the reports, configuration exports, alert samples and review minutes that show the monitoring operated over time. Assessors typically test this period of operation, so the records must be kept as they are produced. The step is done when the evidence register maps each evidence item to the DE.CM-09 Implementation Examples and the responsible owner.

Which self-hosted open-source tools support each monitoring need

osquery is the tool to consider when the question is what is running on each computing environment right now. It exposes operating system state such as running processes, loaded kernel modules, open network connections, browser plugins, hardware events and file hashes as SQL tables, so an analyst can ask the same question of every host. Its osqueryd daemon can schedule those queries across a fleet, which turns point-in-time checks into a recurring record.

Evidence produced: scheduled query results with timestamps, such as a log of listening ports or loaded kernel modules per host over time.
Runtime visibility: process and network tables help show unexpected runtime activity that DE.CM-09 asks an organization to watch for.
License caveat: osquery is offered under Apache-2.0 OR GPL-2.0-only, so the licensing path should be confirmed with counsel before distribution or embedding in a commercial product.
Coverage limits: query results are only as complete as the hosts enrolled in the fleet, so enrollment records are part of the evidence.
Log handling: results need a retention and forwarding design so the records survive the host that produced them.

Confirm with your own environment whether the operating systems, endpoint population and query volume fit osquery's deployment model before writing it into the control narrative.

Evidence that passes a DE.CM-09 review

An assessor testing DE.CM-09 wants to see that computing and runtime monitoring exists, covers the right assets, produces alerts that someone acts on, and is reviewed on a schedule. The cards below cover the artifacts that show each of those points, and each one needs a routine owner so it stays current between audits.

Monitoring coverage inventory

A list of every endpoint, server, container host, runtime environment and mail, web and collaboration service, with the monitoring agent or sensor that covers it and the date its coverage was last confirmed. Assessors compare this list against the asset inventory to find gaps, so the reconciliation matters more than the list itself. Keep it current by reconciling against new enrollments and decommissions every month, and record every host that is not covered along with its compensating control. Fleet queries from a tool such as osquery can help confirm which hosts actually report, but the inventory should still be signed by the person who owns it.

Baseline and configuration records

The approved configuration baselines that monitored systems are checked against, with version history, approval records and the change ticket behind each revision. DE.CM-09 expects that drift from these baselines is detected, so the assessor will ask how a deviation is found and who receives it. Review baselines when platforms are upgraded and at least on the review cycle set in your configuration management policy, and archive superseded versions so a sampled date can be matched to the baseline in force at that time.

Alert samples with triage records

A sample of alerts from configuration drift, file changes, malware detections and suspicious runtime activity, each traced to a ticket showing who triaged it, what was decided and how it closed. An alert with no disposition is weak evidence, and a sample that includes only easy closures will not persuade a reviewer. Keep a rolling set of alerts from each detection source and review the disposition rules quarterly so that false-positive tuning is documented rather than silent.

Integrity check reports

Output from file integrity monitoring and verification jobs, including baseline checksums, scheduled scan results and the alerts raised when a monitored file or directory changed. Records should show who or what made the change, when, and whether the change was authorized. Wazuh file integrity monitoring and Bareos Verify jobs both produce this type of output. Confirm that the baseline itself is protected from tampering and that report retention matches your evidence period.

Authentication monitoring logs

Logs of authentication attempts from directories, identity providers, privileged access tools and endpoints, with retention settings and a record of how failed-attempt thresholds were set and reviewed. DE.CM-09 is tested by asking whether these attempts are monitored and whether anomalies reach someone. Confirm that log forwarding has not silently stopped, since a gap in the record is itself a finding. Export a sample period each quarter and store it with the review sign-off.

Endpoint health policy and exceptions

The written rule that defines a healthy endpoint, such as required agents, patch level, disk encryption and anti-malware status, along with what happens to a device that fails the check and the register of approved exceptions. NIST's small business guidance cites this control when it suggests installing and maintaining anti-malware software on all business devices. Each exception should name an owner, a reason, a compensating measure and an expiry date, and the register should be reviewed before every audit cycle.

Review sign-offs

Dated records showing that a named owner reviewed the coverage inventory, baselines, alert trends, integrity reports and exception register, with the findings and actions that followed. Assessors look for evidence that review happens and changes results, so a sign-off without a follow-up action is not persuasive. Set a recurring review calendar, assign a deputy for absences, and keep the minutes or ticket references with each sign-off so the chain from finding to fix is visible.

What DE.CM-09 costs in money and effort

This table breaks the cost of monitoring computing and runtime environments into its main components, showing who is paid, whether each cost is one-time or recurring, and what drives it. Use it to see where open-source tooling removes license spend but not operating effort, and to know what to ask for in a written quote. No figures are given because none have been researched for this topic.

Cost component	One-time or recurring	What drives it	What to ask for in a quote
Tooling and licenses	Recurring for hosted or commercial add-ons; open-source core carries no license fee	Choice of agents, whether a commercial console or support tier is added, and the number of endpoints covered	Confirm which components are open source, which carry a license, and what support terms apply to each
Deployment and agent rollout	One-time, with later changes	Number and variety of operating systems, cloud workloads and endpoints, and how agents are pushed and updated	A list of covered platforms, the rollout method, and who handles failed or offline hosts
Baseline and query engineering	One-time, then recurring on each change	Number of configuration baselines, file integrity sets, scheduled queries and hunts that must match approved change records	Which baselines are in scope, who approves them, and how drift is tracked after each change window
Alert triage staffing	Recurring	Alert volume from authentication, email, web and file integrity sources, plus tuning effort to reduce noise	Expected alert routing, after-hours coverage, and who owns escalation to incident response
Evidence upkeep	Recurring	Frequency of evidence capture, retention periods set by the organization, and how often reports are reviewed	Which records are produced for DE.CM-09, where they are stored, and who signs off on them
Independent testing or review	Recurring, usually tied to an assessment cycle	Scope of monitoring tested, whether attack paths such as phishing or tampering are exercised, and the depth of review	Whether test scope includes detection of the monitored vectors and how findings are reported back
Auditor sampling and assessment	Recurring, set by the assessor	Number of sampled hosts, periods covered and the completeness of evidence produced in advance	Assessor sampling approach and the evidence list requested, confirmed directly with the assessor
Hardware and storage for logs and baselines	Recurring	Retention length, log volume per endpoint and the size of the central collection store	Storage sizing assumptions, retention settings and the cost of expanding capacity

Where DE.CM-09 programs usually fall short

Most DE.CM-09 programs have monitoring tools running but cannot show that they watch the right assets, judge results against a baseline, or act on what they see. The gaps below share a root cause: monitoring is configured once and then assumed to work, so each card ends with a check that proves the monitoring is still doing its job.

Monitoring deployed without a baseline

Agents and scanners may run on every host, yet nobody has recorded what a healthy configuration, file set or process list looks like. Without that reference, configuration drift and tampering cannot be detected as deviations. Wazuh file integrity monitoring records a baseline of checksums and attributes for monitored files and directories, which is the kind of reference DE.CM-09 implies. Action: record a documented baseline for each monitored host class and confirm that deviations from it generate alerts.

Alerts without triage records

Alerts from email gateways, authentication logs and endpoint agents often close without a record of who reviewed them, what they found and why they were dismissed. An assessor asking how monitoring leads to action will look for that trail. Check whether each alert class has an owner, a severity rule and a closure reason stored in the ticketing or SIEM system. Action: sample a set of closed alerts and confirm each one shows a reviewer, a disposition and a link to any resulting incident.

Endpoints outside the agent fleet

Monitoring covers the devices in the inventory, but unmanaged laptops, test servers and contractor machines often sit outside it. A host without an agent produces no health data, no process telemetry and no baseline comparison, so its absence from reports looks like a clean record. Compare the asset inventory against agent registration each month. Action: list every host that lacks a healthy agent and assign it an owner and a deadline for enrollment or removal from the network.

Offline devices never reconciled

Laptops and remote systems that miss their check-ins can fall out of view, and their last known state is then mistaken for current state. Endpoint tools that schedule collection for machines when they reconnect reduce this risk, but only if someone reviews what was collected. Check how long a device may stay silent before it is flagged, and whether results from a reconnecting device are reviewed. Action: set a silence threshold, flag devices that exceed it, and record how each one was resolved.

Email and collaboration vectors unmonitored

Teams often watch endpoints and network traffic but leave email, web and file-sharing services outside the monitoring scope. DE.CM-09 expects monitoring of these channels for malware, phishing and exfiltration, and the gap is common because these services are run by third parties. Confirm which mail, web and collaboration platforms send logs to the monitoring system, and which of them do not. Action: write down each channel, its log source and its alert rules, and record any channel where logging is unavailable or delayed.

Evidence gathered only at audit time

Programs often assemble monitoring evidence when an assessment is announced, which leaves gaps in dates, sampling and continuity. An assessor will look for records produced during normal operations, such as baseline reviews, alert samples and coverage reports dated across the period under review. Confirm that coverage and alert reports are generated on a fixed schedule and retained according to your own policy. Action: set a recurring evidence calendar, store outputs in a system of record, and test one retrieval before any assessment begins.

Who owns DE.CM-09, who helps, and where the auditor stops

Your organization owns DE.CM-09. The NIST CSF 2.0 Subcategory describes an outcome, that computing hardware and software, runtime environments and their data are monitored for potentially adverse events, and the organization decides how that outcome is met, who acts on alerts, and what counts as acceptable. No outside party can accept that risk on your behalf. In practice, the security team and platform team share the work: security defines which events matter and who responds, while platform engineering owns the hosts, agents and baselines they monitor.

Decide the scope: Name the endpoints, servers, email, web and collaboration services, and runtime environments that fall under DE.CM-09, and record what is excluded and why.
Set baselines: Approve the configuration baselines and monitored file sets that drift and integrity checks compare against.
Own alert response: Assign owners, severity levels and escalation paths for authentication failures, tampering signals and endpoint health findings.
Keep the policy current: Maintain the monitoring standard and review it when systems or threats change.
Retain the records: Keep alert histories, change approvals and review sign-offs in a location the assessor can access.

Before any assessment, confirm that each item above has a named owner and a dated record, because assessors test whether the process runs, not whether a tool is installed.

Questions buyers ask about DE.CM-09

Does NIST certify that we comply with DE.CM-09?

No. NIST does not certify organizations, products, implementations or services against the CSF, and it has no plans for a conformity assessment program. Alignment with DE.CM-09 is a statement your organization makes about its own monitoring outcomes. If a customer or regulator asks for proof, an independent auditor or assessor can test your controls and issue a report, but that report comes from the assessor, not from NIST. DeployOpen prepares systems and evidence for that review but does not issue audit reports or certificates. Confirm the exact evidence format your customer or regulator expects before you start.

Can open-source tools cover DE.CM-09 on their own?

Open-source tools can produce much of the evidence for DE.CM-09, but they do not satisfy the Subcategory by themselves. DE.CM-09 asks that computing hardware, software, runtime environments and their data be monitored for potentially adverse events. Tools such as osquery, which queries endpoint state across a fleet, Wazuh, which provides file integrity monitoring with alerts, and Bareos, whose Verify jobs compare files against cataloged attributes, can each cover part of that scope. You still need defined monitoring scope, alert ownership, review procedures and records that show the monitoring runs. Confirm each tool's capabilities against your own environment before you rely on it in an assessment.

How long does it take to implement DE.CM-09 monitoring?

The duration depends on scope, which is the number of endpoints, servers, cloud workloads and runtime environments in view, the number of data sources you need to onboard, and how much tuning the alerts require. No timeline has been supplied for this topic, so treat any figure you hear with caution. A fixed-scope engagement starts with written scope, deliverables and timelines agreed before work begins. Ask any implementation partner to break the timeline into discovery, deployment, alert tuning, evidence collection and handover, and to state what is assumed about your environment.

What does our internal team need to provide?

Your team owns the controls, so several roles must be filled internally regardless of who deploys the tools. You need an owner for the monitoring policy and baseline definitions, administrators who can approve agent deployment and access to endpoint and server inventories, and an operations owner who reviews alerts and records what happened. Security staff must decide which configuration changes count as drift and who approves exceptions. Plan for review time during deployment and for recurring alert handling after go-live. Ask a partner to list these roles by name in the written scope.

Will an auditor accept self-hosted monitoring tools?

Auditors generally test the outcome and the evidence, not the brand of tool. A self-hosted platform running in your own cloud account, data center or air-gapped network can produce logs, alert records, baseline reports and configuration snapshots that an assessor can inspect. The questions an auditor will ask include who can change the monitoring configuration, how the data is protected, whether alerts are reviewed on schedule and whether the records are complete. Confirm the expectations of your specific assessor and your customer before deployment, and keep records showing that the tooling itself is under change control.

How do we keep DE.CM-09 evidence current?

Evidence stays current when collection is automated and reviewed on a fixed cadence. Set scheduled exports of monitoring configurations, baseline definitions, alert logs and review sign-offs, and store them in a location that is protected and retained according to your policy. Schedule regular reviews of endpoint coverage so that new hosts are added to monitoring and retired hosts are removed. Track exceptions to baselines with an approver and an expiry date. A retainer for ongoing support, upgrades and continuous testing can help with maintenance, and its scope should be written down before it begins.

When is outside help worth paying for?

Outside help is most useful when the scope is large, the environment is hard to reach, or the team lacks time or experience to build and maintain the monitoring. Consider a partner when you need to deploy agents across mixed systems, configure file integrity baselines, integrate alerts with your incident process, or prepare evidence for an assessment. Keep ownership in-house. A partner can plan, implement and document the systems, but only an independent auditor or assessor issues reports or certificates. Ask for a fixed-scope written proposal that lists deliverables, responsibilities and what your team must provide.

How DeployOpen works on this

DeployOpen plans, implements and documents self-hosted open-source monitoring for DE.CM-09 Computing and runtime monitoring inside your own cloud accounts, data centers or air-gapped networks. We prepare the systems and evidence an assessor will ask for, while your organization keeps ownership of its controls and independent auditors issue any report or certificate.

How we scope

Written scope lists which endpoints, servers, containers and runtime environments fall under monitoring and which data sources they feed.
Scope names the Implementation Examples for DE.CM-09 being addressed, such as email and collaboration monitoring, authentication attempts and endpoint health checks.
Engagements are fixed-scope, so deliverables, timelines and responsibilities are agreed in writing before any build work starts, and ongoing support can follow as a retainer.

How we build

We deploy agents such as osquery for process, kernel module and network visibility across the host fleet, configured to your environment.
We configure file integrity monitoring in Wazuh against a recorded baseline, with alerts on who changed a monitored file and when.
We test that configuration drift, tampering and failed authentication events raise alerts in your environment, and document the results of each test.

How we hand over

Handover includes a runbook covering each monitored asset class, the query and alert definitions in use, and who reviews each alert.
Evidence packs map each DE.CM-09 implementation to the configuration files, alert logs and test records an independent assessor would request.
Documentation records known gaps and the open questions your team must confirm, so your control owners can decide how to close them.

How we support

Upgrades, backups and hardening of the monitoring stack can be covered by a retainer, so agent and rule versions stay current.
Periodic reviews check that baselines still match approved configurations after changes to hosts, images or applications.
Continuous security testing can exercise the monitoring itself, confirming that simulated attacks and drift events are still detected.