PM-8 Critical infrastructure plan: requirements and evidence

PM-8 critical infrastructure plan: what the requirement asks and why it is different

If an assessor or a contract asks for evidence of PM-8, the short answer is that PM-8 requires information security and privacy issues to be addressed in the development, documentation and updating of the organization's critical infrastructure and key resources protection plan. The control does not ask for a standalone security plan. It asks that the protection plan for critical infrastructure and key resources already in place, or required by the organization's mission, visibly account for both security and privacy when it is written and when it changes. Under SP 800-53B, PM-8 is a Program Management control deployed organization-wide, so it is not allocated to the low, moderate or high baselines and does not depend on a system's impact level. It is included in the privacy baseline, which applies to systems regardless of impact level, so privacy-scoped engagements will test it even when the security baseline is silent.

PM-8 is harder to satisfy than its one-sentence wording suggests for two reasons. First, the critical infrastructure protection plan often belongs to a business continuity, emergency management, facilities or operations function rather than the security team, so the security and privacy content may never reach the document unless someone is named to review it. Second, the control covers both disciplines. A plan that addresses cyber threats thoroughly but says nothing about personal information held by the infrastructure, or the privacy impact of a response, will not show the privacy consideration an assessor looks for. Before work begins, confirm which office owns the plan, who approves its updates, and whether the privacy office has a documented role in its development. Those three answers determine the evidence trail that follows.

Which plans, teams and systems PM-8 reaches

PM-8 sits at the organization level, so its reach depends on decisions made before any system is assessed. The cards below cover whether a critical infrastructure and key resources plan exists, which parts of the organization it covers, how it links to the system inventory, and which related controls feed or depend on it.

Whether a plan exists at all

PM-8 requires security and privacy issues to be addressed in a critical infrastructure and key resources protection plan. Start by confirming whether your organization has such a plan, who owns it, and whether it is a standalone document or a section of another program plan. If no plan exists, the control cannot be met by pointing to a system security plan. Ask the accountable official to state in writing whether the organization considers itself a critical infrastructure operator for this purpose and which sector guidance it relies on.

Business units and facilities in scope

Decide which business units, sites and key resources the plan covers. A plan that names only headquarters while operations, data centers or outsourced facilities depend on critical services leaves a gap an assessor will notice. Record the exclusions and the reason for each. Facilities that fall under physical controls such as PE-18 should be listed so the plan and the physical program describe the same locations.

Link to the system inventory

The plan should identify which systems in the organization's inventory support critical functions. The PM-5 system inventory is the natural source. Check that every system named as critical in the plan appears in the inventory, that its owner matches the plan, and that systems added later trigger a plan review. A mismatch between the two lists is a common finding because the inventory and the plan are often maintained by different teams.

Continuity and recovery controls that feed the plan

CP-2 contingency plans and CP-4 contingency plan testing supply the recovery steps that the critical infrastructure plan relies on. Confirm that the recovery objectives used in the contingency plans match the dependencies described in the protection plan. If the two documents assign different owners for the same service, the protection plan cannot show that its security and privacy issues are actually addressed during recovery.

Risk and supply chain controls it depends on

PM-9 risk management strategy, PM-11 mission and business process definition, RA-3 risk assessment and SI-12 information management and retention inform what the plan protects and how risk is judged. PM-30 supply chain risk management is not on the related list, but critical suppliers often belong in the plan. Verify that the risk assessment results and the supplier dependencies named in the plan are the same ones the risk program tracks.

Privacy baseline applies regardless of impact level

PM-8 is not allocated to the low, moderate or high security baselines because Program Management controls apply organization-wide. It does appear in the SP 800-53B privacy baseline, which applies to systems regardless of impact level. Teams that process PII must therefore address privacy issues in the plan even when no system is categorized as high impact. Confirm with the senior agency official for privacy, tied to PM-18 privacy program plan, which privacy issues the plan covers.

How an assessor tests PM-8 under SP 800-53A

This table walks through how an assessor tests PM-8 under SP 800-53A, method by method, with the assessment object, the evidence requested and the findings that appear most often. Read each row as a question the assessor asks about the plan, the people behind it and the process that keeps it current. The main takeaway is that a plan on file is only the starting point, because the assessor also tests how the plan was developed, documented and updated in practice.

