PM-25: Minimization of Personally Identifiable Information Used in Testing, Training, and Research

PM-25 requires you to develop, document, and implement policies and procedures that control and minimize the use of personally identifiable information (PII) in internal testing, training, and research. Operationally, you need a rule set that prefers synthetic or de-identified data, restricts access and retention when real PII is unavoidable, and produces repeatable evidence for assessors. ¹

Key takeaways:

• Default to synthetic, masked, or de-identified datasets for testing, training, and research, and treat real PII as an exception.
• Put a documented approval path around “PII exceptions,” with technical safeguards, time-bound retention, and logging.
• Build assessor-ready evidence: a policy, a procedure, an inventory of non-production datasets, and proof that controls run in practice. ²

PM-25: minimization of personally identifiable information used in testing, training, and research requirement is one of those controls that fails in practice for a simple reason: engineering teams move fast, and “temporary” copies of production data become permanent fixtures in lower environments. For a CCO or GRC lead, the win condition is not a perfect data lab; it is a governed pathway that makes the safe option the default and makes exceptions visible, justified, and controlled.

PM-25 sits in the NIST SP 800-53 Program Management (PM) family. That matters because assessors typically expect organization-level direction (policy), repeatable execution (procedures), and consistent evidence across teams, not a one-off fix in a single application. The requirement text is short, but it implies a full operating model: dataset classification, environment scoping, de-identification standards, approvals, access controls, retention controls, and auditability.

This page gives you requirement-level implementation guidance you can put into motion quickly: who owns it, what steps to run, what artifacts to retain, what auditors ask, and where teams get stuck.

Regulatory text

Requirement (PM-25): “Develop, document, and implement policies and procedures that address the use of personally identifiable information for internal testing, training, and research;” ¹

Operator interpretation: You must have (1) a written policy and (2) an executable procedure that governs how PII may or may not be used in three contexts:

• Testing (QA, UAT, performance testing, troubleshooting, staging)
• Training (internal training, demos, onboarding labs, support enablement)
• Research (product analytics, experimentation, data science, model development)

“Implement” is the key word. A policy alone will not pass a serious assessment. Expect to show that teams follow the procedure, that exceptions are controlled, and that lower environments do not quietly become alternate production data stores. ²

Plain-English interpretation (what PM-25 really demands)

You are required to minimize real PII outside production use cases. In practice, that means:

1. Default position: Use synthetic data or de-identified/masked data for testing, training, and research.
2. Exception position: If a team claims they “need production data,” you require a documented justification, a risk review, and compensating controls (least privilege, environment boundaries, logging, retention limits, secure disposal).
3. Proof position: You can produce evidence that (a) non-production datasets exist and are governed, (b) access is controlled, and (c) exceptions are time-bound and reviewed.

Who it applies to

Entity scope: PM-25 is commonly applied across federal information systems and contractor systems handling federal data that implement NIST SP 800-53 controls. ¹

Operational scope (where it shows up):

• SDLC environments: dev, test, staging, QA, sandbox
• Data platforms: warehouses, lakes, notebooks, feature stores
• Security tooling: log aggregation, APM traces, SIEM test feeds
• Support tooling: ticket attachments, screen recordings, call transcripts used for training
• Third parties: testing vendors, training platforms, research partners (because “internal” programs often still rely on third-party tooling)

Control ownership (recommended):

• Primary owner: Privacy Officer / Security Governance (varies by org)
• Co-owners: Engineering Platform, Data Engineering, IAM, AppSec
• Approvers for exceptions: Data Protection Officer/Privacy, System Owner, Security

A practical model: assign a single accountable owner in GRC, but push day-to-day execution into the teams that provision datasets and environments.

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

Use this as your minimum viable operating procedure for PM-25.

1) Define scope: what counts as “testing, training, research”

Write a one-page scoping statement that names:

• Which environments are “non-production”
• Which tools are “training” (LMS sandboxes, demo tenants, enablement labs)
• Which activities qualify as “research” (analytics, experimentation, model development)

