CUI scoping for security tools — why your EDR and SIEM are probably in scope
A decision framework for classifying endpoints, SIEM, and cloud services under CMMC 2.0. Scope follows data flows, not product categories.
Most organizations handling Controlled Unclassified Information assume their security tools are out of scope for CMMC — because the tools are not where CUI is intentionally stored. That assumption is wrong more often than it is right. We published a series of scoping blueprints to make the decision framework concrete.
Where CUI lives — and the key distinction that matters
CUI lives on laptops, desktops, servers, AWS/cloud workloads, databases, and file shares. If a system stores, processes, or transmits CUI, it is a CUI Asset. That much is straightforward.
The distinction that trips most teams up is between CUI and Security Protection Data (SPD). CUI is business, contract, or technical information controlled under law, regulation, or government-wide policy — drawings, specs, contract data, program files. SPD is the security layer: logs, detections, configs, vulnerability data, security telemetry. SPD is used to protect the environment and may exist even when business CUI is not present.
A tool may not be a CUI repository, but it can still be in scope if it protects CUI assets.
The scoping decision flow
For any tool or service, walk through three questions in order.
First: does it store, process, or transmit CUI? If yes, classify as a CUI Asset — full CMMC scope.
Second: does it provide protection for CUI assets or handle SPD? If yes, classify as a Security Protection Asset — in scope for SPD.
Third: can telemetry, logs, uploads, memory captures, file names, screenshots, or command lines expose CUI? If yes, treat as possible CUI handling — validate features and data flows.
Only if all three are no does the tool have lower scoping impact — and even then, document the rationale.
The critical principle: scope is driven by actual data flows and enabled features, not just product category.
What EDR, SIEM, and cloud actually handle
Endpoint / EDR (e.g. CrowdStrike): base telemetry usually equals SPD — it protects endpoints that hold CUI. But optional features like file submission, sandboxing, live response, forensic collection, DLP, and data discovery may pull in actual CUI. Typical outcome: Security Protection Asset, but may handle CUI depending on enabled features.
NG SIEM: aggregates detections, logs, cloud audit data, and endpoint alerts. Usually contains SPD. But logs may include file names, object names, payloads, ticket text, or copied snippets — making the SIEM a potential CUI repository depending on log content.
AWS / Cloud: workloads, storage, databases, and backups containing CUI are in the CUI environment. Cloud-native security and logging services may be SPA or SPD unless actual CUI enters them. Typical outcome: mixed scope that depends on each service and data flow.
The key takeaway: EDR, SIEM, and cloud platforms are Security Protection Assets that handle SPD by design and may handle actual CUI depending on configuration, log sources, and use.
CUI protection architecture — the full data flow
The protection architecture has five stages. CUI environment (in-scope assets: laptops, desktops, servers, VMs, file shares, databases, AWS S3/EC2/RDS, apps that process/store/transmit CUI). Security Protection Layer (CrowdStrike/EDR/XDR, NG SIEM/log management, firewalls/IDS/IPS, cloud security tools like CASB/CSPM, vulnerability scanners). Assess and classify data flows — separating CUI content (files, DB images) from metadata that may reveal CUI (filenames, paths, commands). External Service Providers (MSSP managing EDR/SIEM, cloud provider, support/IR vendor, backup/DR provider, sandbox/threat intel vendors). Governance and artifacts (SSP, asset inventory, data flow map, responsibility matrix, vendor/ESP agreements, evidence for assessment).
Classify each tool: CUI? SPD? Both? Then define controls, access, retention, encryption, and vendor responsibilities.
CMMC 2.0 classification and service provider roles
Under CMMC 2.0, there are two primary classifications: CUI Assets (process, store, or transmit CUI — Level 2 scope) and Security Protection Assets (provide security functions for CUI Assets — Level 2 scope).
Service provider roles matter: an External Service Provider (ESP) processes, stores, or transmits CUI or SPD on your behalf. A Cloud Service Provider (CSP) provides cloud services that process, store, or transmit CUI.
FedRAMP terminology is evolving from Low / Moderate / High to new impact and risk-based tiers — Baseline Impact, Moderate Impact, High Impact, High Risk Impact. Use providers with the appropriate authorization level for CUI workloads under the new model.
The practical checklist
Six questions for every tool in scope:
1. What data enters the tool? 2. What features are enabled? 3. Can analysts view or export sensitive content? 4. Do logs contain file names, object names, commands, or payloads? 5. Does a vendor, MSSP, or ESP access the platform? 6. Is the system documented in the SSP, diagrams, asset inventory, and responsibility matrix?
The scoping exercise produces six artifacts assessors will ask for: network and data flow diagrams, asset inventory and classification, control mapping (NIST 800-171r3), shared responsibility matrix (RACI), ESP agreements and DPAs, and an evidence pack for assessments.
Rule of thumb: do not assume EDR or SIEM is out of scope just because it does not intentionally store business CUI. If it protects CUI assets or handles SPD, it is still relevant to scope. Continuous review is essential — reassess when tools, data types, or FedRAMP impact levels change.
Governance and operational controls
Six governance requirements that tie the scoping exercise to ongoing operations:
1. Document all tools in the SSP, asset inventory, and network diagrams. 2. Define data sources, retention, and data handling in the SSP. 3. Establish data minimization and masking rules for logs. 4. Vendor contracts must flow down security and data handling requirements. 5. Conduct regular access reviews and role recertifications. 6. Monitor, test, and continuously improve.
Risk questions to ask for every tool: can this tool collect CUI intentionally or unintentionally? Where is the data stored and for how long? Who has access, internal and external? Is it documented in the SSP? Is the vendor FedRAMP Authorized at the appropriate tier?