File Sharing With Permission Control: Who Sees What

The phrase "permission control" sounds like a checkbox in a settings menu, and in a lot of software, that's exactly what it is — one checkbox, two options, done. Real file sharing with permission control is more than that: it's a structural decision about how access is granted, inherited, and revoked, and getting it wrong is the most common way small businesses accidentally expose one client's data to another.

Permission control vs. the illusion of it

A lot of tools market "secure sharing" while offering nothing more than a link with an optional password. That's not permission control — it's obscurity with an extra step. Real permission control ties access to an identity: this specific person, or this specific client account, has this specific level of access to this specific resource. You can revoke one person's access without affecting anyone else, and you can prove, via a log, exactly who had access and when.

NIST's access control guidelines describe this as the difference between discretionary controls (anyone with a secret can access something) and identity-based access control (access is tied to who you are, not what you know). Small businesses rarely need the full complexity of an enterprise access-control framework, but the underlying principle — identity over secrets — is worth applying even at five people.

The three tiers that cover most cases

Overcomplicating permission tiers is a common mistake. Most small businesses only need three levels, applied consistently:

1. View-only. The client or contact can see and often download a file, but can't change or comment on it. Right for finished deliverables and reference material.
2. Comment/collaborate. They can leave feedback or annotations without altering the source file. Right for anything in active review.
3. Edit. Full read-write access. Reserve this for genuinely collaborative documents and specific individuals, not entire client organizations by default.

Why inheritance is the feature that actually matters

Setting permissions file by file works fine for the first ten files. It breaks down completely once a client relationship generates hundreds of documents, boards and tasks over a year. The fix is inheritance: permissions are set once at the client or project level, and every new file created underneath automatically gets the right access, with no manual step required.

This is the single biggest practical difference between a general file tool and a system built around client records. In Dropbox alternatives for client files, I cover the structural gap this creates — a folder named after a client isn't the same as a client record with enforced, inherited permissions. When your system understands "this file belongs to this client," permission control becomes something that happens automatically rather than something a person has to remember to do correctly every single time.

Revocation: the step most systems get wrong

Granting access correctly is only half of permission control. Revoking it cleanly is the other half, and it's the part that gets skipped most often — an old contractor still has edit access six months after the project ended, a former client contact's link never got killed. Good permission systems make revocation a single action that takes effect immediately and shows up in an access log, so you can verify it actually happened rather than assuming it did.

Build a habit around this: whenever a client contact leaves, a project ends, or a contractor rolls off, revoke access the same day, not "eventually." Secure file sharing for agencies covers this specifically as part of an offboarding checklist, which is the practical mechanism that actually gets revocation done consistently rather than left to memory.

What permission control can't do

It's worth being honest about the limits. Once someone downloads a file, your permission system no longer governs that specific copy — it can prevent future access to the source, but it can't reach into a saved file that's already been forwarded. This is a reason to keep highly sensitive material as view-only, no-download where your tool supports it, and to treat permission control as reducing risk rather than eliminating it entirely. How to share files with clients securely covers the broader set of habits that work alongside permission settings, not instead of them.

Testing this before you trust it

Before relying on any tool's permission control for real client data, create two fake client accounts and verify, hands-on, that one cannot see the other's files regardless of what you try — guessing URLs, checking shared folders, searching within the tool. If a vendor can't demonstrate this cleanly in a five-minute test, that's the answer, regardless of what the pricing page claims about security.

FAQ

See below.