Current: Phase II suspended July 13, 2026. Phase I self-assessment requirements remain.Read the update →
SYSTEM MONITORING

CMMC System Monitoring and Security Alerts: What 3.14.6–3.14.7 Actually Require

CMMC 3.14.6–3.14.7 require monitoring for attacks and indicators of attack, plus a working process to identify and investigate unauthorized system use.

Papercraft radar monitor with an alert bell connected to a magnifying glass investigating a flagged event, illustrating system monitoring and security alert investigation.

Requirements 3.14.6 and 3.14.7 are the monitoring end of system integrity: watch systems and communications for attacks or indicators of attack, and identify unauthorized use.

The working question for a small business under CMMC is concrete: within the defined FCI/CUI boundary, who is responsible for this requirement, and what evidence today shows it is functioning as intended?

The rule in plain English

The control does not say every small contractor must own a giant SIEM. It does require enough monitoring across relevant systems and traffic to detect the events the organization says it can detect.

Alerts also need ownership, review, escalation, and records. A sensor nobody checks is weak evidence of an implemented process.

How to implement it without overbuilding

Start with identity, endpoints, firewalls or gateways, remote access, and critical CUI applications. Define a small set of meaningful alert categories and who receives them.

If an MSP/MSSP monitors alerts, document the handoff, customer visibility, severity definitions, response expectations, and evidence retention.

What evidence to keep

Keep alert rules, enabled data sources, sample alerts, investigation tickets, escalation records, and periodic review reports.

Use one recent alert to demonstrate the full chain from detection through review and closure.

Where teams get into trouble

A frequent failure is collecting logs without monitoring them. Another is outsourcing monitoring while the contractor cannot show what the provider watches or how incidents reach the contractor.

Small-contractor walkthrough

A firewall, identity platform, endpoint tool, and Microsoft 365 all generate alerts, but only the endpoint alerts create tickets. The monitoring design should say which signals matter, who reviews each source, and how suspicious activity becomes an investigation record.

  • List monitored sources.
  • Define alert ownership.
  • Tune high-value detections.
  • Document provider handoffs.

Decisions to document before assessment

Before marking this topic ready, make four decisions explicit: list monitored sources; define alert ownership; tune high-value detections; and document provider handoffs. Assign an owner and an evidence location to each decision.

Manual deep review: cover system, inbound, outbound, and unauthorized-use detection

A firewall watching incoming internet traffic is not the whole requirement. 3.14.6 asks the contractor to monitor organizational systems for attacks and indicators of potential attacks, including inbound and outbound communications traffic. Host behavior, authentication activity, network traffic, and cloud-service events may each contribute depending on the architecture. Outbound visibility deserves explicit attention because compromised systems can reveal themselves through command-and-control traffic, unusual destinations, large transfers, or other outbound behavior.

3.14.7 adds the need to identify unauthorized use. That can include an unauthorized identity, misuse of a valid account, activity from an unapproved device or location, or actions outside the permissions the organization intended. Identity alerts, endpoint detections, administrative logs, remote-access logs, application activity, and network monitoring can all contribute. The requirement does not force every small contractor to buy a large SIEM, but the monitoring design must have credible coverage and a human or provider review process.

Create a monitoring-source matrix with source, assets covered, important event categories, alert destination, reviewer, escalation path, and evidence retained. This immediately exposes the dashboard-nobody-checks problem. A firewall, EDR platform, VPN, identity system, and Microsoft 365 or another SaaS platform may all produce useful security signals while only one currently creates a ticket.

If an MSSP performs monitoring, document the sources it ingests, detections enabled, severity model, notification method, investigation responsibilities, and evidence the contractor can retrieve. Before assessment, choose one alert and show the entire chain from originating telemetry through review, investigation, disposition, and any follow-up action. Then pick one CUI system and confirm there is a defensible visibility path for host, inbound, outbound, identity, and remote-access activity.

  • System/host monitoring source.
  • Inbound and outbound traffic monitoring.
  • Unauthorized-use detection source.
  • Named reviewer or MSSP responsibility.
  • Investigation and closure evidence.

Manual assessment cross-check

Choose one important CUI system and trace host, inbound, outbound, identity, and remote-access visibility to a human or provider review workflow.

Use CMMC System Monitoring and Security Alerts: What 3.14.6–3.14.7 Actually Require as an operating guide, not as a substitute for the controlling source. Before publication or assessment use, re-open the current NIST SP 800-171 Rev. 2 requirement, the corresponding NIST SP 800-171A assessment objectives, and the DoD CMMC Level 2 Assessment Guide. Confirm that every mandatory statement on the page maps to those sources or to a clearly labeled organizational implementation choice.

Additional objective-level implementation notes

The monitoring design should answer three questions: what is watched, who watches it, and what happens next. For 3.14.6, explicitly map system, inbound, and outbound visibility. If outbound monitoring relies on a firewall, DNS service, proxy, EDR telemetry, or MSSP platform, document which CUI systems and paths are actually covered rather than assuming the perimeter sees everything.

For 3.14.7, identify detections that reveal unauthorized use and connect them to a review process. A technically good alert that no one receives is weak evidence. If an MSSP performs first-line review, define what it escalates, how the contractor receives the case, and where investigation records are retained. Use the organization's documented retention needs rather than inventing a universal number.

Final manual spot check

For a final spot check, choose one representative CUI system and trace which monitoring source covers host activity, inbound communications, outbound communications, identity activity, and remote access. Then choose one recent alert and reconstruct the review from the originating signal through analyst or administrator action, disposition, and closure. If an MSSP participates, the contractor should be able to retrieve the same evidence without asking the provider to create a special report solely for assessment.

WORKING CHECKLIST

A short working check

  • List monitored sources.
  • Define alert ownership.
  • Tune high-value detections.
  • Document provider handoffs.
  • Retain investigation evidence.
  • Test alert escalation.

Common questions

Is a SIEM required?

No specific SIEM product is mandated, but the monitoring outcome still has to be achieved and evidenced.

Can an MSSP satisfy this for us?

An MSSP can perform parts of the work, but the contractor remains responsible for implementation and evidence.

What is unauthorized use?

It can include activity by unauthorized identities, misuse of valid accounts, or use outside approved functions depending on the system.

How much alert history should we keep?

Retention should support the organization's documented monitoring, incident, and assessment needs rather than a made-up universal number.

Does CMMC require a 24/7 SOC for 3.14.6 and 3.14.7?

The requirements do not state a universal 24/7 SOC mandate; the monitoring and response design must still be effective and demonstrable.

Official sources used for this guide

Open the primary source before making a contract-specific decision. Regulations and program implementation can change.