An external lab needs a login on Monday. Your quality manager needs the full batch record, though not what the material cost. Someone left in March, and nobody is certain their access ended.
Three ordinary requests, and one question underneath all of them. Who should be able to see what, and can you show that it held?
The second half is the expensive one. When somebody asks who could have opened a record last spring, and assembling the answer takes three days, the cost is not the permission that was wrong. It is the three days, and the doubt that follows them.
This guide covers the six decisions behind user permissions, what to ask a vendor about each one, and a worked example built around that external lab.
What are user permissions?
User permissions decide which people can open, change or download which information, and the system enforces them rather than a policy document does. It covers whole areas of work, individual records and single pieces of information on a record. In regulated work it also has to be demonstrable afterwards, not merely present.
That last part is what separates it from ordinary business software. Most business software has permissions of some kind. The harder question is what they were on a particular day a year ago, and that is the version an auditor tends to ask. It is worth establishing early which one a platform can answer.
What are you actually deciding when you set up user permissions?
Six things, and each one narrows what the previous one allowed. A person's real user permissions are what survives all six. Which of them you need follows from what your own work and your own obligations require, so the assessment comes before the configuration.
| The decision | What it settles | A typical use |
| Who administers | Who configures the system, and who only uses it | Separating the people who build from the people who work |
| Which group they belong to | Their department, employer or project team | Quality, finance, an outside laboratory |
| Which applications they open | Whole areas of work | Keeping finance out of study data entirely |
| Which kinds of record | Types of record inside an application | Inspections, but not investigations |
| Which specific records | One site, one client, one study | A contract lab sees only its own samples |
| Which fields on the record | Individual pieces of information | Hiding cost from a supplier who can see the rest |
The first three describe the shape of the organization: who configures, who belongs where, and which areas of work are open to them. The last three describe the shape of the data: which kinds of record, which particular records, and which pieces of information on them. Knowing which obligations name something specific is what tells you how far down the list to read.
The two decisions that matter the most
Group membership does more work than anything else on the list. Attach access to a group rather than to individuals and every arrival becomes one action with a known outcome. Attach it to individuals and you are making a fresh decision every time somebody joins, moves or leaves, with nobody reviewing the pattern.
A quick test. Could you explain your access model to a new colleague in five minutes? If the explanation involves naming people, it lives in individuals rather than in groups, and it is worth moving.
The field decision is the other one worth understanding, because it does something most people do not expect. A field can be set to accept one entry and then become read only. That is what makes a signed result or a recorded approval mean something, because the value stops being editable once it is recorded.
Those rules can also follow the record's status rather than waiting for a person to remember. A result locks the moment quality releases the batch. No separate process has to chase it.
Does the rule hold everywhere, or only on screen?
Ask every vendor this one, because it is where platforms genuinely differ and the answer is easy to test. A field someone is not permitted to see should also be missing from their exports and their reports, not only from the page in front of them.
A restricted value that vanishes from the screen and reappears in a downloaded file was never really restricted. It left the building; it just left through a side door. It is quick to check with a test account, and it is worth doing before a purchase rather than after.
Both the access control requirements in NIST SP 800-53 and the access management provisions of the HIPAA Security Rule include controls the system applies, not only procedures people follow. The distinction sounds academic until somebody tests it.
What should you ask a vendor about access?
Five questions. Each one has a clear answer, so an evasive response is itself informative.
- Can you hide a single field from one group while everyone else still sees it? This separates platforms that control whole records from platforms that control what is on them, and it is the difference that matters when an obligation names something specific.
- Is that field also absent from an export? Ask for a demonstration rather than an assurance. It takes a test account.
- Can a field lock itself once a record reaches a certain status, without anybody remembering to do it? Anything that depends on a person remembering will eventually meet a person who did not.
- How do I remove someone's access, and when does it take effect? The useful answer is on their next action. Ask when a removal takes effect, and ask the vendor to show you rather than describe it.
- What can you show me about past access, and over what period? Not what the settings are today, which is the easy question, but what they were then. Almost every difficulty in this area is a version of that one.
Write the answers down while you are still comparing. Six months into an implementation nobody remembers which vendor said what, and by then the answer has become your problem rather than theirs.
A worked example, one batch record
Back to that external laboratory. A batch record shared between manufacturing, quality and an outside testing lab, with three groups, three different needs and one record between them.
Manufacturing needs the full record while the batch is in process. Quality needs the same record plus the disposition, and needs the manufacturing entries locked once submitted. The external laboratory needs only its own samples, with no sight of cost, other clients or internal commentary.
Built through the six decisions, that becomes three groups, one application open to all three, a rule limiting the laboratory to its own samples, cost hidden from the laboratory entirely, and manufacturing entries that lock on submission. All of that is configuration inside the platform.
Now change one thing. A second laboratory joins for a specific set of samples. That is one new group and one new rule, and nothing about the first laboratory moves. The separation holds because you drew it once rather than maintaining it by hand every month.
Where user permissions quietly go wrong and what to do about it
Three things come up repeatedly, and none of them is a flaw in any particular product. Each is a place where a little deliberate effort pays back, so each one below comes with the fix.
- A mistake makes no noise. Set a permission too broadly and nothing breaks, nobody complains, and the work carries on. A silent mistake is not one your own monitoring will surface. The fix is to check rather than wait to be told. After setting up a group, sign in once as somebody in it and confirm you see what you expected.
- The answer lives in more than one place. Somebody asks why a particular person can see a particular thing, and six decisions means six settings to look at. The fix costs a few minutes. Keep a short note beside the configuration saying what each group is meant to see, and what it is not.
- Access accumulates unless somebody removes it. Permissions start tight, then loosen through exceptions, each granted for a good reason on the day. The fix is to design roles first and place people into them. A new arrival then becomes one action rather than a fresh decision. Our guide to role-based access control covers that design work.
Underneath all three sits one habit: treating access as something designed rather than something accumulated. That is the same argument we make about compliance being built in rather than added. Checking that it still holds is the other half, and we take that up on Thursday in our piece on running a user access review.
What does this cost you to run?
Less than you might expect, provided the design happens once. A model built on groups costs a few minutes per new starter and very little afterwards. A model built on individuals costs a decision every time anybody joins, moves or leaves, and those decisions are made quickly by whoever is nearest.
The larger cost is the one nobody budgets for, which is reconstruction. Somebody asks a question about last year, the answer is not readily available, and a capable person spends days assembling it from whatever can be found. How often that happens depends on your regulator and your luck. What it costs when it does is the same either way, and it is largely avoidable.
So the useful comparison is not the price of the software against the price of a spreadsheet. It is the cost of designing this properly once against the cost of answering the same question from scratch every time somebody asks.
How far down should you actually go?
Start from the obligation rather than from the settings screen. Write down what you must be able to control, and in what terms your regulator, your client or your own policy expresses it. That list tells you which of the six decisions you are actually making.
An obligation phrased in terms of departments points at groups and applications. One phrased in terms of a site, a client or a study points at record-level rules. One that names a particular piece of information, such as cost, personal data or a signature, points at the field level. The wording of the requirement is usually a reliable guide to the layer that satisfies it.
Then write down why each rule exists. The system records what your user permissions are and does that reliably. It cannot record why you chose it, and why is the question that arrives two years later from somebody who was not in the room.
If you want to walk through how your own obligations map onto these six decisions, talk to an expert. It is a more useful conversation with your actual boundaries in front of us. For the wider picture of governing data across a system, our overview of data access control is a good companion, and guidance from the Canadian Centre for Cyber Security is a readable starting point for anyone building the case internally.
