PM-8: Critical Infrastructure Plan

PM-8 requires you to build, document, and keep current a Critical Infrastructure and Key Resources (CIKR) protection plan that explicitly addresses information security and privacy. Operationalize it by defining what “critical” means for your mission, inventorying the supporting systems and third parties, assigning owners, and running a recurring update and evidence cycle tied to real changes. ¹

Key takeaways:

• PM-8 is a planning control: you must produce a living CIKR protection plan, not a one-time document. ¹
• The plan must explicitly cover both information security and privacy impacts for critical services, systems, and dependencies. ¹
• Audits tend to fail on “no defined scope,” “no owner,” and “no update cadence/evidence,” so design the control around repeatable artifacts. ¹

PM-8: critical infrastructure plan requirement is easy to misunderstand because it sits in the Program Management family and reads like policy. In practice, assessors and customers treat it as proof that you can keep critical mission services running while managing security and privacy risk across the systems, facilities, people, and third parties that those services depend on. ¹

For federal information systems and contractor systems handling federal data, PM-8 becomes your “single pane” narrative that connects criticality decisions to concrete safeguards: which assets are critical, which threats matter, what privacy exposures exist, what compensating controls you rely on, who owns remediation, and how you keep the plan current when dependencies or risks change. ²

This page is written for a Compliance Officer, CCO, or GRC lead who needs to implement PM-8 quickly. You’ll get a plain-English interpretation, a step-by-step build plan, the evidence to retain, audit questions to prepare for, and a practical execution plan that you can assign to control owners immediately.

Regulatory text

Requirement (verbatim excerpt): “Address information security and privacy issues in the development, documentation, and updating of a critical infrastructure and key resources protection plan.” ¹

What the operator must do

You must:

1. Develop a Critical Infrastructure and Key Resources protection plan (a documented plan, not informal knowledge). ¹
2. Ensure the plan addresses information security and privacy issues relevant to the critical infrastructure and key resources you rely on. ¹
3. Document the plan in a way that is reviewable and assessable (clear scope, ownership, and actionable content). ¹
4. Update the plan over time (define triggers and cadence, and keep evidence that updates occur). ¹

If you only have a business continuity plan, only have a system security plan, or only have a privacy impact assessment, you are probably partial. PM-8 expects a joined-up plan for “critical” services and resources with explicit security and privacy coverage. ¹

Plain-English interpretation

PM-8 means you need a living plan that answers four exam-grade questions:

1. What is critical, and why? Define the mission/business services that cannot tolerate loss, corruption, or unavailability.
2. What does that critical service depend on? Systems, data stores, identity services, networks, facilities, people, and third parties.
3. What security and privacy issues could break the service or create unacceptable harm? Security incidents, integrity failures, supply-chain failure, and privacy risks tied to processing personal data. ¹
4. How do you protect it, and how do you keep the plan current? Controls, escalation paths, test/verification, and an update mechanism tied to change. ¹

Think of PM-8 as “criticality-driven security + privacy planning.” It should be short enough to be used during a real event, but structured enough to be assessed.

Who it applies to

Entities

• Federal information systems implementing NIST SP 800-53. ³
• Contractor systems handling federal data where NIST SP 800-53 controls are flowed down contractually or used as the assessment baseline. ³

Operational contexts where PM-8 becomes high-priority

• You operate services that support government mission delivery (availability and integrity are mission outcomes).
• You run shared services (identity, logging, network security) that are upstream dependencies for multiple systems.
• You rely on third parties for hosting, connectivity, managed security, or software supply chain components that could fail in correlated ways.
• You process sensitive data where privacy harms can occur even if availability is maintained. ¹

What you actually need to do (step-by-step)

Step 1: Assign ownership and define the boundary

• Control owner: name a single accountable owner (often GRC + resiliency/BCP lead), with security and privacy co-owners for content sign-off.
• Boundary statement: define whether the plan covers an enterprise, a program, a platform, or a specific system authorization boundary.

