This guide sets out which documents live where in your cloud (like Google Drive) and who gets in. The goal: access is intentional, not accidental.
This guide assumes a team large enough to have distinct roles: a People lead, a Finance lead, a Tech lead, and so on. In smaller organisations one person often covers several of these roles simultaneously.
That's fine. The drive structure still applies, but you'll have fewer people to assign. What matters is that sensitive data stays in a restricted drive, even if the same person holds the keys to two or three of them.
Give people access to what they need for their work, no more. This is called the : it limits the damage when things go wrong: a phishing attack, a departing employee, an accidental share.
This can feel at odds with a Holacracy or transparency-first culture, where open information is part of how decisions get made. The tension dissolves when you distinguish what kind of information you're sharing:
- strategy, OKRs, project status, budgets and compensation at policy level, fundraising strategy. This is what distributed decision-making actually needs.
- individual salaries, personnel files, performance reviews, health data, donor records. It's a legal obligation under the AVG/GDPR.
- financial detail, IT security configs, legal documents. Broad access here creates real risk: fraud, security incidents, legal exposure.
Our advice:
- The two principles are compatible, they just apply to different things.
- Grant access at the Drive level, not the folder level. Keep folder-level exceptions minimal — they accumulate quickly and become impossible to audit.
Any docs without sensitive data:
- Operations
- People policies
- Finance (basics)
- Fundraising strategy
- Marketing & PR
- etc.
- Personnel files (contracts, compensation, performance, etc.)
- Recruitment (CV's, interview notes)
- Donor records/names/history
(if there are docs about this, and the fino is not all listed in a CRM)
- Audit reports with findings (especially if they flag internal control weaknesses)
- Authorization matrix
- Incident logs
- Security audits
- NDAs
- Board minutes dealing with complaints, dismissals, or governance conflicts
- Regulatory correspondence (e.g. a letter from the Belastingdienst or an ANBI audit: sensitive until resolved)
- Sensitive correspondence
Someone gets temporary project access and keeps it. A role changes, but Drive permissions don't. the Tech lead typically owns this.
Check for:
- Anyone who has left still showing up with access.
- Role changes not yet reflected in Drive permissions.
- Unexpected sharing: documents shared to personal Gmail accounts, or links set to "anyone with the link."