Document access control in a regulated library looks like a configuration problem and is really an enforcement problem.
Nearly every serious system lets an administrator define roles, write rules that narrow a role to part of the library, and set out what each role may do at each stage of a document’s life. That part is well understood and it demonstrates beautifully.
The harder question — and the one worth spending your evaluation time on — is whether all that configuration is actually consulted, everywhere, including on the screens nobody thought about.
Three questions, all answered from your configuration
DnXT’s Security Manager asks three things every time somebody touches a document:
- Does a role this person holds allow this action at all?
- Do that role’s rules reach this particular document?
- Is this action allowed at the document’s current stage?
Each one can only ever narrow access. What an administrator has not configured restricts nobody.
That property matters more than it sounds. It means adding a rule can only reduce what people can reach — so nobody has to hold the entire configuration in their head to predict what one change will do. Systems where a new rule can accidentally widen access are systems that get frozen after the first surprise.
The three things that most often go wrong
These are worth checking in any system you are evaluating, or already running.
1. What happens when the permission check itself fails?
The most dangerous thing in any permissions system is error handling that allows the action when something goes wrong. It turns every technical problem — a timeout, a misconfiguration, a service being briefly unavailable — into a silent grant of access. And unlike a refusal, it generates no complaints, so nobody ever finds out.
Ask what happens when the part of the system that makes the decision cannot be reached. “It refuses” is the only acceptable answer.
2. Is the check applied in one place, or screen by screen?
DnXT checks permissions centrally, on every request that touches a document — including simply viewing one.
There are dozens of ways to touch a document, and more arrive with every release. Checking inside each screen makes your coverage only as good as the last person to remember, and the one that gets forgotten is invisible from the outside: it works perfectly, for everybody, which is exactly what a missing check looks like.
Checking centrally inverts the default. A new capability is protected because it exists, and a developer has to deliberately exempt something rather than deliberately remember to protect it. The consequence of forgetting becomes “too strict”, which somebody reports on day one, instead of “too permissive”, which surfaces at audit.
3. Do lists and searches ask a narrower question, or hide results afterwards?
Document lists, folder views and search have to ask a narrower question in the first place, rather than fetching everything and hiding what you may not see. Two reasons, and the second is the serious one.
Page counts stop making sense. Fetch fifty documents, hide the twelve this person may not see, and you show thirty-eight on a page that claims fifty, with a wrong total and documents silently skipped between pages. Users notice this and cannot describe it, which makes it an expensive support burden.
Search gives things away simply by finding them. A search result tells you a document exists and usually tells you what it is — its title, its type, often a line of its content. Hiding results after the search has already found them means the disclosure has already happened; you are only declining to display it. For a library that may hold unannounced products, partner-confidential content or safety information, the existence of a document is frequently the sensitive part.
Hiding search results afterwards is not access control. It is a curtain in front of an answer that has already been given.
The rollout mode that makes this safe to adopt
Of everything here, the setting that changes nothing is what makes the rest deployable.
In monitoring mode, every decision is worked out and recorded, and nobody is refused anything.
The reason is a specific and entirely predictable problem. Once rules are switched on, somebody who has not been given a role can see nothing. That is correct behaviour — and it is overwhelmingly the likeliest way a rollout goes wrong, because organisations discover their role assignments are incomplete precisely when being incomplete starts having consequences.
Monitoring mode gives you a window to find those people in a report rather than in a queue of angry tickets. Run it for a week, review what would have been refused, fix the assignments, then switch enforcement on. The alternative is discovering the gaps through a Monday morning of people unable to do their jobs.
Any access control capability going into an existing library should offer this, and its absence is a reasonable thing to push back on.
Opt-in, with a safeguard you cannot lock yourself out of
Enforcement is switched on per workspace. A workspace where nobody has been given a role has not adopted it, and its library carries on as before.
Administrators are exempt before any rules are read. Not a convenience — the safeguard against an administrator writing rules that exclude themselves and then having no way back in.
A short evaluation checklist
- Ask what happens when the permission check cannot run. Does it refuse, or does it allow?
- Ask where the check happens. Centrally on every request, or separately on each screen?
- Ask whether search asks a narrower question or hides results afterwards. If it hides them, the search has already given the answer away.
- Ask whether there is a monitoring mode. If not, plan the rollout as an outage.
- Then test it. Create a user with no role and open the library. What they can see is the real answer.
DnXT builds eCTD publishing, submission planning, document management and dossier review software for regulatory operations teams. Book a demo to see access control applied everywhere, including simply viewing a document against your own submissions.
