DE.CM-06 External provider monitoring: evidence guide

What DE.CM-06 external provider monitoring asks organizations to prove

DE.CM-06 external provider monitoring asks an organization to show that the activities and services of its external service providers are watched for potentially adverse events. When a provider holds administrative access, runs maintenance on your systems, or hosts something your operations depend on, an auditor or customer will want to see how that activity is observed, not just what the contract says. The Subcategory sits in the DETECT Function of NIST CSF 2.0, under the Continuous Monitoring Category, and its outcome is paraphrased as monitoring external provider activity for adverse events. NIST publishes two Implementation Examples. The first covers monitoring remote and onsite administration and maintenance that providers perform on organizational systems. The second covers watching cloud services, internet service providers and other providers for deviations from expected behavior. The Subcategory continues CSF 1.1 DE.CM-6 at the same identifier and absorbs part or all of CSF 1.1 DE.CM-7, according to NIST's transition spreadsheet.

The risk is straightforward. Vendor access is a path around internal controls: a support engineer logging in through a remote tool, or a managed service account with broad rights, can change configurations without passing through your change process. Much of that activity is also invisible to your own logs, because it happens in the provider's tooling, on the provider's infrastructure, or under credentials your identity team does not fully see. An organization that cannot see provider sessions cannot say whether they were expected, so it cannot detect a deviation in time to act on it. Start by listing every provider with privileged or remote access, then record which of their sessions, changes and API calls reach your own logs and which do not.

What usually makes this hard is the contract. Many agreements grant the provider broad operational rights but do not require session logs, notice of maintenance windows, or access to audit records in a usable format. Provider platforms are often multi-tenant, so the organization sees only its own tenant's summary, if that. Before signing or renewing, confirm with each provider which logs it will share, how often, in what format, and how long it retains them. Ask whether privileged sessions can be recorded and routed to your SIEM, and whether you can define what counts as expected behavior for their accounts. These answers decide whether DE.CM-06 can be evidenced at all.

Which providers, systems and accounts fall inside DE.CM-06

DE.CM-06 reaches every outside party that acts on or observes your systems, from remote administrators to cloud and network carriers. The scope decisions below determine how much monitoring work exists, so settle them before choosing tools. Each card names a provider type, the activity in scope and the question your team must answer.

Remote administrative sessions

Vendor engineers who log in over VPN, bastion hosts or vendor remote access tools to administer your systems are the most direct DE.CM-06 scope item. Inventory every provider account that can reach production, and mark each as persistent or just-in-time. Persistent accounts need continuous monitoring of session start, commands run and data touched. Ask the provider whether it uses shared accounts, since shared accounts make it impossible to attribute activity to a person.

Onsite technicians and maintenance visits

Field engineers who maintain servers, network gear, or industrial equipment in your facilities create activity that is partly physical and partly logical. Record each visit's window, the systems touched and the escort or approver. Connect badge and visitor logs to the logical sessions opened during the visit, so the two records can be compared. Confirm who reviews these records and how quickly a mismatch between a visit and a session gets raised.

Cloud service provider activity

Cloud providers act on your environment through their control plane, and their staff may access your tenant under documented conditions. Decide which provider-side events you can actually observe, such as administrative API calls, support access logs or configuration changes made on your behalf. Where the provider does not expose an event, record that gap as a risk and document the compensating check. Your baseline should name the expected regions, services and administrative roles.

Internet and network service providers

Internet service providers and transit carriers handle your traffic without operating your systems, so their activity appears as routing, DNS or link behavior. Scope the routing announcements, DNS resolvers and circuits you depend on, and define what normal looks like for each, including expected prefixes and resolver paths. Deviations here can signal hijacking or a failed failover. Confirm which carrier alerts and status feeds you receive and who is responsible for acting on them.

Managed security and IT service providers

Managed service providers that run your monitoring, firewalls or backups hold privileged access to the tools that detect adverse events, which makes their own activity a special case. Scope their administrative accounts on your security tooling, their access to log stores and their change tickets. Decide whether the provider's actions appear in your own audit trail or only in theirs, and where the two must be reconciled. Ask how the provider notifies you of its own incidents.

Documented baseline of expected provider activity

