PM-6 Measures of performance: requirements and evidence

What PM-6 measures of performance requires and why it is hard to evidence

PM-6 requires the organization to develop, monitor and report on information security and privacy measures of performance. In NIST's framing these are outcome-based metrics that show how effective or efficient the security and privacy programs and their controls are. If you are the compliance lead or CISO, the test is whether your metrics can change a decision: funding, staffing, a risk acceptance or a priority in the remediation backlog. A program that runs without measures of this kind cannot tell whether it is working, and that gap is exactly what an assessor looks for when they test PM-6.

The difficulty is that most programs already report plenty of numbers, but they count activity: scans run, training completions, tickets closed, policies reviewed. Activity measures show that work happened. They do not show whether the program reduced exposure, shortened exposure windows or protected privacy data better than before. PM-6 is organization-wide rather than per system, so the measures must roll up across the security and privacy programs and the controls deployed across them, and they must link to the risk management strategy under PM-9. PM-6 is also part of the SP 800-53B privacy baseline, which means privacy measures of performance apply to systems regardless of impact level, a point many security-led programs miss.

To evidence PM-6, confirm three things with your own records: who develops and approves the measures, how often they are monitored and by whom, and where results are reported and acted on. The SP 800-53A procedures assess this through examining the measures themselves, interviewing the people who run them and testing the process that produces and reports them. Ask your team to show one measure, its last three reporting cycles and a decision that changed because of it. Where that chain is missing, the gap is the finding to plan for.

Which programs, teams and data sets fall under PM-6 measures

PM-6 applies at the organization level, so its scope is set by which programs exist and who feeds them data, not by any single system. The cards below separate the programs that need measures, the teams that produce the data, the feeds that come from tools and third parties, and the controls that consume the results.

Security and privacy programs in scope

PM-6 covers both the information security program and the privacy program, so each needs its own set of measures of performance. Confirm that the security measures reflect the organization-wide security program and that the privacy measures reflect the privacy program, rather than assuming one set of metrics serves both. Write down which program owns each measure so an assessor can trace it to a decision.

Teams that produce metric data

Security operations, IT operations and the privacy office each generate data that PM-6 metrics depend on, such as incident handling times, patch status and privacy request handling. The SP 800-53A procedures expect personnel who develop, monitor and report these measures to be identified and interviewed. Confirm who owns each data source, who reviews it, and who signs off on the reported results.

Tool and third-party data feeds

Many measures come from scanners, ticketing systems, logging platforms and external service providers rather than from staff. Each feed should be listed with its owner, its collection method and its reliability, because a metric is only as sound as the data behind it. Ask whether the feed is complete, whether it can be exported for review, and whether a change to the tool would break the metric.

Process records behind each metric

The assessment procedures for PM-6 examine processes for developing, monitoring and reporting measures, not only the numbers. Define how each metric was chosen, how often it is calculated, how exceptions are handled and where results are reported. These process records are often the evidence an assessor asks for first, so keep them current.

Privacy baseline applicability

PM-6 is not allocated to the low, moderate or high control baselines, which apply by system impact level. It is included in the privacy baseline, which applies to systems regardless of impact level. Confirm which systems process PII and therefore fall under the privacy baseline, because that determines whether PM-6 privacy measures must be in place for them.

Feeds into CA-7 and PM-9

The related control CA-7 uses measures in continuous monitoring, so the same metrics should drive monitoring decisions and assessment follow-up. The related control PM-9 covers the organization-wide risk management strategy, which should use the results to review risk tolerance and priorities. Document where each measure is used in these two processes so the connection is visible to an assessor.

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

This table breaks down how an assessor works through PM-6 using the SP 800-53A Rev. 5 methods of examine, interview and test. Read each row as one assessment activity, what the assessor looks for, and the evidence that usually shows it.

Assessment activity	What the assessor checks	Evidence usually requested
Examine: measures of performance	Whether information security and privacy measures of performance are documented and defined, with clear purpose and outcome focus	Metrics register, metric definitions, targets, data sources and owners for each measure
Examine: privacy measures	Whether privacy measures of performance exist alongside security measures, since PM-6 is in the privacy baseline	Privacy metric definitions, linked privacy program objectives and recorded baselines
Interview: responsible personnel	Whether named staff who develop, monitor and report the measures can explain what each metric shows and how it is produced	Role descriptions, RACI entries, and the walkthrough of one metric from data source to report
Test: development process	Whether a repeatable process exists to create, approve and revise measures as programs change	Documented metric development procedure, approval records and revision history
Test: monitoring process	Whether measures are collected and reviewed on a defined schedule and anomalies are followed up	Monitoring schedule, dashboards or exports with dates, and tickets raised from threshold breaches
Test: reporting process	Whether results reach the defined officials and feed decisions on the risk strategy and resourcing	Report distribution lists, dated report versions and minutes showing review and decisions
Common finding: no target	Metrics reported without a defined target, threshold or baseline, so results cannot show effectiveness	Ask for the target and its approval date for every reported measure
Common finding: no cadence	Measures reported irregularly or without a stated reporting frequency	Confirm the monitoring and reporting frequency in the procedure and a sample of dated outputs

