A board sets a risk appetite statement: no production personal data in non-production environments, with no exceptions. Engineering accepts it. What has the organisation bought, what is it paying, and when does the cost surface?

What is bought

A large, real reduction in exposure. Non-production environments are where access is broad, logging is weak, backups are informal and contractors have accounts. Most reported data exposure from internal environments comes from copies made for testing, and a single clean rule removes the whole category. It is also easy to audit, which matters: a rule with exceptions costs more to verify than it saves. Regulators have treated test-environment copies as in scope since the GDPR became applicable in 2018, so the appetite is usually cheaper than the argument about it.

What is paid

• Reproducing production defects gets harder. A bug that depends on the shape of real data — a name with an apostrophe, a 400-item basket, a 20-year-old account — cannot be reproduced from data that does not contain those shapes.
• Synthetic data becomes a maintained product, not a script. It needs referential integrity, realistic distributions and refresh as the schema changes, and somebody owns that.
• Performance testing loses fidelity. Query plans depend on data distribution and cardinality; uniformly generated data produces plans that do not match production.
• Migration rehearsals get weaker, which is where this bites hardest, because a migration rehearsal's whole value is that it ran against realistic data.

When the cost surfaces

Not at adoption. It surfaces at the first severity-1 incident that cannot be reproduced, when an engineer asks for a production extract at 3am and the answer must be no. That is the moment the appetite is either real or quietly abandoned, and it is worth deciding in advance which it will be.

The second moment is the first large migration, where the rehearsal is the control that everything else depends on.

How to keep the option to reverse, without weakening the rule

• Fund the synthetic data generator properly before the rule takes effect, including edge cases harvested from incidents rather than invented.
• Build a production debugging path that does not involve copying: read-only access for a named person for 60 minutes, audited, with queries logged. Choose this over an exception process, because an exception process under incident pressure becomes a rubber stamp. This satisfies the appetite's intent — no copies — while answering the 3am question.
• Tokenise rather than exclude where joins matter, so a referentially intact dataset can exist in a lower environment without the values.
• Measure the cost — reproduction time, incidents closed without root cause — and report it to the board annually. An appetite statement whose cost is never reported will be blamed rather than revisited.

When this appetite is the wrong call

For an organisation whose data is not personal and not commercially sensitive, the rule buys little and costs the same. The statement should name the data class, not the environment: "no personal data outside production" is enforceable and proportionate; "no production data" bans a reference table for no benefit.