The CA domain is where most contractors get a rude awakening. They spend six months locking down their systems, encrypting all the things, and configuring MFA -- then walk into an assessment and fail because nobody wrote any of it down. This guide covers all four CA practices so you understand not just what they require, but why they exist and how to implement them without losing your mind.
CA stands for Security Assessment. It is one of 14 domains in CMMC Level 2, and it maps to the four practices in NIST SP 800-171 section 3.12. At a high level, CA is your self-awareness layer: it covers how you check whether your security controls are working, track what is broken, watch for problems between checks, and document your entire security setup in one master reference document.
Think of the other CMMC domains as telling you what to build. CA is the part that asks: okay, but how do you know it is actually working?
Imagine you install a deadbolt on every door in your warehouse. CA is the practice of actually testing whether the deadbolts lock, writing down that you tested them, fixing the ones that do not, and keeping a document that explains the whole security setup to anyone who walks in and needs to understand it.
Every other CMMC domain asks: does this control exist? The CA domain asks: do you actually know whether your controls are working? That is a fundamentally different question, and it is much harder to hand-wave past.
You can have every technical control configured perfectly and still fail CA. Here is why: during an assessment, a C3PAO assessor will pull up your assessment report, your POA&M, your monitoring logs, and your SSP -- and then start cross-referencing them against each other. If your SSP says you run monthly vulnerability scans but your scan logs only go back 60 days, that is a finding. If your POA&M shows 20 open items but your last assessment identified 25, they will calmly ask where the other five went. (Spoiler: "we closed them" is not sufficient. Show the evidence.)
The CA domain is where the paper and the reality are required to match. That is what makes it hard -- and that is why people skip it until it is too late.
CMMC Phase 2 Note (July 2026): DoD has temporarily suspended the mandatory C3PAO third-party assessment requirement while it works through program capacity issues. Self-attestation is still required for most Level 2 contractors. Important: the CA requirements apply equally to self-attestation. You still need real documentation and real evidence. "We attested to it ourselves" is not a shield against a future audit.
This practice says you must periodically evaluate your security controls to determine whether they are effective. The word "periodically" is doing a lot of work here -- NIST deliberately left the frequency vague, which is both a blessing (you can define it) and a trap (you still have to define it and stick to it).
Once a year (at minimum), someone needs to actually test your security controls -- not just assume they work. Like a fire drill: you do not wait for a fire to find out if everyone knows where the exits are.
What counts as "periodic"? Most assessors and all practical guidance land on annual as the floor. That does not mean every single control needs a full deep-dive every year -- you can tier your assessment so higher-risk controls get more attention -- but the overall assessment cycle should not exceed 12 months.
What your assessment must produce:
Who can run it? For internal assessments, your own ISSO or IT security staff can do it. The catch: they should not be assessing controls they are solely responsible for operating. There needs to be some separation. For the formal C3PAO assessment itself, that independence is mandatory and provided by the third party.
The classic mistake: Using a spreadsheet where someone types "Yes" next to each control based on their gut feeling, then calling it an assessment. Assessors will ask for the underlying evidence. "I checked the box" is not evidence. A screenshot of the config, a log export, or a test result -- those are evidence.
First: POA&M stands for Plan of Action and Milestones. It is pronounced like "po-am" by people who say it a lot. It is a formal list of every security gap or deficiency you have found, with details on who owns it, how they plan to fix it, and by when.
The POA&M is your security to-do list -- but with accountability. Not just "fix the firewall rules" but "who will fix the firewall rules, what exactly they will do, and when it will be done." It is a living document that gets updated as gaps get closed or new ones get discovered.
The POA&M is one of the most scrutinized documents in a CMMC assessment because it reveals whether your organization actually tracks and remediates findings or just acknowledges them and moves on. An old, dusty POA&M with no updates is a red flag. A current POA&M with realistic dates and active management tells a much better story even if it has a lot of open items.
What every POA&M entry must include:
What is "Risk Accepted" and when can you use it? If a finding cannot be remediated by the target date -- or if the cost of fixing it outweighs the risk -- you can formally accept the risk. A manager signs off, the item stays in the POA&M with "Risk Accepted" status, and you document why. This is completely legitimate. What is not legitimate is closing items without evidence just to make the POA&M look cleaner. Assessors have seen that trick before.
The classic mistake: Building a POA&M the week before an assessment and never touching it again. Assessors will notice that every entry has the same creation date, every target date has been deferred multiple times with no notes, and nothing has ever been marked Completed. That is not a POA&M. That is a prop.
Practice 3.12.1 is your annual check-up. Practice 3.12.3 is everything else -- the ongoing activities that tell you whether your controls are still working in between formal assessments.
An annual assessment is like a yearly physical exam. Ongoing monitoring is like checking your blood pressure at home, tracking your sleep, and noticing when something feels off -- instead of waiting a full year to find out you had a problem months ago.
The difference matters because threats do not wait for your annual assessment cycle. A misconfiguration introduced in March should not sit undetected until December. Ongoing monitoring is the feedback loop that catches problems while they are still small.
What ongoing monitoring looks like in practice:
| Activity | Typical Frequency | Evidence You Need |
|---|---|---|
| Security event log review | Daily | Log review records or SIEM alert history |
| Vulnerability scanning | Monthly | Scan reports with remediation tracking |
| POA&M status review | Monthly | Meeting notes or updated POA&M timestamps |
| User account access review | Quarterly | Access review sign-off with dates |
| Configuration baseline comparison | Quarterly | Drift detection reports |
| Policy and procedure review | Annually | Reviewed/approved documents with dates |
| Full control assessment (3.12.1) | Annually | Assessment report with findings |
Your security policy needs to define this schedule in writing -- and your actual monitoring activities need to generate records that prove they happened. This is the part that trips people up: monitoring without records is indistinguishable from not monitoring at all. If your policy says weekly log review, there need to be weekly log review records. Every time.
The classic mistake: Writing a beautiful monitoring schedule in the policy document, then never generating the evidence that any of it happened. Your assessor cannot take your word for it. "We do it but just do not document it" will cost you points and credibility simultaneously.
The SSP is the master document for your entire security program. It describes your systems, your environment, and how each of the 110 NIST SP 800-171 practices is addressed. Every other piece of documentation eventually points back to the SSP.
The SSP is the owner's manual for your security environment. If a brand-new security assessor walked into your organization knowing nothing, the SSP is the document that would explain what systems exist, what data flows through them, what controls are in place, and what is still being worked on. If your SSP is accurate, it tells a coherent story. If it is out of date or inconsistent, it tells on you.
What your SSP must cover:
Why 3.12.4 carries a -15 SPRS penalty (the highest of any single practice): The SSP is foundational. Without it, an assessor cannot evaluate anything else. It is the lens through which your entire implementation is assessed. An organization with no SSP -- or a deeply inaccurate one -- is essentially showing up to an open-book exam without a book.
Keeping it current: The "periodically update" language means the SSP needs a documented annual review cycle, plus update triggers for material changes: new systems added to scope, major personnel changes, new third-party vendors with CUI access, or when assessment findings reveal the SSP does not match reality.
The classic mistake: Writing the SSP once, filing it away, and never touching it again. An SSP describing an environment from 18 months ago -- before you moved to Azure, added three contractors, or changed your MFA solution -- is worse than a starting point because it actively misleads assessors about what you have.
These are not four separate tasks. They form a cycle:
If any link in that chain is broken, the whole CA program falls apart. An SSP that does not match reality makes your assessment inaccurate. Assessments with no findings that feed into a POA&M means either nothing is wrong (unlikely) or nobody looked hard enough. A POA&M nobody updates means deficiencies linger indefinitely. Monitoring with no records means gaps go undetected between cycles.
Start with the SSP. Before you can assess anything, you need to know what you are assessing. Build your system boundary, identify every component in scope, and document your current implementation status for each practice -- even if that status is "Not Implemented" for half of them.
Then run your first gap assessment against all 110 practices. This gives you your first 3.12.1 execution. Every gap you find goes into a POA&M entry. Now you have a live POA&M, a baseline SSP, and a dated assessment report. You have hit all four CA practices in one structured effort.
The good news: doing it right once creates the paper trail that makes every subsequent assessment easier. The bad news: there is no shortcut. The paper has to reflect reality, and reality has to be documented.
Assessor perspective: Assessors are not hoping to fail you. They are trying to determine whether your organization actually understands its own security posture. A contractor who walks in with 15 open POA&M items, a realistic remediation plan, and honest documentation has a better assessment than a contractor who claims perfect implementation and cannot back it up. Credibility counts. Own your gaps; do not hide them.
Your SPRS score is the 110-practice self-assessment score you report to the DoD Supplier Performance Risk System. It starts at 110 and you subtract points for each practice that is not fully implemented. The CA practices carry the following weights:
| Practice | Description | SPRS Point Value |
|---|---|---|
| 3.12.1 | Periodic control assessments | -5 |
| 3.12.2 | POA&M | -5 |
| 3.12.3 | Ongoing monitoring | -5 |
| 3.12.4 | System Security Plan | -15 |
Practice 3.12.4 -- the SSP -- carries the highest single-practice penalty in the entire 800-171 framework at -15 points. If you have not yet built your SSP, that single action moves your SPRS score by 15 points. No other practice delivers that kind of single-task ROI.
Not doing any of the four CA practices costs you 30 points off your SPRS score. That is 27% of your total possible score wiped out by documentation failures alone.
| Tool / Resource | What It Helps With |
|---|---|
| NIST SP 800-171A | The official "how to test each practice" guide -- assessors use this exact document |
| NIST SP 800-18 | The government's own guide to writing SSPs |
| Microsoft Excel / Google Sheets | Perfectly adequate POA&M tool for small contractors; GRC platforms for larger orgs |
| Tenable Nessus / OpenVAS | Vulnerability scanning for ongoing monitoring |
| Azure Defender / Defender for Endpoint | Continuous monitoring with alert telemetry for log review |
| CMMC Assessment Evidence Tracker | Links your assessment findings directly to POA&M entries -- keeps everything connected |
The Security Assessment (CA) Policy Template covers all four practices in a single ready-to-edit Word document. Includes a POA&M risk classification table, monitoring frequency schedule, SSP section structure, and roles matrix -- all formatted and CMMC-mapped. Download, fill in your brackets, done.
Get the Template → $29The CA domain is the oversight layer for everything else -- which means these guides cover what you will actually be assessing and monitoring:
All 110 NIST SP 800-171 practices organized by domain -- formatted for assessment prep. Free PDF, instant access.