CP-2 Contingency plan: requirements and evidence

What the CP-2 contingency plan must contain and why assessors start there

When an authorizing official, customer or auditor asks for your contingency plan, they want a written, current plan for the system that says how essential functions keep running during a disruption and how the system returns to full operation. CP-2 in NIST SP 800-53 Rev. 5 requires that plan. In plain terms, the plan must name the essential functions the system supports, set recovery objectives and restoration priorities with the metrics used to judge them, list the roles and contacts who act during an event, and describe how the organization continues operations and restores the system fully. The plan must also be approved, distributed to the people who need it, coordinated with incident handling, reviewed at a defined frequency, updated with lessons learned and protected from unauthorized disclosure and modification. Assessors start here because every later recovery control, including alternate sites, backup and reconstitution, depends on a plan that defines what must be recovered, in what order and by whom.

CP-2 is selected in the Low, Moderate and High baselines of SP 800-53B Release 5.2.0, so any system that needs those baselines needs the plan. The privacy baseline does not select CP-2, so a system categorized only against the privacy baseline is not required to meet it on that basis. Moderate and High systems also pick up enhancements: CP-2(1) for coordination with related plans and CP-2(3) for resuming mission and business functions apply at Moderate and High, CP-2(8) for identifying critical assets applies at both as well, and CP-2(2) and CP-2(5) apply only at High. Confirm the enhancement set against the baseline profile for your impact level before scoping evidence, because the selection drives how much the plan must show. Plans most often fail on currency rather than existence. A document last reviewed under an earlier architecture, with contacts who have left and recovery priorities that no longer match the system, will not survive an assessment interview. Before the assessment, check that the plan matches the current system boundary and that its review dates and change history can be shown.

Which systems, teams and third parties a CP-2 plan must cover

Before anyone writes a contingency plan, the scope has to be fixed: which system the plan covers, which impact level selects the baseline, and who else the plan depends on. Each card below is a decision or dependency that changes the size and content of the CP-2 work.

Draw the system boundary first

A CP-2 plan covers one system, so the boundary decides which components, data stores, interfaces and admin paths the recovery steps must reach. Map the boundary against the system security plan and list every component the essential functions rely on, including identity, DNS and logging. Check that the boundary matches the one used for backups under CP-9, because a plan that restores a system whose backups sit outside the boundary will not work in practice.

Set the impact level and baseline

The impact level of the system selects its SP 800-53B baseline, and CP-2 is selected at low, moderate and high. The plan does not apply to the privacy baseline. Confirm the impact level with the system owner and record it in the plan, because the enhancements that follow depend on it. A system that moves from moderate to high after a change to its data or mission must have its plan reviewed against the higher baseline.

Coordinate with related plans at moderate and high

CP-2(1) requires the contingency plan to be coordinated with other related plans, such as incident response, business continuity and disaster recovery plans. CP-2(3) requires the plan to resume mission and business functions, and CP-2(8) requires the organization to identify critical assets. These three apply at moderate and high, so a moderate system needs them in its plan from the first version. List each related plan by name, owner and version, and confirm that the recovery order does not conflict with the incident handling steps.

Add capacity and continuity at high only

CP-2(2) asks the plan to address capacity planning so that essential functions continue during disruption, and CP-2(5) asks the plan to continue mission and business functions with minimal or no loss. These two enhancements apply only at the high baseline. Confirm the required capacity with the owners of the workloads, and document the minimum service level the plan must hold while the primary environment is down. Capacity figures belong to the system owner, not to the plan author.

Name the teams and their contacts

The plan must name the roles that execute recovery and the people who fill them, including platform engineering, application owners, security operations, legal, communications and the executives who approve decisions. Shared on-call rosters and out-of-hours contacts are common gaps. Test each contact path before the plan is approved, and record how the list is kept current when staff change roles.

Cover third-party hosting and SaaS dependencies

Where the system runs on a cloud provider, a colocation facility or a SaaS product, the plan must state what the provider restores, what the organization restores and what it must obtain from the contract. Check the provider's recovery commitments and support escalation paths against the recovery objectives in the plan. Where a provider's own continuity documents are needed as evidence, request them during procurement rather than during the assessment.

Decide which plans are shared or inherited

