Administration
Who can see your documents
The question everyone asks before uploading anything, answered with what can be checked.
It is the first serious question anyone asks before putting their clients' documentation somewhere new, and it deserves an answer you can check rather than a promise. There are three separate circles, and it helps to look at them one at a time.
The three circles
| Who | What they see | How you check it |
|---|---|---|
| Your team | Whatever their role and permissions allow | The activity log: it says who opened what and when |
| Third parties you invite | Only their own, or what you grant | The same log, with their name |
| The platform's providers | What operating the service requires | The public subprocessor list and what you signed |
Important
Over the first circle you have full control and proof: **every access is logged, including read-only ones**. That means the answer to "who has seen this document?" does not depend on trusting anyone, not even inside your own company. It is the most underestimated point when evaluating a tool and the most valuable the day there is a suspicion.
What to ask for in writing before signing
- 1
Where the data is hosted
Country and infrastructure provider, not "in the cloud".
- 2
Which subprocessors are involved and for what
There should be a public, current list, with notice when it changes.
- 3
In what cases support accesses, and with what trail
The right question is not whether they can, but when and what is recorded.
- 4
And what happens at the end
How you take everything with you and what is deleted, with timeframes.
Watch out
Be sceptical of "nobody on our team can see anything". In any service run by people, someone administers the infrastructure, and claiming otherwise is a simplification that collapses in the first serious audit. The credible answer is not that it is impossible: it is **what is restricted, what is logged and what you signed** — that is what an auditor checks and what you can demand.
What you can do to shrink the circle
The last is the least technical and the most effective: not everything that exists in your company has to live in any tool.
Worth knowing
If a client sends you a security questionnaire, these are the same questions they will put to you — and a public subprocessor list is part of an answer you can give without negotiating anything.
›Can I find out whether someone viewed a specific document?
Yes, in the activity log, with name and time.
›Does the assistant see more than I do?
No: it answers with what your permissions allow you to see.
›What if I need a formal answer for a client?
Ask for it in writing and keep it with that client's documentation.
A real case
The situation
An advisory firm hesitates to upload its clients' documentation to a new tool.
What you do
- Asks in writing about hosting, subprocessors and the support access trail
- Checks that the activity log also records views
What you get
Signs with an answer it can show its own clients when they ask.
The situation
A client asks who can see their documents.
What you do
- Checks that file's permissions
What you get
The answer is specific.
The situation
The whole team sees every client's documentation.
What you do
- Limits access according to the engagement
What you get
Sensitive material stays where it should.
The situation
It is shared with an external party who sees more than intended.
What you do
- Checks the scope before sharing
What you get
They see theirs and nothing more.
The situation
Nobody knows who has opened a document.
What you do
- Checks the access log
What you get
The question has an answer.
The situation
The client is answered from memory.
What you do
- Checks before answering
What you get
What is asserted is true.
This article answers
- who has access to my documents
- can the vendor see my data
- support access to our account
- where is the data hosted