Assessment method	Assessment object	Evidence an assessor expects	Common finding
Examine	The critical infrastructure and key resources protection plan	Current approved plan, version history, and sections showing security and privacy issues are addressed	Plan covers security but has no privacy content or no approval record
Interview	Personnel who develop, document and update the plan	Named owners, role descriptions, and staff explaining who triggers an update and who approves it	Owners are unclear, or staff cannot describe the plan's current version
Test	Organizational processes for developing, documenting and updating the plan	Written procedure, dated update records, and review and approval evidence from the last cycle	No update after major infrastructure, organizational or threat changes
Determination statement coverage	The six SP 800-53A determination statements for PM-8	Assessor worksheet mapping each statement to the examine, interview or test evidence that supports it	Evidence exists but cannot be tied to a specific statement
Related control inputs	Plan inputs from CP-2, RA-3, PM-9 and related controls	Cross-references showing risk assessment results and contingency planning feed the plan	Plan written in isolation from the risk management strategy and recovery plans
Ownership boundary	Who holds each part of the assessment	Organization owns and approves the plan; an implementation partner may prepare drafts and evidence; an independent assessor tests and reports	Drafts prepared by a partner are presented as approved without internal sign-off

How the security and privacy issues get into the plan

PM-8 expects security and privacy issues to be written into the critical infrastructure and key resources protection plan from the start, not added after the plan is drafted. In practice the plan's owner, usually the function that already runs business continuity or critical infrastructure protection, should ask the senior information security and privacy officials to contribute during drafting. Their input should be recorded in the plan itself or in a linked working document, with a named owner for each issue, so an assessor can trace a cyber or privacy risk from the threat description to the protective measure. The assessment procedure looks for personnel who develop, document and update the plan and for the processes they follow, so the reader should be able to name those people and show the steps they take.

Review and approval are where the control is most often tested. Confirm who signs off the plan, whether security and privacy leads are formal reviewers, and how disagreements are escalated and resolved. Keep dated review records, comments and version history so the approving official's decision can be shown. Update triggers usually include changes to the asset list or the systems the plan covers, new or changed threats, significant incidents, reorganizations, and changes to privacy obligations that affect how personal information flows through critical services. The organization should set these triggers in its own governance documents, and it should confirm the review frequency there and against any sector rules that apply to its infrastructure, because those rules may set cycles or reporting expectations that a general NIST reading will not capture.

An implementation partner can help define the drafting workflow, the review checklist and the change log, and can prepare the sample evidence set an assessor will request. The organization still owns the plan, its approvals and its update decisions, and an independent assessor determines whether the control is met. Before the next review cycle, ask the plan owner to produce the current version, the last approval record and the list of changes since the previous version, and check whether security and privacy reviewers appear in each step.

Implementing PM-8 step by step

This sequence turns PM-8 from a document that exists on paper into a critical infrastructure and key resources protection plan with a named owner, security and privacy inputs, a defined update trigger, linked controls and a recorded approval that an assessor can trace.

Confirm plan scope and accountable owner
Start by agreeing in writing which critical infrastructure and key resources the plan covers, which systems, facilities, data and suppliers sit inside that boundary, and which senior official owns the plan. Record the scope statement and the owner's appointment in the governance file so the plan has a defined perimeter before any content is written. The output is a signed scope statement and a named owner that an assessor can match to the plan's cover page. Confirm the owner's authority with your own governance documents, since the organization owns this decision and not the implementation partner.
Inventory the assets and dependencies in scope
Build the list of critical assets, key resources and their dependencies, including the systems that support them, the facilities and telecommunications they rely on, and the third parties that provide them. Pull this from the existing system inventory and the risk assessment rather than creating a parallel list that drifts over time. The output is a reviewed dependency register with an owner for each entry. Where the register is not yet current, the gap goes into the plan of action and milestones so the omission is tracked.
Map security and privacy inputs into the plan
Bring the security and privacy requirements for each in-scope asset into the plan. For each dependency, document the protection measures, the privacy considerations for any PII the asset handles, and the risk response decided under the organization's risk management strategy. The security and privacy teams review their own sections, and the plan records who reviewed what. The output is a plan draft in which every critical asset has a stated protection measure and a named reviewer for both security and privacy.
Link the plan to related controls
Cross-reference the plan to the controls that it depends on or informs, including contingency planning, risk assessment, mission and business process definition, and supply chain controls. Each link should name the specific artifact that the other control produces, such as the contingency plan, the risk assessment report or the supplier inventory, so an assessor can follow the chain of evidence in both directions. The output is a traceability table attached to the plan. Confirm the related control identifiers against your own control catalog before publishing the table.
Document the update procedure and triggers
Write a procedure that states how the plan is updated, who initiates an update, who approves it and where the previous versions are kept. Define change triggers that force an unscheduled review, such as a new critical asset, a material change to a dependency, a significant incident, or a change in the risk strategy. Set the review frequency your own governance requires, and record it in the plan rather than assuming it. The output is a procedure document and a trigger list that the plan owner signs off.
Run the first review against the assessment objectives
Test the draft against what an assessor will check: that the plan exists and is examined, that the personnel who develop and update it can be interviewed on their roles, and that the process for developing, documenting and updating it operates as written. Walk through one update cycle using a realistic change, recording what was done and by whom. The output is a review record listing each gap found and its disposition, either fixed in the plan or logged in the plan of action and milestones.
Record approval and set the evidence trail
Obtain formal approval from the accountable owner and any required senior officials, then store the approved version, the approval record, the scope statement, the traceability table and the review record in a controlled repository with version history. Confirm that the evidence is retrievable by someone who did not write it. The output is an approved plan with a dated approval record and a documented evidence index that supports the next assessment cycle. Keep the self-hosted repository access controls under the same review as the rest of your governance records.

