Virtual Data Room Permission Levels Explained

Table of Contents

1. Why Permission Levels Are Easy to Misread
2. The Layers of a VDR Access Decision
3. Identity and Authentication
4. Groups, Roles and Inheritance
5. Object-Level Rights: Folders and Documents
6. View-Only: How Rendering Changes the Threat Model
7. Print Controls
8. Download Controls
9. NDA Gating as an Access Condition
10. Individual Rules and Precedence
11. Time-Limited Access and Session Lifetime
12. Contextual Conditions: Network, Device and Step-Up
13. A Permission Matrix and Its Residual Risks
14. Testing Your Configuration
15. Frequently Asked Questions

Why Permission Levels Are Easy to Misread

Administrators often see a permission dropdown with options such as "View," "View and Print," "Download," or "Full Access," and assume the labels describe the complete behavior of the system. In practice, each label is a shorthand for a set of checks that run at different points: when a session starts, when a page is requested, when a file is fetched, and when the user performs an action in the browser. A label may be correct for one path and incomplete for another.

A useful way to think about the subject is to separate three questions. First, is this person allowed to reach this object at all? Second, what is the server willing to deliver to them? Third, what can the person's own device and software do with what they receive? The first two questions are enforced by the platform. The third is where most of the uncertainty lives, because it depends on browsers, operating systems, screenshot tools and the people using them.

This article follows that structure. It starts with the decision layers, explains each permission type, and closes with a matrix that lists what each control prevents and what remains as residual risk. It is written for VDR administrators, IT security teams and deal managers who need to configure a room and explain its limits to stakeholders. For a higher-level comparison of VDRs and general cloud storage, see Virtual Data Room vs Cloud Storage.

The Layers of a VDR Access Decision

When a reviewer opens a document, a well-designed VDR evaluates several layers, usually in roughly this order:

1. Authentication. Is the session associated with a known, verified identity, and does it satisfy any required authentication strength such as multi-factor authentication?
2. Access gating. Has the user met a precondition, such as accepting the room terms or signing an NDA?
3. Membership. Which groups does the user belong to, and what do those groups grant?
4. Object authorization. For the specific folder or document requested, what rights apply after considering group rules and individual overrides?
5. Delivery mode. Is the content delivered as a rendered view, a streamed document, or an original file?
6. Session controls. Does the session carry restrictions such as watermarking, idle timeout, or device or location constraints?
7. Logging. Is the attempt and its outcome recorded, with enough detail to reconstruct it later?

Permissions can fail at any layer. A user who is authenticated but not in the correct group should be refused. A user in the correct group who has not accepted the NDA should be refused. A user with permission to view a document who attempts to download it should be refused by the object authorization or delivery layer, depending on how the platform is built.

The practical lesson is that a permission label describes one or two layers, and the others must be checked separately.

Identity and Authentication

The identity layer determines who the session belongs to. VDRs typically support one or more of the following:

• Email and password with invitation, where the user receives a link, sets credentials and may be asked to verify the email address.
• Single sign-on through an identity provider, which is common for internal administrators and sometimes offered to external users by enterprise customers.
• One-time codes or magic links, which reduce password management but depend on the security of the email account.
• Multi-factor authentication, which can be optional, required for all users, or required for specific groups or actions.

Authentication is the foundation of every other permission. If an account can be taken over, the document-level controls will be applied to the attacker. The relevant guidance is in NIST SP 800-63B, which describes authenticator assurance levels and the requirements for session management. Administrators should understand which authentication options the platform offers, whether it supports phishing-resistant methods for administrators, and how account recovery works, because recovery flows are a common route to takeover.

Groups, Roles and Inheritance

Most VDRs organize users into groups, which can represent a buyer's legal team, a bidder's finance team, a clean team, or an administrator role. Groups are attached to folders or documents with specific rights, and users inherit those rights by membership.

Inheritance is usually hierarchical. If a folder grants "view" to a group, documents within that folder typically inherit that right unless a more specific rule applies. This simplifies administration but creates a risk: a broad grant at a high level can expose content the administrator did not intend to share, particularly when new documents are added later.

Good practice includes:

