What DE.CM-03 personnel activity monitoring requires
DE.CM-03 asks the organization to monitor personnel activity and technology use for potentially adverse events. NIST gives three Implementation Examples: using behavior analytics to detect anomalous user activity and insider threats, monitoring logical access control logs for unusual patterns and failed attempts, and monitoring deception technology, including decoy accounts, for any use. An auditor, customer or internal risk owner who asks how insider threats and misuse of access are detected is really asking whether someone is watching the right signals, and whether anyone acts on what they see. The risk is that a trusted user, or a stolen credential used by someone posing as one, can do damage that perimeter controls never see. What usually makes this hard is not the tooling but the surrounding conditions: logs are noisy, so real signals get buried; no one clearly owns the review of access anomalies; and there is no baseline of normal behavior, so unusual activity is hard to define. Confirm early who reviews alerts, how often, and what happens when a finding is raised.
In CSF 1.1, this outcome sat in DE.CM-3 (monitoring personnel activity) and DE.CM-7 (monitoring for unauthorized personnel, connections, devices and software). NIST's transition spreadsheet shows that DE.CM-03 keeps the earlier identifier and absorbs part or all of DE.CM-7, so teams with an existing 1.1 assessment should review how their old DE.CM-7 evidence maps forward. NIST describes CSF 2.0 outcomes, not a checklist of tools or settings, so the organization decides how to meet the outcome for its own environment. NIST does not certify organizations, products or service providers against the CSF, so any claim of DE.CM-03 alignment rests on your own assessment, and a customer may ask for independent evidence instead.
Which accounts, systems and logs fall under personnel activity monitoring
Personnel activity monitoring only works when the organization decides which identities, systems and logs it covers. Each decision below changes how much collection, correlation and review effort is needed, and what evidence an assessor can inspect for DE.CM-03.
Workforce accounts versus privileged and service accounts
Standard employee identities generate the bulk of routine activity, while privileged and service accounts carry the highest-impact actions and are often used non-interactively. Monitoring them usually needs separate detection rules, because a service account should rarely log in interactively and any such login is a signal. Confirm that privileged activity is logged at a finer grain than general user activity, and that service account owners are named so that anomalies can be attributed.
Identity providers and directory services
The identity provider or directory is usually the single best source for authentication attempts, failed logins, group changes and password resets. Scope decisions here determine whether a user's activity can be followed across applications at all. Check that directory audit logs are forwarded to the monitoring platform, that retention meets the organization's own review cycle, and that administrative changes to the directory itself are captured.
SaaS and collaboration tools
Email, file sharing, chat and business applications hosted by vendors often hold sensitive data and offer audit logs of varying depth and retention. Each tool added to scope means another log source to ingest, normalize and test. Ask each vendor which events are exported, whether exports are real-time or batched, and whether bulk downloads, external sharing and mailbox rule changes are recorded.
File and application audit logs
Self-hosted applications and file stores can record who accessed, changed or exported records. Where audit logging is off by default or set to a minimal level, personnel activity cannot be reconstructed. Nextcloud's admin_audit app, for example, writes additional event information to a dedicated audit log file, and its location is a configuration choice. Confirm which applications write audit logs, where those logs are stored, and who can alter them.
Deception assets such as decoy accounts
Decoy accounts and other deception technology are monitored for any use, because no legitimate user should touch them. Adding them to scope adds little log volume but creates high-confidence alerts that are easy to evidence. The decision to create them requires care: decoys must be realistic enough to attract misuse, must not grant real access, and must be documented as part of the monitoring design so that assessors can see why they exist.
Contractors and outsourced administrators
Contractors and managed service providers who act under the organization's own accounts are personnel for monitoring purposes, even though their employer is another company. Scope must cover their sessions, shared administrative accounts and the time windows in which they work. Confirm how their identities are issued, whether each person has an individual account, and how their activity is reviewed against the terms of the contract or service agreement.
How to implement DE.CM-03 step by step
This sequence takes an organization from an undefined view of personnel activity to a monitored, tested and periodically tuned program that produces records an assessor can follow from source to alert to response.
Define monitored personnel actions and technology uses
Start with a written scope that names the personnel actions and technology uses under watch, such as privileged administration, access to sensitive data stores, use of shared accounts and use of decoy resources. Business owners, HR and the security lead agree the list, and legal or works council review applies where employee monitoring is regulated in your jurisdiction. The output is a signed monitoring scope statement that lists each action, its business reason and the owner who approves it. The step is done when every later rule can be traced back to one line in this scope.
Build the monitored-source register
Inventory every log source that records the scoped actions, including identity providers, directory services, hosts, applications, collaboration tools, cloud audit trails and the audit logs of self-hosted platforms. For each source, record the owner, the log types it produces, the retention setting and whether delivery to the central store is confirmed. Check completeness by comparing the register against the access paths in your identity inventory, which exposes gaps such as applications that bypass central authentication. The output is a monitored-source register, and the step closes when an unexplained gap count is zero or each gap has a dated remediation owner.
Set baselines for behavior analytics
For the first Implementation Example, establish what normal activity looks like for each user group, such as working hours, typical systems accessed, data volumes and privilege use. Document the baseline window, the groups and the thresholds, and state how analysts will distinguish legitimate change, such as a project or role move, from anomalous activity. Tools such as Wazuh can decode events and apply built-in and custom rules, while OpenSearch Security Analytics can run detectors against ingested logs, so confirm which platform holds each detection. The output is a baseline document per user group, and the step closes when each baseline has a named approver.
Write rules for logical access patterns and failed attempts
For the second Implementation Example, write detection rules for unusual logical access patterns and failed attempts, including repeated authentication failures, access outside normal hours, unexpected privilege changes and access from unusual locations. Express rules in a format your platform supports, and where Sigma rules are used, store them under version control with a rule ID, log type, severity and the scope line they trace to. Test each rule against sample events so you know it fires on what it should. The output is a rule catalog with one entry per rule, and the step closes when every catalog entry links to a scoped action.
Deploy deception technology and route alerts to named reviewers
For the third Implementation Example, place decoy accounts or resources where no legitimate user has a reason to touch them, and configure alerts whenever they are used. Route every alert class to a named reviewer or role, define the escalation path to incident response, and set response times in a written policy rather than leaving them to individual judgment. Confirm the notification channels, such as Slack or email, work outside business hours. The output is a routing matrix and a review record template, and the step closes when a test alert reaches the named reviewer and the review is logged.
Test detection with simulated misuse
Run controlled exercises that imitate misuse, such as a test account reading a restricted data store, repeated failed logins, a decoy access and a privilege escalation. Record the time each event occurred, when it was detected, who reviewed it and what action followed, and compare the results with the rule catalog to find rules that did not fire or fired without an owner. Keep the test plan, the authorization for the exercise and the results as evidence. Where you lack in-house capacity, an independent testing provider can run the exercise, but the organization still owns the controls and the results. The output is a test report, and the step closes when each failed detection has a tuning ticket.
Schedule periodic tuning and review
Set a recurring review of the monitored-source register, baselines, rule catalog and routing matrix, and tune rules that create excessive noise or miss known misuse. Track alert volume, false positives, missed detections and review timeliness so changes are based on measured results rather than memory. Update the Subcategory mapping for DE.CM-03 when standards references change, because NIST updates informative references and implementation examples online more often than the framework document. The output is a dated tuning log with approvals, and the step closes when each review cycle produces a signed record that an assessor can sample.
How an assessor tests DE.CM-03 and what passes
This table compares six test angles an assessor may use against DE.CM-03, the evidence each one requests and the findings that show up most often. Read each row as a question the assessor will ask about your monitoring program, then check whether your records answer it without extra explanation. The main takeaway is that a tool being switched on is rarely enough; assessors look for scoped coverage, tuned rules and records showing that someone reviewed and acted on what the tools produced.
| Test angle | Evidence requested | Common findings |
|---|---|---|
| Scope of monitored personnel and technology | Documented scope listing user populations, privileged accounts, SaaS and on-premises systems in scope, and the asset inventory they map to | Privileged or contractor accounts omitted; cloud applications not feeding logs; scope document older than the current environment |
| Sampling of log sources | Log source inventory with onboarding dates, and sample logs from identity providers, directories, admin consoles and key applications | Sources configured but silently failing; logs present for some hosts only; no check that ingestion is ongoing |
| Review of detection rules and their tuning | Rule set with owners, change history, test results for behavior analytics thresholds and tuning decisions with reasons | Default rules never reviewed; exclusions added without approval; no evidence that rules were tested against known anomalous activity |
| Evidence of reviewed alerts and escalations | Alert queue records, triage notes, escalation tickets and closure reasons for a sample of alerts across the period | Alerts generated but not reviewed; closures without rationale; insider-threat cases not linked to HR or legal workflow |
| Testing of deception assets | Inventory of decoy accounts and deception objects, placement rationale, and alerts raised when those objects were touched | Decoys created once and forgotten; no alert routing to responders; decoys visible to ordinary users or excluded from logging |
| Evidence that failed access attempts are reviewed | Failed logon thresholds, reports of unusual failure patterns, follow-up actions such as lockouts or investigations | Failed attempts logged but never summarized; no threshold defined; lockout events not correlated with other alerts |
Open-source tools that produce personnel activity evidence
OpenSearch Security Analytics is a detection layer for logs already collected from hosts, network devices and cloud services. Its detectors match ingested logs against prepackaged or custom Sigma rules, and each match is recorded as a finding with the rule, log type and severity. Findings can send alerts to channels such as Slack or email, and a correlation engine links findings across log types in a correlation graph, which helps show when one user's activity spans several systems.
- Detector coverage: Confirm which prepackaged rules apply to your identity provider, endpoints and cloud accounts, then add custom Sigma rules for behavior your insider threat model covers.
- Finding records: Findings carry the rule, log type and severity, which are the fields an assessor will ask you to explain for each alert.
- Alert routing: Document who receives each channel, how acknowledgment is recorded and what happens when an alert goes unanswered.
- Correlation graph: Review links between findings to show analysis of related personnel activity, not only isolated events.
- License: OpenSearch is licensed under Apache-2.0, which carries attribution and notice obligations when you distribute the software.
Your organization still owns the rule tuning, the review cadence and the retention period for findings. Confirm with your assessor which findings they will sample and how long those records must remain available.
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 become alerts written to alerts.log and alerts.json, mapped to MITRE ATT&CK techniques and forwarded to the Wazuh indexer for review in the dashboard. The result is a machine-readable trail of which personnel activity triggered which rule, at what time and on which host.
- Built-in ruleset: Review the over 3,000 built-in rules and decoders against the systems you actually run, and disable rules that do not apply so the alert stream stays reviewable.
- Custom rules: Write rules for logons outside approved hours, repeated failed authentication and access to sensitive paths, and keep them under version control.
- Alert files: alerts.log and alerts.json are the primary artifacts an assessor can sample, so set retention on the files and the indexer to match your stated policy.
- ATT&CK mapping: Use the technique tags to show coverage of insider and credential misuse behaviors in your detection documentation.
- License: Wazuh is licensed under GPL-2.0-only. Review what distribution or modification of the software triggers source obligations for your environment.
Wazuh produces alerts, not conclusions. Your team must record triage decisions, false positive tuning and escalation outcomes so the evidence shows review, not only detection.
Nextcloud's admin_audit app records additional event information to an audit log. By default the log is written to audit.log in the data directory, or to a different path set with logfile_audit. For personnel activity on file collaboration, this log is the record of administrative and user events that your team can search, export and forward to a central store.
- Log location: Confirm whether the default audit.log in the data directory or a path set with logfile_audit fits your storage, permissions and backup design. Restrict read access to the log.
- Enabling the app: Verify that admin_audit is installed and active in every instance in scope, including staging systems that hold copies of production data.
- Forwarding: Ship the audit file to your central log platform so it is not solely on the application host, where it can be altered or lost with that host.
- Retention: Set a retention period in your policy and apply it to the log files, rotated archives and any forwarded copies.
- License: Nextcloud is licensed under AGPL-3.0-only. If you modify the server and offer it to users over a network, the AGPL source obligations apply to those modifications.
The app does not decide what counts as adverse. Your team must define which events are reviewed, by whom and how often, and keep those review records alongside the log.
OpenBao audit devices keep a detailed JSON log of every API request and response, including errors. Most sensitive values are hashed with HMAC-SHA256, so the log shows who accessed a secret or policy and when, without storing the secret itself. For personnel activity, this is the record of privileged access to credentials and secrets management.
- Device enablement: Enable at least one audit device before any production traffic and confirm that requests fail closed if the audit device cannot write, according to the behavior you have verified in your deployment.
- Hashed values: Explain to assessors that HMAC-SHA256 hashing protects sensitive values, and keep the key handling for the hashing salt under your own control.
- Coverage: Confirm which request paths, including administrator and token operations, appear in the log before relying on it as access evidence.
- Central storage: Forward JSON logs to a store that privileged users cannot edit, and set retention to match your access review cycle.
- License: OpenBao is licensed under MPL-2.0. Modifications to MPL-covered files must be made available under the same license when you distribute them.
Before an assessment, test a sample of logged privileged requests against your change tickets and approvals so you can show the log matches authorized activity.
Evidence that shows personnel activity monitoring is running
An assessor testing DE.CM-03 wants proof that personnel activity is monitored, that alerts are reviewed and that the monitoring itself is maintained over time. The cards below name the artifacts that carry that proof and how to refresh each one between audits, so the evidence reflects current operation rather than a snapshot prepared for the audit.
Monitored source inventory
A current list of every log source feeding personnel activity analysis, such as directory services, endpoints, VPN gateways, file shares, SaaS admin consoles and cloud control planes. For each source, record the owner, the log types collected and the date coverage was last confirmed. Check that identity and privileged access sources appear, because a missing source means activity on it cannot be detected. Refresh the inventory on a fixed schedule and after every new system onboarding, and have the system owner sign off each change.
Detection rule catalog with change history
The set of behavior and access rules that flag unusual personnel activity, with the rule source, severity, log type and the owner who approved each change. Wazuh rulesets and OpenSearch Security Analytics detectors built on Sigma rules can both be exported as configuration. Keep the version history in version control so an assessor can see when a rule was added, tuned or disabled and why. Confirm that disabled rules have a recorded justification.
Alert and finding exports with review dispositions
Exports of alerts and findings that show each item was reviewed and closed with a disposition, such as benign, confirmed, false positive or escalated, along with the reviewer and the review date. An export of raw alerts without dispositions shows that the tool worked, not that people acted on it. Schedule the export monthly or quarterly, store it with the reviewer sign-off, and sample a set of entries to confirm the disposition matches the underlying log.
Escalation and incident records
Tickets and case records that show how a personnel activity alert moved from triage to investigation, containment or closure, including timestamps, the people involved and any HR or legal referral. This is where an assessor checks that monitoring feeds a real response path. Keep a sample of closed cases with their decisions and lessons recorded. Confirm that the case management system retains these records for the period your audit covers.
Deception asset register and interaction logs
A register of decoy accounts, honeytokens and other deception assets, with the owner, the purpose, the location and the date each was deployed or retired. Pair it with the logs of any interaction with those assets, since NIST's Implementation Example covers monitoring deception technology, including decoy accounts, for any use. Review the register to confirm that retired decoys are removed from directories and that no legitimate process depends on them.
Access log retention settings
Configuration evidence showing how long logs of logical access and application activity are kept and where they are stored. Examples include the Nextcloud admin_audit app writing to audit.log, and OpenBao audit devices recording every API request and response in JSON. Capture the actual configuration keys and file paths from each system, along with the retention policy and any archive destination. Confirm that log integrity and access to the log store are restricted, and test that a sample of old entries can still be retrieved.
What meeting DE.CM-03 costs in money and effort
This table lists the cost components behind DE.CM-03 personnel activity monitoring, who is paid for each, whether it is one-time or recurring, and what moves it up or down. Use it to build a written scope and to ask vendors and implementation partners for line-item quotes. Fees follow from the agreed scope, so the main takeaway is that self-hosted open source removes license spend but not the staffing and tuning work.
| Cost component | One-time or recurring | What drives it | How to keep it down |
|---|---|---|---|
| Log platform and licensing | Recurring if commercial; none for the license if self-hosted | Event volume, number of log sources, retention period, and whether the platform is a commercial subscription or self-hosted open source | Choose open-source components such as OpenSearch Security Analytics or Wazuh, but budget for hosting, storage and support contracts |
| Engineering time to onboard log sources | One-time, with recurring updates when systems change | Number of identity providers, directories, applications and cloud services that emit access logs, and their log formats | Prioritize sources that record logical access and privileged actions first, and reuse existing decoders and rules |
| Rule writing and tuning | One-time build, then recurring tuning | Number of Sigma or custom rules for failed attempts, unusual access patterns and insider-threat behavior, plus false-positive rates | Start from prepackaged rules, document each rule's purpose and owner, and review noisy rules on a fixed schedule |
| Analyst review time | Recurring | Alert volume, severity thresholds, on-call coverage, and the depth of investigation each alert requires | Route alerts by severity, define triage steps in writing, and correlate related findings so analysts review incidents rather than single events |
| Deception asset build and upkeep | One-time build, recurring upkeep | Number and realism of decoy accounts, placement across systems, and how often decoys are rotated or retested | Limit decoys to high-value systems, keep naming and monitoring logic in configuration, and assign one owner for upkeep |
| Evidence retention storage | Recurring | Retention periods set by the organization's own policy and contracts, log volume, and whether audit logs are stored in tamper-resistant form | Set retention by log class, compress and archive older records, and confirm storage terms in the written scope |
| Independent testing or review | Periodic | Scope of the review, whether detection logic is tested with simulated insider activity, and whether an external assessor reviews the evidence | Ask for a defined test plan covering a sample of accounts and rules, and keep the scope to DE.CM-03 outcomes |
| Auditor sampling effort | Periodic, recurring with each assessment cycle | Number of accounts, alerts and review records the auditor samples, and how easily the organization can produce them | Keep review tickets, alert dispositions and rule change records in one searchable place before the assessment starts |
Who does what: your team, a partner and the auditor
Your organization owns DE.CM-03 as an outcome. Your team decides which personnel activity and technology use is monitored, who reviews the signals, which detection rules are authoritative, how each alert is dispositioned, and how long logs are kept. These decisions stay with you even when a partner configured the platform. Auditors will ask staff to explain them, so they must be written down and owned by named roles.
- Scope decisions: Define which identities, privileged accounts, applications and data stores fall under user behavior analytics, logical access log review and deception assets.
- Review ownership: Assign a named analyst or team to review findings on a defined schedule, with backup coverage for absences.
- Rule governance: Approve changes to detection content, including Sigma rules and custom rules, and keep a record of who changed what and why.
- Disposition and escalation: Decide what counts as a suspicious finding, when it becomes an incident, and who is told.
- Retention and access to logs: Set retention periods and restrict who can read or alter audit records.
Confirm that each of these decisions has an owner, a written procedure and a record that an auditor can sample.
An implementation partner such as DeployOpen prepares the systems and evidence that let your team run the control. In practice this means collecting logs from identity providers, hosts, applications and cloud services into a self-hosted platform, loading and tuning detection content, creating deception assets such as decoy accounts, building dashboards and producing evidence exports. The partner works inside your infrastructure and under a written, fixed scope. It does not decide what your organization considers an adverse event, and it does not issue audit reports or certifications.
- Log collection: Connect sources and confirm that access and audit events arrive complete and with reliable timestamps.
- Detection content: Deploy and adjust rules in tools such as Wazuh or OpenSearch Security Analytics, then document the logic and known gaps.
- Deception assets: Build and place decoy accounts and monitor them for any use.
- Evidence exports: Produce repeatable reports showing that monitoring ran, alerts were generated and reviews were recorded.
- Scoped testing: Simulate misuse under a written scope to show whether detections fire, then report the results to your team.
Confirm in the statement of work that the partner's deliverables are configurations, runbooks and evidence, and that your team signs off on each one.
The independent auditor tests whether the control is designed appropriately and operates effectively over a period. Depending on the framework and the engagement type, the auditor may be a CPA firm, an accredited assessor or a certification body. Only that party issues a report, attestation or certificate. NIST states that it does not offer certifications or endorsements of CSF-related implementations or services, so no certificate for DE.CM-03 exists from NIST itself.
- Design testing: Check that monitoring coverage, rule ownership and review procedures are defined and suit the stated risk.
- Operating effectiveness testing: Sample alerts and review records across the period to confirm that reviews happened and were documented.
- Independent evidence requests: Ask for raw logs, change records and deception asset configurations, and check them directly rather than relying only on partner summaries.
- Exception handling: Record gaps, such as missed review days or unmonitored accounts, and assess their effect.
- Report issuance: Only the auditor issues the final opinion or report, based on its own work.
Confirm the auditor's accreditation or eligibility with the framework owner before you commit to scope, and agree with the auditor in advance which evidence it will accept.
Where personnel activity monitoring programs usually fall short
Most personnel activity monitoring programs fail in the gap between collecting logs and acting on them. The cards below cover the gaps assessors and implementers see most often, and each one pairs the gap with a concrete fix and the evidence that shows the fix works.
Logs collected but never reviewed
Access and activity logs flow into a central store, yet no one has a defined review cadence or owner. DE.CM-03 asks for personnel activity to be monitored, so an assessor will look for proof that someone reads the output. Close the gap by assigning a named reviewer to each log source, setting a review frequency in writing, and recording who reviewed what and what they found. Evidence: dated review records, tickets raised from log findings, and the reviewer's sign-off.
No baseline for normal behavior
Behavior analytics can only flag anomalies against a known norm. Without a baseline of typical logon times, data volumes, login locations and application use per role, alerts are either absent or noisy. Build baselines per role group, document the learning period and the assumptions behind it, and revisit them after organizational changes. Evidence: the baseline document, its approval date, and examples of deviations investigated against it.
Admin and service accounts excluded from scope
Privileged and service accounts often sit outside monitoring because they generate high volume or break automation. These are the identities most able to cause harm, so their exclusion leaves the largest blind spot. Bring administrator, break-glass and service identities into scope, and alert on use outside approved windows or from unexpected hosts. Evidence: a scope list that names every privileged and service account, and logs showing their activity reaching the monitoring platform.
Detection rules never tuned
Rules deployed once and left alone generate alerts that analysts learn to ignore, which defeats the monitoring purpose. Review alert outcomes regularly, suppress known benign patterns with a recorded reason, and retire rules that never fire or always fire. Sigma rules and the prepackaged rulesets in tools such as Wazuh and OpenSearch Security Analytics need this same lifecycle. Evidence: a rule change log, false-positive rates by rule, and tuning approvals.
Deception assets built without owners
Decoy accounts and honeytokens are useful only when someone knows they exist, what they are for and who responds when they trigger. Assets built by one team and forgotten create confusion during an incident and may be mistaken for real accounts. Assign an owner to each decoy, document its purpose and expected use, and route its alerts to a defined response path. Evidence: a register of decoys with owners, alert routing tests, and records of triggered decoys handled.
Failed-attempt logs without retention rules
Failed logon records are essential for spotting password spraying and brute force, but they are often kept indefinitely in some places and purged unpredictably in others. Define a retention period per log type, enforce it in the platform, and confirm that audit logs of administrative changes are protected from deletion. Ask your platform owner to confirm the default retention settings in your environment, since defaults vary by product. Evidence: a retention schedule, configuration screenshots or exports showing it applied, and deletion records.
Questions buyers ask about DE.CM-03
Can we meet DE.CM-03 in-house with open-source tools?
Yes, many organizations do, because the outcome is about monitoring personnel activity and technology use, and self-hosted platforms can collect and alert on that activity. The organization still owns the control: it must decide what to monitor, who reviews alerts, how findings are handled and what records are kept. The main questions are staff capacity and skills. Tools such as OpenSearch Security Analytics, which runs Sigma-based detectors, or Wazuh, which compares events against a ruleset of over 3,000 built-in rules and decoders, can be deployed in your own environment. Ask an implementation partner to confirm which log sources your systems produce before you commit to a design.
What drives the effort to implement DE.CM-03?
Effort depends mainly on how many systems, identity sources and applications produce logs about user activity, and how much of that data is already captured. Other drivers include the number of detection use cases you choose (behavior analytics, logical access log review for unusual patterns and failed attempts, and deception technology such as decoy accounts), the quality of existing identity and audit logging, and how alerts are routed to people who can act on them. Tuning detections to reduce false positives usually takes sustained work after go-live. Ask any provider for a written scope that lists each log source, each detection use case and each alert route.
How long does a first DE.CM-03 implementation usually take?
No reliable duration can be stated without a defined scope, so treat any single number you see with caution. The time to a first working deployment is set by the number of log sources to onboard, whether identity and access logs are already centralized, the access your team can grant for installation, and how many change approvals and testing windows apply in your environment. Detection tuning and alert review continue after the first deployment. Ask for a written timeline that separates collection, detection build, alert routing and tuning, with the dependencies on your side named explicitly.
What does the work need from our internal staff?
Your staff must provide decisions and access that no outside party can supply. Typical needs include an owner for the control, identity and system administrators who can enable and export logs, a security analyst or on-call function that reviews alerts, and an HR, legal or privacy contact who approves what personnel monitoring covers. Staff also need time to review alerts during testing and tuning. Ask a provider to list these roles in the scope so you can confirm availability before work starts.
Does NIST certify that we comply with DE.CM-03?
No. NIST does not offer certifications or endorsements of CSF-related products, implementations or services, and it has no plans to develop a conformity assessment program. Alignment with DE.CM-03 is demonstrated through your own documented results and, if you need independent assurance, an assessment by a qualified outside party. Be wary of any offer that claims a NIST certificate. Ask providers to describe what they will deliver, such as evidence packages and configuration records, and who will judge the result.
What will an assessor ask to see for DE.CM-03?
An assessor will typically ask whether personnel activity and technology use are actually monitored, how the monitoring is configured and whether adverse events are detected and reviewed. Expect requests for documented log sources, the detection rules or use cases in force, samples of alerts with how each was triaged, evidence of logical access logs being reviewed for unusual patterns and failed attempts, and records of deception technology such as decoy accounts. Map your evidence to the CSF Core and to the informative references you rely on, such as SP 800-53 AU-12 or AC-2, so the assessor can trace each claim. Ask your assessor which evidence format they prefer before you collect it.
Does behavior analytics require employee notice or legal review?
Usually yes, and the decision belongs to your organization, not to the tool or the implementer. Monitoring employee activity is governed by employment law, labor agreements, data protection rules in your jurisdiction and internal policy, and the rules differ by country and sector. Legal and HR should confirm what is collected, how long it is kept, who can access it, and what employees are told. Data minimization and purpose limitation are common review points. Ask counsel to approve the monitoring scope in writing before any collection starts, and ask your implementation partner to configure access controls that match that approval.
What should we ask for in a written scope for DE.CM-03?
A useful scope lists the systems and log sources in scope, the detection use cases and their intended outcomes, the platforms and versions to be deployed, the evidence to be delivered and in what format, the roles each party owns, and the acceptance criteria. Also ask who approves monitoring rules, how alerts are routed, how tuning is handled after go-live, and what support or retainer arrangements apply. DeployOpen plans and implements self-hosted platforms in the client's own environment and prepares evidence, but it does not issue audit reports or certifications. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and a quote follows from that written scope.
How DeployOpen scopes and prepares DE.CM-03 evidence
DeployOpen plans and implements the self-hosted open-source platforms that collect and analyze personnel activity logs for DE.CM-03, inside your own cloud accounts, data centers or air-gapped networks. We prepare the systems, detection content and evidence, while your organization owns the control and an independent auditor or assessor issues any report.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope names which identity, access and application logs feed monitoring and which hosts and platforms are included.
- We confirm which insider threat use cases, failed-attempt rules and deception elements your organization has decided to run.
How we build
- We deploy log collection and analytics components, such as Wazuh or OpenSearch Security Analytics, within your environment.
- We configure detection rules for unusual logical access patterns and repeated failed attempts, documenting each rule and its owner.
- We test alert paths end to end, including sample events, and confirm findings reach the channels your responders use.
How we hand over
- You receive configuration records, rule inventories, data retention settings and the audit log locations for each platform.
- Documentation maps each deliverable to DE.CM-03 and the related Implementation Examples so your assessor can trace evidence.
- Handover sessions walk your staff through alert triage, review cadence and how to export evidence for an assessment.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover rule tuning, platform upgrades and periodic checks that monitoring still produces the expected evidence.
- Ask any provider to confirm in writing who owns the control, who runs the tools and who issues the assessment report.
