NIST SP 800-53 PM Program Management: Key Controls, Enhancements and How to Evidence Them

The Program Management (PM) family is the part of SP 800-53 that most system-level assessments skip, because its 32 controls belong to the organisation rather than to any one system, so nobody owns them. This guide works through the PM family control by control: what each control asks for, which organisation-defined parameters you must set, how PM controls relate to the system security plans that inherit them, and what evidence an assessor will look for. It is written for CISOs, risk and compliance leads, programme managers and assessors who need the organisation-wide layer of a Rev. 5 control set to hold up. For the catalogue as a whole, see the NIST SP 800-53 Guide; this page goes one level deeper on PM only.

Key takeaways

• PM controls sit outside the baselines. The SP 800-53 Release 5.2.0 catalogue says PM controls are implemented at the organisation level, are independent of FIPS 200 impact levels and are not associated with the SP 800-53B baselines. Low, Moderate and High systems all depend on them. The separate privacy baseline does select 24 PM controls and enhancements, so privacy programmes must account for them.
• Two plans carry the family. The information security programme plan (PM-1) and the privacy programme plan (PM-18) document the PM controls and the common controls that systems inherit, alongside each system's own plan under PL-2.
• Risk governance is now explicit. PM-9 (risk management strategy), PM-28 (risk framing), PM-29 (Senior Accountable Official for Risk Management and a Risk Executive function), PM-30 (supply chain risk strategy) and PM-31 (continuous monitoring strategy) turn risk appetite into written, reviewable artefacts.
• Inventory and measurement are PM controls too. PM-5 (system inventory), PM-5(1) (inventory of systems that process personal data) and PM-6 (measures of performance) are where many programmes fail first, because the inventory does not include every system, service and machine identity in use.
• Evidence is governance artefacts with dates. Assessors examine the programme plan, strategies, POA&M records and review records, and interview the senior officials named in them. Undated or unapproved documents are the most common finding.

How the PM family differs from other families

Most SP 800-53 families are selected per system through a baseline and tailored in the system security plan. PM is different in three ways.

• Scope: PM controls are written for the organisation. A system cannot "implement" PM-2; it inherits the fact that a senior information security officer has been appointed.
• Origin: the catalogue ties PM to FISMA, the Privacy Act and OMB Circular A-130. Non-federal organisations adopt PM as their governance layer.
• Documentation: PM controls live in the programme plans, which together with system plans cover every control the organisation employs.

When a system plan marks a control as inherited, the provider is usually a PM artefact. If the PM layer is missing, the inheritance claim has nothing behind it.

The PM family at a glance

The table groups all 32 current PM controls by purpose, from the Release 5.2.0 OSCAL catalogue. None is allocated to the Low, Moderate or High security baselines. The OSCAL privacy baseline profile selects PM-3, PM-4, PM-5(1), PM-6 to PM-11, PM-13, PM-14, PM-17 to PM-22, PM-20(1), PM-24 to PM-28 and PM-31. PM-18 to PM-27 are the privacy programme controls.

Programme plan, leadership and resources: PM-1, PM-2, PM-3, PM-13

• PM-1: develop and disseminate an organisation-wide information security programme plan that gives an overview of programme requirements, describes the PM and common controls in place or planned, assigns roles and responsibilities, reflects coordination among the entities responsible for security, and is approved by a senior official accountable for the risk. Review and update it at a frequency and after events you define, and protect the plan from unauthorised disclosure and modification.
• PM-2: appoint a senior agency information security officer with the mission and resources to run the organisation-wide programme. Outside government this is the CISO; evidence is a written appointment.
• PM-3 and PM-13: include the resources for the security and privacy programmes in capital planning and investment requests, document exceptions and make them available for expenditure; PM-13 adds a workforce development programme.

The PM-1 parameters are the review frequency and the events that trigger an update. NHI Mgmt Group recommends an annual review plus a review after any reorganisation, merger, change of CISO, major incident or change of framework. See the Security Programme Building Guide for sequencing.

Risk governance: PM-9, PM-10, PM-11, PM-28, PM-29, PM-32

These controls link SP 800-53 to the NIST Risk Management Framework. Read them as a chain.

