Writing Effective Policies and Procedures for CMMC

During a CMMC journey, the self-assessor must meet objective requirements using “specifications”. Specifications are document-based artifacts that contain a company’s written decisions for how they will address objectives outlined in the framework. These are usually expressed through written policies and procedures, typically documented in a system security plan.  

Here, we face another CMMC flaw: expecting self-assessors to know and understand how to write effective policies and procedures. RADICL has got you covered.  

What is a policy? 

A policy is a statement of self-governance where a business must decide how it will meet objectives outlined in a framework. The policy is a written expression of these decisions and explains what objectives and points have been accepted and adopted.  

When to write a policy 

While CMMC is mandated, the individual objectives inside the framework require discernment to determine if and how they are relevant to the FCI/CUI environment. A company working towards CMMC will write a policy and procedure when they have decided to elect objective requirements and implement the recommended cybersecurity best practices. 

When to NOT write a policy

A company can decide not to adopt an assessment objective where a reasonable explanation considers residual risks, risk transfer, mitigations, and risk acceptance. CMMC and all cybersecurity frameworks require documentation of risk acceptance within the system security plan. It's common for a company to adopt most controls and choose a select few where risk acceptance is applicable. 

According to NIST SP 800-39, Managing Information Security Risk, here are a few reasons a company may choose not to adopt an objective.  

1. Compelling mission, business, or operational needs.  
2. Priorities and trade-offs between:
   1. Near-term mission/business needs and potential for longer-term mission/business impacts, and
   2. Organizational interests and the potential impacts on individuals, other organizations, and the Nation. 

Therefore, a company can decide not to adopt a control if it hinders the mission objective, ineffectively reduces risk, is an unsustainable financial burden to implement, compensating controls exist, or the risk is minimal based on predetermined conditions.  

How to write an effective policy 

Writing a policy takes finesse, and if you have ever downloaded a template policy from the internet, you will quickly realize they often do not fit. They require thought and a tailor to adopt the control into the company's purview. A policy should answer the following questions: 

1. When was this policy written? When was it last reviewed and updated? 
2. Who does the policy apply to? 
3. What guidelines or standards is the company going to require itself to adopt? 
4. At what frequency should the policy be acted on or carried out?  
5. Why was this policy written? 
6. What problem does the policy address? 

How to write an effective procedure  

Procedures are the follow-up to the outlines defined in each respective policy. Procedures should consider and include the following. 

1. When was the procedure written? When was it last updated? 
2. Who should follow the procedures? 
3. Provide instructions for following the procedure or reference a technical document explaining implementation actions. Include screenshots, diagrams, instruction sets, videos, or other guiding information to follow the policy.  
4. How often should the procedures be followed? 

Common mistakes to avoid 

Writing policies and procedures correctly can be daunting, and it's no surprise that challenges exist when working toward cybersecurity compliance. The following are commonly observed issues with documented policies and procedures. 

1. Restating the objective 
   1. Example: Require strong passwords that include complexity requirements. 
   2. Mistake: ACME organization requires all employees to use strong and complex passwords. 
2. Missing logistics details 
   1. Policies and procedures should define logistic requirements, who is responsible, how often to follow, how to track implementation, and when they were last updated and reviewed. 
3. Not reviewing and updating 
   1. At a minimum, policies and procedures require annual review to remain relevant. 
4. Not updating after significant system changes 
   1. Material changes to the FCI/CUI environment require review for accuracy. 
5. Missing the point 
   1. Misunderstanding technical requirements often leads to writing policy content that is missing the point of the objective. 

Conclusions 

For each CMMC objective, an assessor must write down their respective policy and procedures. Although not outlined in CMMC, these companies should document them in a System Security Plan, maintained in a central location. Companies working towards CMMC will face challenges throughout their compliance journey. Often, these challenges show up in their documentation efforts due to the complex nature of self-governance. By responding to each policy and procedure question discussed above, a company can write much more effective policies and procedures that are sure to pass compliance audits.  

If you’d like to find out how RADICL can help you on your CMMC journey, Let’s Talk