When several systems rely on one platform, such as a shared identity service or hosting cluster, the organization may maintain one plan for the platform and reference it from each system plan. Decide which plan is the authoritative record, who owns it, and how a system-level plan records the inherited parts. Shared plans reduce duplicated effort but fail quietly when a dependency changes, so assign a review trigger to each inherited element.

How an assessor tests CP-2 with examine, interview and test methods

This table maps each SP 800-53A assessment method to what the assessor does for CP-2, the evidence it produces and the findings that usually follow. Read it as a preparation checklist: each row is a test the assessor will run, so each row is a question your team should be able to answer with a document or a person.

Assessment method	What the assessor does for CP-2	Evidence that passes	Typical finding if it fails
Examine: the plan	Reads the contingency plan and checks that it names essential functions, recovery objectives, restoration priorities and metrics, roles and contacts, and continuity and full restoration steps.	A current plan that covers each of these elements and records an approval date and approver.	Plan omits recovery priorities, or recovery objectives do not match the system's stated impact level.
Examine: review and update records	Checks evidence that the plan was reviewed at the defined frequency and updated after changes, tests and incidents.	Dated review records, change history and a lessons-learned entry linked to a test or real event.	No review evidence since the last major system change, or lessons-learned updates are missing.
Interview: contingency planning personnel	Asks the people who own recovery how they would execute the plan, who they would call and which systems come back first.	Consistent answers that match the written plan, with named owners who can explain their steps.	Staff describe a different restoration order, or the named owner has left the organization.
Interview: incident handling personnel	Asks incident responders how the contingency plan is invoked during an incident and who makes that decision.	Documented handoff between the incident response plan and the contingency plan, understood by both teams.	Plans are not coordinated with incident handling, so responders and recovery teams work from different priorities.
Test: plan development and approval process	Observes how the organization drafts, approves and distributes the plan and checks that distribution reaches the people who need it.	Approval workflow, distribution list and access records showing the current version reached recovery roles.	Unapproved drafts in circulation, or copies held by people outside the recovery team.
Test: review, update and protection process	Tests whether the process for review and update runs as written and whether the plan is protected from unauthorized change or disclosure.	Version history showing who changed what and when, with access restricted to authorized editors.	Stale contacts and phone numbers, or an editable plan shared without access control.
Determination statements	Assessor records a finding for each of the 24 CP-2 determination statements in SP 800-53A Rev. 5.	Each determination statement has a supporting artifact or interview record that the assessor can cite.	Gaps cluster in the update and coordination statements, which are often where plans fall behind.
Enhancements in scope	Checks CP-2(1), CP-2(3) and CP-2(8) at moderate and high impact, and CP-2(2) and CP-2(5) at high impact.	Documented coordination with related plans, resumption steps, capacity planning and a list of critical assets.	High-impact systems without capacity planning or critical asset identification in the plan.

How to write, approve and maintain a CP-2 plan step by step

This sequence moves from defining what the system must keep running to a plan that is approved, distributed, tied to incident handling and kept current. Each step produces a document or record that an assessor can examine.

Confirm essential functions and system boundary
The system owner and business leads list the mission and business functions the system supports and decide which of them are essential. Security and infrastructure staff then fix the system boundary, including components, hosting locations, interfaces and third-party services the functions depend on. The output is a scoped inventory of essential functions and the components that support them. The step is done when the business owner signs off that nothing essential sits outside the boundary.
Set recovery objectives, priorities and metrics
For each essential function, the business owner and the technical team agree a recovery time objective, a recovery point objective and the order in which functions must come back. They also define the metrics used to judge recovery, such as data loss tolerance or the share of functions restored. Confirm these values against the backup and recovery design, because CP-9 and CP-10 must be able to meet them. The output is a priority table with objectives and metrics that the plan can cite.
Name roles, responsibilities and contacts
Assign a named owner for each contingency role, including plan coordinator, recovery leads for infrastructure and applications, communications, and decision authority during an outage. Record a primary and alternate contact for each role with current phone and email, and state who can declare a disruption and invoke the plan. Ask the people named to confirm the assignment in writing. The output is a roles and contacts register that is kept current outside the plan document itself, since contact details change more often than the plan text.
Document continuity and full restoration procedures
Write the operational steps for two phases. Continuity procedures explain how essential functions keep running during the disruption, including workarounds and any alternate site or service the organization relies on. Restoration procedures explain how the system returns to normal operation, referencing the recovery steps in CP-10 and the backup sources in CP-9. Reference the technical runbooks rather than copying them. The output is a procedure set that a trained responder could follow without the original author present.
Coordinate with incident handling and obtain approval
Map the handoffs between the contingency plan and the incident response plan, covering who decides whether an event is a security incident, when recovery begins, how evidence is preserved and which related plans, such as the alternate storage and processing site plans, are invoked. Then route the complete draft to the officials who own the system and the risk, and record their formal approval with date and version. The output is an approved plan with a documented incident handling interface and a signed approval record.
Distribute the plan to the people who need it
Send the approved plan to every named role and store copies where responders can reach them during an outage, including offline copies if the primary repository depends on the affected system. Record who received which version and when. Confirm that the protection measures the plan requires, such as restricted access and controlled edits, apply to every copy, because the plan itself describes weaknesses that should not be widely exposed. The output is a distribution record that shows each recipient and version.
Schedule review and record updates
Set the review frequency in the plan and the events that trigger an unscheduled review, such as significant system changes, organizational changes or lessons learned from a test or real event. Each review checks the essential functions, objectives, roles and contacts, and procedures against the current system. Record each change with the reason, the reviewer and the new version, and feed lessons from CP-4 testing into the update. The output is a version history that shows the plan stayed current, which assessors will examine.