1. PM-28 Risk Framing: identify and document the assumptions, constraints, priorities and trade-offs that affect risk assessment, response and monitoring, and the organisational risk tolerance. Distribute the results to the people you define and review them at a defined frequency.
2. PM-9 Risk Management Strategy: develop a strategy for security risk from operating systems and privacy risk to individuals from processing personal data, implement it consistently, and review it at a defined frequency or when the organisation changes.
3. PM-29 Leadership Roles: appoint a Senior Accountable Official for Risk Management to align security and privacy with strategic, operational and budget planning, and establish a Risk Executive function that views risk organisation-wide.
4. PM-10 Authorization Process: manage the security and privacy state of systems through authorisation processes, designate the people who fill risk management roles, and integrate authorisation into the organisation-wide programme.
5. PM-11 Mission and Business Process Definition: define mission and business processes with security and privacy in mind and derive information protection and personal data processing needs from them.
6. PM-32 Purposing: analyse the systems or components you define that support mission essential services to confirm they are used as intended.

A written risk appetite is the most useful single artefact for PM-28 and PM-9; the Cyber Risk Appetite Statement Template gives a starting format, and the NIST Risk Management Framework (SP 800-37) Guide explains how authorisation decisions under PM-10 use it.

Inventory, architecture and critical infrastructure: PM-5, PM-7, PM-8

• PM-5 System Inventory: develop and update an inventory of organisational systems at a frequency you define. PM-5(1) adds an inventory of all systems, applications and projects that process personal data.
• PM-7 Enterprise Architecture: develop and maintain an enterprise architecture that considers security, privacy and the resulting risk. PM-7(1) Offloading asks you to move non-essential functions or services you define to other systems, components or an external provider.
• PM-8: address security and privacy in the critical infrastructure protection plan.

Where identity fits: PM-5 counts systems, but a system inventory that cannot say which service accounts, API keys, workload identities and AI agents each system uses will not support the system-level controls that depend on it (AC-2, IA-9, CM-8). We recommend recording, for each inventoried system, its owner, its authorisation status and a pointer to its machine identity inventory. See the Asset Inventory and CMDB Security Guide.

Remediation, measurement and monitoring: PM-4, PM-6, PM-14, PM-31

• PM-4 Plan of Action and Milestones Process: make sure POA&Ms for the security, privacy and supply chain programmes and their systems are developed, maintained, document remedial actions and are reported as required; review them against the risk management strategy and organisation-wide priorities. See the Plan of Action and Milestones (POA&M) Guide.
• PM-6 Measures of Performance: develop, monitor and report security and privacy measures of performance.
• PM-14 Testing, Training, and Monitoring: make sure plans for testing, training and monitoring are developed, maintained and executed, and reviewed against the risk strategy.
• PM-31 Continuous Monitoring Strategy: develop an organisation-wide continuous monitoring strategy that sets the metrics to monitor, the frequencies for monitoring and for assessing control effectiveness, ongoing monitoring, correlation and analysis of assessment and monitoring results, response actions, and reporting of system status to the people you define at a frequency you define.

PM-31 is the organisation-level parent of CA-7: write its parameters once and have each system plan point to them. For metric design, see the Security Metrics and KPIs Programme Guide.

Insider threat, threat awareness and supply chain: PM-12, PM-15, PM-16, PM-17, PM-30

• PM-12 Insider Threat Program: implement an insider threat programme with a cross-discipline insider threat incident handling team. The SP 800-53A interview list names legal counsel and team members, so the team must exist in practice. See the Insider Threat Programme Guide.
• PM-15: keep contact with security and privacy communities for training and information sharing.
• PM-16 Threat Awareness Program: implement a threat awareness programme with a cross-organisation information-sharing capability; PM-16(1) adds automated mechanisms for sharing threat intelligence. See the ISACs and Information Sharing Communities Guide.
• PM-17: set policy and procedures so that requirements for protecting controlled unclassified information on external systems are implemented, and review them at a defined frequency. See the CUI Guide.
• PM-30 Supply Chain Risk Management Strategy: develop, implement and review an organisation-wide strategy for supply chain risk across development, acquisition, maintenance and disposal. PM-30(1) adds identifying, prioritising and assessing suppliers of critical or mission-essential items. The system-level SR family depends on it; see the NIST SP 800-161 Cyber Supply Chain Risk Management Guide.

The privacy programme controls: PM-18 to PM-27