The Implementation Examples treat deviation from expected behavior as the test, so scope is incomplete without a written baseline for each provider. The baseline should list permitted accounts, access paths, typical session times, approved change types and expected data volumes. Without it, monitoring produces alerts that no one can judge. Review the baseline when contracts, support tiers or provider personnel change, and record who approved each revision.

How an assessor tests external provider monitoring

This table compares five test steps an assessor may run for DE.CM-06, the evidence each step asks for and the findings that most often come up. Read each row as a question the assessor will put to the organization, judged against the organization's own documented expectations for provider behavior, because NIST does not set numeric thresholds. The independent auditor or certification body draws the conclusion, not DeployOpen.

Test area	Test approach and evidence requested	Common findings
Provider inventory and baselines	Assessor reviews the list of external providers with access to systems, such as managed service, cloud, ISP and remote maintenance vendors, and the documented expected activity for each. Evidence: current provider register, access grants and written baseline of expected behavior.	Providers with access are missing from the register, or baselines exist only as informal knowledge held by one administrator.
Provider session sampling	Assessor selects a sample of provider sessions, including remote and onsite maintenance, and checks that each session has a logged start, end, account used and purpose. Evidence: session records, change or ticket references and audit log extracts.	Sessions logged under shared or generic accounts, or sessions with no matching ticket or approval.
Alert triage and closure	Assessor traces alerts raised on deviations from expected provider behavior to their disposition, confirming someone triaged each one and closed it with a written outcome. Evidence: alert records, triage notes, escalations and closure entries.	Alerts exist but show no owner, no review date or no closure reason, or were suppressed without a recorded decision.
Contract and service terms	Assessor reads the contracts and service terms with each material provider to confirm the organization can obtain provider logs or activity reports when needed. Evidence: signed agreements, log access clauses and notice or retention terms.	Contracts silent on log access, or the organization cannot obtain logs for a cloud or ISP service it relies on.
Cloud and ISP feed review	Assessor confirms that cloud service and internet service provider activity feeds reach a monitored destination and that a named role reviews them on a stated schedule. Evidence: log routing configuration, dashboard or SIEM views, and review records.	Feeds are enabled but routed nowhere, or reviewed only when an incident prompts it, with no recurring record.

How to implement external provider monitoring step by step

This sequence turns DE.CM-06 from a policy statement into working monitoring: every external provider and access path is known, its normal behavior is written down, provider activity reaches a central store, deviations raise alerts that someone owns, and the path is tested before an assessor asks to see it.

