> For the complete documentation index, see [llms.txt](https://docs.docontrol.io/docontrol-user-guide/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.docontrol.io/docontrol-user-guide/best-practices/google-drive-inherited-permissions.md).
# Google Drive inherited permissions
This page details the new My Drive & Shared Drive Assessment and Remediation Enhancements made to the DoControl platform.
Inherited permissions are built into the folder structure of Google shared drives.
Permissions for a shared folder propagate downward, with all child assets and folders inheriting permissions from the parent. Whenever permissions or the hierarchy is changed, the propagation occurs recursively through all nested folders.
**Google has recently updated Drive’s sharing model so that My Drive now follows the same inherited-access logic as Shared Drives.**
In practice, access granted on a parent folder is inherited by the files and folders inside it, and you can no longer remove or reduce a user’s access only on a specific child file if that access comes from the parent. When that happens, Google directs users to manage the permission on the parent folder instead. See Google’s file and folder sharing policy [here](https://support.google.com/drive/answer/7166529?sjid=7870076433464715682-EU).
DoControl fully supports this Google My Drive permission model change.
## My Drive & Shared Drive Assessment and Remediation Enhancements
DoControl has released a set of significant enhancements to the MyDrive and Shared Drive assessment and remediation workflows. These updates were prompted by changes to how Google handles permission inheritance in MyDrive — where files and folders can inherit permissions from parent folders up the directory hierarchy.
The enhancements address three core areas:
* **Visibility** — making inherited vs. direct permissions clearly distinguishable in the UI
* **Assessment accuracy** — filtering out assets that cannot be remediated before they enter the workflow
* **Remediation robustness** — enabling the system to automatically climb folder hierarchies and remediate permissions at the correct source
* **Owner change** — a ‘Change Owner’ workaround is available for specific scenarios
* **Fast inventory syncs** — speed improvements
#### 1. Permission Visibility Enhancements
**1.1 Inherited vs. Direct Permission Indicators**
Users can now distinguish between permissions that were directly granted on an asset and those that were inherited from a parent folder.
How to use:
* Navigate to any file or folder in the DoControl inventory.
* Hover over the sharing status (internal or external) listed on the asset.
* A tooltip will display the collaborator's role.
* If the permission is inherited, a specific symbol will appear alongside the role label, indicating that the permission originates from a parent folder rather than being set directly on the asset. You can also see any external/internal members added from the inventory page.
* Previously, you only had an indication of whether the asset was shared internally or externally, without the option to hover over the sharing status and see the actual members. Before this, you had to open the asset page to view the members.
**Example Scenario**
A file nested inside Folder A, which is nested inside Folder B, may show an external editor as a collaborator. If that editor's access was granted at the Folder B level, the permission on the file is inherited. The new indicator makes this chain of inheritance visible without requiring the user to manually trace parent folders.
#### 2. Assessment Report Enhancements
**2.1 Two New Columns in Downloadable Assessment Reports**
The assessment report export now includes two additional columns:
| Column | Description |
| ------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Role | The collaborator's role on the asset (e.g., Editor, Viewer, Commenter). Previously absent from the report. |
| Send to Remediation | Indicates whether the asset is eligible or valid to be included in a remediation workflow. Assets expected to fail remediation are marked as invalid and excluded automatically. |
**2.2 Invalid Asset Classification**
Assets that are expected to fail remediation — for example, files whose inherited permission source cannot be reached — are now classified as invalid before the workflow begins. This prevents these assets from appearing as errors during execution and keeps remediation runs clean and actionable.
In other words, if the checkbox “Inherited collaborators from parent folder” is not checked off, those will not be sent to remediation. See figure below.
What triggers invalid classification:
* The asset's permission is fully inherited and the source parent folder is outside the organization's reach (e.g., owned by an external user).
* No resolvable path exists up the hierarchy to a folder with a direct, remediable permission.
**2.3 Remediation Scope View**
When reviewing a remediation workflow, a new view displays the full scope of the assessment including the checkbox selections configured when the assessment was created. This provides transparency into what was and was not included.
***
#### 3. Remediation Workflow Enhancements
**3.1 Inherited Permission Remediation (New Checkbox)**
A new "Remediate Inherited Permissions" checkbox is available in the remediation workflow configuration.
**Behavior when enabled:**
* When a target asset has an inherited permission, the system automatically traverses the folder hierarchy upward to locate the source parent folder where the direct permission was granted.
* The remediation is applied at the source parent, not at the child asset, which is the correct and only effective location.
* The system orders all tasks top-down — remediating parent folders before child assets — so that inherited instances are cleared in the correct sequence.
The order is very critical when one of the folders in the chain has direct+inherited permissions. Why? Because: first, you have to make the inherited permission disappear, and then once you are left with only the direct permission — you will be able to remediate it as well.
Why this matters: Previously, attempting to remediate an inherited permission directly on a child asset would result in an error because Google does not allow removal of inherited permissions at the child level. The system now handles this automatically.
But, if the entire chain only has inherited permissions, it’s enough to send only the parent source folder (who has that permission as 'direct') to remediation.
**Behavior when disabled:**
* Only assets with direct permissions are included in scope.
* Inherited-permission assets are skipped or classified as invalid.
**3.2 Automatic Hierarchy Traversal**
When the system detects that a permission is inherited, it:
1. Identifies the permission is not direct on the target asset.
2. Climbs the parent folder hierarchy to locate the folder where the direct permission exists.
3. Adds the parent folder(s) to the remediation workflow.
4. Executes remediation starting from the top of the hierarchy and working down.
This ensures all inherited instances across child files and folders are cleared as a result of the single top-level remediation action.
**3.3 Error Prevention**
* Assets that cannot be reached via hierarchy traversal are blocked from the workflow entirely.
* Users will no longer encounter unexpected red-flag errors for assets that were structurally impossible to remediate.
***
#### 4. Owner Change: Breaking the Inheritance Chain
**4.1 When to Use This Feature**
In some cases, the parent folder from which a permission is inherited may be unreachable — for example, if it's owned by someone outside the organization and DoControl does not have access to remediate at that level.
In these scenarios, a Change Owner workaround is available.
**4.2 How It Works**
1. Navigate to the target file in the DoControl inventory.
2. Use the Change Owner action to reassign ownership to another user within the organization.
3. When ownership is transferred, Google automatically moves the file to the new owner's root drive.
4. The file is disconnected from its previous parent folder hierarchy.
5. With the inheritance chain broken, inherited permissions that previously could not be reached are eliminated.
Important: This action changes the file's ownership and its position in the folder hierarchy. Communicate with relevant stakeholders before using this on shared or sensitive files.
**4.3 Use Case Example**
An external editor has access to a file via inheritance from a parent folder owned by a former employee's personal Google account. DoControl cannot reach that parent folder to remove the direct permission. By changing the file's owner to an internal user, the file moves to that user's root drive, severing the old hierarchy and removing the inherited external access.
***
#### 5. Sync Speed Improvements
| Before | After |
| ------------------------------------------------------ | ------------------------------------------------------ |
| Changes could take up to a week to appear in inventory | Changes are reflected within hours to one business day |
***
#### 6. Summary of Changes
| Enhancement | What Changed |
| ----------------------------------------------- | ------------------------------------------------------------------------------------------------- |
| Inherited permission indicators | Hover over a collaborator to see if their permission is inherited, marked with a dedicated symbol |
| Collaborators panel indicators | Inherited role and external type indicators now visible in the panel |
| Assessment report: Role column | Collaborator role now included in downloadable reports |
| Assessment report: Valid for Remediation column | Assets blocked from remediation are flagged in the report |
| Invalid asset classification | Assets expected to fail are blocked before workflow execution |
| Remediation scope view | Displays assessment configuration and selected checkboxes |
| Remediate Inherited Permissions checkbox | Enables top-down hierarchy traversal and remediation at the source |
| Automatic hierarchy traversal | System climbs folder hierarchy to find and remediate the source permission |
| Change Owner workaround | Breaks inheritance chain for unreachable parent folders |
| Sync speed | Changes reflected in inventory within hours vs. up to one week |
***
For additional support, contact your DoControl Customer Success representative.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.docontrol.io/docontrol-user-guide/best-practices/google-drive-inherited-permissions.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
**Example Scenario**
A file nested inside Folder A, which is nested inside Folder B, may show an external editor as a collaborator. If that editor's access was granted at the Folder B level, the permission on the file is inherited. The new indicator makes this chain of inheritance visible without requiring the user to manually trace parent folders.
#### 2. Assessment Report Enhancements
**2.1 Two New Columns in Downloadable Assessment Reports**
The assessment report export now includes two additional columns:
| Column | Description |
| ------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Role | The collaborator's role on the asset (e.g., Editor, Viewer, Commenter). Previously absent from the report. |
| Send to Remediation | Indicates whether the asset is eligible or valid to be included in a remediation workflow. Assets expected to fail remediation are marked as invalid and excluded automatically. |
**2.2 Invalid Asset Classification**
Assets that are expected to fail remediation — for example, files whose inherited permission source cannot be reached — are now classified as invalid before the workflow begins. This prevents these assets from appearing as errors during execution and keeps remediation runs clean and actionable.
In other words, if the checkbox “Inherited collaborators from parent folder” is not checked off, those will not be sent to remediation. See figure below.
What triggers invalid classification:
* The asset's permission is fully inherited and the source parent folder is outside the organization's reach (e.g., owned by an external user).
* No resolvable path exists up the hierarchy to a folder with a direct, remediable permission.
**2.3 Remediation Scope View**
When reviewing a remediation workflow, a new view displays the full scope of the assessment including the checkbox selections configured when the assessment was created. This provides transparency into what was and was not included.
***
#### 3. Remediation Workflow Enhancements
**3.1 Inherited Permission Remediation (New Checkbox)**
A new "Remediate Inherited Permissions" checkbox is available in the remediation workflow configuration.
**Behavior when enabled:**
* When a target asset has an inherited permission, the system automatically traverses the folder hierarchy upward to locate the source parent folder where the direct permission was granted.
* The remediation is applied at the source parent, not at the child asset, which is the correct and only effective location.
* The system orders all tasks top-down — remediating parent folders before child assets — so that inherited instances are cleared in the correct sequence.
The order is very critical when one of the folders in the chain has direct+inherited permissions. Why? Because: first, you have to make the inherited permission disappear, and then once you are left with only the direct permission — you will be able to remediate it as well.
Why this matters: Previously, attempting to remediate an inherited permission directly on a child asset would result in an error because Google does not allow removal of inherited permissions at the child level. The system now handles this automatically.
But, if the entire chain only has inherited permissions, it’s enough to send only the parent source folder (who has that permission as 'direct') to remediation.
**Behavior when disabled:**
* Only assets with direct permissions are included in scope.
* Inherited-permission assets are skipped or classified as invalid.
**3.2 Automatic Hierarchy Traversal**
When the system detects that a permission is inherited, it:
1. Identifies the permission is not direct on the target asset.
2. Climbs the parent folder hierarchy to locate the folder where the direct permission exists.
3. Adds the parent folder(s) to the remediation workflow.
4. Executes remediation starting from the top of the hierarchy and working down.
This ensures all inherited instances across child files and folders are cleared as a result of the single top-level remediation action.
**3.3 Error Prevention**
* Assets that cannot be reached via hierarchy traversal are blocked from the workflow entirely.
* Users will no longer encounter unexpected red-flag errors for assets that were structurally impossible to remediate.
***
#### 4. Owner Change: Breaking the Inheritance Chain
**4.1 When to Use This Feature**
In some cases, the parent folder from which a permission is inherited may be unreachable — for example, if it's owned by someone outside the organization and DoControl does not have access to remediate at that level.
In these scenarios, a Change Owner workaround is available.
**4.2 How It Works**
1. Navigate to the target file in the DoControl inventory.
2. Use the Change Owner action to reassign ownership to another user within the organization.
3. When ownership is transferred, Google automatically moves the file to the new owner's root drive.
4. The file is disconnected from its previous parent folder hierarchy.
5. With the inheritance chain broken, inherited permissions that previously could not be reached are eliminated.
Important: This action changes the file's ownership and its position in the folder hierarchy. Communicate with relevant stakeholders before using this on shared or sensitive files.
**4.3 Use Case Example**
An external editor has access to a file via inheritance from a parent folder owned by a former employee's personal Google account. DoControl cannot reach that parent folder to remove the direct permission. By changing the file's owner to an internal user, the file moves to that user's root drive, severing the old hierarchy and removing the inherited external access.
***
#### 5. Sync Speed Improvements
| Before | After |
| ------------------------------------------------------ | ------------------------------------------------------ |
| Changes could take up to a week to appear in inventory | Changes are reflected within hours to one business day |
***
#### 6. Summary of Changes
| Enhancement | What Changed |
| ----------------------------------------------- | ------------------------------------------------------------------------------------------------- |
| Inherited permission indicators | Hover over a collaborator to see if their permission is inherited, marked with a dedicated symbol |
| Collaborators panel indicators | Inherited role and external type indicators now visible in the panel |
| Assessment report: Role column | Collaborator role now included in downloadable reports |
| Assessment report: Valid for Remediation column | Assets blocked from remediation are flagged in the report |
| Invalid asset classification | Assets expected to fail are blocked before workflow execution |
| Remediation scope view | Displays assessment configuration and selected checkboxes |
| Remediate Inherited Permissions checkbox | Enables top-down hierarchy traversal and remediation at the source |
| Automatic hierarchy traversal | System climbs folder hierarchy to find and remediate the source permission |
| Change Owner workaround | Breaks inheritance chain for unreachable parent folders |
| Sync speed | Changes reflected in inventory within hours vs. up to one week |
***
For additional support, contact your DoControl Customer Success representative.