03.14.06 System monitoring: requirements and evidence

What NIST SP 800-171 system monitoring requires in plain terms

03.14.06 requires you to monitor your systems well enough to detect attacks, indicators of potential attacks, unauthorized connections and unauthorized use, including the inbound and outbound communications traffic that carries them. In Rev. 3, NIST folded the Rev. 2 requirement 3.14.7 into this one, so the monitoring obligation that once sat in its own requirement now sits here. The Rev. 2 requirement it traces to, 3.14.6, is still the one assessed under CMMC Level 2, where it appears as SI.L2-3.14.6 and carries 5 points under the scoring methodology in 32 CFR 170.24. A contractor that cannot show monitoring in place cannot place this requirement on a plan of action and milestones and still claim Conditional status, because 32 CFR 170.21 does not allow it. Confirm which revision your contract cites before you plan the work, since the DoD guidance on Rev. 2 and Rev. 3 is changing.

The hard part is rarely buying a tool. Monitoring only works if logs arrive from the right places: authentication events from directory services, administrative actions on servers, endpoint detections, firewall and boundary device logs, and cloud control plane activity for any system that handles CUI. Your system security plan should name each source, what it records and where it is stored. Assessors using the SP 800-171A examine and interview methods will ask who installs, configures and maintains these sources and who reviews what they produce, so the answers need to be written down and tied to named roles.

Someone must also act on the output. An alert queue nobody reviews does not show that unauthorized use is being detected. Before an assessment, confirm three things with your own environment: which sources feed monitoring for systems in CUI scope, who triages alerts and how quickly they are expected to do so under your own procedures, and how monitoring results connect to your incident response process and to the audit records your organization keeps under 03.03. The organization owns these decisions. An implementation partner can help build the sources and dashboards, and an independent assessor will test whether they work.

Which systems, traffic and teams 03.14.06 covers

Scoping decides how much monitoring 03.14.06 demands in practice. The requirement reaches every system that handles CUI, the boundary where that CUI enters and leaves, and the people or providers who watch those systems, so each card below names one scoping decision to settle before choosing tools.

CUI systems and enclave boundaries

Start by listing every system that stores, processes or transmits CUI, then draw the boundary around them. Monitoring that stops at the enclave edge misses lateral movement from a non-CUI system into the enclave, and monitoring that covers the whole network is costly to run. Confirm with the contracting agency or your system security plan which systems are in scope, and record the boundary so an assessor can trace each monitored asset back to it.

Endpoints and servers

Workstations, laptops, servers and virtual machines are the most common places where an attack first shows up. Confirm that each in-scope host forwards security-relevant logs such as authentication events, process starts and privilege changes to a central collector, and that the collector receives them even when a device is offline for a period. Ask which hosts are excluded and why, since an assessor will expect exclusions to match your documented scope.

Network devices and cloud services

Firewalls, routers, switches, VPN gateways and cloud control planes generate the records that show unauthorized connections and unusual administrative activity. Cloud audit logs in particular are often disabled by default or kept only briefly, so check that they are enabled, retained and forwarded for every account that touches CUI. Document which device and cloud log sources feed monitoring and who reviews each one.

The perimeter where CUI traffic crosses

Monitoring of inbound and outbound communications is most useful where CUI traffic leaves or enters the boundary, such as internet egress, remote access gateways, email gateways and file transfer services. Identify those crossing points on a diagram and decide which signals to watch at each one, such as unexpected destinations, large outbound transfers or connections from unapproved countries or services. Confirm that sensors at these points see traffic before any encryption terminates, or document where they do not.

Third-party managed monitoring

Many organizations hand the monitoring tools to a managed security service provider or a managed detection and response firm. The provider can run the sensors and the alert queue, but the organization still owns the obligation under 03.14.06 and must show that monitoring operates. Ask the provider for its log sources, alert triage process, escalation times and evidence exports, and confirm in the contract that you can obtain them during an assessment.

Who owns the monitoring duty

Monitoring fails most often in the gap between operations, security and the managed provider, where each party assumes another is reviewing the alerts. Name one accountable owner for 03.14.06, list who installs and maintains the tools, and list who reviews and acts on alerts, including after hours. Assessors interview these people, so their roles must match what the documentation says they do.