Why the CP-2 plan depends on backup, recovery and testing controls

CP-2 is the governing document of the contingency program, and the other controls in the family supply the mechanisms it describes. The plan names essential functions, recovery objectives, restoration priorities and metrics, but it does not itself back up data, switch to a standby site or rebuild a server. Those capabilities sit in CP-3 (training people to act on the plan), CP-4 (testing it), CP-6 and CP-7 (alternate storage and processing sites), CP-8 (alternate telecommunications), CP-9 (system backup) and CP-10 (recovery and reconstitution). The SP 800-53 Rev. 5 catalog lists 25 related controls for CP-2, including CP-11 and CP-13, so an assessor will expect the plan to point to the mechanisms that deliver it, not describe them in isolation. Confirm the full list against the catalog entry for CP-02 before you build your traceability matrix.

The most common gap is a recovery time or recovery point objective in the plan that no backup or restore record can support. Read each objective in the plan against the evidence from CP-9 and CP-10. If the plan says a database must return to a known state within a stated window, the backup schedule, retention and restore logs must show that a restore from that point has been performed within that window. Open-source tools can generate this evidence. Bareos keeps a catalog of backed-up files and restores from the current backup or from one before a given date and time, and restic's check command with --read-data or --read-data-subset reads pack files back to confirm stored data is unmodified. Ask your team to name which tool and which job records prove each objective.

CP-2(1) requires the plan to be coordinated with related plans, such as the incident response plan under IR-8, and CP-2(3) and CP-2(5) require the plan to resume mission and business functions, with CP-2(5) applying at the high baseline. These enhancements link the plan to the rest of the program. A decision to make now is which restore order and dependencies the plan will use for resumption, and whether the incident response team can start a recovery without waiting for a separate approval. Test that handoff during a CP-4 exercise, and record the outcome as evidence for both CP-2 and CP-4. Confirm with your assessor how they expect the cross-references to be documented, because SP 800-53A examine and interview methods will check the plan against what staff actually do.

Evidence that passes a CP-2 review and how to keep it current

An assessor testing CP-2 looks for a contingency plan that exists, is current and is used. The artifacts below show that chain from approval through coordination and protection, and each one decays unless someone owns its refresh schedule between assessments.

Approved plan with version history

Assessors ask for the plan in its current approved form, plus the record of who approved each version and when. Check that the plan names its essential functions, recovery objectives, restoration priorities and metrics, and that the approval date matches the latest revision. A wiki with page-level version control, such as XWiki, can keep every change with its author and timestamp, and lets you compare two versions side by side when an assessor asks what changed after an incident. Confirm that the plan's last approved version is the one people actually open during a disruption.

Distribution records

CP-2 expects the plan to reach the people who must act on it. Keep a dated list of recipients, their roles and the format each received, such as a read-only copy in the wiki or an offline printout stored off-site. Reconcile this list against staff changes each quarter so that departed employees lose access and new contingency role holders receive the current version. An assessor who finds a recipient list older than the latest approved version will question whether distribution happened at all.

Role and contact lists

