Rewrite: it-security-management-making-cmmc-part-of-daily-operations

Word count: ~1,950

Specificity markers hit (5/5):

1. ✅ NIST/CMMC control references — CA.L2-3.12.3, RA.L2-3.11.2, SI.L2-3.14.1, AT.L2-3.2.1, AU.L2-3.3.1, IR.L2-3.6.1
2. ✅ Cost/time estimate — Annual security review 40–80 hrs; SIEM $8K–$20K/yr; training $15–$30/user/yr; quarterly scans
3. ✅ Tool/product name — Tenable Nessus, Microsoft Defender for Endpoint, Splunk, ServiceNow, Jira
4. ✅ Common mistake — Treating CMMC as a project with an end date; letting SSP drift from reality
5. ✅ Decision point with guidance — Build in-house security operations vs. use an MSSP

---

Getting to CMMC compliance is a project with a finish line. Staying compliant is a program with no finish line.

Most defense contractors spend 12–24 months implementing controls, writing documentation, and preparing for their C3PAO assessment. They cross the line, get their certification, and then — because the organization is exhausted from the effort — security management quietly slides back to reactive mode. Patches get delayed. Access reviews stop happening. Training lapses. The SSP stops reflecting what the systems actually do.

Three years later, the triennial assessment arrives, and the organization has drifted significantly from what the assessors certified.

The goal of IT security management for CMMC is to run the ongoing program that prevents that drift — turning the controls you implemented into routine operations that your team maintains without a special project every three years.

What "Ongoing Security Management" Actually Means

The CMMC framework has explicit ongoing maintenance requirements across multiple domains. These aren't implied — they're stated:

CA.L2-3.12.3 — Monitor the security controls on an ongoing basis to ensure continued effectiveness. This isn't "review your SSP annually." It means active, continuous monitoring of whether your controls are working: configurations in their expected state, logs being generated and reviewed, access controls enforced, systems patched.

CA.L2-3.12.2 — Develop and implement plans of action designed to correct deficiencies and reduce or eliminate vulnerabilities. Your Plan of Action & Milestones (POA&M) isn't a document you create for your assessment and then forget. It's a living record of known gaps and your remediation progress. It should be reviewed monthly and updated as issues are closed and new ones identified.

RA.L2-3.11.2 — Periodically scan organizational systems for vulnerabilities, and scan again when new vulnerabilities affecting those systems are identified. "Periodic" isn't defined — assessors look for quarterly at minimum, monthly is better. New CVEs affecting your platforms don't wait for your scan schedule; they require ad hoc scanning.

AT.L2-3.2.1 — Provide security awareness and training to organizational personnel. Annual training is the minimum. Your training records need current dates — if the last training completion record is 18 months old, that's a lapse.

AU.L2-3.3.1 — Review and protect audit logs. Log review isn't automatic. Someone needs to check for anomalies, failed logins, unusual access patterns, and alert on security-relevant events. If logs exist but nobody reads them, the control is technically Not Met.

IR.L2-3.6.1 — Establish an operational incident response capability. Your incident response capability needs to be tested periodically — not just documented. An untested IR plan is weaker evidence than a tested one.

Building the Annual Security Calendar

The simplest way to operationalize ongoing CMMC management is to build a security calendar — a schedule of recurring activities that runs independent of project work.

Here's a workable annual structure for a small-to-mid defense contractor:

Monthly: - Review POA&M — close completed items, add new findings, update timelines - Review SIEM alerts and audit log summaries — look for anomalies, failed authentication spikes, unusual access patterns - Check patch status — verify critical patches deployed within your 30-day SLA, high patches within 60 days - Review service account and privileged account activity

Quarterly: - Run vulnerability scans on all CUI systems (RA.L2-3.11.2) and document results - Conduct access reviews — have system owners verify their user access lists are current and appropriate - Test backup restoration — verify that backups are actually restorable, not just being written - Review and update asset inventory — confirm no new systems have been added to the CUI environment without assessment

Annually: - Security awareness training for all personnel (AT.L2-3.2.1) — run training, collect completion records and signed acknowledgments - Review and update the System Security Plan — walk through the SSP section by section and verify it still accurately describes your environment and control implementations - Update risk assessment (RA.L2-3.11.1) — review the threat landscape, assess whether new risks have emerged, confirm risk acceptance decisions are still appropriate - Tabletop exercise for incident response (IR.L2-3.6.1) — run a scenario, test communications, document lessons learned - Policy review — review all security policies and update as needed; log the review dates and approvals

This calendar isn't comprehensive — your specific environment will add activities — but it covers the minimum ongoing requirements that assessors will look for evidence of during triennial assessments.

The SSP Drift Problem

