User permissions and audit trails: the basis of trust in any business system

In a company’s early years, employees know one another, and you only have to ask to find out who edited an invoice or changed a price. As the number of employees and branches grows, that question gets harder, and small mistakes turn into disputes that no one settles.

Many companies move from shared Excel files to a business system, then find that the new system repeats the same problem: everyone logs in with broad permissions, and there’s no trace of who did what. We covered moving the data itself in “From Excel to a system: a practical data migration plan”; here we look at who has the right to change it afterward.

Permissions and the audit trail aren’t a technical add-on that comes at the end of the project. They’re part of the business rules, and they determine how much trust you can place in the numbers your dashboard shows.

Roles first, then the least privilege needed

A common mistake is to grant permissions to each person individually: this employee sees the reports, that one edits prices, and a third was given a temporary permission that no one revoked. Months later, no one knows why each person has the access they have.

The alternative is to define roles by the work: storekeeper, accountant, branch manager, and salesperson. Permissions are linked to the role, and each employee is linked to one or more roles. When a new employee joins, you only need to choose their role, and when a role’s definition changes, the effect applies to everyone at once.

This also makes a once-difficult question easier for management: who can approve this request? The answer becomes a clear list of roles, not a search through each user’s settings one by one.

Within each role, we apply the principle of least privilege as OWASP guidance describes it: users are granted the minimum permissions they need to do their job, and access is denied by default until a permission is explicitly granted. The effect on the business is direct: the less a single account can do, the less damage is caused by a mistake or by an account whose password has been stolen.

Data scope: the branch and the warehouse

The role defines what a user does; the scope defines which data they do it on. A branch manager needs to approve their own branch’s requests, not those of every branch. A storekeeper sees the stock levels of their own warehouse, and may not need to see prices or profit margins at all.

Suppose a company has three branches, and a salesperson at one of them can see the invoices and customers of the other branches. Nothing has gone wrong yet, but the full customer list is now within reach of every salesperson. Limiting scope by branch closes that door without disrupting anyone’s work.

Separation of duties and sensitive operations

Separation of duties means that no single person has enough permissions to misuse the system alone, a definition found in the NIST glossary of security terms. In day-to-day work, this translates into a simple rule: the person who creates a transaction is not the person who approves it.

• Whoever creates a purchase order doesn’t approve it, and whoever approves it doesn’t receive the goods.
• Whoever records a supplier invoice doesn’t release its payment.
• Whoever adds users doesn’t grant themselves extra permissions.

Then come the sensitive operations: those in which a mistake hits money directly. We identify them with management before development, and give each one a clear rule:

• Discounts: a ceiling for each role, with anything above it requiring approval.
• Price changes: a permission for a specific role, with a date from which the new price applies, instead of writing over the old price.
• Exchange rate changes: a restricted permission, because their effect extends to every invoice in another currency.
• Deletion: financial records aren’t deleted but canceled with a reversing entry that stays visible.
• Reopening a closed accounting period: with explicit approval and a written reason.

Approval doesn’t mean work stops until the manager shows up. The approval request can reach a phone, the approver can see the reason and the amount before agreeing, and their decision can be recorded in the same log. That way, sales stay fast, and exceptions stay visible to those who need to see them.

The audit trail: who did what, and when

The audit trail is the system’s memory, and it doesn’t forget. OWASP guidance recommends that, for each event, the log keep a record of when it happened, where in the system, who did it, and what happened. In business systems, we add one element that can’t be left out: the value before and after the change.

Suppose an item’s price was changed, and the item was then sold at the new price many times before anyone noticed. Without an audit trail, you’re left with an endless argument. With one, you know who changed the price, from what value to what value, and at what time, so you deal with the cause instead of looking for someone to blame.

• No user, not even the system administrator, can edit or delete the audit trail.
• Corrections are made with a reversing entry or a new correcting transaction, so the mistake and the correction stay visible side by side.
• Denied access attempts are logged too, since they are an early sign of a missing permission or an illegitimate attempt.
• Changes to permissions themselves are logged: who granted the permission, to whom, and when.

It’s also important that the audit trail can be searched in business terms: by invoice, item, user, or period. A log that only a developer can read is one nobody in management will open.

And a log is no use if no one reads it. We suggest that the business owner appoint someone to review a short periodic report: discounts that exceeded the limit, changes to prices and exchange rates, reversing entries, and transactions made outside normal working hours.

Trust in a system’s numbers does not come from preventing every mistake, but from being able to tell where it happened and how it was corrected.

Reviewing permissions when staff change

Permissions pile up over time: an employee moved from sales to purchasing and kept their old permissions; another left the company, and their account stayed active. That’s why OWASP guidance recommends reviewing permissions periodically after launch, to make sure they haven’t gone beyond what was originally designed.

• When a role changes: the previous role’s permissions are removed the same day, and the new ones aren’t added on top of them.
• When someone leaves: the account is disabled immediately, not deleted, so its history stays in the audit trail.
• Temporary permissions: granted with a set expiry date, not with a promise to revoke them later.
• Periodic review: each manager reviews the list of their team and their roles, confirming what’s needed and removing what isn’t.

Suppose an employee in purchasing left the company, and their account stayed active because no one was told. Nothing may happen, but any purchase order created from that account will look valid in every report. Linking account deactivation to HR’s offboarding procedures closes that gap.

We do not suggest a single review frequency; it’s a decision for the business owner, based on the size of the team and how sensitive the data is. What matters is that it’s written down and has a known owner.

A pre-launch checklist

• Roles are defined by the work, and each employee is assigned a role, not individual permissions.
• Access is denied by default, and every permission granted has a known reason.
• Each user’s scope is limited to the branch or warehouse where they work.
• Sensitive operations are named, and each one has a limit or an approval.
• The person who creates a transaction is not the one who approves it.
• The audit trail records who, what, and when, plus the value before and after the change.
• The audit trail is protected from editing and deletion, and corrections are made with a reversing entry.
• Someone is responsible for reading the audit trail and reviewing permissions.

These rules are settled in the discovery session before development, because adding them to an existing system is harder and costs more. When we build a custom ERP system module by module, we design permissions and the audit trail with the first module, and the remaining modules build on them.

If your current system gives everyone access to everything, or you’re planning a new system, you can discuss your situation with the ITS team, so that together we can define the roles and sensitive operations before any code is written.