PM-14 Testing, training, and monitoring: requirements and evidence

What PM-14 asks for and why PM-14 is an organization-level control

If you are the compliance lead being asked whether PM-14 is covered, the short answer is that PM-14 Testing, training, and monitoring requires a process that makes sure plans for security and privacy testing, training and monitoring of systems are developed, maintained and carried out, and that those plans are reviewed for consistency with the risk management strategy and risk response priorities. The control is about the plans and the process that keeps them current, not about any single test, course or monitoring tool. Because PM-14 is a Program Management control, SP 800-53B treats it as deployed across the organization rather than allocated to the low, moderate or high baselines, so it does not depend on a system's impact level. It does appear in the SP 800-53B privacy baseline, which applies to systems regardless of impact level, so privacy-relevant systems need to be able to show it.

The reason PM-14 sits at program level is that one organization-wide plan set has to drive many system-level activities. The catalog links PM-14 to seven related controls: AT-2 and AT-3 for security and privacy awareness and role-based training, CA-7 for continuous monitoring, CP-4 for contingency plan testing, IR-3 for incident response testing, PM-12 for the insider threat program, and SI-4 for system monitoring. PM-14 is where those activities are planned as a coordinated whole. Confirm which of these controls your organization already implements, who owns each plan, and where each plan is stored, because an assessor will ask whether the testing, training and monitoring plans cover the same systems and risks.

The usual difficulty is not writing the plans but keeping them connected to decisions. Plans are often created for an audit, then left unchanged while systems, threats and the risk management strategy move on. Testing schedules may ignore findings from the last assessment, training may not reflect new roles, and monitoring may watch signals that no longer match the risk priorities. SP 800-53A asks assessors to examine the plans and interview the people who develop and maintain them, so a plan that nobody can explain or update will fail even if activities are happening. Before scoping the work, ask who approves the plans, how often they are reviewed against the risk management strategy (PM-9), and what evidence shows that review actually took place.

Which programs, systems and teams PM-14 applies to

PM-14 reaches further than most teams expect. It covers the organization-wide plans themselves, the system-level activities those plans govern, and the people and third parties who carry them out. Scoping starts by deciding which of these sit under the control and which sit under the owners of individual systems.

Organization-wide testing, training and monitoring plans

PM-14 is written at the organization level, so the first in-scope item is the set of plans themselves: the security and privacy testing plan, the training plan and the monitoring plan. Confirm that each plan exists as a maintained document with an owner, a revision history and a stated link to the risk management strategy. Assessors will ask for the plans before they look at any individual activity.

System-level testing and monitoring activities

The plans govern what happens to systems: security and privacy control testing, training delivery and ongoing monitoring. Inventory which systems are covered by each activity and where the results land. The related controls in the catalog, including CA-7 for continuous monitoring and SI-4 for system monitoring, show where system owners already produce evidence that feeds the organization-wide plans.

Privacy baseline systems at any impact level

PM-14 is not allocated to the low, moderate or high security baselines, but it is part of the privacy baseline, which applies regardless of system impact level. Any system that processes PII therefore falls within scope for privacy testing, training and monitoring, even when its security categorization is low. Check the privacy baseline selection for each system rather than relying on its security impact level alone.

Plan owners versus plan executors

Separate the people who own and approve the plans from the teams that run the activities. Owners are usually accountable officials in the security, privacy or risk functions who keep the plans consistent with the risk management strategy. Executors include security testing, training and operations staff. Document both roles in writing so that an assessor can trace each activity back to an accountable owner.

Third-party testers and training providers

External penetration testers, red teams, training vendors and managed monitoring providers are in scope when they carry out activities under the plans. The organization still owns the plans, so contracts should require the provider to follow them, share results and report against the agreed scope. Ask each provider for its written scope and for the records it will return.

Risk strategy and response priorities link

PM-14 requires that plans are reviewed for consistency with the risk management strategy and risk response priorities. Any system, team or provider that falls outside that review is a gap. Map each plan to the risk strategy document it cites, and record who reviewed the link and when. The risk strategy itself is governed by PM-9.

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