How an assessor tests system monitoring under SP 800-171A

This table maps the three SP 800-171A Rev. 3 assessment methods (examine, interview and test) to the objects an assessor uses for 03.14.06 and the evidence each one typically requests. Read each row as a question the assessor will ask, then check that your monitoring program can answer it with dated records. The main takeaway is that a detection tool that is installed but never tested or reviewed will not satisfy this requirement.

Assessment method	Objects the assessor examines or questions	Evidence to prepare	Common finding
Examine: monitoring policy and procedures	System and information integrity policy and procedures, and the procedures for system monitoring tools and techniques	Approved monitoring procedure naming the tools, log sources, alert triage steps and escalation path, with version and approval date	Procedure exists but describes a tool that was replaced, or does not match the configured detectors
Examine: continuous monitoring strategy	Continuous monitoring strategy covering what is watched, how often, and by whom	Written strategy that lists in-scope CUI systems, boundary sensors, host and cloud log sources, and review cadence	Strategy is generic and does not cover cloud services or remote endpoints that handle CUI
Interview: personnel who install, configure or maintain the system	Administrators responsible for deploying and tuning monitoring components	Walkthrough of how a new log source is onboarded, how rules are changed, and how monitoring health is checked	Staff cannot explain how a silent sensor would be detected
Interview: personnel with monitoring responsibilities	Analysts who triage alerts and decide whether to escalate	Explanation of triage steps, handoff to incident response, and examples of closed alerts with rationale (illustrative)	Analysts describe alerts from memory, with no record of how they were closed
Test: intrusion detection and system monitoring processes	Intrusion detection and monitoring processes, including detection rules, correlation and alert delivery	Test results showing that a known benign test event produces an alert, that alerts reach a reviewed channel, and that inbound and outbound traffic is covered	Detection rules were never tested, or alerts go to a mailbox that nobody reviews
Test: outbound and inbound traffic coverage	Boundary sensors and host telemetry that record traffic entering and leaving the CUI environment	Sensor placement diagram, configured log output, and proof that unusual outbound connections are logged and reviewed	Monitoring covers inbound traffic only, leaving unauthorized outbound connections unseen
Test: unauthorized use and connections	Monitoring of unauthorized connections and unauthorized use of the system	Sample of alerts or findings for unauthorized logins or devices, with ticket numbers showing investigation	Findings exist, but no ticket shows that they were investigated or closed

How to implement system monitoring in the order that passes assessment

This sequence moves from defining what gets watched to proving that detections fire and that someone acts on them. Each step closes with an artifact an assessor can examine, interview against and test.

Define monitored assets and traffic boundaries
The system owner and security lead list every asset in the CUI boundary, including endpoints, servers, cloud workloads, network devices and identity services, and mark where inbound and outbound traffic crosses the boundary. This comes from the system inventory and network diagrams already maintained for the configuration management and boundary protection work. The step is done when the asset list and boundary diagram match each other and the system security plan. The assessor will ask to see both and will check that no in-scope asset is missing.
Set monitoring objectives in the system security plan
Write the monitoring objectives for 03.14.06 into the system security plan: which attacks and indicators you detect, which unauthorized connections and unauthorized use you look for, and which inbound and outbound traffic patterns you review. Assign values to any organization-defined parameters in the requirement, since a nonfederal organization must set them when the federal agency does not. Confirm the parameter values with your contracting agency. The output is a monitoring section in the plan that an assessor can compare line by line against the requirement.
Deploy log collection and detection rules
Engineers connect log sources from hosts, network devices and cloud services to a collector, then enable detection content. Wazuh can decode logs and match them against built-in and custom rules, OpenSearch Security Analytics can run detectors built on Sigma rules, and OPNsense can run Suricata with a chosen ruleset and export EVE JSON to syslog. Confirm each platform's current capabilities and supported log types in your environment before you commit to a design. The output is a source inventory and a rule inventory that show what is collected and what each rule detects.
Route alerts to a named reviewer
Configure each detection platform to send alerts to a defined queue, such as a monitored mailbox, ticketing system or chat channel, and name the people who review it. Record the reviewer and backup for each alert source in the monitoring procedure. Keep alert retention and access aligned with the audit logging requirements so the alert trail survives review. The output is a routing configuration export and a roster that an assessor can match against the people they interview.
Write review and escalation procedures
Write the procedure that tells reviewers how to triage alerts, which findings become incidents, how to hand them to the incident response process, and who is notified at each level. Tie escalation to the incident response plan so that a monitoring alert can start incident handling without a second approval step. Train reviewers on the procedure and keep the training record. The output is a signed or version-controlled procedure, a sample of triage records and an escalation path that the assessor can walk through with the staff involved.
Test detections with known-bad activity
Run controlled tests that generate activity the rules should flag, such as a simulated port scan, a test malware file, or a login from an unexpected source, in an approved test window. Confirm that each test produces an alert, that the alert reaches the named reviewer and that the reviewer records a disposition. Fix any rule that stays silent and retest. The output is a test log with the test case, the expected alert, the observed alert and the reviewer's action. An assessor who tests this requirement will look for exactly this evidence.
Keep monitoring evidence current
After go-live, the monitoring owner reviews rule changes, new log sources and alert volumes on a schedule set in the procedure, and records each change through the configuration change process. Repeat the known-bad tests after significant changes to rules or sources. Ask your assessor or outside consultant which evidence they expect to see over time, since the requirement is assessed on what the system does, not only on the day the setup is complete. The output is a dated change history and repeat test results.