Implementing PM-6 measures step by step

This sequence turns PM-6 from a policy statement into a working cycle: defined programs, owned metrics with data sources, targets, a reporting rhythm, and results that feed risk strategy and continuous monitoring. Each step names the artifact it produces so an assessor can trace the chain from objective to report.

Define the programs and outcomes to measure
Start by listing the information security and privacy programs in scope and the outcomes each one is meant to achieve, such as reducing exposure to known vulnerabilities, shortening access review cycles, or keeping privacy complaints resolved within the defined process. The senior security and privacy leaders, with the risk function, agree the list and approve it. The output is an outcome statement for each program, approved and dated. The step is done when every outcome can be stated as an effect on risk, not as an activity count.
Select metrics with named owners
For each outcome, choose a small set of measures of effectiveness or efficiency and write down the question each one answers. Assign an accountable owner who can explain the number and act on it. Avoid metrics that only count tasks completed, because they show activity rather than results. The output is a metrics register that records the metric name, definition, calculation, owner, outcome it supports and the control or process it reflects. The register is complete when no metric lacks an owner.
Map each metric to its data source
Trace every metric to the system, record or person that produces its underlying data, such as a vulnerability scanner export, an identity provider report, a ticketing system or a training platform. Note who can access the source, how often it refreshes and where its known gaps are. The output is a data source map linking each metric to its origin, extraction method and data owner. Confirm each source with its owner before the metric is treated as reliable, since a measure built on unverified data will not hold up in assessment.
Set targets and reporting frequency
Agree a target or threshold for each metric and the frequency at which it is measured and reported. Record the rationale for each target against the risk strategy, and state what happens when a result falls outside it, including who is told and by when. The output is a reporting calendar and a target record that the accountable officials have approved. Revisit targets when the risk strategy or the systems in scope change, and record each change so the history is visible to assessors.
Automate collection where feasible
Where a data source can export results on a schedule, script the collection and store the outputs with timestamps so each measurement can be reproduced. Manual collection remains acceptable where automation is not practical, but the steps and the person responsible must be documented. Confirm with each tool vendor which exports and APIs its current version provides. The output is a collection procedure per metric and a retained set of raw extracts. The step is done when a sample measurement can be regenerated from its source by someone other than the original collector.
Run the review and reporting cycle
At each scheduled interval, the metric owners review results against targets, document the explanation for any miss, and agree corrective actions with dates and owners. The reviewed results go to the officials who approve the security and privacy programs. The output is a dated report with trend lines, exceptions, decisions and the status of prior actions. Retain each report as evidence that the organization monitored and reported the measures, and that results led to decisions.
Feed results into PM-9 and CA-7
Pass persistent or significant results to the risk management strategy under PM-9, where they can change risk tolerance, priorities or resourcing decisions. Feed system-level monitoring results into the continuous monitoring activities under CA-7 so that trends in individual systems are visible in the organization-wide picture. The output is a documented handoff, such as an updated risk register entry or a monitoring finding, that cites the metric that triggered it. The step is complete when at least one result can be traced from the metric to a risk decision or monitoring action.
Review the measures themselves
Periodically test whether the metrics still measure the outcomes they were chosen for. Remove measures that no longer inform decisions, add measures where the risk picture has shifted, and correct data sources that have changed. Record each change with the reason and approval. The output is a revision log for the metrics register and the data source map. This review keeps PM-6 aligned with the program rather than becoming a fixed reporting exercise.

What makes a measure outcome-based rather than activity-based

PM-6 asks for measures of performance for the information security and privacy programs, and the discussion describes these as outcome-based metrics of how effective or efficient the programs and their controls are. The distinction that matters is between a measure of what the program achieved and a count of what the program did. A count of scans run, tickets opened or training sessions delivered shows activity. It does not show whether risk went down. An outcome measure links a result to a target, so an assessor can see whether the program is meeting the objective it was funded to meet.