This table pairs each assessment method in SP 800-53A for PM-14 with the artifacts an assessor typically asks for and the findings that appear most often. Use it as a preparation checklist, and confirm the exact determination statements and method mix in the NIST CPRT or the SP 800-53A text before the assessment starts. The main takeaway is that plans, review records and staff understanding must all agree with the current risk management strategy.

Assessment method	Artifacts the assessor asks for	Common findings
Examine: testing, training and monitoring plans	Current plans for security and privacy testing, training and monitoring, with version history and approval records	Plans exist for some activities but not for privacy testing or monitoring
Examine: consistency with risk strategy	Risk management strategy, risk response priorities and a mapping showing how each plan reflects them	Plans were written once and never compared with the current risk strategy
Examine: review and update records	Dated review minutes, change logs and evidence that plans were revised after significant changes	Reviews are scheduled but not documented, so the assessor cannot confirm them
Interview: plan owners	Named owners who maintain the plans, and their explanations of scope, frequency and approvals	Owners describe the plans differently from the written documents
Interview: personnel who run the activities	Staff who carry out tests, deliver training and review monitoring output, explaining how the plans reach them	Staff are unaware the plans exist or cannot say how results feed back into planning
Test: execution against the plans	Records showing planned tests, training sessions and monitoring activities were carried out, with their results	Planned activities are missing from the records, or results are not linked to the plan
Test: follow-up on results	Remediation tickets or risk responses that trace back to test, training or monitoring findings	Findings are logged but no response priority is recorded

Sequence to build a PM-14 process that survives an assessment

This sequence turns scattered testing, training and monitoring activity into one organization-level process that is documented, owned, reviewed against the risk strategy and ready for an assessor to test against the PM-14 determination statements.

Inventory existing testing, training and monitoring activity
The security or privacy program office lists every testing, training and monitoring activity already running across systems, business units and suppliers, including vulnerability scans, penetration tests, tabletop exercises, awareness courses, role-based training and log or control monitoring. Each entry records the activity, the systems it covers, the team that runs it and where its output is stored. The step is complete when the inventory is reviewed by the people who run these activities and gaps are marked, so the team knows what plans must cover before drafting anything.
Anchor plans to the risk management strategy
Before drafting, the team reads the organization's risk management strategy (PM-9) and the current risk response priorities, then confirms which activities address the highest-ranked risks and which systems carry the most impact. This matters because PM-14 asks that the plans be reviewed for consistency with that strategy, and an assessor will look for the link. The output is a short mapping note that states which priorities each planned activity serves, signed off by the risk executive or the accountable official named in the strategy.
Draft or consolidate the plans
Using the inventory and the priority mapping, the team writes or updates the plans for security and privacy testing, training and monitoring. Overlapping plans for the same systems are merged, and each plan states its scope, method, frequency, expected outputs and the controls it supports, including the related AT, CA, CP, IR, RA and SI controls where they apply. The output is a current set of plan documents approved through the organization's normal document process, with version numbers and approval dates recorded.
Assign named owners to each plan
Each plan receives one accountable owner and a named delegate, selected from the security, privacy, IT and business functions that perform the work. The owner is responsible for executing the activity, keeping its records and raising gaps. Owners acknowledge their assignment in writing, and the assignments are reflected in role descriptions where the organization keeps them. An assessor's interview objectives for PM-14 are aimed at these personnel, so the output is a roster that names each person, their responsibility and the plan they own.
Set review and update cycles
The team defines how often each plan is reviewed and what triggers an unscheduled update, such as a significant change to a system, a new threat pattern, an incident, or a revised risk management strategy. Review dates are entered into a tracking system that assigns reminders to owners. The frequency values are set by the organization's own policy, so the team confirms them with the risk function rather than adopting a generic interval. The output is a review calendar and a change log template attached to the plan set.
Execute activities and record the results
Owners run the planned testing, training and monitoring activities and record each one with a date, scope, participants, results and follow-up actions. Training completion is captured in the learning platform, for example through activity completion records in a self-hosted LMS, which can show when a learner completed a course. Findings from testing and monitoring are routed into the plan of action and milestones process (PM-4) where they require remediation. The output is an evidence set per plan for each cycle, stored where an assessor can retrieve it.
Run the periodic consistency review
On the schedule defined in the previous step, the risk or program office compares what was executed against what was planned, checks the results against the current risk strategy and priorities, and decides whether plans need to change. Gaps, missed activities and plans that no longer match the risk picture are documented with decisions and owners. The review closes when minutes or a signed report record the outcome and the plans are updated. This closing record is what shows the process operates as a loop, and it becomes the starting point for the next inventory.

