Sensitive Data Protection, De-identification and Pseudonymization

What it is

Sensitive Data Protection (SDP), which includes the Cloud Data Loss Prevention (DLP) API, finds sensitive data such as names, card numbers and national IDs, and transforms it so it is safe to use. It works on data at rest in Google Cloud and on content you send to the API.

Its two jobs are finding sensitive data (discovery and inspection) and reducing risk (de-identification).

How it works

Finding sensitive data

Detection uses infoTypes. Built-in ones include EMAIL_ADDRESS, CREDIT_CARD_NUMBER, PHONE_NUMBER and many country-specific IDs. Custom infoTypes use a dictionary or regular expression, for example employee IDs, and likelihood thresholds trade false positives against misses.

Findings and profiles can be sent to Security Command Center, BigQuery, Pub/Sub or Dataplex Universal Catalog. Saving settings as inspect templates keeps detection consistent across jobs.

De-identification methods

Pseudonymization means replacing identifiers with consistent tokens, using hashing, deterministic encryption or FPE. The same input always gives the same token, so analysts can count and join without seeing real values.

Reversible methods need a key; use a key wrapped by Cloud KMS rather than a raw key in the request. Re-identification calls the reidentify method with the same configuration and needs access to that key.

Example: tokenizing card numbers and hiding emails

{
  "item": {"value": "Card 4111111111111111 paid by ana@example.com"},
  "inspectConfig": {
    "infoTypes": [{"name": "CREDIT_CARD_NUMBER"}, {"name": "EMAIL_ADDRESS"}]
  },
  "deidentifyConfig": {
    "infoTypeTransformations": {
      "transformations": [
        {
          "infoTypes": [{"name": "EMAIL_ADDRESS"}],
          "primitiveTransformation": {"replaceWithInfoTypeConfig": {}}
        },
        {
          "infoTypes": [{"name": "CREDIT_CARD_NUMBER"}],
          "primitiveTransformation": {
            "cryptoReplaceFfxFpeConfig": {
              "cryptoKey": {
                "kmsWrapped": {
                  "wrappedKey": "BASE64_WRAPPED_KEY",
                  "cryptoKeyName": "projects/sec-keys/locations/global/keyRings/sdp/cryptoKeys/fpe"
                }
              },
              "commonAlphabet": "NUMERIC",
              "surrogateInfoType": {"name": "CARD_TOKEN"}
            }
          }
        }
      ]
    }
  }
}

The email becomes [EMAIL_ADDRESS]. The card number becomes a numeric token of the same length, prefixed with the surrogate name so it can be found and re-identified later. Save this as a de-identify template so every pipeline applies the same rules.

Where de-identification runs

A worked example

An insurer's data lake has unknown PII. The engineer turns on discovery for the organization, which profiles every BigQuery table and flags 60 tables with high sensitivity, published to Security Command Center.

New data flows through Dataflow, which calls a de-identify template: emails replaced, policy numbers tokenized with deterministic encryption, birth dates bucketed to years. Only the fraud team can re-identify, because only it has access to the KMS key.

How the exam asks about this

• "Analysts must join customer records across tables without seeing real customer IDs, and a small team must be able to recover them." Deterministic encryption or FPE with a KMS-wrapped key.
• "A legacy system validates that account numbers are 16 digits, but real numbers must not be stored there." Format preserving encryption.
• "Find which BigQuery datasets across the organization contain sensitive data." Sensitive Data Protection discovery with data profiles.