Access control
A shared drive permission review that finishes in one sitting
A scoped method for reviewing shared drive permissions folder by folder, removing stale groups and orphaned entries without breaking the work people depend on.
Start with repeatable IT work that has a clear owner, clear access limits, and a review cadence. Keep risky technical decisions with the manager or provider who owns the system.
Delegation playbook
On this pageJump to section
A shared drive permission review usually stalls because the drive is enormous and nobody wants to break a folder that finance uses every month. The result is a review that begins with good intentions and ends with a spreadsheet nobody finishes. A scoped review works on one drive at a time, exports the real access list, and resolves the entries that carry the most risk first. It finishes because it has a clear stopping point.
Scope one drive at a time
Choose a single drive or site with a known owner and a manageable number of folders. A department drive is usually a better first target than the company-wide file share. Write down the boundary of the review, including the folders that are out of scope and why. A clear boundary keeps the work finite and makes the next review easier to plan.
Ask the drive owner to name the people who depend on it and the groups that should have access. Confirm the business process the drive supports so the reviewer can tell a stale entry from a working one. Agree on a maintenance window when permissions can change without interrupting a deadline. Put the owner's name and the window at the top of the review record.
Export the current permissions
Export permissions from the platform rather than reading them from screenshots. Include the item path, the principal name, the principal type, the permission level, and whether the entry is inherited. Capture the export date and the tool used so the evidence can be reproduced. An export that cannot be reproduced is hard to defend later.
Reconcile the export count with the platform's own report before analysing it. Large drives often contain broken inheritance and duplicate group nesting that inflate the row count. Normalise the principal names so a group and its mail-enabled alias are not treated as different entries. Record any folder the export could not read, because an unreadable folder is itself a finding.
Identify stale groups and orphaned entries
List every group with access and check whether it still has an owner and a purpose. A group created for a project that ended two years ago is a standing permission with nobody accountable for it. Look for entries for departed staff, vendor accounts, and generic logins that cannot be traced to a person. Mark each one as keep, remove, or investigate.
Check nested groups, because a user can inherit access through a path that never appears on the folder's direct list. Expand the membership of each group far enough to see who actually gains access. Record the access path for any entry that is not direct. The path is what makes a removal safe or dangerous.
Rank by data sensitivity
Sort the findings by the sensitivity of the data the folder holds, not by the size of the group. A small group with access to payroll files matters more than a large group with access to public templates. Use the company's existing classification if one exists, and record the classification source. Where no classification exists, ask the owner to make a judgement and write it down.
Prioritise folders that contain personal data, financial records, contracts, or credentials. Then review folders used by external parties, because a vendor account may have access the business never intended. Leave low-risk folders in a later batch rather than trying to fix everything at once. The review should produce a short, defensible list of changes.
Decide and document each change
Record the decision for every finding, the reason, and the date. A removal without a reason is hard to reverse when a user reports a missing file. A keep decision should name the owner who confirmed the access is still needed. The record becomes the audit trail for the next review and the explanation for any access change.
Where possible, remove access by deleting the group membership rather than the group itself. This preserves the group's history and makes restoration simple if the decision was wrong. For direct entries, remove the permission and note the folder path. Send the owner a short summary of the changes rather than a raw spreadsheet.
Verify access after the change
Test the result with a user who should retain access and a user who should have lost it. Ask them to open a representative file in the affected folder and report what they see. A permission change that breaks a shared workflow will be discovered quickly, and it is better to discover it during the review window. Record the test result and the tester.
Check the platform's audit log for the changes and confirm they were applied to the intended principals. Look for accidental changes to inheritance that affect child folders. If a change had to be reversed, record the reason and the final state. The review is complete only when the intended state matches the tested state.
Schedule the next review
Set the next review date with the drive owner before closing the current one. A quarterly cadence is often enough for stable department drives, while a shared project drive may need a review at each project close. Record the owner, the scope, and the date in the same register. The next reviewer should not have to reconstruct the method.
Track the number of entries removed and the number of open investigations as a simple trend. A review that keeps finding the same stale group points to a joiner and leaver process problem. Feed that observation back to the team that manages accounts. The permission review is a control, not a one-off cleanup.
Sources and next step
Use the CISA Cross-Sector Cybersecurity Performance Goals and the NIST Cybersecurity Framework 2.0 as primary references for the asset, access, certificate, and vendor practices discussed in this guide. The NIST media sanitization guidance supports the disposal steps described here. Apply your own policies, contracts, and system documentation to the workflow. Compare this guide with the certificate renewal calendar and the shared drive permission review before changing a live process.
Keep decisions, approvals, and evidence in systems the business already controls. If the coordination is recurring and your technical owner can define the boundaries, review the IT virtual assistant service areas and contact ITVirtualAssistant to discuss a limited pilot.
Operating brief
What this guide should help you decide
Routine intake, status updates, records, screenshots, and documentation upkeep.
Approvals, risky system changes, security decisions, and final technical judgment.
How to use this guide
Use this page to decide what an IT virtual assistant should handle first. If the task is recurring, documented, and easy to review, it is usually a better first delegation candidate than work that requires live technical judgment.
Treat the article as an operating brief, not just a topic overview. The goal is to turn loose IT work into a named workflow with inputs, outputs, permissions, review cadence, and a handoff rule that protects the business while reducing manager load.
Workflow
Recommended operating workflow
Define the request
Write what a shared drive permission review that finishes in one sitting means in your company, where requests enter, and what finished work looks like.
Limit the access
Give the assistant only the tool permissions needed for intake, records, status updates, or documentation.
Run a pilot
Use a two-week sample period so the manager can review accuracy before expanding the workflow.
Review patterns
Summarize repeat issues, blocked requests, and escalation volume so the technical owner can improve the process.
Decision rules
| Question | VA fit signal | Escalate when |
|---|---|---|
| Is the work repeatable? | The same request appears weekly and can be described in steps. | The request changes business policy or system design. |
| Can quality be reviewed? | The manager can inspect the output without redoing the work. | Only a senior technical person can judge correctness. |
| Is access contained? | The assistant can work with read-only or role-limited access. | Admin rights, customer data, or security settings are involved. |
Delegation checklist
- Write the intake source, expected output, and manager review cadence.
- Confirm the assistant has only the permissions needed for the workflow.
- List the events that require escalation before work continues.
- Track examples for two weeks before changing the workflow.
- Save examples of good and bad outputs so the assistant has concrete references.
- Review the workflow monthly and remove permissions that are no longer needed.
Example first-week agenda
Day one should cover the workflow owner, tools, allowed actions, forbidden actions, and escalation language. By the end of week one, the assistant should have produced a small sample of completed work, a list of unclear requests, and a manager-reviewed improvement note.
What to review before delegating
Confirm the owner, access level, review cadence, and escalation path before assigning any recurring IT workflow to a remote assistant.
What should an IT virtual assistant handle first?
Start with repeatable, reviewable work such as ticket summaries, account records, documentation updates, and checklist follow up.
Get free IT support review