Which evidence shows that system monitoring is working

An assessor testing 03.14.06 checks whether monitoring is documented, scoped, tuned and actually reviewed, not just switched on. The six artifacts below connect the written strategy to the detections, alerts and human review that show the strategy runs. Each one goes stale unless someone owns a routine that refreshes it between assessments.

Monitoring procedures and strategy

The written procedures for system monitoring tools and techniques, together with the continuous monitoring strategy, are the first thing an assessor examines. They should name what is monitored, which tools cover which sources, who responds, and how often the strategy is reviewed. Check that the document matches the tools actually deployed, not an earlier design. Review it on a fixed schedule and after any change to monitored boundaries or tooling, and record each review with a date and approver.

Asset and log source inventories

Monitoring only detects what it can see. The inventory should list every host, network device, cloud service and application that sends logs or traffic to the monitoring stack, with the log types each one produces. Compare it against the system security plan boundary and flag any system that handles CUI but sends nothing. Reconcile the inventory against asset discovery output at regular intervals, and record when a source was added, changed or lost.

Detection rule sets with change records

Detection content, such as Sigma rules in OpenSearch Security Analytics, Wazuh rules and custom rules, and Suricata rulesets on OPNsense, determines what gets flagged. Keep the active rule list, the source of each rule, and a change log showing who approved each addition, tuning change or disablement and why. An unexplained disabled rule is a common finding. Confirm that rule updates from upstream feeds are tested before they reach production.

Sample alert records with disposition notes

Assessors ask for real alerts and what happened to them. Pull a sample across different sources and severities, and for each one record the alert, the analyst's disposition (false positive, benign, escalated, or incident), and the follow-up action. Alerts such as those written to Wazuh alerts.json or Suricata EVE JSON output should be traceable from the detection to the ticket. Keep a rolling sample so the evidence reflects current operation rather than one selected week.

Test detections for monitoring coverage

Evidence of test detections shows that the monitoring chain works end to end. Run controlled, documented tests such as a simulated unauthorized login, a known-bad test string in a non-production host, or outbound traffic to a test destination, and show that the event was collected, matched and alerted. Record the test plan, the expected result, the observed result and any gap. Schedule these tests so each one is repeated after a rule, source or platform change.

Review logs for alert handling

Review logs show who looked at alerts, when, and what they concluded. They support the interview method, because personnel with system monitoring responsibilities will be asked to explain their routine. Keep shift or queue records, acknowledgment timestamps and handoff notes, and check for alerts that sat unreviewed. Confirm that reviewers are named in the responsibilities list and that their coverage holds during absences, since gaps in these records are often what assessors notice first.

What meeting 03.14.06 costs in money and effort

This table breaks down the cost components of building and running system monitoring for 03.14.06, showing who is paid, whether each cost is one-time or recurring, and what drives it up. Use it to shape a quote request, since most of the spend sits in people and log storage rather than software licenses. No prices are given because none are supplied, so the figures to ask for are listed in the last column.

