PM-22 PII quality management: requirements and evidence

What PM-22 PII quality management asks your organization to do

PM-22 asks your organization to adopt organization-wide policies and procedures for PII quality: reviewing personally identifiable information for accuracy, relevance, timeliness and completeness across its life cycle, correcting or deleting inaccurate or outdated records, notifying the people and entities who received them, and giving individuals a route to appeal adverse decisions made on correction or deletion requests. For a privacy or compliance lead, the practical question is whether you can show that these rules exist, who runs them, and how they are applied in every system that holds PII, not just in the one system an assessor happens to sample. That organization-wide scope is why PM-22 is hard. Personal data is copied into CRM exports, data warehouses, support tickets, analytics extracts and test environments, and each copy has its own owner, or none. A correction made in the system of record often never reaches those copies, and the downstream recipients who received the old values are rarely tracked. Without a documented life-cycle view of where PII flows, a procedure for correction and deletion cannot be complete, and an assessor interviewing staff with privacy program responsibilities will quickly find the gaps.

PM-22 belongs to the Program Management family, which NIST deploys across the organization rather than per system. In SP 800-53B, PM-22 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. Confirm with your privacy office which systems fall within that privacy baseline for your environment, and whether any sector rule or contract adds further obligations on top of it. A useful first step is to ask for three things: the current PII life-cycle documentation, a sample of past correction or deletion notices, and a written appeals procedure with a named owner. If any of these does not exist, you have a planning item for your privacy program plan, not a gap you can fill by configuring a single system. An independent assessor will test these artifacts against the determination statements in SP 800-53A, so start by confirming where each one is kept and who can produce it.

Which PII, systems, teams and third parties PM-22 reaches

PM-22 is an organization-wide control, so its scope is set by where PII lives, who changes it and who receives it. The cards below cover the decisions that change the workload: which holdings are in scope, which copies need correction, which teams own accuracy and which outside recipients must be told. Confirm each decision in writing before you assign evidence owners.

PII holdings in scope

Start with an inventory of the PII holdings the organization processes, not only the systems of record. For each holding, record the purpose, the individuals affected and the decisions made from the data, because those decisions determine how much accuracy, relevance, timeliness and completeness matter. Ask whether the inventory aligns with the system inventory maintained under PM-5, since gaps between the two lists are a common source of uncorrected data.

Copies and data stores

Correcting a record in the source system often leaves stale copies in data warehouses, analytics extracts, backups, email attachments, test environments and caches. Map every store that holds a copy of each PII holding, and decide whether each copy is refreshed, purged or excluded from further use. Your procedures should state which copies are corrected directly and which are rebuilt from the source.

Teams that own accuracy

Accuracy usually splits across business owners who approve changes, privacy staff who decide on deletion and appeals, data teams who run pipelines and reconciliation, and support staff who take individual requests. Assign a named owner for each step and document the handoffs. Unclear ownership is the most frequent reason correction requests stall between teams.

Third parties that receive corrections

Processors, service providers and data recipients may hold PII you have already shared. PM-22 expects you to notify recipients of corrections or deletions, so build a register of outbound data flows with contact points and notification methods. Check the contract terms for each recipient, since they determine how quickly and in what form notifications must be sent.

Privacy baseline placement

In SP 800-53B, PM-22 is not allocated to the low, moderate or high security baselines. It appears in the privacy baseline, which applies to systems regardless of impact level. Confirm with your privacy office which systems fall under that baseline, because the obligation follows the PII processing rather than the system's security categorization.

Related controls and CSF mapping

PM-22 relates to PM-23 (data governance body) and SI-18 (PII quality operations), so decisions about data governance and quality checks in those controls should be reviewed together. NIST's CSF 2.0 crosswalk maps PM-22 to ID.AM-08 as an informative reference only, and NIST marks that crosswalk as not comprehensive. Use the mapping to orient the discussion, not to claim coverage.

How assessors test PM-22 PII quality management

