You’ve completed your internal assessment and scoped your environment. Now it’s time to act on all that intelligence and achieve compliance. How do you go about documenting your compliance with the requirements and making a plan to implement the remaining controls? Let’s discuss.
Why Evidence Drives Compliance Confidence
Evidence is key to a successful and high confidence assessment. Be sure to follow NIST SP 800-171A, the NIST 800-171 assessment guide, as this is the same document the auditors will be referencing. For each assessment objective outlined in the guide, think what an auditor would expect you to prove through demonstration or evidence.
Your system security plan (SSP) is your narrative. It’s your opportunity to tell a story. Write your SSP in a way that accounts for the assessment objectives and ensures that you’re telling that story ahead of an engagement with an auditor. Be aware that without evidence, there’s no defensible score. Evidence is necessary to effectively prepare with confidence. Validate from a documentation and an implementation standpoint to make sure you have full confidence in your preparedness.
What Auditors Expect to See
Evidence can come in many varieties from configuration settings, which you can document with timestamped screenshots or Group Policy outputs; log samples showing activity or alerting; tickets and records from IT service management systems that show that you’re following a process and generating a paper trail; or change management meeting minutes or reviews for monitoring activities. Evidence can also be in any formal documents for any ‘define’ / ‘identify’ / ‘specify’ requirements.
NIST 800-171A is the paybook for evidence collection. You must meet each assessment objective for a control to avoid a score deduction. Ask yourself, “What can I demonstrate to prove something is occurring?” Here is guidance for how to approach the objectives.
- For Define objectives, you need a document.
- For Implement objectives, you need a working system.
- For Monitor objectives, you need records.
- For Review objectives, you need proof of human activity.
Real-World Example: Password Complexity Done Right
Let’s review a real-world example involving the password complexity (IA.L2-3.5.7) requirement, which states that an organization must enforce a minimum password complexity and character change when new passwords are created. Each assessment objective must be passed to avoid a scoring deduction.
| Objective | Description | Score | What’s needed |
|---|---|---|---|
| (a) | Define password complexity requirements | FAIL | Documented defined organizational password complexity (e.g., policy, standard) |
| (b) | Define password character change requirements | FAIL | Documented requirement that new passwords differ from previous passwords |
| (c) | Enforce complexity | PASS | Config screenshot or GPO enforcing length/symbols |
| (d) | Enforce character change | PASS | Password history/difference enforcement proof |
As you can see there are four assessment objectives for this particular requirement.
C and D address the technical enforcement. In this example, the client had the password history setting enabled and had documentation to demonstrate that. What the client failed to do, however, was define password complexity which is required in objectives A and B. While the company had the technical capability in place, without the written policy, two of the four objectives failed, resulting in partial compliance and a full point deduction. Enforcement alone doesn’t cut it. Documentation matters.
Using POAMs to Drive Corrective Action
Writing real plans of action and milestones (POAMs) is the start of your corrective actions. As you are collecting data, the corrective actions are the deficient items that require subsequent steps to get to compliance. If something is not in place or not provable with evidence, then it’s a finding. You need to get to a point where you can stand in front of an auditor and confidently state, show, and defend your stance.
Write clear, concise fixable POAMs that highlight what is missing, the necessary corrective action, task ownership, and targeted completion date. Avoid vague language like ‘implement monitoring’ with no detail. Instead write, ‘Need to evaluate, select, and deploy a multifactor authentication solution due to lack of MFA on endpoint devices.’ A POAM does not equate to compliance. It is a path forward. Use it well.
POAMs are mandatory and auditable. They are required by NIST SP 800-171, Requirement 3.12.2, DFARS 252.204-7019, and CMMC Level 2 Final Rule (32 CFR Part 170). If you’re not tracking deficiencies, you’re not compliant. Auditors will ask to see your POAMs. They should be updated, versioned, and traceable to assessment results.
What True CMMC Readiness Looks Like
CMMC readiness means you can defend your implementation. You should not be entering into a CMMC assessment engagement unless you feel that you are in full, defensible compliance.
You should be ready to defend everything and:
-
- Know your boundary and scope cold. Both should be well-established and defensible.
- Articulate your CUI flows with confidence. Prepare to explain to an auditor what your flows and boundaries are. Show illustrations. Make sure your SSP is well-documented, clear, and concise.
- Prove implementation of all applicable requirements. Draw the boundaries, explain what those boundaries mean, and then prove implementation with all of the applicable requirements.
CMMC Compliance Is a Continuous Process
Lastly, recognize that there is no end state for CMMC compliance. Readiness isn’t a one-time milestone—it’s a system. Repeat assessments, maintain and version POAMs, treat SSPs as living documents, and continuously gather and update evidence.
These steps feed certification and future re-certification and prepare you for the real reason you’re doing this: protecting CUI for national defense.
If you have any questions about how to proceed with your assessment, scoping, or evidence gathering, contact the experts at CyberSheath. We’re here to help.