Evidence that passes a PM-8 assessment

SP 800-53A assesses PM-8 through examine, interview and test methods, so an assessor will look at a document, the people behind it and the process that produces it. The cards below group the artifacts that cover each method and explain how to keep them current between assessments.

Approved critical infrastructure plan

This is the document the examine method targets: the critical infrastructure and key resources protection plan itself. It should identify the organization's critical infrastructure and key resources, state how security and privacy issues are handled in the plan, and name the official who approved it. Keep a version history that records each revision, its date, its author and its approver, so an assessor can see that the plan in use is the one that was approved. Confirm with your own governance team which approval authority your organization uses.

Security and privacy content records

PM-8 requires that information security and privacy issues be addressed in the plan, so assessors will look for evidence that both appear in it. Prepare a mapping that shows where security requirements and privacy requirements sit in the plan, along with the systems, data flows or services they protect. Records of how privacy risks were considered, such as a privacy review or a note from the privacy function, strengthen this evidence. Without these records, a plan can read as a security-only document even when it is well written.

Update and review records

The plan must be developed, documented and updated, so the update record matters as much as the original text. Keep a review log that shows the defined review trigger, such as an annual cycle or a significant change in the organization's critical services, the date each review occurred and the outcome. Record changes to the plan that followed incidents, exercises, new dependencies or changes in critical infrastructure ownership. Gaps between review dates are a common finding, so set a calendar reminder tied to the review schedule the organization has defined.

Role descriptions for plan owners

The interview method asks organizational personnel responsible for developing, documenting and updating the plan. Assessors will want written role descriptions that name who drafts the plan, who reviews it, who approves it and who maintains the inventory of critical assets it depends on. Each role should list responsibilities in plain terms and the authority needed to act. Keep these descriptions current when staff change, and record the interviewees' understanding in your own preparation notes so the answers match the written roles.

Process records for plan development

The test method examines the organizational processes that develop, document and update the plan. Keep a written procedure that describes intake of new critical dependencies, drafting steps, stakeholder consultation and sign-off. Then retain the records a process produces, such as meeting minutes, review comments, approval emails and tickets that link plan changes to the triggering event. An assessor testing this method will try to follow one change from its trigger to its approval, so make sure each step leaves a traceable record.

Linked evidence from related controls

PM-8 relates to nine other controls, including CP-2 for contingency planning, RA-3 for risk assessment and PM-9 for risk management strategy. Assessors often check whether the plan agrees with the outputs of those controls. Keep cross-references from the plan to the contingency plan, risk assessment results and risk management strategy so each can be traced. When these documents disagree, record the reconciliation. Confirm the full related-control list in the current catalog before you build the cross-reference table.

What PM-8 costs to meet

This table breaks down the cost components of producing and maintaining a critical infrastructure and key resources protection plan under PM-8, showing who is paid for each, whether it is one-time or recurring, and what moves it up or down. NIST does not estimate compliance costs, so use the table to shape a written scope and quote request, not as a budget.

