How should security teams investigate sensitive data access in Google Workspace across My Drive and Shared Drives?

Security teams should correlate audit activity with data classification and identity context, not treat every file event as equal. Focus on access, sharing, movement, and deletion events involving sensitive data such as PII, PCI, credentials, or regulated records. That approach turns raw logs into actionable investigations and helps teams prioritize the events most likely to create exposure.

Why This Matters for Security Teams

Google Workspace file activity often looks routine until it involves regulated records, credentials, customer data, or internal source material. The main issue is not the volume of events, but the fact that My Drive and Shared Drives behave differently from a governance perspective. Security teams need to distinguish legitimate collaboration from exposure, especially when access is inherited, link-sharing is enabled, or a file moves from a restricted area into a broadly accessible workspace. Current guidance suggests treating audit data as an investigation signal, not as proof of risk on its own.

For practitioners, the investigative mistake is usually assuming that ownership, location, and sharing state tell the full story. They do not. A sensitive file can remain in My Drive with broad access through delegation, or sit in a Shared Drive with tightly controlled membership but still be copied, downloaded, or redistributed. That is why identity context, classification context, and event sequencing matter together. The control objective aligns with NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where logging, access enforcement, and incident review depend on reliable evidence. In practice, many security teams encounter the exposure only after a file has already been shared externally or copied into an unmanaged location, rather than through intentional monitoring.

How It Works in Practice

Effective investigation starts by building a timeline around the sensitive file, then layering in user identity, device context, and permission changes. Teams should review events such as file open, share, permission grant, move, copy, download, deletion, and ownership transfer. The most useful question is not simply who accessed the file, but who gained new capability over it, from where, and whether that access was consistent with job role and approved need.

My Drive investigations often require closer attention to direct ownership and user-driven sharing, while Shared Drive investigations usually require attention to membership, inherited permissions, and group-based access. A file in a Shared Drive may not be “public,” yet it can still be overexposed if the drive membership is too broad or if external collaborators are allowed. In both cases, security teams should verify whether the file was labeled, classified, or stored in a location that should have restricted handling.

• Correlate file activity with identity events such as new login, elevated privilege, or recent account recovery.
• Check whether the file was shared externally, converted into a link-accessible object, or copied to another workspace.
• Compare access to the data category, such as PII, PCI, credentials, or regulated documents.
• Review whether the action was initiated by a human user, service account, or automated workflow.
• Preserve the sequence of events so the investigation shows movement, not just isolated access.

Where automation or delegated access is involved, the investigation should also account for non-human identities, especially when scripts, connectors, or sync tools touch sensitive content. The OWASP Non-Human Identity Top 10 is useful here because many file exposure cases are amplified by overprivileged integrations rather than a single user click. These controls tend to break down when organisations lack consistent file classification, because the investigation then relies on guesswork about which events are actually sensitive.

Common Variations and Edge Cases

Tighter investigation rules often increase analyst workload, requiring organisations to balance coverage against alert fatigue. That tradeoff becomes more visible in large Workspace tenants, M&A environments, and teams that rely heavily on external collaboration. Best practice is evolving, but there is no universal standard for how much file-sharing telemetry is enough without overwhelming responders.

Edge cases usually arise when a file is copied from a protected Shared Drive into a personal My Drive, when a collaborator is added through a group rather than directly, or when a service account exports content into another platform. These cases can hide the real source of exposure because the last event in the log is not the first risky event. Teams should also be careful with read-only access: a view event can still matter if the file contained secrets, source material, or regulated records and the user had no business need.

Another practical issue is that not every sensitive access event is malicious. Some are legitimate review actions by legal, HR, audit, or incident response teams. The operational question is whether the access followed policy, whether it was time-bound, and whether it left the expected trace. That is where role context and privilege context matter as much as the file event itself. When external sharing, automation, and large delegated drive structures overlap, investigation logic becomes less reliable and false positives rise quickly.

Related resources from NHI Mgmt Group

• How should security teams govern access when sensitive data is spread across multiple systems?
• How should security teams govern AI access to sensitive data across hybrid environments?
• How should security teams investigate sensitive file exposure when data is copied across multiple systems?
• How should security teams govern access to sensitive data across IAM and data security tools?