CA.L2-3.12.3 Security control monitoring: evidence and audit

What CA.L2-3.12.3 security control monitoring requires in CMMC Level 2

CA.L2-3.12.3 is a 5-point requirement that must be MET, not placed on a plan of action and milestones. Under the CMMC Scoring Methodology in 32 CFR 170.24, a NOT MET result subtracts 5 points from the maximum score of 110. Because the point value is above 1, 32 CFR 170.21(a)(2) does not allow it on a POA&M, so a contractor cannot reach Conditional or Final Level 2 status while it is open. The requirement asks the organization to monitor its security controls on an ongoing basis so that they remain effective. NIST SP 800-171A gives it one assessment objective: controls are monitored on an ongoing basis to ensure their continued effectiveness. The assessor is checking whether monitoring is a running practice, not whether the controls were reviewed once.

The requirement recurs more often than the periodic assessment in CA.L2-3.12.1. The CMMC Assessment Guide for Level 2 says monitoring should inform management decisions on acceptable risk, so the output of monitoring is a set of signals that leadership reviews and acts on: a control that has drifted, a failed check, a new exposure, or a change that affects a security decision. The usual difficulty is proving that monitoring happened over time. A single dashboard screenshot or a one-off review meeting will not show continuity. Assessors look for evidence that monitoring was defined, performed on a schedule, produced results, and led to recorded follow-up. Before the assessment, confirm with your C3PAO or your own assessment lead which monitoring records they will request, and how far back they expect those records to go.

Start by writing down what is monitored, how often, by whom, and what counts as a failure, and tie each item to the controls in your system security plan. Then keep the outputs. Tools such as Wazuh, OpenSearch Security Analytics and Fleet can produce recurring evidence: Fleet policies show which devices pass or fail each yes or no check, Wazuh writes matching alerts to alerts.log and alerts.json, and OpenSearch records rule matches as findings. Export and retain those records on a schedule so that a gap in monitoring is visible rather than assumed. Review the results in a documented management meeting and record the decisions taken. Those decisions are what connect monitoring to the acceptable-risk judgment the requirement describes. Confirm with your platform team that each tool's retention settings meet the period your assessor expects.

Which systems, teams and providers fall under control monitoring

Control monitoring under CA.L2-3.12.3 applies wherever CUI is processed, stored or transmitted, plus the tooling and people that watch those systems. The cards below separate the assessment boundary, the monitoring stack, the review roles and the external providers whose output the organization depends on.

CUI systems inside the assessment boundary

Every system that processes, stores or transmits CUI sits inside the assessment boundary, and each one needs ongoing monitoring of its security controls. Start from the data flow diagram, not the asset list, because email, collaboration tools, file shares and build servers often carry CUI without being labeled as such. Confirm with your scoping decision which systems are in scope and which are documented as out of scope, since an assessor will test that line.

Security tooling that produces monitoring evidence

Monitoring depends on tools that continuously collect and evaluate control state, such as endpoint policy checks, log analysis and vulnerability scanners. Record which tool checks which control, how often it runs, and where its output is stored. A tool that runs but whose results nobody reviews does not show that controls remain effective, so the assessor will ask for both the configuration and the review record.

Logs and audit records as monitoring inputs

Audit logs from identity systems, firewalls, cloud consoles and endpoints show whether access and boundary controls still behave as designed. Confirm that each in-scope source forwards logs to a central store, that time sources are consistent, and that someone can show a sample of alerts raised from those logs. Gaps in log coverage usually surface as gaps in monitoring evidence.

Owners who review monitoring results

Monitoring only informs decisions when a named owner reviews the results and acts on them. Assign owners for each control family, usually security operations for technical controls and compliance or GRC for policy and procedure controls, and define who escalates a failed control to management. Record the review date, the reviewer and the decision taken, because those records are what an assessor tests.

Managed service providers and their reports

When a managed security provider runs monitoring for you, the organization still owns the control and must be able to show its effectiveness. Obtain the provider's monitoring scope, alert procedures and periodic reports in writing, and confirm whether the provider is inside your assessment boundary because it stores or accesses CUI. Ask how the provider's evidence will be made available to your assessor.

