Google Workspace DLP: checking what is actually blocked

Google Workspace DLP is the set of data protection rules configured in the admin console to detect sensitive content and block, warn or log its sharing in Drive, Gmail and the managed Chrome browser. An active rule does not prove that a leak is blocked: only verification by active testing, with synthetic data, shows what actually gets through.

This article is for CISOs and SecOps teams who have deployed DLP rules in Google Workspace and want to know, with evidence to back it up, what those rules really stop.

What Google Workspace DLP covers, and what it does not

Google Workspace DLP rules apply to several surfaces, depending on your edition and your licences. The exact scope depends on the contract: check it before drawing any conclusion at all.

Scroll the table →

Why an “active” rule is not a rule that blocks

The console shows rules with active status. That is configuration information, not evidence of effectiveness. Several mechanisms make a rule fail without any alert:

• The scope of application. A rule limited to an organisational unit or a group ignores moved accounts, newcomers attached to the wrong unit and service accounts.
• The detectors. A predefined detector calibrated for a foreign format recognises a French identifier poorly. A custom detector based on an overly strict regular expression misses input variants (spaces, hyphens, line breaks).
• The thresholds. A trigger threshold set at several occurrences lets through a document that contains fewer.
• The chosen action. A rule in audit or warning mode has often stayed that way since the pilot phase. The user clicks “continue” and the file leaves.
• The scanning delay. On Drive, content scanning is not always instantaneous: a share made right after upload can precede detection.

These silent failures are detailed in our article on DLP false negatives. They have one thing in common: nothing in the console flags them.

Method: checking your rules channel by channel

The principle is simple. For each rule, you craft synthetic content that should trigger it, you attempt the forbidden action from a representative test account, then you compare the expected result with the observed result. The decoys must look like real data (same format, same document structure) without ever being real. The general method is described in our guide to synthetic data in production.

Drive: external sharing

1. Create a document containing synthetic numbers in the expected format (IBANs, social security numbers, classified internal references).
2. Upload it with a standard user account, in the organisational unit targeted by the rule.
3. Attempt a share to an external address, then the creation of a public link.
4. Repeat with variants: PDF, spreadsheet, compressed archive, scanned image, renamed document.
5. Note for each variant: blocked, warned, logged, or nothing.

Gmail: outbound email

Send messages carrying the decoy in the body, as an attachment, then inside a nested attachment, to an external test mailbox you control. Check the actual behaviour on the recipient side: a message supposedly blocked that arrives anyway is the most important finding of the day. The specifics of this channel are covered in our article on email DLP.

Chrome: upload and copy and paste

From a workstation with managed Chrome and the work profile, try to upload the synthetic file to an unauthorised storage service, then paste its content into a web form. Then repeat the test from a personal profile, and then from another browser on the same workstation. If only the first attempt is blocked, you know exactly where the boundary of your control lies.

A concrete scenario

A mid-sized company (ETI) deploys a Drive rule that blocks external sharing of documents containing social security numbers. The console has shown it as active for months. A test with a synthetic spreadsheet shows that sharing is indeed blocked. The same content exported as a scanned PDF gets through without an alert, because the chosen configuration has no text recognition on that format. And an account attached to an organisational unit created after the deployment is covered by no rule at all.

Two fixes, very different in effort: extending the rule’s scope (a few minutes), dealing with scanned documents (an architecture decision). That is precisely what verification should produce: a prioritised list of actions, not an overall finding.

Verification checklist

• Every rule has a written test scenario, with an expected result.
• Tests cover all organisational units, including the most recent ones.
• Format variants are tested, not only the nominal format.
• Rules in audit or warning mode are inventoried and justified.
• DLP logs do produce an event the SOC can act on.
• Paths outside Workspace (unmanaged browser, personal synchronisation) are tested separately.
• Tests are replayed after every change of rule, licence or organisation.

This last point matters more than it seems. A DLP posture degrades over time, through reorganisations and configuration changes. A one-off test gives a snapshot, regular replay gives a trend. For an overview of the approach, see our page on data exfiltration testing.

Frequently asked questions