Security Control Monitoring
Practice statement
Monitor security controls on an ongoing basis to ensure the continued effectiveness of the controls.
Quoted verbatim from NIST SP 800-171 Rev. 2 §3.12.3.Source
The source document’s non-normative “Discussion” section is not reproduced here. ControlVerdict quotes normative text verbatim or omits it — it never paraphrases a standard. Follow the source link above for the full context.
Assessment Objectives(1)
An assessor determines each objective separately. “Mostly implemented” is not a result — every objective below has to stand on its own.
- [a]
security controls are monitored on an ongoing basis to ensure the continued effectiveness of those controls.
1 example covers this
Objective text quoted verbatim from NIST SP 800-171A via the CMMC Level 2 assessment guide.
Implementation examples(1)
Submit your own example- addresses
CA.L2-3.12.3Security Control Monitoring
Monitor security controls on an ongoing basis to ensure the continued effectiveness of the controls.
[a]
security controls are monitored on an ongoing basis to ensure the continued effectiveness of those controls.
Eighteen continuous-monitoring signals that fail loudly instead of silently
ControlVerdict Corpus@cv-corpusOSCJul 31, 2026Community is just starting — add yours. No verdicts yet.Implementation
AO coverage. Addresses the Security Control Monitoring objective: security controls are monitored on an ongoing basis to confirm they remain effective.
What ongoing means here. Point-in-time assessment tells us a control worked in March. Monitoring tells us it is still working today. We defined eighteen machine-checkable signals that indicate a control has stopped functioning, and each one produces an alert or a ticket rather than a dashboard tile nobody opens.
Representative signals. Device compliance rate below threshold; any conditional access policy disabled or set to report-only; a privileged role assigned as permanently active; an account in the enclave group without a matching HR record; a log source silent for 24 hours; backup job failure or a restore test not completed this quarter; encryption disabled on any managed endpoint; a new external sharing link on a labeled library; scan coverage below the asset count; an exception past its expiry date.
Fail loudly. Each signal routes to a queue with a response time, and the absence of data is treated as failure — a compliance connector that stops reporting raises the same alert as a control that fails. This is the part most monitoring programs get wrong, so it is explicitly tested twice a year by disabling a connector in a maintenance window and confirming the alert fires.
Human review. Automation covers what machines can see. A monthly checklist covers what they cannot: reviewing recent exceptions, spot-checking two evidence artifacts for freshness, and confirming that changes made last month were reflected in the SSP.
Feeding the program. Signals that trip repeatedly become an assessment finding rather than a recurring ticket, because a control that keeps failing is not effective. Trends are reported to leadership quarterly.
Accepted gap. Physical security controls have no automated signal in this environment. They are covered by the monthly human checklist and the badge-log review, which is slower detection than the technical signals and is documented as such.
What the evidence looks like
- Signal catalog mapping each monitored signal to the practice it evidences
- Alert routing configuration and sample tickets from the last month
- Results of the semi-annual dead-connector test
- Completed monthly human review checklists
- Quarterly monitoring trend report to leadership
Environment
Cloud-native OSC, ~120 staff, everything in one cloud tenant with no data center. A two-person security team can only sustain monitoring that is automated and alert-driven.Tools
Discussion(0)
No discussion on this control yet
Edge cases, scoping questions, and “would this pass?” scenarios belong here.
Sign in to start a thread.