Permissions: Who Sees What Once Data Leaves the File

Part four set the migration order: master data before transactions, parallel running with a declared end date rather than an open one, and a single sign of success — somebody stops opening the old file without being told to. The data now lives in its new home.

And with it comes a question that did not exist in the world of files, not because anyone ignored it but because a file has no way of asking it: who sees what? This is not a security question for IT. It is an operational question for you, because its answer decides what each employee can learn about the company, about their colleagues, and about your customers.

A file knows one answer: open or closed

A spreadsheet is an excellent tool for many things, and permissions is not one of them. It has a single level: whoever reaches it sees all of it. There is no column that appears for one person and hides from another, no row the accountant may read and the sales rep may not. Even the password sometimes placed on a file does not change the equation, because it guards the door rather than the contents — cross the door and everything behind it is visible.

More importantly, copies multiply. You send the file to a colleague to review one line item, and a complete copy now lives on their machine permanently. They forward it to whoever is helping them, it travels through email, chat and a USB drive, and it ends up on the laptop of an employee who left a year ago. You never granted anyone permanent access, but the copy grants it on your behalf, and there is no way to withdraw it once it is out.

Three things exposed daily without anyone noticing

Ask an owner what their files expose and they usually think of sales numbers. Three other things travel more quietly and matter more:

• Payroll. The payroll file normally starts as a sheet with the accountant, then HR needs it, then whoever executes the bank transfer reviews it. Three copies, each carrying every salary in the company. A leak needs no bad intent: it is enough for someone to open the file on a screen a passing colleague can read. The effect on your team is heavier than any financial loss, because salary comparison damages working relationships in ways that do not return to how they were.
• Margins and special pricing. The sales sheet itself usually carries the cost price, the permitted discount band, or the special rate given to a large account. A sales rep needs the price in order to sell; they do not need the cost. When they see both together their negotiating behaviour changes, and your special pricing reaches the market through the first employee who moves to a competitor.
• Customer data. Names, mobile numbers, addresses, and sometimes images of ID documents and registrations. This is not company information alone; it is the personal data of people who entrusted it to you. It is also the item that carries a statutory obligation rather than an internal norm, and we return to it shortly.

Notice that none of the three is exposed by decision. Nobody decided the rep should see cost — the column simply happened to be in a file they needed for another reason. That is precisely the problem: in a world of files, exposure is the default state, and the exception requires a deliberate effort nobody makes under daily pressure.

What a system gives you first is not a prettier screen

When you move to a system, the first real difference is neither appearance nor speed. It is that the question becomes askable and answerable: who sees what? There are four practical differences:

• Permission attaches to the role, not the person. You define once what the sales role can see, and everyone who holds that role inherits it. A new joiner does not require the thinking to start again, and an employee moving between departments has their visibility change with their role rather than whenever somebody happens to remember.
• Permission goes down to the field. A rep can see the full customer record and its order history without seeing the margin on the same line. That is impossible in a file and ordinary in a well-designed system.
• There is a record of who viewed and who edited. That log is less a tool for monitoring staff than a tool for ending arguments. When a number changes and everyone asks who changed it and when, the system answers in a second instead of the question turning into mutual accusation with no reference to settle it — which is exactly what the fourth signal in part one of this series was describing.
• Access is withdrawn instantly. When an employee leaves, disabling their account ends their access immediately and completely. The copies they took from your files over years of work stay with them, and there is no way to retrieve them or even to know how many there are.

The legal edge: customer data is not a tidiness issue

Customer data differs from the other two items, because the cost of mishandling it is not internal embarrassment but statutory liability. The Personal Data Protection Law, overseen by the Saudi Data and Artificial Intelligence Authority (SDAIA), applies to any organisation processing the personal data of individuals inside the Kingdom, with no exemption based on size. It holds the organisation responsible for protecting that data, for collecting no more of it than the purpose requires, and for reporting a breach that threatens it.

Set that obligation beside the daily practice: a file holding hundreds of customer records sent through a chat application to three employees, saved automatically onto their personal phones. In that situation you do not know where copies of your data exist, who can reach them, or how to delete them if a customer asks. The difference between that and a system holding the data in one place under defined permissions is not a matter of elegance — it is the difference between being able to comply and not.

We set out the obligations in more detail in our practical guide to the Personal Data Protection Law, and covered the most common case — customer data moving inside conversations — in your customer conversations and the law. For the wider protection picture for a smaller company, see our cybersecurity guide for SMEs.

The Origami view

When we build a custom system for a company that has been running on spreadsheets, the permissions matrix belongs to the design phase rather than the handover. The reason is practical: a permission is not a setting added at the end, it is a decision that shapes how screens are divided, how reports are built, and where a sensitive field is separated from an ordinary one. Deferring it produces a system that cannot be constrained later without rebuilding parts of it.

We also start that matrix from the roles the company actually runs on today rather than from a theoretical list, because a permission designed away from operational reality blocks the work, and the team routes around it by the fastest available means — usually exporting the data to a file. At that point you are back exactly where you started, having paid for a system nobody uses. That logic runs through everything we build across our services: a control that does not respect how the work is actually done will not hold.

Setting permissions without paralysing the work

The common mistake on first rollout is excessive strictness: everything is closed and opened on request, so the team spends its week waiting for approvals and learns to resent the system before learning to use it. This order avoids that:

• Start from roles, not names. Write the list of roles your company actually has: accountant, sales rep, storekeeper, branch manager. Fewer than ten roles usually cover every employee, and a role list is far easier to manage than a list of people that changes monthly.
• Name the sensitive fields first. Salary, cost, margin, permitted discount, customer identity documents. It is a short list in any company, and a clear decision on each item resolves most of the problem.
• Separate viewing from editing. Not everyone who needs to see a number needs to change it. Read without edit is the safest permission and the least disruptive to the work, and it is sufficient in most cases.
• Make export its own permission. This one is always forgotten: anyone who can export data to a file can bypass everything above in a single click. Decide who holds that permission and make every export appear in the log like any other action.
• Review the list at every team change. A joiner, a transfer between departments, or an ending relationship. A periodic review every few months normally surfaces accounts belonging to people who left and permissions left over from a temporary task that finished.

The governing rule is simple: each person sees what they need to do their job, and everything they need to do it. The first half protects you; the second half protects the system from becoming an obstacle the team routes around.

Coming next

We have settled who sees what, which leaves the question of what there is to see. The next part covers the reports you used to build by hand at the end of every month, and why a report inside a system becomes a view of the current moment instead of a collection exercise that finishes after the month it describes has already gone. We then close the series with the first thirty days after the move and what usually breaks in them.

Sources

• Saudi Data and Artificial Intelligence Authority (SDAIA) — the Personal Data Protection Law, its implementing regulations, and controller obligations.
• National Cybersecurity Authority — essential cybersecurity controls covering identity and access management.
• Ministry of Human Resources and Social Development — requirements for keeping employee records and wage data.
• Zakat, Tax and Customs Authority — requirements for retaining invoices and documents and producing them on request.
• Ministry of Commerce — provisions governing commercial books and records.