Inventory external providers and their access paths
Start by listing every external provider that touches your systems: managed service providers, software vendors with remote support, cloud and internet service providers, and contractors with onsite maintenance rights. For each one, record the systems they reach, the access route (VPN, bastion host, vendor portal, remote desktop, API key, physical visit), the accounts they use and the business owner who approved the access. Done means a provider register exists, each row names an accountable internal owner, and no access path is listed as unknown. Ask each owner to confirm the register, because providers often hold access that was granted for a project and never removed.
Define expected behavior as a written baseline
For each provider and access type, write down what normal activity looks like: expected working hours or change windows, the systems and accounts involved, the commands or functions typically used, the source addresses or regions, and the volume of sessions. Cloud and internet service providers also need a baseline for the control-plane and network activity you expect from them, such as administrative API calls and routing changes. Store the baseline document under change control and have the provider's contract manager review it. The output is a baseline document that a security analyst can use to decide whether a given session is an exception.
Route provider and cloud logs into a central store
Configure each system that a provider can reach to send its activity to one central store. Typical sources include session recordings or jump host logs, application audit logs, cloud audit trails, and network telemetry for the VPN and firewall paths. Open-source platforms can carry much of this: Nextcloud's admin_audit app writes additional event information to audit.log in the data directory or to a path set with logfile_audit, OpenBao audit devices keep a JSON record of every API request and response, and Wazuh collects and decodes logs from hosts and cloud sources. Confirm the exact configuration keys and retention settings in each product's documentation. Done means a test event from each provider access path appears in the central store with the provider identity attached.
Write detection rules for deviations and assign owners
Translate each baseline into detection logic. Examples include a provider session outside its approved window, a login from an unrecorded source, use of an account that should be dormant, administrative actions outside the change record, and bulk data export by a support account. In OpenSearch Security Analytics, detectors can match ingested logs against Sigma rules and send alerts to channels such as Slack or email. In Wazuh, custom rules can be written against decoded events, and matching alerts are written to alerts.log and alerts.json. Assign each rule a named owner, a triage path and an escalation contact in the provider's contract. Done means every rule has an owner and a documented response, and the alert records show the rule, the provider and the severity.
Set the review cadence and record each review
Agree a review cadence with the business owners for each provider, based on the access risk you assessed in step one. At each review, the owner checks alerts raised for that provider, confirms or closes the provider's open sessions, compares actual activity with the baseline, and records any change to the baseline. Keep the review record in the same system as the change tickets so that an assessor can trace a review to an alert and a decision. The cadence itself is a decision for your organization, and your assessor will look for evidence that the cadence was followed rather than for a particular interval. The output is a dated review log with reviewer, scope and outcome for each entry.
Test the path with an out-of-pattern provider action
Run a controlled test in which an authorized test account, acting as a provider, performs an action that falls outside its baseline, such as a login from an unexpected source or an administrative command the provider does not normally use. Confirm that the event reaches the central store, that the detection rule fires, that the alert reaches the named owner, and that the owner's response is recorded. Record the test plan, the expected and actual results, and any gaps, then fix the gaps and retest. This test gives you direct evidence that the monitoring works, which is more useful to an assessor than a description of the design. Run it against a non-production copy where the production system could be affected.
Update contracts and runbooks so provider logs stay available
Update provider contracts and statements of work so that the provider must keep and share the logs you need, must notify you of changes to its own access paths, and must support your review and any incident investigation. Add the monitoring steps to the runbooks for onboarding and offboarding a provider, so that every new access path enters the register and every retired path is removed from the baseline and the rules. Ask legal or procurement to confirm the log retention and access terms, because these depend on the contract and on your jurisdiction. Done means the contract clauses and runbook changes are signed off, and a sample offboarding confirms that the provider's access and its monitoring rules are both removed.

Evidence that satisfies external provider monitoring

DE.CM-06 is tested by asking whether provider activity is visible and whether deviations get noticed and handled. The cards below are the artifacts that show this, and most of them need to be refreshed on a schedule rather than prepared once. Confirm with your auditor which samples and time periods they will request before you build the evidence set.

External provider register with access paths

A maintained list of every external service provider with access to your systems, the access path each uses (VPN, bastion, vendor portal, API key, onsite visit), the systems reached, the named internal owner and the approval date. Assessors use it to confirm that monitoring covers every provider, so a missing provider is a finding even if its logs look clean. Review the register after every access change and reconcile it against identity provider accounts each quarter. Ask your auditor how they want provider accounts identified in the register.

Expected-behavior baselines per provider

A written baseline for each provider describing normal activity: which accounts log in, from which source addresses, at what hours, against which systems and for which tasks. DE.CM-06 asks you to detect deviations, and a deviation cannot be recognized without a baseline. Store the baseline with the register, record who approved it, and update it when a provider's scope of work changes. Cloud and internet service provider baselines should also state the expected change activity and service status notifications you accept from them.

Sample log extracts showing provider sessions

Exported log entries for provider sessions from your audit trail, showing the account, timestamp, source, target system and actions taken. Assessors often select a sample of sessions and trace each one back to an approved ticket or maintenance window. For open-source platforms, Nextcloud's admin_audit app writes additional event information to audit.log, so confirm which events are enabled before relying on it. Export a representative sample each quarter and store it with the session's approval reference so the trail stays traceable.

Alert and triage records for deviations

Records showing that a provider deviation produced an alert, was reviewed, and was closed with a documented outcome. Keep the rule that fired, the event, the analyst's decision, and any escalation or contract action. A monitoring tool that generates alerts but has no triage history gives an assessor little to test. Wazuh writes matching alerts to alerts.log and alerts.json and maps them to MITRE ATT&CK, and OpenSearch Security Analytics records matches as findings, so both can supply the triage trail. Confirm which rules cover provider accounts before the assessment period starts.

Review sign-offs with dates

