Compliance

Regulations such as GDPR, HIPAA and PCI DSS restrict how personal and sensitive data is used, including in development and test environments. The platform helps you give those environments the data they need without copying the real values. This page explains what it helps with, the evidence it records, and what stays your responsibility.

This page isn’t legal advice. Whether a particular output meets an obligation depends on your data, your configuration and how the output is used. Check with your compliance and legal teams.

What the platform helps with

Need	How the platform helps
Keep real personal data out of non-production	Masking replaces values in place, and generation creates new rows learned from the input. Subsetting copies fewer rows. See Data Protection.
Keep data in your environment	The platform runs in your own environment, and database contents stay with the workers and the CLI that process them. It can run on machines without internet access. See Security Overview.
Apply the same rules every time	Default rules give every column a transformer, and PII rules at global, organization and project level mark the same types of data in every data source. See PII Detection.
Least privilege	Read-only database users and Read-only data sources for inputs, projects that limit which data sources each team uses, and global and project roles. See Access Control.
Protect credentials	Data source passwords are encrypted at rest, or kept in your secret manager.
Show what was done	The audit log, each workflow’s activity log and version history, run history and run logs. See Evidence you can keep.

Need

How the platform helps

Keep real personal data out of non-production

Masking replaces values in place, and generation creates new rows learned from the input. Subsetting copies fewer rows. See Data Protection.

Keep data in your environment

The platform runs in your own environment, and database contents stay with the workers and the CLI that process them. It can run on machines without internet access. See Security Overview.

Apply the same rules every time

Default rules give every column a transformer, and PII rules at global, organization and project level mark the same types of data in every data source. See PII Detection.

Least privilege

Read-only database users and Read-only data sources for inputs, projects that limit which data sources each team uses, and global and project roles. See Access Control.

Protect credentials

Data source passwords are encrypted at rest, or kept in your secret manager.

Show what was done

The audit log, each workflow’s activity log and version history, run history and run logs. See Evidence you can keep.

Regulations

Regulation What it means for test data What to consider

Regulation	What it means for test data	What to consider
GDPR	Personal data in a test environment is still personal data. GDPR names pseudonymisation as a safeguard, and data that is truly anonymous falls outside its scope.	Keyed masking is pseudonymisation: masked values can’t be reversed without your masking key, which is the additional information GDPR expects you to keep separately. Protect masked outputs as personal data unless your assessment concludes they’re anonymous.
HIPAA	Data is de-identified when the identifiers HIPAA lists are removed (Safe Harbor), or when an expert determines that the risk of re-identification is very small (Expert Determination).	Mask or generate every column that holds a listed identifier, including dates and free-text fields. Use `docanon` for documents. Whether an output is de-identified is your determination.
PCI DSS	Live card numbers aren’t allowed in pre-production environments, unless those environments are protected as part of the cardholder data environment.	Replace card numbers with `finance_generator` or `format_preserving_hashing`, and check that no `passthrough` or learned `categorical_generator` column holds them. Confirm your approach with your assessor.

GDPR

Personal data in a test environment is still personal data. GDPR names pseudonymisation as a safeguard, and data that is truly anonymous falls outside its scope.

Keyed masking is pseudonymisation: masked values can’t be reversed without your masking key, which is the additional information GDPR expects you to keep separately. Protect masked outputs as personal data unless your assessment concludes they’re anonymous.

HIPAA

Data is de-identified when the identifiers HIPAA lists are removed (Safe Harbor), or when an expert determines that the risk of re-identification is very small (Expert Determination).

Mask or generate every column that holds a listed identifier, including dates and free-text fields. Use docanon for documents. Whether an output is de-identified is your determination.

PCI DSS

Live card numbers aren’t allowed in pre-production environments, unless those environments are protected as part of the cardholder data environment.

Replace card numbers with finance_generator or format_preserving_hashing, and check that no passthrough or learned categorical_generator column holds them. Confirm your approach with your assessor.

For which configurations can put real values in an output, see What the output can contain.

Evidence you can keep

Evidence Where it comes from

Evidence	Where it comes from
What a run was set to do	The effective configuration, printed by `tdk dry-run`, and the workflow’s configuration in Governor.
Who did what in Governor	The audit log: every authenticated API call, with the user, the time and the action. See What the platform records.
Who changed a workflow, and when	The workflow’s activity log and version history.
When a workflow ran, and its result	The workflow’s run history and run logs, in the web UI or through the REST API.
Which columns hold sensitive data	The results of a PII scan.
Who can do what	Users' global roles and project roles, under Administration and in each project. See Roles and Permissions.
That inputs can’t be written	Read-only data sources in Governor, and the grants of the platform’s database users. See Database Permissions.

What a run was set to do

The effective configuration, printed by tdk dry-run, and the workflow’s configuration in Governor.

Who did what in Governor

The audit log: every authenticated API call, with the user, the time and the action. See What the platform records.

Who changed a workflow, and when

The workflow’s activity log and version history.

When a workflow ran, and its result

The workflow’s run history and run logs, in the web UI or through the REST API.

Which columns hold sensitive data

The results of a PII scan.

Who can do what

Users' global roles and project roles, under Administration and in each project. See Roles and Permissions.

That inputs can’t be written

Read-only data sources in Governor, and the grants of the platform’s database users. See Database Permissions.

Keep the effective configuration of each run whose output you share, with the date and the data sources it used.

What stays your responsibility

Deciding which data needs protecting, and checking that each workflow protects it.
Assessing whether an output counts as anonymous, pseudonymised or de-identified under the rules that apply to you.
Controlling who can reach the output databases, and how long their data is kept.
Securing the hosts, networks and databases the platform runs on. See the Production Security Checklist.

Documents from Synthesized

Synthesized’s SOC 2 Type 2 audit is in progress, and the report is expected in December 2026. A SOC 2 report is an attestation, not a certification.

For your review of Synthesized as a supplier, Synthesized shares these documents on request:

the Security Assurance Pack: ten policies, covering information security and acceptable use, access control, operations security, secure development, incident response, risk management, business continuity and disaster recovery, third-party management, data management, and the support schedule;
a pre-completed CAIQ (Consensus Assessments Initiative Questionnaire), to start your security questionnaire from;
the SOC 2 Type 2 report, once it’s issued;
a signed Secure Software Development Attestation, the CISA form for software used by US federal agencies;
an Accessibility Conformance Report (VPAT).

The policies and the SOC 2 report are shared under NDA. The policies cover the systems Synthesized operates; a self-managed installation stays under your own controls. Ask your Synthesized representative, or write to security@synthesized.io.