Data Loss Prevention in Cloud Computing – GCP’s DLP API

Sensitive Data Protection (formerly Cloud DLP) is Google Cloud’s managed service for discovering, classifying, and de-identifying personally identifiable information (PII) across text, images, and structured data stores such as BigQuery and Cloud Storage. It matters because a single unredacted export can trigger a GDPR or PCI DSS breach notification. Recommended action: route sensitive fields through a DLP proxy with Cloud KMS-wrapped tokenization keys and least-privilege IAM before data ever leaves storage.

Published: January 2021. Updated: August 2026. Reviewed by Encryption Consulting’s Cloud Data Protection Team.

This post focuses on how to architect Sensitive Data Protection for production use on Google Cloud. For the vendor-neutral definition of data loss prevention and how DLP tooling compares across categories, see our Education Center explainer on What is Data Loss Prevention (DLP) & DLP Solutions. For how the wrapping key itself should be managed across clouds, see AWS KMS Vs Azure Key Vault Vs GCP KMS.

What Is Sensitive Data Protection (Formerly Cloud DLP)?

Sensitive Data Protection is Google Cloud’s product name for what was previously marketed as Cloud DLP; the API endpoint is still called the Cloud Data Loss Prevention API (DLP API). It gives organizations a way to detect the presence of personally identifiable information (PII) and other privacy-sensitive data in user-supplied, unstructured data streams, such as a paragraph of text, an image, or an audio recording converted to text via the Speech-to-Text API. The service also runs directly against data already resting in Google Cloud Storage, BigQuery, and Cloud SQL.

Sensitive Data Protection has three distinct capabilities that are often conflated in casual conversation: discovery profiles an entire organization, folder, or project to show where sensitive and high-risk data likely reside; inspection performs a deep scan of one resource to return the exact location of every matched instance; and de-identification obfuscates matched instances through masking, redaction, bucketing, date shifting, or tokenization. A fourth capability, risk analysis, evaluates re-identification risk on structured BigQuery data before and after de-identification.

How Does Sensitive Data Protection Detect and Classify Sensitive Data?

Detection runs on infoType detectors, Google’s term for the pattern-matching and machine-learning classifiers that recognize a specific category of sensitive data (a US Social Security Number, a credit card PAN, an email address). Google’s own infoType reference now lists well over 200 built-in detectors covering identity documents, financial data, health identifiers, and credentials across dozens of countries, and organizations can define custom detectors with regular expressions, dictionaries, or context rules for anything proprietary, such as an internal account-number format.

1. Sensitive Data Protection ships with 200-plus pre-built infoType detectors, and organizations can add custom detectors for internal formats.
2. After detecting sensitive data, the API can redact, mask, tokenize, or transform text and images to preserve privacy.
3. It is a fully managed service; Google scales inspection and transformation jobs to the volume of data submitted without customer-managed infrastructure.
4. Classification results can be written directly to BigQuery for analysis or exported to another environment for downstream processing.
5. Cloud DLP/Sensitive Data Protection undergoes independent third-party audits covering data handling, privacy, and security controls.

How Does Native vs. External Key Control Work for Tokenization and FPE?

Sensitive Data Protection’s tokenization and date-shifting transforms use cryptography to generate replacement values, and that cryptography needs a key. You can supply that key three different ways, and the choice determines who can technically re-identify the data later.

Key-control model	How it works	Best fit
Native (unwrapped raw key)	The AES key is passed directly in the API request body on every call.	Prototyping and ephemeral test data only; never production, since the key is exposed in every request and in Cloud Logging unless explicitly excluded.
Cloud KMS-wrapped key (BYOK-equivalent)	The AES key is encrypted (“wrapped”) by a Cloud KMS key, and only the wrapped ciphertext is sent to the DLP API; the API calls Cloud KMS to unwrap it for each operation.	Production deployments. Adds IAM-governed access control and a full Cloud Audit Logs trail for every unwrap operation.
External/HYOK-equivalent (Cloud EKM)	The Cloud KMS key referenced above is itself backed by an external key manager over Cloud External Key Manager (EKM), so Google never holds the unwrapped key material at rest.	Regulated workloads (financial services, government) where a contractual or regulatory requirement mandates that the cloud provider never possess usable key material.

Most organizations should default to the Cloud KMS-wrapped model. Wrapping the key in Cloud KMS adds an access-control and audit layer beyond what a bare key can provide, and Google’s own documentation calls it the preferred method for production deployments. Reserve Cloud EKM/HYOK for the narrow set of workloads where a regulator or customer contract requires it, since it adds latency and an external dependency to every tokenize/re-identify call.