• Creating groups by role and purpose, such as "Bidder A, legal, confidential" rather than by individual name, so membership changes do not require rebuilding rules.
• Granting the minimum rights at the highest level that is appropriate, and using explicit document-level rules for sensitive exceptions.
• Documenting group membership with dates, so the permission state can be reconstructed at any point.
• Reviewing inherited permissions after each batch upload, because new documents may land in folders with broader rights than intended.

Object-Level Rights: Folders and Documents

Object-level rights determine what a group or user can do with a particular folder or document. A common set includes:

• List or see: the user can see that the object exists, often including its name and metadata.
• View: the user can open and read the content, subject to delivery and session controls.
• Comment or annotate: the user can add notes, where the platform supports it.
• Download: the user can obtain a copy of the file.
• Print: the user can produce a printed or printed-to-file version.
• Manage: the user can change permissions or the structure of the object.

The distinction between "see" and "view" matters. A user who can see a document's title but not its content may still learn sensitive information from the name. Titles such as "Restructuring plan draft" can reveal more than intended. Index design, discussed in how to organize a virtual data room, should take this into account.

View-Only: How Rendering Changes the Threat Model

"View-only" is one of the most commonly requested and most commonly misunderstood settings. In most VDRs, a view-only document is delivered as rendered pages rather than as the original file. The platform converts the document into images or a proprietary format and streams the pages to the browser, sometimes in tiles or on demand.

Rendering has several effects:

• The original file is not delivered, so the viewer cannot simply save the file from the download link.
• The viewer receives only the pages they request, which can limit bulk extraction.
• Text may be rendered as images, which reduces but does not eliminate copy-and-paste. Some platforms keep text selectable, and that must be checked.
• Dynamic watermarks can be applied to each rendered page with the viewer's identity.

Rendering does not stop screen capture, camera photography, or a determined person who reconstructs the content from the rendered pages. It is a control that reduces the paths available to casual copying and raises the effort for bulk extraction. It should be described to stakeholders as a reduction in exposure, not a guarantee.

It is also important to confirm how view-only interacts with printing. A platform may block printing from the viewer interface but still allow the browser's print dialog to produce a PDF of rendered pages, depending on implementation.

Print Controls

Print is a separate operation from view and download. A platform can implement print controls in several ways:

• Disabled print in the interface, which removes print buttons and blocks print shortcuts where the browser allows the page to intercept them.
• Server-side print rights, where the platform generates a print-ready file only when the user has print rights.
• Print rendering limits, such as lower resolution or watermarked output, which reduce the quality of printed copies.
• Browser print blocking, which attempts to prevent the browser's print function from working on the page.

Each of these has limits. Browser-level controls can generally be bypassed by the user, for example by taking a screenshot or printing from another application. Server-side controls are more reliable when the platform is the only source of printable content, but they still depend on the platform's implementation. Treat print restrictions as useful deterrents and reduced paths, and combine them with watermarking to make any printed copy attributable.

Download Controls

Download is the most clearly defined permission, because it is about whether the platform will deliver an original file to the user. A download control is generally enforced on the server, meaning the platform refuses to send the original file to an account without download rights. This is a stronger control than a browser-level restriction, because it does not depend on what the client does with the content.

However, there are several subtleties:

• A user who can view a document may still be able to capture it through screenshots, which download controls do not address.
• Some platforms provide a "download as PDF" function for view-only documents. If that function is available, it may bypass the intent of the restriction, so confirm the behavior for each permission level.
• Download rights for a folder may not automatically apply to a document inside it, and vice versa, depending on the precedence rules.
• Bulk download features, such as downloading an entire folder as a compressed archive, should be restricted and logged separately.

The safest approach is to test each permission combination with a test account and record the results, rather than relying on the label.

NDA Gating as an Access Condition

NDA gating is an access condition rather than a permission type. Before a user can open the room, or a particular folder, the platform requires them to accept terms, sometimes including an NDA that the user must sign electronically. The acceptance is recorded with a timestamp, the user's identity and the version of the terms accepted.

NDA gating is valuable for three reasons. It creates a clear contractual framework for the user's obligations. It produces evidence that the user agreed to the terms before accessing material. And it can be versioned, so that updated terms require fresh acceptance.

