Give a contractor a synthetic dataset with the same shape as production, the seed script that builds it, a scoped staging account that expires, and written scenarios of the cases they need. Keep real customer data out of the engagement unless a specific, approved need exists.
Why a dump is the wrong default
A production dump hands a third party a full copy of customer data, on a laptop or storage you do not control, with an end date nobody tracks. The data protection principle of limiting data to what is necessary for the purpose applies, and few contractor tasks need real records. This is general information, not legal advice, so check obligations with your counsel and your contracts.
Most requests for "real data" come from wanting realistic behaviour. A well made synthetic dataset gives that.
The handover package
| Item | Purpose |
|---|---|
| Synthetic dataset or seed script | Realistic shape, no real people |
| Schema and data dictionary | What each field means and its allowed values |
| Scenario list | Named test accounts for tricky cases |
| Scoped staging account | Access limited to services in scope, with an expiry |
| Sandbox keys | For third party integrations, not live keys |
| Rules sheet | What is forbidden: copying data out, sharing credentials, using personal devices if that is your policy |
| Contact and escalation path | Who to ask when they think they need real data |
Steps
- Define the task. Write what the contractor must achieve and what data that truly needs. Often the answer is "none".
- Build or reuse the dataset. Use your seed script, with scenario accounts for the edge cases. See the related post on seed scripts.
- Provision access by role. Add the contractor to a group with the narrowest permissions, using single sign on where possible. No shared logins.
- Set an expiry. Put the contract end date on the access grant, and calendar a check a week before.
- Use sandbox keys. Third party integrations in staging must use test credentials.
- Log and review. Keep sign in and admin logs for the engagement. Review them once at the midpoint and at the end.
- Offboard promptly. At the end, remove accounts, revoke keys, and ask the contractor to confirm in writing that they hold no copies of the data you provided. Keep that confirmation.
When real data seems unavoidable
Sometimes a bug only reproduces with a specific production record. Prefer to debug it in house, then give the contractor a synthetic record with the same structure. If an exception is truly needed, get written approval, limit it to the minimum records, put it in a locked environment you control, set an end date, and record deletion.
Mistakes to avoid
- Sending a dump through email, chat or a file sharing link with no expiry.
- Giving a contractor the same access as an employee because it is faster.
- Forgetting the contractor's own subcontractors.
- Assuming a contract clause replaces technical limits.
Quick check
Is a data processing agreement enough?
It is needed when personal data is involved, but it does not replace data minimisation. The safest data is data you never send.
What if the contractor needs production logs?
Redact them first, as in the post on scrubbing customer data from bug reports, and provide only the time window and services required.
Sources
Last reviewed: 19 October 2026.