Cloud providers and inherited controls

Cloud platforms often provide their own monitoring, logs and configuration checks that you can use as evidence. Identify which controls are inherited from the provider, which you configure yourself, and which are shared. Retain the provider's compliance documentation and your own configuration settings, because an assessor will expect you to show that the cloud service is monitored in the way your scope claims.

How an assessor tests control monitoring against NIST SP 800-171A

This table walks through how an assessor reads the single NIST SP 800-171A objective for CA.L2-3.12.3, which objects they examine, what evidence they request and where assessments usually stall. Read it as a checklist of what to have ready before an assessment begins, since the objective is judged on final, dated records rather than on tooling alone.

Assessment element	What the assessor checks	Evidence to have ready	Common finding
Assessment objective	Controls are monitored on an ongoing basis to ensure their continued effectiveness. The assessor looks for an operating monitoring activity, not a one-time review.	Dated monitoring records showing repeated checks across the assessment period	Monitoring described in policy but with no records of it being performed
SSP development and implementation procedures	Documented procedures that explain how the system security plan is created, put into practice and kept current, including who owns each step	Written SSP procedure, role assignments and the approval trail for the current SSP version	Procedure exists but names roles or steps the organization does not actually follow
SSP review and update procedures	How monitoring results feed back into SSP updates when a control changes, fails or is re-scoped	Change log linking monitoring findings to specific SSP revisions	SSP dated years ago while monitoring has reported control changes since
Enterprise architecture documentation	Current diagrams and descriptions of system boundaries, connections and components that monitoring must cover	Architecture diagrams with revision dates and an inventory that matches them	Diagrams omit cloud services, remote access paths or subcontractor connections
Records of SSP reviews and updates	Evidence that reviews happened, who performed them and what changed as a result	Signed or system-recorded review entries with dates and summaries of changes	Reviews recorded as complete with no changes, or records that exist only as drafts
Management use of monitoring results	Whether monitoring output reaches management and informs decisions about acceptable risk and remediation	Meeting notes, risk acceptance decisions or tickets that cite monitoring results	Dashboards are generated but no one reviews them or decides anything from them
Evidence form and status	Whether each artifact is final, approved and dated. Under the CMMC rule a requirement is MET only with evidence in final form, not drafts.	Approved versions with version numbers, approval dates and retention of prior versions	Current evidence is unsigned or marked draft, so the objective cannot be satisfied
Monitoring coverage	Whether the monitored scope matches the system boundary documented in the SSP	Scope statement that ties each monitored asset to the boundary and to the SSP	Monitoring covers the corporate network but not the CUI enclave or cloud tenant the SSP describes

How to implement ongoing control monitoring step by step

This sequence turns CA.L2-3.12.3 from a policy statement into a running practice: a defined monitoring scope, named owners, collected telemetry, a review rhythm, recorded risk decisions and an SSP that reflects what is actually happening. Each step ends with an artifact an assessor can inspect.

