Virtual Data Room Security Checklist for M&A Teams

Table of Contents

1. How to Use This Checklist
2. Scoring and Decision Rules
3. Point 1: Encryption in Transit
4. Point 2: Encryption at Rest and Key Management
5. Point 3: Identity and Multi-Factor Authentication
6. Point 4: Role-Based and Least-Privilege Access
7. Point 5: Per-Document Permissions
8. Point 6: Download and Print Restrictions
9. Point 7: Dynamic Watermarking
10. Point 8: Audit Logging
11. Point 9: Session, Device and Network Controls
12. Point 10: Data Location and Sub-Processors
13. Point 11: Vendor Assurance Evidence
14. Point 12: Vulnerability Management and Secure Development
15. Point 13: Incident Response and Notification
16. Point 14: Data Deletion and Retention at Close
17. Operating Controls: Separation of Duties and Continuity
18. Mapping the Checklist to NIST CSF 2.0
19. Frequently Asked Questions

How to Use This Checklist

This checklist is written for the people who must approve a VDR and the people who will run it. It assumes you are evaluating two or three vendors, or that you have already selected one and are preparing to launch. The same points apply in both cases, but the evidence you request will differ. Before a purchase, you are looking for proof that controls exist and work. After a purchase, you are verifying that the configuration matches what you agreed and that it continues to operate.

Assign each point to a named owner. For a typical deal, that will be a security lead for the technical points, counsel for the contractual and data location points, and the deal lead for the operating points. Record the evidence for each point in a single shared file, with the date you reviewed it.

For the broader context of how VDRs differ from general storage, the article on virtual data room vs cloud storage explains why these controls matter more during transactions than in routine sharing. For an M&A-specific workflow, see how to set up a virtual data room for M&A due diligence.

Scoring and Decision Rules

Score each point as one of three outcomes:

• Pass: The control exists, you have evidence, and the evidence covers the service and the period you need.
• Conditional: The control exists, but the evidence is partial, the scope is unclear, or a configuration step is required before launch.
• Fail: The control is absent, cannot be demonstrated, or the vendor declines to provide evidence.

A reasonable decision rule is that any fail on identity, encryption, audit logging or data location should stop the purchase until resolved. Conditional items should have a written remediation plan with owners and dates. A pass on every point is rare, and the aim is not to produce a perfect score but to make the trade-offs explicit and documented.

Each point below includes what to verify, the evidence to request, and the red flags.

Point 1: Encryption in Transit

What to verify. All connections to the VDR, including browser sessions, API calls, email notifications and any file transfer endpoints, use current Transport Layer Security. Obsolete protocols and weak cipher suites should be disabled.

Evidence to request. A description of the supported TLS versions and cipher suites, and the results of an independent test of the public endpoints, such as an SSL configuration report. Ask whether the vendor follows NIST guidance for TLS implementations.

Red flags. Support for old protocol versions, mixed content warnings in the viewer, or a vendor who cannot describe its configuration in writing.

Point 2: Encryption at Rest and Key Management

What to verify. Stored documents, backups and derived files such as rendered pages are encrypted. Ask how keys are generated, stored, rotated and destroyed, and who within the vendor can access them. Where the vendor offers customer-managed keys, confirm the operational implications, such as what happens if the key is revoked.

Evidence to request. A written description of the encryption scheme and key management practices, with reference to the relevant NIST guidance on key management, such as NIST SP 800-57. Ask whether encryption keys are separated from the data they protect.

Red flags. Vague descriptions such as "bank-grade encryption" without detail, or no information about key management. Encryption at rest does not restrict what an authorized user can view, and vendors that imply it does are conflating two separate controls.

Point 3: Identity and Multi-Factor Authentication

What to verify. Every account, including external reviewers and vendor administrators, has verified identity and supports multi-factor authentication. Administrators should be required to use it. Ask whether the platform supports single sign-on for enterprise users, and whether it can enforce policies such as minimum authenticator strength.

Evidence to request. Documentation of authentication options, a description of account recovery flows, and confirmation of whether phishing-resistant methods are supported for administrators. NIST SP 800-63B describes the requirements for authenticator assurance and can be used to structure the questions.

