Most data room security pages lead with encryption: AES-256 at rest, TLS in transit. Both are standard and both matter. Neither tells you whether a person at the provider could read your board minutes. Encryption protects data from people without the keys, and the provider, by design, usually has the keys.
That does not make data rooms unsafe. It means the right question is not “is it encrypted?” but “who can use the keys or the application on my behalf, and how would I know?”
Who on the provider's side could reach your files, and the safeguard for each route
Support staff
Logging in as you, or viewing a room to fix a problem
Ask forAccess only on your request, time-limited, logged in your audit trail
Platform engineers
Production database or storage access
Ask forLeast privilege, approval workflow, staff access logs reviewed
Key management
Whoever holds the keys can decrypt
Ask forKeys in a managed key service; customer-managed keys where offered
Hosting subprocessor
The cloud provider running the servers
Ask forEncryption at rest, named host and region, subprocessor list
Legal demands
Court orders or government requests to the provider
Ask forPolicy to notify you where lawful; transparency on requests
Why can a provider usually access the data at all?
A data room is a web application. To show you a document preview, run a full-text search or apply a watermark, the platform has to decrypt the file on its servers. That means the platform’s systems hold or can obtain the decryption keys, and people who administer those systems are, in principle, in a position to use them.
This is the normal model for cloud software, not a data room peculiarity. End-to-end encryption, where only users hold keys, exists in some file-sharing tools, but it limits features such as server-side search, previews and dynamic watermarks. Most deal platforms choose the feature set and control access through process instead.
What are the main access routes on the provider’s side?
| Route | When it is used | Main risk | What a good control looks like |
|---|---|---|---|
| Support sessions | You ask for help with a room | Staff see documents while troubleshooting | Your explicit approval, time limit, entry in your audit log |
| Engineer access | Incidents, maintenance, data fixes | Broad production access | Least privilege, break-glass approval, logged and reviewed |
| Key management | Always, in the background | Keys stored alongside data | Managed key service, separation of duties, key rotation |
| Hosting subprocessor | Always, in the background | Infrastructure-level access | Encryption at rest, contractual limits, audited host |
| Legal demands | A court or authority orders disclosure | Disclosure without your knowledge | Policy to notify you where lawful, challenge overbroad requests |
How do support sessions work?
Support is where provider access most often touches real documents. When an administrator says “this folder will not show for the buyer group”, the fastest fix may be for a support agent to look at the room. Providers handle this in different ways:
- Consent-based access: support can only enter a room after the customer grants access, often for a fixed period.
- Impersonation: an agent logs in as a specific user to see exactly what they see. Useful, and sensitive.
- Metadata only: the agent sees folder structures, permission settings and logs, but not document contents.
The key test is whether support access appears in your own audit trail. If an agent can view your room without leaving a trace you can see, you are relying entirely on the provider’s internal logs, which you will never read.
Ask this in writing
“When your support team accesses our room, does that access appear in our audit log, under a name we can identify?” A clear yes is a good sign. “Our staff are bound by confidentiality” is an answer to a different question.
What about engineers and production systems?
Engineers who run the platform need access to production infrastructure. Mature providers restrict this with least-privilege roles, require approval for access to customer data, record the sessions and review them. These controls are exactly what a SOC 2 audit tests, in the logical access sections of the report.
That makes the audit report the best evidence you will get. Our guide to checking a data room’s security claims explains how to read the access control sections and spot exceptions. Every provider in our dataset lists SOC 2; the useful differences are in scope and exceptions.
Who holds the encryption keys?
There are three common models:
| Key model | Who controls keys | Provider access | Trade-off |
|---|---|---|---|
| Provider-managed | The provider, usually in a cloud key management service | Possible, controlled by process | Simplest; all features work |
| Customer-managed keys | You, in your own cloud key service | Reduced; you can revoke the key | Enterprise option, you manage availability |
| End-to-end encryption | Only end users | Minimal | Server features such as search and previews are limited |
Customer-managed keys give you a kill switch: revoke the key and the provider can no longer decrypt your data. They also give you a new responsibility. If your key service fails or a key is deleted by mistake, your own room becomes unreadable. For most single-deal rooms, provider-managed keys with strong process controls are the realistic choice. Ask whether the provider offers customer-managed keys if your organisation’s policy requires it.
What does the hosting subprocessor see?
The cloud host runs the servers and stores the encrypted data. It does not normally have the application keys or access to your room. Its role still matters for data residency (which country your data sits in) and for the security of the underlying infrastructure.
Ask for the subprocessor list and the hosting region. A provider citing only its cloud host’s certifications is telling you about the data center, not about its own staff and application. That distinction is worth holding onto.
What happens if authorities request your data?
Any provider can receive a court order or government request. A good provider has a written policy: it reviews requests, challenges overbroad ones, and notifies the customer unless legally prevented. Some publish transparency reports on how many requests they receive.
The provider’s location and the hosting region both affect which legal regimes apply. For cross-border deals, it is reasonable to ask both questions and record the answers.
What should you ask before signing?
A short written questionnaire covers most of this:
- Can provider staff view document contents, and under what circumstances?
- Does support access require our approval, and does it appear in our audit log?
- How is engineer access to production data approved, logged and reviewed?
- Where are encryption keys stored, and are customer-managed keys available?
- Who are your subprocessors, and where is our data hosted?
- What is your policy on legal requests for customer data?
Compare answers across your shortlist. Vague answers on questions 1 and 2 are the most telling, because those are the routes most often used day to day. Our reviews cover each provider’s certifications and security features; our review method explains how we weigh security posture against workflow and usability.
Does any of this make a data room riskier than email?
No. Email providers also hold keys to your messages, and once an attachment is sent, you lose control entirely. A data room adds permission groups, watermarks, revocation and an audit trail on top. The point of asking about provider access is not to find a zero-risk option, but to choose a provider whose controls you understand and can evidence.
Frequently asked questions
Can data room employees read my documents?
On most platforms some staff could technically access documents, because the provider manages the keys and runs the application. Good providers restrict this to approved, time-limited, logged access, typically only when you request support.
Is my data encrypted in a virtual data room?
Established providers encrypt data at rest and in transit. Encryption protects against anyone without the keys; it does not by itself stop the provider, which usually manages the keys, from decrypting data.
What are customer-managed encryption keys?
Keys that you hold in your own cloud key management service. Revoking the key stops the provider decrypting your data. It is usually an enterprise option and makes you responsible for key availability.
Will I know if the provider accessed my data room?
Only if provider access is recorded in your own audit trail. Ask whether support and staff access appears there under an identifiable name; on some platforms it is logged only internally.
Does the cloud host have access to my files?
The host stores encrypted data and runs the servers but does not normally hold the application's keys. Its role matters mainly for data residency and infrastructure security.