Data room encryption protects deal files in two states: at rest on the vendor's storage, typically with AES-256, and in transit between the reviewer's browser and the server, using TLS 1.2 or 1.3. Encryption makes stolen disks and intercepted traffic unreadable. It does not decide who may open a file. Permissions, identity checks and audit logs do that.
That distinction matters when you buy a secure data room. Almost every vendor advertises 'bank-grade encryption', and the phrase tells you very little. The useful questions are about where encryption is applied, who controls the keys, and which risks sit outside encryption entirely. For the wider control set, see the secure data room features checklist.
Best overall: Read the Papermark review
Papermark is best for deal teams that want encryption backed by audited controls: SOC 2 Type II and ISO 27001 certified, GDPR compliant and EU hosted, with NDA gating, watermarking and audit logs. The Data Rooms plan is $99/month on annual billing with unlimited data rooms and visitors.
How data room encryption at rest works with AES-256
Encryption at rest means files are stored in a form that is unreadable without a key. The standard cipher is AES, the Advanced Encryption Standard published by NIST as FIPS 197. AES-256 uses a 256-bit key and is approved for protecting highly sensitive information. No practical attack against correctly implemented AES-256 is publicly known, so the cipher itself is rarely the weak point. Implementation and key handling are.
In a modern data room, encryption at rest is usually applied in layers. The cloud storage service encrypts disks and objects. The application may add its own layer, encrypting each file with a unique data encryption key. Those data keys are in turn encrypted with a key encryption key held in a key management service or a hardware security module (HSM). This pattern is called envelope encryption. It means a copy of the raw storage, on its own, is useless to an attacker who cannot also reach the key service.
Encryption at rest should also cover backups, the page images generated for the online viewer, search indexes and temporary conversion files. A vendor that encrypts originals but caches rendered pages unencrypted has a gap, whatever the marketing page says.
Encryption in transit: TLS between reviewers and the secure data room
Encryption in transit protects documents while they move across networks. For a browser-based data room that means HTTPS, which runs on TLS. Current guidance, including NIST SP 800-52, expects TLS 1.2 at a minimum and TLS 1.3 where supported. Older protocols such as SSL 3.0, TLS 1.0 and TLS 1.1 should be disabled on every endpoint, not just the main login page.
Two further details separate a careful configuration from a default one. The first is forward secrecy: cipher suites based on ephemeral key exchange mean that if a server key is compromised later, previously recorded sessions still cannot be decrypted. TLS 1.3 requires it. The second is HTTP Strict Transport Security (HSTS), which tells browsers never to connect over plain HTTP and closes off downgrade tricks on public Wi-Fi.
Transit encryption also applies inside the vendor's environment: traffic between the web tier, document processing, database and storage should be encrypted too. Email is a separate channel: a good data room sends a link that requires a login, never the document as an attachment.
- TLS 1.2 minimum, TLS 1.3 preferred, on every endpoint including APIs and file download URLs
- SSL 3.0, TLS 1.0 and TLS 1.1 disabled
- Forward-secret cipher suites only
- HSTS enabled on the application domain
- Encryption on internal service-to-service traffic
- Notifications that link to the room rather than attach files
Data room key management: who holds the keys
Key management decides who can turn ciphertext back into a readable document, and it matters more than the choice of cipher. NIST SP 800-57 sets out the principles most security teams follow: generate keys securely, limit who and what can use them, rotate them on a defined schedule, log every use, and destroy them deliberately when the data they protect should no longer exist.
Data room vendors generally use one of four models. Each trades control against convenience and features.
| Key model | Who controls the keys | What it means for a deal team |
|---|---|---|
| Provider-managed keys | The vendor, usually through a cloud key management service | Simplest to run and supports every viewer feature. You rely on the vendor's access controls and audit evidence for key use. |
| Customer-managed keys (BYOK) | You create or import a key in your own cloud account and the vendor uses it | You can revoke the key to cut off access to stored files. Needs your own cloud security capability and is usually an enterprise option. |
| Hold your own key (HYOK) | Keys stay in your own key service or HSM and are never stored by the vendor | Maximum control and maximum operational burden. An outage on your side can lock reviewers out mid-deal. |
| End-to-end or client-side encryption | Only end users' devices hold the decryption keys | The server cannot read files, so server-side previews, search, dynamic watermarking and page analytics are limited or unavailable. |
Encryption vs access control in a secure data room
Encryption and access control answer different questions. Encryption asks: can someone who gets hold of the raw bytes read them? Access control asks: should this particular person see this particular file right now? A data room needs both, and confusing them leads to false comfort.
When an authorized reviewer logs in and opens a document, the platform decrypts it for them. That is the whole point. So if an attacker phishes a reviewer's password, or a bidder shares login details with a colleague who never accepted the NDA, encryption does nothing to stop the exposure. The intruder is using a legitimate session and sees exactly what the reviewer sees.
That is why the controls on top of encryption carry most of the day-to-day protection: granular folder and file permissions, two-factor authentication, NDA gating before the first view, view-only access and download restrictions, dynamic watermarking that ties each page to a viewer, and an audit log that shows who opened what. Our guides to data room permissions and to watermarking and download controls cover those layers in detail. Encryption is the floor, not the building.
A hypothetical scenario: Halvorsen Marine answers a buyer's encryption question
Halvorsen Marine is a hypothetical, privately held maker of marine navigation electronics with about 140 employees. Its owners are running a sale with three bidders, one of them a listed strategic acquirer whose information security team sends a short questionnaire before its deal team may log in to the data room.
The first question is simple: is the data room encrypted? Halvorsen's CFO, who chose the vendor, is tempted to reply 'yes, AES-256' and move on. Her outside counsel suggests answering the questions the security team will ask next. The CFO goes back to the vendor's security documentation and the SOC 2 Type II report she received under NDA, and writes a one-page answer: encryption at rest on stored files and backups, TLS 1.2 or higher in transit, keys held in a managed key service with restricted and logged access, and independent audit coverage of those controls during the report period.
She adds a second paragraph the bidder did not ask for. It explains that access is restricted by bidder group, that two-factor authentication is required, that every visitor accepts an NDA before the first view, and that sensitive folders are view-only with dynamic watermarks. The bidder's security lead approves access the next morning and later tells counsel that the second paragraph was the one that mattered, because it showed the seller understood that encryption alone does not stop a leak.
What to ask a secure data room vendor about encryption
Send these questions in writing and ask for answers that point to evidence, such as a section of the SOC 2 report or a published security document. For a full vendor review across every security area, use our data room security questionnaire.
| Question | Why it matters | Good answer |
|---|---|---|
| Which cipher and key length protect stored files and backups? | Confirms encryption covers every copy, not just the primary store | AES-256 or equivalent on primary storage, backups, previews and search indexes |
| Which TLS versions are accepted on every endpoint? | A weak protocol on a forgotten API or download domain undoes the main configuration | TLS 1.2 minimum, TLS 1.3 supported, older versions disabled everywhere |
| Where are encryption keys stored and who can use them? | Key access is the real control over decryption | A managed key service or HSM, access limited to named services, every use logged |
| How often are keys rotated, and what happens to old keys? | Rotation limits the damage from a compromised key | A defined rotation schedule with documented retirement of old keys |
| Is customer-managed key (BYOK) available, and on which plans? | Some regulated buyers require the power to revoke keys themselves | A clear yes or no, with the operational trade-offs explained |
| Are encryption and key management controls inside the SOC 2 Type II scope? | Independent testing is stronger than a self-description | Yes, with the relevant controls listed and tested over the report period |
| What happens to keys and data when we close the room? | Destroying keys and deleting backups is how data becomes unrecoverable | A documented deletion timeline for files and backups, with confirmation on request |
What data room encryption does not protect against
Encryption is necessary and well understood. It also has clear limits that buyers should hear plainly, rather than discover during an incident.
- Stolen or shared credentials. A valid login gets decrypted documents. Two-factor authentication and named, individual accounts are the countermeasure.
- Authorized reviewers who leak. Someone with legitimate access can copy notes, retype figures or photograph a screen. Watermarking and audit logs deter and attribute; they do not prevent.
- Downloaded copies. Once a file is downloaded to a reviewer's device, it sits outside the data room's encryption and control. View-only access keeps sensitive files in the browser.
- Permission mistakes. Encryption faithfully protects a file you shared with the wrong group. It cannot tell that the group was wrong.
- Wrong uploads. A draft with tracked changes, a spreadsheet with a hidden tab or a file name that reveals a customer is fully encrypted and fully visible to everyone with access.
- Vendor-side misuse. Platforms that render previews can decrypt files. Restriction, logging and independent audits of staff access are the safeguard, not encryption itself.
Common data room encryption mistakes buyers make
- Treating 'AES-256' on a marketing page as the whole security story instead of asking about keys, scope and backups.
- Assuming encryption replaces permissions, so every buyer group gets the same broad folder access.
- Choosing end-to-end encryption for prestige, then discovering that previews, watermarking and page analytics no longer work as expected.
- Accepting a SOC 2 report without checking whether encryption and key management controls were in scope.
- Never asking what happens to data and keys after the deal, so copies linger on a platform nobody is watching.
More on data room security
Part of the What is a secure data room? cluster.
Next steps
What is a secure data room?
The security hub: how a secure data room differs from ordinary file sharing.
Secure data room features checklist
The full control set to compare, of which encryption is only one layer.
Data room permissions explained
The access control layer that decides who sees decrypted files.
SOC 2 vs ISO 27001 for secure data rooms
Where independent evidence for encryption and key controls comes from.
Data room security questionnaire
The full question set for vetting a data room vendor.
FAQ
Is AES-256 encryption enough for a secure data room?
AES-256 is a strong, widely approved cipher, and no practical attack on a correct implementation is publicly known. It is enough for the job it does, which is protecting stored data. It is not enough on its own, because most leaks involve people with valid access, so permissions, two-factor authentication, watermarking and audit logs carry most of the protection.
What is the difference between encryption at rest and encryption in transit?
Encryption at rest protects files while they are stored on the vendor's disks, backups and caches. Encryption in transit protects files while they travel between a reviewer's browser and the platform, and between the platform's internal services, using TLS. A secure data room needs both.
Can the data room vendor read my documents?
If the platform shows online previews, applies dynamic watermarks or offers full-text search, its systems must be able to decrypt files. What matters is how strictly that ability is limited, whether every access is logged, and whether an independent auditor has tested those controls. Ask which SOC 2 Type II controls cover it.
Do I need customer-managed keys for an M&A data room?
Most private company transactions do not. Customer-managed keys suit organizations with their own cloud security team and a regulatory or policy reason to hold revocation power. They add operational work, and a misconfiguration on your side can lock reviewers out during a live process.
Does encryption stop a buyer from leaking documents?
No. A buyer with legitimate access sees decrypted documents, so encryption has nothing to say about what they do next. View-only access, download restrictions, dynamic watermarking and a complete audit log are the controls that deter and attribute leaks.
Where can I check a vendor's encryption claims?
Ask for the SOC 2 Type II report and ISO 27001 certificate and confirm that encryption and key management sit inside their scope. Check the vendor's security documentation for TLS versions and key handling.