Role-Based Access: How to Keep Sensitive Data Away From the Wrong Team
Build a role and permission matrix so each person sees only the data they need, purchase costs and salaries stay hidden, and every change can be traced.
· Updated
Picture a distribution company with two branches that runs on one Excel file called product-master.xlsx. It holds item codes, names, stock levels, selling prices, and one column only purchasing should ever read: the supplier's cost price. The file goes to the warehouse admin so they can check stock. A week later the same file is circulating in the sales team's group chat, cost column included, and one salesperson is using it to justify a bigger discount for a customer.
Nobody in that story meant any harm. The problem is the sharing model: once a file changes hands, the person receiving it carries every column inside it, including the ones they never needed. This guide walks through setting up access by role, so each person on your team sees the data they need to do their job, while sensitive information like cost prices, salaries, or contract values stays closed to everyone else.
Why "just send them the file" gets expensive
Think about office keys. The security guard, the courier, and the finance director all need to get into the building, but nobody hands them the same master key. The guard needs the front door, the courier needs the loading bay, and the finance filing cabinet opens for a few people only. Company data works the same way. You just can't see the doors.
Security people call this the principle of least privilege. The NIST glossary defines it as a principle that a system should restrict users' access privileges to the minimum necessary to accomplish assigned tasks. For a department manager, the practical version is one question: for each role, what data does this person actually need to get the work done?
When nobody answers that question, three things tend to happen. Sensitive data reaches people who have no reason to see it, like the cost column above. Important records change and nobody can say who changed them, because everyone has edit rights. Then people start keeping private copies to be safe, and you end up with five versions of the same file showing five different numbers.
What counts as sensitive in your department?
Before you touch any settings or software, write the list. Sensitive data looks different in every department, and many managers only notice it after something goes wrong.
In finance it is bank balances, funding requests from other departments, and what the company owes each supplier. Purchasing holds cost prices, payment terms, and competing supplier quotes. Sales has the prospect list, contract values, and special discounts for specific customers. HR keeps salaries, personal employee records, and performance reviews. Project teams usually guard the margin on each project and the value of milestone invoices still unpaid.
The goal isn't to lock all of it. The warehouse admin still needs item names and stock counts, and sales still needs selling prices. What you are looking for are the columns or lists that cause real damage in the wrong hands: a weaker negotiating position with suppliers, colleagues comparing salaries, or a departing salesperson walking out with everyone's prospects.
Build a role and permission matrix
The most useful tool at this stage is a plain table: roles down the side, types of data across the top, and an access level in every cell. You can draft it in a spreadsheet in half an hour with your department heads. Stick to four access levels so it stays readable: edit, view, own records only, or none.
For example, a matrix for a distribution company with Jakarta and Surabaya branches might look like this:
| Role | Funding requests | Prospects | Cost price | Branch |
|---|---|---|---|---|
| Finance manager | Edit | View | View | All |
| Finance staff | Own records | None | None | Jakarta |
| Head of sales | View | Edit | None | All |
| Salesperson | None | Own records | None | Surabaya |
| Warehouse admin | None | None | None | Jakarta |
| Purchasing manager | Own records | None | Edit | All |
Read it one row at a time. Finance staff in Jakarta handle only the funding requests they created, and they see neither prospects nor cost prices. A salesperson in Surabaya sees only their own prospects, so if they leave, they don't take their colleagues' pipeline with them. The warehouse admin can still do the job with stock data, which isn't in this table because it isn't sensitive.
To fill in each cell, ask three questions. Does this role use this data in its daily work? If so, does it need to change the data or only read it? And does it need every row, or only the rows it created or was assigned? Start every cell at "none" and raise it only when there is a clear work reason. That is safer than starting with full access and trying to take it back piece by piece.
Mistakes teams make when setting up access
The first mistake is creating roles for people instead of functions. A role called "Budi's access" is quick to set up today, but when Budi moves departments or someone new takes over the same job, you have to guess what he was given. Name roles after the function, like "Finance staff" or "Salesperson", and put people into them.
The second is assuming view access is always harmless. Someone who can view the entire customer list can still copy every phone number in it. For prospects, "own records only" is often a better fit than "view all".
The third is forgetting branch boundaries. The role permissions look right, yet Surabaya staff can still edit Jakarta's stock because both branches share one list. If your company has several locations, the branch needs its own column in the matrix.
The fourth happens most often: nobody reviews the matrix again. Access that was right in January can be wrong by June after transfers, promotions, and resignations. Set a review schedule, every three months for instance, plus a check whenever someone changes roles or leaves.
One more point gets missed. Limiting access lowers risk but doesn't remove it, so you still need a record of who changed what. Without that trail, when a selling price suddenly changes or a funding request jumps from "Pending" to "Approved", nobody can tell you when it happened or who did it.
When a spreadsheet stops being enough
Spreadsheets give you limited options. You can split the file by role, hide columns whose data still travels inside every copy of the file, or password-protect sheets that end up shared anyway. Each option scatters your data across files whose versions slowly drift apart. A five-person team can live with that. Several departments and branches sharing the same data usually can't.
If you have reached that point, Sora is one option to consider. The Sora homepage explains that you can create roles such as Finance staff or Salesperson, then set which pages each role sees and its access to every list: edit, view, own records only, or none. Sensitive columns like cost price can be hidden from staff, records can be separated by branch, and staff can be limited to the records they created or were assigned. Owners and admins can always change everything, and they can open an audit log showing who changed which record and when, with the values before and after. The matrix you just built doubles as the description you give Sora when it builds the app, or you can start from one of the ready-made apps by business type.
Access rules work best when the workflow itself is clear. If your team is sorting out who approves spending, read how to set purchase approval limits by amount. For sales teams that want each rep focused on their own deals, there is a guide to reviewing a sales pipeline. And if your data still lives in a dozen files, start with moving a team spreadsheet into an app without losing data.
Test the matrix with three scenarios
Before the matrix goes live, run through these three situations with your department heads.
- A salesperson resigns today. What can they still open until their access is removed, and who takes over their prospects?
- The Jakarta warehouse admin needs to help with a stock count in Surabaya for two days. What access gets added, and who makes sure it is removed afterwards?
- An auditor asks who changed the selling price of a product last month. Where does your answer come from?
If any answer is "we'll figure it out later", the matrix isn't finished. Add a rule for that case now, before it happens for real.
Something you can do today: open the file your team shares most often, mark the sensitive columns, and write next to each one which roles truly need to see it. That gives you the first rows of your access matrix.