Cost component	Who carries it	One-time or recurring	What drives it
Internal time to write and review the plan	Your security, operations and facilities staff	One-time to draft, recurring at each update	Number of critical infrastructure dependencies, sites and sectors the plan must cover
Legal and privacy review	Your legal counsel and privacy office	Recurring at each material revision	Regulatory obligations that apply to your sector and jurisdictions, and how often they change
Facilitation of security and privacy input	Internal program lead or an implementation partner if engaged	One-time for the first cycle, recurring for reviews	Number of business units and external parties consulted and whether sessions are documented
Evidence upkeep	Your control owners, with partner support if retained	Recurring	How often the plan and its supporting process records change and how they are stored for assessors
External review or assessor sampling	Independent auditor or assessor, who issues any report	Recurring at each assessment cycle	Assessment scope, the sample the assessor selects and the number of systems tied to the plan
Implementation partner support, if used	Partner, under a written fixed scope or retainer	One-time for scoped work, recurring for retainers	Deliverables in writing, existing documentation quality and the number of revision cycles
Maintenance after significant change	Your change management and risk owners	Recurring, triggered by events	Frequency of infrastructure changes, mergers, new sites or new key resource dependencies

Who owns the plan, who helps and where the auditor stops

The organization owns PM-8. Leadership must decide who is accountable for the critical infrastructure and key resources protection plan, who develops and maintains it, and how it connects to the organization-wide information security program plan and risk management strategy. SP 800-53A describes the assessment objects for this control as the plan itself, the personnel responsible for developing, documenting and updating it, and the processes used to do that work, so these people and processes are what an assessor will ask to see.

Plan ownership: Name an accountable owner and a documented approval path for the plan and its updates.
Personnel responsible: Record who drafts, reviews and updates the plan, and confirm they can explain it in interviews.
Process records: Keep dated revisions, review minutes and sign-offs that show how the plan is developed and kept current.
Interdependencies: Track how the plan relates to contingency planning, incident response and risk assessment content owned by other teams.
Decisions only you can make: Which infrastructure and key resources are in scope, and what risk the plan accepts.

Before engaging anyone outside, confirm that your own team can explain the plan's scope and ownership without notes.

Where PM-8 plans usually fall short

A PM-8 plan is assessed on whether information security and privacy shape how critical infrastructure and key resources are protected, developed, documented and updated. The gaps below recur because the plan often sits with one function, is written once and filed, and is not connected to the controls that feed it. Each card pairs a gap with a check you can run before an assessor does.

Plan owned without security input

Many critical infrastructure and key resources plans are written by facilities, operations or business continuity staff, who address physical protection and service restoration but not information security. Under PM-8, security and privacy must be addressed in developing, documenting and updating the plan, so the assessor will look for security personnel in the authorship and review record. Check whether the security lead signed a review of the plan and whether their comments were resolved or formally accepted as risk.

Privacy absent from the plan

Plans typically list facilities, power, water and communications dependencies, but rarely mention the personally identifiable information held by systems that support those services. Because PM-8 is in the privacy baseline, which applies regardless of impact level, privacy has to appear in the plan as well. Check whether the plan identifies where PII is processed by critical services and whether the privacy office reviewed that section.

No documented update trigger

PM-8 covers updating the plan, but many organizations have no written rule for when an update must happen. Without triggers, the plan drifts away from the actual asset inventory after reorganizations, new hosting arrangements or incidents. Write down the events that force a review, such as a material system change, a significant incident or a change in the services the plan protects, and record the date of each review in the plan's revision history.

Plan not linked to related controls

The SP 800-53 Release 5.2.0 catalog relates PM-8 to CP-2, CP-4, PE-18, PL-2, PM-9, PM-11, PM-18, RA-3 and SI-12, among others. A plan that stands alone cannot show how contingency plans, risk assessments and risk management strategy reflect its priorities. Build a cross-reference table that maps each plan section to the contingency, risk and planning artifacts that implement it, and keep that table current with the plan.

Approval records missing

An assessor testing PM-8 will ask who approved the current version of the plan and when. Plans are often edited in shared documents with no signature, approver or date, so the organization cannot show that the plan was endorsed at the right level. Confirm the accountable official who approves the plan, keep a dated approval record for each version, and retain the prior versions so the change history can be reconstructed.

Process to develop the plan untested

The assessment procedure for PM-8 includes testing the organizational processes for developing, documenting and updating the plan, not only reading the document. A plan that exists but has no repeatable process behind it will struggle to show consistency. Document the steps, owners and inputs for each update cycle, then run one update through that process and keep the resulting records as evidence.

PM-8 questions buyers ask before hiring help

Is PM-8 in the low, moderate or high baseline?