This table maps the assessment methods in SP 800-53A to the objects an assessor asks for, the evidence that answers each request, and the gaps that commonly surface. Read it as a preparation checklist: for each row, confirm the evidence exists, is current and shows that the procedure is actually followed.

Assessment method	Assessment objects requested	Evidence an assessor expects	Where it usually fails
Examine: policy and procedures	Documented PII quality management policy and procedures at organization level	Approved policy with owner, review date and scope covering accuracy, relevance, timeliness and completeness	Policy is generic, names no owner, or was never approved by the privacy function
Examine: life cycle documentation	Information life cycle documentation showing where PII is created, updated, shared and deleted	Data flow or life cycle records tied to named systems and data owners	Life cycle records describe intended flows that differ from production systems
Examine: sample notices	Sample notices of correction or deletion sent to individuals or other entities	Notice templates plus a set of actual sent notices with dates and recipients	No notices can be produced, or samples show no link to a specific correction request
Interview: dissemination staff	Personnel with responsibility for disseminating privacy program information	Named roles, role descriptions and the assessor's own notes from discussions	Staff describe the process differently from the written procedure or are unaware of it
Test: data quality processes	Organizational processes for data quality and PII quality management procedures	Records of reviews, correction tickets, deletion logs and timeliness checks run on sample data	Procedures exist on paper but reviews are not performed or are not recorded
Test: appeals and adverse decisions	Handling of appeals on correction or deletion requests	Appeal log, decision records and evidence the outcome reached the requester	No appeal channel is documented, or appeals are logged without decisions

Implementing PM-22 in sequence, with the output of each step

This sequence turns PM-22 from a policy statement into a working organization-wide practice, where each step produces a record an assessor can examine. Read in order, the outputs build on each other, so the procedure reflects a verified PII inventory and the appeal path is tested before owners rely on it.

Inventory where PII is held and how it moves
Map each system, dataset, document store and third-party exchange that holds personally identifiable information, and record the life cycle stages for each: collection, use, storage, disclosure and disposal. Name a data owner for every entry, since owners carry the later review and correction duties. The output is a PII inventory with life cycle documentation that links each data set to its owner and recipients. The step is complete when the owners have confirmed their entries. Where an inventory already exists under PM-5(1), reuse it and confirm it covers the same life cycle detail.
Define quality criteria for PII
For each data category, write criteria for accuracy, relevance, timeliness and completeness that state what good data looks like and how it is checked. Relevance criteria should tie each field to the purpose it serves, so unnecessary fields can be flagged. Timeliness criteria should state which records go stale and what triggers review. The output is a criteria document signed off by the privacy lead and the data owners. It is done when every inventoried category has criteria and every criterion names a check an owner can perform.
Write and approve the organization-wide procedure
Draft the PM-22 procedure that sets out how reviews are scheduled, who performs them, how inaccurate or outdated PII is corrected or deleted, and how the organization records each decision. Keep the procedure at organization level so it applies across systems, and reference the criteria document rather than repeating it. The approved procedure, with version history and a named approver, is the primary policy evidence an assessor examines. Confirm the approval route with your governance body before publication.
Set the correction, deletion and notification workflow
Build the workflow that runs from a quality finding to a completed change: the request, the owner's decision, the correction or deletion, and the notice to each recipient that received the affected data. Record recipient lists from the inventory so notices can be sent and logged. Each workflow instance should produce a workflow record with dates, actor, change made and notices issued. Wiki or document platforms with version history can hold the procedure and records, but confirm the platform's audit trail meets your retention rules before relying on it.
Define the appeal path for adverse decisions
Specify how an individual can appeal a decision to refuse a correction or deletion request, who reviews the appeal independently of the original decision maker, and how the outcome is communicated back to the individual. Publish the route through the channels the organization uses for privacy complaints. The output is an appeal log that records each appeal, its reviewer, the outcome and the notice sent. An empty log is still evidence, provided the path is documented and the staff who would run it know their role.
Train the data owners and reviewers
Brief each data owner and reviewer on the criteria, the workflow and the appeal path, using the approved procedure as the training material. Cover what counts as an adverse decision and when an appeal must be routed onward. Record attendance and any written acknowledgement of responsibilities. The output is a training record linked to the named owners. This step is complete when every owner in the inventory has an entry, and gaps are escalated to the accountable official.
Run the first review cycle and record results
Apply the criteria to a sample of inventoried data, record each finding, and trace any finding through the correction, deletion or notification workflow to closure. Log open issues in the plan of action and milestones process where they cannot be fixed immediately. Compare the results with the procedure and update either the criteria or the procedure where the review shows gaps. The output is a review record with the sample, findings, actions and sign-off by the accountable official. Ask an independent assessor, when one is engaged, to examine this record as part of the evidence set.