There are limitations. A click-through acceptance is only as strong as the agreement it references and the enforceability of that agreement in the relevant jurisdiction. Counsel should review the wording. NDA gating also does not restrict what the user does with content, which is the job of the permission layer. The two controls should be designed together.

Individual Rules and Precedence

Individual rules apply to a specific user and override or add to group rules. They are useful for exceptions, such as allowing one advisor to download a document that the rest of their group can only view, or blocking a particular individual from a folder that the group can access.

The precedence model determines the outcome when rules conflict. Common models include:

• Explicit deny overrides allow, where any denial, from any source, prevails.
• Most specific rule wins, where a document-level rule overrides a folder-level rule, and an individual rule overrides a group rule.
• Most permissive wins, where any grant of a right produces access, regardless of other denials. This is less common in VDRs and carries higher risk.

Each platform implements these differently, and some combine them. Before relying on the configuration, test a conflict scenario: create a group grant at folder level, an individual deny at document level, and confirm the outcome for the individual. Record the result. Administrators who assume a precedence model without testing it often discover the problem only after a document has been exposed.

Time-Limited Access and Session Lifetime

Time-limited access ensures that a user's rights end on a known date or after a known period. There are at least two timers that matter:

• Access expiry, which is a server-side setting that removes or disables the user's rights at a specified time.
• Session lifetime, which determines how long a logged-in session remains valid, and idle timeout, which ends sessions after a period of inactivity.

Access expiry is the stronger control, because it removes rights on the server regardless of what the user's device does. Session lifetime limits the window in which a stolen session token could be used, but it does not change the user's underlying rights. Administrators should set both, and they should confirm that expiry applies to existing sessions as well as new logins. Some platforms apply expiry only when a session is refreshed, which can leave a window of exposure.

Expiry should be aligned with the process timetable. For a due diligence process, a common approach is to set an expiry date for each bidder at the end of the confirmatory phase, with an extension approved by the deal lead when required. Document each extension.

Contextual Conditions: Network, Device and Step-Up

Some platforms allow access conditions based on context, such as the user's network address, the device they use, or whether they have completed additional authentication recently. These controls are often grouped under zero trust or risk-based access.

• IP allow lists restrict access to particular network ranges. They are useful when recipients work from known offices, but they can be inconvenient for traveling reviewers and do not protect against a compromised device inside an allowed network.
• Device restrictions may limit access to managed devices or block access from unmanaged ones. These controls depend on device management and may not be available to all external users.
• Step-up authentication requires additional verification before a sensitive action, such as a download or a permission change.

The principle behind these controls is described in NIST SP 800-207, which discusses access decisions based on identity, device posture and context rather than network location alone. Use contextual controls as additional layers, not as replacements for identity and object-level permissions.

A Permission Matrix and Its Residual Risks

The matrix below summarizes common permission levels, what each prevents, and the residual risk that remains. Results depend on implementation, so use it as a checklist for your own testing rather than a specification.

Three conclusions follow from the matrix. First, no permission level eliminates exposure to an authorized reviewer. Second, the value of view-only and watermarking is largely in reducing and attributing exposure. Third, download rights should be granted narrowly, because a downloaded file leaves the controlled environment and is difficult to recall.

Testing Your Configuration

Permission settings should be tested before they are relied upon. A practical test plan includes:

1. Create test accounts in each group, including one with individual overrides.
2. For each sensitive document, attempt to view, download, print, copy text, and open the document from a direct link.
3. Attempt access after the expiry date, using a session that began before the expiry if your platform allows that scenario to be tested safely.
4. Confirm that a removed user cannot access content through cached links or previously downloaded pages.
5. Verify that watermarks appear with the test account's identity and that the watermark survives print and export where those options are allowed.
6. Export the audit log and confirm that each test action appears with the correct outcome.
7. Record the results, the platform version, and the date, and repeat the test after major changes or before a new phase begins.

Testing is not a one-time event. Vendors update their software, and configuration changes can have unexpected effects. A recurring test cycle, tied to the process timetable, is a sound practice.