Define the monitored controls and frequency
Start from the system security plan and list the security controls that will be monitored, mapped to their CMMC Level 2 requirement IDs such as AC.L2-3.1.1. For each control, record what signal shows it is working, which system it runs on, and how often the signal should be checked. Monitoring should recur more often than the periodic assessments of CA.L2-3.12.1, so the frequency must be set deliberately and written down. The output is a monitoring matrix that an assessor can compare against the SSP.
Assign a named owner to each control
Assign one accountable person to each monitored control, usually an administrator or engineer who operates the underlying system, with a backup for absences. The owner reviews the signal, not only the vendor dashboard. Record the assignments in the monitoring matrix alongside the control ID. The output is an owner column with names and roles that matches the responsibilities written in the SSP, so an assessor can see who answers for each result.
Collect telemetry from endpoints, logs and network devices
Set up collection that produces the signals named in the matrix. Endpoint configuration and policy compliance can be checked with query-based tools such as Fleet, which answers yes or no policy questions per device. Log-based controls depend on ingestion from hosts, network devices and cloud services into a platform such as Wazuh or OpenSearch Security Analytics, which can match events against rules and record findings. Confirm each tool's supported log sources and rule coverage in your own environment before relying on it. The output is a dated record showing that each monitored source is reporting.
Set detection rules and thresholds
Translate each monitored control into rules or policies that produce a pass, fail or alert result. Keep the rule set under version control, document why each rule exists, and note which control it supports. Test rules against known good and known bad examples so that a silent failure does not look like a passing control. The output is a rule register with rule names, the control each rule supports, and test records, which an assessor can use to judge whether monitoring would catch a control failure.
Define review cadence and escalation paths
Set a review rhythm for each control and a written path for failures: who receives the alert, who triages it, who decides whether it is a control failure, and who is told when a control is not working. Include how a failure links to incident response or to a plan of action where needed. The cadence should be shorter than the assessment cycle under CA.L2-3.12.1. The output is an escalation procedure and a review calendar, and the evidence that reviews happened on schedule.
Record management decisions on acceptable risk
When a monitored control fails or a trend shows drift, record what management decided: fix now, accept the risk for a stated reason, or change the control. The CMMC Assessment Guide ties monitoring to management decisions on acceptable risk, so the decision record matters as much as the alert. Include the approver, the date and the reasoning. The output is a risk decision log linked to the alert or review that prompted it, which shows that monitoring informs management rather than sitting in a dashboard.
Feed monitoring results back into the SSP
Update the system security plan when monitoring shows that a control is implemented differently, that a new component joined the boundary, or that a control was changed by a management decision. Track SSP revisions with dates and the monitoring records that triggered them. The SSP is the document that describes how each requirement is implemented, so it should reflect what the monitoring shows. The output is a revision history of the SSP tied to monitoring findings and decision records, which assessors can use to confirm the plan and the operating environment still agree.

How monitoring differs from the periodic assessment in CA.L2-3.12.1

CA.L2-3.12.3 asks for continuing observation of security controls, while CA.L2-3.12.1 asks for a periodic judgment of whether those controls are effective. The periodic assessment is a scheduled, structured test that produces assessment results, proposed control changes and remediation plans. Monitoring is the routine watching that happens between those tests, so that a control that was working at the last assessment does not quietly stop working for months before anyone notices. The CMMC Assessment Guide Level 2 describes monitoring as recurring more often than the periodic assessments and as informing management decisions on acceptable risk. That second point matters most: monitoring exists so that leadership can decide, in time, whether residual risk is still acceptable.

In practice, the two requirements draw on different records. The assessment produces a dated report with findings and a decision trail. Monitoring produces a steady stream of signals: failed logins, configuration drift, unpatched hosts, agents that have stopped reporting, or access reviews that were not completed. A useful check for your team is to pick three controls that matter most to your CUI environment and ask whether someone would see a failure within a reasonable period without waiting for the next assessment. If the answer depends on luck, the monitoring is not doing its job. The monitoring frequency itself is an internal decision that you should document and justify, and you should confirm the expected cadence with your C3PAO or assessor, since the rule text does not fix a number for it.

Evidence that shows control monitoring is ongoing

An assessor testing CA.L2-3.12.3 looks for records that show monitoring happened, on a schedule, by named people, with decisions that followed. The cards below cover the artifacts that carry that proof and how to keep each one current between assessments.

Documented monitoring procedures

A written procedure states which controls are monitored, what data each check uses, who performs it, how often it runs and how results reach management. Assessors read it first to decide whether monitoring is a defined practice or an informal habit. Review the procedure at least once a year and after any major change to the system boundary, tools or staffing, and record the version and approval date. A draft procedure does not count as final evidence, so confirm the approved version is the one staff follow.

Control monitoring schedule

The schedule lists each monitored control, its check frequency and the owner responsible for it. It should show monitoring running more often than the periodic assessments under CA.L2-3.12.1, so the gap between schedule and assessment is visible. Keep the schedule in a controlled location with change history, and update it when controls move between systems or owners change. Ask your assessor how they expect the frequency to be justified for controls with different risk levels.

Dated review records with reviewer names

