Data Protection for Google Drive

Google Drive is built for sharing and is well-loved because of it. But that same loved feature creates a mess of sensitive files with almost zero visibility, and can become hated by security teams. We heard several common themes from customers:

"What's even in our Drive?" "Who has access to what?" "Is anything being shared that shouldn't be?"

Security teams couldn't tell the difference between normal collaboration and actual security risks. When actual security risks were found, it took a lot of manual labor to figure out the scale of the problem and fix it.

Identifying Files at Risk

Sensitive data is everywhere. Financial reports with quarterly projections. Customer PII. Health records. These weren't theoretical - they were actual types of files being created and shared regularly that security teams need to protect.

There is also a permissions problem for company Google Drives. When a vendor contract ends, or someone internally gets moved to a new team, it can take time to determine what their access was and restrict it to the right level. Over time, this creates layers of unnecessary access that no one actively manages.

The third concern was perhaps the most worrying: external sharing created major blind spots. Links that anyone with the URL could access. Public editing rights to private documents.

Project Constraints

Building a solution like this came with some serious constraints:

For starters, Google Drive's permission model is wonderfully complicated. There are different inheritance patterns depending on where and how you share. Multiple APIs for different types of drives. It might be simpler than the other big cloud storage providers, but it's still a complex system to navigate.

There was also a bit of tension between enforcing new security policies and productivity. We had to beef up security without killing the main selling point of Google Drive - collaboration.

And of course, timing was tight. This was a 0-to-1 project with few competitors in the market. Our customers were already asking for the product before we had even started building.

Discovery & Problem Definition

We used a jobs-to-be-done approach to nail down what security teams actually needed to accomplish:

1. Find sensitive data wherever it exists
2. Understand who has access (especially people outside the company)
3. Fix permission problems without breaking legitimate collaboration
4. Automate the process because nobody has time for manual reviews

We prioritized these based on two factors: customer impact (what would make the biggest difference) and technical feasibility (what was actually possible to build).

Search and Discovery Interface

We kicked things off with a search-first interface to help security teams quickly find their riskiest files.

It actually sort of all began with a hack week project while our team was all in-person together. A small cross-functional team (where I contributed both design and front-end code and our project won best overall!) built a typeahead search system for Google Drive files we already were syncing. This proof of concept, created in just a few days, became the foundation for our production search experience.

The experience we were going for was to allow users to have all the power of Google's API and our analysis of their files, but without the need for them to learn a new query language or syntax on their own.

The typeahead component would let the user see what types of data they could search on and help them to build their query. Each 'operator' was explained inline so users had a clear sense of what they were crafting. Because this was now searching using a real query language vs plain text in the past, we also could check their query and give them status on whether it was valid or not in real-time.

Remediation Workflows

With our discovery interface in place, we moved on to building workflows that would actually let people fix the problems they found.

We were still in the early days and on a tight timeline to launch a 'real' security tool that could take action to protect data. We took an incremental step to add bulk remediation options right in the search results to keep friction low and build on what we had already created.

Power users needed bulk actions, but with safety rails. We designed interfaces for applying actions across multiple files or permissions with appropriate checks and balances. Security tools often feel scary because you can affect people's jobs when you use them. We tackled this by adding visual cues and confirmation patterns to help people understand exactly what would happen when they clicked buttons and reiterating what actually took place when the action is completed.

For organizations with many external partners, we built domain-level controls that enabled selective access management. Keep sharing with approved partners, automatically restrict others - all without micromanaging individual files or people.

It was important that the users could feel confident enforcing security policies without worrying about affecting other people or their workflows.

Automation Framework

Manual fixes are fine for one-off issues, but security teams need automation to stay sane. We used our Data Protection for Google Drive product as our first major test for a new automation framework called Detections.

We created a flow that let you save any search into an automated security "policy" that could take action on files as they were being edited.

We wanted to launch with a set of simple actions that a file detection could take on files that violated a policy. We started with notifications to the end user or Google Drive Admin and revoking permissions (access).

Not everyone is a security engineer, so we created a visual workflow builder that made policies accessible to everyone. A simple way to sequence actions like notifications and access revocation, without requiring coding skills or setting up other tools.

We created customizable notification templates and new underlying email templates powering them. The notifications allowed the security team to alert the right people and help them understand what was wrong and how to fix it, rather than leaving them confused when permissions suddenly changed.

In keeping with our design philosophy, we also wanted to make sure that the end users weren't necessarily interrupted by minor policy violations. We built in grace periods (delays) that respected human workflows. Options to give users time to fix issues themselves before automated enforcement kicked in.

Outcomes and Lessons

When Google Drive Protection shipped, it quickly delivered on its core promises.

Three design approaches made the difference: Our search-first foundation created flexibility throughout the product. We built incremental iterations focused on delivering real value. And we respected human workflows for both the security teams and their end users.

Security teams could finally answer critical questions like "Where is our sensitive data?" and "Who has access to it?" in minutes rather than weeks. Organizations could automatically spot and fix improper sharing during routine moments like off-boarding employees or renewing vendor contracts before breaches could happen. Material Security now had a new product that targeted a new market that became part of the foundation for a whole new era of Detection products to help security admins protect data.

Screenshots