Production Data in Non-Production: A Safe Refresh Runbook for Data, Credentials and Integrations

An environment refresh copies far more than test data: it carries production logins, password hashes, API keys stored in tables, live email addresses and webhook targets into an environment with weaker controls. The policy question of whether production data may be used outside production is covered in the Environment Separation guide, and masking techniques in the Tokenisation and Data Masking Guide. This guide is the operational runbook for when a copy happens: how to plan the refresh, move the data safely, reset every credential and integration that came with it, verify the result and remove it on time. It is for platform engineers, DBAs, release managers and the security teams that approve refreshes.

Key takeaways

• A restore is a credential copy. Database backups and snapshots include logins, role memberships and often password hashes, plus any secrets the application stores in tables.
• Neutralise before you open. Reset credentials, rewrite contact details and disable outbound integrations before any tester or job can connect to the refreshed environment.
• Mask in flight, not after. Data should be masked or subset before it lands in the lower environment; masking after the restore leaves a window where raw data sits in a weaker place.
• Dynamic masking is not a copy control. Query-time masking hides values in results but leaves stored data unchanged, so it does not make a copied database safe.
• Every copy has an owner and an end date. Track refreshed copies like any other sensitive data store and delete them on schedule.

What a refresh actually carries

The PostgreSQL documentation is a good example of the credential point: pg_dumpall --globals-only and --roles-only include role definitions, and the separate --no-role-passwords option exists so that roles restore with a null password and password authentication fails until a new password is set.

Choosing the refresh method

The Environment Separation guide sets which data types are allowed. Once a copy is approved, the method decides how much risk travels with it.

• Cross-account snapshots: Amazon RDS lets you share a manual snapshot privately with up to 20 AWS accounts, or publicly with all accounts if unencrypted. Encrypted snapshots cannot be made public, and snapshots encrypted with the default AWS KMS key cannot be shared, which makes customer managed keys a useful control point: AWS documents copying the snapshot under a customer managed key whose policy names the target account, and the target then copies it again under its own key. Because the source account controls that key policy, it can scope exactly which account can read the copy. Only share with the named target account, never with all, and check sharing with describe-db-snapshot-attributes.
• Query-time masking: Microsoft describes Azure SQL dynamic data masking as hiding values in query results while the data in the database is not changed, and users with administrative rights such as server admin or db_owner see original data. A copy made from a database with dynamic masking contains the real values.
• Pseudonymised copies: the ICO is clear that pseudonymised data remains personal data for anyone who holds the additional information needed to re-identify it. Keep that information out of the lower environment entirely. See the Pseudonymisation Techniques Guide.

The refresh runbook

The sequence below is an NHI Mgmt Group recommendation. The order matters: nothing should be able to connect to the environment until the neutralisation steps are complete.