Illustrative example: a program might track the number of vulnerability scans completed each month, which is an activity count. An outcome-based version would track the share of critical vulnerabilities on in-scope systems remediated within the target window defined in the organization's risk strategy, with the list of systems that missed the target and the reason for each miss. Before adopting any metric, confirm the target and its owner in the organization's own documents, because NIST does not set numeric targets for PM-6. The organization chooses them under its risk management strategy (PM-9) and its continuous monitoring strategy (PM-31).

Assessors test PM-6 by examining the measures, interviewing the people who develop, monitor and report them, and testing the processes that produce them, as the SP 800-53A procedures describe. The question they ask is whether a measure changed a decision. Look for dated reports where a metric crossed a threshold, followed by a recorded action such as reallocating remediation staff, changing a control's frequency, or updating a plan of action and milestones (see PM-4). Metrics that appear in reports but never trigger a decision are a common finding. Build the evidence trail before the assessment, so each reported measure links to the decision it informed.

Evidence that satisfies PM-6 and how to keep it current

PM-6 is assessed by examining the measures themselves, interviewing the people who run them, and testing the process that develops, monitors and reports them. The cards below list the artifacts that show each part of that process and how to keep them current between assessments.

Metrics catalog with definitions

The catalog is the central record of each information security and privacy measure of performance. For each metric, record the question it answers, the formula, the target or threshold, the reporting frequency and the control or program objective it supports. An assessor examining PM-6 will look for measures tied to outcomes rather than activity counts, so check that every entry explains what decision it informs. Keep the catalog under version control so changes to definitions are traceable.

Named owners for each measure

Each metric needs an accountable owner who develops it, monitors it and signs off on its reporting. Record owner names and roles in the catalog, and confirm during the interview that the owners can explain how the figure is calculated and what drives it. Review ownership when people change roles, because a metric with no current owner is one assessors will flag as unmanaged.

Data source records

Metrics are only as credible as the systems that produce them. Document where each figure comes from, such as a ticketing system, scanner export, identity platform or log store, along with the extraction query and the date of each pull. Keep a short note on known gaps, such as systems not yet covered by a data feed. Periodic checks that the source still produces the same numbers help show the measure is tested, not just stated.

Dashboards and exported reports

Keep a dated copy of each dashboard view or exported report that was shared with leadership. A live dashboard alone does not show what was reported at a given time. Archive exports in a fixed folder structure, labeled with the period covered and the metric version used. Compare exports across periods to show trends, which is what outcome-based measurement looks like in evidence.

Review minutes and attendance

Meeting minutes showing that leadership or the governance body reviewed the measures are direct evidence of monitoring and reporting. Record the date, attendees, the metrics presented, the questions raised and any actions agreed. Minutes that show a reviewer challenging a figure are stronger than minutes that only confirm a briefing took place. Store them next to the reporting calendar so the cadence is visible.

Decisions and resource changes from results

The strongest evidence shows that results changed something. Keep records of decisions, funding requests, control changes or plan of action updates that followed from a measure, linking each back to the metric that triggered it. If a metric showed no action was needed, record that conclusion too. Confirm with your assessor which decision records they expect to see for the period under review.

What meeting PM-6 costs in money and effort

This table lists each cost component of running PM-6 measures of performance, who is paid for it, whether it is one-time or recurring, and what pushes it up or down. Use it to structure a quote request and to separate internal effort from outside spend. No dollar figures or durations are given because none were supplied for this control; ask for them in writing against your own scope.

Cost component	Who is paid or who spends effort	One-time or recurring	What drives the cost
Metric design and definition	Internal security and privacy leads, sometimes with an outside consultant	One-time, with periodic revision	Number of programs in scope and how many outcome measures each program needs
Data pipeline engineering	Internal platform or engineering staff, or an implementation partner building the feeds	One-time build, then recurring maintenance	Number of data sources (ticketing, scanners, identity, logging) and how much normalization they need
Metrics owner time	Internal control owners who collect, validate and explain each measure	Recurring	How often measures are reported and how many owners must sign off on each result
Reporting and review effort	Internal governance staff preparing dashboards and reports for senior officials	Recurring	Reporting cadence, audience count and whether reports are assembled by hand or generated
Tooling licenses	Software vendors, if commercial dashboards or GRC platforms are used	Recurring, usually per user, module or entity	Commercial versus self-hosted tooling and the number of licensed seats or modules
Self-hosted open-source tooling	Infrastructure costs in your own environment and staff time to operate it	Mostly recurring infrastructure and support time, with no license fee for the software itself	Hosting footprint, upgrade and backup effort, and internal skills to maintain it
External readiness or review support	Outside advisers or an implementation partner who prepares evidence and tests the reporting process	Usually one-time per readiness exercise, sometimes recurring	Fixed-scope versus retainer terms, and how much of the reporting is handed over
Independent assessment	Independent assessor or auditor, engaged by the organization	Recurring at the assessment cycle	Scope of the assessment, number of programs examined and how mature the evidence trail is

