Every shared drive starts organised. What determines whether it stays that way is whether the structure encodes decisions or merely records history.
Organise by access, not by topic
The usual instinct is to arrange folders by subject: Marketing, Finance, Projects, Design. Then someone in marketing needs one file from Finance, an exception gets made, and within a year the structure no longer describes who can see what.
A better first cut is by who should be able to see it:
- Everyone - handbook, templates, brand assets, policies
- Per team - that team’s working files
- Restricted - HR, payroll, contracts, legal
- External - the only place clients and contractors get access
Topic structure lives inside those. The top level answers “who”, the levels below answer “what”.
The payoff is that permissions follow the tree instead of fighting it. A new project folder inherits the right access because of where it sits, rather than because someone remembered to configure it.
Grant to groups, never to individuals
Granting access person by person feels quicker in the moment and creates the problem that is never solved.
When someone leaves, their individual grants are scattered across dozens of folders and nobody knows where. When someone joins, they acquire access by asking repeatedly across their first fortnight, which is a poor introduction and a slow one.
Grant to roles or groups instead. Joining becomes one membership change, leaving becomes one removal, and both are complete rather than approximately complete.
The test: when someone leaves, can you revoke everything in under a minute and be confident? If not, the model is individual grants wearing a group’s name.
Give the least access that works
Read access where reading is enough. The instinct to grant edit rights “in case they need it” is how a folder ends up with thirty editors, no accountability, and a file nobody can explain the last change to.
This matters most for people outside the organisation. A contractor needs the project folder, not the drive. If they need to hand work back, an upload destination is a safer shape than write access to everything - and it is usually more convenient for them too.
Review when things change, not on a calendar
Access reviews sound bureaucratic and get skipped. In practice the useful trigger is not a date, it is an event.
Someone leaves. Remove them the same day. Check individual grants and API credentials as well as group membership - the credential a departing engineer created two years ago will not appear in any membership list.
Someone changes role. Remove the old access rather than only adding the new. Accumulated permissions are how people quietly end up able to see everything after four years and three teams, and it is never noticed until it matters.
A project ends. External access should end with it. The reliable way to arrange that is to have decided at the start - expiry dates on external shares mean the cleanup happens whether or not anyone remembers.
A contractor’s engagement ends. Same as leaving, and more urgent, because nobody in the organisation is tracking them.
A worked structure
For a company of twenty, this shape holds up:
/company everyone, read; ops team, edit
/handbook
/templates
/brand
/teams
/engineering engineering group, edit
/design design group, edit
/sales sales group, edit
/restricted
/hr HR group only
/finance finance group only
/legal legal + directors only
/external
/client-acme project group + Acme contacts
/client-beta project group + Beta contactsThree properties make it survive contact with reality.
A new project folder under /external inherits the external posture rather than
needing someone to remember. Anything under /restricted is obviously restricted
from its path alone, which prevents the “I didn’t realise that was sensitive”
class of mistake. And there is exactly one place to look when a client engagement
ends.
The structure is boring, which is the point. Clever folder hierarchies stop being followed within a quarter.
Watch the credentials, not just the people
Applications and scripts have access too, and they are invisible in a folder view. A sync client on a laptop that has since been replaced. A backup job. An integration configured by someone who has left, still running, still authorised.
Give each its own credential, scoped to what it needs, so one can be revoked without breaking the others - the same principle covered in our guides to SFTP and server backups.
And check what they have actually been doing. A useful audit trail records which credential acted, not just which account it belonged to. That distinction is the difference between “someone downloaded the client list” and “the deprecated reporting integration downloaded the client list”, which lead to very different afternoons.
Storage is shared too
In a team plan, storage is pooled. One person archiving a video project consumes space everyone else was relying on, and the first anyone hears about it is an upload failing.
Worth knowing before it happens. Our sizing guide covers estimating for a group rather than an individual, and the practical answer is usually to keep bulk archives somewhere separate from the working set.
The structure that survives
If you take one thing: the folder tree should make the right permission the default. Any model that depends on people remembering to configure access correctly will fail, not because people are careless, but because the person creating a folder at 5pm on a Friday is not thinking about who leaves the company in eighteen months.
