Test Data Protection Policy

Document control

Field	Value
Owner	Ron Benisty — CTO & CSO (ron.b@iontwrks.com)
Status	Approved
Version	1.0
Classification	Confidential
Approved by	Ron Benisty — CTO & CSO
Approval date	2026-05-26 (Tuesday)
Last reviewed	2026-05-26
Review cycle	Annual — next review due May 2027
Parent policy	Secure SDLC (SSDLC)

Satisfies ISO/IEC 27001:2022 A.8.33 (protection of test information). Closes Gap 10 of the SSDLC gap analysis.

---

1. The rule

No production data may be used in any non-production environment. This includes dev laptops, the set-nonprod AWS account, demo environments, local Docker, CI containers, and any sandbox a contractor uses.

This is the single hard rule. Everything below describes how it is achieved and what happens when an exception is genuinely necessary.

2. Why this rule is hard

• Tenant data is sensitive by design — compliance artifacts, evidence files, security findings, vendor questionnaires.
• Israeli Amendment 13 restricts cross-border data transfer; copying prod data outside the prod environment crosses jurisdictions, processors, and access controls.
• Schema-per-tenant (Multi-Tenancy) makes prod data trivial to technically copy out (pg_dump --schema=tenant_xxx) — exactly why the policy must be explicit that it is not allowed.

3. Permitted test data

Source	Allowed in	How
Synthetic / generated data	All non-prod	Seed scripts produce realistic-but-fake tenants, users, evidence files, findings
Anonymized public sample data (open-source compliance framework PDFs, public CVE feeds)	All non-prod	Added to the test-fixture set
Internal-team self-onboarding data (the team uses S.E.T as a fake customer)	nonprod only	Treated as if real

4. Environment separation enforces the rule

Per Environments:

• set-nonprod and set-prod-eu are separate AWS accounts — no IAM trust, no cross-account replication.
• Per-environment KMS CMKs that never cross account boundaries — even if a backup were copied across, it could not be decrypted.
• WorkOS environments are separate (Development vs. Production) — no cross-environment user copy.
• Logz.io projects are separate.

The architecture makes accidental prod-to-nonprod movement physically difficult; this policy makes it explicitly disallowed.

5. Exception process (rare)

If a production-only artifact is essential to reproduce an incident or verify a fix:

1. Open a change-management PR (Change Management) requesting the exception.
2. CTO & CSO must approve before any movement occurs.
3. Mask before transfer — PII redacted (email → user+<hash>@example.test), tenant IDs anonymized, evidence content hashed or replaced with sentinels, secrets removed.
4. Time-boxed — the masked snapshot must be deleted from non-prod within 14 days; the deletion is verified in the same PR.
5. Logged in the Evidence Register (Evidence Collection & Retention) — every exception is auditable.

A genuine exception is rare (we should expect to need this 0–2 times per year). If exceptions become routine, the seed-data tooling is what needs work, not the exception process.

6. Customer audit logs stay in tenant schemas

A particular reminder: the customer-facing audit_events table lives inside the tenant's Postgres schema (Observability §Tier 1). It is never copied to nonprod for any purpose. Internal debugging uses Logz.io operational logs (which contain no customer PII per the redaction rule in that section).

7. Document change history

Version	Date	Author	Description of change	Approved by
1.0	2026-05-26	Ron Benisty (CTO & CSO)	Initial version — establishes the Test Data Protection Policy.	Ron Benisty (CTO & CSO)