Auditors look for clarity because teams often argue an environment is “production-like” to bypass controls.

2) Set the policy rule: “No real PII by default”

In the PM-25 policy, state:

• Synthetic data is the default for testing/training/research.
• Masked or de-identified data is allowed when synthetic data is insufficient.
• Production PII in non-production requires an exception approval.

Keep the policy short. Put the operational details in the procedure. ¹

3) Create a data-handling standard for non-production datasets

Define approved dataset types and minimum controls:

Decision matrix (put this in your procedure):

Dataset type	Allowed uses	Minimum controls	Approval required
Synthetic	Testing, training, research	Basic access controls; standard retention	No (standard change controls only)
Masked / de-identified	Testing, training, research	Document method; restrict re-identification; limit fields	Yes (data owner + privacy/security review)
Production PII (raw or lightly filtered)	Narrow, time-bound troubleshooting only	Least privilege, encryption, logging, time-boxed retention, secure disposal	Yes (formal exception)

Don’t over-promise on “anonymization.” Use conservative language: masked/de-identified and document the technique.

4) Stand up an exception workflow (“PII in non-prod” request)

Build a simple intake that engineers will actually use. Minimum fields:

• Business justification (why synthetic/masked won’t work)
• Data elements requested (fields, record types)
• Environment(s) where data will reside
• Access list (named roles or individuals)
• Retention period and disposal method
• Controls to apply (masking, tokenization, encryption, logging)
• Approvals (system owner + privacy/security)

Make the exception time-bound and revocable. Tie it to ticketing so you can prove it happened.

5) Implement technical guardrails where the work happens

Your policy is not a control until guardrails exist. Prioritize:

• Access controls: restrict who can pull exports or snapshots from production; separate duties between DBAs and developers.
• Environment boundaries: prevent copy/paste replication paths into dev/test by default.
• Logging: log dataset creation, access grants, and exports for non-production PII.
• Retention controls: automatic deletion or lifecycle policies for approved datasets.
• Secure disposal: documented deletion steps, with evidence for exceptions.

If you can only do one thing quickly, lock down production export paths and require approvals for any PII movement into lower environments.

6) Inventory and labeling: know where non-production PII lives

Create and maintain:

• An inventory of datasets used for testing/training/research
• A label/tag for “contains PII” and “approved for non-production”
• Dataset owners

Assessors commonly ask, “How do you know developers aren’t using production data?” An inventory plus periodic attestations is a defensible start.

7) Train the teams that generate risk (short, targeted)

Focus training on:

• Engineers who request data
• Data scientists/analysts
• QA and performance testing teams
• Support teams creating training artifacts

Training content should match your procedure: what to do, how to request an exception, and what is prohibited.

8) Evidence cadence: make it repeatable

Decide what you will produce on a recurring basis:

• Exception report (open/closed requests)
• Sample of deletions/disposals completed
• Access review results for non-production systems containing PII
• Attestation from system owners that they comply with the non-production data rule set

Daydream note (earned mention): If you manage PM-25 across many systems, Daydream can track control ownership, map the procedure to each system, and collect recurring artifacts so evidence is ready when assessors ask.

Required evidence and artifacts to retain

Store these in your GRC repository with clear naming and dates:

1. PM-25 policy covering testing, training, and research ¹
2. PM-25 procedure (workflow, approvals, retention/disposal, logging expectations)
3. Non-production dataset inventory (with PII flags and owners)
4. Exception tickets/records with approvals and closure proof
5. Data masking/de-identification method documentation (what technique, where applied, who approved)
6. Access control evidence (role definitions, access lists, access review outputs)
7. Retention/deletion evidence (lifecycle policy configuration screenshots, deletion job logs, or disposal attestations)
8. Training completion or targeted enablement artifacts (slides + attendance or LMS record)

Common exam/audit questions and hangups

Expect questions like:

