CP-1 Policy and procedures: requirements and evidence

What NIST SP 800-53 CP-1 asks for and why assessors start with the policy

NIST SP 800-53 CP-1 policy and procedures is the first control in the contingency planning (CP) family, and it asks for a documented contingency planning policy plus the procedures that put that policy into practice. The policy sets the rules for contingency plans, system backups and recovery, and the procedures describe how staff carry them out. The control also requires that both be distributed to defined roles, managed by a designated official, and reviewed and updated at a defined frequency and after defined events. CP-1 is selected in the low, moderate and high baselines of SP 800-53B but not in the privacy baseline, and it has no control enhancements in Release 5.2.0. Because it is a single control with one policy and one set of procedures, it is short on paper and often underestimated.

Assessors start here because every other CP control depends on it. Without a governing policy, contingency plans, backup schedules and recovery steps tend to be written by different teams, with different assumptions about recovery targets, and nobody is accountable when they disagree. SP 800-53A assesses CP-1 by examining the policy and procedures, the system security plan and interviewing personnel with contingency planning responsibilities, so an assessor will ask who owns the document, who received it and whether the people named in it know what it says. The control also points to related controls in PM-9, PS-8 and SI-12, so the policy should be consistent with the organization's risk management, personnel security and integrity programs.

The usual failures are documents that exist but have no named owner, no record of distribution, and no review after a major system change, a restore test or a staffing change. An assessor can find a policy dated several years ago and conclude that it was never operationalized. Before an assessment, confirm who is the designated official, which roles receive the policy and how receipt is recorded, which review frequency your organization has defined, and which events trigger an out-of-cycle update. Your implementation partner can help structure these records and gather the evidence, but the organization must own the policy and its approval, and an independent assessor makes the determination.

Which systems, teams and documents CP-1 covers in practice

CP-1 is written once, but the work it drives depends on which systems fall inside the authorization boundary, how much impact each system carries, and who holds contingency roles. The cards below set out the scoping decisions an organization should settle before it drafts the policy and procedures.

Systems inside the authorization boundary

CP-1 applies to every system the policy names, so the first decision is which systems fall within the authorization boundary. Confirm the inventory against the system security plan, including hosted components, backup infrastructure and identity services that a recovery depends on. A system left out of the boundary may still hold data that the contingency policy must cover, so check each dependency before accepting an exclusion.

Impact level and baseline selection

The impact level of each system determines whether CP-1 applies at the low, moderate or high baseline under SP 800-53B. Because CP-1 is selected at all three security baselines, the policy itself is the same requirement everywhere, but the procedures, review frequency and downstream contingency controls grow with impact. Record the chosen baseline per system and tailor it in writing, so an assessor can trace why each system carries the procedures it does.

Teams holding contingency roles

CP-1 requires the policy to be distributed to defined roles and managed by a designated official. In practice, those roles span platform operations, security, application owners, facilities and business continuity staff. Map each role to a named person or position, and confirm who approves changes to the policy. Gaps appear most often where a recovery step depends on a team that never received the procedures.

Third parties running backup or recovery

Where a cloud provider, managed service or outsourced data center runs backups or recovery, the policy must still describe how those services are governed. Identify each third party, the service it performs, and the contract or service terms that define its responsibilities. Ask each provider for its own contingency documentation so the organization can confirm that its procedures match what the provider actually does.

One policy, system-specific procedures

An organization can issue one organization-wide contingency policy and maintain separate procedures for each system or group of systems. The policy sets the common rules, roles and review triggers, while each procedure covers the recovery steps, backup schedules and owners for its system. Confirm that every system in the boundary has a procedure that traces back to the policy, and that procedures are reviewed when the policy changes.

How an assessor tests CP-1 with examine and interview methods

This table walks through how an assessor works through CP-1 using the examine and interview methods in SP 800-53A, one test area at a time. Read each row as a question the assessor will ask, the evidence to have ready, and the gaps that most often delay a finding from closing. The main takeaway is that a policy on paper rarely passes on its own; the assessor will check that the named official, distribution, review cycle and staff knowledge all match what the document says.