The System Security Plan is the central document that describes how your organization implements each of the 110 CMMC Level 2 controls. At the moment of your assessment, it's accurate. Over the next three years, things change: new systems get added, tools get upgraded, vendors change, personnel turn over, processes evolve.

The common mistake: organizations treat the SSP as a document created for the assessment, not a living operational document. When the next assessment comes around, the SSP describes a security program that existed three years ago, not the current state.

The fix is straightforward but requires discipline: any time a significant change happens in your CUI environment, update the SSP. The same change management process (CM.L2-3.4.3, CM.L2-3.4.4) that controls what changes you make should trigger an SSP update. If you're adding a new system, the SSP update is part of the change request. If you're changing your VPN solution, the SSP update is part of the project closure.

At minimum, do a full SSP review annually. Read through every control description and verify it still matches reality. It takes 8–16 hours for someone who knows the environment. The first time you do this review after a period of drift, you'll find 15–20 controls where the description no longer matches the implementation. Fix those before they accumulate.

Vulnerability Management as a Repeating Cycle

Vulnerability scanning (RA.L2-3.11.2) and flaw remediation (SI.L2-3.14.1) are two sides of the same ongoing operation. The cycle is:

1. Scan — run authenticated vulnerability scans against all CUI systems. Tenable Nessus, Qualys, or Rapid7 InsightVM are the standard tools. Configure scans with service account credentials so they can assess installed software and local configuration, not just open ports. A non-credentialed scan misses 70–80% of actual vulnerabilities.

1. Prioritize — sort findings by severity and whether they affect CUI systems. Critical CVEs on CUI systems are remediation-required within 30 days. High within 60. Medium within 90. This isn't a universal standard — it's a reasonable benchmark to document and commit to in your vulnerability management policy.

1. Remediate — patch, mitigate, or accept risk (with documentation). For patches, use your patch management tooling (WSUS, SCCM, Intune, or vendor-specific tools). For vulnerabilities that can't be patched (end-of-life systems, systems where patches break functionality), document the compensating controls and risk acceptance in the POA&M.

1. Verify — re-scan after remediation to confirm the vulnerability is addressed. This is the step most organizations skip. Your assessor will ask whether you verify that patches actually worked — a vulnerability still present after a supposed remediation patch is a process failure.

1. Document — keep scan results, remediation tickets, and re-scan results as evidence. Date-stamped scan reports and ticket closure records satisfy the assessor's evidence requirements.

Microsoft Defender for Endpoint includes a threat and vulnerability management module that tracks CVE exposure across enrolled endpoints continuously — no need to schedule separate scans. It's a good option if you're already using Defender for endpoint protection.

To Build vs. To Buy: Security Operations Staffing

At some point, small defense contractors face a decision: do we staff internal security operations, or do we use a Managed Security Service Provider (MSSP)?

Internal security operations make sense when you have the budget for at least one dedicated security person, your technical environment is complex enough to require institutional knowledge, and your security posture is mature enough that you're maintaining controls rather than still building them. A security-focused hire at $90,000–$130,000/year handles ongoing monitoring, maintains the security calendar, owns the SSP updates, and coordinates assessment prep.

MSSP makes sense when your team is too small for a dedicated security person, your security program is largely in place and needs monitoring and maintenance rather than construction, and you can define the scope clearly. MSSPs providing SIEM management, log monitoring, and vulnerability scanning run $2,000–$8,000/month for small contractors. They don't replace your internal security knowledge — someone inside still needs to own the SSP and interface with assessors — but they handle the operational monitoring workload.

The hybrid approach: an internal part-time security function (often the IT manager wearing a security hat) paired with an MSSP for monitoring handles most small contractor needs at $50,000–$80,000/year total cost.

What Your Assessor Expects

Triennial assessments are retrospective evaluations. Your assessor isn't just checking your current state — they're verifying that you've been maintaining controls since your last assessment. That means your evidence needs to span the assessment period, not just be current at assessment time.

For ongoing management controls (CA.L2-3.12.3, RA.L2-3.11.2, AU.L2-3.3.1), assessors typically want to see:

• Scan reports with quarterly or better frequency going back at least 12 months
• POA&M revision history showing items being added, updated, and closed
• Log review records or SIEM alert histories showing active monitoring
• Training completion records with completion dates across multiple periods
• Dated SSP revision history showing it's been maintained, not static

If you have records for the past three months but nothing from the prior two and a half years, you'll have trouble demonstrating continuous compliance. The security calendar approach makes this easy — it produces dated records automatically as a byproduct of doing the work.

---

Building your security calendar? Start with what you're already doing and schedule it. Then identify the gaps — access reviews and SSP updates are where most small organizations have no existing process.