Learn
Guide
Sharing a Google Drive file and sharing access to your company’s data are two different actions with two different risk profiles, but most small teams treat them as the same click. When a folder is shared in Google Drive, permissions propagate to every file and subfolder inside it. Sharing a single file only grants access to that one item, leaving the parent folder untouched. That distinction sounds small. It isn’t: a client contract stays shared with a personal Gmail address three months after its owner’s last day, or a contractor added “just for one project” ends up with visibility into the entire finance folder.
TL;DR
Google Drive file sharing and folder-level access are governed by different permission rules, and mixing them up is how sensitive data quietly spreads.
Shared drives (formerly Team Drives) separate ownership from access, which solves some problems but introduces new ones if permissions aren’t audited regularly.
Moving a file out of a shared folder strips inherited permissions but keeps any permissions granted directly on that file, a detail that trips up most manual offboarding processes.
A proper employee offboarding checklist has to account for file-level, folder-level and shared-drive-level access separately, not just deactivate the account.
Compliance frameworks like SOC 2 and ISO 27001 expect access controls and audit trails over who can reach what.
About the Author: ShiftControl is an IT operations platform purpose-built for Google Workspace, founded by operators who ran IT at ExpressVPN. That experience, managing access sprawl at speed without a large IT department, shapes how ShiftControl’s team thinks about Google Drive permission risk for small businesses today.
What’s the Actual Difference Between Sharing a File and Sharing Access?
Sharing a file gives someone a key to one room. Sharing access to a folder or shared drive gives them a key that opens every room behind that door, including ones added later. Google’s own Drive Help documentation describes it the same way: folder-level sharing propagates down to every file and subfolder inside it, while file-level sharing is scoped to that document alone.
The practical problem is that most people don’t experience this as two different actions. They experience it as one button labeled “Share.” An employee dragging a sensitive HR file into a shared “Company Docs” folder isn’t thinking about permission inheritance. They’re thinking about tidiness. But if that folder is already shared with the whole company, the file just became visible to everyone in it, silently and instantly.
This is where Google Drive sharing settings deserve more attention than teams usually give them. The default sharing settings on a folder determine the default exposure of everything placed inside it going forward, not just at the moment of creation.
Why Do Small Teams Mix These Up So Often?
Small teams mix these up because nobody owns the decision. In a company with a dedicated IT function, there’s usually a person or policy that decides who gets folder-level access versus file-level access, and that decision gets reviewed periodically. In a 15-to-80-person company running on Google Workspace, that decision is usually made ad hoc by whoever is fastest to hit “Share” when someone asks for a document.
There are a few recurring patterns:
The “just add them to the folder” reflex. It’s faster to share an entire folder than to hunt down the one file someone needs, so folder-level access becomes the default even when file-level access would have been sufficient.
Ownership tied to individuals, not the team. Files created in “My Drive” are owned by the person who created them. If that person leaves the company, ownership questions can complicate access, which is part of why shared drives exist as an alternative.
No review cadence. Access granted for a single project rarely gets revoked when the project ends, because nobody is tasked with checking.
Confusing convenience with control. Broad access feels efficient in the moment. It only reveals its cost later, usually during an audit, an offboarding or an incident.
None of this is a failure of judgment. It’s a failure of process, and process is exactly what breaks down first in companies that haven’t hired for IT yet.
How Do Shared Drives Change the Access Equation?
Shared drives solve the ownership problem but don’t automatically solve the visibility problem. A shared drive is a space owned by the team rather than an individual, so files persist even as people join or leave. That’s a real improvement over “My Drive” sharing, where a departing employee’s files can become an ownership question for whoever inherits their account.
But shared drive permissions still need active management. Shared drives have several membership roles, and the broader ones reach everything inside them. That means shared drive permissions need reviewing with the same discipline as folder permissions, arguably more, because shared drives are built to accumulate content. Moving folders into a shared drive is a good moment to re-evaluate who actually needs access, rather than replicate the existing sprawl into a new container.
Here’s a simple mental model: a shared drive is like a filing cabinet with a single key that opens every drawer. A folder inside “My Drive” is more like a single drawer you can lend out one at a time. Neither is inherently safer. The filing cabinet is more convenient for teams that genuinely need to see everything. The single drawer is safer when only a few people should ever see the contents. The mistake is picking the filing cabinet by default because it’s less friction, without asking which drawers actually need a shared key.
Why Does This Confusion Create Real Security Risk?
Building on the ownership and visibility issues above, the sharper risk shows up at the edges of the employee lifecycle: onboarding, role changes and especially offboarding. Smaller organizations often lack the resources to review Drive permissions on any regular schedule, so the gaps sit open longer.
The specific failure mode looks like this:
An employee is granted folder-level access for a project.
The project ends, but access isn’t revoked.
The employee leaves the company. Their account is deactivated, but files they created or explicitly shared elsewhere may retain those permissions.
Nobody audits what that person could still see, because nobody was assigned to check.
This is precisely the gap that compliance frameworks are built to close. SOC 2, ISO 27001, GDPR and HIPAA each require access controls and audit trails over who can reach what. A Google Workspace security audit is the mechanism that catches the folder someone forgot to lock down eighteen months ago.
What Should an Employee Offboarding Checklist Actually Include?
An offboarding checklist that only deactivates the Google account is incomplete. Deactivation stops login. It does nothing about files that person owns, folders they were added to or third-party apps they authorized with their Google credentials.
A more complete employee offboarding checklist should cover:
Google account deactivation or suspension, not just a password reset.
File ownership transfer for anything the departing employee owned in “My Drive,” since ownership doesn’t automatically pass to a manager.
Shared drive membership removal, checked directly, not assumed to happen automatically.
Third-party app access revocation, including any SaaS tool the employee connected via Google sign-in, which is often invisible unless someone runs a shadow IT discovery tool.
Review of file-level shares the employee created, since those can persist independently of folder permissions even after the person leaves.
Doing this manually across dozens of apps for every departure is the kind of repetitive, error-prone task that automating access was built to remove. This is also the point where the “one platform vs. four tools” problem becomes concrete. Provisioning and access, SaaS spend management, app-permission visibility and incident response are four separate jobs. Most small companies handle them with four separate tools, or a spreadsheet and good intentions.
How Does ShiftControl Approach This Differently?
ShiftControl is built for operators, not IT teams. Google Drive permission sprawl is exactly the kind of problem that’s invisible until someone goes looking for it. The platform is purpose-built for Google Workspace, connecting through a Google Workspace admin login in as little as 10 minutes. You need admin rights; you do not need IT expertise.
ShiftControl removes access when an employee’s status changes in your HRIS: automatically for apps that support it, as a guided step for the app owner where they don’t. The steps that still need a person are built into the workflow, not left on a checklist you have to remember. Permissions Insights shows which third-party apps hold access to your Google Workspace data, and at what scope, surfacing the risky ones before they become an incident. Combined with SaaS spend management and automated provisioning in the same platform, it replaces the four-tools-and-a-spreadsheet approach with one system.
Security is a basic right, not a luxury. ShiftControl’s pricing is public: $10 per user per month with everything included, and 80% off your first 10 seats for the first year if you’re a startup, and incident response through Blackpanda’s IR-1 service is included in the subscription rather than sold as an add-on.
Frequently Asked Questions
Does sharing a Google Drive folder automatically share every file inside it?
Yes. Permissions on a folder propagate to all files and subfolders within it. Anyone with folder access can see new files added later. Per Google’s own Drive Help documentation, you cannot give someone less access to a file than they have to the folder it sits in. If a file needs tighter permissions, move it out or put it in a limited-access folder of its own.
If I move a file out of a shared folder, does it lose its permissions?
It loses permissions inherited from that folder, but any permissions granted directly on the file itself remain in place. This is a common source of confusion during offboarding.
What’s the difference between “My Drive” sharing and a shared drive?
Files in “My Drive” are owned by an individual, while shared drives are owned by the team, so content persists as people join or leave. Shared drives solve ownership continuity but still require active permission review.
What do compliance frameworks require around access control?
SOC 2, ISO 27001, GDPR and HIPAA each set requirements around access control and audit trails covering who can reach what.
Can a shadow IT discovery tool catch permission risks that Google Drive settings miss?
Yes. Many risky access grants come through third-party apps connected via Google sign-in rather than direct Drive sharing. A shadow IT discovery tool surfaces those connections and their scopes, which Drive’s native sharing settings don’t show on their own.
Do I need a dedicated IT hire to manage Google Drive permissions properly?
No. With the right automation and permissions visibility, small teams can keep access under control without a dedicated IT department.
About ShiftControl
ShiftControl is an IT operations and SaaS management platform purpose-built for Google Workspace, designed to give small and growing businesses the access control, provisioning automation and spend visibility of a full IT department, without the overhead. Founded by former ExpressVPN operators who ran IT there, the platform combines provisioning and access, SaaS spend management, app-permission visibility and incident response into a single system that sets up in as little as 10 minutes. ShiftControl is SOC 2 Type 2 compliant and ISO 27001 certified, and signed the CISA Secure by Design Pledge in 2024, reflecting a belief that basic security shouldn’t cost extra.
If Google Drive permissions at your company haven’t been reviewed since someone last asked “can you just add me to that folder,” it’s worth a closer look now rather than after an incident. ShiftControl is built to close that gap, with automated access changes and permissions visibility in one place.