How PM-14 plans feed the CA, IR, AT and CP work

PM-14 is the organization-level layer that sits above the system-level controls it names. The plans it requires for security and privacy testing, training and monitoring are the same plans that CA-7 continuous monitoring, IR-3 incident response testing, AT-2 and AT-3 training, CP-4 contingency plan testing and SI-4 system monitoring carry out for individual systems. The practical test is simple: if a system-level control produces a test schedule, a training record or a monitoring result, it should trace back to a single organization-wide plan rather than to a separate spreadsheet kept by each team. Start by asking the owner of each family to point to the plan, schedule and risk strategy reference their control uses, then confirm that the plan approved under PM-14 lists those activities and their frequencies. Gaps usually appear where a system team runs a test that no organization-level plan mentions.

Evidence can be reused in both directions. A continuous monitoring report, an incident response exercise after-action report, a contingency test record and a training completion export can each serve as the execution evidence for PM-14, so long as each is dated, tied to the plan item it fulfills and reviewed against the risk management strategy and risk response priorities. Do not write a separate PM-14 narrative that restates them. Instead, keep one review record per planning cycle that cites the artifacts by identifier. PM-12 insider threat fits as a specialized testing and monitoring activity: user activity monitoring and awareness training that the insider threat program requires should appear in the same plan so that assessors can see the monitoring scope is consistent with the risk strategy. For learning records, Moodle's activity completion API can show when a learner viewed or was graded on a module, which helps prove that AT-2 and AT-3 completions reflect actual participation. Confirm with your assessor which artifacts they will accept as the single source for each shared item before you begin collecting.

Evidence that passes a PM-14 review

An assessor testing PM-14 looks for a documented process and the paper trail showing it runs. The cards below cover the artifacts that connect plans, execution and risk strategy, and how to keep each one current between assessments so it reflects what the organization actually did.

Approved testing, training and monitoring plans

These are the organization-level plans for security and privacy testing, training and monitoring that PM-14 requires to be developed, maintained and executed. Each plan should name its owner, scope, approval authority and review cycle, and carry a version history showing who changed what and when. Between assessments, confirm that the plan was reviewed on its stated cycle and that approvals were recorded, not just the latest draft.

Testing and training calendars

A calendar shows which security and privacy tests and training events are scheduled, for which systems or roles, and by whom. Assessors compare it against the plans to see whether the stated activities are actually scheduled. Keep it in a system of record that retains prior versions, so the calendar as it stood during the assessment period can be shown.

Monitoring plans and their scope

Monitoring plans define what is watched, how often, through which tools and who responds to what. They should trace back to the continuous monitoring strategy and to the systems in scope. Check that monitoring coverage has tracked changes to the system inventory, since a plan that omits newly added systems will not show how monitoring was carried out.

Records of execution

Execution records are the results of tests, completed training, and monitoring reviews: scan reports, test reports, training completion data and review sign-offs. Records should link back to the plan item they fulfill and show the date, the performer and the outcome. Gaps between scheduled and completed activities should be documented with a reason and a follow-up, not left unexplained.

Review minutes tied to the risk strategy

PM-14 expects the plans to be reviewed for consistency with the risk management strategy and risk response priorities. Minutes from these reviews should record the risk strategy version referenced, the priorities discussed and any changes agreed. Confirm that the reviews happen at the cadence the organization defined, and that attendees include the officials accountable for the risk strategy.