Cost component	Who is paid, one-time or recurring	What drives it	What to request in a quote
Monitoring platform licenses	Open-source options carry no license fee; recurring only if a commercial tier or subscription is chosen	Choice of platform and whether paid add-ons or support tiers are needed	Confirm the license model for each component and any paid features the design depends on
Platform support and hardware	Recurring hardware or cloud compute, plus optional support contracts	Number of sensors, indexer nodes and retention period	Itemized compute, storage and support costs with the assumptions behind them
Engineering to deploy and tune detections	One-time implementation effort by the implementation partner or internal team	Number of monitored sources, custom rule count and network segmentation	Fixed-scope deliverables listing sources onboarded, rules written and tuning cycles
Analyst time to review alerts	Recurring internal or outsourced staff time	Alert volume, false positive rate and whether alerts route to a 24/7 function	Alert triage workflow, escalation paths and the staffing model assumed
Log storage and retention	Recurring storage for inbound, outbound and host logs	Log volume per day, retention period and indexing overhead	Estimated daily log volume, retention settings and storage growth projections
External testing	One-time or periodic fees to an outside tester for detection validation	Scope of attack simulation and number of test cycles	Test scope, rules of engagement and what evidence the report will contain
Assessor sampling effort	Assessor time billed by the independent assessor, not the implementation partner	Number of systems, sampled alerts and interviews required	Sampling approach, the evidence list requested and whether monitoring records are sampled by period

Which open-source tools produce monitoring evidence

Monitoring evidence for 03.14.06 comes from the tools that collect events, match them against rules and keep the results. The four tools below cover log-based detection, host and endpoint rule matching, network intrusion detection and a structured network record, and each one leaves different artifacts for an assessor to examine.

OpenSearch Security Analytics

Security Analytics runs detectors that match ingested logs from hosts, network devices and cloud services against prepackaged or custom Sigma rules. Each match is recorded as a finding with its rule, log type and severity, alerts go to channels such as Slack or email, and the correlation engine links findings across log types in a correlation graph. The license is Apache-2.0. Confirm that your log sources, rule set and alert channels meet your own monitoring design before you rely on it as the evidence source.

Wazuh alerts and rule matching

Wazuh decodes collected logs and compares each event against a ruleset of over 3,000 built-in rules and decoders, plus any custom rules you write. Matching alerts are written to alerts.log and alerts.json, mapped to MITRE ATT&CK and forwarded to the Wazuh indexer for review in the dashboard. The license is GPL-2.0-only, so confirm with counsel how that license applies if you modify or distribute the software. Check that your decoders cover your actual log sources.

OPNsense intrusion detection with Suricata

OPNsense includes an intrusion detection and prevention system built on Suricata, running rulesets such as Emerging Threats and Abuse.ch. It can alert on or block matching traffic and send alerts to syslog in EVE JSON format. OPNsense is licensed BSD-2-Clause and Suricata is GPL-2.0-only. Confirm which rulesets are enabled, whether the policy is alert-only or blocking, and that the firewall sits at the boundary points where you need inbound and outbound visibility.

Suricata EVE JSON records

Suricata's EVE output writes JSON records for rule match alerts, anomalies, flows, and protocol transactions such as HTTP, DNS, TLS, SSH and SMB, along with file information, dropped packets and engine statistics. The output can be split into separate files for log management tools, which lets flow and protocol records be retained apart from alerts. Suricata is GPL-2.0-only. Confirm which record types you enable and how long your log platform keeps them, since flow records can be large.

Who owns system monitoring, who can help, and where the auditor stops

Your organization owns the system monitoring obligation under 03.14.06. That means you decide what the system must detect, who reviews the alerts, how quickly suspicious activity is escalated, and which incidents are declared. An outside partner can build the tooling, but the monitoring program remains yours, and your assessor will ask staff to explain it in their own words.

Monitoring scope: Define which systems, accounts, network boundaries and cloud services are monitored, and document the rationale in the system security plan.
Alert ownership: Name the people or on-call roles who review detections, with coverage for nights, weekends and absences.
Escalation decisions: Decide when an alert becomes an incident, who can authorize containment, and how that ties into your incident response plan.
Tuning approval: Approve changes to detection rules so that suppressions and exclusions are documented and reviewed, not quietly added.
Operating records: Keep review logs, ticket histories and metrics that show monitoring happens every day, not only at deployment.