Dated approvals by the control owner confirming that the provider register, baselines and deviation reviews were checked for the period. Without a sign-off, an assessor cannot tell whether monitoring is run or simply configured. Record the reviewer, the date, the items reviewed and any changes made. Schedule the review at least as often as your own policy sets, and add an ad hoc review after any provider incident or contract change so the record stays current.

Contract clauses granting log access

Contract terms that let your organization receive or request logs of provider activity, define notification of security events, and require cooperation during investigations. Without them, monitoring can break at the point where a provider controls the evidence. Check that clauses cover remote and onsite access, subcontractors, and cloud or internet service providers whose logs you depend on. Legal and procurement own these clauses, so review them when contracts renew and when a provider changes its service model, and keep the signed version with the register.

Which open-source tools can produce provider monitoring evidence

Self-hosted open-source tools can collect and preserve the records that show what external providers did in your environment, but they do not decide what counts as expected behavior. That baseline comes from your own provider agreements, change windows and access approvals, and it has to be written down before any tool can flag a deviation. For DE.CM-06, the practical question is which of your provider access paths produce logs, where those logs land, and whether a reviewer can tie each entry to a named provider account and an approved task.

Nextcloud (AGPL-3.0-only) is relevant where a provider administers or maintains the file-sharing or collaboration platform. The admin_audit app writes additional event information to audit.log in the data directory, or to a path set with the logfile_audit setting, so administrative actions by provider accounts can be retained outside the application database. Confirm against the Nextcloud admin manual on logging which events are captured in your version, and whether provider sessions are distinguishable from internal administrators. OpenBao (MPL-2.0) audit devices keep a detailed JSON log of every API request and response, including errors, with most sensitive values hashed with HMAC-SHA256. That makes it a strong source for remote API access by a provider, but you should confirm that the hashing scheme and the fields you need for review are acceptable to your assessor, since hashed values cannot be read back to identify an account.

OpenSearch (Apache-2.0) Security Analytics can ingest logs from hosts, network devices and cloud services, match them against prepackaged or custom Sigma rules, and record matches as findings with the rule, log type and severity. It can send alerts to channels such as Slack or email and use its correlation engine to link findings across log types, which helps when a provider's activity spans a jump host, a cloud control plane and a network device. Wazuh (GPL-2.0-only) decodes collected logs and compares each event against a ruleset of over 3,000 built-in rules and decoders plus custom rules, writes matches to alerts.log and alerts.json, maps alerts to MITRE ATT&CK, and forwards them to the Wazuh indexer. Confirm that the built-in decoders parse the exact log formats your providers' access paths generate, and add custom rules where they do not. Have counsel review the license obligations of AGPL-3.0-only, GPL-2.0-only, MPL-2.0 and Apache-2.0 against how you plan to modify or distribute each component.

What meeting external provider monitoring costs in money and effort

This table lists the cost components of monitoring external provider activity for DE.CM-06, who is paid for each, whether it is one-time or recurring, and what drives it up or down. Use it to structure a quote request, since no currency figures or durations are supplied for these components. The main takeaway is that self-hosted open-source collection and detection can remove license spend, but staff time, hosting and provider contract work remain.

Cost component	One-time or recurring	What drives it	How to keep it down
Tooling or licenses	Recurring if commercial; open-source components carry no license fee	Number of log sources, event volume and whether SIEM or detection modules are commercial	Use self-hosted open-source collection and detection for the components that fit; budget hosting and retained staff time separately
Engineering time to build pipelines and baselines	One-time, with periodic rework	Provider count, access paths, number of log sources and how many expected-behavior baselines must be written	Start with the highest-risk providers and cloud services; reuse parser and rule templates across providers
Provider contract amendments and legal review	One-time per provider, plus renewals	Whether existing contracts already require logging, alert notification and access records from the provider	Standardize a monitoring clause for new contracts; amend renewals in batches
Ongoing review and alert triage	Recurring	Alert volume from provider sessions, review cadence, and how many provider changes and maintenance windows must be reconciled	Tune baselines against approved change tickets; agree a review cadence in writing and route provider alerts to a named owner
Evidence upkeep	Recurring	Frequency of evidence pulls, retention periods set by the organization, and the number of providers whose records must be kept	Automate exports of logs, approvals and review records; keep one evidence index per provider
External security testing or review of the monitoring design	Periodic, per engagement	Scope of the review, number of provider access paths tested and whether cloud configurations are included	Fix the scope in writing before work starts; test the monitoring design alongside related controls such as CA-7 or SI-4 coverage
Auditor sampling	Recurring, per assessment cycle	Sample sizes the auditor selects, the number of providers in scope and how complete the evidence is on first request	Keep a provider register and complete review records so samples can be pulled without rework