The plan must name the people and teams responsible for recovery, along with their alternates and escalation paths. Store contact details in one maintained roster and record the date each entry was last verified by a call or message, not just by a document edit. Include vendors, cloud providers and alternate site contacts. Ask yourself whether the on-call contact for each essential function still works, because a stale phone number is a common finding during interviews with contingency personnel.

Review and update logs

Keep a log that records each scheduled review, its reviewer, the date, the changes made or the reason none were needed. The review frequency should be set in your own organization-defined parameter and the log should show that the cadence was met. Changes triggered by system changes or significant events should appear as separate entries so an assessor can trace each update to its cause. Missing entries for a review that was skipped are easier to explain than entries that look backdated.

Lessons-learned entries

Plans must be updated with lessons learned from testing and real events. Record each exercise or incident with the gap found, the owner of the fix and the plan section it changed. Link each entry to the revision that incorporated it. The key check is whether a lesson from the last test appears as a changed step in the next approved version. Entries that never reach the plan show the update loop is broken.

Coordination with incident response

CP-2 requires the plan to be coordinated with incident handling, and the plan should name the trigger points where an incident becomes a contingency event and the reverse. Keep a cross-reference table between the contingency plan and the incident response plan, with the shared roles and handoff steps. Review it whenever either plan changes, and record that review in the same log as the contingency plan. An assessor will often test this by picking one incident scenario and tracing it through both documents.

Protection and access controls on the plan

The plan describes how to restore systems, so it must be protected from unauthorized disclosure and modification. Restrict edit rights to named plan owners and read rights to people with contingency roles. Role-based permissions in a tool such as BookStack can be set at the shelf, book or page level, which keeps the plan separate from general documentation. Export access logs for the plan and confirm that an offline copy exists for the case where the platform itself is unavailable.

What meeting CP-2 costs in tools, effort and outside review

This table breaks down the cost components of producing and maintaining a CP-2 contingency plan, marking which items are one-time and which recur. Use it to see who is paid for each item and which sizing drivers move the total, then ask every bidder for the same line items in a written quote.

Cost component	Who is paid or who does the work	One-time or recurring	What drives it up or down
Initial plan development and workshops	Internal engineering and business-continuity staff, plus an implementation partner if engaged for plan preparation	One-time, then revised at each review	Number of systems in scope, number of essential functions, and how many business owners must agree on recovery priorities
Recovery objectives and dependency mapping	Business owners, system owners and architects	One-time, refreshed when systems change	Count of interdependent systems and whether recovery objectives already exist in a business impact analysis
Documentation tooling and version control	Software license spend or self-hosted open-source platform setup and hosting	Tooling setup is one-time; hosting and administration recur	Whether an existing wiki or document system is reused, and whether the plan needs approval workflows and access controls
Roles, contacts and distribution	Operations and HR staff who maintain contact lists and distribution records	Recurring, tied to staff turnover	Size of the response team, number of vendors with contact roles, and frequency of staffing changes
Coordination with incident handling	Incident response leads and continuity owners working through joint procedures	One-time design, recurring during reviews	Number of overlapping incident and continuity procedures and how often they are exercised
Recurring review and update effort	Plan owner, system owners and reviewers, sometimes an outside reviewer	Recurring at the review frequency the organization sets and after significant changes	Frequency the organization defines, system change rate, and lessons learned from tests or incidents
Testing support and external review	Specialist testers or an independent reviewer, if engaged	Recurring, usually tied to contingency plan testing (CP-4)	Scope of tests, number of enhancements selected, and whether tests are facilitated or run internally
Assessor sampling time	Independent assessor, paid by the organization; DeployOpen does not issue assessment results	Recurring at each assessment cycle	Number of systems sampled, evidence quality, and how quickly plan versions and review records can be produced
Enhancement scope	Engineers and planners for each enhancement selected	One-time build, recurring operation	Moderate baseline adds CP-2(1), CP-2(3) and CP-2(8); high baseline also adds CP-2(2) and CP-2(5)

Who writes the plan, who prepares evidence and who assesses it

Your organization owns CP-2. Accountable officials must approve the contingency plan, decide which functions are essential and set the recovery objectives and restoration priorities that the plan states. Those decisions depend on business impact, so they belong to business owners and the system owner, not to the people who configure backups. Your staff also maintain the plan over time: they review it at the frequency you define, record lessons learned from exercises and real incidents, and keep the plan current when systems change.