Test area	What the assessor examines or interviews	Evidence requested	Common findings
Contingency planning policy	Examines whether a documented contingency planning policy exists, covers purpose, scope, roles and compliance, and fits the organization's risk management approach.	Approved policy document with version, approval date, owner and scope statement naming the systems it covers.	Policy is a generic template, does not name the systems in scope, or is unsigned and undated.
Implementing procedures	Examines whether procedures turn the policy into steps for planning, backup, testing and recovery, and whether they are aligned with the policy.	Procedure documents for contingency planning, backup and recovery, each linked to the policy section it implements.	Procedures exist for some systems only, or describe a process the team does not follow in practice.
Distribution to defined roles	Examines the distribution list and access records, and checks that the roles the organization defined actually receive the policy and procedures.	Distribution records or acknowledgments, role list from the organization's definition, and access logs for the document repository.	Distribution is to a mailbox or a team name, with no record that named roles received or accessed the documents.
Designated official	Examines the document that names the official who manages the policy and procedures, and whether that person has authority and time to do it.	Signed designation memo or role description, plus evidence the official approved the most recent revision.	Official is named in the policy but has left the organization, or the role is shared with no clear owner.
Review frequency	Examines whether the organization defined how often the policy and procedures are reviewed and updated, and whether reviews happened on that schedule.	Review log with dates, reviewer names, and the recorded outcome of each review, such as no change or revision.	Review frequency is defined but no review record exists, or reviews are logged without any substantive comment.
Review after defined events	Examines the events the organization defined as triggers for an update, such as system changes, incidents or organizational changes, and checks that updates followed them.	List of trigger events, change tickets or incident records, and matching revision history showing an update after each trigger.	Triggers are defined but a major system change or incident passed with no update to the policy or procedures.
Version control and change history	Examines how revisions are tracked, who approved them and whether earlier versions can be retrieved for the period under review.	Revision history showing what changed, when and by whom, and retained prior versions.	Edits overwrite the previous version, so the assessor cannot see what the policy said during the review period.
Interviews with contingency planning personnel	Interviews staff who hold contingency planning responsibilities to confirm they know the policy, their duties and where the procedures are kept.	Interview notes, and optionally a short walkthrough showing staff locate the current policy and procedures.	Staff describe a process that differs from the written procedures, or do not know the current version exists.

How to write, approve and distribute the contingency planning policy

This sequence turns CP-1 from an intention into a governed document set: a named owner, a defined review cadence, a written policy with implementing procedures, formal approval, and records showing the right people received and acknowledged it. Each step ends with an artifact an assessor can examine.

Assign the designated official
Name one senior role, not a team, as the official who manages the contingency planning policy and procedures. The sponsoring executive, usually the CIO, CISO or head of operations, should confirm the appointment in writing and state the official's authority to approve procedures and request resources. Record the role, the named individual and the date of appointment in the governance register. The step is complete when an assessor can trace from the policy to one accountable person without asking who owns it.
Set the review frequency and trigger events
CP-1 requires the organization to define how often the policy and procedures are reviewed and which events force an earlier review. Choose these parameter values yourself, based on your risk appetite, regulatory obligations and system change rate, and document the rationale. Typical triggers to consider include a major system change, a real or tabletop-revealed recovery failure, a change in the organization's essential functions, and a change in applicable law or contract. Output: a parameter table approved by the designated official, which the policy will cite verbatim.
Draft the policy and implementing procedures
Write the policy at the level of purpose, scope, roles, principles and compliance expectations, then write procedures that describe how each contingency activity is carried out. Map each procedure to the controls it supports, including CP-2 contingency plans, CP-3 training, CP-4 testing, CP-9 backup and CP-10 recovery, so that gaps are visible. Where a procedure depends on a system owner's own runbook, reference it rather than copy it. Output: a draft policy, a set of procedures and a role-to-procedure map showing who performs and who approves each one.
Obtain formal approval
Route the draft through the reviewers your governance model requires, which commonly include the designated official, the system owners whose systems are in scope, legal or compliance, and business continuity or operational resilience leads. Record each reviewer's comments and the resolution of each one. The approval is complete when the policy carries a version number, an effective date, the approver's name and the approval record is stored with the document. Confirm with your own auditor which approval evidence they expect.
Distribute to defined roles with acknowledgment
Publish the approved policy and procedures to the defined roles, such as system owners, operations staff, incident managers, backup administrators and recovery leads, and to any third party that performs contingency functions under contract. Use a document system that keeps version history and can show who accessed which version. Collect written or electronic acknowledgments and keep a distribution log that matches the role-to-procedure map. Output: the distribution log, the acknowledgment records and a list of any roles that have not yet responded.
Schedule review and track changes
Put the defined review frequency and trigger events into the organization's calendar and change process so that reviews happen without relying on memory. At each review, confirm that the policy still matches the current contingency plans, backup schedules and recovery objectives, record any changes as a new version, and repeat distribution and acknowledgment for affected roles. Output: a review log with dates, reviewers, findings and the version history. An assessor will look for evidence that the cycle has actually run, not only that it is written down.