Evidence that passes PM-22 and how to keep it current

PM-22 is tested by examining documents, interviewing staff and testing whether PII quality processes actually run. The cards below cover the artifacts that answer each assessment method, and each one needs a routine that keeps it dated, approved and traceable between assessments. Your organization owns these records; an independent assessor decides whether they are sufficient.

PII quality policy and procedures

This is the organization-wide policy and the procedures beneath it that set how accuracy, relevance, timeliness and completeness of PII are reviewed. Assessors examine it first, so it must name owners, review triggers and the systems in scope. Keep a dated approval record from the accountable privacy official, a review cadence you can show you follow, and a version history that lets an assessor see what changed and when. A document that has not been reviewed since it was written is a common finding.

Information life cycle documentation

Assessors look for documentation showing where PII enters, where it is stored, how it is used and when it is deleted. This is the map that makes the review step testable, because reviewers need to know which records to check and which downstream recipients must be notified of a correction. Keep the diagrams and data inventories tied to the system inventory, and record the date of each update so a reviewer can match the map to the systems that existed during the assessment period.

Sample correction and deletion notices

Examples of corrections and deletions carried out in practice show that the procedure works. Keep a sample set that covers different data types and both correction and deletion, with the request, the decision, the change made and the date. Assessors will ask whether the samples came from real activity, so record the source ticket or request reference. Redact individual details but keep enough metadata to trace each case back to the underlying system change.

Notification records to recipients

PM-22 requires notifying individuals or other entities that received inaccurate PII when it is corrected or deleted. The assessor will want evidence of who was notified, when and through which channel. Maintain a recipient list for each data flow, a log of notices sent and any notices that failed or were not sent, with a reason. Gaps in this log are easier to explain when they are recorded at the time than when reconstructed for an assessment.

Appeal records with decisions

Where an individual challenges a decision to refuse a correction or deletion, the appeal and its outcome must be recorded. Keep a case register with the original request, the appeal, the reviewer, the decision and the reasons. Confirm with your privacy office how appeal timelines are set, because no supplied source fixes them for your organization. A register with no entries is only persuasive if the intake channel is published and tested.

Training and responsibility records

Interviews test whether personnel with information dissemination responsibilities know the PII quality process and their role in it. Keep role descriptions that name the duties, training completion records tied to those roles, and attendance or acknowledgment records for procedure updates. Refresh these whenever the procedure changes or staff move roles, so the interview answers match the written process on the day of assessment.

What meeting PM-22 costs in money and effort

This table breaks down the cost and effort components of PM-22, who typically performs each one, whether it is one-time or recurring, and what drives it up. NIST does not estimate compliance costs, so the table names the drivers and questions to ask in a written quote rather than figures.