Who owns PM-6, what a partner prepares and what the auditor tests

Your organization owns PM-6 in full. The control asks that you develop, monitor and report on measures of performance for the information security and privacy programs, and the choice of what to measure is a management decision tied to your risk strategy and mission. Only your people can decide which outcomes matter, what good looks like and what happens when a result falls short. A partner can propose a metric set, but the accountable officials must adopt it, set targets and sign off on reporting.

Metric selection: Decide which outcome-based measures reflect the effectiveness or efficiency of the security and privacy programs and their controls, and record why each one was chosen.
Targets and thresholds: Set the target values and the trigger points that prompt a decision, and document who approved them.
Reporting cadence and audience: Define who receives results, how often, and which decisions the reports are expected to support.
Response to results: Assign owners for acting on metrics that miss target, including linking gaps to plans of action and milestones under PM-4.
Policy and procedure ownership: Keep the measurement process documented and reviewed so that it survives staff changes.

Before engaging any outside party, confirm that a named internal owner can answer for every metric in an assessment interview.

Where PM-6 programs usually fall short

PM-6 is easy to satisfy on paper and hard to satisfy in practice. The gaps below tend to appear together: metrics exist, but nobody owns them, they measure activity, and they never reach a risk decision. Each card names one gap and the action that closes it.

Metrics without owners or targets

A dashboard full of numbers with no named owner and no agreed threshold cannot show whether the program is working. For PM-6, each measure needs a responsible role, a defined target or tolerance, a data source and a reporting frequency. Check whether every metric in your program record names a person or role who answers for it and states what result counts as acceptable. Action: assign an owner and a target to each measure before the next reporting cycle, and record both in the measure definition.

Measures that count activity

Counts of scans run, training sessions held or policies signed show that work happened, not that the program achieved its objectives. PM-6 asks for outcome-based measures of effectiveness or efficiency, so a measure should tell you whether a risk got smaller or a process got faster. Check a sample of your measures and ask what result would change if the activity doubled or stopped. Action: rewrite each activity count as a paired outcome measure, such as the time to remediate critical findings or the share of systems with current authorization.

Privacy measures missing from the program

Many organizations track only security measures, even though PM-6 covers both information security and privacy measures of performance. The privacy baseline in SP 800-53B includes PM-6, so privacy measures are not optional for systems that process PII. Check whether your measure set includes indicators from the privacy program, such as completion of privacy impact assessments or handling of privacy complaints. Action: add a privacy measure set with its own owner, alongside the security set, and report both together.

No evidence of review

Assessors test PM-6 partly through interviews and by examining whether measures are monitored and reported. A measure set that was written once and never revisited shows no monitoring process at all. Look for dated reports, meeting minutes where results were discussed and records of decisions taken from those results. Action: set a review cadence for each measure, keep dated reports, and record who reviewed the results and what they decided.

Metrics disconnected from risk decisions

PM-6 measures are meant to inform the organization's risk choices, and PM-9 sets the risk management strategy those choices follow. When measure results never reach risk acceptance, funding or treatment decisions, the program reports numbers that change nothing. Check whether each measure can be traced to a risk in the risk register and whether results have led to a documented decision. Action: link every measure to a PM-9 risk statement and require that threshold breaches go to the officials who own that risk.

Data sources that cannot be trusted

A measure is only as reliable as the system that produces it. Metrics pulled from manual spreadsheets, or from tools whose coverage is incomplete, can look precise while missing large parts of the environment. Confirm where each figure comes from, how often the source is refreshed and whether its coverage matches the systems in scope. Action: document the data lineage for each measure and state known coverage gaps in the report, so readers can judge the result.

PM-6 questions buyers ask before bringing in help

How much effort does PM-6 take to meet?

PM-6 takes sustained effort rather than a one-time project, because it asks for measures to be developed, monitored and reported over time. The first phase is definitional: agreeing which outcomes matter, how each measure is calculated, who owns the data and how often results go to leadership. The recurring phase is the reporting cycle, where data is collected, reviewed and acted on. Effort rises with the number of systems, data sources and reporting audiences. Ask any partner to show the measure definitions, data sources and reporting calendar they expect the organization to maintain, and estimate the staff time for each in writing before agreeing a scope.

Can we build PM-6 measures in-house?