How Does IAM Control Access in a DLP Proxy Architecture?

One reliable way to remove PII before it reaches a consumer is to route queries and results through a module that parses, inspects, and logs the findings, then de-identifies the results using Sensitive Data Protection before returning or forwarding the data. This module is commonly called a DLP proxy: it accepts a SQL query as input, runs it against the database, and applies the DLP API to the results before returning them to the requester.

Cloud Audit Logs is Google Cloud’s integrated logging service for this architecture, and it captures who made each DLP API call, which project it ran against, and whether a template was used. If auditing is enabled in the proxy’s configuration, Cloud Audit Logs also records a summary of the inspection findings.

Sensitive Data Protection also supports templates: reusable inspect and de-identify configurations that define what to look for and how to transform matches, referenced by name instead of repeated inline. A production DLP proxy should reference both an inspect template and a de-identify template rather than defining detection rules ad hoc per call.

For production, apply the principle of least privilege across three separate personas so no single identity can both access raw data and reconfigure detection rules:

1. Infrastructure admin installs and configures the proxy’s compute environment, but has no IAM grant to the Sensitive Data Protection API itself.
2. Data analyst accesses only the client application that connects to the DLP proxy, never the underlying database or the Cloud KMS key.
3. Security admin classifies the data, creates and maintains the inspect/de-identify templates, and is the only identity with cloudkms.cryptoKeyEncrypterDecrypter on the wrapping key.

How Should You Handle Wrapped-Key Rotation for Tokenization?

Rotating the Cloud KMS key that wraps a tokenization key creates a new active key version, but Google Cloud is explicit that rotation “doesn’t re-encrypt your data and doesn’t disable or delete previous key versions.” That distinction matters for tokenization specifically: if you rotate the wrapping key without a re-wrap and re-tokenize plan, existing tokens generated under the old key version become unrecoverable once that version is destroyed, because deterministic tokenization ties re-identification to the exact key version used to create the token.

A safe rotation runbook has three steps: rotate the Cloud KMS wrapping key on a schedule (Google’s general recommendation is roughly every 90 days for symmetric keys, though Cloud KMS does not enforce a fixed minimum or maximum rotation interval); re-wrap the AES tokenization key under the new Cloud KMS key version; and only then schedule destruction of the old Cloud KMS key version, with a deliberate delay (Cloud KMS defaults to a 30-day scheduled-destruction window, configurable per organization policy) long enough to confirm no outstanding tokens still depend on it.

What Should You Log When Using Sensitive Data Protection?

• DLP API call logs: caller identity, project, and whether an inspect/de-identify template was referenced, via Cloud Audit Logs.
• Inspection-finding summaries: counts and infoType categories matched, enabled through the proxy application’s own audit configuration rather than logging raw matches.
• Cloud KMS unwrap events: every Decrypt/AsymmetricDecrypt call against the wrapping key, so a security admin can detect anomalous re-identification activity.
• BigQuery export logs: when discovery or inspection results are written to BigQuery for analysis, standard BigQuery audit logging covers who queried the profiled results afterward.

Never log the unredacted match value itself; log the infoType category, the location, and the identity that triggered the scan. Logging the actual PII defeats the purpose of running DLP in the first place.

What Does Sensitive Data Protection Cost?

Sensitive Data Protection bills separately for inspection, transformation (de-identification), and discovery, and the rate depends on whether the job runs against storage (BigQuery, Cloud Storage, Cloud SQL) or against content submitted directly through the API. Directional list pricing as of this writing (confirm current rates against Google’s own pricing page before budgeting):

Job type	Inspection	Transformation
Storage jobs (BigQuery, Cloud Storage, Cloud SQL)	First 1 GB/month free, then ~$1.00/GB up to 50 TB, declining at higher volume	Same tiered structure as inspection
Content API calls (real-time)	First 1 GB/month free, then ~$3.00/GB up to 1 TB	First 1 GB/month free, then ~$2.00/GB up to 1 TB
Discovery (data profiling)	Consumption mode ~$0.03/GB profiled, or subscription mode at a flat rate per subscription unit for large estates

Cloud KMS charges separately for the wrapping key’s encrypt/decrypt operations, and those charges scale with how often tokens are created or re-identified, not with the volume of data scanned. Teams migrating a large BigQuery estate to tokenization should model Cloud KMS operation volume alongside Sensitive Data Protection’s own per-GB pricing, since a high-traffic re-identification workload can make the KMS operation cost the larger line item.

What Does a Multi-Cloud Data Loss Prevention Architecture Look Like?

