NetDocuments security permissions decide who can view, edit, share, and administer every document, folder, and workspace in a cabinet. They are set in three layers: a cabinet default for each user group, an access list on each item, and profile-based security that assigns rights from matter or client values.
What are NetDocuments security permissions?
NetDocuments security permissions are the access rights that control what each user or group can do with items in a cabinet, expressed as combinations of View, Edit, Share, and Administer. Getting them wrong is costly, since the 2026 edition of a long-running global study puts the average cost of a data breach at $4.99 million, a record high. Every document, folder, saved search, and workspace carries its own access list, and those lists are populated from the cabinet default, from folder inheritance, or from profile-based security.
The stakes are real. Permissions limit the damage a stolen login can do, and an analysis of 12,195 confirmed breaches found credential abuse was the most common way attackers got in, at 22 percent. Well-designed permissions limit how much a compromised account or a misdirected invitation can open.
The design question is which groups should see which matters by default, and which matters need a wall. Those answers belong in the design phase of a NetDocuments rollout, where cabinets, profiles, and workspace structure are settled before documents move.
What do the NetDocuments cabinet access levels mean?
NetDocuments cabinet access levels define the default rights a user group has over items added to the cabinet by other people. NetDocuments offers six cabinet settings and recommends No Default Access for external groups when a cabinet uses workspaces.
- VESA. The group can view, edit, share, and administer items, which includes deleting them and changing their access lists.
- VES. The group can view, edit, and share, but cannot delete documents.
- VE. The group can view and edit, but cannot share or delete items added by others.
- VS and V. VS allows viewing and sharing without editing. V is read-only.
- No Default Access. The group belongs to the cabinet and can add documents, but sees nothing created by others until someone grants explicit rights.
A user who imports a document also receives VESA on that document. A workspace gives no individual VESA automatically and inherits rights from the cabinet or from profile-based security.
How do NetDocuments rights combine across user groups?
NetDocuments rights combine cumulatively across user groups, so a user who belongs to several groups receives the combined total of their rights. A user with V through one group and VES through another has VES in that cabinet. No Access is the one exception: when a user or group is set to No Access on an item, it overrides every other right that user holds through any group.
With 15 or 20 user groups in a cabinet, one broad group (such as “All Legal”) can quietly grant access a narrower matter team was meant to hold alone. Map group membership before you assign rights, and use No Access deliberately for ethical walls.
How does NetDocuments profile-based security work?
NetDocuments profile-based security (PBS) assigns access rights from the value of a profile attribute, usually the matter or client, through an access column on that attribute’s lookup table. Any document profiled to that matter picks up the rights written against the matter row.
- The attribute. An administrator enables “Base Security on this Attribute” on the matter (or client, or department) attribute in the cabinet’s profile settings.
- The access string. Each lookup row carries a string such as `Litigation|VES*Estate|V`, where each group or user is paired with a right and entries are separated by asterisks. Individual users are written with a `U:` prefix and their login email. The access level must be uppercase.
- No Access. Writing `N` against a group or user removes their access to that matter’s documents, and it overrides rights they hold elsewhere.
PBS suits a legal department with hundreds or thousands of matters: you maintain one string per matter, and the platform applies it to every document profiled there.
What is the difference between additive and absolute security in NetDocuments?
Additive security in NetDocuments adds the PBS rights to whatever access an item already has, while absolute security replaces the existing access with the PBS string. Additive is the default behavior; absolute is switched on per lookup row.
Under additive security, the matter string is layered on top of the cabinet default, so everyone who could see the document before still can, plus the groups named in the string. Placing an exclamation mark at the start of the row, as in `!Finance|VES*Legal|V`, makes it absolute: the cabinet default is discarded and only the string applies. The exclamation mark governs the entire entry, so every group and user in that row is affected.
Absolute security is how you build a restricted matter for confidential work such as an internal investigation or an M&A project. Before you mark a row absolute, confirm that the string names every group that still needs access, including administrators and records staff.
Does NetDocuments profile-based security apply to existing documents?
NetDocuments profile-based security applies to items profiled after the setting is in place, so documents, folders, and workspaces that already exist keep their previous access until someone updates them.
Bringing existing content into line is a separate piece of work. It typically means applying the string to the matter, running an advanced search on that matter value, using a mass access change on the results, and updating the workspace’s own access list. NetDocuments’ mass access change handles up to 10,000 documents per run, so a large matter may take several passes.
The same gap appears in every migration. Documents moved from iManage arrive carrying whatever security the legacy system held, and rushing a legacy data migration leaves costs that surface long after go-live. Poor data migration and inadequate training are among the usual causes of failed legal technology implementations. Decide the PBS model first, then migrate into it.
How should external users get access in NetDocuments?
External users in NetDocuments should reach content through explicit grants on a workspace or its documents, because external groups join a cabinet with No Default Access and cannot inherit access by design. Outside counsel, clients, and other third parties then see only what someone has deliberately shared.
- Workspace grants. Add the external group to the specific workspace with the right it needs (V, VS, VE, VES, or VESA), then grant access to the workspace’s documents with a mass access change on the matter’s results list.
- CollabSpaces. In a CollabSpace-enabled cabinet, external groups are capped at No Default Access, workspaces are hidden from external users, and sharing happens inside CollabSpaces. Any user with VES rights on a workspace can enable the CollabSpaces tab.
- Revocation. Remove the external group from each workspace the day an engagement ends. Outside counsel onboarding runs as a workstream with its own owner and checklist, and offboarding belongs on that checklist.
How do secure links control document sharing in NetDocuments?
Secure links in NetDocuments deliver a single document to someone outside the cabinet through a URL that can carry a password, a download restriction, and an expiration date. They suit a one-off send, such as a signed agreement to a counterparty.
- Password. Senders can protect a link with a password, and cabinet administrators can require a password on every secured link in the cabinet.
- Download control. Senders can allow or block downloading, and administrators can switch downloading off by default.
- Expiration and revocation. Links can expire automatically, administrators can set a maximum expiration period, and a sender can revoke every link delivered for a version at once.
NetDocuments also offers Data Loss Prevention controls for organizations that need to govern which sharing actions are allowed at all. For most legal departments, a required password and a maximum expiration of 30 to 90 days is a sensible cabinet baseline.
How should you test NetDocuments security permissions before go-live?
NetDocuments security permissions should be tested with named test users in every group, against real matter types, before the cabinet opens to the business.
- Role matrix. Build a matrix of 8 to 12 test users covering each group, then check view, edit, share, and delete on a sample of matters.
- Restricted matters. Test every absolute PBS row with a user who should be excluded, and confirm they cannot find the matter’s documents through search.
- Production check. Configuration proven in a sandbox still needs verification once it reaches production, so repeat a subset of the matrix after deployment.
Record each result against the user, matter, and expected right. That record is your evidence when auditors ask how access is controlled.
Conclusion
NetDocuments security permissions work reliably when the three layers are designed together: cabinet defaults that reflect group roles, profile-based security that carries matter-level rules, and absolute rows reserved for the matters that need a wall. The real work sits in group design, in bringing existing documents into line after every change, and in testing with real users before go-live.
How Basla can help
Basla provides certified delivery team members for NetDocuments implementation, including business analysts who design the group and PBS model with your legal and IT stakeholders, and QA analysts who build and run role-based security test matrices across real matter types. Basla’s documentation writers produce the security design specification and administrator guides that keep access rules maintainable after go-live.
Basla delivers legal technology services through staff augmentation or Basla-managed delivery. On other legal platform programs, Basla has created and executed more than 1,000 test records for a CLM rollout and doubled delivery team capacity to meet compressed implementation timelines.
Frequently asked questions
What are NetDocuments security permissions?
NetDocuments security permissions are the View, Edit, Share, and Administer rights that control what each user or group can do with documents, folders, and workspaces. They come from cabinet defaults, item access lists, and profile-based security.
What is No Default Access in NetDocuments?
No Default Access in NetDocuments lets a group join a cabinet and add documents without seeing anything created by others. It is the default and recommended setting for external groups when a cabinet uses workspaces.
What does the exclamation mark mean in NetDocuments profile-based security?
The exclamation mark in NetDocuments profile-based security makes a lookup row absolute, so its access string replaces existing access. It applies to every group and user in that row.
Does changing profile-based security update existing NetDocuments documents?
Changing profile-based security in NetDocuments affects items profiled after the change. Existing documents, folders, and workspaces need a separate access update, usually a search followed by a mass access change.
How do NetDocuments rights combine when a user is in several groups?
NetDocuments rights combine cumulatively across groups, so a user receives the total of all their group rights. No Access is the exception and overrides every other right on that item.
Can external users inherit access in NetDocuments?
External users cannot inherit access in NetDocuments by design. They receive access only through explicit grants on a workspace, a folder, a document, or a CollabSpace.
*This article is provided for general information only and does not constitute legal advice. Basla Solutions provides legal technology implementation and support services and does not practice law.*

