Audit Google Drive Sharing Permissions for Separate Client Folders

A Google Drive file can look private while access is still available through a parent folder, a group, a broad “general access” setting, or an old link. A useful audit must identify how access is granted—not just read the list of names shown on one file.

This guide provides a bounded review process for freelancers and small teams that keep separate client folders. It starts with fictional test content so the reviewer can understand the interface without opening sensitive client files unnecessarily.

Method note: This is a documentation-based workflow, checked August 12, 2026. It does not claim that Safer Digital Desk tested every Google Account, Workspace edition, administrator setting, or regional interface. Available controls can differ between personal Drive, My Drive in a managed account, and shared drives.

Define What the Audit Must Prove

“Check sharing” is too vague. Choose a concrete outcome for one project folder:

  • Only named client contacts can open the final-deliverables folder.
  • A review link no longer works after the review period.
  • A contractor can edit working files but cannot open another client's folder.
  • The business—not one departing person—controls ownership and administration.

Write the expected people, role, and end date before opening permissions. The expected state becomes the comparison point; otherwise every unfamiliar entry turns into guesswork.

Start With a Fictional Test Folder

Create a folder using fictional files such as Project-Brief-Test.txt and Review-Image-Test.png. Do not copy a real client folder merely to test sharing. If authorized test accounts are available, use them to represent an owner, an editor, and an external viewer.

A safe test can answer:

  • Where Google shows people, groups, and general access
  • Whether a child file reflects access granted at the folder level
  • What an external viewer sees
  • How access changes after a person or link is removed

Do not publish screenshots containing real email addresses, file names, client identities, link tokens, or administrator details. Recreate the example with fictional accounts where practical.

Use an Access-Route Worksheet

Item Expected audience Access route observed Role End date or trigger Action and verifier
Client A working folder Internal project team Named people or managed group Editor Contractor departure Project owner reviews membership
Client A review folder Two named client contacts Specific people Viewer/commenter as required Review accepted Owner removes access; second person verifies
Public portfolio copy Anyone only after written approval General access Viewer Approval withdrawn or asset replaced Owner records approval and next review

Never paste the share URL into the worksheet. The URL itself may provide access.

Step 1: Identify the Owner and Storage Context

Record whether the item is in a personal Google Account, My Drive in a managed Workspace account, or a shared drive. Ownership and offboarding behavior differ. For example, shared-drive content belongs to the organization rather than an individual member, while My Drive files may require ownership transfer under supported conditions.

Google documents the controls for sharing files from Google Drive and separately explains how a user can transfer ownership of a file. Review the restrictions shown for the exact account type before changing ownership.

Step 2: Review Every Access Route

Open the sharing controls for the selected folder and record access through:

  • Individual people
  • Google Groups or other managed groups
  • General access, including anyone-with-the-link or organization-wide access where available
  • Parent folders or shared-drive membership
  • Ownership and manager roles

A familiar group name is not enough. If authorized, verify its current membership through the system that manages the group. Removing a person directly from one file will not help if the same access arrives through a group or parent folder.

Failure case: a child file inherits broader access

A reviewer may narrow the visible file entry while the file remains inside a folder shared more broadly. When the interface indicates inherited access, trace it to the parent and decide whether the folder structure—not the file—is the correct place to change permissions.

Step 3: Match the Role to the Task

Do not give edit access merely because it avoids a follow-up message. Decide whether the person needs to view, comment, edit, organize, or manage. Also review whether viewers can download, copy, or print when those controls are available. These restrictions reduce some casual actions but do not guarantee that an authorized viewer cannot capture information another way.

Record why the role is needed and the event that should end it. Project completion, contractor departure, delivery acceptance, and publication approval are stronger triggers than “review someday.”

Step 4: Test From the Recipient Side

Use a fictional test item and an authorized test account. Check the link in a separate browser profile that is not signed in as the owner. Verify:

  • Whether sign-in is required
  • Which account can open the item
  • Which role is actually available
  • Whether unrelated parent or sibling items are visible
  • What happens after access is removed

Do not use private/incognito mode as proof that no one can access the file; the result depends on the link and account state. Record the exact test conditions.

Step 5: Review External Sharing at the Organization Level

Google Workspace administrators may control external sharing more broadly than a file owner can. Google's current administrator documentation explains how to manage external sharing for an organization. Organization-wide restrictions can limit user choices, but an available option in one Workspace does not establish that it exists in another edition or organizational unit.