Each monitoring cycle should leave a record with the date, the controls checked, the result for each and the name of the person who reviewed it. Records without a reviewer or with generic shared accounts are hard to accept because nobody is accountable for the check. Keep these records for the full period your contract or assessment requires, and confirm that retention with your assessor and the contracting office before setting a retention limit.

Alert and finding records with disposition

Monitoring tools generate alerts and findings, and each one needs a recorded disposition: closed as benign, escalated, assigned for remediation or accepted with a reason. Wazuh alerts in alerts.log and alerts.json, or OpenSearch Security Analytics findings, become useful evidence only when someone shows what happened to them. Check that the tool retains its alert history long enough to cover your review cycle, and that exported records keep timestamps and rule identifiers intact.

SSP review and update records

NIST SP 800-171A ties 3.12.3 to the system security plan, so assessors look for records of SSP reviews and updates alongside monitoring results. Each review should note what changed in the environment, which controls were found to differ from the written description and when the SSP was revised. Keep the revision history in the SSP itself, and link each update to the monitoring finding or change request that triggered it.

Management decision minutes on acceptable risk

The CMMC Assessment Guide expects monitoring to inform management decisions about acceptable risk. Minutes from security or risk meetings should record which monitoring results were presented, what decision was made, who approved it and any deadline for follow-up. Without these minutes, monitoring looks like data collection with no owner. Keep minutes signed or stored with access controls, and confirm with your assessor how they want decisions linked to specific controls.

What meeting CA.L2-3.12.3 costs in money and effort

This table breaks the cost of continuous control monitoring into its components, showing who is paid, whether each cost is one-time or recurring, and what drives it up. Use it to build a quote request, since no price or duration is published for these components and the real figures depend on your environment and chosen scope.

Cost component	One-time or recurring	Who is paid or who carries effort	What drives the cost
Monitoring tooling or licenses	Recurring (commercial) or none (open source license fees)	Software vendor for commercial tools; internal staff or an implementation partner for self-hosted open source	Number of endpoints, log sources and cloud accounts; retention period; whether support is bought
Engineering time to configure collection and alerting	One-time, with later changes	Internal engineers or an implementation partner, under a written scope	Number of log source types, custom rules, dashboards and integrations with ticketing or chat tools
Baseline and monitoring procedure documentation	One-time, then recurring updates	Internal compliance or security staff, or an advisor preparing the artifacts	Number of control areas monitored, how often the SSP changes, and how many environments are in scope
Recurring review time by staff	Recurring	Internal security operations or system owners reviewing dashboards, alerts and failing checks	Alert volume, tuning needs, number of systems, and how often management reviews results
Evidence upkeep	Recurring	Internal staff keeping monitoring records, review logs and SSP update history current	Number of monitoring outputs retained, review cadence, and how records are stored and versioned
External review of monitoring design	Recurring or periodic	Independent consultant or implementation partner; never the assessor	Scope complexity, number of environments, and whether the review is a readiness check or a pre-assessment
Assessor time	Recurring at each assessment cycle	Certified third-party assessor (C3PAO for Level 2 certification, where required)	Assessment scope, number of systems and evidence readiness. Ask the assessor for a written estimate.

Open-source tools that produce control monitoring evidence

OpenSearch Security Analytics (Apache-2.0) runs detectors against logs that your hosts, network devices and cloud services send into the cluster. Each detector matches events against prepackaged or custom Sigma rules, and every match is recorded as a finding with its rule, log type and severity. Alerts can be sent to channels such as Slack or email, and the correlation engine links related findings across log types in a correlation graph.

Detector configuration: Exported detector definitions and the log types they cover show what is being monitored.
Findings history: Dated findings with rule and severity show that monitoring ran and what it detected.
Alert routing: Records of which channels received alerts show who was notified.
Correlation graph: Linked findings across sources help show how events were investigated.
Custom rules: Version-controlled Sigma rules tied to the controls they monitor give assessors a traceable link.

Confirm in your own environment which log sources, rule packs and retention settings your deployed version supports, and check the Apache-2.0 license terms that apply to your distribution.

Where control monitoring usually falls short