1. Approve: record the requester, purpose, data classes, approver (the data owner, not the requester's manager), target environment and deletion date. This is the evidence NIST SP 800-53 SA-3(2) auditors ask for.
2. Isolate the target: block inbound user access and outbound network egress from the target environment for the duration of the restore, except to the restore source.
3. Extract with exclusions: exclude role passwords and global objects where the tooling allows, and apply masking and secret-nulling rules during extraction so raw values never land in the target.
4. Restore with jobs disabled: restore with schedulers, database agents, replication and mail features disabled, so no production job runs from the copy.
5. Reset database identities: drop or disable every production login and role that is not needed, create environment-specific logins with new passwords from the target environment's vault, and remap application users. See the Secrets Management Guide.
6. Replace application secrets: overwrite API keys, OAuth client secrets and refresh tokens, SMTP and payment credentials, and signing keys stored in tables with test values. Treat any production secret found later as exposed and rotate it in production.
7. Rewrite contacts and endpoints: change email addresses and phone numbers to a controlled test domain or masked values, and point webhooks, payment and partner endpoints at stubs.
8. Reset end-user authentication: replace user password hashes with a known test value or disable users, and clear MFA seeds, recovery codes and session tables.
9. Verify: run automated checks (see below) before opening access. Fail the refresh if any check fails.
10. Open access: enable test users and jobs selectively, and record the environment in the data inventory with its owner and deletion date.
11. Expire: delete or re-mask the copy on the recorded date, and delete intermediate exports, snapshots and shared snapshot permissions.

Rollback: if verification fails, do not attempt to fix forward in an open environment. Keep access blocked, drop the restored databases and rerun from the extraction step with corrected rules.

Verification checks

• Login diff: compare the list of logins and role members with the expected environment baseline; any production-only login is a failure.
• Secret scan: scan configuration tables and exported files for credential patterns and known production key prefixes. See the Secret Sprawl Measurement Guide.
• Canary values: seed known canary records in production (a fake customer with a unique email) and confirm they appear masked in the copy.
• Endpoint check: query outbound configuration for any production hostname or live payment endpoint.
• Egress test: confirm the environment cannot reach production databases, identity providers or partner endpoints.
• Job state: confirm all schedulers and agents are disabled or on an approved allow list.

Beyond the database: other stores that travel

Refresh runbooks often stop at the relational database. Production data and secrets also travel through other stores, and each needs the same neutralisation.

• Object storage: uploaded documents, images and exports copied with a bucket sync. Copy only the prefixes the test needs, apply the same masking decision to documents (which often cannot be masked and should be replaced with samples), and keep production bucket policies and access keys out of the target configuration.
• Search indexes and caches: search clusters and caches rebuilt from production carry unmasked text fields. Rebuild them from the masked copy rather than snapshotting the production index.
• Message queues and event streams: replaying production events into test can resend real notifications and carry tokens embedded in payloads. Replay only from masked or synthetic event sets.
• Application configuration and environment files: copying a production configuration bundle to speed up a refresh is a common way production secrets reach test. Generate configuration per environment from its own vault path.
• SaaS sandboxes: many SaaS platforms offer full-copy sandboxes refreshed from production. Apply the same runbook: check what the platform rewrites automatically and what it does not, reset integration users and connected app secrets, and disable outbound messaging until verified. Confirm current sandbox behaviour in the vendor's documentation.
• Logs and backups of the copy: the non-production environment's own backups and logs now contain whatever the copy contained. Include them in the deletion step.

Where identity fits

Refreshes cross the line between environments, so the identities involved deserve attention.

• Refresh pipeline identity: the job that reads production and writes to test is a privileged machine identity with read access to production data. Give it a dedicated identity, read-only on the source, no interactive login, and a named owner. See the Service Account Security Guide.
• Test accounts: the environment-specific logins and test users created after the refresh need owners and expiry like any other test account. See the Test Accounts Governance Guide.
• Shared credentials between environments: a password or key that works in both test and production turns any test compromise into a production compromise. Every environment gets its own vault path and its own keys.

Small and large organisations

Detection and measurement

Monitor for snapshot sharing changes and cross-account restores, large exports from production databases, logins to non-production using production account names, outbound connections from test to production or live partners, and refreshed environments past their deletion date.

• Approved copies: percentage of production copies outside production with a recorded approval and owner.
• Verification pass rate: refreshes that pass all checks first time.
• Secrets found: production secrets found in non-production per quarter (each triggers production rotation).
• Overdue copies: non-production copies past their deletion date.
• Time to neutralise: time between restore completion and credential reset completion.

Framework mapping

Common failure patterns

• Restore first, mask later: the copy lands raw and the masking job runs the next day, or fails silently, leaving real data open to every tester.
• Production logins survive: the restored database still accepts the production application login, and its password is the same in both environments.
• Integration keys still live: a payment or messaging key in a settings table lets test code send real transactions or messages.
• Customers emailed from test: a scheduled job sends notifications to real customer addresses because contacts were not rewritten.
• Snapshots shared too widely: a snapshot shared to a broad set of accounts, or left shared after the refresh, becomes an uncontrolled copy.
• Copies never deleted: a diagnostic copy approved for two weeks is still running a year later with no owner.

Practitioner checklist

• Require a recorded approval, owner and deletion date for every production copy outside production.
• Exclude role passwords and global objects from exports where tooling allows.
• Mask personal data and null secret columns during extraction, not after restore.
• Restore with jobs, mail and replication disabled and egress blocked.
• Reset all database logins and application secrets using the target environment's vault.
• Rewrite contacts and repoint outbound endpoints to stubs.
• Run automated verification and fail the refresh on any finding.
• Rotate in production any production secret found in a lower environment.
• Delete copies, intermediate exports and snapshot shares on schedule.

Standards and references

• NIST: SP 800-53 Rev 5 Security and Privacy Controls (SA-3(2))
• ICO: Pseudonymisation
• PostgreSQL: pg_dumpall
• AWS: Sharing a DB snapshot for Amazon RDS
• Microsoft Learn: Dynamic data masking
• AWS: Sharing encrypted snapshots for Amazon RDS

Related NHI Mgmt Group resources: Environment Separation · Tokenisation and Data Masking Guide · Test Accounts Governance Guide · Anonymisation and Re-identification Risk Guide