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
The hardest part of GDPR for engineering teams isn't production. Production has logging, access control, encryption at rest, audit trails. The hard part is everywhere production data spreads: dev, QA, UAT, staging, the laptop a contractor restored a backup to last Tuesday. That's where most leaks happen, and that's where most audits actually fail.
If you can answer "yes" to all twelve, you've effectively eliminated the dominant class of GDPR risk in your SQL Server estate. If you can't, this is the order to 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, it will get skipped. The workflow should not allow an unmasked clone to 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
Tabletop: "Regulator just asked for last quarter's masking evidence". If your team can produce it in five minutes, you pass. If they need to grep through SSMS history, 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
How DataTamed implements all twelve out of the box
We didn't write this checklist as a sales document — it really is the field manual we wish we'd had years ago. But we'll be honest: DataTamed was designed to make every one of these twelve checks pass by default, without configuration:
- Automatic detection of six PII categories at import time (#1, #2)
- Per-column masking strategy selection (#3)
- Masking enforced at the platform level — there's no "skip masking" toggle (#4)
- Every clone, masking, and backup event logged in exportable reports (#5, #8, #11)
- Role-based access control, distinct API keys per agent (#6, #7)
- Automatic SQL Server version compatibility validation in the clone wizard (#9)
- Self-hosted by default — the server runs in your network, full stop (#12)
If you'd like a complete tour, the Compliance & GDPR use-case page covers each of the twelve in depth, with screenshots from the actual product. Or jump straight to a 14-day free trial and run through the checklist on your own data.