Most organizations running CA.L2-3.12.3 already have monitoring tools switched on, so the shortfalls tend to sit in the records, reviews and handoffs around them. The cards below cover the gaps assessors most often find and the concrete action that closes each one.

Monitoring that exists only as configuration

A scanner, log pipeline or endpoint policy can be deployed and still leave no proof that anyone looked at its output. Assessors testing the single objective for 3.12.3 want to see that controls are monitored on an ongoing basis, so tool settings alone are weak evidence. Close it by scheduling recurring review tasks with a named owner, and keep dated records of what was reviewed, what was found and what was done about it.

Reviews that never reach management

Monitoring results often stay inside the security team's dashboard, so leadership never decides whether residual risk is acceptable. The CMMC Assessment Guide expects monitoring to inform management decisions on acceptable risk. Close it by sending a short recurring summary of failing controls, open risks and decisions needed to a named executive, and file the minutes or sign-off as evidence.

SSP left behind after monitoring findings

When monitoring shows a changed firewall rule, a new cloud service or a retired system, the system security plan may still describe the old state. SP 800-171A looks for records of SSP reviews and updates, so a stale SSP undermines otherwise good monitoring. Close it by linking each significant finding to an SSP update task and recording the revision date and reviewer.

Log sources missing from collection

Monitoring can only cover what is collected. Servers added during a project, cloud accounts created outside the standard build or network devices with forwarding turned off often never reach the monitoring platform, and the gap stays invisible. Close it by reconciling the asset inventory against collected sources each review cycle and documenting any source intentionally excluded, with the reason.

Draft or unsigned monitoring evidence

Assessors accept only evidence in final form. Monitoring procedures stored as drafts, review reports without approval, or exported dashboards with no date and no reviewer will not satisfy an objective, and the requirement cannot be counted as MET. Close it by setting a version-control rule that marks each procedure and review record as final once approved, and by keeping superseded versions separate.

Unclear ownership between tools and teams

Security operations may own the alerting platform, IT may own the endpoints and compliance may own the assessment, and no one owns the question of whether controls still work. The gap shows up when a finding falls between teams. Close it by writing a RACI for control monitoring that names who runs each check, who reviews the results and who escalates to management.

Common questions about CA.L2-3.12.3 cost, effort and assessment

How much effort does CA.L2-3.12.3 security control monitoring take?

The effort depends mainly on how many systems are in scope and how much monitoring already exists. The requirement has one assessment objective in NIST SP 800-171A: security controls are monitored on an ongoing basis to ensure their continued effectiveness. That makes it a standing operating process, not a one-time project. Effort concentrates in three places: deciding which controls are monitored and how often, collecting recurring evidence such as log reviews, configuration checks and records of system security plan reviews, and keeping those records in final form. The assessment objects in SP 800-171A center on the system security plan, so an organization without a documented SSP review cycle has more setup work. When you request an estimate, ask for setup effort and recurring operating effort as separate lines.

Can we meet CA.L2-3.12.3 with our own staff?

Yes. The organization owns its controls, and the requirement does not require an outside party to run monitoring. In-house teams need people who can define which controls are monitored, review the output on a set schedule, record decisions about acceptable risk and keep the evidence in final form. The CMMC Assessment Guide for Level 2 says monitoring should inform management decisions, so the review process must reach people who can approve risk decisions. Staff also need time to maintain the monitoring tools themselves, including rule updates, agent coverage and alert handling. If your team already runs security operations, the main gap is usually documentation: a monitoring plan, a review log and an SSP that reflects what is actually monitored.

Do we need an implementation partner to monitor controls?

A partner is optional. An implementation partner can prepare systems, controls and evidence, and DeployOpen does this for self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks. A partner can deploy and tune monitoring, document how each control produces evidence and set up review records. A partner does not issue assessment results. Only an independent assessor or certification body issues those, and the organization still owns its controls. DeployOpen works under fixed-scope engagements, so ask for a written scope that names the monitored systems, the tools deployed, the evidence each control produces, who reviews it and how records reach final form.

How often must security controls be monitored under CA.L2-3.12.3?

