PM-22: Personally Identifiable Information Quality Management

PM-22 requires you to establish and document organization-wide policies and procedures that keep personally identifiable information (PII) accurate, complete, relevant, and timely throughout its lifecycle. To operationalize it, assign ownership, define data quality rules and monitoring, build correction workflows, and retain evidence that the program runs as designed ¹.

Key takeaways:

• Treat PII quality as a governed program (policy + procedures + owners), not an ad hoc data-cleanup task ¹.
• Build repeatable workflows for validating, correcting, and propagating PII fixes across systems, not just within one application.
• Evidence must show operation: rules, logs, tickets, approvals, metrics, and remediation closure records.

The pm-22: personally identifiable information quality management requirement is one of the fastest ways for an assessor or customer to test whether your privacy program is operational or only documented. If your systems store PII that drives identity verification, benefits eligibility, access provisioning, payments, customer communications, or HR actions, bad data becomes a direct compliance risk. The result is predictable: misdirected notices, incorrect decisions, unresolved consumer requests, security control failures due to identity mismatches, and weak audit trails when you need to explain “why this record says that.”

PM-22 sits in NIST SP 800-53’s Program Management family. That matters because auditors commonly expect a control design that works across teams and systems, not a one-off checklist for a single database. “Organization-wide” is the operational keyword. You need a clear policy position on what “quality” means for PII, plus procedures that define how you prevent errors, detect errors, correct errors, and verify the corrections took effect everywhere that PII is used ¹. This page gives you a requirement-level build plan that a CCO, GRC lead, or Compliance Officer can put into motion immediately.

Regulatory text

Excerpt (as provided): “Develop and document organization-wide policies and procedures for:” ¹

Operator interpretation: PM-22 is a documentation-backed governance requirement. You must (1) define the organization-wide policy position for managing PII data quality and (2) document procedures that make the policy real in day-to-day operations ¹. Assessors will look for consistency across systems, roles, and lifecycle stages (collection, use, sharing, retention, disposal), and for evidence that the procedures run.

Plain-English meaning (what “PII quality management” means in practice)

PII quality management means you control the accuracy and integrity of PII so it is fit for the purposes you use it for. Practically, that translates into:

• Defined quality rules (what “valid” looks like for each PII element).
• Prevention controls (validation at collection and entry).
• Detection controls (monitoring and reconciliations that surface errors).
• Correction controls (workflows to fix PII and propagate fixes).
• Accountability (owners, approvals, and audit trails).

Who it applies to

PM-22 applies when you operate:

• Federal information systems that process PII ².
• Contractor systems handling federal data, including environments where PII is processed on behalf of a federal customer ¹.

Operationally, treat PM-22 as in-scope for any system, pipeline, or third party workflow that:

• Collects PII directly (web forms, call center intake, HR onboarding).
• Imports PII (file transfers, API ingestion, data brokers).
• Uses PII to make decisions (eligibility, identity proofing, access, fraud, payments).
• Stores PII in multiple places (CRM + ticketing + marketing automation + data warehouse).
• Shares PII with third parties (benefits administrators, background check providers, payment processors).

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

1) Create the PM-22 control card (make ownership and execution unambiguous)

Document a “control card” that an operator can run without interpretation. Minimum fields:

• Objective: Maintain PII quality so records are accurate and suitable for intended use.
• In-scope systems/data stores: List system names and PII domains (customer, employee, applicant).
• Control owner: One accountable owner in Privacy/GRC, plus system-level owners in IT/Data.
• Trigger events: New system onboarding, schema changes, new data source, incident, major migration.
• Cadence: Define how you run monitoring and reviews (your choice; keep it consistent).
• Exceptions: Who can approve exceptions, for how long, and required compensating controls.

This aligns to the recommended practice of a requirement control card with objective, owner, trigger events, execution steps, and exception rules ¹.

2) Define “PII quality” rules by data element and purpose

Build a lightweight PII Data Quality Standard that maps:

