---
id: KB-AD-016
url: https://app.codecontract.io/help/administration/who-can-see-your-documents
idioma: en
categoria: administracion
audiencia: administrador
nivel: intermedio
actualizado: 2026-08-13
tambienEn: [es]
relacionados: [KB-AD-004, KB-NO-014, KB-AD-019]
citadoPor: [KB-AD-007]
---

# Who can see your documents

_The question everyone asks before uploading anything, answered with what can be checked._

**Responde a:** who has access to my documents · can the vendor see my data · support access to our account · where is the data hosted

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.

> [!WARNING]
> 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

**En corto**

- Grant the minimum permission, and review annually who sees what.
- Withdraw outsiders' access when the engagement ends.
- Avoid shared accounts, which break the log.
- And decide which sensitive documentation goes in and which does not need to.

The last is the least technical and the most effective: not everything that exists in your company has to live in any tool.

> [!NOTE]
> 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.

## Ejemplos

**An advisory firm hesitates to upload its clients' documentation to a new tool.**

- Asks in writing about hosting, subprocessors and the support access trail
- Checks that the activity log also records views

→ Signs with an answer it can show its own clients when they ask.

**A client asks who can see their documents.**

- Checks that file's permissions

→ The answer is specific.

**The whole team sees every client's documentation.**

- Limits access according to the engagement

→ Sensitive material stays where it should.

**It is shared with an external party who sees more than intended.**

- Checks the scope before sharing

→ They see theirs and nothing more.

**Nobody knows who has opened a document.**

- Checks the access log

→ The question has an answer.

**The client is answered from memory.**

- Checks before answering

→ What is asserted is true.