Cost component	One-time or recurring	Main cost drivers	What to ask for in a quote
Policy and procedure drafting for PII quality management	One-time, then periodic review	Number of privacy programs and business units covered, existing privacy policy maturity, legal review cycles	Named deliverables for the PII quality policy and procedures, review cadence, and who signs off
Data inventory and quality criteria work	One-time, then updated as systems change	Number of PII stores, data sources, and how much data lacks a documented life cycle	Scope of stores covered, the accuracy, relevance, timeliness and completeness criteria to be defined, and the inventory format
Engineering time for correction and deletion workflows	One-time build, then recurring maintenance	Number of systems holding PII, how many systems support record-level correction or deletion, integration with ticketing	Which systems are in scope, whether workflows are built or configured, and testing evidence delivered
Recipient notification mechanics	Recurring per event	Count of downstream recipients, number of third parties receiving PII, automation level of notices	How recipients are identified, how notices are logged, and whether notification templates are included
Appeal handling staff time	Recurring, varies with volume	Volume of correction or deletion requests, number of adverse decisions, reviewer seniority required	Expected handling steps, record-keeping for appeals, and how staffing assumptions are documented
Evidence upkeep (records of corrections, deletions and notices)	Recurring	Retention period set by the organization, number of records, how evidence is stored and versioned	Evidence list mapped to the assessment objects, storage location, and access controls on the records
External review, testing and auditor sampling	Recurring at each assessment cycle	Sample sizes the assessor selects, number of procedures tested, readiness of records	Who performs testing, what the independent assessor will sample, and whether a readiness review is included
Open-source licensing	Usually none for the platform itself	Choice of self-hosted tools and their support model	Confirm license terms for each component and any paid support or hosting costs separately
Internal labor for operating open-source tooling	Recurring	Administration, upgrades, backups and access management of self-hosted systems	Named operator roles, upgrade responsibilities, and whether a retainer covers ongoing support

Open-source tools that can hold PM-22 evidence

PM-22 is an organization-wide policy and procedure requirement, so much of its evidence is documentation: the PII quality procedures, their revision history and who approved them. The two tools below can host that documentation, but they only manage the record of how PII quality is handled. Correcting, deleting and notifying still happens in the systems that hold the data.

Version-controlled PII quality procedures

XWiki keeps every change to a page under version control, recording what changed, when and by whom. For PM-22, this gives an assessor a dated trail for the procedures covering review of accuracy, relevance, timeliness and completeness, and for correction, deletion and notification steps. Users can compare any two versions and roll back to an earlier one. Confirm that the revision history meets your retention rules and that exports of the history can be produced for an assessor.

Role-based owner approval

BookStack assigns user abilities through roles and lets you override permissions per role at the shelf, book, chapter or page level. You can give privacy officers edit and approval rights over the PII quality procedures while other staff can only read them. This supports the PM-22 expectation that named personnel own and maintain the procedures. Check that the role model matches your privacy governance, and record approvals outside the tool if your process requires signed sign-off.

Procedure content, not data correction

Neither wiki holds the data itself, so neither can correct or delete inaccurate PII, and neither sends notices of correction to recipients. Those actions need to be performed and logged in the systems of record, such as your CRM or case management platform, with their own audit trails. The wiki documents the steps and the decision owners. Confirm which system performs each correction step and link its log to the matching procedure page.

Appeal and notice templates

Sample notices of correction or deletion and the procedure for handling appeals of adverse decisions are the documents an assessor will ask to examine. Store each template as a versioned page with its approval date and the owner who signed it off. Templates kept this way show that notices follow a defined form. Ask your privacy counsel to review wording, because the wiki does not check whether a notice meets legal requirements.

Fit against your retention and workflow

Before choosing either tool, confirm how long procedure revisions must be kept, whether you need to export the full history for an assessor, and whether reviewers must approve changes in a fixed order. Also confirm that access to the instance is controlled and logged under your other controls. These checks decide whether a wiki, a document management system or a ticketing workflow fits your PM-22 evidence needs.

Who owns PM-22, who can help, and where the auditor draws the line

PM-22 is an organization-wide requirement, so the policies, procedures and accountability for PII quality sit with your organization and cannot be handed to a vendor. Your privacy and data governance leaders decide how accuracy, relevance, timeliness and completeness are reviewed, which data owners are responsible for each record set, and what happens when an individual appeals a correction or deletion decision. Those decisions reflect your legal obligations, business purpose and risk appetite, and an assessor will expect to interview the people who hold them.