Check that each monitoring role has a named person, a backup, and written procedures that match what staff actually do.

Where organizations fall short on system monitoring and how to close it

Most organizations under 03.14.06 System monitoring already collect logs and run a tool, so assessors usually find the gaps in what happens after collection. The cards below cover where monitoring stops short of detecting attacks and proving that someone acted on what it found.

Logs collected with no reviewer

A SIEM or alert dashboard that fills up with events but has no named owner, shift or review cadence does not detect anything. Assessors look for personnel with monitoring responsibilities, interviewed to confirm they know what they watch and when. Close the gap by assigning a named role and a documented review schedule, then checking that alerts reach that person through a channel they actually read. Wazuh writes matching alerts to alerts.log and alerts.json and forwards them to the indexer for dashboard review, so confirm which of those paths your reviewers use.

Detection rules never tested

Detection content that was installed once and never exercised may not fire on the activity it was written for. Assessors using the test method look for processes that show intrusion detection and system monitoring actually work. Build a small set of test events, such as a failed-login burst or a known-bad domain lookup in a lab, and record whether each rule raised an alert. Re-run the tests after rule updates, and keep the results as evidence that detection was verified rather than assumed.

Outbound traffic left unmonitored

Many monitoring programs watch inbound attacks and miss data leaving the environment. The requirement covers monitoring both inbound and outbound communications traffic for unusual or unauthorized activity, so an egress blind spot is a direct finding. Confirm that the perimeter IDS or firewall logs outbound sessions, not just blocked inbound probes. OPNsense runs Suricata for its IPS and can send EVE JSON alerts to syslog, so check whether outbound rule matches and flow records reach your collector.

Cloud services outside collection scope

Cloud identity, storage and SaaS audit logs are often enabled by the cloud team but never forwarded to the monitoring platform. An assessor who asks whether unauthorized use of CUI-bearing services would be visible may find the answer is no. Inventory every system in the system security plan boundary, including managed cloud services, and map each to its log source and collector. Document any service where logs cannot be exported, so the gap is recorded and handled rather than hidden.

No records of review or disposition

Monitoring produces alerts, but without records showing who reviewed each one and what was decided, there is no evidence the activity was monitored. Auditors want to see a trail from alert to disposition, such as dismissed as benign with a reason, escalated to incident response, or tuned into a rule change. Configure the case or ticket workflow in your platform so that every alert above a set severity has an owner, a status and a closing note. OpenSearch Security Analytics records matches as findings, which gives you a starting point for that trail.

Procedures that do not match running tools

A monitoring procedure written when the environment was first documented can describe tools, log sources or alert paths that have since changed. Assessors interview personnel and compare the written procedure with what the system does, so any mismatch undermines the rest of the evidence. Review the procedure against the live configuration at least once a review cycle, and update it whenever a collector, detector or notification channel changes. Record the date of each review so the document can be shown as current.

How long, how much effort and how much help does 03.14.06 need?

Does 03.14.06 differ from Rev. 2 requirements 3.14.6 and 3.14.7?

Yes, in structure but not in intent. NIST's Rev. 2 to Rev. 3 change analysis traces 03.14.06 to Rev. 2 requirement 3.14.6 and classifies that change as minor. Rev. 3 withdrew 03.14.07 (Rev. 2 3.14.7) and folded it into 03.14.06, so the monitoring expectations of both older requirements now sit in one requirement. Organizations that already meet 3.14.6 should check that their monitoring also covers the Rev. 2 3.14.7 scope, which is the part most likely to have a gap. CMMC Level 2 still uses Rev. 2, so for defense contracts the Rev. 2 numbering and scoring still apply. Confirm which version your contract names before you map your evidence.

What drives the effort to meet 03.14.06?

The effort depends mostly on how many log sources and network boundaries are in scope and how much monitoring already exists. The main work items are:

Inventorying hosts, network devices and cloud services that must send logs to a central point.
Defining what counts as an attack indicator, unauthorized connection or unusual traffic for your environment, and documenting it.
Deploying and tuning detection content so alerts are reviewed and acted on, not only generated.
Writing the procedures and continuous monitoring strategy that assessors will examine.

