What to take away
Google Workspace data loss prevention (DLP) uses rules to detect sensitive content and apply configured protections. This guide focuses on Google Drive: check your edition, test a rule, investigate gaps, then review who still needs access. Content detection and permission cleanup are complementary jobs.
1. Check which Google Workspace DLP controls you have
Full Drive DLP rules are available on supported editions, including Enterprise Standard and Enterprise Plus. Check Google’s current edition list before following the custom-rule setup below. Business Plus includes Security advisor protections with a subset of predefined detectors and more limited rule editing.
Write down your edition, available controls, and the Drive locations you need to protect. A missing custom-rule option can be an entitlement or admin-role issue. Start by checking those two points rather than assuming protection is active or immediately buying another tool.
References: Google — About DLP for Drive · Google — Security advisor for data protection
2. Separate content, permissions, and business need
Google’s Drive DLP documentation describes rules that inspect eligible content and apply configured actions, including warnings or blocks on external sharing. Availability depends on your Workspace edition and administrative privileges. Check the current provider documentation before choosing controls.
Your review also needs an account of the audience and the business reason for sharing. A confidential file can have appropriate access, while an ordinary project document can still expose information to an obsolete collaborator. Use the three views below together when choosing what to investigate.
| View | Question it answers | Evidence to retain |
|---|---|---|
| Content and DLP | Does supported content match a sensitive-data rule? | Rule, finding, scope, and observation date |
| Sharing permissions | Which people, groups, or link audiences have access? | Current permission details and drive context |
| Owner review | Is this audience still needed for the work? | Decision, business reason, and exception owner |
| Verification | Did the intended access change actually happen? | Source state checked after the change |
References: Google — About DLP for Drive
3. Define the scope and collect a dated view
Start with a business area, sensitive project, or group of external collaborators. Identify the relevant My Drive and shared-drive content, responsible owners, and review date. Decide how you will examine public links, named external recipients, and group-based access. Record any areas you cannot inspect.
For each item, keep a file reference, owner, location, audience, sensitivity signal, proposed action, and decision owner. Include the date of collection. A file can change between discovery and review, so check the current source before making a correction. Keep investigation records limited to what reviewers need; copying the sensitive document into a tracking sheet creates another exposure to manage.
4. Configure a Drive DLP rule, then test it in audit mode
In the Admin console, open Security → Access and data control → Data protection. Creating rules requires the relevant DLP, organizational-unit and group admin privileges; use Google’s linked setup instructions to verify the role.
Use an isolated pilot scope and synthetic documents. Give the rule a clear purpose, such as identifying a fictional project codename before deciding whether its external sharing should be blocked.
- Create a rule under Manage rules and select Google Drive files.
- Choose the pilot scope and a content condition: a predefined detector, word list, or expression.
- For an audit-only test, leave the enforcement action unselected and save the rule as Active. Inactive rules do not test anything.
- Inspect Rule log events. Once the test is satisfactory, choose the appropriate warning or blocking action, communicate the change, and repeat the test.
| Example rule to test | Synthetic fixture | What to record |
|---|---|---|
| Internal project name | A test document containing the fictional codename CEDARTEST, and a control document without it. | Whether only the intended document matches; inspect broad or ambiguous words before enforcement. |
| Sensitive-data detector | A provider-approved synthetic example for the chosen detector, plus a similar non-sensitive example. | The detector and threshold, both observed results, and any false positive to investigate. |
| External-sharing control | A test owner, an approved external test account, and an internal collaborator. | The observed sharing outcome for each account before and after the chosen action. |
References: Google — Create DLP rules and test with audit-only actions · Google — Create data protection rules
5. Diagnose missing detections and unexpected sharing
No alert is not proof that a document is safe. Check the rule, the test fixture and the access path separately. Google documents both content exclusions and scanning limits; compare the exact file you tested with those limits.
| Observation | Check next | Evidence before closing |
|---|---|---|
| Nothing is detected | Confirm the rule is active, the owner or shared drive is in scope, and the condition matches the fixture. Allow for scan processing. | A matching and a non-matching synthetic test, with rule and observation times. |
| A large or protected file is missed | Check the supported format and extraction limits. Drive DLP evaluates the first 10 MB of extracted text; password-protected contents are excluded. | File type, size, location of the test content, and the documented coverage limit. |
| The rule matches but a user can share | Check the configured action. Audit mode records; a warning can be overridden. Check the actual recipient and other access paths. | The rule event, chosen action and resulting recipient access. |
| A sharing event appears in a log | Read the current permissions too. A historical event does not establish today’s audience. | A dated permission check, including relevant groups and inherited access. |
References: Google — About DLP for Drive · Google — Drive log events · Google — DLP content and rule size limits
6. Choose the smallest appropriate correction
Consider a fictional procurement folder shared with a supplier whose engagement has ended. Ask the owner whether the supplier still needs access, whether a group grants additional access, and whether another team relies on the same folder. If removal is appropriate, assign the change and record its completion rather than stopping at the reviewer’s approval.
For an active collaboration, the answer may be to retain a named recipient while removing an unnecessary broad link. For an exception, record the reason, approver, permitted audience, and review date. Prioritize exposure and sensitivity while preserving a clear route for legitimate business work.
- Validate the current audience and business purpose with the owner.
- Choose the permission or policy change that addresses the identified issue.
- Name the person who will apply changes that cannot be made directly.
- Retain the decision separately from the evidence that it was implemented.
7. Verify access and watch for retained permissions
Google documents an important shared-drive behavior: tightening an external-sharing restriction can prevent access while leaving the underlying file permission in place. If the restriction is later relaxed, that permission can grant access again. Record whether you removed a permission or only changed a policy that currently blocks it.
After a correction, inspect the source and validate access using approved test accounts where appropriate. Check that the intended audience lost access and that required collaborators can still work. Include relevant group membership and inherited access in that assessment. Retain the result, date, and any unresolved access path before closing the item.
References: Google — How file access works in shared drives
How Elba supports a Drive sharing review
Elba can connect supported Drive sharing findings to the asset, audience, and employee who understands the context. Eligible issues can expose direct permission removal or be distributed to an employee for review and a supported correction. Data Protection Playbooks help organize recurring findings around the conditions available in your workspace.
The Google Workspace directory connection is separate from the Google security-source grant used for supported Drive and OAuth security workflows. Connecting the directory does not enable Drive inspection by itself. Findings and actions depend on the enabled grant, workspace configuration, and object. Review the live scopes and validate representative findings before relying on coverage.
Drive sharing review checklist
Your checks stay on this page and reset when you reload it.
Common questions
Does DLP replace a review of sharing permissions?
No. Content rules, the current audience, and the business need answer different questions. Use them together to decide whether a particular exposure needs a correction.
Does blocking external sharing remove every existing permission?
Do not assume so. Google documents shared-drive restrictions that prevent access while retaining underlying permissions. Check the resulting source state and the effect of later policy changes.
How should a team handle legitimate external collaboration?
Verify the intended recipients with the owner, remove unnecessary access where appropriate, and document any exception with a review date. Blanket changes can disrupt work if the scope is not understood.
Does the Elba directory connection automatically inspect Drive?
No. Supported Drive security workflows require the separate Google security-source grant and the relevant capabilities to be enabled. Direct corrections are available only for eligible objects and permissions.
Sources & further reading
Primary documentation used to review this guide. Product settings and edition requirements can change; check the linked documentation before making changes.