Security Protection Data in CMMC
Why Logs and Monitoring Tools Expand Your Level 2 Scope
Your SIEM, your firewall logs, your vulnerability scan results, and the MSP managing them — none of these sit quietly outside your CMMC assessment boundary. Under the DoD scoping guidance, the data these tools generate is regulated, the assets generating it are fully assessed, and the providers touching it are pulled into your audit.
Under 32 CFR Part 170, Security Protection Data (SPD) is defined as the data generated, processed, or stored by a Security Protection Asset — including the configuration data required to operate the asset and the log files it generates or ingests. Security Protection Assets (SPAs) are the systems that perform security functions for your CMMC assessment scope: scanning for vulnerabilities, aggregating audit logs, enforcing network boundaries, or detecting threats.
The scoping consequence, stated directly in the DoD CIO's CMMC Level 2 Scoping Guide: SPAs are inside your assessment boundary and are assessed against the Level 2 requirements relevant to the security capabilities they provide. Because SPD includes configuration data and log files — not just CUI documents — any system storing, processing, or transmitting that data is carrying sensitive operational information with defined protection obligations.
SPA and SPD Defined Side by Side
The two terms are tightly coupled — every SPA generates SPD, and every system holding SPD is either an SPA or connected to one. Understanding the relationship makes scoping decisions cleaner.
Which Tools Generate SPD — and How Each One Affects Scope
Any system that observes, logs, or defends your CUI environment qualifies as a Security Protection Asset and generates Security Protection Data. The five tool categories below account for the majority of SPA classifications in CMMC Level 2 assessments.
The "Relevant Controls" classification means the SPA is not assessed against all 110 NIST 800-171 practices — only those relevant to the security function it performs. A firewall is assessed against network protection, configuration management, and access control practices. It is not assessed against personnel security or physical protection practices applicable only to facilities with direct CUI handling. This nuance matters for scoping decisions involving specialized security tools.
Where SPD Lives — and Why Location Determines Scope
The scope consequence of SPD is driven not just by the tool generating it but by where the data lands after generation. A log file that stays on an on-premises server inside your enclave is a scoping footnote. The same log file exported to an MSP's SIEM platform outside your certification boundary is a scope expansion that brings the MSP's people, technology, and facilities into your assessment.
Evidence Expectations: How Assessors Verify Security Tooling
Assessors scrutinize SPAs more intensely than almost any other asset category, because security tooling failures are evidence of systemic compliance gaps — not isolated misconfigurations. They will apply all three assessment methods to each SPA: Examine the configuration and output, Interview the control owner, and Test the live system.
The NIST SP 800-92 standard defines the specific data fields that audit log entries must capture to satisfy CMMC logging requirements. A log that captures events but omits required fields — such as user identity or outcome — is a partially compliant log that creates partial findings.
| Log Field | Requirement Status | What It Captures |
|---|---|---|
| Event Type | Required | The action that occurred — login, file access, configuration change, privilege escalation |
| Timestamp (UTC) | Required | When the event occurred, synchronized to a reliable time source (NTP) |
| Source and Destination | Required | IP addresses and hostnames of the origin and target systems involved |
| User Identity | Required | The account or principal associated with the event — not just the system generating the log |
| Outcome / Result | Required | Whether the event succeeded or failed — critical for detecting failed authentication and access attempts |
| Supplemental Data | Conditional | Application-specific context, error codes, or additional fields required for specific control practices |
How to Contain SPD Sprawl: Boundary Design and Documentation
SPD sprawl — security data scattered across tools, tenants, providers, and systems without clear ownership or boundary documentation — is one of the most common causes of unexpected scope expansion in CMMC Level 2 assessments. Three design patterns prevent it.
Rather than building and operating on-premises log management or SIEM infrastructure, use cloud service providers with FedRAMP Moderate or High authorization to host your security tooling. A FedRAMP-authorized SIEM platform inherits a substantial set of infrastructure and physical security controls, reducing the controls you must independently evidence.
The key requirement: obtain a Customer Responsibility Matrix from the provider showing exactly which controls they cover and which you must configure in your tenant. Platform authorization does not cover tenant configuration.
Security Protection Data must be accessible to authorized security personnel — and only them. If SIEM logs, scan results, and firewall configuration exports are stored on systems that general corporate users can reach, you have a data exposure risk and a scoping problem. Unauthorized internal access to SPD is not a CRMA non-issue — it is a finding against the relevant access control and audit logging practices.
Enforce VLAN segmentation and ACL rules around SPD storage systems with the same rigor you apply to CUI assets. An assessor who can demonstrate that an HR laptop can read your firewall configuration export will treat that as a boundary failure.
Any MSP or ESP that monitors your security tools, manages your SIEM, or reviews your logs as a service is interacting with Security Protection Data and qualifies as an SPA. Before engaging any such provider, require documentation of their own CMMC Level 2 certification or confirm their FedRAMP authorization status.
A certified provider can be referenced in your SSP with their certificate as evidence. An uncertified provider must be evaluated by your assessor as part of your engagement — their documentation, their staff, their infrastructure. The cost difference between these two outcomes is substantial.
| Control | Certified Cloud Provider | Your Organization | Notes |
|---|---|---|---|
| Physical security of SIEM servers (PE.L1-3.10.1) | ✓ | ✗ | Provider secures the data center. Inherited via FedRAMP authorization — no action required on your end. |
| FIPS-validated encryption for log data at rest (SC.L2-3.13.11) | ✓ | ✗ | Provider uses FIPS-validated modules. Verify via CMVP certificate number in their responsibility matrix. |
| User access controls for SIEM console (AC.L2-3.1.1) | ✗ | ✓ | Provider delivers the platform. You configure the accounts, roles, and access permissions. Your tenant config is the evidence. |
| Audit log review and alerting (AU.L2-3.3.2) | ✗ | ✓ | Provider collects and stores logs. You must review them, act on alerts, and document the review process. Collection alone does not satisfy this control. |
| Multi-factor authentication for SIEM access (IA.L2-3.5.3) | ⊘ | ⊘ | Provider enables MFA capability. You must configure and enforce MFA policy for all accounts with SIEM access. Shared — both parties have obligations to evidence. |
A Customer Responsibility Matrix for your SIEM or security monitoring platform. Every row where your organization carries responsibility must appear in your SSP with a specific implementation statement — the provider's authorization does not substitute for your configuration evidence.
The Bottom Line
Security Protection Data is the operational intelligence of your CUI defenses — what your firewall allows, what your scanner found, who your SIEM alerted on. The DoD treats it as regulated data with defined handling requirements, and the systems generating it as Security Protection Assets that are fully inside your assessment boundary.
The scope consequence is direct: every tool that monitors or defends your CUI environment, every provider who manages those tools or receives their output, and every system that stores the resulting data is part of your assessment. Containing that scope requires deliberate architecture — FedRAMP-authorized platforms, logically isolated SPD storage, certified service providers, and a Customer Responsibility Matrix that makes inherited controls provable.
Collecting logs is not the same as reviewing them. Owning a SIEM is not the same as operating it compliantly. Assessors have seen both patterns, and they test for both. The evidence they will ask for is not a dashboard screenshot — it is a dated log review record, a signed scan remediation report, and a configuration export that matches your documented baseline.