Evidence of corrective changes

When testing, training results or monitoring findings show a gap, the plan should change or a corrective action should be tracked. Keep the link from the finding to the plan revision, the approval and the closure evidence. Between assessments, review open items for overdue actions, because an unresolved finding with no plan update is a common reason a PM-14 review stalls.

What meeting PM-14 costs in money and effort

This table breaks down the cost and effort components of meeting PM-14, who is paid for each, whether it is one-time or recurring, and what drives it up or down. NIST does not estimate compliance costs, so no figures appear here; use the rows to build a scope and ask for line-item quotes.

Cost component	Who is paid or who spends effort	One-time or recurring, and drivers
Writing the testing, training and monitoring plans	Internal governance and security staff, possibly an external consultant for drafting	One-time to create, then recurring to maintain. Drivers: number of systems in scope and how many plan types are separate documents
Annual review against the risk management strategy	Risk owners, CISO office, and whoever maintains PM-9 and PM-31 content	Recurring. Drivers: how often the risk strategy changes and how many risk response priorities must be reconciled
Training content and completion records	Internal trainers or a training vendor, plus LMS administration	Content is one-time with periodic refresh; records are recurring. Self-hosted LMS such as Moodle (GPL-3.0-or-later) can reduce licensing, but hosting and administration remain internal or contracted effort
Security and privacy testing	External testers, internal red or test teams, and tooling	Recurring per test cycle. Drivers: system count, testing depth, and whether testing is performed in-house or by an independent party. Ask for scope per system and retest terms
Monitoring tooling and log handling	Tool licensing or open-source hosting, security operations staff	Mostly recurring. Drivers: data volume, retention, and integration effort with the systems being monitored
Assessor sampling and evidence preparation	Independent assessor fees and internal staff who gather evidence	Recurring at each assessment. Drivers: the number of plans, test records and training records the assessor samples under the SP 800-53A procedures
Program governance and reporting to leadership	Senior accountable officials and program managers	Recurring. Drivers: reporting frequency and how many findings require tracking through POA&M processes

Who owns PM-14, what a partner does and what the auditor decides

Your organization owns PM-14. The control asks for a process that keeps plans for security and privacy testing, training and monitoring developed, maintained and carried out, and checks those plans against your risk management strategy and risk response priorities. Those judgments depend on your mission, your risk tolerance and your regulatory obligations, so they cannot be delegated to a vendor or a consultant. Internal owners also answer assessor interviews, and the SP 800-53A procedures for PM-14 include interviews with personnel who develop and maintain these plans.

Risk strategy and priorities: Set or confirm the risk management strategy and the risk response priorities that the testing, training and monitoring plans must be reviewed against (PM-9 and PM-28 feed this).
Plan approval: Decide who signs off on the annual testing, training and monitoring plans and record that approval.
Plan maintenance: Assign an accountable role to update plans when systems, threats or regulations change.
Resourcing decisions: Fund the testing and training activities and accept or reject residual risk from gaps.
Interview readiness: Make sure the named owners can explain how the process works in practice.

Confirm internally who holds each of these roles before any outside party is engaged, and write the assignments down.

Where PM-14 programs usually fall short

PM-14 is easy to document and hard to run. The gaps below tend to appear where plans, training records, monitoring output and the privacy baseline drift apart over time. Each card names one gap and the check that closes it.

Plans not reviewed against the risk strategy

Testing, training and monitoring plans are often written once and then left alone. PM-14 expects the plans to be reviewed for consistency with the organization's risk management strategy and risk response priorities, so a plan built before the latest risk strategy or priority change may test the wrong things. Check that each plan names the risk strategy version it was reviewed against, the reviewer, and the date of the last review. Ask who owns that review and what triggers an out-of-cycle update.

Training and testing scheduled but unrecorded

A calendar entry for a tabletop exercise or a role-based training course is not evidence that it happened. Assessors look for completed activity, the people who took part and the results, so gaps appear when sessions run without attendance or outcome records. Confirm that every planned activity produces a dated record with participants, the version of material used and any findings. Where a learning platform is used, confirm that completion settings reflect the actual requirement rather than simple page views.