Organizations running workloads across GCP, AWS, and Azure rarely get to standardize on one DLP product, because Amazon Macie and Microsoft Purview’s data loss prevention capabilities are scoped to their own storage and Microsoft 365 surfaces respectively, the same way Sensitive Data Protection is scoped to Google Cloud. The practical multi-cloud pattern is not a single DLP tool spanning all three clouds; it is a consistent policy (the same infoType categories, the same de-identification transforms, the same key-wrapping standard) implemented natively per cloud, with classification results centralized into one SIEM or data catalog for cross-cloud visibility.

The key-management layer is where standardization is actually achievable: whichever cloud holds the data, wrap the tokenization/FPE key in that cloud’s native KMS (Cloud KMS, AWS KMS, or Azure Key Vault) under a common rotation and access-review cadence, so an auditor sees one control regardless of which cloud produced the finding. See our comparison of AWS KMS, Azure Key Vault, and GCP KMS for how that native key-management layer differs across providers.

What Are the Limitations of Sensitive Data Protection?

• Detection is probabilistic. InfoType detectors reduce false negatives on common PII formats but will not catch every proprietary or unusually formatted identifier without a custom detector.
• It does not replace an encryption or access-control strategy. Sensitive Data Protection reduces exposure of what is already being read or exported; it does not stop an over-privileged identity from querying the raw source table directly.
• Tokenization key-version management is a customer responsibility. Google will not automatically re-wrap or retire tokenization keys; that lifecycle has to be built into the DLP proxy’s operational runbook.
• Cost scales with data volume across three separate billing dimensions (inspection, transformation, discovery), which is easy to underestimate on a large historical BigQuery backfill.

Decision Checklist: Deploying Sensitive Data Protection in Production

1. Inventory which data stores (BigQuery, Cloud Storage, Cloud SQL) actually hold regulated PII before scoping an inspection job.
2. Choose Cloud KMS-wrapped keys as the default tokenization/FPE key model; reserve Cloud EKM/HYOK for contractually mandated cases.
3. Stand up a DLP proxy with the three-persona least-privilege model (infrastructure admin, data analyst, security admin) rather than a shared service account.
4. Define a wrapping-key rotation and re-tokenization runbook before the first production token is issued, not after.
5. Model inspection, transformation, and discovery costs separately against expected data volume before committing to a full-estate rollout.

What Would Encryption Consulting Recommend?

We consistently see the same gap on Sensitive Data Protection deployments: teams stand up inspection and de-identification quickly, then never build the key-rotation and access-review runbook for the Cloud KMS wrapping key underneath it, which is exactly the piece an auditor asks about first. Encryption Consulting’s Cloud Data Protection advisory service designs the DLP proxy architecture, the least-privilege IAM model, and the wrapping-key lifecycle together, and our HSM-as-a-Service offering gives the underlying Cloud KMS key hardware-backed custody where a compliance requirement calls for it.

Frequently Asked Questions

Is Cloud DLP the same product as Sensitive Data Protection?

Yes. Google folded Cloud DLP into the broader Sensitive Data Protection product name; the API endpoint customers call is still the Cloud Data Loss Prevention API (DLP API), and existing integrations do not need to change.

Do I have to use Cloud KMS with Sensitive Data Protection?

No, you can pass a raw AES key directly to tokenization and date-shift calls. Google recommends wrapping the key in Cloud KMS for production, because it adds IAM-governed access control and a Cloud Audit Logs trail that a bare key cannot provide.

Can Sensitive Data Protection scan data outside Google Cloud?

It can inspect content submitted directly through the API regardless of where that content originated, but its storage-job scanning (the lowest-cost mode) is scoped to BigQuery, Cloud Storage, and Cloud SQL within Google Cloud.

What happens if I rotate the Cloud KMS wrapping key without re-tokenizing existing data?

Existing tokens remain re-identifiable as long as the old Cloud KMS key version they depend on still exists, since rotation alone does not delete previous versions. The risk appears only if that old key version is later destroyed before a re-tokenization pass runs against the data it protects.

How is Sensitive Data Protection priced compared to Amazon Macie?

Both charge on data volume processed rather than a flat subscription, but the billing dimensions differ (Sensitive Data Protection separates inspection, transformation, and discovery; Macie bills primarily on data evaluated for classification and monitoring). Model both against your actual data volume rather than comparing list prices directly, since the free tiers and per-GB breakpoints are structured differently.

Ready to close the gap between deploying Sensitive Data Protection and actually governing the keys behind it? Talk to Encryption Consulting’s Cloud Data Protection team about a DLP proxy and key-management review.