• PII element (name, DOB, SSN/ID number, email, phone, address, employee ID).
• Quality dimensions you will enforce (accuracy, completeness, validity, timeliness, uniqueness).
• Validation rules (format checks, allowable values, verification sources).
• Authoritative source (system of record) and downstream replicas.
• Allowed update paths (who can change it, via which system/workflow).
• Evidence generated (logs, tickets, approvals).

Keep the rules pragmatic. The goal is consistency and traceability across teams.

3) Implement prevention controls at collection and entry points

For each intake channel:

• Add field validation (format, required fields, checksum rules where applicable).
• Add identity matching rules to prevent duplicate identities where that matters.
• Add user-facing error handling that prevents partial or malformed records.
• For internal entry (HR, support), add guided entry and training plus UI controls that reduce free-text.

Document these as procedures tied to the policy.

4) Implement detection controls (quality monitoring and reconciliation)

Quality issues surface in predictable places. Set procedures for:

• Duplicate detection (same person, multiple identifiers).
• Stale record detection (records not updated when business rules require).
• Cross-system reconciliation (system of record vs downstream copies).
• Exception reporting (invalid formats, missing required fields, conflicting values).
• Third party data checks when PII comes from external sources (contractual correction paths).

Your monitoring can be manual, automated, or hybrid. Auditors care that it is defined, repeatable, and produces auditable output.

5) Implement correction workflows (ticketable, approved, and propagated)

Write a procedure that answers:

• How errors are submitted (user self-service, support ticket, internal discovery).
• How errors are triaged (severity, impact, identity verification steps).
• Who can approve changes to sensitive PII fields.
• How fixes are propagated to downstream systems and third parties.
• How you verify completion (post-change checks, reconciliation results).
• How you prevent reintroduction (root cause tagging and fixes to intake rules).

Make sure your workflow handles two hard cases:

• Conflicting sources: Two systems disagree on a value.
• Immutable audit needs: You may need history, but still correct the active record.

6) Define the minimum evidence bundle (what you must retain)

Create an evidence checklist per execution cycle (your defined cadence). Minimum bundle:

• Approved policy and procedures for PII quality management ¹.
• The control card (ownership, scope, triggers, exceptions).
• PII data quality standard (rules by element, authoritative sources).
• Monitoring outputs (reports, dashboards, query results, exception logs).
• Sample correction tickets with approvals, verification steps, and closure notes.
• Change management artifacts for data-quality rule changes (review/approval).
• Exception register with approvals and compensating controls.

This aligns to defining the minimum evidence bundle (inputs, approvals, output artifacts, retention location) ¹.

7) Run control health checks and remediate to closure

Set a recurring control health check that validates:

• Monitoring ran as scheduled.
• Exceptions were handled within your defined SLAs.
• Propagation checks worked.
• Metrics are reviewed by the owner.
• Corrective actions closed, with validation.

Track remediation items to validated closure with due dates ¹. Evidence of closure matters more than the initial finding.

Required evidence and artifacts to retain (audit-ready list)

Use this table as your “show me” package.

Artifact	What it proves	Typical owner
PM-22 policy	Organization-wide intent and governance	Privacy / Compliance
PM-22 procedures/runbooks	Repeatable operating steps	Privacy + IT/Data
Control card	Ownership, cadence, triggers, exceptions	GRC
Data quality standard for PII	Defined rules and authoritative sources	Data governance
Data flow / system inventory of PII	Scope is complete and current	Security architecture
Monitoring logs/reports	Detection control operates	Data engineering
Correction tickets + approvals	Corrections are controlled and traceable	Support/HR Ops
Propagation verification	Fixes reach downstream systems	IT Ops
Exception register	Deviations are approved and managed	GRC
Control health check results	Ongoing assurance	GRC/Internal audit

Common exam/audit questions and hangups

Expect these questions, and prepare the binder answers:

1. “Define ‘quality’ for PII.” Show your data quality standard and validation rules.
2. “Who owns PII quality across the enterprise?” Show the control card with accountable owner and RACI.
3. “How do you detect inaccurate PII?” Produce monitoring outputs and reconciliation procedures.
4. “Walk me through a real correction.” Provide a ticket with approval, verification, and propagation proof.
5. “How do you handle conflicts across systems?” Show authoritative source designation and dispute resolution steps.
6. “How do third parties correct PII you send them?” Show contract clauses or operational procedures for correction requests.

