What a CMMC Continuous Monitoring Procedure Actually Contains

The short answer

Search for CMMC continuous monitoring and you will get checklists. Every one of them tells you what to monitor. None of them is a procedure.

That distinction is the whole requirement. A checklist is a list of things someone should do. A procedure states who does them, how often, using what, what happens when a check fails, who verifies that the failure was handled, and what record survives the process. An assessor is looking for the second thing.

This article gives the structure of a continuous monitoring procedure that satisfies CA.L2-3.12.3, and names the two sections that almost every organization leaves out.

What does the requirement actually say?

Monitor security controls on an ongoing basis to ensure the continued effectiveness of the controls.

That is CA.L2-3.12.3, short name Security Control Monitoring.

Sources: DIB SCC CyberAssist, CA.L2-3.12.3 and csf.tools, NIST SP 800-171 Rev. 2 3.12.3. The CMMC Level 2 requirements are identical to NIST SP 800-171 Rev. 2 by regulation, per 32 CFR 170.14.

Three sibling requirements shape what the procedure has to cover:

Source for 3.3.1: NIST SP 800-171 Rev. 2, primary. Text for 3.12.1 and 3.12.2 from csf.tools, authoritative secondary.

Read together: monitor continuously, assess periodically, route failures into a POA&M, and keep records that let someone reconstruct what happened.

Why does a checklist fail this?

Because a completed checklist proves that a list existed and someone ticked it. It does not establish frequency, ownership, method, or what happened when a box could not be ticked.

Consider what an assessor can ask about any single line on your list:

• How often is this checked, and where is that frequency stated?
• Who is accountable for the check, by role rather than by name?
• What tool or command produces the result, and what does its output look like?
• What is the threshold that makes a result a failure?
• When it failed on some date last quarter, what happened next?
• Who confirmed the fix, and how is that confirmation recorded?

A checklist answers none of these. A procedure answers all of them in writing, before anyone asks.

The seven sections

1. Scope

Which controls this procedure monitors, and across which assets. Reference your asset inventory and your defined boundary rather than restating them, so the two documents cannot drift apart.

State exclusions explicitly. A control monitored under a different procedure, or an asset class deliberately out of scope, should be named here with the reason. Silent omissions read as gaps.

2. The monitoring schedule

This is the core of the document and it belongs in a table, not in prose. One row per monitored control, with these columns at minimum:

The artifact column is the one people skip, and it is the one that determines whether the procedure produces evidence or just activity.

3. Data sources and their limits

For each method in your schedule, state what the source can and cannot establish. This section is unusual and it is worth writing, because it is where an assessor stops probing.

A worked example from a Mac fleet: a management console report showing a configuration profile installed is evidence that the profile was delivered. It is not evidence that the setting is in force, because Apple's ProfileList command returns payload metadata rather than setting values. Apple does report genuine device state for a fixed set of facts, through the SecurityInfo command and through Declarative Device Management status items. FileVault is covered by both. The external storage restriction introduced at macOS 15 is covered by neither, so effectiveness there has to come from on-device audit output.

Sources: Apple Developer, Profile List command and Apple, Declarative status reports

Writing this down does two things. It stops your organization from over-claiming in the SSP, and it demonstrates the kind of understanding that makes the rest of your documentation credible.

4. Deviation handling

This is the first of the two sections that almost everyone omits, and it is what the word "assurance" in continuous compliance assurance is pointing at.

A monitoring procedure that only describes the happy path is not a control. Specify:

• What counts as a deviation. The threshold or condition that turns a result into a finding. "FileVault reported disabled on any in-scope asset" is a threshold. "FileVault looks wrong" is not.
• Who is notified, and within what time. Role and elapsed time, both stated.
• The immediate action. Contain, remediate, or accept with justification.
• The decision point for a POA&M. Not every deviation becomes a POA&M item. State the criterion that decides, and note that CMMC has its own rules about which requirements may be deferred at all.
• Who may authorize an exception, and for how long. Exceptions with no expiry become permanent gaps.

If your organization already tracks exceptions in a register, reference it here rather than duplicating it.

5. Verification

The second commonly missing section. Monitoring produces results. Verification confirms that the monitoring itself happened and that deviations were closed.

Three questions to answer:

• Who reviews the monitoring records, and how often? Typically a different role from the one performing the checks.
• What does that review produce? A dated record with a name and a scope statement. A review that leaves no artifact did not happen, from an evidence standpoint.
• What happens when a scheduled check was missed? A procedure with no answer here will fail on its first missed month, and every procedure eventually has a missed month.

This section is what separates ongoing monitoring under 3.12.3 from periodic assessment under 3.12.1. If your only verification is the annual assessment, you are meeting 3.12.1 and describing 3.12.3.

6. Records and retention

For each artifact named in the schedule: where it is stored, in what format, who can access it, how long it is retained, and how its integrity is protected.

Two practical points. Timestamps and hostnames should be visible in the artifact itself, not supplied by a spreadsheet alongside it. And if you hash artifacts on collection, say so here, because it converts a screenshot into something that can be shown not to have changed.

7. Review and update

Who owns this procedure, how often it is reviewed, and what events trigger an off-cycle update. A new asset class, a change of MDM, a new macOS major version, or a change to the assessment basis are all triggers worth naming.

Include a revision history in the document. An assessor reading a procedure with a single revision dated three weeks before the assessment draws a conclusion, and it is not a favorable one.

A worked schedule fragment

Illustrative only. Your frequencies and thresholds are your organization's decision to make and defend.

That last row is the verification loop. Note that it monitors the monitoring.

The mSCP compliance script referenced above writes results to a plist at /Library/Preferences/org.BASELINE_NAME.audit.plist and a log at /Library/Logs/BASELINE_NAME_baseline.log, which are collectable file-level artifacts.

Source: mSCP, How to generate compliance scripts

One caveat on leaning on mSCP: the project's CMMC Level 2 baseline describes itself as "a catalog, not a checklist or benchmark," and states that "satisfaction of every item is not likely to be possible or sensible in many operational scenarios." It is a source of evidence, not a certification.

Source: usnistgov/macos_security, baselines/cmmc_lvl2.yaml

What makes a procedure defensible

Four properties, in order of how often they are missing:

1. It produces artifacts. Every scheduled activity leaves something behind that is dated, attributable, and retained.
2. It handles failure. The deviation path is written down before it is needed.
3. It is verified by someone other than the person performing it. Self-verification is not verification.
4. It matches what actually happens. A procedure describing a weekly review that is performed monthly is worse than one that honestly describes a monthly review, because the mismatch is discoverable and it undermines every other document you produced.

That fourth point is the one worth sitting with. The gap between "say what you do" and "do what you say" is where most documentation fails, and it fails during the assessment rather than during the writing.

Where macOS specifics belong

Everything above is platform-independent by design. The monitoring methods for an Apple fleet are a separate question: which checks are available, which require an MDM, which require on-device execution, and where Apple's own reporting stops short.

Those belong in your implementation guidance rather than in the procedure. See continuous monitoring for a macOS fleet under CMMC for the Mac-side detail.