Most Google Workspace data leaves through ordinary sharing, sending and pasting, and the controls that stop it are spread across data protection rules, trust rules, classification labels and Chrome policies that many tenants never connect. This guide goes deeper than the general Workspace hardening pages: it explains how each data protection layer actually evaluates content, what it cannot see, and how to combine them into one working programme for Drive, Gmail, Chat, Calendar and the browser. It is for Workspace administrators and data protection engineers who already have a baseline and now need rules that block real leaks without flooding users with warnings.
This is an independent guide from NHI Mgmt Group, based on Google's public Workspace documentation as of November 2026. It is not sponsored or reviewed by Google. Product features change, so confirm settings against Google's current documentation.
Key takeaways
- Rules follow the owner, not the reader. Drive data protection rules and trust rules are evaluated against the file owner's organisational unit (OU) or group, or against the shared drive, so where files live decides which policy applies.
- Each app scans differently. Drive scans files continuously, Gmail scans before and after sending, and Chat scans sent messages within a fixed time budget, so the same detector can behave differently per app.
- Labels are the bridge between classification and enforcement. Badged labels and single-select options lists can be applied by rules, by AI classification or by default policy, then used as conditions to block sharing or sending.
- Encrypted content is invisible to content scanning. Client-side encrypted files and mail are not scanned, so rules must fall back to labels, titles and encryption status.
- Audit first, then enforce. An inactive or action-free rule logs matches to the rule log without touching users; promote it to warn and then block only after reviewing real matches.
The data protection stack in Workspace
Workspace has several policy engines that share a rules page (Menu > Rules) and a common log but evaluate different things. Knowing which one decided an outcome is the first step in diagnosing a leak or a false block.
| Layer | What it decides | Evaluated against | Typical use |
|---|---|---|---|
| Drive sharing settings or trust rules | Who may share with whom, regardless of content | Owner's OU or group, and the other party | Block sharing with personal accounts; allow one partner domain for one team |
| Data protection rules (DLP) | What happens when content matches a condition | Content, metadata, labels, Context-Aware Access level | Block external sharing of files with card numbers; quarantine outbound mail with passport numbers |
| Classification labels | How sensitive an item is, as structured metadata | Applied manually, by rule, by AI model or by default policy | "Confidential" badge that drives DLP and Vault retention |
| DLP for Chrome | Upload, download, paste, print and URL actions in the managed browser | Content and browser context | Stop pasting customer data into unsanctioned web apps |
| Client-side encryption (CSE) | Whether Google can read the content at all | Keys held in a key service the customer controls | Highly restricted material where provider access is unacceptable |
The general hardening settings (Takeout, Drive SDK, Chat external file sharing, SCuBA policy IDs) are covered in the Google Workspace Security Guide and the Google Workspace Security Checklist. Vendor-neutral detection and tuning principles are in the Data Loss Prevention (DLP) Guide.
Editions and privileges
As documented in November 2026:
- Data protection rules for Drive and Gmail: Frontline Standard and Plus, Enterprise Standard and Plus, and Education Fundamentals, Standard and Plus. Drive DLP is also listed for Enterprise Essentials Plus.
- DLP for Chat: Frontline Standard and Plus, Enterprise Standard and Plus, and Education Fundamentals, Standard and Plus.
- Trust rules for Drive: Frontline Plus, Enterprise Standard and Plus, Education Standard and Plus, and Enterprise Essentials Plus.
- Classification labels: a wider set, including Business Standard and Plus and Frontline Starter. AI classification is included with Frontline Plus and Enterprise Plus, or with certain AI add-ons.
- DLP for Chrome: requires the Chrome Enterprise Premium add-on.
- Client-side encryption: Frontline Plus, Enterprise Plus, and Education Standard and Plus.
Separate admin privileges govern each layer: View and Manage DLP rule, View and Manage Chrome DLP rule, View and Manage Trust Rules, and Manage Classification Labels. Grant them to a small data protection admin role, because anyone who can edit a rule can quietly switch it to audit only.
Drive sharing control: settings versus trust rules
Before content inspection, decide who may share with whom. Classic Drive settings (Apps > Google Workspace > Drive and Docs > Sharing settings) work per OU. Trust rules replace them with explicit allow, warn and block rules that can target users, groups, OUs and domains.
- Conversion: turning trust rules on converts existing "Sharing outside your organization" settings into trust rules and deactivates the old settings. Preview converted rules by filtering the Rules page for the Trust type.
- Rollback cost: turning trust rules off restores the previous Drive settings and permanently deletes any trust rules you created. Export or document every rule before testing a rollback.
- Rule structure: a scope (whose files), a trigger (sharing, receiving or both), conditions (the other party, such as specific domains, groups or anyone with a Google Account) and an action. When rules conflict, Block beats Allow, and Allow beats Allow with warning.
- Two default rules: sharing within the organisation, and sharing with anyone who has a Google Account. The second is the one to deactivate or narrow first.
- Limits and timing: 200 active rules and 2,000 in total; changes take up to 24 hours, or up to 48 hours when OUs are in scope or conditions.
Trust rules apply to files owned by users or shared drives in scope. If a user moves OU or leaves a group that permitted external sharing, files they own take on the new rules, and earlier external shares stop working. Test OU moves on a pilot group before a bulk reorganisation. Admin logs do not record what changed in a trust rule, so keep rule definitions under change control outside the console.
How data protection rules evaluate content
A data protection rule has apps and triggers, actions, an optional alert severity, a scope and conditions. Conditions combine with AND, OR and NOT and can test content (all content, body, title, file name, extension, MIME type, suggested edits), a classification label value or the file encryption status. Drive and Chrome rules can also require a Context-Aware Access level.
Detectors
- Predefined data types: for example "United States - Social Security Number". Each condition has a likelihood threshold, a minimum unique match count and a minimum match count. Raising the minimums is the first lever against false positives.
- Custom regular expressions: written in Google RE2 syntax, with a Test Expression button in the console. Use them for internal identifiers such as project codes or account number formats.
- Custom word lists: comma-separated, case and symbols ignored, whole words only, each entry at least two alphanumeric characters. Use them for code names and restricted product names.
- Proximity: Drive conditions can limit a detection to a set distance from a keyword or pattern.
Editing a detector that a rule uses rescans affected Drive files; plan detector changes like code releases.
Per-app behaviour
| App | Trigger and scan | Actions | Blind spots |
|---|---|---|---|
| Drive | Files owned by users or shared drives; modification triggers evaluation; continuous scan of the latest revision | Block external sharing; warn on external sharing; disable download, print and copy; apply classification label; audit only | Comments, Sites content, form responses other than uploads, password-protected files, audio and video; images only with OCR on |
| Gmail | Message sent and message received; synchronous scan at compose and send, asynchronous scan after send | Block, warn and quarantine (outgoing only); audit, apply classification label and add custom note (both directions) | Password-protected attachments; files attached from Drive (Drive DLP scans those); very large attachments may only be caught after send |
| Chat | Messages and attachments sent in 1:1 chats, group chats and spaces, even with history off | Block message, warn users, audit only | Incoming messages, linked content, password-protected files; detectors may time out, notably date of birth and person name |
| Chrome | File uploaded, file downloaded, content pasted, content printed, URL visited | Block; enforce cloud storage (downloads); allow with warning; audit only | Up to 10 MB of text scanned per file; no URL evaluation inside embedded iframes |
In Drive and Chat the stricter action wins. In Gmail, Block beats quarantine and quarantine beats warn; when several rules share the same action, only the first by rule resource name applies, and data protection rules run before legacy content compliance and routing rules.
Classification labels as the enforcement backbone
Detectors find regulated data patterns but cannot tell a board paper from a lunch menu; labels add sensitivity metadata that rules can test. Labels are created in Security > Access and data control > Label manager; an organisation can have up to 150 labels, each with up to 10 fields.
- Badged label: a label with a badge list field (one per label, up to 200 options), shown prominently in Drive and Gmail. Use one badged label for the organisation's sensitivity scheme, mirroring the Data Classification Policy Template levels.
- Standard labels: other field types (options lists, number, date, text, person) for ownership, project or retention metadata. Several field types are not available in Gmail, so keep the sensitivity field as a single-select list if it must work in both apps.
- Publishing: new labels start as drafts, field types cannot be changed after publishing, and labels used in DLP or Vault retention rules are locked and cannot be disabled or deleted. Design the scheme before the first publish.
- Required fields are prompts: they highlight a field but do not force a choice; enforcement comes from rules.
Three ways labels get applied
| Method | Basis | Strength | Watch out for |
|---|---|---|---|
| Default classification (Drive) | Owner's OU or group, or the shared drive, at creation or ownership change | Predictable baseline: everything HR creates starts as "Internal" | Does not read content; does not relabel existing files unless ownership changes |
| Data protection rule (Drive and Gmail) | Content and metadata conditions | Labels new and existing content; can stop users changing the value | A rule cannot use the same label as both condition and action; Gmail messages hold at most 20 labels |
| AI classification (Drive) | A custom model trained on your labelled files, or Gemini instructions (beta) | Catches sensitive documents with no regex-friendly pattern | Needs at least 100 training files per option and 2 to 7 options; applied labels cannot be rolled back |
When methods disagree, data protection rules win, then the user's manual choice, then AI classification, then default classification. Google reports custom model quality as recall per label option and recommends waiting until every option reaches at least 80 per cent before turning on auto-apply. Test automatic labelling on a temporary label and a small audience first.
Client-side encryption and what it changes
CSE encrypts content in the user's browser with keys from a key service the customer controls (Cloud HSM for Google Workspace, a partner key service, or a service built on the CSE API). It covers Gmail, Drive including shared drives, Calendar, and Docs, Sheets and Slides. The trade-off for DLP is direct: DLP cannot read encrypted content, and encrypted files and mail are not scanned for phishing or malware. Vault can still retain, search and export encrypted items, but only on metadata such as title and owner.
Keep CSE for the small set of material where provider access is unacceptable, label it, and write rules on the "File encryption status" condition and label values. Key access control lists in the key service become a data protection control in their own right; see the BYOK, HYOK and External Key Management Guide.
Browser and AI channels
Users also copy data into personal webmail and consumer AI tools. DLP for Chrome extends the same rule engine to the managed browser on Windows, macOS, Linux and ChromeOS, with conditions on source URL, URL category, Incognito, clipboard source and the signed-in account of the web app. A practical first rule is "Content pasted" with the source being a Workspace app and the destination URL category being generative AI, set to warn. For downloads, "Enforce cloud storage" keeps files off the device and saves them to the organisation's cloud storage instead, for files up to 150 MB. Browser-level design choices are covered in the Enterprise Browser and Browser Security Guide.
Google also lists Gemini and Workspace Studio among the surfaces data protection rules can govern, and the rule log now records agent execution events (audited, blocked, end user review) with agent ID and name. Review it with the Gemini for Google Workspace Security Guide.
Where identity fits
Every DLP outcome is keyed to an identity: the file owner, the sender, the OU or group. Two identity gaps undermine good rule sets.
- Service accounts and automation: Drive DLP blocks downloads and transfers through automated tools when a file violates an active rule, and high volumes of simultaneous preflight checks by apps or scripts can cause connection failures. Inventory integrations before enforcing, and review service accounts with domain-wide delegation, which can read Drive and Gmail as any user. See the Google Workspace Domain-Wide Delegation Security Guide.
- OAuth apps: a third-party app with Drive scopes moves data through the API, not the sharing dialog. Pair DLP with app access control; see How to Inventory third party oauth apps in google workspace.
Phased rollout
- Inventory (weeks 1 to 2): confirm editions per OU; list sharing settings, shared drives with external members, OAuth apps with Drive or Gmail scopes and Gmail content compliance rules. Agree the sensitivity scheme with data owners.
- Labels (weeks 2 to 4): publish one badged sensitivity label with a single-select list. Turn on default classification for a pilot OU so new files start labelled. Do not attach labels to DLP rules yet, because that locks them.
- Audit rules (weeks 3 to 6): create rules with no action (audit only) for the top regulated data types and custom detectors, scoped organisation-wide. Google's templates, such as "Prevent financial information sharing (International)", are a reasonable start.
- Sharing control (weeks 4 to 8): preview converted trust rules, narrow the "anyone with a Google Account" default for a pilot group, and add explicit partner rules.
- Warn (weeks 6 to 10): switch tuned rules to warn for a pilot ring; frequent overrides mean the rule is wrong or the process needs a sanctioned path.
- Block (from week 10): enforce block for high-confidence detectors and for the top sensitivity label value, ring by ring. Keep a named rollback: set the rule to Inactive, which takes effect within the documented propagation window of up to 24 hours.
- Extend: add AI classification once you have enough labelled examples, then Chrome rules and CSE for the narrow cases that need them.
Decision guidance
- Trust rules or classic settings: classic OU settings are enough when every OU has one sharing posture. Choose trust rules when different groups need different partner domains, or when you need receiving controls. Factor in the destructive rollback.
- Content rules or labels: use content detectors for regulated identifiers with reliable patterns. Use labels for business-sensitive material such as strategy documents, contracts and source designs, where patterns fail.
- Warn or block: block where a single leak is reportable (card data, health data, national identifiers in bulk). Warn where context matters and an audit trail of the user's decision is valuable.
- Small organisations: on Business editions without DLP, rely on sharing settings, labels and default classification; the Google Workspace for Small Business page covers that baseline.
- Large or regulated organisations: run rules as reviewed change and decide CSE scope with legal and records teams.
Detection and measurement
Every rule match writes a rule log event, usually within an hour of the user action. Drive events include "Sharing blocked", "Access blocked", "Label applied" and "Label removed"; Gmail events include message send audited, blocked, quarantined and warned. Fields include rule name, severity, triggered and suppressed action, detector name, resource owner and actor OU. Investigate in the security investigation tool and forward events with the rest of the audit stream as described in the Google Workspace Audit Log Detection Guide.
Detections worth building on top of DLP events:
- A single actor triggering many warn overrides in a short window, especially near a resignation date.
- "Label removed" or field value changes on high-sensitivity labels followed by external sharing.
- Rule edits that change action from block to audit, or change scope, by anyone outside the data protection admin role.
| Metric | How to measure | What good looks like |
|---|---|---|
| Labelled share of sensitive locations | Labelled files in target shared drives divided by all files there | Rising each quarter towards the agreed coverage target |
| Warn override rate | Overrides divided by warnings per rule | Falling after tuning; persistent high rates trigger rule review |
| True positive rate on block rules | Sampled incidents confirmed as genuine | High enough that users are not taught to route around blocks |
| Externally shared files carrying top sensitivity label | Count from Drive audit and label events | Near zero outside approved exceptions |
Framework mapping
| Workspace control | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | ISO/IEC 27001:2022 Annex A | ATT&CK technique addressed |
|---|---|---|---|---|
| Trust rules and sharing settings | AC-21 Information Sharing; AC-3 Access Enforcement | PR.DS-01 | A.5.14 Information transfer | T1530 Data from Cloud Storage |
| Data protection rules | AC-4 Information Flow Enforcement | PR.DS-01, PR.DS-02 | A.8.12 Data leakage prevention | T1567.002 Exfiltration to Cloud Storage |
| Classification labels | AC-16 Security and Privacy Attributes | ID.AM-07 | A.5.12 Classification of information; A.5.13 Labelling of information | Supports all of the above |
| Client-side encryption | SC-28 Protection of Information at Rest | PR.DS-01 | A.8.24 Use of cryptography | T1530 Data from Cloud Storage |
| Rule log monitoring | AU-6 Audit Record Review; SI-4 System Monitoring | DE.CM-03 | A.8.16 Monitoring activities | T1114.003 Email Forwarding Rule (paired with Gmail controls) |
In CIS Controls v8.1, this work sits under Control 3 (Data Protection), notably the data classification and data loss prevention safeguards.
Common failure patterns
- Labels locked too early: a label used by a DLP or Vault rule is locked, so a rushed scheme becomes permanent.
- Assuming Gmail DLP covers Drive attachments: files attached from Drive are scanned by Drive DLP, not Gmail DLP. A Gmail-only rule set leaves the most common sharing path unchecked.
- Trust rules switched off to "test" a rollback: this permanently deletes the custom rules. Document first.
- Over-trusting Chat DLP: detectors can time out and .csv files are scanned as plain text, so column-based data can slip through.
- Encrypted or password-protected files treated as safe: DLP cannot read them. Write rules on encryption status and use Gmail attachment compliance for password-protected archives.
- Rules scoped to the sharer instead of the owner: Drive rules follow the owner's OU or the shared drive. A finance user sharing a file owned by marketing is governed by marketing's rules.
Practitioner checklist
- Create a dedicated data protection admin role with DLP, trust rule and label privileges, separate from general admins.
- Publish one badged sensitivity label with a single-select list after data owners agree the scheme.
- Turn on default classification for high-value OUs and shared drives.
- Tune predefined detectors with likelihood, minimum unique matches and proximity before enforcement.
- Preview converted trust rules and narrow the "anyone with a Google Account" default.
- Write rules on encryption status and labels for client-side encrypted content.
- Inventory automation, OAuth apps and domain-wide delegation that touch Drive before enforcing block.
- Forward rule log events to the SIEM and alert on rule edits that weaken actions.
Standards and references
- Google: Create data protection rules
- Google: About DLP for Drive
- Google: About DLP for Gmail
- Google: About DLP for Chat
- Google: Create and manage trust rules for Drive sharing
- Google: Create classification labels for your organization
- Google: Label Google Drive files automatically using AI classification
- Google: Rule log events
Related NHI Mgmt Group resources: Data Loss Prevention (DLP) Guide, Google Workspace Security Guide, Data Classification Guide, Google Workspace Compromise Playbook, Data Exfiltration Guide.