Role-based access control for a business app, in one answer
Role-based access control (RBAC) in a business app gives people roles, and each role a set of permissions. To survive a reorganisation, keep roles few and ask two separate questions: what may this person change, and what may they see? Grant each role over a scope, such as a branch or a team, and store the grants as data. A restructure is then an admin task, not a code change.
The usual first version copies this year's org chart into the code, one role per job title. It works on launch day. It starts to fail the first time a manager covers two branches, a team moves, or a contractor needs read-only access for a month.
This guide is for owners and operations leads at UK and EU companies of 10 to 200 people. You may be commissioning a web application or an internal tool, or living with one whose permissions have turned into a list of exceptions. It covers the two questions, scopes, joiners and leavers, where data slips past permissions, and how to test it all before you accept the software.
Why roles copied from the org chart break
Say you run a lettings and property management firm with 80 staff in five branches around Manchester. Your new system launches with five roles, one per job title: director, branch manager, negotiator, property manager and accounts. Each role's rules are written into the code.
Then eighteen months of ordinary business happen:
- The Bolton and Wigan branches merge.
- You hire a regional manager to look after three branches.
- Property management moves into one central team that serves every branch.
- An accounts assistant starts chasing late rent for the Stockport branch.
- A bookkeeper joins for three months to help with the year-end.
None of this is unusual. Yet each change needs either a developer to rewrite the rules or a new role: "branch manager (Bolton and Wigan)", "accounts plus arrears", "temporary bookkeeper".
OWASP, a non-profit web security foundation, has a name for where this ends: "role explosion", when a system defines too many roles. Its authorisation guidance warns that with many roles, checks get missed or done wrong, which "can result in both too much and too little access". Testing and auditing get harder with every role added.
The quick fix is worse. When the right role doesn't exist and the developer is busy, someone is made an admin "for now". Two reorganisations later, several people are admins and nobody can say who can see the landlords' bank details.
Two questions: what people may change, and what they may see
Most permission designs ask one question: what can this role do? Split it in two. What may this person change, and what may they see? The answers are often different, and they move separately when the business changes.
For the lettings firm, the two lists might look like this:
| Role | May change | May see |
|---|---|---|
| Negotiator | Viewings and offers | Applicant and tenant contact details |
| Property manager | Repairs and inspections | Landlord and tenant contacts, but not bank details |
| Accounts | Payments and landlord statements | All money records; tenant contacts only for arrears |
| Regional manager | The discounts and exceptions they approve | Everything in their branches, including money |
| Year-end bookkeeper | Nothing | Payments and statements for that financial year |
Look at the last two rows. The regional manager sees almost everything and changes very little. The bookkeeper changes nothing at all. A single "can do" list can't describe either of them without giving something extra away.
The split also protects the records themselves. A negotiator who logs offers doesn't need to see what each let earns the firm. Someone who can't see the money attached to a record also can't tell which record would be safe to fake.
A few pairs of permissions should never sit with one person. The classic pair is changing a landlord's bank details and approving the payment run that uses them. Risky actions like that payment run also need a confirmation that states their effect, which our guide to admin dashboard design covers.
Scope: roles say what, scopes say where
A role describes a kind of work. A scope says where the person does it: one branch, three branches, the properties they manage, or the whole firm. Most reorganisations change scopes, not roles.
So give each person grants, and make each grant one line: this person, this role, over this scope, from this date, until that date. The lettings firm's eighteen months then look like this:
| What changed | With one role per job title | With roles granted over scopes |
|---|---|---|
| Bolton and Wigan merge | A new role, or a code change | Wigan's records move to Bolton; the grants follow |
| Regional manager for three branches | A new role | One grant: branch manager, over three branches |
| Central property management team | Rewrite the property manager rules | The scope changes from "my branch" to "properties I manage" |
| Accounts chases Stockport arrears | An "accounts plus arrears" role | A second grant: arrears, over Stockport |
| Three-month bookkeeper | Shared login, or admin rights | Read-only finance, ending on the contract's last day |
Every line on the right is something your office manager can do on a screen, with no developer and no new release. Our web applications page promises "roles and access that hold up when the org chart changes". This table is that promise in practice.
"Properties I manage" is a relationship between a person and a record. OWASP's guidance says relationship- and attribute-based checks "should typically be preferred for application development", because they are easier to update when needs change.
You don't need the jargon or a special product to use the idea. For most business apps, a role, a scope and an "assigned to" link are enough. OWASP's Top 10 says the same about individual records: access rules should enforce record ownership, rather than let anyone with a role read or change any record.
Joiners, movers and leavers
People join, change jobs and leave, and each event needs a change to their access on the right day. The UK's National Cyber Security Centre asks for a "joiners, movers and leavers" policy, "so access can be revoked when no longer needed, or changed for movers".
Movers are the hard case. Someone moves from lettings to sales and gets the sales grants. Nobody removes the lettings ones, because nobody asked, and after three moves they can see more than anyone else in the firm. The app should treat a move as one step: pick the new grants, then confirm a list of the old ones that end the same day.
Leavers need their access to end everywhere at once. In April 2022, Block, the company behind Cash App, reported an incident in a filing with the US Securities and Exchange Commission. A former employee had downloaded reports containing customer information in December 2021.
The employee "had regular access to these reports as part of their past job responsibilities", but downloaded them after their employment ended. Cash App Investing contacted about 8.2 million current and former customers.
Three habits close most of that gap:
- Sign in with the company's work accounts, such as Microsoft 365 or Google Workspace. Switching off one account then locks the person out of the app too, which is why the NCSC's guidance points to single sign-on.
- Give temporary access its end date when you grant it, rather than a reminder to remove it later.
- Once a quarter, and after every reorganisation, have the owner read the list of who can see money and personal data.
Record every grant and every removal, with who approved it and when. Our guide to audit trails covers how to keep that history so nobody can quietly edit it.
"See" rules belong where data leaves the server
Hiding a column on screen doesn't stop anyone seeing it. If the server still sends the landlord's bank details to the browser, anyone who opens the browser's developer tools can read them. OWASP's Top 10 gives the example of an app with all its access control in the front end. The attacker skips the page and asks the server for the admin data straight from the command line.
So the "see" rules run on the server, at the point where it builds each response, and they cover every way data leaves. That means pages, search results, exports, emailed reports, notifications and the app's API. The server drops what this person may not see before anything is sent. On a shared device, such as a tablet in a branch, the app should also clear anything it stored locally when a different person signs in.
Exports need the most care, because a file sits outside your permissions the moment it's saved. Desjardins, a Canadian financial co-operative, had a breach affecting close to 9.7 million people. The Privacy Commissioner of Canada's findings describe how.
Access to its data warehouses was restricted. Marketing staff who had that access copied personal information into a shared directory that every employee in the department could open. An employee without warehouse access copied it from there between March 2017 and May 2019. The Commissioner found the system "allowed authorized users to move restricted data to unprotected directories and storage media without any controls".
Data protection law points the same way. Article 25(2) of the UK GDPR, worded the same as the EU GDPR, requires data protection by default. It applies that duty to the "accessibility" of personal data, not only to how much you collect and how long you keep it. In a business app, accessibility is the "see" list.
So give exporting its own permission, separate from viewing a record. Each export should carry only the columns that person may see, and the history should record who exported what, and when.
When you don't need all this
Many firms don't, and a builder who insists otherwise is selling you complexity.
- If 15 people share one office and everyone does a bit of everything, two roles are enough. An owner runs the account, and members do the work. Our guide to what an MVP should include explains that start, and how to leave room to grow.
- If you run on products such as Xero, HubSpot or Microsoft 365, set up their own user roles first. Thousands of firms have already tested them. We make the same case for sales teams in custom CRM vs HubSpot or Pipedrive.
- If your structure rarely changes, a clear table of roles in the code and a developer you can call may serve you better than a screen for managing grants.
Customer and partner logins are a separate problem. If you sell a SaaS product, each customer company is its own scope, and one customer must never see another's records. OWASP notes that roles alone are "poorly suited" when different organisations share one system, so design for companies from the first release.
How to test permissions before you accept the software
A demo shows you the admin's view. Test the rest on the staging copy yourself, as the most junior person and as the most senior.
- Ask for the permission table: every role, what it may change and what it may see, in plain words. It belongs in your documentation, in your accounts.
- Log in as a negotiator from one branch and open a record. Change the record number in the address bar to one from another branch. You should see "permission denied", not the record.
- Export a list as that negotiator and open the file. It should hold only what they may see.
- Rehearse a reorganisation. Merge two test branches, move a person between teams and add a contractor with an end date. None of it should need a developer.
- Switch off a test leaver's work account. Check they can't get back in, including on a phone where they were already signed in.
- Read the history for all of the above. Every change should show who made it and when.
Start with a list of names
This week, write down everyone in the company. Beside each name, note what they change in your systems and what they see. Then write down the next few changes you can imagine: a branch opening, a merger, a manager covering two teams, a contractor for the busy season.
Walk each change through your current software, or through the proposal on your desk. Any change that needs a developer, a new role or a shared login is a question for your builder. Ask it now, while the answer is a design decision rather than a rebuild.
Questions
Can we manage roles in Microsoft Entra ID or Google Workspace instead of in the app?
Partly. Use your directory for sign-in and for switching people off, and map a directory group to a broad role if that helps. The directory doesn't know which branches or clients a person handles, though. Scopes and the rules about which records someone may see still live in the app. Decide which system holds each fact, so nobody has to update two places.
Should we delete a leaver's account?
Usually not at first. Switch it off so the person can't sign in, and keep the account so their records still show who created and changed them. Deleting it can break that history, or quietly hand their work to someone else. Your data retention policy then decides when their personal details are removed.
Who keeps the permission table up to date after launch?
Someone in your company, usually the operations lead, with the owner signing off anything that touches money or personal data. The builder's job is to make that possible without them: a screen for grants, a readable list of roles, and documentation in your own accounts. When we build, the code and the documentation are yours and move into your accounts at handover.
How we wrote this: drafted with AI, then checked and edited by the people who build our projects. Figures come from our own work or from the linked sources.