Who Can See What: Access Control and Audit Trails in Business Systems

Confidential information inside a business system is protected by two things: who is allowed to see what, and a record of who actually did. The first is access control — roles, permissions, and limits down to individual fields and records. The second is an audit trail that records reads as well as changes, kept where the people it records cannot edit it.

Most mid-sized businesses have the first in a rough form and almost none of the second. In Oman the gap now has legal weight. The data protection law’s record of processing must describe who is authorised to access personal data. The 2026 Cybercrime Law punishes exceeding authorised access — more heavily when an employee does it in the course of their work. And the protection the Industrial Property Law gives trade secrets depends on having taken reasonable steps to keep them secret.

This article covers how to design both into a custom or business system. The infrastructure side — multi-factor authentication, administrator rights, backups — is in the security baseline a mid-sized Omani business needs.

The short answer

• Grant access by role, defined by what each job needs, not by who asked loudest.
• Go below the screen: restrict sensitive fields, and limit records by branch, team or ownership.
• Treat export as its own permission. Seeing a record and downloading ten thousand of them are different risks.
• Separate duties where one person could otherwise both commit and conceal an error or fraud.
• Log reads, not just writes, for sensitive data, and keep logs out of reach of the people they record.
• Review access regularly, and remove it the day someone leaves or changes role.

Why this has become a legal question in Oman

Three laws converge on the same design.

Data protection. The Executive Regulation of the Personal Data Protection Law requires a record of processing activities. That record must include a description of the categories of personal data held and the persons authorised to access them. The Regulation also requires controls that protect electronic systems against unauthorised access, leakage, tampering and misuse. You cannot describe who is authorised if the system does not know.

Cybercrime. The Law on Combating Information Technology Crimes, issued by Royal Decree 61/2026, applies to anyone who intentionally and without right enters a system, exceeds the access authorised to them, or stays after realising they should not be there. The base penalty is one to six months’ imprisonment and/or a fine of OMR 100 to 1,000. It rises if data is copied, disclosed or altered, and rises again if that data is personal. Article 7 then sets one to three years and/or OMR 3,000 to 7,000 where the offence is committed during or because of the offender’s work. Leaving the job does not escape it.

A crime of “exceeding authorised access” only protects you if “authorised” is defined. A system where every employee can open every record makes that very hard to prove.

Trade secrets. Article 65 of the Industrial Property Law (Royal Decree 67/2008) treats disclosure, acquisition or use of undisclosed information without the lawful holder’s consent, contrary to honest commercial practice, as unfair competition. One element of the definition is that the holder has taken reasonable steps to keep the information secret. Role-based access and logging are about as clear an example of reasonable steps as a business can show.

Start from jobs, not people

Role-based access control works when roles describe work. “Branch sales staff”, “finance approver”, “warehouse supervisor” and “HR administrator” are roles. “Ahmed’s access” is not.

Build the matrix in three passes:

1. List the roles that exist in the business, and the actions each must perform: view, create, edit, approve, delete, export.
2. Grant the minimum each role needs to do its job. When someone asks for more, the question is which task requires it, not whether they are trusted.
3. Assign people to roles. Where someone genuinely needs two roles, give them both rather than inventing a hybrid. Hybrids multiply until nobody understands them.

Keep the number of roles small enough that a manager can read the matrix and say whether it is right. A permissions model only the original developer can explain will not be reviewed, and an unreviewed model drifts.

Go below the screen: fields and records

Screen-level permissions — who can open the customer page — are the coarse layer. Confidentiality usually lives in two finer ones.

Field-level. A customer service agent needs a customer’s name, order history and delivery address. They do not need the national ID number, the credit limit or the notes from a collections call. An HR coordinator needs leave balances, not salaries or medical certificates. Mark sensitive fields in the data model, and let roles see them only where the job requires.

Record-level. A branch manager in Sohar should see Sohar’s customers and staff, not Salalah’s. A salesperson may need their own accounts but not their colleagues’. Board papers belong to the board. Scope each role to the records it owns, by branch, team, ownership or classification.

Both layers belong in the server, not just the interface. Hiding a field in the screen while the API still returns it is a common mistake. Anyone who opens the browser’s developer tools can see the data.

Treat export as its own permission

Most serious leaks of business data are exports, not hacks: a customer list downloaded the week before someone joins a competitor, or a payroll file emailed to a personal address.

• Make export a separate permission from viewing, granted to fewer roles.
• Log every export with who, what, how many records and when.
• Alert on volume, such as a user exporting far more than their usual pattern, or exporting at unusual hours.
• Prefer reports to raw extracts. Most needs are met by an aggregate without personal data in it.