Policy and procedure ownership: Approve the PII quality management policy and the procedures that implement it, and keep them current as systems and laws change.
Accountable officials: Name the senior official and the data owners who answer for PII quality in each business area.
Appeal decisions: Decide appeals of adverse correction or deletion decisions, and record the reasoning.
Notification judgments: Determine which recipients must be told about corrections or deletions and what the notice says.
Assessment readiness: Make staff with privacy program information dissemination responsibilities available for interviews, and keep the sample notices and life cycle documentation that an assessor will examine.

Confirm with your privacy office which of these roles already exist in your governance model before work begins.

Where PM-22 programs usually fall short

PM-22 programs tend to fail in the spaces between documents and systems: procedures nobody approved, copies of PII nobody tracks, and quality checks nobody measures. The cards below cover six gaps that assessors commonly probe, each with a closing action the organization can start now.

Procedures never approved or reviewed

PM-22 expects organization-wide policies and procedures for PII quality, so a draft wiki page that nobody signed does not meet the requirement. Check that the procedure has a named owner, a formal approval record and a review date. Assessors using SP 800-53A will ask personnel with privacy information responsibilities what the procedure says, so the approved version must be the one they actually use. Close it by routing the procedure through the privacy program's approval chain and recording the approver and review cycle in the document itself.

No inventory of PII copies

Inaccurate PII usually persists in places nobody remembered to check, such as exports, analytics extracts, backups and shared spreadsheets. PM-22 asks for review across the information life cycle, which means knowing where the data travels. Ask each data owner for a list of downstream copies, including third parties that received records. Close it by building a simple register of PII locations per data flow and linking each copy to the system of record that governs it.

Corrections that stop at the source

A correction fixed in the core system often never reaches the reporting warehouse, the CRM or a partner feed, so the same person has two versions of their record. Test one known correction end to end and see which downstream systems still hold the old value. Deletions carry the same risk, because a removed record can survive in a cache or archive. Close it by defining a propagation step for each correction type that names every dependent system and confirms it was updated.

No notification record to recipients

PM-22 requires notifying individuals or other entities when inaccurate or outdated PII is corrected or deleted. Without a record, an organization cannot show who was told, when, or what changed. Many teams send notices by email from a personal inbox and keep no evidence. Close it by logging each notification with the recipient, the correction made, the date sent and the delivery channel, and by keeping sample notices for the examine step.

Appeals with no defined path

PM-22 also covers handling appeals of adverse decisions on correction or deletion requests. When appeals arrive by phone, email or a support ticket with no owner, they are often lost or answered inconsistently. Assessors will look for a documented route, a decision maker separate from the original reviewer and a log of outcomes. Close it by publishing a single intake channel, assigning an appeal owner and tracking each case from request to final decision in one system of record.

Quality criteria never measured

Accuracy, relevance, timeliness and completeness are the four quality dimensions PM-22 names, yet many programs define them without any metric. A review that happens once and is never repeated gives no evidence of ongoing quality. Ask which field-level checks run, how often, and who sees the results. Close it by choosing one measurable check per dimension, such as the share of records with a verified date, and reporting the results to the privacy program on a set cadence.

Common questions about PM-22 cost, effort and outside help

Does PM-22 need its own system or tool?

No. PM-22 is an organization-wide policy and procedure control, so it does not require a dedicated system. It asks for documented rules on how PII quality is reviewed, corrected, deleted and appealed. Those rules can apply across the systems that already hold PII. Technical tooling only matters where it produces evidence, such as a versioned procedure, a log of corrections or a sample notice. NIST's Program Management controls are deployed across the organization and are not allocated to a system impact level, so the work sits with the privacy and security program rather than inside one application. Confirm with your privacy office which existing systems hold the PII in scope before deciding where records will live.

How much effort does PM-22 take and what drives it?

Effort depends mainly on how many systems and data flows hold PII, how mature the existing privacy program is, and how many correction or deletion requests the organization receives. NIST does not estimate compliance costs or set implementation timelines, so no figure can be taken from NIST for this control. The SP 800-53A assessment has 16 determination statements, which gives an assessor a defined set of points to examine, interview and test. Organizations with documented data life cycles and an established request process usually need less new work than those starting from scratch. Ask your team to inventory PII sources and count recent requests before estimating effort.