Evidence that passes CP-1 and how to keep it current between audits

An assessor testing CP-1 Policy and procedures wants to see a policy that exists, is approved, reaches the people who hold contingency roles, and is reviewed on schedule and after significant events. The cards below cover the six items that usually carry that proof, with a refresh habit for each so the record stays current between audits without a rebuild.

Approved contingency policy

The contingency planning policy itself, with a version number, an owner, an approval date and the name of the approving official. The assessor checks that the document covers purpose, scope, roles, compliance and coordination with the rest of the organization, and that the version in circulation matches the approved one. Between audits, record each approval as a new version rather than editing the approved copy in place, and confirm that the policy still references current role titles.

Implementing procedures

Step-by-step procedures that turn the policy into work, such as how backups are scheduled, how restores are requested and how the contingency plan is activated. Assessors compare these against the policy and against what staff actually do during an interview. Keep each procedure tied to a named owner and a review date, and check at each review that tool names, backup schedules and escalation paths still match the running environment.

Distribution and acknowledgment records

Proof that the policy and procedures reached the defined roles, typically a distribution list plus signed or electronically recorded acknowledgments with dates. Assessors sample named individuals who hold contingency responsibilities and ask whether they have seen the current version. Refresh this record whenever a role changes hands, and send the new version to affected staff so acknowledgments match the current revision.

Designated official appointment

A written appointment naming the official who manages the policy and procedures, with the scope of that authority and the date it took effect. Assessors confirm the appointee is the person who answers questions about the policy during interviews. When staffing changes, update the appointment record first, then confirm that the policy's ownership field and any delegation notes name the same person.

Scheduled and event-driven review records

Dated review entries showing that the policy and procedures were examined at the frequency the organization defined, and again after events that the policy names as triggers, such as a failed restore test, a major system change or a relocated site. Assessors look for a review that found something or recorded why no change was needed. Keep a review log with the trigger, reviewer, outcome and any change made, so the next audit can follow the trail without reconstruction.

Procedure to plan and backup mapping

A traceability table linking each procedure to the contingency plan (CP-2), backup (CP-9) and recovery (CP-10) controls it supports, and to the systems in scope. Assessors use it to test whether the policy drives real content rather than sitting alone. Review the mapping whenever a system is added, retired or re-hosted, and flag any procedure that points to a plan section or backup job that no longer exists.

What meeting CP-1 costs in staff time, tooling and review

This table compares the main cost components of meeting CP-1, showing who does the work, whether each cost is one-time or recurring, and what drives it up or down. Because CP-1 has no control enhancements, the largest swing usually comes from how many systems and procedures the policy must cover, so use the drivers column to scope a written quote.

