SecuritySecurityCompliance

Data Room Permissions and Access Control Explained

Permissions are the part of a data room that nobody notices when they are set up well and everybody notices when they are not. I have run diligence on both sides of the table, and the difference betwe

By Rohan Nayak13 min readUpdated July 2026
Data Room Permissions and Access Control Explained
On this page

Permissions are the part of a data room that nobody notices when they are set up well and everybody notices when they are not. I have run diligence on both sides of the table, and the difference between a room that feels trustworthy and one that feels leaky comes down to a handful of access decisions made in the first hour. Who can see what. Who can download what. Who gets watched, and who gets blocked. Get those right and the room runs itself. Get them wrong and you spend the next three weeks fielding "I can't find the file" emails, or worse, discovering that a sensitive contract was forwarded to someone who was never supposed to see it.

This is a practical explainer of how data room permissions actually work: the roles, the permission levels, fence view, audit trails, and link controls. I will tie it to how I set things up in Plox data rooms, because that is the tool I run my own rooms in, but the underlying concepts map onto any serious virtual data room.

Why permissions are the whole point of a data room

You can store documents in a shared cloud folder for free. What you cannot do in a shared folder is grant one named person access to exactly one file, watch them open it, stop them downloading it, and revoke them the day the deal dies, all while keeping a tamper-evident record of every action. That bundle of controls is the reason data rooms exist as a category instead of just being a folder with a link.

So when people ask what data room permissions are, the honest answer is that they are the access-control layer that turns a pile of confidential files into a system you can defend in front of a lawyer, a board, or a regulator. Everything else in the product, the structure, the Q&A, the analytics, sits on top of that layer.

The roles: who gets to do what

Almost every data room sorts people into a small set of roles. The labels vary between products, but the shape is consistent. I think about it as three buckets.

RoleTypical abilitiesWho it is for
Administrator / ownerFull control: invite users, set permissions, upload, delete, see the audit log, manage billingYou and your deal lead
Editor / contributorUpload and organize documents, sometimes manage Q&A, no permission controlYour lawyer, your CFO, internal team
Viewer / guestView only, within the permissions granted to them, no upload, no adminInvestors, buyers, their advisers

The mistake I see most often is collapsing these into too few roles. A founder gives their lawyer admin rights "to make it easier," and now a third party can change who sees the cap table. Keep the administrator role to the smallest possible circle, usually just you and one other person. Everyone external should be a viewer with deliberately scoped access, never an editor.

Inside the viewer bucket, real control comes from grouping. Rather than setting permissions person by person, I create groups: "Lead investor," "Co-investors," "Buyer legal," "Buyer commercial." Each group gets a permission profile, and adding a new reviewer is then a one-click decision about which group they belong to. This matters more than it sounds, because the failure mode in diligence is not the permission you set, it is the permission you forgot to set when a fourth lawyer joined on a Friday afternoon.

Permission levels: from view-only to full download

Roles decide what a person can do in the room. Permission levels decide what they can do with a specific document or folder. These are stackable, and good rooms let you set them per folder or per file.

The common levels, from most restrictive to least:

  • No access. The document is invisible. The reviewer does not know it exists. This is the correct default for anything not yet ready to share.
  • Fence view only. The reviewer can read the document inside the browser, but a digital fence (more on this below) blurs everything outside a moving focus area, making it unreadable in a screenshot or photo.
  • View only. The document renders in the browser. No download, no print, no copy. The reviewer can read it but cannot take a copy away.
  • View and print. Adds controlled printing, usually with a watermark baked into the output.
  • Download with watermark. The reviewer gets a file, but every page carries a dynamic watermark stamping their name, email, and the timestamp.
  • Download original. The unmodified file. Reserved for documents you are genuinely comfortable leaving the room, and for people you trust completely.

I treat this list as a ladder and I climb it reluctantly. Most documents in a live raise sit at view only or watermarked download. The cap table, the customer contracts, and anything with personal data start at fence view or view only and move up only when there is a reason. Defaulting to the restrictive end and loosening deliberately is the single habit that prevents the worst data room mistakes.

A watermark, by the way, does not technically stop a determined leaker, and I would never claim it does. What it does is change behavior. When someone's own name and email is stamped across every page, the casual forward to a colleague stops happening, because the document now points back at them. That deterrent is the real value, and it is why dynamic watermarking belongs on every sensitive file rather than just the most secret ones.

Fence view, explained

Fence view (sometimes called secure view or a screen shield) is the control people understand least and underrate most. Here is what it does in plain terms.

When a document is open under fence view, only a small band of the page is sharp at any moment. The rest is blurred. As the reader moves their cursor or eyes down the page, the sharp band follows. A human reading naturally can take in the content fine. But a screenshot, a phone photo of the screen, or a screen recording captures mostly blur, because only a fraction of the page is legible in any single frame.

I reach for fence view when a document is too sensitive to download but still has to be read by an outside party. The classic case is a term sheet or a key customer contract during a competitive process, where you want a rival investor or acquirer to be able to evaluate it but not to walk away with a clean copy. It is also the control I lean on for anything containing personal data, which connects directly to the obligations I cover in HIPAA compliant document sharing, where the goal is to let an authorized person read without ever creating an uncontrolled copy.

Fence view is not a fit for everything. It slows reading down, so I never apply it to the bulk of the room. I reserve it for the handful of documents where the cost of a leak is high enough to justify the friction.

Audit trails: the record that makes permissions enforceable

Permissions decide who can do what. The audit trail records what they actually did. Without it, your access controls are a promise. With it, they are evidence.