For managed environments, record:

  • Whether external sharing is allowed
  • Whether allowlisted domains or organizational units affect the user
  • Who may create shared drives or manage members
  • Who reviews exceptions
  • Which logs or reports are available

Google also documents Drive log events for supported administrator environments. Logs can support review, but availability, retention, fields, and interpretation depend on the account and edition.

Step 6: Remove Access in a Controlled Order

  1. Confirm the approved expected audience.
  2. Transfer required ownership or business records before deletion.
  3. Remove obsolete direct people and groups at the correct parent level.
  4. Restrict or remove broad general access that is no longer required.
  5. Retest with the fictional recipient account or equivalent safe method.
  6. Record exceptions, owner, and due date.

Do not delete a production file as a permission test. Do not remove the only owner or manager without a verified continuity plan.

Permission cleanup should follow the intended transfer decision, not replace it. First classify the client file and choose the sharing method. If access belongs to a departing person, use the offboarding access map. For Microsoft-hosted work, use the separate OneDrive and SharePoint audit workflow because its access routes differ.

Worked Example: Two Client Folders, One Contractor Group

A fictional studio maintains separate Client Red and Client Blue folders. A contractor should edit Client Red only, but the studio added the contractor to an “External Creators” group that has access to the parent folder containing both clients.

The audit starts with the child file and traces the permission to the parent group. Removing the contractor directly from one Client Blue file would not fix the route. The bounded correction is to redesign group or folder membership so each client receives a distinct access boundary, then verify with fictional test files. This is a constructed workflow example, not a real client incident.

When a Drive Permission Audit Is Not Enough

Seek qualified help when files contain regulated data, a breach or improper disclosure may have occurred, logs or evidence must be preserved, organization-wide policies conflict, or the team cannot identify the lawful owner of the content. Permission cleanup should not erase evidence or override retention duties.

A complete audit record identifies the expected audience, every observed access route, the final role, the removal trigger, the change made, and the independent verification result. “Restricted” is useful only when the reviewer can explain what it means for that item and account.

Comments

Post a Comment

Popular posts from this blog

A Digital Security Baseline for Freelancers and Small Teams

A freelancer can lose access to work without experiencing a sophisticated cyberattack. A phone replacement can remove an authenticator app, a client folder can inherit the wrong sharing setting, or an old contractor can retain access because nobody recorded which accounts they used. This guide creates a small, reviewable security baseline for people who do not have an IT department. It is not a promise that the controls will prevent every incident. The goal is to identify the few accounts, files, devices, and recovery dependencies that would cause the most disruption if they failed. Method note: This is a documentation-based planning guide, checked August 12, 2026. The worksheet and priority method are original to Safer Digital Desk. The control themes are aligned with the NIST Cybersecurity Framework 2.0 Small Business Quick-Start Guides and CISA's Secure Our World guidance. Digital security baseline map A four-part baseline covering accounts, files, devices, and r...
Read more

Passkeys, Authenticator Apps, and Security Keys: How to Choose

A passkey, an authenticator app code, and a physical security key can all strengthen sign-in, but they solve different workflow and recovery problems. The safest option on paper may be unusable if only one person can recover it, while the most convenient method may depend on a phone number or synchronized account you have not evaluated. This guide compares the methods by phishing resistance, device dependence, sharing and administration, and recovery. It does not declare one universal winner. Method note: This is a documentation-based comparison, checked August 12, 2026. It does not claim that every provider, device, or plan was tested. Confirm the sign-in and recovery options shown in the official settings for your exact account. First Separate Sign-In From Recovery A method can work well for daily sign-in while creating a fragile recovery path. Before choosing it, write down: Who needs access and whether the account is personal, shared, or centrally administered Whic...
Read more

How to Share a Client File: Match the Method to the Data

“Send the file” is not a complete instruction. A public brochure, a client draft, a payroll export, and a folder containing identity documents do not deserve the same delivery method. The useful decision begins with the data, the intended recipient, and what must happen after access is granted. This guide provides a provider-neutral way to choose among an attachment, a named-recipient link, a shared workspace, or a controlled transfer process. It does not claim that one method makes a file completely safe. Method note: This documentation-based framework was reviewed August 12, 2026. The decision card and scenarios are original, constructed examples. They are not client incidents or the results of a production security test. Start With a Five-Question Data Card Before choosing a tool, write one line for each question. Do not put the sensitive data itself in the card. Question Why it changes the method What type of information is present? Public, routine business, c...
Read more