What PM-25 asks for when developers copy production data into test environments
Engineering teams often want a copy of production data because it reproduces real edge cases, while privacy staff want as little personally identifiable information (PII) as possible outside production. PM-25 is the control that settles this tension at the organization level. It asks for documented policies and procedures covering the use of PII in internal testing, training and research, for that PII to be minimized, for its use to be authorized only where it is necessary, and for those policies and procedures to be reviewed and updated at a defined frequency. The control does not ban production data in test environments. It requires a decision process that the organization can show an assessor it actually follows.
PM-25 sits in the Program Management family because it is meant to be deployed once across the organization, not configured system by system. SP 800-53B treats PM controls as organization-wide and independent of impact level, so PM-25 is not allocated to the low, moderate or high baseline. It is included in the privacy baseline, which applies to systems regardless of impact level. A system that processes PII therefore needs PM-25 evidence even if its security impact rating is low. Ask your privacy office which organization-wide policy carries this control and whether your environments are covered by it.
The difficulty is practical. Test data is copied through pipelines, database refreshes, support tickets and laptops, so minimization fails quietly unless someone owns each path. A useful first step is to inventory which non-production environments receive production extracts, who approves each copy, and whether masking, subsetting or synthetic generation is applied before the data lands. Evidence an assessor will ask for includes the policy, the approval records and a sample of refresh logs. Independent assessors test whether the process works, while the organization owns the decisions. Implementation partners can help build the pipeline controls and collect the records, but they cannot certify that the control is met.
Which test, training and research data sets fall under PM-25
PM-25 applies wherever personally identifiable information leaves production and enters a development, training or research setting. The cards below list the data sets and third-party copies that most often fall into scope, and the decision each one forces. Because PM-25 sits in the privacy baseline rather than the security baselines, scoping starts from where PII is used, not from the system impact level.
Production extracts used for QA
Test teams often copy production tables or files to reproduce defects or check releases. Each copy is a PII use that PM-25 requires the organization to justify, minimize and authorize. Check whether the extract includes names, contact details, account numbers or free-text fields, whether it is refreshed on a schedule, and who holds the only record of when it was created and deleted. The question to answer is whether a masked or synthetic set would reproduce the defect.
Analytics sandboxes and shared workspaces
Analysts frequently receive broad read access to warehouses or sandboxes built from operational data. These environments are easy to forget during scoping because they are not labeled as test systems. Inventory each sandbox, record which PII fields it holds, and confirm that the business purpose for each field is documented and approved before the copy exists.
Training material and classroom exercises
Security awareness labs, onboarding sandboxes and classroom exercises often reuse realistic-looking records. Trainees usually have wider access than their roles require, and training copies persist after the course ends. Confirm that exercise datasets are fictional or minimized, that course materials contain no live identifiers, and that the training environment is covered by the same deletion schedule as other test data.
Research and model development datasets
Research datasets are often assembled from several sources and kept for years, which makes them hard to minimize after the fact. Records should show the research question, the fields that question needs, the approval for each use, and the review date. If a dataset feeds model training or evaluation, document whether identifiers were removed before training begins and whether the set can be reproduced without them.
Vendor-hosted test tenants
Test environments hosted by SaaS providers, integration partners or outsourced testers can hold PII outside the organization's own boundary. Such tenants are often provisioned by a project team and never added to the system inventory. Ask each provider where test data is stored, how long it is retained, whether it is used for the provider's own purposes, and how deletion is evidenced.
Third parties that receive copies
Consultants, offshore development teams and tool vendors sometimes receive data extracts for debugging, benchmarking or migration rehearsals. Each recipient extends the PII footprint that PM-25 covers. Confirm that the contract or data sharing agreement limits use to the stated purpose, that recipients receive only minimized data, and that copies are returned or destroyed with written confirmation.
How an assessor tests PM-25 with examine, interview and test methods
The examine method starts with documents. For PM-25, the assessor reads the policies and procedures that govern the use of personally identifiable information in internal testing, training and research, then checks whether they cover each part of the control: minimizing the PII used, authorizing its use only when it is required, and reviewing and updating the policy at the defined frequency. The assessor compares the written text against the organization's own parameter values and dates, and looks for gaps between what the policy says and what the organization describes it does.
- Policy scope: Confirm the document names testing, training and research as covered uses, not only production processing.
- Defined review frequency: Check that the organization has set the review interval and that the last review is dated and approved.
- Authorization rules: Look for the approval step that must exist before PII is used for a purpose outside production, and who signs it.
- Procedures, not only principles: Procedures should describe how minimization happens, such as masking, subsetting or synthetic data.
- Version control: Revision history and approval records show the policy is maintained rather than written once.
Before the assessment, confirm that every policy and procedure the organization relies on is current, approved and easy to produce.
The interview method tests whether people who run the work know the rules and follow them. Assessors typically interview personnel with privacy program responsibilities, such as the senior agency official for privacy or a privacy officer, along with system owners, test data managers, data scientists and trainers who handle PII outside production. The interview confirms that the written policy is understood, that authorization is sought in practice, and that the organization can explain how it decides when PII is needed.
- Privacy program staff: Ask how requests to use PII for testing or research are received, reviewed and recorded.
- System owners: Ask which non-production environments hold PII and how each one was approved.
- Test and training teams: Ask what data they use for courses, demonstrations and test cases, and who decides.
- Researchers: Ask how they request datasets and what minimization they apply before analysis.
- Consistency: Assessors compare answers across roles, so the story must match the documents.
Before interviews, confirm the people who will be interviewed, their availability and a short briefing on the scope of PM-25.
The test method checks that the processes described in the policy actually operate. For PM-25, the assessor looks at how PII moves into testing, training and research, how it is minimized, and how the organization manages data quality and PII throughout those activities. The assessor chooses the samples and decides the conclusions. DeployOpen does not perform the assessment or issue findings, and the organization should not expect an implementation partner to pick samples for the assessor.
- Data flow tracing: The assessor may follow a sample of non-production datasets back to their source and authorization record.
- Minimization in practice: Look for evidence of masking, tokenization, subsetting or synthetic data in a sample of environments.
- Access to non-production data: Confirm that copies of PII are restricted and not left in shared test buckets.
- Data quality handling: Check how inaccurate or stale records are corrected before reuse.
- Change control: Pipeline logs and merge records can show when new test data sources were added and approved.
Ask the assessor in advance which systems and samples they plan to use, and confirm that the records for those systems exist.
How to implement PM-25 in five phases
This sequence moves PM-25 from an unknown pile of production data in test, training and research environments to a documented, approved and periodically reviewed minimization program. Each phase produces a record an assessor can examine.
Inventory where PII appears outside production
Identify every non-production location where personally identifiable information may reach: test and staging databases, developer laptops, analytics sandboxes, training datasets, bug tracker attachments, log exports and research extracts. Privacy and engineering leads should work from the system inventory maintained under PM-5 and interview system owners about refreshes and copies. The output is a data location register listing each store, its owner, the PII categories it holds and how the data got there. The step is done when system owners have confirmed the register.
Write the minimization and authorization procedure
The privacy office, with security and the data owners, writes the policy and procedure that govern PII in testing, training and research. It should state when PII may be used at all, which minimization technique applies to each use case, who may authorize an exception and how the rules apply to vendors and contractors. The output is an approved, versioned procedure with named owners and a review date. Confirm with counsel that the wording matches your privacy obligations and any contractual limits on secondary use.
Implement masking, synthetic or subset data
Engineering replaces production PII in non-production pipelines with masked, tokenized, synthetic or minimized subset data. Typical steps include a refresh job that masks identifiers before data leaves production, seeded synthetic datasets for functional and load testing, and column-level restrictions for analysts. Teams should keep the transformation scripts under version control so the method is repeatable and reviewable. The output is a working pipeline and a test record showing that a sample refresh contains no unmasked identifiers. Automated checks such as Semgrep rules in CI can flag hard-coded personal data in test fixtures, and GitLab protected branches can restrict who may change the masking code.
Set an approval path for necessary exceptions
Some testing, training and research genuinely needs real PII. Define a request form and an approval chain that records the business purpose, the PII fields needed, why masked or synthetic data will not work, the storage location, the access list and the end date. The privacy office approves or rejects, and security reviews access controls for approved requests. The output is an exception register with approval records. Each entry should be traceable back to the procedure written in the second phase.
Monitor and log non-production PII use
Operate the controls so that drift is caught. Schedule scans of non-production stores for unmasked identifiers, check that approved exceptions still match their register entries, and remove expired copies. Retain the scan results and the removal records as evidence of ongoing operation. The output is a monitoring log that shows each run, its findings and the actions taken.
Schedule periodic review and update
Set the review frequency for the procedure and the exception register, using the organization-defined interval that PM-25 requires. Reviewers should compare the data location register against current systems, check whether any exception should close, and confirm that tooling still masks the fields it was built for. The output is a dated review record with decisions and updates to the procedure. Confirm the interval with your assessor before the first review, since the control leaves the frequency to the organization.
Evidence that passes PM-25 and how to keep it current
PM-25 is assessed by examining documents, interviewing privacy program staff and testing how PII actually moves through test, training and research work. The cards below cover the artifacts an assessor will ask for and how each one stays accurate between assessments, so the evidence reflects current practice rather than a snapshot prepared for the audit.
Approved PII use policy and procedures
The organization-level policy and its procedures for using PII in internal testing, training and research are the first thing an assessor examines. Record the approving official, the version, the effective date and the next scheduled review date on the document itself. Between assessments, confirm that the review date has not passed, that the procedures name current teams and tools, and that the review was actually performed rather than only scheduled. Keep superseded versions so the review history is visible.
Data minimization standard
A written standard should define when production PII may be copied into a non-production environment and what must be removed, generalized or excluded first. It should state which data fields are required for each test type, such as functional, performance or model evaluation work. Refresh the standard whenever new data stores or test tools are added, and check a sample of recent test datasets against it to confirm the rules are followed.
Authorization records with justification
Each instance of PII use outside production needs a record showing who authorized it, which data elements were requested, the business reason and the period of use. Assessors typically sample these records and compare them with what the environment actually holds. Between assessments, close out expired authorizations, confirm that copies were deleted at the end of the approved period, and flag any dataset that exists without a matching record.
Masking and synthetic data configuration
Configuration files, masking rules and synthetic data generators show how minimization is enforced in practice rather than by policy alone. Store the rule sets in version control so every change has an author and a reason. Before each assessment, rerun the masking jobs against a sample, check that direct identifiers are not recoverable, and record the results. A rule set that has drifted from the standard is a finding even if the policy is current.
Test environment access logs
Access logs for environments holding PII-derived data show who could reach that data and whether access matched the authorization records. Export and retain logs on a defined schedule, and review them for accounts that no longer have an approved purpose. Check that logging is enabled on every non-production store that holds PII, since a gap in coverage often surfaces only when an assessor asks for logs from a specific dataset.
Training materials and review minutes
Training decks, sample records and lab datasets used for workforce instruction must be checked for PII, and the checks should be documented. Review minutes from the body that oversees privacy and data use show that policy gaps were discussed and assigned owners. Refresh both by scheduling a periodic PII scan of training content, recording findings and closing them, and keeping minutes that name decisions and follow-up actions instead of only attendance.
What meeting PM-25 costs in effort, tooling and external review
This table breaks down the work behind PM-25, showing who is paid for each component, whether it is one-time or recurring, and what drives it up or down. Use it to scope internal effort and to frame questions for any outside privacy reviewer, implementation partner or assessor. No fixed costs are shown because none were supplied; ask for each line item in a written quote.
| Cost component | Who carries it | One-time or recurring | What drives it |
|---|---|---|---|
| Policy and procedure drafting | Privacy office and legal staff, with security input | One-time drafting, recurring review | Number of test, training and research use cases and existing data handling policies |
| Privacy review and authorization of PII use | Senior privacy official and data owners | Recurring, per request and per review cycle | Volume of requests to use production PII and how often authorizations expire |
| Data discovery and inventory of PII in non-production | Engineering and data teams, sometimes an implementation partner | One-time initial sweep, recurring rescans | Data volume, number of databases and file stores, and how much data is copied to test environments |
| Masking, tokenization and synthetic data engineering | Platform or data engineering, often outsourced in fixed-scope work | One-time build, recurring maintenance as schemas change | Number of data sources, schema complexity and the de-identification approach chosen |
| Pipeline and environment changes | DevOps and platform engineering | One-time build, recurring as environments are added | Number of environments, CI/CD pipelines that refresh data and access controls on each |
| Evidence collection and upkeep | Compliance lead and system owners | Recurring | Frequency of the defined review cycle, number of systems in scope and how evidence is stored |
| External privacy or assessment review | Independent assessor or privacy consultant, paid per engagement | Recurring per assessment cycle | Scope of the assessment, number of systems sampled and readiness of evidence before fieldwork |
| Auditor sampling and testing | Independent assessor, billed through the assessment | Recurring per assessment cycle | Sample sizes the assessor selects, number of test and training requests and quality of records |
| Open-source tooling licenses | Usually none for the core tools; cost falls on hosting and staff time | Recurring hosting, one-time setup | Self-hosting capacity and staff skills; confirm each tool's license terms before adoption |
Who owns PM-25 and what an implementation partner can take on
The organization owns PM-25 in full. Its privacy and security leaders write the policy and procedures that govern when personally identifiable information (PII) may appear in testing, training and research, decide who may authorize each use, and set the review frequency the control requires. No vendor can hold these decisions on the organization's behalf, and an assessor will ask who approved each exception and when.
- Policy and procedures: Approve a written standard that defines testing, training and research use, bans raw production PII by default and names the review cycle.
- Authorization: Assign an accountable owner who signs off each exception, such as a dataset needed for fraud model tuning, with a stated purpose and end date.
- Data inventory: Know which systems hold PII, which copies exist outside production and where they are stored, so minimization can be applied to them.
- Periodic review: Schedule reviews of the policy and of the authorization log, and record the outcome and any changes.
- Privacy program ties: Connect PM-25 to the privacy program plan, PII quality management and the data governance body where those exist.
Before engaging anyone, confirm that the policy names an accountable official and that the authorization record can be produced on request.
An implementation partner can prepare the technical and documentaryground that PM-25 depends on, under a written scope that defines the systems, environments and deliverables. The partner builds and configures the working environment and gathers evidence. It does not decide whether the organization's policy is adequate, does not approve exceptions, and does not issue assessment conclusions about whether PM-25 is met.
- Pipeline setup: Configure non-production pipelines so that test and training environments draw from masked, synthetic or de-identified data sets rather than raw production copies.
- Masking and access controls: Implement masking rules and restrict who can request and retrieve datasets, with logging of each request.
- Repository controls: Harden code and configuration repositories, for example with protected branches in GitLab Community Edition, so changes to data-handling scripts follow approval.
- Evidence packs: Assemble configuration exports, pipeline logs, access records and authorization entries into a structured package for the organization and its assessor.
- Handover documentation: Document how each control is operated and who runs it after the engagement ends.
Before signing, ask the partner to list in writing which items are delivered and which remain the organization's responsibility.
The independent assessor evaluates PM-25 against the assessment procedure in SP 800-53A Rev. 5. That procedure uses determination statements and the examine, interview and test methods. The assessor examines the policy and procedures, interviews personnel with privacy program responsibilities, and tests the processes for data quality and PII management. The assessor, not the organization or the partner, decides whether each determination is met and issues findings.
- Examine: Review the written policy, the authorization records and the evidence pack for completeness and currency.
- Interview: Ask privacy program staff, testers and data engineers how PII is kept out of test and training work in practice.
- Test: Sample real requests and environments to confirm that masking and access rules operated as documented.
- Findings: Record each determination as met or not met, with the reasoning and the evidence relied on.
- Independence: Confirm the assessor has no role in designing or operating the controls it tests.
Before engaging an assessor, confirm the assessor's qualifications and independence, and agree in writing what evidence the organization will supply.
Where PM-25 programs usually fall short
PM-25 is easy to document and hard to operate. The gaps below tend to appear between a written policy and what happens in test environments, training rooms and research projects. Each card names one gap and the action that closes it.
Policy without a test data procedure
The organization has a privacy policy on PII minimization, but no procedure tells engineers how to build test data. Assessors look for the policy and the procedures that carry it out, so a policy that names no steps for testing, training or research will not pass the examine method. Confirm that a written procedure covers how test datasets are requested, generated, masked and approved, and that a named owner signs it.
Production copies in unmanaged sandboxes
Developers often restore a production database into a staging or sandbox environment to reproduce a defect. Those copies rarely appear in access reviews, backup schedules or deletion routines, so unmasked PII persists with weaker controls than production. Search every non-production environment for restored production data and record where each copy lives.
No authorization record for exceptions
Some projects need real PII, for example to reproduce a fraud pattern or validate a migration. PM-25 requires that such use be authorized only when required, so an informal Slack approval does not meet it. Keep a signed exception record that states the data elements, purpose, approver, environment and end date for each case.
Training materials built on real customer records
Training decks, onboarding labs and support runbooks often use real customer names, account numbers or case notes because they are convenient. Those materials are copied widely and rarely reviewed, which makes them a quiet source of PII exposure. Replace real examples with clearly synthetic records and review existing decks before the next training cycle.
No periodic review of the policy
PM-25 requires the policy and procedures to be reviewed and updated at a defined frequency. Many programs set no frequency at all, or set one that nobody tracks, so the policy drifts away from how test and research data is actually handled. Confirm the review interval is written down, assigned to an owner, and evidenced by a dated review record.
Test environments missing from the system inventory
Test, training and research environments are often left out of the organization's system inventory, which PM-5 expects to include systems that process PII. An environment that is not inventoried cannot be scoped for minimization or review. Add every test, training and research environment to the PM-5 inventory and link each one to the PII it holds.
Questions buyers ask about PM-25 cost, effort and outsourcing
What drives the cost of meeting PM-25 minimization of PII in testing?
The cost depends mainly on how much personal data your test, training and research environments hold today and how many of them copy production data. PM-25 is not allocated to the low, moderate or high baselines, but it sits in the SP 800-53B privacy baseline, so it applies to systems regardless of impact level. The main cost components are internal time to write the policy and procedures, time spent locating PII copies across environments, changes to data handling in pipelines, and assessment support. Organizations with few non-production copies usually have a smaller job than those with many. Ask any partner to price discovery, policy drafting, technical changes and evidence collection as separate line items, so you can see which parts recur after the first review.
How long does PM-25 readiness work usually take?
No supplied source gives a standard duration for PM-25 work, so treat any timeline as something to confirm, not assume. The schedule depends on how many test, training and research data sets exist, how well they are inventoried, whether data masking or synthetic data is already in use, and how quickly policy owners can approve changes. Ask for a written plan that names the phases, the owner of each deliverable and the dependencies on your privacy office and application teams. Under a fixed-scope engagement, the timeline and deliverables are agreed in writing before work starts, which makes it easier to compare proposals.
What does PM-25 require from our internal staff?
PM-25 is an organization-level control, so the work needs people who own privacy policy, people who own the test and training environments, and people who can approve research uses of PII. The assessment procedure in SP 800-53A has assessors examine policies and procedures, interview personnel with privacy program responsibilities and test organizational processes for data quality and PII management. That means your privacy lead must be able to make decisions, your engineers must explain how data reaches non-production systems, and your data owners must sign off on authorized uses. Plan for these people to take part in reviews, not only in kickoff meetings.
Can our own team implement PM-25 without an outside partner?
Yes, many organizations do this internally, provided they have a privacy lead, engineers who understand data flows and the time to maintain the work. Internal teams usually have the advantage of knowing their systems. An outside implementation partner can help where the workload is heavy, such as inventorying copies of data across several platforms, building masking or synthetic data pipelines, or producing evidence in a format assessors expect. Remember that an organization owns its controls, a partner prepares systems and evidence, and only an independent auditor or assessor issues assessment conclusions. Decide early which parts of the work you will keep in-house.
How does PM-25 relate to the PT and SI control families?
PM-25 sits alongside the PII processing and transparency controls in the PT family and the PII quality and de-identification content in SI. The SP 800-53 Release 5.2.0 catalog lists PM-23, PT-3, SA-3, SA-8 and SI-12 as related controls for PM-25, so the same policy and data handling decisions often serve several controls. PT-3 addresses the purposes for which PII is processed, which informs what test and research uses are justified. SI-12 covers information handling and retention, which affects how long copies persist. Mapping these links once avoids duplicate evidence and keeps your system security and privacy plan consistent.
Which tools can produce PM-25 evidence for engineering teams?
Tooling supports PM-25 mainly by enforcing rules in code and environments, not by deciding policy. Git-based platforms such as GitLab Community Edition support protected branches, which restrict which roles can push or merge and can block direct pushes, giving a change record for configuration and data handling code. Semgrep Community Edition can scan repositories in languages including Python, Java, JavaScript and Terraform with custom rules, which can flag hard-coded production data references in pipelines. Confirm each tool's coverage for your stack before relying on it, because these tools do not inventory PII on their own.
What should we ask a partner to include in a written PM-25 quote?
A useful quote states the scope in writing: which systems, test, training and research environments are covered, and which PM-25 determination statements the work addresses. Ask the partner to list deliverables such as a PII-minimization policy and procedures, an inventory of non-production data copies, data handling changes, authorization workflow for research uses, a review schedule and evidence mapped to the SP 800-53A assessment methods. Also ask which costs are one-time and which recurs, what assumptions the price depends on, what your team must provide, how changes to scope are priced, and whether the auditor or assessor is paid separately. Confirm that the partner prepares evidence but does not issue assessment conclusions.
How often does PM-25 need review after the first implementation?
PM-25 requires that the policies and procedures be reviewed and updated at a defined frequency, and the organization sets that frequency. The assessment work does not end at go-live, because new test datasets, training material and research requests keep appearing. Recurring effort includes periodic policy review, authorization of new uses, checks that non-production copies are still minimized and refreshing evidence. Ask any partner whether ongoing support is priced as a retainer and what it covers, since ongoing support and continuous testing are available as retainers rather than one-time work.
Where to read the PM-25 text and assessment procedure
Start with the CPRT entry for PM-25 in SP 800-53 Release 5.2.0, which is the current release, and read the control text there before anything else. The NIST CPRT entry for PM-25 shows the control statement, its discussion and the related controls in one place. Then open the SP 800-53A Rev. 5 document, which holds the assessment procedure for PM-25: 22 determination statements, each tied to examine, interview or test methods and suggested assessment objects. Your privacy office and your assessor should work from the same version of that procedure, so record the release number in your assessment plan. Use the SP 800-53B document to confirm that PM-25 sits in the privacy baseline and is not allocated to the low, moderate or high baselines. Program Management controls are organization-wide, so the baseline check tells you which systems must meet PM-25 directly.
Use the OSCAL catalog to check the five related controls named for PM-25: PM-23, PT-3, SA-3, SA-8 and SI-12. Download the Release 5.2.0 catalog JSON from the usnistgov/oscal-content repository and search for the control identifiers pm-23, pt-3, sa-3, sa-8 and si-12. The links entries attached to PM-25 show how each related control connects, and comparing those controls against PM-25 helps you find where data governance, PII processing rules, development lifecycle requirements, engineering principles and data quality duties overlap with the testing and training minimization policy. Confirm the identifiers in the JSON, since OSCAL uses lowercase keys and the leading zero format differs across NIST products. Record which related controls your own policies already cover, so that gaps in the PM-25 procedure are visible before an assessor asks.
How DeployOpen works on this
DeployOpen approaches PM-25 as a set of written policies, data handling steps and evidence that the organization owns and an independent assessor tests. We prepare the systems, data controls and documentation for that review, while the organization decides what PII its testing, training and research actually need.
How we scope
- Agree in writing which test, training and research environments and data sets fall under PM-25.
- Inventory where personally identifiable information currently appears in non-production copies, fixtures and sample datasets.
- Define the authorization path, named approvers and review frequency the organization will commit to before work starts.
How we build
- Configure self-hosted open-source platforms so that non-production environments receive masked or synthetic data by default.
- Enforce change control for test data pipelines using protected branches in GitLab Community Edition, with direct pushes blocked.
- Scan infrastructure and application code in CI/CD with Semgrep Community Edition to catch hard-coded or exported PII samples.
How we hand over
- Deliver the written PM-25 policy and procedure set, mapped to the 22 determination statements in SP 800-53A Rev. 5.
- Provide configuration records, pipeline logs and authorization records that show the minimization and approval steps operating.
- Document the review cycle, owners and open gaps so the organization can run it without us.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after the fixed-scope work is accepted.
- Re-check test and training data pipelines when systems change, and update the evidence set to match.
- Confirm with your assessor which artifacts they expect, since only an independent auditor or assessor issues findings.
