Policy Templates Help DoD Contractors Achieve Compliance with CMMC

Cybersecurity policies are a critical component of DoD contractor compliance, but also one of the most difficult things to accomplish without help.

The Department of the Defense (DoD) expects Defense Industrial Base (DIB) contractors to have cybersecurity policies and high-level processes in place. This becomes apparent when attempting to achieve compliance with DFARS 252.204-7012¹, CMMC 2.0², and NIST SP 800-171³. The reason is that policy is fundamentally important to protecting your information system. It must also integrate with and inform your business operations.

This article will explain what it takes to create policy, show some examples, and offer a much better solution in the form of Policy Templates.

What Does It Take to Create the Required Policy?

The short answer is approximately 250 hours to meet current DoD compliance requirements. Assuming only one person is putting hours into writing policy and that person has DoD-specific compliance expertise. Not everyone is a technical writer, with the time and patience to create dozens of pages of documentation. Even fewer people are experienced compliance consultants, able to properly interpret and write to the 320 required Control Objectives within the 110 Security Controls of CMMC 2.0 / NIST SP 800-171.

Policy Templates will save you a tremendous amount of time and effort, allowing the company to focus on your business mission instead of creating paperwork.

How Much Customization Is Needed?

This depends on where you get your policy from. The majority of policy available on the Internet or sold commercially is not specifically written to the NIST SP 800-171 control set required by CMMC and DFARS 7012. Of the few that are, many take a very rough approach to the 110 controls, not addressing the 320 required control objectives within them. Therefore, it will save you tremendous time and effort to begin with policies that are specific to your DoD compliance needs.

The good news is the NIST SP 800-171 controls and their objectives are fairly high-level. This means a thorough set of policy does not require much customization. We recommend carefully reviewing each line of the Policy Templates to determine how they apply to your business operations, your IT environment, and how you handle Government sensitive information (e.g., FCI, CUI, CDI, FOUO, SBU, LES).

How Does Policy Impact My SPRS Score?

Immensely. If you think that you have a positive SPRS Score but do not have thorough policies, your actual SPRS Score is much lower. This is because DoD requires all control objectives to be fully met in order to get credit for a control. Policy is either explicitly required for or supporting approximately 66 of the 110 controls, with a total SPRS Score value of 171 points (out of 313 points total between the SPRS Score range of -203 and +110).

Ideally, all 110 controls and their 320 objectives should be addressed to some extent in policy. This ensures all compliance requirements are addressed in policy and shows due diligence to any assessor or auditor.

Policy is so important to cybersecurity, compliance, and the SPRS Score that Peerless provides our Policy Templates free of charge with our full Gap Assessments.

What Do I Need to Do With Policy?

Formally communicate it to all relevant employees, contractors, and users. Have them sign an acknowledgment that they have received, understand, and will follow the policy. Place it in a central location accessible to them. Train them in policy and their responsibilities, to include training based on any specific roles and job functions they may have. Be sure to also include policy for Telework and Work from Home (WFH).

Consider having a separate Acceptable Use Policy (AUP), Rules of Behavior, or Employee Handbook policy document for general system users. This allows you to provide them with a single, easier-to-understand document that is separate from the policy to be followed by management and technology staff.

Review policy at least once a year with all stakeholders, update it as your business changes or requirements change, and have it approved by leadership.

What Does Acceptable Policy Look Like?

Acceptable policy cannot be a copy/paste of the Security Controls and their objectives (requirements). It needs to capture or reference cybersecurity best practices in a manner that can be enforced by management, communicated to users, and translated into processes and procedures.

As an example, this is an outline of the policy documents provided with the Peerless Policy Templates. There is one policy document for each of the 14 NIST SP 800-171 control families, in addition to important supplemental policy documents.

• Security Control Objectives
  The requirements within a Security Control. For example, Control 3.13.10 on Cryptographic Keys:
  
  
  
• Bad Compliance Policy
  Policy that is generally a copy/paste of the Security Control Objectives is not effective and will not meet (i.e., get credit for) the Security Control. Bad policy does not communicate what must be done to address the requirements and does not address the cybersecurity best practices necessary to meet requirements. Adding process (how something is done) is a common way that policy is made to look more thorough, but it does not satisfy what is needed at the policy level.
  
  
  
• Good Compliance Policy
  Expands upon each requirement by communicating what must be done to meet the requirements and incorporating best practices according to Government, Federal/DoD agencies, product vendors, and the cybersecurity industry. This is how the Peerless Policy Templates are designed.
  
  

What Is the Difference Between Policy, Process, and Procedures?

Policy, process, and procedures are directly related, with each one informing the next and increasing the level of detail.

Security controls lead to policy, which leads to process, which leads to procedures.

• Policy is explicitly required by many of the Security Controls and implicitly expected by assessors to exist in a manner that addresses all of them. Otherwise, questions are raised such as "How can your employees and users know to follow these compliance requirements if there is no documented policy?" Policy must be formally communicated to relevant managers, employees, and users as relevant to their job functions and system access. Policy documents should be kept in a central document repository or Content Management System (CMS).
  
  
• Process is explicitly required or implied by the Security Controls at a high level and is often captured at a high level within policy documentation and/or within the required System Security Plan (SSP) created from a Gap Assessment / Gap Analysis of your compliance. The Security Controls encourage detailed process, but only high-level process is explicitly required. Detailed process typically requires the creation of dedicated documents. Process can also be written as an executive summary or outline for procedures. Dedicated process documents should be kept along with policy in a central document repository or Content Management System (CMS).
  
  
• Procedures are not explicitly required by the Security Controls, but they are critical to providing evidence that your business is following policy and operating in a compliant manner. These are often step-by-step, capturing every action needed to complete a task. Procedures are dependent on your business, how you operate, your physical and technology environments, and what specific solutions you have in place. The good news is competent high-level process from Policy Templates will guide and simplify the procedures you need. Administrative procedures will typically only require a bit of training (e.g., use of a visitor check-in sheet). Technical procedures are often provided by vendors or searchable online (e.g., how to generate a patch report). Organizing, communicating, and training users on procedures is where a Knowledgebase or Content Management System (CMS) can help.