The Permission Nobody Asked For
A role granted just for now and never removed. Why over-broad access costs you the audit trail rather than the feature, what to review, on what cadence, and who should own it.
Someone needed to see one customer for ten minutes on a Friday, so somebody opened the permissions screen and granted a role that lets them see everything. It was meant to be temporary. Nobody recorded a date, nobody told the person it was temporary, and nobody added it to any list. Four months later the access is still on, the person has long since forgotten why they have it, and the business has a problem that is not really about security: it can no longer produce the audit trail it would need to answer a simple question about its own records.
That is the part worth dwelling on. Over-broad access is usually discussed as a security risk, and it is one. But for a small business the first thing to break is narrower and more immediate — the ability to say who could have done what. Once four people can cancel an invoice, that question has no answer, and the answer was more valuable than the convenience the access bought.
"Just for now" has no expiry date
The granting of temporary access is a decision made in a hurry, and hurried decisions have two properties that matter here. They are usually generous, because the person granting access is solving the problem in front of them and not the one that might appear later. And they are almost never annotated, because the person granting access expects the situation to resolve itself within days, and writing "temporary, until the 8th" in a notes field while standing at a counter feels like an unnecessary act of paperwork.
The result is a permission with no end date attached to a person who is not the person who granted it. Both halves of that sentence matter. The first means the access does not end. The second means nobody is looking out for it: the grantor has moved on, the recipient does not know it was a favour rather than a role, and the only moment at which anybody would notice is a review that nobody scheduled.
Worked example, constructed for this article — the arithmetic.
A counter employee is granted full billing access on 4 August so that she can settle a customer query while the owner is travelling. The stated intention is two days.
Access is still in place when the owner returns, in late October. Working days from 4 August to the review:
- August: 31 − 4 = 27 remaining working days in the month, of which not all are working days; counting calendar days to keep the arithmetic simple and checkable, 4 August to 4 October is 27 + 30 + 31 = 88 days
- Add the 3 days to reach the review date in early October: 88 + 3 = 91 days
- Days beyond the two-day intention: 91 − 2 = 89 days
So the access ran roughly 45 times longer than it was meant to, with no end date and no reminder, because nothing in the system knew there had been an intention. That is the whole mechanism: an intention that lives only in the head of the person who granted the access is not a control, and it cannot expire.
Everything is the easy answer
There is a second reason the grant is generous, and it is not laziness. Narrowing a role requires knowing what the person actually needs, and that is a question nobody has answered. "Can see one customer's invoices" is a need. "Billing access" is the closest available answer in most permission screens, and it is much easier to grant. The person granting it is not being careless; they are working with the vocabulary the software gives them. If the software only offers broad roles, broad roles are what you get.
So the useful question is not "why did she have too much access" but "what would have made the narrow grant as easy as the broad one". Usually the answer is a role designed around a job rather than around a department: a billing clerk who can create and edit invoices and record payments, but cannot cancel, cannot change prices, and cannot see cost. That role is a setup decision. It takes an afternoon to define and it takes an owner to keep it current.
Illustrative: ten areas of billing access on a counter login (constructed example)
| Area of access | Needed for the stated task? | Consequence of having it unnecessarily |
|---|---|---|
| View customers and contacts | Yes | None — this is the task |
| Create and edit invoices | Yes | None — this is the task |
| Record a payment against an invoice | Yes | None — this is the task |
| Change prices or discount levels | No | Price changes cannot be traced to an instruction |
| Cancel or void an invoice | No | The set of people who could have cancelled becomes everyone |
| Issue a credit note | No | Credits are indistinguishable from corrections |
| Edit or adjust stock quantities | No | Stock differences have more possible causes |
| View cost price and margin | No | Price decisions cannot be checked against cost |
| View every customer's account | No | Every record is readable by the wrong person |
| View business reports and totals | No | Total activity cannot be attributed to a few logins |
Worked example, constructed for this article — the arithmetic.
Counting the table above: 10 areas of access were granted.
The stated task needed 3 of them: view customers, create and edit invoices, record a payment.
- Areas granted beyond the stated need: 10 − 3 = 7
- Records produced on that login during the 91 days: 412 invoices, 61 credit notes, 9 cancellations
- Total actions on the login: 412 + 61 + 9 = 482
- The 9 cancellations were 9 of 482 actions, and because four different people held full billing access in that window, the question "who cancelled these?" has 4 possible answers and no way to narrow it
Every one of these figures is invented for the example. The point is not that 482 is a lot of actions. The point is that 9 of them are the ones you will be asked about, and the permission structure is the reason you cannot answer.
The audit trail you can no longer produce
Here is the actual cost, and it is worth being precise about it because it is easy to dismiss as an abstraction. Suppose a customer disputes invoice IN-204. You need to say: who created it, what it was created from, who changed it afterwards, and who cancelled or credited any part of it. With a trail, that is a sequence of records with names on them. Without one, it is a set of possibilities, and the number of possibilities is the number of people who could have done it. Over-broad access does not create the problem; it multiplies the number of defensible stories.
It also degrades quietly. The cancellation of an invoice in a system that allows cancellations is a recorded event with a name and a time. If everyone can cancel, that record still exists — but on its own it proves nothing, because it cannot distinguish an authorised correction from an unauthorised one. The record answers "what happened", never "was that allowed". For an audit the second question is the whole job.
What to review, when, and who owns it
A permission review that depends on somebody remembering is not a review. It has to have a trigger, a named owner, and a defined output — and the output has to be a change, not a confirmation. The most common failure is a review that concludes everything is fine because nobody can think of a problem, which is a very different statement from a review that examines each access against a stated need.
A review that produces something
- List every user login and every role it holds. The list is the artefact; a meeting is not.
- For each role, write the one-line job it belongs to. If you cannot name the job, the role is not a role, it is a leftover.
- Check each grant against a date and a reason. No reason means the grant is either permanent by accident or temporary by accident, and you need to decide which.
- Count how long the last review was, and set the next one as a date with a name against it — the owner is usually not IT, because IT does not know why a person needs access.
- Remove first, ask later. Deleting an access that was genuinely needed costs an hour; leaving it costs a question you cannot answer later.
- Re-review after every role change, every departure, and every acquisition. The last one is the most commonly missed.
Worked example, constructed for this article — the arithmetic.
A three-person business reviews access once a year. The last review was 14 months ago.
- Quarterly reviews that should have happened in 14 months: 14 ÷ 3 = 4 full quarters, plus 2 months into the fifth. So 4 reviews were due and not done, and the fifth was due 2 months ago.
- Monthly reviews that should have happened: 14 reviews, none held.
The person granted the 4 August access in the earlier example would have been caught at the first quarterly review, which was due within 3 months of the grant, by naming the 2-day intention that never existed in the system. A yearly review catches it at 12 months; a review that depends on memory catches it never. The gap between those is the entire cost of not scheduling the thing.
Narrow roles are a design decision
It is worth saying plainly where this capability sits, because it is asked about constantly and it is frequently oversold. Role-based permissions and an activity trail exist in the Nox-Billings billing area, where employee logins, threshold rules, and per-employee activity are part of the product as described on the billing pages. In the wider NoxOrigin platform the same principle carries across areas, and the current availability of each area is published on the product status page rather than promised here.
None of that is a substitute for a permission review that somebody owns. Software can make the narrow grant as easy as the broad one; it cannot decide that a role should be removed, because that is a judgement about a person's job, and the judgement has to belong to a named person on a date in the diary.
Three attributes every grant should have
Almost every over-broad grant is missing the same three things, and it is worth naming them separately because they fail differently. A grant has no holder — it belongs to a role rather than to a person, so it survives the person leaving and nobody notices it was theirs. It has no need — nobody wrote down what the access is for, so there is nothing to compare it against and no way to say it has grown too large. And it has no end — not because anyone decided it should be permanent, but because nobody ever had to make that decision.
Each missing attribute has a cheap repair. A holder means granting to a named person or to a role with exactly one current member, so a departure produces a list. A need means one line of text, and the test for whether the line is real is whether somebody could say no to the grant on the strength of it. An end means either a date or an explicit statement that there is no end — because a grant nobody ever reviewed is not a permanent grant, it is an unexamined one, and those behave differently when you eventually have to explain them.
What a grant is missing and how to repair it
No holder
It is attached to a role with several members, so it outlives the person who needed it. Repair: grant to a person, or to a role with one named member, and re-check it at every departure.
No stated need
Nobody wrote what the access is for, so it cannot be compared against anything. Repair: one line of need, written at the moment of the grant, phrased so somebody could refuse it.
No end
Nobody decided whether the access is permanent, so nobody revisits it. Repair: a review date, or an explicit decision that the access is standing rather than temporary.
Frequently asked questions
How do I remove temporary access before it becomes permanent?
Give it an owner and a date rather than relying on memory. A monthly half-hour with the user-and-role list in front of you, a stated need against each grant, and removal-first as the default catches a two-day favour within a month. A review that nobody is named against does not happen.
Can NoxOrigin tell me who could have cancelled an invoice?
It can tell you which user login cancelled it and when, because the action carries a name and a timestamp. It cannot narrow the field of possible actors beyond the people whose roles allowed the action. Broad roles mean many possible actors; narrow roles mean the trail is informative. That is a design decision you make at setup.
Do you offer periodic access certification or a segregation-of-duties report?
No. Role-based permissions and a per-user activity trail exist; a certification workflow and a formal segregation-of-duties report do not. We would rather name that gap than describe it as a feature. Published availability and maturity for each area is on the product status page.
Does this apply to expenses and payroll too?
Expenses are a Nox-Billings capability, there is no payroll module, and there is no timesheet record in the platform. Purchasing sits in Commerce. Shift close and day-end reconciliation are assisted-setup maturity, not self-serve switches, so any access review that depends on those is depending on something that needs a person to set it up.