If you’ve built a NetDocuments ethical wall in Workspace Security Manager, secured every matter on the list, and then discovered that the matter opened last Tuesday is sitting there wide open, you’re not alone. The wall you built is working exactly as designed. The problem is that it’s only half the job.
There Are Two Ways to Build an Ethical Wall
Most firms only know about one of them.
Workspace Security Manager (WSM) is the newer tool that everybody reaches for. You point it at the matters you want walled off, apply the policy, and everything that already exists gets locked down — the Workspace, the folders, the filters, and every document already sitting in those matters. That retroactive sweep is the whole reason WSM is good.
Profile-Based Security (PBS) came first. It predates WSM entirely, and it works at a higher level: you assign a security string to the Access field of a Profile Attribute value, and anything filed against that value inherits the restriction.
Each one has exactly the gap the other one covers.
WSM secures what exists on the day you run it and nothing after. PBS secures what gets created after you write the string and nothing before. Set up a security string on a client that already has ten years of matters under it, and none of those matters change — you’d be going back through every matter, folder, filter, and document, applying it by hand.
So when I know a firm needs to wall off a client, I use both. WSM for the back catalog, PBS for everything that comes next. Neither one on its own gets you all the way there.
Why the WSM-Only Approach Leaves a Hole
WSM secures matters. That’s the whole scope of it.
What it will not let you do is secure a client.
So, the day you run it, everything is correct. All existing matters for that client are protected. Then the intake team opens a new matter under the same client next week, and that matter has no policy on it at all. Open the matter in WSM, and you’ll see nothing under the matter access section. Nothing applied, nothing inherited.
If WSM is the only tool you’re using, the remedy is for someone to go back in and add the policy every single time a matter is created. In a firm, opening a handful of matters a week, that lasts about a month before somebody forgets — and the one they forget is the one that matters.
Why This Is a Real Risk, Not a Housekeeping Item
An ethical wall isn’t a preference. It’s usually there because a lateral hire brought a conflict with them, or because the firm is on both sides of a related matter and the wall is what makes the engagement defensible.
A wall with a gap is worse than no wall because the firm believes it’s protected. Nobody audits a control they think is already on.
The Fix: Add a Profile-Based Security String to the Client
You can’t set client-level security in WSM, but you can set it with PBS. Assigning a security string to the Access field of the Client value pushes the restriction down to everything filed under that client — every matter, every Workspace, every folder, every document, including the ones that don’t exist yet.
Here’s the combination I use.
Step 1: Build the Ethical Wall in Workspace Security Manager
Create the group of users who need to be blocked and apply the wall to the matters the firm has identified. Do this part first. WSM is the only one of the two tools that looks backward, and it applies across every matter, folder, filter, and document already in place—which is exactly what you need on day one.
Step 2: Confirm the Existing Matters Are Secured
Spot-check a few. Open the matter that was in scope, check matter access, and confirm the group is listed. My rule of thumb is to pick five random matters rather than the first five on the list — the first five are always the ones that worked.
Step 3: Open the Client Profile Attribute Table
Go to the Admin Console → the Cabinet → Profile Attributes, and open the Client attribute table. This is the lookup table behind the Client field on every profile in the Cabinet, and it’s where Profile-Based Security is applied.
Step 4: Write the Security String Into the Client’s Access Field
Find the client and add a security string to its Access field, giving the same group you used in WSM no access. You’re securing the client value itself, not any one matter under it.
Step 5: Create a Test Matter and Verify
Don’t take my word for it, and don’t take the console’s word for it either. Create a throwaway matter under that client, save a document into it, and check the result.
Open the matter, and you’ll see no ethical wall on it. That’s expected. Now open the document, go to More → Modify Access, and the ethical wall is right there. Check the Workspace, and it’s secured too.
Why This Works: No Access Always Trumps
Security in NetDocuments is cumulative in one direction only. A user can gain access from several places — cabinet membership, group membership, or a Workspace they were added to — but a no-access entry overrides all of it.
That’s the mechanism doing the work here. The people you blocked may well be members of the default Workspace Cabinet, and under normal circumstances, they’d see the new matter the moment it was created. The no-access entry on the client value overrides that membership before it ever becomes a problem.
What You Won’t See in Workspace Security Manager
One caveat worth writing down for whoever inherits this configuration: new matters secured this way will not show an ethical wall in WSM. Open one, and the matter access looks empty.
It isn’t. The restriction is coming from the security string on the Client Profile Attribute, and WSM only reports on what it applies itself. If someone on your team goes looking six months from now and concludes the wall was never set up, they’ll “fix” it by removing something that was never broken.
Document it. Note in the firm’s security documentation that the wall for that client is enforced through Profile-Based Security and that WSM will not display it.
The Result
Two tools, two halves of the timeline:
- Workspace Security Manager – reaches backward. Secures every matter, folder, filter, and document that already exists, in bulk, on the day you set up the wall.
- Profile-Based Security on the Client – reaches forward. Secures everything created under that client from that day on, with nobody having to remember anything.
Run one without the other, and you have a wall with a hole in it. The only question is whether the hole is in the past or the future.
No one has to add a policy when creating a matter. No one has to audit last week’s intake. Every matter opened under that client is walled off the moment it exists, and every document saved into it inherits the restriction.
Need Help?
Ethical walls are one configuration where being 95% right is equivalent to being wrong, and the gap is usually not visible from the console. If your firm has walls in place and you’re not certain new matters are landing behind them, we can review both halves of the setup and test it against a live matter — usually in a single call.
Schedule a free consultation at go.oncehub.com/optconsult.
Optiable has guided over 550 law firms through NetDocuments implementations since 2010, specializing in firms with 10 to 150 users.
CONNECT WITH CRAIG → https://www.linkedin.com/in/craigbayer/