A proper audit log captures, at minimum:

  • Every login, with the user, time, and often the IP or location.
  • Every document opened, by whom, and for how long.
  • Every download and print, tied to a named person.
  • Every permission change, so you can prove who granted access to what and when.

This record does two jobs. The obvious one is forensic: if a document leaks, the log narrows the field to people who actually opened it, and combined with watermarking it usually points at one person. The less obvious job is informational, and during a live deal it is the one I use daily. When I can see that the lead investor spent forty minutes in the financial model and keeps reopening the customer concentration tab, I know what the next call is going to be about before they do. The audit trail is a permission-enforcement tool and a deal-intelligence tool at the same time.

The discipline here is to actually read it. A log nobody looks at is just storage. I check the room's activity at least once a day during an active process, watching for two things: who has gone quiet (a stalling reviewer) and who is moving faster than expected (a buyer about to make an offer).

Most rooms let you share either by inviting named users or by generating a link. Link controls are the settings that keep a shared link from becoming an open door.

The controls I always set on any link:

ControlWhat it doesWhen I use it
Email verificationRecipient must confirm a code sent to their address before viewingAlways, for anything non-public
Expiry dateLink stops working after a set dateTeasers, time-boxed reviews
Download toggleAllows or blocks downloading through the linkOff by default
WatermarkingStamps the viewer's details on every pageOn for any sensitive file
PasscodeAdds a shared secret on top of the linkBroad distributions like a deck
Instant revokeKills the link immediatelyThe moment a deal dies or a person leaves

The two controls that matter most are email verification and instant revoke. Email verification means a forwarded link is useless to whoever it was forwarded to, because they cannot pass the verification step. Instant revoke means the day a process ends, you close the door in one click rather than hoping nobody kept a copy of the URL. Together they turn a link from a liability into a controlled channel. The same principles underpin granular document control, which is really just link and permission control applied at the level of the individual file.

A permissions setup checklist

This is the order I work through when I open a new room. It takes about fifteen minutes and saves days.

  • Set every new document to private by default, not shared.
  • Create groups (lead, co-investors, buyer legal, buyer commercial) before inviting anyone.
  • Assign each group a permission profile, not each person.
  • Keep the administrator role to two people at most.
  • Put anything with personal data or competitive value on fence view or view only.
  • Enable dynamic watermarking on every sensitive file.
  • Turn off original-file download except where you genuinely accept the file leaving.
  • Require email verification on every share link.
  • Set expiry dates on time-boxed access.
  • Confirm the audit log is on and decide who reviews it daily.
  • Document your revoke plan: when the deal ends, what gets killed and by whom.

Best practices I would not skip

A few habits separate rooms that hold together from rooms that leak.

Default to closed. Share deliberately, document by document, rather than opening the whole room and trimming back. Every painful permissions story I know started with someone being granted more than they needed.

Match the control to the sensitivity, not the other way around. Fence view on the office lease is theatre. View-only download blocking on the cap table is sensible. Spend your friction budget where a leak would actually hurt.

Revoke on a schedule, not on a feeling. The day a deal dies, revoke that party's access the same day. The most common stale-permission problem is the investor who passed in March still having access in September because nobody closed the door.

Review the audit log as a routine, not after a scare. The log only protects you if you read it. Build a daily glance into your process during any live deal.

Use groups so onboarding is a decision, not a configuration. When a new reviewer joins, you should be choosing a group, not rebuilding a permission set from scratch and hoping you got it right.

Frequently asked questions

What is the difference between a role and a permission level in a data room?

A role describes what a person can do across the whole room: an administrator can invite users and set permissions, an editor can upload, a viewer can only read what they are shown. A permission level describes what a person can do with a specific document or folder: no access, fence view, view only, view and print, watermarked download, or original download. You assign a role once and then layer document-level permissions on top of it.

Can a data room stop someone from downloading or copying a document?

It can stop the easy paths and deter the hard ones. View-only permission blocks downloading, printing, and copying through the room itself. Fence view defeats screenshots and screen recordings by keeping only a small band of the page sharp at a time. What no software can fully prevent is someone retyping a document by hand or photographing a screen frame by frame, so dynamic watermarking is layered on to make any leaked copy trace back to the person who took it. The combination changes behavior even where it cannot guarantee a technical block.

What should an audit trail record?

At a minimum it should log every login with user and time, every document opened and for how long, every download and print tied to a named person, and every permission change. Good audit trails also capture IP or location and let you export the whole record. The point is to be able to answer "who saw this, when, and what did they do with it" without having to take anyone's word for it.

The two controls that do the heavy lifting are email verification, which forces the viewer to confirm a code sent to their address so a forwarded link is useless to the wrong recipient, and instant revoke, which kills a link the moment a deal ends. Around those, expiry dates, passcodes, download toggles, and watermarking let you tune how open or locked a given link is. Set conservatively, a link becomes a controlled channel rather than an open door.

Are these permission features specific to one product?

No. Roles, permission levels, fence view, audit trails, and link controls are standard across serious virtual data rooms, though the labels and the depth of control differ. I set mine up in Plox data rooms because the controls are granular and quick to configure, but the principles in this guide, defaulting to closed, grouping users, matching control to sensitivity, and reviewing the audit log daily, apply whichever room you run your deal in.

Rohan Nayak

Written by Rohan Nayak · Co-founder, Plox

Rohan co-founded Plox. He spends most of his time with founders working out how to share a deck or a data room without losing control of it.

Connect on LinkedIn