PM-18 and PM-19 mirror PM-1 and PM-2 for privacy: an approved privacy programme plan and a senior agency official for privacy. The rest set public and operational duties. Several are specific to US federal agencies (PM-21 and PM-24 reflect Privacy Act and computer matching requirements); non-federal organisations usually adopt the intent and record a tailoring rationale.

How to evidence PM controls

The OSCAL catalogue carries the SP 800-53A examine, interview and test objects for every PM control. For PM, examine objects are mostly plans, strategies and review records, and interviews are with the senior officials named in them (PM-31 lists the Senior Accountable Official for Risk Management, the CIO, the senior agency information security officer and the senior agency official for privacy). The table turns that into evidence.

For assessment depth and sampling, see the NIST SP 800-53A Guide.

Implementing the PM family: a phased approach

This sequence is NHI Mgmt Group's recommendation for an organisation adopting SP 800-53 whose system plans already claim common controls.

1. Name the officials. Record the PM-2 security officer, the PM-19 privacy official and the PM-29 Senior Accountable Official for Risk Management, with written appointments.
2. Write the risk frame. Document assumptions, constraints, priorities and tolerance (PM-28), then the strategy (PM-9). Have the accountable official approve both.
3. Build the inventory. Reconcile PM-5 against cloud accounts, SaaS tenants and CMDB records; add PM-5(1) flags for personal data and a pointer to each system's machine identity inventory.
4. Publish the programme plan. PM-1 lists every common control and who provides it. Check each system plan's inheritance claims against this list and fix mismatches.
5. Stand up the operating controls. POA&M process (PM-4), measures (PM-6), continuous monitoring strategy (PM-31), insider threat team (PM-12) and supply chain strategy (PM-30).
6. Test before the assessment. Run an internal review against the SP 800-53A objects. If a PM artefact fails review, keep the previous approved version in force until the corrected one is approved, rather than leaving a gap.

Decision guidance

• Federal versus non-federal: federal agencies implement PM as written. Others should adopt PM-1 to PM-16, PM-28 to PM-31 and the privacy controls that match their legal duties, and record a rationale for any control tailored out.
• Small versus large organisations: a small organisation can combine PM-1 and PM-18 into one programme document and give one person several roles, provided the plan says so. Large organisations need the Risk Executive function (PM-29) to keep risk acceptance consistent across business units.

Detection and measurement

• Share of system security plans whose common control claims match the PM-1 list.
• Systems discovered outside the PM-5 inventory per quarter, and time to add them.
• POA&M items past their milestone date, by risk level.
• Age of the risk strategy, risk frame and programme plan against their review parameters.
• Continuous monitoring reports delivered on schedule to the PM-31 recipients.

Framework mapping

Mappings are "intersects with", not equivalence. Check them against NIST's published informative references before using them in an audit. For method, see the Control Mapping Guide.

Common failure patterns

• Common controls with no provider: system plans mark controls as inherited from "the organisation", but no PM-1 plan lists them.
• Risk tolerance never written: PM-28 is skipped, so every risk acceptance under PM-10 is a judgement with no reference point.
• Inventory limited to on-premises systems: PM-5 misses SaaS tenants, cloud accounts and the machine identities that connect them.
• POA&M as a parking lot: items are opened to satisfy an assessment and never reviewed against the risk strategy, contrary to PM-4(b).
• Insider threat team on paper only: PM-12 names a team that has never met or handled a case.

Practitioner checklist

• Appoint and record the PM-2, PM-19 and PM-29 officials in writing.
• Document the risk frame, including tolerance, and the risk management strategy.
• Publish an approved PM-1 plan that lists every common control and its provider.
• Reconcile the PM-5 inventory with cloud, SaaS and machine identity records.
• Run a POA&M process that ties every item to a risk and a dated milestone.
• Set organisation-wide continuous monitoring metrics and frequencies under PM-31.
• Convene the PM-12 insider threat team and keep records of its work.
• Fill every PM organisation-defined parameter and record tailoring rationales.

Standards and references

• NIST: SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations
• NIST: OSCAL content, SP 800-53 Release 5.2.0 catalogue and baseline profiles
• NIST: SP 800-53A Rev. 5, Assessing Security and Privacy Controls
• NIST: SP 800-53B, Control Baselines for Information Systems and Organizations
• NIST: SP 800-37 Rev. 2, Risk Management Framework
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: NIST SP 800-53 Guide · NIST SP 800-53B Control Baselines and Tailoring Guide · Risk Register Template · Identity Security Programme Guide