Who does what: our team, an implementation partner and the auditor

Your organization owns DE.CM-06. Monitoring external provider activity only means something when someone inside the organization has decided what the provider is allowed to do, what normal looks like, and what happens when activity falls outside that picture. NIST's Implementation Examples for this Subcategory describe monitoring remote and onsite administration and maintenance by providers, and monitoring cloud services and internet service providers for deviations from expected behavior. Those deviations can only be recognized against a baseline your team wrote and maintains.

Provider register: Keep a current list of every external service provider with administrative or data access, including the systems and accounts each one touches.
Expected behavior baselines: Define which remote sessions, maintenance windows, cloud API calls and network paths are normal for each provider, and who approves changes to those baselines.
Review cadence: Assign people to review provider access logs and alerts, and record the outcome of each review.
Contract terms: Write notification, log access and onsite visit obligations into provider contracts so monitoring is possible in practice.
Risk acceptance: Decide which deviations are acceptable, which trigger investigation, and who signs off on residual risk.

Check that every provider on the register has a named internal owner, a documented baseline and a contract clause that supports the monitoring you claim.

Where external provider monitoring usually falls short

External provider monitoring fails less often for lack of tools than for lack of inputs: no list of who has access, no agreed picture of normal provider behavior, and no record of what happened to the alerts. The cards below name six gaps that assessors commonly find under DE.CM-06 and one concrete action to close each.

No maintained register of provider access

Monitoring cannot cover providers the organization has not listed. Remote vendor accounts, onsite maintenance contractors, managed service staff and cloud administrators often accumulate over years of projects. Build a register that names each provider, the systems they can reach, the access method, the sponsoring owner and the review date. Reconcile it against identity provider accounts and VPN grants every quarter, and treat any account without a register entry as a finding to investigate.

Shared or persistent provider accounts

When several provider staff use one login, or a standing account stays enabled between visits, activity cannot be attributed to a person and alerts lose their meaning. Require named accounts for every provider user, time-limited access that expires after each maintenance window, and multi-factor authentication for remote sessions. Confirm in the contract that the provider will not share credentials among its own staff.

No written expected-behavior baseline

Deviation alerts have nothing to measure against when nobody has written down what a provider normally does. Document the expected pattern for each provider: which hosts they touch, which hours they work, which commands or API calls belong to routine maintenance and which do not. Store the baseline with the provider register and update it after each change request. Without it, a sudden burst of administrative activity looks identical to planned work.

Contracts silent on log access

Many provider agreements grant service delivery rights but say nothing about the organization's right to receive logs, session records or activity reports. Add clauses that require the provider to forward administrative activity logs, to retain them for an agreed period, and to notify the organization of suspected compromise within a defined time. Ask legal and procurement to confirm these terms before the next renewal, since changing them later usually requires the provider's agreement.

Cloud and ISP telemetry collected but never reviewed

Cloud control plane logs and internet service provider notices often reach a storage bucket or a mailbox that nobody reads. Route these sources into the same log pipeline as internal systems, assign a named reviewer, and set a review cadence that matches the risk. For example, a self-hosted Wazuh deployment can decode cloud audit events and compare them against its ruleset, with matches written to alerts.json for review in the dashboard. Confirm which cloud audit sources your provider exposes and how far back they are retained.

Alerts closed without a recorded decision

When an analyst closes a provider alert with no note, the organization cannot later show that it was reviewed or why it was dismissed. Require a short disposition for every provider alert: the expected activity it matched, the ticket or change request it relates to, the reviewer and the decision. Keep these records with the alert itself so that an assessor can sample them. Recurring false positives should lead to a baseline update, not a standing suppression rule.

Questions buyers ask about meeting DE.CM-06

How much effort does meeting DE.CM-06 take?