Red flags. Accounts that can be created without verification, account recovery that depends only on email access, or administrators who cannot be required to use multi-factor authentication.

Point 4: Role-Based and Least-Privilege Access

What to verify. Roles are defined for administrators, deal leads, reviewers and external parties, and each role has only the rights needed for its function. Confirm that the platform supports groups, that group membership can be changed quickly, and that removing a user does not leave orphaned rights.

Evidence to request. A role matrix from the vendor, and a demonstration of creating a group, granting access, and removing a member. Ask how the platform handles users who belong to multiple groups.

Red flags. A single administrator role with unlimited rights, no ability to separate deal administration from content management, or group membership that cannot be audited.

Point 5: Per-Document Permissions

What to verify. Permissions can be set at folder and document level, with explicit overrides, and the platform's precedence rules are documented. Permissions should be enforced on the server, not only in the interface.

Evidence to request. Documentation of the permission model, including view, download, print and manage rights, and of the precedence logic. Test a conflict scenario with a test account before relying on the design. The VDR permission levels explainer describes the layers in more detail.

Red flags. Permissions that apply only to folders, no document-level exceptions, or precedence rules that the vendor cannot describe.

Point 6: Download and Print Restrictions

What to verify. Download and print can be restricted independently for each document and each recipient group. Confirm whether view-only documents can be exported to PDF or printed through another function, and whether bulk download is restricted.

Evidence to request. A test report showing the outcome of view, download, print and export attempts for view-only documents. Ask how the platform delivers view-only content, for example whether original files are withheld from the client.

Red flags. Download restrictions that apply only to the interface while the original file is still delivered to the browser, or view-only settings that can be bypassed by a standard export function.

It is worth being precise about what this control does. Download and print restrictions reduce the number of paths by which a reviewer can obtain a copy. They do not stop screen capture, and they do not stop a reviewer from reproducing content they have read.

Point 7: Dynamic Watermarking

What to verify. Watermarks show the viewer's identity, the timestamp and, where appropriate, the access context on each rendered page. Confirm whether the watermark is applied to printed output and exports where those are allowed, and whether it is legible without obscuring content.

Evidence to request. Sample output showing the watermark on screen, in print, and in any export format. Ask whether the watermark can be configured per folder and per recipient group.

Red flags. Static watermarks that do not identify the viewer, watermarks that can be removed by changing a setting in the viewer, or no watermark on printed output.

Dynamic watermarks are a deterrent and an attribution tool. They make copies traceable, which changes behavior for most people, but they do not prevent a photograph of a screen. Treat them as part of a layered approach.

Point 8: Audit Logging

What to verify. The platform logs logins, failed logins, permission changes, invitations, views, downloads, prints, Q&A actions and administrative changes. Ask at what granularity page-level activity is recorded, how long logs are retained, whether logs can be exported, and whether logs are protected from modification.

Evidence to request. A sample audit export with explanations of each field, the retention period, and a description of how logs are protected against tampering. NIST SP 800-92 describes the principles of log generation, protection and review, which can guide your questions.

Red flags. Logs that record only that a document was opened, no export capability, retention periods shorter than your transaction requires, or no information about who can alter or delete logs.

Test the logs yourself. Perform a set of known actions in a test room, export the log, and confirm that each action appears with the correct user and timestamp. Logs that have never been tested are not reliable evidence.

Point 9: Session, Device and Network Controls

What to verify. Sessions expire after a period of inactivity, and access can be restricted by network range or device type where needed. Confirm that session timeout and access expiry are enforced for active sessions, not only at the next login.

Evidence to request. Configuration options for idle timeout, absolute session lifetime, IP allow lists and device restrictions, and a demonstration that an expired or revoked session cannot continue to view content.

Red flags. No idle timeout, expiry that takes effect only at login, or device controls that cannot be enforced for external users.

Context controls are useful additional layers, but they are not substitutes for identity and object-level permissions. NIST SP 800-207 describes the broader principle of evaluating access based on identity and context.

Point 10: Data Location and Sub-Processors

What to verify. The regions where data is stored and processed, the subcontractors who have access to it, and the legal frameworks that apply. For transactions involving personal data, confirm the vendor's data processing terms and transfer mechanisms.