Frequent implementation mistakes (and how to avoid them)

• Mistake: Policy-only compliance. A well-written policy with no repeatable procedure fails quickly in an audit. Add runbooks and evidence bundles.
• Mistake: One-system thinking. Quality fixes that do not propagate create inconsistent identities and downstream errors. Map authoritative sources and replication paths.
• Mistake: No approval model for sensitive fields. Changes to high-risk identifiers need controlled approvals and verification steps. Define “protected fields” and enforce workflow checks.
• Mistake: Monitoring without remediation. Dashboards that nobody works are audit liabilities. Tie alerts to ticketing and closure validation.
• Mistake: Exceptions live in email. Build an exception register with approvals and periodic review.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite enforcement examples.

Operational risk is still concrete:

• Inaccurate PII can trigger incorrect identity decisions, misdirected communications, and failed access controls.
• Poor correction workflows can undermine consumer or employee trust and create audit trail gaps.
• In federal contracting contexts, weak PM-22 implementation increases the chance you cannot demonstrate programmatic control operation under assessment ².

Practical 30/60/90-day execution plan

Use phases without time estimates beyond the requested structure.

First 30 days (stabilize and define)

• Name the PM-22 accountable owner and system owners.
• Draft and approve the PM-22 policy and procedures (v1).
• Build the control card and scope the in-scope systems and PII domains.
• Define the initial PII data quality standard for the highest-impact fields.
• Stand up an evidence repository and the minimum evidence bundle checklist.

Days 31–60 (operate and instrument)

• Implement or tighten validation at primary intake points.
• Stand up monitoring for duplicates, invalid values, and cross-system conflicts.
• Implement correction workflows in a ticketing system with approvals and verification.
• Start the exception register and define exception review meetings.

Days 61–90 (prove sustained operation)

• Run the first control health check and document results.
• Close remediation items with validation evidence.
• Expand rules and monitoring to additional PII elements and systems.
• Test downstream propagation by sampling completed correction cases end-to-end.
• Prepare an audit-ready PM-22 evidence packet with a table of contents.

Ongoing (keep it alive)

• Treat schema changes, new data sources, and third party onboarding as trigger events for PM-22 updates.
• Review metrics, exceptions, and recurring issues, then fix root causes in intake, integration, or training.

Where Daydream fits (only where it earns its place)

If your biggest PM-22 blocker is proving “who owns it, how often it runs, and what evidence shows it ran,” Daydream can help by standardizing control cards, evidence bundles, and recurring control health checks across teams, so you can answer audits with a consistent packet instead of scrambling across tickets, dashboards, and shared drives.

Frequently Asked Questions

Does PM-22 require a specific data quality metric or threshold?

The provided PM-22 excerpt requires organization-wide policies and procedures, not a specific metric ¹. Define metrics that match your PII use cases and can be evidenced through monitoring outputs.

What’s the difference between PII quality management and data governance?

PM-22 is a control expectation focused on PII quality, enforced through documented policies and procedures ¹. Data governance is broader; you can implement PM-22 as a defined slice of your data governance program.

If we have one system of record, do we still need propagation procedures?

Yes, because most organizations still replicate PII into downstream systems for operations and analytics. Document how corrections flow from the system of record to copies, and retain verification evidence.

How do we handle PII quality when a third party is the source of truth?

Contractually and operationally define the correction path: how you dispute errors, expected turnaround, and how corrected values are transmitted. Keep tickets, communications, and updated records as evidence.

What evidence is most persuasive in an audit?

A clean chain from policy to procedure to outputs: monitoring reports, exception logs, correction tickets with approvals, and proof of closure. Pair that with a control card that shows ownership, cadence, and exceptions ¹.

Can PM-22 be owned by Security instead of Privacy?

It can, but the owner must have authority across data-producing teams and the ability to enforce procedures. Many teams use a shared model: Privacy/GRC owns the control, while IT/Data owns the technical monitoring and correction runbooks.

Footnotes

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

2. NIST SP 800-53 Rev. 5