Output: PM-8 control record with owner, approvers, and where the plan lives (repository/path).

Step 2: Define “critical infrastructure and key resources” for your organization

Create a definition that your business will sign. Keep it operational:

• Critical services (e.g., “case intake,” “payment processing,” “identity proofing”)
• Key resources (e.g., “IdP,” “KMS/HSM,” “SIEM,” “primary cloud tenant,” “tier-0 admin tooling”)

Tip: Tie “critical” to mission impact and dependencies, not to org politics.

Output: CIKR scope list with rationale and business owner.

Step 3: Build the dependency map (systems, data, facilities, third parties)

For each critical service/resource, document:

• Systems/components: applications, databases, queues, storage, network segments
• Data types: include personal data categories where applicable (privacy linkage) ¹
• Access paths: admin consoles, privileged accounts, CI/CD pipelines
• Third parties: cloud providers, MSSPs, SaaS, critical subcontractors, and single points of failure

Output: Dependency register (table) mapped to asset inventory and third-party inventory.

Step 4: Identify security and privacy issues that matter for CIKR

This is where most PM-8 plans become too generic. Keep it specific:

• Security issues: loss of availability, integrity compromise, unauthorized admin access, logging gaps, supply-chain compromise, key management failure
• Privacy issues: unauthorized disclosure, excessive collection, retention failures, data subject rights breakdown, breach notification workflow gaps (as applicable) ¹

Output: Risk/issue register per critical service with “issue → existing controls → gaps → owner → remediation.”

Step 5: Document protection and response strategies

Your plan should describe, at minimum:

• Preventive controls: controls you rely on to prevent compromise (identity, segmentation, backups, monitoring)
• Resilience controls: redundancy assumptions, failover approach, backup/restore strategy
• Detection and escalation: who gets paged, what triggers an incident, what logs/telemetry are required
• Privacy response alignment: how privacy incidents are triaged and who approves communications ¹

Output: CIKR Protection Plan document with clear sections and named roles.

Step 6: Define update triggers and a recurring review motion

PM-8 explicitly requires updating. Put it on rails:

• Update triggers: new critical service, major architecture change, material third-party change, major incident/near miss, new privacy processing purpose, or risk assessment changes. ¹
• Review cadence: choose a cadence that matches your change rate; auditors mainly want to see it exists and is followed.
• Governance: a short change log with approvers and dates.

Output: Update procedure + change log template.

Step 7: Make it assessable (map PM-8 to evidence artifacts)

Treat this as an “evidence machine,” not a narrative document.

• Map PM-8 to: control owner, implementation procedure, recurring evidence artifacts. ¹

Where Daydream fits: Daydream can track the PM-8 requirement, assign owners, schedule recurring evidence requests, and keep a clean audit trail of plan versions, approvals, and the artifacts that prove the plan is being updated.

Required evidence and artifacts to retain

Keep these artifacts in a controlled repository with versioning:

1. Critical Infrastructure and Key Resources Protection Plan (current version) addressing security and privacy. ¹
2. CIKR scope definition and criticality rationale (why each item is critical).
3. Dependency register linking critical services to systems, data, and third parties.
4. Security + privacy issues register (risks/issues, current controls, gaps, owners). ¹
5. Approval record (named approvers, date, version).
6. Update procedure (triggers, review process, responsible roles). ¹
7. Plan change log and prior versions (evidence that updating occurs). ¹
8. Linkage evidence to adjacent programs: incident response, privacy program processes, third-party risk workflows (cross-references are fine; avoid duplicating content).

Common exam/audit questions and hangups

Assessors commonly press on:

• “Show me your definition of critical and who approved it.” Hangup: criticality defined informally or after the fact.
• “Does this plan cover privacy, or only security?” Hangup: privacy handled elsewhere with no explicit linkage. ¹
• “Prove the plan is updated.” Hangup: a PDF with no change log, or updates that are not tied to real triggers. ¹
• “What about third parties?” Hangup: critical SaaS/cloud/MSSP dependencies missing from the plan.
• “Who owns each gap?” Hangup: the plan lists issues but no accountable remediation owners.