Essential functions and priorities: Business and mission owners name what must continue, in what order and to what level of service.
Roles and contacts: Named individuals, alternates and escalation paths, kept current outside the system that may be down.
Approval and distribution: Evidence that the accountable official approved the plan and that the right people received it.
Coordination with incident handling: Agreed handoffs with the incident response plan, so a disruption caused by an attack follows one decision path.
Review and protection: A documented review cycle, change history and access restrictions on the plan itself.

Before any outside party starts work, confirm which of these decisions your leadership will make personally and which can be delegated in writing.

Where CP-2 plans usually fail review and how to close each gap

Assessors reviewing CP-2 tend to find the same weaknesses: plans that describe functions without measurable targets, contacts nobody has checked, and plans that were never tested or linked to incident handling. Each card names one gap, why it matters for the contingency plan, and the check that closes it.

Essential functions without measurable recovery objectives

A plan that lists essential functions but never states how fast each must return, or how much data loss is tolerable, gives an assessor nothing to test against. CP-2 expects recovery objectives, restoration priorities and metrics to be identified. For each essential function, record the recovery time objective, the recovery point objective, the priority rank and the system components it depends on. Close the gap by checking that every function in the plan maps to a number that the backup and recovery configuration can actually meet.

Out-of-date contacts and roles

Contact lists age quickly. Staff leave, on-call rotations change and vendor escalation numbers go stale, and the plan then fails at the first call. CP-2 requires roles and contacts to be named. Set a recurring check against the HR roster and the on-call schedule, record who verified each contact and when, and keep a backup copy of the list outside the systems the plan is meant to recover.

No evidence of review after incidents

Assessors look for proof that the plan changed after something went wrong. A plan with an approval date from years ago and no lessons learned is a weak plan. CP-2 requires updates driven by lessons learned and reviews at a defined frequency. Keep a dated review log, link each post-incident finding to a specific plan revision, and record who approved each change.

Plan not coordinated with IR-4, IR-6 and IR-8

A contingency plan and an incident response plan that disagree about who declares a disruption, who leads the response and when recovery starts cause delay in the first hours. CP-2 requires coordination with incident handling, and the related controls IR-4, IR-6 and IR-8 cover handling, reporting and the response plan itself. Walk through one disruption scenario with both teams, note every handoff and confirm that both documents name the same decision owner and escalation triggers.

Plan stored without access control

A contingency plan contains network diagrams, recovery sequences and contact details that help an attacker as much as a responder. CP-2 requires the plan to be protected from unauthorized disclosure and modification. Store the plan in a wiki or document system with role-based permissions, enable version history so every change is attributable, and restrict editing to named owners. Confirm that a read-only offline copy exists for use when the primary system is down.

Plan written but never exercised

A plan that has never been run is an untested assumption. Assessors ask for test records, findings and the corrective actions that followed. CP-2 is tested through CP-4, so the plan should be exercised at the frequency it defines, starting with a tabletop walkthrough and moving to restoration of a sample system. Record each exercise, its scope, the gaps found and the plan revision that fixed them.

Questions buyers ask about CP-2 cost, timing and effort

What work does CP-2 actually require from the organization?

CP-2 requires the organization to write, approve, distribute and maintain a system contingency plan. The plan has to name the essential functions the system supports, the recovery objectives and restoration priorities for them, the roles and contacts who act during a disruption, and how the system returns to full operation. It also has to be coordinated with incident handling, reviewed at a defined frequency, updated with lessons learned and protected from unauthorized disclosure and modification. The hard part is rarely the document itself. It is getting business owners to agree on which functions matter most and how long each can be unavailable, then keeping the plan consistent with the backup, recovery and testing work that CP-9, CP-10 and CP-4 require. Confirm the exact review frequency and parameter values with your assessor and in your own system security plan, since the organization sets them.

Can an in-house team write a CP-2 plan without outside help?

Usually yes, if the team has access to the system owners and the authority to set recovery priorities. The work is mostly coordination: a business impact view of each function, a technical inventory of the components that support it, and a clear set of contacts with decision rights during an outage. Teams that have run a real recovery exercise tend to write a usable plan faster than teams working from a template. Outside help makes sense when no one has owned contingency planning before, when several systems share dependencies that need mapping, or when the plan must be tied to an existing authorization package. Ask any partner to show how the plan will be kept under version control, reviewed on schedule and tested, because a plan that is written once and never exercised will struggle at assessment.

