Guide
How to keep PII out of staging databases and laptops
Auditors and customers keep asking the same question: where does your real customer data live? A staging database restored from a production dump is often the honest answer, and it is hard to defend. This checklist covers the controls that make the answer simple. It is engineering guidance, not legal advice.
Updated
Why staging is a risk
Production has access controls, monitoring and a small number of people who can read it. A staging copy usually has none of that, and it is reachable by every developer, CI job and test tool. Frameworks such as SOC 2, HIPAA, GDPR and India's DPDP Act do not name a tool, but they all expect you to limit who can see personal data and to show evidence that you do.
1. Keep raw data in production
The simplest control is that real rows never leave the production environment unmasked. Copy through a tool that masks while it reads, so the target only ever receives masked values. Subveil runs inside your own network or CI runner and masks rows in process, so no raw value is written to the target.
2. Mask in a way that keeps data useful
Staging data that does not behave like production gets bypassed, and teams go back to dumps. Use deterministic masking so joins, uniqueness and reproducible bugs survive, and subset the data so environments stay small and fast. See the guides on anonymizing and subsetting PostgreSQL.
3. Manage one masking policy for the team
A policy that lives only in each developer's local file drifts. With Subveil Cloud you can publish a versioned masking policy per project, and the CLI pulls it when it runs. With --require-audit the run stops before touching the target if the policy cannot be fetched, instead of silently falling back to something weaker.
4. Watch for new columns that hold personal data
Schemas change. A new date_of_birth column is unmasked until someone adds a rule. Subveil Cloud receives the schema, with names and types but never values, and flags columns that look like personal data and have no rule in the current policy. A flagged column is a candidate to review, not proof.
5. Keep evidence
A control you cannot show is hard to defend. After a pull the CLI sends a signed audit receipt to Subveil Cloud: which tables were copied, how many rows and when. Receipts hold counts and hashes, never row values, so the evidence itself is not a new copy of the data.
6. Give pull requests safe databases
Preview environments are a common leak, because it is tempting to point them at a real copy. Subveil generates a GitHub Actions workflow that builds a masked database inside your own CI for each pull request, and Subveil only tracks the lifecycle, never the data.
What masking does not do
- It does not make you compliant by itself. Compliance depends on your whole process, contracts and the framework that applies to you.
- Masked data can still be personal data if people can be re-identified, for example from a rare combination of birth date, postcode and job title. Review quasi-identifiers as well as obvious fields such as names and emails.
- It only covers what you configure. Review the generated config and keep checking drift alerts.
Frequently asked questions
- Does Subveil make me SOC 2, HIPAA, GDPR or DPDP compliant?
- No tool does that alone. Subveil helps you keep raw personal data out of non-production environments and gives you evidence of it. Your compliance still depends on your policies and your auditor.
- Does Subveil Cloud see my data?
- No. The CLI runs in your network and only metadata crosses to the cloud: schemas, policies, hashes and counts. Row values are never sent or stored.
- Is the CLI free?
- Yes. The CLI is free for everyone. The cloud has a free Community plan, and paid plans add team features.
Try it on your own database
Subveil is a free CLI for PostgreSQL. Your data stays in your network.