Cost component	One-time or recurring	What drives it and how to keep it down
Drafting the policy and procedures	One-time, then updated	Driven by the number of systems and contingency procedures in scope. Keep the policy at the level of roles and requirements, and put system-specific steps in procedures that can change without a full policy rewrite.
Legal or management approval	One-time per version, recurring at each review	Driven by how many approvers sign off and how many review cycles run. Agree the approval chain and the review trigger in writing before drafting starts so each revision does not restart the process.
Distribution and acknowledgment tracking	Recurring	Driven by headcount, contractor use and staff turnover. Tie acknowledgments to onboarding and role changes so tracking is an extension of existing HR and access processes.
Scheduled and event-driven reviews	Recurring	Driven by the review frequency the organization defines and by how often systems change or incidents occur. Fewer, well-documented triggers reduce unplanned review work.
Tooling for version control and access	Recurring license or hosting cost, or one-time setup for self-hosted tools	Driven by the number of editors, readers and approvers. Self-hosted open-source wikis such as XWiki (LGPL-2.1-or-later) and BookStack (MIT) keep version history and role-based permissions without a per-seat license line, but hosting, patching and backup of the tool become internal or contracted work to confirm.
Independent assessment preparation	Recurring at each assessment cycle	Driven by how easily an assessor can find the current policy, prior versions and approval records for the assessment window. Keep these in one versioned location, and confirm with the assessor which evidence format they accept.

How XWiki and BookStack keep policy versions and access controlled

CP-1 expects a contingency planning policy and procedures that are documented, distributed to the right roles and kept current. Two self-hosted documentation platforms can hold that material, and the cards below show what each one offers for version history and access control. Neither tool is a compliance product, so the organization still owns its policy content and must confirm that the platform meets its own retention and access rules.

XWiki version control for policy history

XWiki keeps every change to a page under version control, recording what changed, when and by whom. Users can compare any two versions and roll back to an earlier one. For CP-1, this is the evidence an assessor usually asks for: a dated trail showing when the contingency planning policy and procedures were reviewed, updated and approved, and by whom. Confirm that the page history cannot be purged by users with editing rights and that the retention period matches the organization's own record-keeping rules. The XWiki project is licensed under LGPL-2.1-or-later, so review the license terms with counsel before embedding it in a product.

BookStack roles for controlled distribution

In BookStack, user abilities come from the roles assigned to each account. Permissions can then be overridden for a specific role at the shelf, book, chapter or page level. For CP-1, this lets the organization publish the contingency policy to the roles that must read it, such as recovery leads and system owners, while restricting edits to the designated policy owner. Check that the role model reflects who actually holds contingency responsibilities, and that access reviews are scheduled and recorded. BookStack is released under the MIT license, which is permissive, but the organization should still confirm the terms for its own use.

Assigning a policy owner

CP-1 requires a designated official to manage the policy and procedures. Neither tool assigns that accountability for you. In either platform, set the owner as the only account able to approve publication, and record that appointment in a dedicated page that links to the policy. Ask the assessor how they want the designation evidenced, for example a signed appointment memo stored alongside the policy. This keeps ownership clear when staff change roles.

Confirming the platform meets your requirements

Before relying on either tool for CP-1 evidence, test the controls in your own environment. Confirm that the version history survives backups and restores, that exports preserve timestamps and authorship, and that administrator actions are logged. Document the results in the system security plan. Remember that a tool that stores documents does not itself satisfy the control; the organization must still review, approve and distribute the policy on the defined schedule.

Who owns CP-1, what a partner can prepare and where the auditor stops

CP-1 asks for a contingency planning policy and implementing procedures that are distributed to defined roles, managed by a designated official, and reviewed on a defined frequency and after defined events. Those decisions belong to your organization. Your leadership decides who holds the policy, what it covers, and how it connects to the business continuity and disaster recovery work that already exists.

Designated official: the person accountable for the policy and for confirming that procedures are followed and kept current.
Policy owner: the person who maintains the document day to day, tracks review dates and records changes.
Approvers: the executives or governance body who formally adopt the policy and any material revision.
Procedure recipients: the system owners, operations staff and recovery leads who must read and act on the procedures.

Confirm that each role is named in writing, that the designated official has the authority to enforce the policy, and that the review frequency and triggering events are defined by your organization rather than left to the implementation team.

Where CP-1 policies usually fail review and how to close each gap

