The DBA's GDPR Database Cloning Checklist (Free, 12 Items) | DataTamed
The DBA's GDPR database cloning checklist
Twelve checks every SQL Server team should be able to pass before a single byte of production data hits a non-prod environment. Copy, paste, run.
Why this matters
Here's the awkward truth about GDPR for engineering teams: production is rarely where it bites you. Production has the logging, the access control, the encryption at rest, the audit trail — the whole grown-up setup. The problems live wherever production data quietly spreads: dev, QA, UAT, staging, the integration sandbox someone span up for a partner, and yes, the laptop a contractor restored a backup to last Tuesday and forgot about. That sprawl is where most leaks happen, and it's where most audits actually fall over.
So we wrote the checklist we wish someone had handed us years ago. Twelve plain questions. If you can answer "yes" to all of them, you've effectively closed the door on the dominant class of GDPR risk in your SQL Server estate. If you can't yet, this is roughly the order we'd fix them in.
The twelve checks
1. We have an up-to-date inventory of PII columns
Every database, every table, every column that contains personal data — written down somewhere that isn't lost when the lead DBA goes on holiday.
2. PII is masked before the database file is stored
Not "after restore". Not "in the next maintenance window". Before the file lands on a non-prod disk. Mask at import time so production-grade PII never reaches a non-prod environment in the first place.
3. The masking strategy per column is documented
For each PII column: which strategy (partial / redact / nullify) and why. Auditors love this, because it shows the choices were deliberate.
4. Masking is enforced by the platform, not by humans
If your masking lives in a script that someone has to remember to run, sooner or later — usually on a Friday afternoon, usually when someone's covering for someone else — it'll get skipped. Build it into the workflow so an unmasked clone simply can't exist.
5. Every clone event is logged
Who, when, source image, target server, masking applied. One row per clone. Exportable.
6. Self-service is role-controlled
Self-service is a feature, not a default for everyone. Restrict who can create clones to the people who need to.
7. Non-prod credentials are different from production
Distinct SA passwords per environment. Distinct service accounts. Production secrets stay in production.
8. There's a one-click masking report
When the regulator asks "show me your masking evidence", you should be able to produce a CSV / Excel / PDF inside five minutes — not by running a SQL query against the masking_log table.
9. Cross-version cloning is validated
Cloning a SQL Server 2022 database onto a 2017 instance silently breaks compatibility levels. Validate version compatibility explicitly during clone — and refuse to proceed if it'd break.
10. There's a retention policy for non-prod clones
Even a masked clone is data. Expire it. Three months. Six months. Pick a number, write it down, enforce it.
11. We've rehearsed the audit
Try it as a tabletop: "A regulator has just asked us for last quarter's masking evidence." If your team can produce it in five minutes — calmly, from a known place — you pass. If the first move is "let me grep through SSMS history and ping the DBA who's on holiday", you don't.
12. We know exactly where database files travel
If a cloning tool sends backups, schemas, or metadata to the cloud, you should be able to point at the contract that says so. If not, your tool of choice should be self-hosted by default — like DataTamed.
Twelve checks every SQL Server team should pass before production data hits non-prod.Click to share
If you'd like the full tour, the Compliance & GDPR use-case page walks through each of the twelve in depth with screenshots from the actual product. Or skip the brochure and jump straight to a 14-day free trial — run through the checklist on your own backups and see how many of them flip to green without writing a single script.