# Compliance

> Source: https://docs.synthesized.io/tdk/latest/user_guide/060_security_compliance/compliance
> For the complete documentation index, see [llms.txt](https://docs.synthesized.io/llms.txt).

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.

> **NOTE**
> 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](https://docs.synthesized.io/tdk/latest/user_guide/060_security_compliance/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](https://docs.synthesized.io/tdk/latest/user_guide/060_security_compliance/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](https://docs.synthesized.io/tdk/latest/user_guide/030_core_concepts/pii).

 |
| 

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](https://docs.synthesized.io/tdk/latest/user_guide/060_security_compliance/rbac/).

 |
| 

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](#_evidence_you_can_keep).

 |

## Regulations

  
| 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.

 |

For which configurations can put real values in an output, see [What the output can contain](https://docs.synthesized.io/tdk/latest/user_guide/060_security_compliance/data_protection#_what_the_output_can_contain).

## Evidence you can keep

 
| 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](https://docs.synthesized.io/tdk/latest/user_guide/060_security_compliance/security_overview#_what_the_platform_records).

 |
| 

Who changed a workflow, and when

 | 

The workflow’s activity log and [version history](https://docs.synthesized.io/tdk/latest/user_guide/020_guides/managing_data_properties/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](https://docs.synthesized.io/tdk/latest/user_guide/020_guides/advanced_workflows/external_api_reference).

 |
| 

Which columns hold sensitive data

 | 

The results of a [PII scan](https://docs.synthesized.io/tdk/latest/user_guide/030_core_concepts/pii).

 |
| 

Who can do what

 | 

Users' global roles and project roles, under **Administration** and in each project. See [Roles and Permissions](https://docs.synthesized.io/tdk/latest/user_guide/050_deployment_operations/administration/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](https://docs.synthesized.io/tdk/latest/user_guide/010_get_started/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](https://docs.synthesized.io/tdk/latest/user_guide/060_security_compliance/production_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](mailto:security@synthesized.io).