Each source added to scope increases the work, and a flat network with few boundaries is simpler to cover than a segmented one with many egress points.

How long does deployment and evidence preparation take?

No supplied source gives a duration for implementing 03.14.06, so treat any timeline as something to agree in writing. The schedule depends on the size of the environment, whether a monitoring stack already exists, and how long it takes to tune detections until alerts are useful. Evidence preparation is usually a separate track: collecting policies, procedures, alert samples and review records over a period that shows the monitoring operates. Ask any implementation partner to state the phases, the deliverables for each phase and what the client must provide before work starts. Fixed-scope engagements, where scope and timelines are agreed in writing before work begins, make these dependencies easier to see.

Can an internal team meet 03.14.06 without outside help?

Yes, if the team has security monitoring skills and the time to run the work. Internal teams often already operate a log platform or intrusion detection sensor, so the gap may be documentation, scope coverage and evidence. Outside help is most useful when the team lacks experience tuning detections, when the environment spans many systems, or when the organization needs an independent view of readiness before an assessment. Remember that an implementation partner prepares systems and evidence, while the organization owns its controls and an independent assessor or certification body issues any report. Ask a partner to state in writing which parts they will build and which parts stay with your staff.

What does the work need from our staff?

Monitoring cannot be handed off entirely, so the organization needs named owners in several roles:

Administrators who can install and configure log forwarding and sensors.
Analysts who review alerts and record what was done with each one.
A policy owner who approves the system and information integrity procedures and the continuous monitoring strategy.
Network staff who can confirm which inbound and outbound paths exist.

Plan for these people to spend recurring time after go-live, since monitoring that is not reviewed does not meet the requirement in practice.

What will an assessor ask for to test 03.14.06?

An assessor using SP 800-171A Rev. 3 checks six determination statements for 03.14.06 with examine, interview and test methods. In practice they will ask for the system and information integrity policy and procedures, the procedures for monitoring tools and techniques, and the continuous monitoring strategy. They will interview staff who install, configure and maintain the system and staff with monitoring responsibilities. They will test intrusion detection and system monitoring processes, which usually means showing sample alerts, their review records and evidence that traffic is monitored in both directions. Prepare these artifacts before the assessment rather than during it. Confirm the assessment method and scope with your contracting agency and your assessor.

Which costs are one-time and which recur for 03.14.06?

One-time costs include scoping, deploying log collection and detection tooling, tuning rules and writing procedures. Recurring costs include staff time to review alerts, maintain detection content, keep log sources connected and refresh evidence for each assessment cycle. Hosting, storage and licensing costs depend on your chosen tooling and data volume. No supplied source gives figures for these, so ask any quote to separate one-time implementation from recurring operation, and to state what it assumes about log volume, number of sources and hours of review. Open-source components such as those named on this page remove license fees, but not the labor to run them.

How DeployOpen works on this

DeployOpen plans, implements and documents self-hosted open-source monitoring for 03.14.06 System monitoring inside your own infrastructure. We prepare the detection, logging and evidence; your organization owns the requirement, and only an independent assessor can issue a conclusion on it.

How we scope

Confirm which systems, network boundaries and CUI environments the monitoring must cover for 03.14.06.
Agree in writing which detection tools, log sources and alert channels are in scope before work starts.
Define which ODP values your organization or contracting agency sets for monitoring and retention, and record who approved them.

How we build

Deploy log collection from hosts, network devices and cloud services into the chosen platform, such as Wazuh or OpenSearch Security Analytics.
Configure network traffic inspection with Suricata, including EVE JSON output for alerts, flows and protocol transactions.
Tune detection rules, including Sigma or Wazuh custom rules, and test that alerts fire for simulated unauthorized connections.

How we hand over

Document monitoring procedures, tool configurations and continuous monitoring strategy in a form an assessor can examine.
Provide alert records, rule inventories and test results that show monitoring operating for the interview and test methods.
Walk responsible personnel through alert review and escalation so the interview determinations can be answered accurately.

How we support

Scope ongoing tuning, rule updates and platform upgrades under a retainer if your organization wants continued support.
Run security testing against the monitored environment to check that detections still catch realistic attack paths.
Confirm with your assessor and contracting authority which evidence they accept before final handover.