Yes, many organizations do. PM-6 is an organization-level control, so the people who already run security and privacy operations, and who can pull data from their tools, are usually well placed to define the measures. The harder parts are choosing outcome-based measures rather than activity counts, agreeing targets with leadership and keeping the reporting process running. An outside partner can help with the design and the tooling, but the organization still owns the measures, the targets and the decisions made from them. If internal staff lack time or experience with metrics design, scope that gap explicitly in any engagement.

How long does it take to build a PM-6 metrics program?

No duration is given here because the timing depends on the factors that drive it, not on a fixed figure. The main drivers are how many programs the measures must cover, whether reliable source data already exists, how many approvals the targets need and how mature the current reporting is. A program with clean data in existing tools and a small set of agreed measures moves faster than one that must first create data collection. Ask for a milestone plan with named dependencies, such as data access, leadership sign-off and the first reporting cycle, and confirm which of those the organization must supply.

What does the team need to provide for a PM-6 engagement?

The team needs a named owner for the security and privacy programs, access to the systems that hold relevant data, and time from people who run controls day to day. Leadership must also agree which outcomes matter and what targets mean. In practice this means:

A decision-maker who approves measure definitions and targets
Data owners in security operations, IT, privacy and risk who can confirm figures
A reporting audience that will act on the results
Documented processes for how results are collected and reviewed

If any of these are missing, the measures will be hard to defend in an assessment, so resolve them before the design phase begins.

Can an auditor help us build PM-6 metrics?

No. An auditor or assessor tests the control independently and should not design the measures it will later examine, because that would compromise its independence. Assessors under SP 800-53A examine the measures, interview the personnel who develop and report them, and test the processes behind them. An implementation partner can prepare the measures, data flows and reporting records so that they are ready for that testing, but only the independent assessor reaches a conclusion about whether the control is met. Ask any firm to confirm which role it plays before you engage it.

How does PM-6 relate to the privacy baseline?

PM-6 is not part of the low, moderate or high security baselines, because Program Management controls sit at the organization level and are independent of system impact level. It is included in the SP 800-53B privacy baseline, which applies to systems regardless of impact level. This means that a system processing personally identifiable information must have privacy measures of performance supporting its privacy program, in addition to the security measures. Teams should confirm with their assessor how privacy and security measures are reported, and whether one dashboard can satisfy both sides of the control.

Which SP 800-53 controls connect to PM-6?

The SP 800-53 Release 5.2.0 catalog lists CA-7 and PM-9 as related controls. CA-7 covers continuous monitoring, which supplies much of the data that measures draw on. PM-9 covers the organization-wide risk management strategy, which should guide which outcomes are worth measuring. Reviewing these three controls together helps keep measures tied to monitoring activity and to stated risk tolerance. Confirm the current related-control list in the official catalog before drafting your evidence matrix.

How DeployOpen scopes and prepares PM-6 evidence

DeployOpen starts PM-6 work with a written, fixed-scope agreement that names the security and privacy measures of performance in scope, the systems and data sources that feed them, the teams that develop, monitor and report on them, and the reporting cadence leadership expects. Because PM-6 is an organization-wide program control rather than a per-system control, the scope document should state which business units, platforms and privacy processing activities the metrics cover, and who signs off on that boundary. Deliverables and timelines are agreed in writing before work begins. The organization keeps ownership of its measures, its risk decisions and its control statements. DeployOpen prepares the systems and evidence; it does not issue audit reports, attestations or certifications, and an independent assessor or certification body makes those determinations.

Inside the client's own cloud accounts, data centers or air-gapped networks, the technical work usually covers three things: collection pipelines that pull data from existing scanners, ticketing, identity and logging sources; a metrics layer that calculates each measure with a documented definition, owner, data source and target; and dashboards plus a recurring evidence pack that shows the measure values, the trend, the actions taken and the sign-off record. The evidence pack is where a PM-6 assessor will look first, so each metric should carry its calculation logic, the period it covers and the reviewer's name. Confirm with your own team which source systems can export data in a form the pipeline can read, and whether the monitoring tools you plan to use have the capabilities you need. Do not assume a platform produces a given metric until you have tested it in your environment.

During the assessment, DeployOpen supports the client's staff in walking the assessor through the process for developing, monitoring and reporting measures, which is the object the SP 800-53A procedures test, and in showing interview evidence from the people who run that process. Ask your assessor early which evidence formats they accept, how they want the metric definitions versioned and whether they will sample past reporting periods. Retainers can cover ongoing metric maintenance and changes to the reporting cycle after the initial engagement. For the standard's control text and its assessment procedures, use the NIST CPRT catalog entry for PM-06 and confirm your assessor's expectations against it.

PM-6 Measures of performance