Every business app eventually faces the same question: should the new sales executive really be able to see everyone’s salaries? Access control decides who can see and change what, and getting it wrong is one of the most common causes of data leaks we see. The good news is that a clear, role-based design is simpler than it sounds, and much easier to get right early.
Users, roles and permissions in plain English
Role-based access control, usually shortened to RBAC, has three building blocks. Permissions are individual actions, such as “view invoices” or “approve refunds”. Roles are bundles of permissions that match a job, such as Accountant or Branch Manager. Users are people, and each one is given one or more roles rather than a long list of individual permissions.
The point of the middle layer is maintenance. When a new accountant joins, you assign the Accountant role and they get exactly what their colleagues have. When your refund policy changes, you update one role instead of editing forty user accounts. It also makes reviews possible, because you can read a short list of roles and understand who can do what.
Designing roles for a real business
Start from jobs, not screens. Sit down with each department and list what people actually do in a normal week, then group those actions into roles. Most small and mid-sized businesses need between five and twelve roles. If you find yourself designing thirty, you are probably creating a role per person, which defeats the purpose.
Follow the principle of least privilege: give each role the minimum access it needs to do the job, and add more only when there is a real request. It is far easier to grant a permission later than to discover, after an incident, that half the company could export the customer list.
Separate the duties that check each other
Some combinations of access are risky even when each permission looks harmless on its own. The person who creates a supplier should not be the person who approves payments to that supplier, and whoever issues refunds should not also reconcile them. Auditors call this segregation of duties, and building it into your roles prevents both honest mistakes and fraud.
Access should be earned by the job someone does, not by how long they’ve been around.
Beyond roles: limiting which records people see
Roles answer what someone can do. Real businesses also need to control which records they can do it to. A branch manager in Sharjah should approve leave for Sharjah staff, not for the Riyadh office. This is called data scoping, and it is where many off-the-shelf tools become awkward.
- Ownership — sales staff see the leads assigned to them, managers see their whole team’s.
- Location or entity — access limited to a branch, country or legal entity within a group.
- Field-level rules — HR can see salaries and passport numbers; line managers see names and job titles only.
- Thresholds — a supervisor approves refunds up to AED 500; larger amounts go to finance.
Build scoping into the database queries and the API, not just the screens. Hiding a button in the interface is not security: if the underlying API still returns every branch’s data, anyone with a little curiosity and a browser’s developer tools can see it. We test this explicitly on every project by trying to fetch records a role should not reach.
Audit trails, sign-in and compliance
Access control is also a legal matter. The UAE’s Personal Data Protection Law and Saudi Arabia’s PDPL both expect businesses to limit access to personal data and to protect it with appropriate technical measures. Sectors such as healthcare and finance, and free zones like DIFC and ADGM with their own data protection rules, set the bar higher still.
In practice, that means three things. Log every sensitive action, such as viewing a salary, exporting data or changing a role, with who did it and when. Require multi-factor authentication for anyone with administrator or finance access. And use single sign-on through Microsoft Entra ID or Google Workspace where possible, so removing a leaver’s email account removes their app access too.
For customer-facing apps, the same thinking applies to your users. A customer should only ever see their own orders and documents, and a vendor on a marketplace only their own products and payouts. Logging in with UAE PASS or Nafath can strengthen identity checks where regulation or the value of the transaction justifies it.
The mistakes we see most often
Most access problems we find during security reviews are not clever attacks. They are shortcuts taken under deadline pressure that nobody revisited once the system was live. Each of the four below is easy to fix, and each one, left alone, eventually turns into an awkward conversation with a customer or a regulator.
- Everyone is an admin — usually because it was quicker during launch, and nobody went back to fix it.
- Shared logins — one account for the whole warehouse means no audit trail and no way to remove one person.
- Forgotten leavers — former staff and contractors with active accounts months after leaving.
- No regular review — roles quietly accumulate permissions until they mean nothing.
The bottom line
Good access control is mostly good organisation. Map the jobs in your business, turn them into a short list of roles, add scoping for branches and sensitive fields, and log what matters. Build it into your app from the first release, because retrofitting permissions onto a live system with real data is slower, riskier and far more expensive than designing them in from day one.
If you already have a system in place, start with a quick audit. Export the list of users and their roles, ask each department head to confirm who should still have access, and remove anything nobody can justify. It usually takes an afternoon, and it is one of the cheapest security improvements available to any business.