• “Show me your policy and procedure for PII in testing and training.” ¹
• “Where is your inventory of non-production datasets, and how do you label PII?”
• “Prove that production PII is not routinely copied to lower environments.”
• “How do you approve exceptions, and who signs off?”
• “How do you ensure data is deleted at the end of the approved period?”
• “Do third parties involved in testing/training receive PII, and under what controls?”

Hangups that stall audits:

• No single place where exceptions are recorded
• Teams claiming “we only use a subset,” with no proof of minimization
• Retention being “manual” without evidence that deletion happens

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Writing a policy that says “minimize” without a default rule.
   Fix: Make synthetic the default and require an exception for real PII.

2. Mistake: Treating masking as a checkbox.
   Fix: Document the method, the fields affected, and whether re-identification is possible in your environment.

3. Mistake: Forgetting training artifacts and support tooling.
   Fix: Include screenshots, recordings, ticket attachments, and demo tenants in scope.

4. Mistake: No retention mechanism.
   Fix: Put deletion into automation (lifecycle rules, scheduled jobs) and keep logs.

5. Mistake: “Internal” interpreted as “no third parties.”
   Fix: Map where third-party platforms are part of internal testing/training operations and apply the same minimization expectations contractually and technically.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. The practical risk is still straightforward: non-production environments often have weaker controls, broader access, and less monitoring than production. If real PII lands there, you widen the breach surface area and complicate incident response and disclosure analysis.

Practical execution plan (30/60/90-day)

Use phases (not time promises) so you can execute without committing to unrealistic dates.

First 30 days (Immediate stabilization)

• Assign PM-25 control owner and system-owner stakeholders.
• Publish the “no real PII by default” policy statement and the exception workflow.
• Lock down production export/snapshot permissions to a small, named group.
• Start an initial inventory of known non-production datasets and environments.

Next 60 days (Operationalize and prove)

• Implement tagging/labeling for datasets and environments that contain PII.
• Roll out masking/de-identification guidance and approved patterns.
• Begin periodic exception reporting and closure verification (deletion evidence).
• Add PM-25 checks to SDLC gates (change review questions, CI/CD templates, data request forms).

Next 90 days (Scale and audit hardening)

• Expand inventory coverage across business units and data platforms.
• Automate retention/deletion for approved non-production datasets.
• Run a tabletop exercise: “Engineer requests production PII for performance testing.” Validate approvals, controls, and disposal evidence.
• Centralize artifacts in Daydream (or your GRC system) so auditors can trace policy → procedure → execution → evidence.

Frequently Asked Questions

Do we have to ban production data in non-production environments to meet PM-25?

PM-25 does not say “ban,” but it requires policies and procedures that address use of PII in testing, training, and research. A defensible approach is “default deny with documented exceptions” so minimization is real. ¹

What counts as PII for PM-25 purposes?

Use your organization’s privacy definition of PII consistently across production and non-production. If teams can link data back to an individual in your context, treat it as PII and route it through the PM-25 procedure.

Are masked datasets always acceptable?

Only if you can explain the masking/de-identification method and control access to any keys, lookup tables, or side channels that could re-identify individuals. Document the method and require approval for masked datasets used beyond routine testing.

How do we handle log data used for debugging and training?

Treat logs as datasets that may contain PII and apply the same rules: minimize collection, redact where possible, restrict access, and enforce retention. Add explicit language in the procedure for APM traces, error payloads, and support attachments.

Does PM-25 apply to machine learning model training?

Yes when model training is part of “training” or “research” activities that use PII. Your procedure should cover feature stores, notebooks, and experiment tracking so PII does not spread into unmanaged workspaces. ¹

What evidence is most persuasive to an assessor?

A small set of items wins consistently: the policy, the procedure, an exception log with approvals, an inventory of non-production datasets, and proof of time-bound deletion for exceptions. Those artifacts demonstrate “develop, document, implement” in practice. ¹

Footnotes

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

2. NIST SP 800-53 Rev. 5