Policies
Also called: Rulebook, Guidelines, Policy
What it is
A Policy is the organization’s official rules and outcomes. It answers:
-
“What must we do?”
-
“What must be true?”
-
“What are we aiming for?”
A policy is not a how-to guide. It’s more like the rules of the road.
Why it exists
Because in a real organization, people need clarity and consistency. Policies prevent “everyone doing it their own way.”
What it usually looks like
-
Short sections like “Purpose,” “Scope,” “Requirements,” “Roles & Responsibilities”
-
Statements like “must,” “required,” “shall”
-
Often approved by leadership
-
Often versioned (because auditors and reality both demand receipts)
Examples
-
“Employees must complete security training annually.”
-
“Access to systems must be reviewed every quarter.”
-
“Background checks are required before hire.”
How to use it
-
Read it to understand the rule.
-
Link your procedures/processes to it (even if writers forget, your system can connect them later).
-
When you’re not sure what “good” looks like, start here.
Common confusion
Policy vs Procedure:
-
Policy = what/why
-
Procedure = how
The official CMMC definition of Policy is:
A policy is a high-level statement from an organization’s senior management that documents the requirements for a given activity. It is intended to establish organizational expectations for planning and performing the activity and communicate those expectations to the organization. Senior management should sign policies to show its support of the activity.
Policy Listing
The current CMMC Assessment Guide identifies the following policies as it describes the sorts of documents an assessor may look to review:
- Access Control Policies
- Asset Management Policies
- Audit and Accountability Policy
- Configuration Management Policy
- Data Protection Policy
- Identification and Authentication Policy
- Information Flow Control Policies
- Information Security Policies
- Information Technology Policies
- Insider Threat Policy
- Password Policy
- Privacy and Security Policies
- Security Assessment and Authorization Policy
- Security Awareness and Training Policies
- Security Planning Policy
- Software Review Policy - In House Development
- Systems Media Policy
- User-installed Software Policy
Organizations need not have exactly this list of policies, but should have a set of policies that address these items. Future versions of FutureFeed will allow tagging of uploaded policies with the above list.
What makes good policy?

Size (Length)
Policies can vary significantly in length, and there are advantages and disadvantages to both short and long policies. Generally, conciseness is advised. The length of a policy can determine how easy it is to find the keywords searched for within the policy, and how easy it is to navigate and read. As a general rule, the shorter the policy, the easier it is for users to retrieve the information they are seeking.
Policy Text Organization
If your policy is long and contains multiple sub-sections within the Policy Statement section, strive to organize the material using sub-headings and bulleted lists.
Avoid the use of numbering schemes, if possible. If you are anticipating including an ordered list, consider whether the material is actually a process rather than policy. Supplemental information such as procedures is not included in the Policy Library, but links to such material are encouraged within the "Resources" section (see above).