What network monitoring evidence does a CMMC Level 2 assessment actually ask for?
Short answer
A CMMC Level 2 assessment is not satisfied by saying: "Yes, we monitor the network." Assessors evaluate whether the organization has implemented the applicable CMMC Level 2 requirements and whether objective evidence supports that implementation. For network monitoring, logging, audit, incident detection, vulnerability management, boundary protection, and system integrity, evidence can include:
- Policies and procedures
- System Security Plan documentation
- Network and data flow diagrams
- Asset inventories
- Firewall and security configurations
- Audit logging configurations
- Actual system audit logs
- SIEM records
- Alert history
- Authentication records
- Administrative activity
- Incident tickets
- Investigation records
- Vulnerability scan results
- Remediation records
- Configuration baselines
- Change records
- Monitoring dashboards
- Endpoint security evidence
- IDS or IPS evidence where used
- Interviews with responsible personnel
- Demonstrations or tests of the mechanisms implementing the
requirement
The official CMMC Level 2 Assessment Guide uses three assessment methods repeatedly: Examine Interview Test That distinction matters. A screenshot of a dashboard can help demonstrate that a monitoring tool exists. It does not, by itself, prove that the organization has defined what should be monitored, configured the system correctly, retained appropriate records, reviewed events, responded to findings, protected audit information, and integrated monitoring into its cybersecurity program. The better question is not: "Do we have network monitoring?" It is: "Can we demonstrate, with repeatable evidence, how our monitoring supports each applicable CMMC assessment objective?" Important: This article is educational and is not CMMC certification, assessment, legal, or contractual advice. The evidence required for a particular assessment depends on the organization's CMMC Assessment Scope, architecture, implementation, contracts, and the specific assessment objectives being evaluated. Use the current DoD CMMC Level 2 Assessment Guide and Scoping Guide as the controlling references.
Why monitoring is where Level 2 gets real
Why Is Network Monitoring Important for CMMC Level 2?
CMMC Level 2 is designed to protect Controlled Unclassified Information, or CUI. Protecting CUI requires more than preventing unauthorized access. Organizations also need the ability to identify activity that could indicate:
- Unauthorized access
- Compromised accounts
- Malware
- Suspicious network behavior
- Configuration changes
- Security control failures
- Vulnerabilities
- Policy violations
- Attempted attacks
- Data exposure
- System integrity problems
Monitoring helps create visibility into what is actually happening inside the environment.
Does CMMC Require a Specific Network Monitoring Product?
No single monitoring product automatically satisfies CMMC Level 2. An organization might use combinations of:
- Firewall logging
- SIEM
- Endpoint Detection and Response
- Managed Detection and Response
- Intrusion detection
- Intrusion prevention
- Network monitoring
- Identity monitoring
- Cloud security logging
- Vulnerability scanning
- Configuration monitoring
- Ticketing
- Incident response systems
The architecture should support the applicable security requirements and assessment objectives.
Does CMMC Require a SIEM?
DoD's Level 2 Scoping Guide specifically identifies SIEM solutions as examples of Security Protection Assets when they provide security functions to the CMMC assessment scope. That does not mean every organization must purchase the same SIEM product. It means that if a SIEM is protecting the CUI environment, it is relevant to CMMC scope and should be documented and treated appropriately.
Security Protection Assets, and the part people miss
What Is a Security Protection Asset?
A Security Protection Asset, or SPA, provides security functions or capabilities to the CMMC Assessment Scope. Examples in DoD's Level 2 Scoping Guide include:
- Cloud based security solutions
- Hosted VPN services
- SIEM solutions
- Security Operations Centers
- Cybersecurity consultants
- MSP personnel who implement system maintenance
- Enterprise network administrators
These assets matter because they help protect the CUI environment.
Are Security Protection Assets in CMMC Scope?
Yes. The DoD Level 2 Scoping Guide requires the organization to document applicable Security Protection Assets in the asset inventory, document their treatment in the SSP, and include them in the network diagram of the CMMC Assessment Scope.
And then a fourth thing, which the documentation-focused reading of this consistently misses: Security Protection Assets are also assessed against the Level 2 requirements relevant to the security capabilities they provide. Listing your SIEM in an inventory does not put it out of reach. If a tool protects the CUI environment, the controls it implements are in play. Organisations that treat SPA handling as a paperwork exercise get a surprise at assessment. This is particularly important for organizations outsourcing monitoring to an MSP, MSSP, SOC, or cloud security provider.
Which version of NIST 800-171 this actually uses
Which Version of NIST 800-171 Does This Actually Use?
Get this right before anything else, because getting it wrong sends you to the wrong document.
CMMC Level 2 is assessed against NIST SP 800-171 Revision 2, using the assessment procedures in NIST SP 800-171A, June 2018. Both are named explicitly in the rule: 32 CFR 170.14(c) requires Level 2 to use "NIST SP 800-171 R2 (incorporated by reference)", and 170.11(a) requires assessments to be conducted "in accordance with NIST SP 800-171A Jun2018 (incorporated by reference)".
Here is the trap. NIST withdrew both documents on 14 May 2024, superseding them with Revision 3. So a reader who searches NIST for "800-171" today lands on Revision 3 — which CMMC does not use, and which has different control numbering.
The withdrawal has no effect on CMMC, and this is deliberate rather than an oversight. Incorporation by reference under 1 CFR part 51 freezes a specific static edition, approved by the Director of the Federal Register. The withdrawal predates the CMMC rule's effective date by seven months; DoD incorporated those editions knowing they had been withdrawn. They govern until DoD amends 32 CFR 170 through notice-and-comment rulemaking, which has not happened.
Practically: work from Revision 2 and the June 2018 A-document, and expect to have to hunt for archived copies.
What Does an Assessor Actually Do?
The CMMC Level 2 Assessment Guide uses assessment procedures derived from NIST SP 800-171A, June 2018. The three core methods are:
Examine
The assessor reviews evidence. Examples can include:
- Policies
- Procedures
- SSP
- Configuration settings
- Audit records
- Security logs
- Incident reports
- System documentation
Interview
The assessor talks with people responsible for implementing or operating the requirement. Examples can include:
- Security personnel
- Network administrators
- System administrators
- Incident responders
- Audit and accountability personnel
- Management
Test
The assessor evaluates whether the mechanism actually performs the intended function. That can involve demonstrations of:
- Logging
- Alerting
- Access restrictions
- Security mechanisms
- Monitoring
- Technical enforcement
This is why documentation alone is insufficient.
Audit logs: AU.L2-3.3.1 and what it asks
What Does CMMC Say About Audit Logs?
One of the most directly relevant Level 2 practices is commonly referenced as: AU.L2-3.3.1 — System Auditing. Note the hyphen: the CMMC identifier is AU.L2-3.3.1, and searching for a mangled version of it will find you nothing. The assessment objectives address whether the organization:
- Specifies which audit logs or event types are needed
- Defines the content needed in audit records
- Generates those records
- Includes the defined content
- Defines retention requirements
- Retains records according to those requirements
Potential evidence listed by the Assessment Guide includes audit policies, procedures, SSP content, design documentation, configuration settings, audit record procedures, actual system audit logs, auditable events, and incident reports.
Is Turning Logging On Enough?
No. Logging has several separate questions:
- What events should be logged?
- What information should each record contain?
- Which systems generate those records?
- Where are the logs collected?
- How long are they retained?
- Who can access them?
- How are they protected?
- Who reviews them?
- What triggers investigation?
- What happens after an alert?
An assessor can evaluate each part.
What Events Should We Monitor?
The exact event set depends on the environment and the organization's security requirements. Common examples can include:
- Successful authentication
- Failed authentication
- Privileged authentication
- Account creation
- Account deletion
- Privilege changes
- Administrative configuration changes
- Firewall policy changes
- VPN connections
- Endpoint security detections
- Malware events
- IDS or IPS alerts
- Vulnerability findings
- Security agent failures
- Logging failures
- Unauthorized software
- Network anomalies
- Cloud administrative events
- Access to sensitive systems
- Security tool configuration changes
The organization should define its auditable events deliberately.
Which systems produce useful evidence
Do We Need Logs From Every Device?
Not necessarily every event from every device. The organization should determine which systems and events are needed to support the applicable security requirements, monitoring, analysis, investigation, and reporting. The decision should be documented and defensible. Collecting enormous volumes of irrelevant logs without the ability to analyze them does not automatically improve compliance or security.
Which Systems Commonly Produce Useful CMMC Monitoring Evidence?
Depending on scope:
- Firewalls
- Routers
- VPN platforms
- Domain controllers
- Identity providers
- Servers
- Workstations
- EDR platforms
- Email security
- Cloud platforms
- File repositories
- DNS security
- Wireless infrastructure
- SIEM
- Vulnerability scanners
- Backup systems
- Administrative portals
- Security gateways
- SaaS platforms handling CUI
The asset inventory and network diagram should help identify the relevant sources.
Do Firewall Logs Matter?
Yes, when the firewall is part of the CMMC environment or provides security protection to it. Firewall evidence can help demonstrate:
- Boundary control
- Allowed and denied traffic
- Administrative changes
- VPN activity
- Security events
- Rule enforcement
- Segmentation
- External connections
But raw firewall logs alone do not prove that firewall rules are appropriate. Configuration evidence and review processes also matter.
What Firewall Evidence Should We Keep?
Depending on the environment:
- Firewall inventory
- Current configuration
- Rule base
- Network objects
- Administrative roles
- MFA settings
- Firmware version
- Security subscriptions
- VPN configuration
- Logging configuration
- Alert configuration
- Change history
- Rule review records
- Backup configuration
- Relevant security events
The evidence should connect to the requirement being assessed.
Do Fortinet, Meraki, SonicWall, Palo Alto, or Other Firewall Brands Change the Requirement?
No. CMMC requirements are not written around a specific firewall brand. The important questions are:
- What security function does the device perform?
- Is it in the assessment scope?
- How is it configured?
- How is it administered?
- What does it log?
- Who reviews the logs?
- How are changes controlled?
- Can the organization demonstrate that the mechanism works?
Availability monitoring, NOC and SOC
Does Network Availability Monitoring Count as CMMC Evidence?
It can support the cybersecurity program, but availability monitoring alone is not the same as security monitoring. For example: Ping succeeds does not tell you whether:
- A privileged account was compromised
- Malware executed
- Firewall rules changed
- CUI was accessed improperly
- A vulnerability was exploited
Operational monitoring and security monitoring can complement one another.
Can Ping and Traceroute Satisfy CMMC Network Monitoring?
Not by themselves. Ping and traceroute are useful troubleshooting and availability tools. They can help establish:
- Reachability
- Latency
- Path behavior
- Connectivity changes
But CMMC Level 2 security evidence requires a broader set of capabilities tied to applicable assessment objectives.
Can ADAM Pulse Monitoring Help With CMMC?
Potentially, as one component of the evidence and operational monitoring architecture. Network monitoring can help document:
- Availability
- Connectivity changes
- Circuit performance
- Device reachability
- Network events
- Historical behavior
- Alert generation
- Escalation
- Incident timelines
However, an availability monitoring platform should not be represented as satisfying every CMMC logging, SIEM, EDR, vulnerability, incident response, or security assessment requirement. The strongest architecture combines operational visibility with appropriate cybersecurity controls.
What Is the Difference Between NOC Monitoring and SOC Monitoring?
A Network Operations Center generally focuses on operational health. Examples include:
- Availability
- Latency
- Packet loss
- Circuit failures
- Device status
- Performance
- Escalation
A Security Operations Center focuses on security events. Examples include:
- Threat detection
- Suspicious authentication
- Malware
- Endpoint detections
- Security correlation
- Incident investigation
- Threat response
For CMMC, both can be useful, but they solve different problems.
Can the Same Team Perform NOC and SOC Functions?
Potentially, depending on staffing, expertise, tooling, procedures, and scope. The important issue is whether the required security functions are actually performed and can be demonstrated. Calling a help desk a SOC does not create a security operations capability.
What Does "Continuous Monitoring" Mean?
Organizations often use the phrase loosely. In practice, continuous monitoring means maintaining ongoing visibility into relevant security conditions rather than performing one annual snapshot. It can involve:
- Automated data collection
- Alerting
- Scheduled reviews
- Vulnerability scanning
- Configuration review
- Endpoint monitoring
- Security event analysis
- Risk review
The specific cadence depends on the control, risk, system, and organizational process.
Does CMMC Require Someone to Watch a Dashboard 24 Hours a Day?
CMMC does not reduce monitoring to one universal staffing rule. The organization should establish monitoring and response appropriate to the applicable requirements and risk. Some environments may use:
- Internal security personnel
- MSSP
- MDR
- SOC
- Automated alerting with escalation
- After hours response
What matters is that the implemented process supports the organization's security obligations.
SIEM, MSSPs and outsourced monitoring
What Is a SIEM Supposed to Do?
A Security Information and Event Management platform can centralize and analyze security information from multiple sources. Typical functions can include:
- Log collection
- Normalization
- Correlation
- Search
- Alerting
- Investigation
- Dashboards
- Retention
- Reporting
A SIEM is most valuable when it supports an actual security process.
Is Having Microsoft Sentinel, Splunk, or Another SIEM Enough?
No. An unused SIEM does not prove effective monitoring. Assessors can look beyond product ownership to determine whether:
- Relevant sources are connected
- Events are being generated
- Retention is configured
- Alerts exist
- Personnel review events
- Investigations occur
- Evidence is preserved
The process matters as much as the platform.
What If We Use an MSSP?
Document the relationship clearly. Understand:
- Which systems the MSSP monitors
- Which logs it receives
- What alerts it investigates
- What it escalates
- Response times
- Who owns remediation
- How evidence is retained
- Who has administrative access
- What happens after hours
- How incidents are documented
The service agreement should align with the actual operating model.
Will an Assessor Interview Our MSP?
Potentially. The CMMC assessment methods include interviews with personnel responsible for implementing and operating relevant security requirements. If an MSP performs key functions, its personnel, documentation, and processes can become important to the assessment.
Vulnerability management and patching
What About Vulnerability Scanning?
Vulnerability management is another important source of objective evidence. Useful evidence can include:
- Scan configuration
- Scan schedule
- Asset coverage
- Findings
- Severity
- Remediation assignments
- Exceptions
- Rescan results
- Aging reports
- Tickets
- Risk decisions
A vulnerability scanner that generates reports nobody reviews is not a complete vulnerability management process.
How Often Must We Scan?
Do not invent a universal cadence without checking the applicable requirement, organizational risk process, contractual obligations, and implementation. The organization should define an appropriate frequency and be able to demonstrate that it follows the defined process.
What About Patch Management Evidence?
Useful evidence can include:
- Patch policy
- Patch schedule
- Asset coverage
- Missing patch reports
- Deployment records
- Exceptions
- Emergency patch procedures
- Remediation tickets
- Validation reports
Monitoring should help identify systems that fall outside expected patch status.
Endpoint, network and cloud telemetry
What About EDR?
Endpoint Detection and Response can provide evidence around:
- Malware detection
- Suspicious processes
- Endpoint events
- Isolation
- Investigation
- Remediation
- Agent health
- Policy enforcement
If EDR is used as a Security Protection Asset, document its role accordingly.
What About Antivirus?
Traditional antivirus can still be part of the environment, but modern endpoint security often includes broader capabilities. The key question is whether the organization meets the applicable System and Information Integrity requirements and can demonstrate the mechanisms used.
What About IDS and IPS?
Intrusion Detection and Intrusion Prevention technologies can support network threat detection and boundary protection. If deployed, useful evidence can include:
- Sensor placement
- Enabled signatures
- Alert history
- Tuning
- Investigation records
- Response workflow
- Configuration changes
Do not deploy an IDS simply to create a checkbox if nobody monitors it.
What About DNS Security?
DNS security can provide useful telemetry and threat prevention. Evidence may include:
- Malicious domain blocks
- Policy configuration
- Query logs
- Alerts
- Investigation records
Whether it is necessary depends on the organization's security architecture.
What About VPN Logs?
VPN logs can be important because remote access affects the CUI boundary. Useful evidence can include:
- Authentication
- MFA
- Source information
- Connection time
- Session duration
- Failed access
- Administrative changes
- User authorization
The organization should know who can remotely access the CUI environment.
What About Cloud Logs?
Cloud services can produce important evidence. Depending on the environment:
- Administrative events
- Authentication
- File access
- Sharing
- Configuration changes
- Security alerts
- API activity
- Data access
- Privilege changes
Cloud services should not disappear from the monitoring program simply because the infrastructure is not physically onsite.
What About Microsoft 365?
If Microsoft 365 is in the CMMC scope or provides security protection to it, relevant configuration and audit evidence should be incorporated into the monitoring and assessment strategy. The exact cloud architecture and contractual requirements matter.
What About Zoom or Other Communications Platforms?
If the communications environment is in scope, relevant administrative, authentication, recording, messaging, security, and configuration evidence may matter. This is the same scoping question that decides whether a communications platform is in scope at all. The question is not whether every phone call needs to be ingested into a SIEM. The question is what information and security events are relevant to the organization's defined CMMC environment.
Incident response evidence
What Does the Assessor Want to See for Incident Response?
Monitoring should connect to incident response. A mature evidence chain can look like: Security event → Alert → Triage → Ticket → Investigation → Containment → Remediation → Validation → Closure → Lessons learned where applicable This is far more persuasive than showing a dashboard full of red alerts with no documented action.
Do Tickets Count as Evidence?
Yes, tickets can be valuable evidence when they accurately document the process. A useful security ticket may contain:
- Detection time
- Alert source
- Asset
- User
- Severity
- Initial analysis
- Escalation
- Actions taken
- Evidence
- Resolution
- Closure time
- Responsible personnel
The ticketing system should support the actual workflow.
Can Zoho Desk Be Used to Document Security Incidents?
A ticketing platform can support incident documentation if configured appropriately. The organization should consider:
- Access control
- CUI handling
- What information is entered
- Retention
- Auditability
- Integrations
- Scope
Do not copy CUI into an out of scope ticketing system merely to document an incident.
What About Screenshots?
Screenshots can be useful supporting evidence. But screenshots have limitations. They can become stale and may show only one moment in time. Where possible, combine screenshots with:
- Configuration exports
- Logs
- Reports
- Tickets
- Policies
- Procedures
- Demonstrations
The goal is repeatable evidence.
What counts as objective evidence
Should We Build an "Evidence Binder"?
A structured evidence library can make assessment preparation much easier. Organize evidence by:
- CMMC practice
- Assessment objective
- System
- Evidence owner
- Evidence type
- Date
- Source
- Review status
Do not wait until the assessor arrives to locate evidence.
Should Evidence Be Collected Only Before the Assessment?
No. Evidence is strongest when it comes from normal operations. For example:
- Routine log reviews
- Real vulnerability reports
- Actual incident tickets
- Real change records
- Regular access reviews
- Periodic firewall reviews
A cybersecurity program should generate evidence naturally.
What Is "Objective Evidence"?
Objective evidence supports the conclusion that a requirement is implemented. It should be:
- Relevant
- Authentic
- Current enough to represent the environment
- Traceable
- Consistent with policy and procedures
- Consistent with interviews
- Consistent with technical testing
If the policy says one thing but the firewall configuration shows another, the inconsistency becomes important.
What If Our Policy Is Better Than Our Actual Configuration?
The assessment is about implementation. A beautifully written policy does not compensate for a missing technical mechanism. Policies should describe what the organization actually does.
What If the Tool Is Configured Correctly but Nobody Knows How It Works?
That can create assessment risk. The interview method exists for a reason. Personnel responsible for monitoring should understand:
- Their responsibilities
- The tools
- The alerts
- Escalation
- Retention
- Review procedures
- Incident response
Training and operational ownership matter.
What If We Outsource Everything?
Outsourcing does not eliminate the organization's responsibility to understand its CMMC environment. The organization still needs to know:
- What the provider does
- What assets are involved
- What evidence exists
- What contractual responsibilities apply
- How incidents are escalated
- How the service fits into the SSP and scope
Diagrams, segmentation and multi-site
What Should a Monitoring Architecture Diagram Show?
A useful diagram can include:
- CUI assets
- Security Protection Assets
- Network boundaries
- Firewalls
- Internet connections
- VPN
- Servers
- Endpoints
- Identity services
- Cloud services
- SIEM
- EDR
- Vulnerability management
- MSP or SOC relationships
- Logging flows
- Administrative paths
The diagram should help an assessor understand the environment.
Should Internet Circuits Appear on the Diagram?
If they are relevant to the assessment boundary and architecture, showing external connectivity can help explain the environment. For multi site organizations, document:
- Site connectivity
- Primary WAN
- Backup WAN
- VPN or SD WAN
- Cloud access
- Security boundaries
What About Network Segmentation?
Segmentation can help reduce and clarify scope. Evidence can include:
- Network diagrams
- VLAN configuration
- Firewall rules
- ACLs
- Routing
- Access restrictions
- Test results
- Change records
The organization should be able to demonstrate that the boundary exists in practice.
Is a VLAN Enough to Prove Segmentation?
No. A VLAN can be part of segmentation, but effective segmentation depends on how traffic between environments is controlled. The assessor may evaluate the actual enforcement mechanism.
What About Multi Site Organizations?
Multi site monitoring should answer:
- Which sites contain CUI assets?
- Which sites can reach the CUI environment?
- What security devices protect each site?
- Where are logs collected?
- Who monitors each site?
- How are remote circuits protected?
- What happens if security monitoring fails?
A central monitoring platform can simplify evidence when configured correctly.
What About Remote Workers?
Remote access creates additional evidence requirements around the implemented security controls. Depending on architecture:
- Managed endpoint status
- VPN
- MFA
- EDR
- Authentication logs
- Device compliance
- Remote access authorization
- Security alerts
Remote work should be explicitly included in the monitoring design.
Proving it works, and what happens when it stops
How Do We Prove That Monitoring Is Working?
Use a controlled demonstration. For example, an authorized test may generate an event such as:
- Failed authentication
- Test security alert
- Controlled policy violation
- EDR test event
- Approved firewall test
Then demonstrate: Event occurs → Log is generated → Log reaches monitoring system → Alert triggers where designed → Personnel receive it → Ticket or response process begins This is much stronger than simply showing that an agent is installed. Testing must be safe and authorized.
What Happens if Logging Stops?
The organization should know. Security monitoring can fail because of:
- Agent failure
- Storage exhaustion
- Credential expiration
- API failure
- Firewall changes
- Licensing
- Collector failure
- Network outage
Monitoring the monitoring system itself is a useful operational practice.
Should We Alert When a Security Agent Goes Offline?
That can be valuable because an offline security tool creates a visibility gap. The appropriate alerting and response process depends on the architecture.
Retention and protecting the logs themselves
What Does "Retain Audit Records" Mean?
The organization should define retention requirements and retain audit records accordingly. The Assessment Guide specifically evaluates whether retention requirements are defined and whether audit records are retained as defined. The important phrase is: as defined If your policy says logs are retained for a period, the technical configuration and actual records should support that statement.
Does CMMC Specify One Universal Log Retention Period?
Do not assume one universal period applies to every log source solely because of CMMC. Retention should be determined from the applicable requirements, contracts, policies, incident response needs, and architecture. Then implement and document it consistently.
How Should Audit Logs Be Protected?
Audit information should be protected from unauthorized access, modification, and deletion according to the applicable requirements. Useful mechanisms can include:
- Role based access
- Separate administrative privileges
- Centralized log collection
- Restricted deletion
- Immutable or protected storage where appropriate
- Backup
- Monitoring of administrative changes
Who Should Be Able to Delete Logs?
Access should be limited according to the organization's security architecture and least privilege principles. An administrator should not automatically receive unrestricted access to every security record merely because they administer another system.
How monitoring feeds the other requirement families
What Is the Relationship Between Monitoring and Change Management?
Security relevant changes should be controlled and documented. Examples include:
- Firewall rule changes
- New VPN access
- New administrators
- SIEM configuration changes
- Logging changes
- EDR exclusions
- Network segmentation changes
- New cloud integrations
Change records can become valuable assessment evidence.
What Is the Relationship Between Monitoring and Configuration Management?
Monitoring can help identify drift. For example: Approved firewall configuration versus Current firewall configuration A mature program can detect when security settings no longer match the approved baseline.
What Is the Relationship Between Monitoring and Risk Assessment?
Monitoring produces real information about the environment. That information can help identify:
- Repeated attacks
- Vulnerable systems
- Weak configurations
- Unsupported software
- Risky remote access
- Security control failures
Risk assessment should use operational evidence rather than existing only as an annual document.
What Is the Relationship Between Monitoring and Security Assessment?
Security assessment asks whether controls are implemented and effective. Monitoring provides ongoing evidence that can support that evaluation. The two should reinforce each other.
The five mistakes
What Is the Biggest CMMC Monitoring Mistake?
Buying a SIEM and assuming the requirement is solved. A tool without configuration, review, response, retention, and evidence is just software.
What Is the Second Biggest Mistake?
Collecting logs without defining what matters. Volume is not visibility.
What Is the Third Biggest Mistake?
Generating alerts without documenting what happens next. An assessor may reasonably ask: Show me what you did with this alert.
What Is the Fourth Biggest Mistake?
Keeping the monitoring provider outside the CMMC documentation. If an MSP, MSSP, SOC, or consultant provides security protection, its role needs to be understood in the assessment scope.
What Is the Fifth Biggest Mistake?
Creating evidence the week before the assessment. The strongest evidence comes from normal operations.
What to be able to show, and what to do now
What Should We Be Able to Show an Assessor?
At a practical level, be prepared to show:
What You Monitor
The relevant assets, systems, users, connections, and security events.
Why You Monitor It
The policy, requirement, risk, or security purpose.
How Monitoring Is Configured
Actual technical settings.
Where the Data Goes
Logs, SIEM, security platform, ticketing, or other systems.
Who Reviews It
Named roles and responsibilities.
What Creates an Alert
Defined detection or escalation logic.
What Happens Next
Triage, investigation, escalation, remediation, and closure.
How Long Evidence Is Retained
Defined and implemented retention.
How the Evidence Is Protected
Access and integrity controls.
How You Know It Works
Testing, demonstrations, and operational history.
What Should a Small Defense Contractor Do Right Now?
1. Confirm the CMMC Assessment Scope
Identify CUI Assets, Security Protection Assets, Contractor Risk Managed Assets, Specialized Assets, and Out of Scope Assets as applicable.
2. Build the Asset Inventory
Know what you are protecting.
3. Build the Network Diagram
Show boundaries, connections, security systems, and monitoring flows.
4. Identify Required Log Sources
Determine which systems produce security relevant events.
5. Define Auditable Events
Document what should be logged.
6. Configure Logging
Verify that the systems actually generate the expected records.
7. Centralize Where Appropriate
Use SIEM or other centralized monitoring where it supports the architecture.
8. Define Retention
Set a defensible policy and implement it.
9. Protect the Logs
Restrict access and unauthorized modification or deletion.
10. Define Alerting
Determine what events require action.
11. Connect Alerts to Tickets or Incident Response
Create a traceable workflow.
12. Review Vulnerabilities
Scan, assign, remediate, and validate.
13. Monitor Security Tool Health
Know when logging or security agents stop working.
14. Collect Evidence During Normal Operations
Do not manufacture an evidence library immediately before assessment.
15. Test the Process
Demonstrate that events are generated, detected, escalated, and handled.
16. Train the People Who Will Be Interviewed
They should understand the process they actually perform.
What Should Be in a CMMC Network Monitoring Evidence Library?
A practical evidence library can contain:
Governance
- Monitoring policy
- Audit policy
- Incident response policy
- Vulnerability management policy
- Configuration management policy
- Access control policy
Architecture
- Network diagram
- Data flow diagram
- Asset inventory
- Security Protection Asset inventory
- External service provider list
Logging
- Auditable event definition
- Logging configurations
- Sample audit records
- SIEM configuration
- Retention configuration
- Access controls
Monitoring
- Alert rules
- Alert history
- Dashboards
- Investigation records
- Security tickets
- Escalation records
Vulnerability Management
- Scan reports
- Findings
- Remediation tickets
- Exceptions
- Rescan evidence
Network Security
- Firewall configuration
- Rule reviews
- VPN configuration
- Segmentation
- IDS or IPS configuration where used
Endpoint Security
- EDR configuration
- Agent health
- Detection history
- Response records
Operations
- Change tickets
- Incident records
- Review records
- Training
- Test results
The library should map evidence to the specific CMMC assessment objectives it supports.
Evidence checklist
CMMC Level 2 Network Monitoring Evidence Checklist
Scope and Architecture
- CMMC Assessment Scope defined
- CUI Assets identified
- Security Protection Assets identified
- Contractor Risk Managed Assets identified
- Asset inventory current
- Network diagram current
- External providers documented
- Monitoring data flows documented
Audit and Logging
- Auditable events defined
- Required audit content defined
- Logging enabled
- Relevant log sources identified
- Logs generated as expected
- Retention requirements defined
- Retention technically configured
- Audit information protected
- Administrative access restricted
Network Security
- Firewall configurations documented
- Firewall logging enabled where appropriate
- Rule reviews documented
- VPN activity logged
- Network segmentation documented
- Boundary protections documented
- IDS or IPS evidence retained where used
Security Monitoring
- SIEM documented where used
- Log sources connected
- Alert rules documented
- Alert history available
- Monitoring ownership defined
- After hours process defined where applicable
- Security tool health monitored
- Failed logging or agent conditions addressed
Endpoint and System Integrity
- EDR or endpoint security documented
- Agent health reviewed
- Malware detections retained
- Vulnerability scans performed
- Findings assigned
- Remediation tracked
- Rescans or validation performed
- Patch status documented
Incident Response
- Alerts connect to a response workflow
- Security tickets retained
- Triage documented
- Investigations documented
- Escalation documented
- Remediation documented
- Closure documented
- Relevant incident evidence preserved
Assessment Readiness
- Evidence mapped to assessment objectives
- Evidence owners assigned
- Policies match actual implementation
- Personnel understand their responsibilities
- Technical mechanisms can be demonstrated
- Sample events can be traced through the workflow
- Evidence is generated during normal operations
- MSP or MSSP responsibilities documented
Frequently asked questions
What network monitoring evidence does a CMMC Level 2 assessor ask for? Depending on the requirement, evidence can include policies, procedures, SSP content, network diagrams, asset inventories, configuration settings, actual audit logs, SIEM records, alerts, incident reports, vulnerability findings, tickets, interviews, and technical demonstrations.
## Does CMMC Level 2 require a SIEM? DoD identifies SIEM solutions as examples of Security Protection Assets when used to protect the CMMC environment. The framework does not reduce compliance to purchasing one particular SIEM product.
Are SIEM systems in CMMC scope? If a SIEM provides security protection to the CMMC assessment scope, DoD's Level 2 Scoping Guide treats it as a Security Protection Asset.
## Does CMMC require audit logs? Level 2 includes Audit and Accountability requirements addressing the creation and retention of system audit logs and records needed for monitoring, analysis, investigation, and reporting of unauthorized activity.
Is enabling firewall logging enough? No. The organization should define relevant events, configure logging, retain appropriate records, protect them, review them, and connect findings to investigation and response.
## Can firewall logs be CMMC evidence? Yes, when relevant to the assessment objective and scope.
Can network uptime monitoring satisfy CMMC? Availability monitoring can provide useful operational evidence but should not be represented as a substitute for the broader security logging, detection, vulnerability management, incident response, and protection required by CMMC.
## Can ping and traceroute satisfy CMMC monitoring requirements? Not by themselves. They are useful operational diagnostic tools but do not provide the full security visibility needed for CMMC Level 2.
Does an assessor only review documents? No. CMMC Level 2 assessment methods include examination, interviews, and testing.
## Can an assessor ask us to demonstrate that logging works? Yes. Testing mechanisms implementing a requirement is part of the assessment methodology.
Do vulnerability scans matter? Yes. In 800-171 Revision 2 the relevant family is Risk Assessment, not System and Information Integrity: scanning is RA.L2-3.11.2 and remediation is RA.L2-3.11.3. Scan configuration, coverage, findings, remediation records and rescan results are evidence against those.
## Do incident tickets matter? Yes. Tickets can demonstrate that alerts lead to triage, investigation, escalation, remediation, and closure.
Does our MSP matter to CMMC scope? Potentially. DoD's Level 2 Scoping Guide identifies MSP personnel implementing system maintenance among examples associated with Security Protection Assets.
## Should we collect evidence only before our assessment? No. Strong evidence should be generated through normal cybersecurity operations.
How long should we retain logs? The organization should define retention requirements based on applicable requirements, contracts, policies, incident response needs, and architecture, then demonstrate that records are retained according to that definition.
## Can ADAM Pulse replace a SIEM? No. ADAM can support network visibility, availability monitoring, alerting, historical network evidence, and operational documentation. A SIEM and other security technologies address different cybersecurity functions.
Related articles
- CMMC for the small defense supplier: what did the 48 CFR rule change? — why any of this affects whether you can win the work.
- Zoom, Zoom for Government and CMMC — whether your communications platform is inside the assessment scope.
- Firewall monitoring: what to watch — the operational version of the firewall evidence discussed here.
- Network baseline monitoring — knowing what normal looks like, which is what makes an alert meaningful.
References
The rule, the standards it incorporates, and DoD's own guides. Where this article names a control identifier or a document revision, it is because the vague version sends readers to the wrong document.
- eCFR — 32 CFR part 170, Cybersecurity Maturity Model Certification (CMMC) Program— § 170.14(c) requires Level 2 to use NIST SP 800-171 R2; § 170.11(a) requires assessments to follow NIST SP 800-171A Jun2018. Both are incorporated by reference under § 170.2.
- NIST — SP 800-171 Revision 2 (withdrawn 14 May 2024)— the standard CMMC Level 2 is assessed against. NIST withdrew it in favour of Revision 3, which CMMC does not use.
- NIST — SP 800-171A, June 2018 (withdrawn 14 May 2024)— the assessment procedures, including the examine / interview / test methods and the potential-evidence lists an assessor works from.
- DoD CIO — CMMC Assessment and Scoping Guides— the Level 2 Assessment Guide and Level 2 Scoping Guide, including the treatment of Security Protection Assets.
- Acquisition.gov — DFARS 252.204-7012, Safeguarding Covered Defense Information and Cyber Incident Reporting— the underlying safeguarding and incident reporting obligation that most of this evidence also serves.
- Acquisition.gov — DFARS 252.204-7019 and 252.204-7020, NIST SP 800-171 DoD Assessment Requirements— the self-assessment and SPRS posting requirements that sit alongside CMMC.
- Federal Register — Cybersecurity Maturity Model Certification (CMMC) Program— 89 FR 83092, published 15 October 2024, effective 16 December 2024.
Managed network monitoring and NOC services, SDVOSB. We build the monitoring evidence trail a Level 2 assessment asks for — circuit and device inventory, network and monitoring architecture diagrams, availability and performance data with real retention, and alert-to-ticket records that show someone acted. CAGE 9QJS2 · UEI NJ7FKBV9X6L1. Support: (888) 989-4872 · support@adampulse.us