The requirement calls for monitoring on an ongoing basis, and the CMMC Assessment Guide for Level 2 says this monitoring should recur more often than the periodic assessments under CA.L2-3.12.1. The periodic assessment is performed at least annually under the CMMC rule, so monitoring must run continuously between those assessments. The supplied sources do not set a fixed monitoring interval. Frequency is driven by your risk profile and by how quickly management needs to know about a failed control. Confirm the expected cadence with your assessor and document the cadence you chose and why. Automated checks produce data continuously, but a tool alone does not satisfy the requirement unless someone reviews the results and records what happened.

Is a POA&M allowed for CA.L2-3.12.3?

No. CA.L2-3.12.3 is a 5-point requirement, and 32 CFR 170.21(a)(2) does not allow requirements worth more than one point on a plan of action and milestones. Under the CMMC Scoring Methodology in 32 CFR 170.24, the requirement is subtracted from the maximum score of 110 if it is NOT MET. It must be MET to reach Conditional or Final Level 2 status. The practical consequence is that a monitoring gap cannot be documented as a future fix and accepted. Monitoring must be operating, with evidence in final form, before the assessment. Read the rule text in the eCFR version of 32 CFR Part 170 and confirm the current treatment with your contracting officer.

How does the current CMMC Phase status affect when we need monitoring in place?

The Department of War suspended CMMC Phase II on 13 July 2026. That phase was scheduled to start 10 November 2026 and would have required Level 2 C3PAO certification for applicable contracts, and a 60-day review by a CMMC Reform Task Force followed. Phase I self-assessments, SPRS postings, annual affirmations and DFARS 252.204-7012 obligations remain in place. As of 17 October 2026, the DoW CIO About CMMC page says implementation is paused in Phase 1 and may only require self-assessments at Levels 1 and 2, while the eCFR text of 32 CFR 170.3(e) still shows the original four-phase schedule. The requirement itself does not change, so set timing from written contract requirements and current guidance, not from the eCFR schedule alone.

Which open-source tools can produce monitoring evidence for this requirement?

Several open-source platforms produce data that can support this requirement, but none satisfies it alone. Fleet policies ask yes or no questions of devices as osquery queries, and the policies page shows which devices pass or fail each policy. Wazuh decodes collected logs, compares events against a ruleset of over 3,000 built-in rules and decoders plus custom rules, and writes matching alerts to alerts.log and alerts.json. OpenSearch Security Analytics runs detectors against Sigma rules and records matches as findings. CISO Assistant can track assessments and framework mappings. Confirm each platform's fit with your environment, then connect the outputs to a documented review process and to the SSP.

How DeployOpen prepares control monitoring for a CMMC assessment

DeployOpen works on CA.L2-3.12.3 as an implementation partner: we set up the monitoring systems, records and review routines that show your organization whether its controls keep working between periodic assessments. Your organization owns its controls and decides what counts as acceptable risk, and only an independent assessor can judge whether the requirement is met.

How we scope

We agree a written scope listing the systems, enterprise environments and CUI boundary that monitoring must cover before work starts.
We confirm which security controls your team will watch, which ones feed the system security plan, and who reviews the results.
We document scope, deliverables and timelines in writing, because most engagements are fixed-scope and ongoing support is available as a retainer.

How we build

We deploy self-hosted monitoring in your own infrastructure, such as Wazuh for log decoding and alerting and Fleet policies for device configuration checks.
We configure OpenSearch Security Analytics detectors with Sigma rules so matched events become findings with severity and alerts to your channels.
We set up CISO Assistant to track control status, assessment records and evidence against the framework your organization is assessed on.

How we hand over

We deliver a monitoring runbook describing what is checked, how often, who reviews results and how exceptions reach management decisions.
We provide dated review records and SSP update logs that show monitoring results were acted on, in final form rather than drafts.
We train your staff to run the monitoring, so your organization can produce its own evidence for the independent assessor.

How we support

We can maintain tuning, rule updates and platform upgrades under a retainer that is agreed in writing.
We can run continuous testing of the monitored environment, with findings fed back into your control monitoring records.
Before an assessment, we can help your team check that evidence is complete, while your independent assessor makes the determination.