SafeSeed: Fake by Design

Most privacy incidents do not begin with someone proudly uploading `production_customers.csv` to GitHub and announcing it in Slack. They begin with a copy.

A copy in staging. A copy in CI fixtures. A copy on a developer laptop. A copy in a bug ticket screenshot. A copy in that one shared drive folder called `temp_final_REALLY_FINAL`, because apparently every organization has to maintain a small haunted forest.

Everyone agrees on the sermon: do not use real personal data in non-production environments.

Lovely. Correct. Frequently useless.

Because the moment someone says “use synthetic data,” the real question is: synthetic how?

A lot of synthetic-data tooling learns the shape of your real data from your real data. That may be useful for analytics, simulation, or model training. But for privacy, it leaves you arguing about memorization, resemblance, linkage, re-identification, and whether the fake thing is still dragging a little production-data ghost behind it.

SafeSeed takes the boring, defensible path: it never lets production data into the room.

Every PII-shaped value comes from a range reserved for non-real use, designated for testing, or built to be unmistakably fake. Documentation emails. Documentation IPs. Test card numbers. Fictitious phone ranges. Values designed to be useless to attackers and uninteresting to regulators for the best possible reason: they were never about a person in the first place.

Anonymous from the first keystroke, not scrubbed after the fact.

---

Quick start

UserRun the live demoGenerate synthetic data, fingerprint it, prove it hasn't changed, then scan a file you already have, all in your browser. Privacy / LegalJump to the compliance bridgeTranslate the control into GDPR Art. 25/32, ISO 27001 A.8.33, and SOC 2 language without overstating it. CISORead the proof and the limitCheck what the run record proves, what it refuses to prove, and where the assurance boundary sits.

---

Four honesty tiers

Not all fake data is equally fake. Sounds obvious, until someone hands you “synthetic” records generated from production data and asks whether the privacy risk is gone. The risk is not gone. The risk is still in the room, standing in the corner, smiling smugly in his knockoff Ray-Bans.

SafeSeed labels every value with the strength of claim it actually earns.

---

Live demo

Run the whole loop yourself, right here: generate data that's fake from the ground up, fingerprint it, prove it hasn't changed, then audit a file you already have. Nothing ever leaves the browser.

[[safeseed-netcheck]]

[[safeseed-proof]]

---

Wire it into CI/CD

Drop it into your pipeline and the build fails the moment the data drifts out of range or is tampered with.

# generate a committable fixture, offline and deterministic
npx safeseed generate --fields email:email,phone:phone,ssn:ssn,card:creditCard --rows 1000 --seed 1337 \
  --out fixtures/seed.csv --record fixtures/seed.record.json

# fail the build if it ever drifts out of range or is tampered with
npx safeseed verify --in fixtures/seed.csv --record fixtures/seed.record.json

Or as a required check in a GitHub Action:

# .github/workflows/ci.yml
- uses: advokat-frida/safeseed@v0.2.1
  with:
    data: fixtures/seed.csv
    record: fixtures/seed.record.json

---

What it proves, and what it doesn't

The one sentence to keep: "not derived from production data" is not the same claim as "not personal data." SafeSeed makes the first claim honestly, and never pretends to make the second.

Where this fits your programme

SafeSeed is a control for non-production test data. Not a privacy programme. Not a compliance strategy. Not a blessed amulet you tape to a staging database while pretending access controls are someone else’s problem. A control. A useful one.

Obligation	What SafeSeed contributes	The honest limit
GDPR Art. 25 / 32 privacy by design; security of processing	Generates never-real test data; supporting evidence toward privacy-by-design and security-of-processing	Supports privacy by design and security of processing. Does not satisfy either article by itself.
ISO/IEC 27001:2022 Annex A 8.33 Test information	Evidence toward the "selected" and "protected" elements: never-real test data keeps real information out of test environments.	Does not address the "managed" duties: authorization, access control, retention, and deletion.
SOC 2 Confidentiality and data-handling in test environments.	Artifacts that support test-environment data-handling evidence	Map to your auditor’s exact criteria. Do not freestyle SOC 2 like it is jazz night.

And the line you can lift straight into a control register or a DPIA:

Non-production test data is generated from standards-reserved non-real ranges (SafeSeed), with a tamper-evident run record (SHA-256 content fingerprint) and a verify/scan step run in CI to confirm files are unchanged and within reserved synthetic ranges. Supports a data-minimisation and privacy-by-design posture (GDPR Art. 25) and the "selected" and "protected" elements of ISO/IEC 27001:2022 Annex A 8.33; can form part of an Art. 32 measures narrative. It does not, on its own, satisfy these in full, address A 8.33's "managed" duties (authorization, access control, retention, deletion), or constitute anonymisation of production data.

The usual caveat, stated plainly: this is a practitioner's mental model and a how-to, not legal advice. Your facts, your counsel.

Questions a sceptic asks first

---

Get SafeSeed

SafeSeed is a CLI, a library, and a verify GitHub Action. No backend, no runtime dependency on a hosted service, and no reason to see your data. It runs locally because test data does not need to become SaaS confetti.

Install it with:

npm install safeseed

Or read the source, inspect the standards, and kick the tires on GitHub.

—🦊

Catch something wrong, or just want to argue with me? hello@advokatfrida.com