The effort depends mostly on how many external providers touch your systems and how much of their access is remote. Each provider needs its administrative sessions, maintenance windows and cloud or internet service activity brought into a log source you can review. Most of the work is one-time setup: identifying providers, enabling logging on their access paths, and defining what counts as expected behavior. The recurring work is reviewing the alerts and provider reports against that baseline, which grows with the number of providers. Ask any firm for a quote that breaks out setup and recurring review separately, and that lists the log sources in scope.

How long does it take to put external provider monitoring in place?

The duration is set by the drivers rather than a fixed figure, so no timeline can be given here without a written scope. The main drivers are the number of providers, whether their access already produces logs you can collect, how many systems and cloud accounts sit in scope, and how quickly your staff can agree on a baseline of expected provider behavior. Engagements that start with a complete provider list and existing logging usually move faster than those that must first discover who has access. Confirm the schedule, dependencies and acceptance criteria in the written scope before work starts.

What does the organization need to provide?

Several inputs are needed before monitoring produces useful evidence:

Can an internal team meet DE.CM-06 without outside help?

Yes, an internal team can meet DE.CM-06 if it has staff who understand the systems, the provider access paths and the log platform. The organization owns its controls, so the outcome is its responsibility either way. Outside help is most useful for planning the scope, configuring collection and detection across several platforms, and preparing evidence for an assessor. A partner such as DeployOpen can plan, implement and document the monitoring on self-hosted platforms in your own infrastructure, but it does not decide whether the control is met. Weigh your staff's time against the provider count and the log sources involved before deciding.

Does NIST certify that an organization meets the CSF?

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. The CSF is voluntary for most organizations, although some customers or suppliers may require alignment. If a contract asks for proof, the claim usually comes from a self-assessment, a customer audit or an independent assessment, and the scope of that claim should be written down. Check what your customer will accept as evidence before choosing an approach.

Who issues the evidence that counts for DE.CM-06?

An independent auditor, assessor or certification body issues the formal findings that a third party will rely on. Implementation partners prepare the systems, logs, alert rules and documentation that the assessor tests, but they do not issue reports or certificates. Your organization remains accountable for the control itself. Ask the assessor in advance which provider access records, review records and alert handling samples it expects, so the monitoring is built to produce them.

How does DE.CM-06 relate to ISO/IEC 27001:2022 controls 5.22 and 8.16?

The NIST CSF 2.0 Reference Tool lists ISO/IEC 27001:2022 Annex A controls 5.22 and 8.16 as informative references for DE.CM-06. Control 5.22 concerns monitoring, review and change management of supplier services, and control 8.16 concerns monitoring networks, systems and applications for anomalous behavior. Evidence gathered for one framework can often support the other, since both ask for records of provider activity and review. The mapping is a reference provided by NIST, so confirm the exact wording of each control with your certification body before treating the overlap as complete.

How DeployOpen works on this

DeployOpen approaches DE.CM-06 External provider monitoring as an implementation task inside your own infrastructure. We prepare the logging, detection and evidence that show how external providers act on your systems, while your organization keeps ownership of the control and its decisions.

How we scope

Written scope names each provider path in use, such as remote vendor sessions, onsite maintenance, cloud accounts and internet service provider feeds.
Scope records which expected-behavior baselines your team will approve for each provider before monitoring rules are built.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts. Ongoing support is available as a retainer.

How we build

We configure audit logging for administrative and maintenance actions in self-hosted platforms within your cloud accounts or data centers.
We build detection rules that flag provider activity deviating from the agreed baseline, then test them with recorded sample events.
We run security testing against the monitoring path itself so gaps in log collection or alert routing are found before an assessor does.

How we hand over

Handover includes documentation of each log source, detection rule, alert destination and the named owner who reviews it.
We package sample alerts, review records and provider access logs as evidence an independent assessor can sample and test.
Your team receives runbooks for triaging provider deviations, escalating them and recording the outcome in your own tickets.

How we support

Retainers cover rule tuning, upgrades to monitoring components and periodic checks that provider access stays within the written scope.
Continuous testing can re-validate detections after provider changes, new cloud services or updates to your ruleset.
Confirm with us during scoping which assessment evidence your auditor expects, since DeployOpen prepares evidence but does not issue reports.