In terms of CMMC many organization feel overwhelmed by documentation and do not always understand the distinction between policy, plans, and procedureYet we often get lost in the effort to meet compliance requirements and forget that the “G” in GRC stands for governance The documentation your company uses in cybersecurity should define HOW you govern your company. They need to have merit and functionality for your employees.polcy flowchart

Policy

Policies provide a formal statement of organizational intent and management direction. In terms of CMMC these policies usually point to a control family and say what requirments you will meet.

NIST describes security policy as defining the objectives and constraints of the security program. It generally answers “what” and “why,” rather than “how,” and is normally written so it is not dependent on a specific technology.

A policy should establish:

  • The organization’s security objective.
  • Who and what are covered.
  • Mandatory requirements.
  • Assigned authorities and responsibilities.
  • Rules for exceptions and enforcement.
  • Review and approval requirements.

The policy establishes the rule, but it does not explain every administrative step for creating an account.

In NIST SP 800-53, many control families begin with a requirement to develop, document, disseminate, review, and update a family-level policy and procedures. The policy governs the relevant controls, while the procedures facilitate their implementation.

Plan

A plan translates policy and requirements into an organized implementation approach. They explain who does the what.

Plans are normally broader than procedures. They coordinate:

  • People.
  • Responsibilities.
  • Resources.
  • Technology.
  • Schedules.

A plan may describe how the organization intends to achieve an outcome, but it usually does not contain steps people take

Your Cybersecurity Program may have some of the following plans

  • System Security Plan.
  • Security and Privacy Assessment Plan.
  • Continuous Monitoring Strategy or Plan.
  • Contingency Plan.
  • Incident Response Plan.
  • Configuration Management Plan.
  • Plan of Action and Milestones.
  • Security Training Plan.

In your plan you explain the structured process for preparing, categorizing, selecting, implementing, assessing, authorizing, and continuously monitoring security and privacy controls. Plans provide the organized documentation needed to carry out those activities.

For example your Configuration Management Plan might establish:

  • The Change Control Board membership.
  • Which systems and configuration items are controlled.
  • Change categories.
  • Approval responsibilities.
  • Baseline-management approach.
  • Required security-impact analysis.
  • Emergency-change process.
  • Configuration monitoring and reporting.
  • Review cadence.

The plan explains how configuration management gets organized in your organization., but a separate procedure may explain exactly how to submit and approve a change ticket. Some companies, to cut down on total documentation, may combine plans and procedures.

ISO/IEC 27001 does not require every organization to use a document literally titled “Plan.” Instead, it requires appropriate documented information demonstrating that required processes are planned, implemented, controlled, monitored, and improved. So many CMMC companies with previous ISO work may not have the plans found in RMF.

Therefore, under ISO, planning information may appear in different documentation that you can map back to your policies.

Procedure

A procedure explains how personnel perform a specific activity consistently. These documents provide steps people take to enact a plan aligned to your policy,

A good procedure should be sufficiently detailed so a qualified person can perform the activity without inventing the process.

It typically identifies:

  • Trigger or frequency.
  • Responsible role.
  • Required access and tools.
  • Inputs or prerequisites.
  • Sequential steps.
  • Decision points.
  • Required approvals.
  • Records and evidence produced.
  • Escalation conditions.
  • Exceptions.
  • Completion criteria.

How do they fit?Consider incident response:

Policy

Let us consider incident response. Cybersecurity incidents, regardless if CUI got compromised, must get immediately, investigated, contained, documented, and reported to external authorities when legally or contractually required.

Plan

The Incident Response Plan identifies:

  • Incident-response team members.
  • Incident categories and severity levels.
  • Communication channels.
  • Reporting responsibilities.
  • External reporting requirements.
  • Available technical resources.
  • Coordination with legal counsel and service providers. *Testing and exercise schedule.

Procedure

A suspected CUI incident procedure operationalizes the plan for every day users

  • How the user reports the event.
  • Who opens the incident ticket.
  • How the device is isolated.
  • How logs and forensic images are preserved.
  • Who determines whether CUI or covered defense information was involved.
  • How the 72-hour DFARS reporting deadline is tracked.
  • Who submits the report.Overall a document should not be classified solely by its title. Its function and content determine what it it acts as a policy, plan, or procedure. A Plan could have many documents. Procedures can get used to meet the requirement of numerous policies. A document called a “policy” that contains only step-by-step instructions is operationally a procedure, while a document called a “procedure” that only states executive requirements may actually be functioning as policy.

work cited: complianceforge.com/start-her…