Monitoring output not linked to plans

Security monitoring, vulnerability scans and assessment results can all run without feeding back into the testing and training plans. PM-14 links these activities, so a recurring finding in monitoring output should change what is tested or taught next. Check whether each monitoring finding has a path to the plan that owns it, and whether the plan is updated when a finding repeats. Ask the team to show one finding traced from detection to a change in a plan.

Privacy baseline systems left out

PM-14 is not allocated to the low, moderate or high security baselines, but it is part of the privacy control baseline, which applies to systems regardless of impact level. Programs that scope PM-14 only to security-categorized systems can miss systems that process PII. Confirm which systems fall under the privacy baseline, and make sure their testing, training and monitoring plans are written and carried out. Document the scoping decision so an assessor can see how the privacy baseline was applied.

Assessment evidence held in separate places

Plans may live in one repository, training records in a learning system, monitoring output in a SIEM and risk decisions in a spreadsheet. When an assessor asks how the four connect, the team spends days reconstructing them. Map where each artifact is kept, who can retrieve it, and how long it is retained. A self-hosted evidence store with consistent identifiers can keep the chain intact, but the organization still needs to decide which system is the record of truth.

Unclear ownership of the process

PM-14 covers organization-wide activity, yet responsibility is often split between security, privacy, HR and IT with no single owner for the process. Plans then drift, and no one notices that a training cycle or test program lapsed. Confirm which role is accountable for developing and maintaining the plans, which roles execute them, and who reviews them against the risk strategy. Record those assignments in writing so an interviewee can state them consistently.

PM-14 questions buyers ask before hiring help

How much effort does PM-14 take to meet?

The effort depends mostly on how many plans already exist and how well they are kept current. PM-14 asks for a process that makes sure plans for security and privacy testing, training and monitoring are developed, maintained and carried out, and that they are reviewed against the risk management strategy and risk response priorities. If the organization already has a testing calendar, a training plan and a monitoring plan tied to its risk strategy, the work is largely a consistency review and a documented review cycle. If those plans are scattered across teams or do not exist, the work is greater and falls mostly on the people who own each plan. Ask a partner to separate the one-time build of the process from the recurring review it needs.

How long does it take to get ready for a PM-14 assessment?

No supplied source gives a duration for PM-14 readiness, so the timeline should come from a written scope rather than a rule of thumb. The main drivers are the number of plan types in scope, whether the risk management strategy is current, and how many teams must agree on the plans. NIST's SP 800-53A Rev. 5 assesses PM-14 through 12 determination statements, using examine and interview methods, so an assessor will want to see the plans and speak with the people who maintain them. Ask the partner to show which artifacts must exist before the assessment window opens and which can be produced during it.

What does the work need from our team?

The organization owns its controls, so the team must provide decisions and access that no partner can supply for it. Expect to name owners for the security testing plan, the training plan and the monitoring plan, and to give them time to review drafts. The risk management strategy and risk response priorities are inputs to PM-14, so the risk function must confirm they are current. Someone must also be able to show how each plan is carried out, such as test reports, training completion records and monitoring reviews. Assessors interview the people responsible for these plans, so those people should be available and able to explain them.

Can we meet PM-14 ourselves without an outside partner?

Yes, an organization can meet PM-14 with its own staff if it has the risk, security and training ownership to write and maintain the plans. A partner adds value where the team lacks capacity, where the plans must be tied to a monitoring stack or learning platform, or where the work must be scoped and delivered on a fixed schedule. Be clear about the boundary: an implementation partner prepares plans and evidence, while only an independent auditor or assessor issues an assessment result. Ask whether the internal team can name the owner of each plan and produce the review records before deciding.

Which tools can produce evidence for PM-14?