Evidence to request. A current list of data locations and sub-processors, the data processing agreement, and the vendor's process for notifying customers of changes to sub-processors. For personal data processed in or about the European Union, the GDPR text available at gdpr-info.eu is a useful reference for the questions counsel should ask.

Red flags. Refusal to name sub-processors, data stored in jurisdictions that conflict with the transaction's requirements, or no contractual commitment on notice of changes.

Point 11: Vendor Assurance Evidence

What to verify. The vendor holds independent assurance over its controls. Common examples include a SOC 2 Type II report, an ISO/IEC 27001 certificate, and penetration test summaries. Each should be checked for scope, date and coverage of the service you are buying.

Evidence to request. The current SOC 2 Type II report under appropriate confidentiality terms, the ISO/IEC 27001 certificate with its scope statement, and a summary of recent independent penetration tests. Confirm that the scope includes the production environment for the service you intend to use.

Red flags. A certificate that does not name the service in scope, a report that is out of date or covers only a subset of the platform, or a vendor who describes certifications in marketing material without providing documents.

Do not treat certification as proof of security for a particular configuration. A report describes the controls tested during a period and the vendor's own description of its system. You still need to verify how your room is configured.

Point 12: Vulnerability Management and Secure Development

What to verify. The vendor has a documented process for identifying, prioritizing and fixing vulnerabilities, and a secure development lifecycle. Ask how security issues are reported and how quickly critical issues are addressed. The OWASP Application Security Verification Standard provides a detailed set of requirements for web application security that can be used as a reference.

Evidence to request. A summary of the vulnerability management process, the most recent independent application security assessment summary, and the process for coordinated disclosure.

Red flags. No documented process, no independent testing, or an unwillingness to share summary results.

Point 13: Incident Response and Notification

What to verify. The vendor has an incident response plan, defined contacts, and commitments on notification timing. Confirm how you would be told of a suspected or confirmed incident affecting your room, and what information you would receive.

Evidence to request. The incident response summary, the notification commitments in the contract, and a named contact for security matters during the deal. Ask whether the vendor conducts exercises and whether customers can participate.

Red flags. No defined notification commitment, contacts that route only to a general support inbox, or no evidence of incident response testing.

Also plan your own response. Decide in advance who inside your organization will be informed, who will decide whether to inform counterparties, and how you will preserve logs. The incident plan should be part of the deal team's preparation, not something discovered during an incident.

Point 14: Data Deletion and Retention at Close

What to verify. The vendor deletes or returns data at the end of the engagement according to the contract, and it provides written confirmation. Ask how long backups are retained and how they are deleted. Confirm the process for retaining audit logs for the period your transaction requires, even after the room is closed.

Evidence to request. The data deletion procedure, the backup retention period, and a sample of the written confirmation provided after a previous engagement, with customer-identifying details removed. NIST SP 800-88 describes media sanitization principles that can inform questions about deletion.

Red flags. No deletion commitment, backups that are retained indefinitely, or no mechanism to retain logs after deletion of content.

Operating Controls: Separation of Duties and Continuity

Security does not end when the room opens. Several operating controls should be in place throughout the process:

• Separation of duties. The person who grants access should not be the only person who reviews the access list. Deal administrators should not approve their own permission changes where the platform allows a second approver.
• Break-glass access. Define an emergency procedure for restoring access if the primary administrator is unavailable, and log its use.
• Backup administrators. Name at least two people with administrative rights, both with multi-factor authentication.
• Scheduled access reviews. Review the list of users and groups at each phase transition and at least weekly during active review.
• Continuity planning. Confirm what happens if the platform is unavailable during a critical deadline, including how you would communicate with bidders.
• Change control. Record significant configuration changes, such as permission model changes and watermark settings, with the approver and the date.

Mapping the Checklist to NIST CSF 2.0

For organizations that already use the NIST Cybersecurity Framework, the fourteen points map to its functions as follows.

The framework is available from NIST at nist.gov/cyberframework. It is not a certification, but it provides a shared vocabulary for explaining your controls to boards, counsel and counterparties.