What drives the cost and effort of a CP-2 plan?

The main cost driver is how many systems and dependencies the plan covers. Effort rises with the number of essential functions, the number of teams who own pieces of the recovery path, the state of existing documentation and the number of interviews needed to confirm priorities. Cost also depends on whether the plan must align with other artifacts, such as a system security and privacy plan, an incident response plan or backup runbooks, and whether a partner must build the recovery procedures or only the plan narrative. Most of the spend is one-time for the initial plan and dependency mapping. Recurring spend covers annual or event-driven reviews, updates after system changes and exercises. When requesting a quote, ask for the list of systems in scope, the number of interviews, which recovery procedures are included, and what the review and update cycle covers.

How long does it take to get a CP-2 plan ready for an audit?

The honest answer depends on the system, its dependencies and how quickly owners can agree on priorities. NIST does not set a duration for implementing controls, and this page does not supply one. A reasonable approach is to treat the plan as ready for assessment only after its core content is approved, its contacts are confirmed, its recovery objectives match the backup and recovery design, and at least one exercise has produced documented results that led to updates. Ask a prospective partner to describe the stages of their plan, which dependencies must be confirmed before drafting starts and what they consider evidence of completion. Any timeline you receive should be tied to a written scope, not to a generic promise.

Can a partner write the CP-2 plan, and what does an assessor check?

A partner can help write and prepare the plan. The organization still owns the plan, its approval and the decisions about essential functions and recovery priorities. An independent assessor, following the SP 800-53A assessment procedures for CP-2, reviews the plan and the evidence behind it. Assessors look at whether the plan exists and is approved, whether it is distributed to the people who need it, whether personnel with contingency and incident handling roles can describe their responsibilities, and whether the organization can show reviews, updates and protection of the document. Only the assessor or certification body issues findings or attestations. A partner's role is to make the plan, its supporting records and its test results ready for that review.

How does the CP-2 plan change with the baseline level?

CP-2 is selected in the low, moderate and high baselines of SP 800-53B Release 5.2.0, but it is not selected in the privacy baseline. Its enhancements vary by level. CP-2(1), which coordinates the plan with related plans, CP-2(3), which covers resuming mission and business functions, and CP-2(8), which identifies critical assets, apply at moderate and high. CP-2(2), on capacity planning, and CP-2(5), on continuing mission and business functions, apply only at high. The base requirement is the same across levels, but a high-impact system needs deeper dependency analysis, capacity planning and continuity arrangements. Confirm the selected baseline and any tailoring with your authorizing official or governance owner before scoping the work.

Does CP-2 cost more if the plan must match several frameworks?

It can, mainly because each framework asks for overlapping evidence in different wording. NIST's crosswalk from CSF 2.0 to SP 800-53 Release 5.2.0 maps CP-2 to several CSF 2.0 subcategories, including ID.IM-04 and RC.RP-03, and NIST marks that crosswalk as not comprehensive, so it should be checked against your own requirements rather than treated as a complete mapping. Building one well-maintained plan with clear cross-references is usually cheaper than writing separate plans for each framework. Ask any partner how they will keep a single source of truth and how they will record which requirements each section satisfies.

How DeployOpen prepares CP-2 systems and evidence in your environment

DeployOpen works on CP-2 as an implementation partner inside your own infrastructure. We prepare the systems, contingency plan documentation and evidence that your team owns and that an independent assessor reviews, and we do not issue audit reports or certifications.

How we scope

Agree in writing which systems, baselines (low, moderate or high) and CP-2 enhancements are in scope
Confirm essential functions, recovery objectives and the named plan owner before any build work starts
Engagements are fixed-scope, and ongoing support for plan reviews is available as a retainer

How we build

Draft the contingency plan structure covering roles, contacts, restoration priorities and full restoration steps
Set up version-controlled documentation so every plan change records what changed, when and by whom
Connect the plan to backup and recovery tooling such as Bareos and restic, with restore evidence captured

How we hand over

Deliver the approved plan, distribution list, review schedule and change log for your records
Provide a mapping of each CP-2 determination statement to the document or log that supports it
Walk your assessors and plan owners through the evidence, while your organization retains control of approvals

How we support

Update the plan after lessons learned from tests, incidents or significant system changes
Coordinate plan revisions with incident handling procedures so both documents stay consistent
Run recurring checks of plan currency and evidence freshness under a retainer agreed in writing