A CP-1 policy is usually written, approved and filed, then found wanting when an assessor asks who owns it, who received it and whether it matches what the team actually does. The gaps below recur across organizations, and each one has a remedy that can be checked before the assessment starts.

No named official owns the policy

The policy exists, but no individual is recorded as responsible for keeping it current, answering questions about it and approving changes. CP-1 expects the policy to be managed by a designated official, so an assessor will look for a name, a role and an approval record. Close the gap by naming one accountable official in the policy itself, giving that role authority to approve procedures, and recording the appointment in the governance documents. Confirm the named person still holds the role at each review.

Distribution is undocumented

Staff with contingency roles may never have received the current policy, or nobody can show that they did. CP-1 requires the policy and procedures to be disseminated to defined roles, so the assessor will ask for the distribution list and proof of receipt. Keep a distribution record that lists each defined role, the version sent, the date and how acknowledgment was captured. Publish the policy in one location that role holders are directed to, and keep the acknowledgment with the version it covers.

Reviews are never scheduled or triggered

The policy carries a review date that passed years ago, or no date at all. CP-1 expects review and update at a defined frequency and after defined events, such as a significant system change, a failed test or a relocated site. Write both triggers into the policy, add the review to the organization's compliance calendar, and record each review with its outcome, including reviews that result in no change. An assessor will compare the recorded reviews against the frequency written in the policy.

Procedures contradict the policy

The policy sets a backup frequency, recovery approach or testing cycle that the procedures do not match, or the runbooks were written by a different team and never reconciled. An assessor who reads both documents side by side will find the mismatch quickly. Map each policy statement to the procedure that implements it, correct the conflicting document, and note the reconciliation in the revision history. Ask the people who run the procedures to confirm the steps still match the systems in production.

Policy not linked to plans and backups

The contingency policy sits in one folder while the contingency plans, backup procedures and recovery runbooks sit in others, with no cross references between them. CP-1 is the policy that the other CP controls implement, and the related controls in the catalog include PM-9, PS-8 and SI-12. Add a document index to the policy that points to each contingency plan, backup procedure and recovery runbook, and check that each linked document cites the policy version it implements.

Version history lost in shared files

Edits made in shared office files overwrite each other, and nobody can show which version was approved or who changed a recovery step. An assessor will ask for the approved version in force on a given date, and a shared file often cannot answer that. Hold the policy and procedures in a documentation platform that keeps version history, records author and time for each change, and allows comparison and rollback. Self-hosted wiki and documentation tools with version control, such as XWiki and BookStack, can keep this history inside the client's own infrastructure. Confirm each tool's retention and export behavior before relying on it as evidence.

How much effort CP-1 takes and whether the team can do it alone

How much effort does CP-1 take compared with the other contingency planning controls?

CP-1 is usually one of the lighter contingency planning controls in effort, because it asks for a policy and procedures rather than a tested plan, exercised backups or alternate sites. Its work is mostly drafting, approval and assigning owners. The heavier CP controls, such as CP-2 contingency plans, CP-4 testing and CP-9 system backup, depend on system-specific detail, evidence from exercises and technical configuration. CP-1 is still a dependency for them: the policy sets the frequency, roles and review cycle those controls reference. Expect the effort to be front-loaded, then mostly maintenance. Confirm this against your own baseline, since SP 800-53B selects CP-1 for the low, moderate and high baselines and the assessment procedure sets the depth of evidence an assessor will examine.

Can one contingency planning policy cover several systems?

Yes, and most organizations are better served by one enterprise policy with system-level procedures. The policy states the organization-wide rules: who owns contingency planning, how plans are prepared, how often they are reviewed and what triggers an update. Each system then needs its own contingency plan under CP-2, with recovery objectives, roles and contacts that differ by system. Where systems have very different impact levels or hosting models, you may need separate procedures or appendices while keeping one policy. Decide the scope explicitly in the policy text, including which systems, business units and third-party hosted services it applies to, so an assessor can match the scope to your inventory.

How long does a first CP-1 policy and procedures set usually take?