No. PM-8 is not allocated to the low, moderate or high baselines in SP 800-53B. Program Management controls are deployed organization-wide, support the information security program and are independent of any system's impact level. PM-8 does appear in the SP 800-53B privacy baseline, which applies to systems regardless of impact level. Confirm this against the SP 800-53B profiles for your own program, since a privacy baseline selection can change which controls your assessor reviews. The SP 800-53B publication is the natural next read.

What does PM-8 require the organization to produce?

PM-8 requires that information security and privacy issues are addressed when the organization's critical infrastructure and key resources protection plan is developed, documented and updated. The work is a plan and the process that maintains it, not a technical configuration. An assessor typically examines the plan, interviews the people who develop and update it, and tests the process itself, which is how SP 800-53A structures the procedure for this control. The organization owns the plan and its content. An implementation partner can help draft the security and privacy sections and set up a review cycle, but the plan must reflect the organization's own critical functions and dependencies.

How much effort does PM-8 take to meet?

Effort depends on how mature the existing critical infrastructure plan is, how many business units and third parties it covers, and whether security and privacy are already part of its update cycle. No supplied figure gives a reliable effort estimate for PM-8 alone, so ask for one in writing. Ask any partner to split the estimate into a one-time gap assessment and drafting, and a recurring review of the plan at the cadence the organization sets. Related controls such as CP-2, RA-3 and PM-9 usually share evidence with this work, so ask whether the quote counts that overlap once or separately.

How long does it take, and what does it need from internal staff?

No supplied fact gives a duration for PM-8, and the timeline depends on the size of the plan, the number of reviewers and how quickly approvals move. Internal staff are needed for three things: the people who own the critical infrastructure plan, the security and privacy leads who must review it, and the staff who can confirm which systems and dependencies it covers. Ask a partner for a dated schedule that lists the internal participants and the decisions each must make. A fixed-scope engagement should state these dependencies in the written scope before work starts.

Can we meet PM-8 ourselves without outside help?

Yes, many organizations do. PM-8 is a documentation and process control, so an internal team that owns the critical infrastructure plan can add security and privacy content and a review cycle without specialist tooling. Outside help is most useful when the team lacks a current baseline, when the plan spans many systems or third parties, or when the assessor's expectations are unclear. Read the six SP 800-53A determination statements for PM-8 first. If the internal team can show evidence against each one, outside help may only be needed for a readiness review.

What will a partner produce for PM-8, and what will it not?

A partner such as DeployOpen prepares systems, controls and evidence for an assessment. For PM-8, that can include a gap review against the SP 800-53A procedure, drafted security and privacy content for the plan, a review workflow and a set of evidence records. A partner does not own the controls, does not decide what the critical infrastructure plan must say, and does not issue audit reports or attestations. Only an independent assessor or certification body can do that. Put the deliverables, exclusions and acceptance steps in the written scope before engagement starts.

What should we ask for in a quote for PM-8 work?

Ask for a written scope that names each deliverable, the systems and business units covered, the assumptions about internal staff, and what is excluded. Request a split between one-time work, such as the gap review and first draft, and recurring work, such as plan updates and assessor support. Ask how the quote handles overlap with related controls in the CP, RA and PM families. Confirm who signs off on acceptance and whether any ongoing support is a separate retainer. A quote should follow from that scope, since DeployOpen does not publish a price list.

How DeployOpen prepares PM-8 evidence

DeployOpen works on PM-8 as an implementation partner: we help prepare the critical infrastructure and key resources protection plan, the processes that develop and update it, and the records an assessor will ask for. The organization owns the plan and its approval, and only an independent assessor can issue an assessment conclusion.

How we scope

Engagements are fixed-scope, with the PM-8 deliverables and boundaries agreed in writing before work starts.
We confirm which organizational units, systems and critical services the protection plan must cover, and who owns each one.
The written scope names the plan documents, process records and interview participants that the engagement will prepare.

How we build

We help draft or restructure the protection plan so it addresses information security and privacy issues in its content.
We document the process for developing, reviewing and updating the plan, including the roles that approve each revision.
We test the update process against a sample change so the organization can show the process runs as written.

How we hand over

We deliver the plan, process documentation and a cross-reference to the related controls, including CP-2, PM-9 and RA-3.
We provide an evidence index mapping each PM-8 assessment objective to the document, record or interview that supports it.
Ownership, review dates and approval records transfer to named staff so the organization can maintain the plan after handover.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer for plan reviews and evidence refreshes.
We can help prepare staff for assessor interviews on how the protection plan is developed and updated.
Before any assessment, confirm with your assessor which evidence formats and sampling they expect for PM-8.