The same thinking applies to new channels of export. Pasting records into an external AI tool is an export too, covered in a policy for staff using AI tools.

Separate duties where fraud would otherwise be easy

Some combinations of permissions let one person both commit and conceal a problem:

• creating a supplier and approving payments to it;
• changing a customer’s bank details and issuing their refund;
• editing stock counts and approving write-offs;
• granting user access and using the access granted.

Split these between roles, and make the system enforce the split rather than relying on policy. Where a small team cannot split them, compensate with logging and a second person’s review after the fact.

Log reads, not just writes

Most systems record who changed a record. Few record who looked at it. For ordinary data that is acceptable. For sensitive data — salaries, health information, customer identity documents, pricing strategy, board material — reading is exactly the event you need to see.

A useful audit trail records, for each event:

• who did it, as a named individual — shared accounts make logs useless;
• what they did — viewed, created, edited, approved, exported, deleted;
• which record, and for edits, the values before and after;
• when, and from where — device or network.

Three properties make the trail trustworthy:

1. Tamper-resistance. Store logs where application users, and ideally administrators, cannot edit or delete them — a separate store, write-once settings, or a log service.
2. Retention long enough to investigate. A breach may come to light months after it began. Pick a retention period for logs deliberately and record why.
3. Someone reads them. Logs nobody reviews protect you in court and not before. Define a few alerts that matter — mass exports, access outside working hours, an account viewing records outside its scope — and send them to a named person.

Under Oman’s data protection rules, you must notify the competent department within 72 hours of becoming aware of a breach that threatens data subjects’ rights. Without read logs, you cannot say what was accessed, and the safe assumption becomes the widest one.

Joiners, movers and leavers

Access decays without a process. The three moments to control:

• Joiners get the role their job needs on the first day, not a copy of their predecessor’s accumulated rights.
• Movers lose the old role when they gain the new one. Promotion is when people quietly accumulate the most access.
• Leavers lose access on their last day — before it ends, for sensitive roles — including mobile apps, API keys and shared credentials they knew.

Then review. Every quarter, send each manager the list of who in their team has which role, and ask them to confirm it. Most of the work is removing access nobody remembered granting.

External parties: vendors, auditors and support

Suppliers often need access: your software vendor for support, an auditor for a review, a contractor for a project. Give them named accounts, scoped roles and an end date. Log their access as carefully as staff access. The 2026 Cybercrime Law’s offences apply to anyone who exceeds authorised access, and your contract should define what that access is. Hiring a software company without handing over your data covers the contract terms.

---

Frequently asked questions

What is role-based access control? A model where permissions are attached to roles that describe jobs — such as finance approver or branch sales — and people are assigned to roles. It keeps access consistent, reviewable and easier to change when someone moves jobs.

Do we need to log who views records, or just who changes them? For sensitive data, log views too. Reading is the event that matters in a confidentiality breach. Oman’s 72-hour breach notification is hard to meet if you cannot say what was accessed.

Is an employee who looks at data they shouldn’t committing a crime in Oman? The 2026 Cybercrime Law penalises intentionally exceeding authorised access to a system, with heavier penalties if data is copied or disclosed, if it is personal, or if the offence is committed in the course of work. That only works if your system defines what each person is authorised to access.

How does access control help protect trade secrets? Oman’s Industrial Property Law protects undisclosed information that its holder has taken reasonable steps to keep secret. Role-based access, export controls and audit logs are concrete evidence of those steps.

How often should access be reviewed? A quarterly review by each manager of their team’s roles is a practical rhythm for most mid-sized businesses. Remove leavers’ access on their last day, and remove a mover’s old role when the new one is granted.

Should our software vendor have access to our production system? Only as much as support requires, through named accounts, scoped roles and an end date, with access logged. Shared or permanent vendor administrator accounts are among the hardest risks to see.

---

This article states the position under the Personal Data Protection Law and its Executive Regulation, the Law on Combating Information Technology Crimes issued by Royal Decree 61/2026, and the Industrial Property Law, as in force on 21 October 2026, the date of publication. It is not legal or security advice; confirm your position with a qualified adviser.

Sources: Royal Decree 61/2026 — Law on Combating Information Technology Crimes (Arabic text) · Ministerial Decision 34/2024 — Executive Regulation of the PDPL (Arabic text) · Royal Decree 67/2008 — Industrial Property Law (Arabic text) · OWASP — Authorization Cheat Sheet · OWASP — Logging Cheat Sheet

Need roles, field-level permissions and audit trails in your systems? ZAWAT builds business systems and custom software with access control and logging designed in from the first screen. Book a call.