Does the staging copy need your real customer records?

Start from the question the test must answer

A staging environment exists to answer a specific question: does the new theme render correctly, does the updated plugin break checkout, does the migration preserve product structure. Write that question down with the developer before discussing data. The question, not the phrase 'realistic data,' determines what the copy needs to contain.

Most staging questions are about structure and behavior, not about any real person. A checkout test needs a cart, a price and a submit action; it does not need a real buyer's name and address. Where the developer asks for 'a database copy,' ask which question requires production records, and record the answer verbatim. An unanswered why is itself the finding.

Prefer fixtures that cannot identify anyone

Synthetic fixtures, meaning invented customers, orders and addresses created for testing, cover the large majority of staging work and reduce the need to copy real personal records at all. Fixtures stay non-identifying only if their values are genuinely invented rather than derived from real customers, and live connections and outputs, such as email sending or payment calls, still need to be controlled so test actions cannot reach real people. Fixtures reduce exposure; they do not eliminate it. Where the platform or tooling offers documented test modes or sample-data generation, use them within their documented scope; this page does not prescribe a specific generation method, and the method must come from the platform's own documentation.

If someone claims fixtures are insufficient, record the concrete reason: a specific edge case tied to real data shape, such as a migration that must preserve historical order formats. A vague appeal to realism is not a reason. The documented reason becomes the scope boundary for whatever real data follows, and anything outside it is excluded.

If real fields are unavoidable, bound them before copying

The ICO's UK guidance on data minimisation states that personal information should be adequate, relevant and limited to what the purpose requires. The guidance reflects a UK principle and does not decide every lawful basis or vendor arrangement, but its discipline is the right test here: each real field copied to staging should trace to the named testing purpose, and fields that merely come along with the export should be excluded.

For any approved copy, record the field list, the access holders by name and role, the environment's access controls as they actually are, and the removal condition, meaning the event or date on which the copy is deleted. Card numbers, verification codes, passwords, API secrets and full payment records are excluded from staging regardless of purpose; troubleshooting payment behavior uses the provider's documented test facilities, not copied cardholder data.

Authorize the copy, then verify the teardown

The merchant's authorized owner signs off the staging-data sheet before any export runs, and the developer confirms the environment matches what was approved: only the listed fields, only the listed access holders, no additional integrations pulling the data elsewhere. A copy that already happened without this sheet is a handling issue to record and remediate, not a fait accompli to normalize.

When the testing purpose ends, verify removal: the staging database is deleted or the real fields are removed, access is closed, and the owner records the date. Teardown is part of the authorization, not an afterthought. If recurring staging requests reveal that your public privacy wording says nothing about test environments, or says something your practice does not match, a Prism website review can examine that public wording within an agreed scope; responsibilities, fees and terms are confirmed before work.

Staging-data authorization sheet

Complete this before any production data is copied, using internal references rather than real customer details. No sheet, no copy; an existing unapproved copy is recorded as a handling issue with a remediation owner. This sheet never contains card data, credentials or customer records themselves.

Worksheet entries are not submitted by Prism’s worksheet and are not saved by the site. Use record types, availability, anonymized observations, or match/mismatch results. Do not enter government identifiers, customer names or addresses, customer messages, receipt-access links, card or bank details, passwords, or keys. Send sensitive documents only through the provider’s verified secure channel.

These are temporary notes. Leaving or reloading this page may clear them. Worksheet entries are not sent automatically. If you copy notes into the consultation message and submit the form, Prism receives them as part of your request.