The duration depends on the drivers, not on a fixed number, and no figure is given here. The main drivers are how many business units must agree on roles, whether a contingency planning policy already exists and how well it matches current practice, how many systems the procedures must cover, and how quickly the approving official can review drafts. Approval routing and the number of revision cycles often take longer than the writing itself. Ask any provider for a schedule that lists the review steps, the owners of each decision and the dates the drafts are due, and compare it with your governance calendar before work starts.

What does the work need from our staff?

The work needs time from a small set of people who can make decisions, not a large team. Typically this includes a designated official for the policy, IT operations leads who know how backups and recovery are run, a business continuity or risk lead who can confirm essential functions, and someone from legal or HR who checks distribution and acknowledgment requirements. Each reviewer should expect a few focused sessions and a review of drafts. The most common delay is waiting for a decision on who owns the policy or how often it is reviewed. Name those decisions up front so the policy does not stall at the approval stage.

Can a small team write CP-1 without outside help?

A small team with a clear owner and some experience in policy writing can usually produce CP-1 without outside help, provided they have the time and the authority to approve it. The harder parts are consistency and evidence: the policy must match what IT actually does, the procedures must name real tools and roles, and the review history must show the policy was distributed and updated. Teams without prior audit experience often miss the evidence trail, not the text. Outside help is most useful when the policy has to align across several frameworks, when the internal owners disagree or when the team has no capacity to run the review cycle.

What does a partner add, and what does the auditor still do?

An implementation partner can prepare the policy and procedures, map the document to your systems, set up document control and collect the evidence an assessor will examine. DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, and can prepare systems and evidence for an assessment. DeployOpen does not issue audit reports, attestations or certifications. The organization still owns the policy and its approval. An independent assessor performs the assessment against the SP 800-53A procedures and reaches its own determination. Make that split explicit in any proposal so no one assumes the partner has validated the control.

What should we ask for in a written quote for CP-1 work?

A written quote should follow from a written scope, and should list the deliverables, the systems and business units covered, the defined parameters you must choose, and the review rounds included. Ask for the roles and time expected from your staff, the acceptance criteria for each deliverable and what happens if the scope changes. Confirm which items are one-time, such as the first policy and procedures, and which recur, such as annual review support. Ask how evidence will be stored, which document control tool will hold it and who keeps it current after handover. Finally, confirm that the partner does not issue assessment results and that the assessor is named as a separate party.

How often must the CP-1 policy and procedures be reviewed?

CP-1 requires the policy and procedures to be reviewed and updated at a frequency your organization defines, and also after defined events such as significant system changes, incidents or organizational changes. The control leaves both parameters to you, so the frequency you choose must be realistic and then followed. Record the chosen interval in the policy, assign the review to a named official and keep the review record as evidence. Tools such as XWiki and BookStack can keep version history and permissions, which helps show who changed what and when, but you still need to confirm that they fit your environment and records requirements.

How DeployOpen prepares CP-1 policy and evidence for a self-hosted environment

DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, and prepares the contingency planning policy, procedures and records that CP-1 asks for. The organization owns the policy and approves it, while an independent assessor tests it.

How we scope

Engagements are fixed-scope, with the CP-1 deliverables agreed in writing before work starts.
The scope names which systems, baselines and contingency roles the policy and procedures must cover.
We confirm who owns the policy, who approves it and which review frequency and triggering events apply.

How we build

We draft the contingency planning policy and implementing procedures for your review and approval.
We map the policy roles to your existing backup, recovery and incident owners in the self-hosted platform.
We set up document version control so changes to the policy and procedures are recorded with dates and authors.

How we hand over

You receive the approved policy, procedures, role assignments and a log of review dates and revisions.
We provide a mapping from each CP-1 assessment objective to the document or record that satisfies it.
Your team walks through the evidence set so it can answer assessor interview questions on CP-1 directly.

How we support

Ongoing support, upgrades and periodic policy reviews are available as a retainer after handover.
Retainer work can update the policy when systems change, when baselines are revised or when new contingency roles appear.
An independent auditor or assessor, not DeployOpen, decides whether the CP-1 evidence meets the requirement.