Can our team implement PM-22 without an outside partner?

Often yes, if the privacy office has authority over data quality and the engineering team can support record changes. The work is mostly governance: writing the procedure, assigning owners, defining review cycles and keeping evidence. An internal team can do this if it has someone who understands the life cycle of PII and can tie it to assessment objects such as policies, life cycle documentation and sample notices. A partner adds value where systems need technical work, such as building audit trails or change records in self-hosted platforms. Independent assessors, not implementation partners, test the control and issue any report.

What does the organization need to provide for PM-22?

The organization must supply the people and decisions that a technical team cannot make for it. Typical inputs include:

Data owners who confirm where PII is held, how it is used and how long it is kept.
Legal or privacy counsel who review notice wording, appeal rules and the criteria for correction or deletion.
Engineering time to build or adjust correction workflows, retention jobs and change logging in the systems that hold PII.
Business owners who handle appeals and who can explain adverse decisions.

Each of these roles should be named in the procedure. Without named owners, the evidence an assessor requests, such as records of notices or appeal outcomes, is unlikely to exist.

How long does PM-22 take to put in place?

The duration depends on the number of systems in scope, the state of current privacy documentation and how quickly decisions can be made. NIST does not set implementation timelines for SP 800-53 controls, and the federal timelines it references are set through OMB Circular A-130, not by NIST. As a general pattern, the policy and procedure work often moves faster than the technical changes, which depend on system owners' release schedules. Ask any partner to break the schedule into phases: scope confirmation, procedure drafting, system changes, evidence collection and assessment readiness. A fixed-scope agreement should state these phases in writing.

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

A fixed-scope quote should state exactly what is included and excluded. Ask the partner to confirm:

Which systems and PII data flows are in scope, and which are excluded.
The deliverables, such as a written procedure, correction workflow, notice templates and an evidence index.
Which work the partner performs and which the organization performs, including legal review and data owner sign-off.
The assumptions behind the quote and what triggers a change request.
Who prepares evidence and confirm that any audit or attestation is issued by an independent assessor.

DeployOpen agrees scope, deliverables and timelines in writing before work starts, and a quote follows from that written scope.

Does the privacy baseline require PM-22 for every system?

PM-22 is not allocated to the low, moderate or high security baselines, because it is a Program Management control. It is, however, part of the SP 800-53B privacy baseline, which applies regardless of system impact level. That means a system processing PII under the privacy baseline should be covered by the organization-wide PM-22 procedure. Confirm with your privacy office which systems fall under the privacy baseline and how the organization-wide procedure is referenced in each system's privacy documentation.

How DeployOpen scopes and prepares PM-22 evidence

DeployOpen works on PM-22 as an organization-wide program control, not as a single system setting. We prepare the systems, records and documented procedures that let your organization show how it reviews PII quality, corrects or deletes bad data and handles appeals, while your organization keeps ownership of the control and an independent assessor makes any judgment.

How we scope

Agree in writing which PII life cycle stages, systems and data stores fall within the PM-22 review scope.
Confirm which business units own accuracy, relevance, timeliness and completeness reviews, and who handles appeals.
Engagements are fixed-scope, so scope, deliverables and timelines are agreed before any work starts.

How we build

Configure a self-hosted wiki or documentation platform inside your own infrastructure to hold PM-22 policies and procedures.
Set up role-based permissions so data quality owners can edit procedures while reviewers and auditors have read access.
Build templates for correction, deletion and notification records that tie each change to a named owner and date.

How we hand over

Deliver the PM-22 procedure set, life cycle documentation and sample notice of correction or deletion records in your repository.
Map each deliverable to the determination statements in SP 800-53A so your assessor can trace evidence without guesswork.
Document the version history, access settings and open items so your team can run the process after handover.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Review the PM-22 procedures when your data inventory, privacy program or applicable laws change.
Confirm with your assessor and privacy officials which evidence they expect before the next assessment cycle.