Prep tactic: maintain a one-page “PM-8 audit packet index” that points to each artifact and its location.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails	Fix
Writing a high-level narrative with no scoped asset list	Assessors can’t tell what you actually protected	Add a scoped CIKR inventory and dependency register
Treating PM-8 as a BCP/DR document only	PM-8 explicitly calls out security and privacy issues 1	Add security/privacy issue registers and control linkages
No operational ownership	Plans rot without an accountable owner	Name an owner, approvers, and a review process
No update evidence	PM-8 requires updating 1	Keep versioning, change logs, and trigger-based updates
Excluding third parties	Real-world outages and breaches often start in dependencies	Add third-party dependency mapping and tie to third-party due diligence workflows

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so treat PM-8 as an assessment and contractual risk driver rather than an enforcement-driven one.

Operational risk is still real: if you cannot articulate and maintain your critical dependency plan, outages and security/privacy incidents will expose governance gaps. In federal contracting and system assessments, that translates to failed controls, delayed authorizations, remediation plans, and customer confidence loss. ³

Practical 30/60/90-day execution plan

First 30 days (establish scope + skeleton)

• Appoint PM-8 owner and approvers; define the plan boundary.
• Draft your criticality definition and initial CIKR list.
• Build a first-pass dependency register, including third parties.
• Create the plan template with required sections: scope, dependencies, security issues, privacy issues, update process. ¹

Days 31–60 (populate content + connect to operations)

• Run working sessions with system owners, security, privacy, and procurement/TPRM to validate dependencies.
• Document top security and privacy issues per critical service and assign remediation owners. ¹
• Define update triggers and implement a simple change log and approval workflow.
• Map PM-8 to recurring evidence artifacts in your GRC system (or Daydream) so the plan stays current.

Days 61–90 (prove it works + make it assessable)

• Conduct a tabletop or structured review using the PM-8 plan as the primary reference; record outcomes and action items.
• Produce the “audit packet index” with links to each artifact and version history.
• Close obvious gaps (missing third parties, missing privacy linkage, missing owners).
• Schedule recurring reviews and evidence collection so updates happen as a matter of process. ¹

Frequently Asked Questions

Do I need a separate PM-8 plan if we already have BCP/DR documentation?

Often yes, because PM-8 specifically requires addressing information security and privacy issues in the plan, not only continuity mechanics. You can reference BCP/DR content, but PM-8 needs a criticality-driven scope, dependency map, and update evidence. ¹

What counts as “critical infrastructure and key resources” in a SaaS-heavy environment?

Treat “critical” as the services and dependencies whose failure would materially disrupt mission outcomes. In SaaS environments, key resources usually include identity, tenant configuration, encryption/key services, CI/CD, logging, and the most critical third parties.

How do I show auditors that the plan is “updated”?

Keep version history, a change log, and approvals tied to defined triggers (architecture changes, third-party changes, incidents). Auditors want to see repeatable process evidence, not ad hoc edits. ¹

Where should privacy appear in the PM-8 plan?

Include privacy-impacting data types and processing in the dependency register and maintain a privacy issues section tied to incident response and governance workflows. PM-8 explicitly calls for privacy issues to be addressed. ¹

Who should approve the PM-8 plan?

Approval should include the accountable business owner for the critical service, the security owner, and the privacy lead where personal data processing is in scope. The goal is documented accountability for both security and privacy content. ¹

How can Daydream help without turning PM-8 into a paperwork exercise?

Use Daydream to assign control ownership, store the authoritative plan, and run recurring evidence tasks (plan review, dependency updates, third-party change checks). That keeps PM-8 operating as a change-driven workflow with clean audit trails.

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5; Source: NIST SP 800-53 Rev. 5 OSCAL JSON

3. NIST SP 800-53 Rev. 5