In our previous blogs we discussed cybersecurity assessments, requirements scoping, and CMMC readiness. Once you have gained an understanding of your current posture, it’s time to get to work. Implementation/remediation is where good intentions become real fixes. You take the guidance from your assessment and make sure the documentation, configuration, and processes are in place and in alignment with the requirements.
Why Cybersecurity Control Remediation Is Critical for Audits
You are building a system that withstands turnover, audit, and chaos. You need to ensure that what you’re putting in place holds true against the scrutiny of an audit. Move past checklist thinking and be aware that controls must function in your environment, not just be enabled from a technical standpoint.
Remediation means mapping a plan of action and milestones (POAM) to real work. Every fix you make should trace back to an identified gap. Applying those fixes is not just doing the work, but also proving it. Keep in mind that after you have addressed all the gaps, you’re not done as you then need to manage and sustain your compliant state.
From POAM to Remediation: Turning NIST 800-171 Gaps Into Measurable Action
Most compliance failures aren’t due to the missing tools, often it’s the missing process element. For example, putting an IT service management tool in place is a means to an end, but operating that tool is what leads to compliant outcomes. Remediation fails when policies exist, but they are not finalized or communicated.
Another issue is SOPs that are never followed. An organization may have executed the paper exercise of defining an SOP, but that does not mean that they are following it. If you define it, train staff on its use.
Be sure to document and sustain point fixes. Something needs to capture the technical configurations that you’re applying to your platforms and systems at a specific point in time. Collect logs for each in scope platform and track how you’re accessing the environment. Also think in systems. Know who owns the fix, where the evidence is, and what keeps it running. Institutionalize the process or the capabilities of process ownership.
Write the Right Documentation to Meet NIST 800-171 Requirements
If your POAM states ‘define’, ‘specify’, or ‘identify’, you need to write it down. These three words permeate the assessment objective framework in NIST 800-171A. Imagine an environment that is technically fully compliant, but with no policy, procedure, or documentation. If you’re missing written evidence, you are not compliant and the corrective action will be documentation.
Start with reviewing your System Security Plan (SSP), which is your story, your decisions, and your narrative. Also take a look at your Acceptable Use Policy (AUP), which is the most common doc auditors ask users about, and see if it should be communicated and acknowledged by users. Make sure your control family policies and procedures are aligned with the 14 NIST 800-171 families. Confirm that your Incident Response Plan is realistic, owned, and exercised. If you have additional SOPs and plans related to your governance approach, now is the time to review those as well.
If you are only seeing the top level requirement, you might be neglecting the assessment objectives that require you to capture activities and actions in writing as a means of remediation. You are not done until it’s final, true, and communicated.
Don’t Just Document Controls — Operationalize Them for Audit Readiness
The document isn’t the goal. The impact is. Ask if the policy is finalized and dated, if the correct audience received it, if you have the acknowledgement records, and if it is factually true. For example, if your policy stipulates that you review logs weekly, show proof of these reviews, not just the documents that say to do them.
Good documentation answers ‘why?’ through policy, ‘how?’ via procedure or standard, and ‘where’s the proof’ with forms, logs, and records. Simply stated, build a defensible paper trail.
Procedures: These show how tasks are performed. When you establish this through remediation, ensure that you have a means to have output that looks defensible. That could be filling out a paper log, signing a sheet, or issuing a ticket through a platform, but you need to demonstrate that the action occurred.
Standards: These are expected configurations or subsequent language around a particular requirement that’s below policy-level build standards, including facility security and human resource background screening standards. It’s less about prescriptive steps, and more about a checklist, making it more granular than policy.
Forms and Records: This is evidence of execution. The form is a means of record keeping. You might want to create forms attached to procedures to capture when you review logs on a weekly basis. Annotating on a log or SharePoint list could show that you have taken the action.
If you have any questions about how to move forward with your documentation, contact the experts at CyberSheath. We’re here to help.