Open-source tools can hold and report the evidence, but none of them decides whether PM-14 is met. CISO Assistant, licensed under AGPL-3.0-only, ships more than 200 frameworks, including NIST CSF and others, and can run audits and compliance assessments with automatic mapping between frameworks, which helps track PM-14 against its related controls. Moodle, licensed under GPL-3.0-or-later, has activity completion that records when a learner views, is graded on or ticks off an activity, which can serve as training evidence if the conditions are set to match the training plan. Confirm with each tool's documentation whether it fits your testing and monitoring workflow before you rely on it.

What should we ask a partner for in a fixed-scope PM-14 quote?

A fixed-scope quote should state in writing what is in scope and what is excluded. Ask for the list of plans to be built or reviewed (testing, training, monitoring), the review cycle that will be documented, and the interviews or walkthroughs the partner will prepare with your staff. Request the evidence set by name, such as plan documents, review records and completion logs, and the deliverables with their dates. Also ask who performs each task, what the team must supply, and how changes to scope are priced. DeployOpen agrees scope, deliverables and timelines in writing before work starts and does not publish a price list, so the quote follows from that written scope.

Does PM-14 apply to every system, or only the privacy baseline?

PM-14 is a program-level control, so it is not allocated to the low, moderate or high security baselines in SP 800-53B. It is included in the privacy control baseline, which applies to systems regardless of impact level. That means an organization handling PII should confirm that PM-14 is in its privacy assessment scope even if its security baseline does not list it. Ask the partner to map the control to your scope decision in writing so the assessment boundary is clear before work begins.

How DeployOpen prepares PM-14 evidence for your assessor

DeployOpen starts from the written, fixed scope agreed before work begins. For PM-14, that scope names which plans are in play: the organization's security and privacy testing plan, its training plan, and its monitoring plan, along with the owners of each and the systems they cover. We confirm with you which documents already exist, which are informal, and which have no owner. Each gap becomes a deliverable in the scope rather than an assumption. Because PM-14 asks for plans reviewed against the risk management strategy and risk response priorities, the scope also needs the current risk management strategy under PM-9 and the testing, training and monitoring decisions that trace back to it. Confirm early that these documents exist and who signed them.

Once the plans are settled, the evidence pipeline is built on self-hosted tools inside your environment. Training completion can be recorded in a self-hosted learning platform such as Moodle, where activity completion can be set to mark an activity complete when a learner views it, receives a grade, or ticks it manually, so you should decide and document which condition counts as training carried out. Testing and monitoring outputs are stored with dates, scope and reviewer sign-off, and the review record shows where test results were compared with the risk strategy. For compliance mapping, CISO Assistant can hold PM-14 alongside other frameworks and run assessments against them, though its outputs are working papers rather than an audit opinion. DeployOpen prepares these packages for the independent assessor, who alone decides whether the evidence meets the assessment procedures in SP 800-53A and issues any report.

How DeployOpen scopes and prepares PM-14 for assessment

DeployOpen is a Chainscore Labs company that plans, implements and documents self-hosted open-source platforms inside the client's own infrastructure. For PM-14, we prepare the testing, training and monitoring plans, systems and evidence that an independent assessor will examine, while the organization keeps ownership of the control and the assessor issues any findings.

How we scope

Written scope lists which testing, training and monitoring plans and programs are in and out of the PM-14 work.
We confirm which systems, business units and privacy processing activities the plans must cover for the organization.
Scope records who owns each plan, who approves it and how it links to the risk management strategy.

How we build

We draft or update the testing, training and monitoring plans against the organization's risk management strategy and risk response priorities.
We configure self-hosted platforms so training completions, test schedules and monitoring reviews leave dated records.
We map each of the 12 SP 800-53A determination statements for PM-14 to the artifact that will show it.

How we hand over

You receive the plans, configuration records, evidence index and a review log that show how plans were carried out.
Documentation names the owner, review cadence and approval steps so an assessor can interview the responsible staff.
We walk the assessor's likely examine, interview and test steps with your team before fieldwork, without issuing any assessment result.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work ends.
Retainers can keep the PM-14 plans current when risk strategy, systems or training content change.
Ask for the support terms, response expectations and handover responsibilities in the written quote before work starts.