Skip to content

Mask PII / GDPR

The goal of masking in DataMaker is to use the shape of real data without moving real PII where it shouldn’t go. You declare which fields are sensitive, the platform masks them, and the rest of the pipeline behaves accordingly.

The model

  1. Mark fields sensitive on the template (or on a fetched set) and pick a masking strategy per field. See Templates → Sensitive fields.
  2. Mask before it leaves: sensitive values are substituted before the set is exported or handed downstream.
  3. Keep it auditable: masking and exports are recorded so your DPO can review.

Practical pipeline

To turn an existing real table into a safe staging set, drive it from the agent, which has the source connection and the masking behaviour built in:

From the prod (read-only) Postgres connection, pull ~5,000 customers created in the last 90 days. Mask name, email, tax_id, and dob (format-preserving where a validator needs to pass), then push the masked rows into the staging Postgres connection.

Behind the scenes the agent fetches the rows, applies each field’s masking strategy, and exports the safe set, so the real values never land in the destination. Ask it to save this as a scenario to make the flow repeatable.

Strategies

The strategy you pick per field controls how the value is replaced: substitute a fresh fake, preserve the format so downstream validators still pass, or redact. See Sensitive fields for the available strategies and for how deterministic (seeded) masking lets you join masked sets without re-introducing the real key.

What to avoid

  • Don’t print() real values before masking. Run logs are retained, and a raw print(row) lands in them. Log counts or redacted summaries instead.
  • Don’t write real values to a workspace file before masking. Workspace files are plain blobs, not subject to per-field masking. Mask first, then write.
  • Don’t copy real data into a non-DataMaker store and consider yourself done. The masking guarantee only holds while the data flows through DataMaker.