Short answer: ERP access control means each user sees only the data and functions their role requires, enforced by the system rather than by trust. In practice this covers role-based permissions, record-level rules such as a salesperson seeing only their own customers, restrictions on cost and margin visibility, approval thresholds, and an audit trail of who changed what. For most Pakistani SMEs the realistic risk is not external hacking but internal exposure: shared logins, departing staff who retain access, and sensitive cost data visible to everyone.
ERP Trends · Pakistan
Who Can See What: ERP Access Control and Data Security for Pakistani Businesses
The realistic threat is not a hacker in a hoodie. It is a shared login and an employee who left in March.
By Pearl Solutions · Updated September 2026 · 10 min read
When we raise data security during an implementation, the response is usually a version of "we are a small company, who would bother hacking us?"
It is a fair instinct and it is answering the wrong question. In the SME work we have done since 2006, damage from data exposure almost never arrives from outside. It arrives through the front door, with a valid login.
The five exposures that are actually common
1. The shared login
One account, the password known to six people, often written somewhere convenient. It exists because it is easier than creating accounts and because someone once needed cover during leave.
The consequence is that accountability disappears entirely. When a price is changed, a stock adjustment is posted, or a customer's credit limit is quietly raised, the audit trail says the shared account did it. You have a record of what happened and no record of who did it, which for practical purposes means you have nothing.
2. The employee who left
Staff leave. Their ERP access often does not. Nobody owns the offboarding step, so the account remains valid — sometimes for years, sometimes with a departing salesperson's full customer list still attached.
In a market where staff move between competing businesses, this is not theoretical. Your customer list, your pricing and your supplier terms are the most valuable data you hold, and they are exactly what a departing employee's account can still reach.
3. Everyone can see cost and margin
A default ERP installation frequently shows product cost to anyone who can open a product. That means your sales staff, your storekeeper and your data entry operator can all see what you pay and what you make.
Two problems follow. Commercially, margin information reaches competitors through ordinary staff movement. Internally, it changes negotiation behaviour — a salesperson who can see a 40% margin discounts differently from one who cannot, and not in your favour.
4. No approval thresholds
If any user can post a credit note, write off a bad debt, adjust stock or change a price, then a single mistake or a single dishonest act has no friction in front of it. Most losses in this category are errors rather than fraud — but the control that prevents fraud also catches the errors.
5. Data leaves through export
An employee with export rights can download the entire customer master in seconds. This one is rarely considered until after it happens, and unlike the others it leaves almost no trace unless export is logged.
The pattern across all five: these are not attacks on your system. They are your system working exactly as configured, for people you gave access to. The fix is configuration and process, not a firewall.
The layers of control, and what each one is for
| Layer | Question it answers | Example |
|---|---|---|
| Authentication | Who are you? | Individual login per person, no sharing |
| Role permissions | What functions can you use? | Storekeeper can receive stock, cannot see accounts |
| Record rules | Which rows can you see? | Salesperson sees only their own customers |
| Field visibility | Which columns can you see? | Cost price hidden from sales roles |
| Approval limits | What needs a second person? | Discount above 10% requires a manager |
| Audit trail | Who did what, when? | Every change logged with user and timestamp |
Most businesses configure the second row and stop. The rows that prevent the expensive failures are the third, fourth and fifth.
Record rules are the underrated one
Role permissions are coarse: they decide whether you can open the sales module at all. Record rules are precise: they decide that this salesperson sees only their customers and their orders.
The difference matters most on the day someone resigns. Under role permissions alone, a salesperson leaving can see and export every customer you have. Under record rules, they can see the accounts they already knew about. That is the entire gap between an inconvenience and a competitive loss.
Audit trail is what makes disputes resolvable
An audit trail does not prevent anything. What it does is end arguments. Who changed the credit limit. Who approved the discount. Whether the delivery was recorded before or after the complaint. In a business where several people touch the same records, the ability to reconstruct sequence is worth more than most owners expect until the first time they need it.
A workable permission structure for an SME
Elaborate permission schemes fail because people route around them. This is a structure that holds up in a 20 to 150 person business.
| Role | Can see | Cannot see | Needs approval for |
|---|---|---|---|
| Owner / MD | Everything | — | — |
| Accounts | All financials, all customers | — | Write-offs above a limit |
| Sales manager | All customers, sales margins | Payroll, supplier cost detail | Discounts above threshold |
| Salesperson | Own customers, selling prices | Cost, margin, other reps' accounts | Any discount, new credit terms |
| Storekeeper | Stock quantities, movements | Prices, financials, customers | Stock adjustments |
| Data entry / operator | Entry screens for their function | Reports, financials, cost | Deletions, any correction |
| Production | Orders, BOMs, work centres | Costs, customer pricing | BOM changes |
Two design principles behind it. First, cost and margin are restricted by default and granted deliberately, not the reverse. Second, correction and deletion always require a second person, regardless of role, because that is where both error and fraud concentrate.
The process side, which matters more than the configuration
Configuration is a one-day job. These are the habits that decide whether it still holds in a year.
- Offboarding checklist. ERP access revoked on the last working day, as a named person's responsibility. This single item closes the largest gap on the list.
- Quarterly access review. Print the user list. For each person, confirm they still work here and still need that level. Roles accumulate quietly as people change jobs internally.
- No shared accounts, ever. If cover is needed during leave, grant temporary access to a named person and remove it after. A licence saved is not worth an audit trail lost.
- Verified backups. A backup that has never been restored is an assumption, not a backup. Test a restore at least twice a year.
- Log exports. Know who downloaded the customer master and when.
If you do only one thing: get every shared login replaced with individual accounts and add ERP revocation to your exit process. Those two changes remove more real risk than every other item combined, and neither costs money.
Cloud hosting and where responsibility sits
A common assumption is that cloud hosting means security is handled. It handles one half. The provider is responsible for infrastructure: physical security, network, platform patching, backup infrastructure. You remain responsible for who has accounts, what those accounts can reach, and what leaves through them.
Every exposure described in this article sits entirely on your side of that line. Cloud hosting genuinely improves your position on backups, patching and physical risk — which is why we usually recommend it, as covered in cloud versus on-premise ERP in Pakistan — but it does nothing about a shared login.
Getting it right at implementation
Access control is dramatically cheaper to set up during implementation than to retrofit. Once people have had broad access for a year, restricting it is experienced as a loss of trust and gets resisted. Set the structure while everything is new and it is simply how the system works.
If you are already live with everyone on broad access, the practical path is to restrict cost and margin visibility first, then introduce record rules for sales, then add approval thresholds. Do it in steps, explain the reason each time, and expect it to take a quarter.
Frequently Asked Questions
Internal exposure rather than external hacking. The most common risks are shared logins that destroy accountability, departed employees whose access was never revoked, cost and margin data visible to all staff, no approval thresholds on credit notes and stock adjustments, and unrestricted data export. All five are the system working as configured for people who were given access, so the fix is configuration and process rather than a firewall.
Generally no. Cost and margin should be restricted by default and granted deliberately. There are two reasons. Commercially, margin information reaches competitors through normal staff movement. Internally, a salesperson who can see a large margin negotiates differently and typically discounts more than one who cannot. Field-level visibility controls make it possible to hide cost while leaving selling prices fully accessible.
Yes. Odoo supports user groups and role permissions, record rules limiting which records a user can see, field-level restrictions such as hiding cost prices from sales roles, approval workflows with configurable thresholds, and a change log recording who modified what and when. Pearl Solutions, an Official Odoo Partner in Lahore with 30 Odoo implementations and ERP delivery since 2006, configures this structure during implementation. Call +92 300 7774979 or email info@pearlsol.com.