Cloud document management is a system that adds structure and control to your cloud storage. The storage part is easy: any of the big three (Dropbox, Google Drive, OneDrive) or a privacy-leaning option (Proton Drive, Nextcloud) will hold your files. The management part is what most teams skip, and the part that bites you when an auditor asks who had access to that folder in March. This article is the version of the introduction I wish someone had handed me the first time I was asked to clean up a mess of duplicate folders, broken share links, and permissions that nobody could explain.
The reason I care about the privacy and sovereignty angle on a “boring” productivity topic is that the same permissions model that confuses your team is also what regulators and counterparties are looking at. The structural choices you make for “where do we put the quarterly report” are the same structural choices that determine whether a US subpoena can reach your data when it lives on a US-controlled cloud. The two questions look different but they share an answer.
What cloud document management actually means
Cloud document management is the set of rules your team agrees to about where files live, how they are named, who can read and edit them, and what happens when someone leaves. The cloud storage layer (Dropbox, Google Drive, Proton Drive, Nextcloud) is the substrate. The management layer is the policy. Most failures I have seen are not storage failures. They are policy failures that the storage layer surfaces.
A useful working definition: a cloud document management system is the combination of a storage backend, a folder schema (a fixed tree of named folders with a defined purpose), a permissions model (who can see and do what at each level), a naming convention (a fixed format for filenames that encodes the metadata the team needs to find things), and an ownership model (a person or team that owns each folder and is responsible for keeping it clean). Any one of those missing is a hole, and the hole gets bigger as the team grows.
Without that combination, the storage layer becomes a dumping ground. People create folders with their own names. Permissions get granted ad-hoc to “fix it later.” Old files get renamed in place instead of archived. Six months in, the team cannot find anything, and the person who set it up has moved on to a different project.
Why the choice of provider matters more than the choice of folder structure
This is the part that the average “cloud document management” guide skips. The provider you pick is a structural decision that you cannot easily reverse, and the reversal cost is the part that shows up later as a multi-quarter migration. Three categories are worth distinguishing:
- US-controlled hyperscalers (Google Drive, Microsoft OneDrive, Dropbox). The most polished UX, the best collaboration features, the deepest integrations with the rest of the SaaS you are probably already paying for. The catch is the legal regime: the CLOUD Act (a 2018 US law that lets US authorities compel US-based companies to hand over data, even when the data is stored in a non-US data center) means a US court order can reach your data even if it lives in a Dublin or Frankfurt region. GDPR does not change that, because the order comes from a US court, not an EU one.
- EU-controlled providers (Proton Drive is the obvious one, plus a long tail of smaller vendors). The UX is rougher. The integrations are fewer. The legal regime is materially different: a US subpoena does not reach Proton because Proton is not US-controlled. You give up features, you get sovereignty.
- Self-hosted (Nextcloud on your own infrastructure, Seafile, FileCloud). Maximum control, maximum sovereignty, minimum polish. You also become the operator, which means you own the backups, the uptime, the security patches, and the on-call rotation.
For a small team with no regulatory exposure and no contract that says “your data must stay in the EU,” the hyperscaler is the rational pick and the sovereignty question is academic. For a team that handles EU personal data, healthcare records, defense-adjacent documents, or anything that a customer contract ties to a specific jurisdiction, the choice is a real choice, and the folder structure is downstream of it.
The folder schema that scales to about 50 people
A folder schema is the single biggest-impact decision in a cloud document management system. Get it wrong and the team builds a parallel mess on top of the official one. Get it right and the structure carries you for years.
The pattern that has worked for me across three teams of 30-60 people is shallow and wide, not deep and narrow. Top-level folders are functional areas (Sales, Engineering, Finance, People, Customer). Inside each, a fixed substructure:
- Active. Work in flight. Cleared quarterly.
- Archive. Completed work, kept for reference. Cleared yearly.
- Templates. Reusable starting points.
- Inbox. A drop zone for things that need to be filed. Someone owns emptying it weekly.
Depth is the trap. The moment you have six levels of nested folders, you have a folder that only one person understands, and that person is leaving in three months. Keep the tree to three levels deep. Use the filename to encode what the depth would have encoded.
The naming convention is the second half of the schema. A format that has aged well is YYYY-MM-DD_topic_owner_status.ext. The date sorts naturally. The topic is human-readable. The owner tells you who to ask. The status (draft, in-review, final, archived) is searchable. I have watched teams waste entire afternoons hunting for final_v2_REAL_final_Johns_copy.docx. The convention is the cure.
The permissions model that does not bite you later
Three rules cover most cases:
- Group-based, not person-based. Permissions are granted to groups (Sales, Engineering, Finance). When someone joins Sales, they inherit Sales access. When they leave Sales but stay at the company, they lose it. Person-by-person grants are how you end up with someone who left 14 months ago still having edit access to the salary planning folder.
- Default deny at the folder level. New folders are private to the owner. Permissions are explicitly granted, not inherited from a permissive parent. The default-deny model is more work at setup and zero work forever. The default-allow model is zero work at setup and a quarterly audit forever.
- External sharing is a separate permission, with expiry. If your provider lets you share a folder with a customer via a link, set the link to expire in 30 days. Set the permission to view-only unless edit is specifically required. Log every external share to a place the security team can read.
A specific gotcha I have hit twice: shared links with “anyone in the company” or “anyone with the link” scopes. They feel convenient in the moment. They become a security incident in the audit. The default should be “specific named people,” and the only time you loosen it is when the alternative is more annoying than the audit risk.
What to do before you migrate
The most common failure mode is the big-bang migration. A team decides to move from a folder of “Marketing” (a single shared folder with 8,000 files in it) to a proper schema. They schedule a weekend. They move everything. On Monday, 30 people cannot find anything. The migration plan needs three properties:
- Run the new schema in parallel for at least two weeks. People add new files to the new structure while the old one stays read-only. You learn the gaps in the new schema before you commit to it.
- Move files in ownership-aware batches. When you move the Engineering folder, Engineering knows whether the contents are still relevant. The “Marketing” move is the one nobody understands, so it goes last, and the move is a triage, not a copy.
- Keep the old structure read-only for at least 90 days. People will have references in emails, in chat, in their head. The old folder is the fallback when the new one fails to surface what they need.
I have also watched teams do the reverse: a phased migration that drags on for nine months, with two systems running in parallel, and half the team permanently in the old one. The right cadence is two weeks of parallel, then a hard cutover, then 90 days of read-only fallback. Anything else breeds a permanent two-system mess.
Trade-offs
The new system is not free in time. Initial setup is a real project: drafting the folder schema, getting sign-off from each functional lead, setting up the groups, configuring the default-deny permissions, writing the naming convention, and onboarding the team on it. In my experience, that is a 2-4 week project for a 30-50 person team, and a 1-2 week project for a 10-15 person team, with most of the time spent in meetings rather than configuration. The configuration itself is fast. The conversations are slow.
Migration is the second cost. The 8,000-file “Marketing” folder is a real migration. A team that has been on the wrong system for 18 months will spend 4-6 weeks cleaning it up, with one person at least half-time on the work. Some teams decide the cost is not worth it and live with the mess. That is a real choice, and it is sometimes the right one.
The third trade-off is the sovereignty-versus-features question, and there is no clean answer. Proton Drive does not have the collaboration features of Google Docs. Nextcloud does not have the polish of Dropbox. The team that picks sovereignty is paying for that choice in lost productivity on collaboration features, and the team that picks hyperscalers is paying for it in legal exposure. The right pick depends on the regulatory regime and the contract obligations, and pretending the trade-off does not exist is the worst move.
If your team is under 10 people, all in one jurisdiction, with no regulatory exposure, the right answer is probably Google Drive or OneDrive with a clean folder schema and a naming convention. If your team handles EU personal data at scale, or works with defense, healthcare, or critical infrastructure, the sovereignty question is the question, and the folder schema is downstream of it. Everyone else is somewhere on the line between those two poles, and the trade-off is real.
If I could send a message back to the version of me that first opened Google Drive for a team of 30, I would say three things.
- Pick the provider first, then design the schema. The schema you would build for Proton Drive is not the schema you would build for Google Drive, and redesigning the schema because the provider changed is the cost you do not want to pay.
- Default deny on permissions, default to groups, default to no external sharing. Every one of those defaults you relax is a thing you will have to remember to tighten later.
- The naming convention is worth the awkwardness.
2026-06-15_q3-forecast_Finance_draft.xlsxis uglier thanQ3 forecast.xlsx. It is also findable in five years, by someone who was not on the team when the file was created.