In most enterprise software projects, “who can see and do what” gets answered late, often during testing, when a plant head notices he can see another plant's purchase orders. By then, access rules touch every screen, report, export and API, and fixing them is expensive.
This guide shows how to plan access control before development: separating roles from data scopes, building a permission matrix, designing approvals and segregation of duties, connecting single sign-on, handling leavers and deciding what the audit trail must record.
Quick answer: List every user group, the actions each must perform and the data each may see by entity, branch or department. Turn that into a permission matrix, keep roles separate from data scopes, connect login to your identity provider through SSO, define approval limits and segregation of duties, and decide which events the audit trail records and who can read it. Enforce every rule on the server, not only in the screens.
Separate three questions: who, what and which data
Access control in enterprise software answers three different questions, and mixing them is the most common design mistake.
- Who: the person, identified through login, ideally through your corporate directory.
- What: the actions they may perform, such as create a purchase request, approve it or release payment. These belong in roles.
- Which data: the records they may act on, such as one plant, one legal entity, one region or only their own records. This is the data scope.
If you combine actions and data into roles like “Plant 2 Purchase Approver”, a group with ten plants and five functions quickly needs fifty roles, and nobody can review them. Keep a small set of job-based roles and assign a separate scope to each user. Some systems add attribute-based rules on top, for example limiting approval to a value range or a cost centre. That combination is usually easier to maintain than an ever-growing list of roles.
Build a permission matrix before any screen is designed
A permission matrix is a simple grid of actions against roles. Draft it in a spreadsheet with your process owners. It becomes part of the requirements, and later it becomes a test script for user acceptance testing.
| Action | Requester | Approver | Finance | Auditor | Admin |
|---|---|---|---|---|---|
| Create purchase request | Yes | No | No | No | No |
| Approve within limit | No | Own plant | No | No | No |
| Release payment | No | No | Yes | No | No |
| View purchase orders | Own | Own plant | All | All, read-only | No |
| Change approval limits | No | No | Propose | No | Apply, logged |
| Export reports | No | Own plant | Yes | Yes | No |
Notice that the admin cannot view purchase orders or approve anything. Separating technical administration from business authority is deliberate.
Design approvals and segregation of duties
Segregation of duties means no single person can complete a sensitive transaction alone. Write these rules into the requirements:
- Maker-checker for master data: a change to a vendor's bank account needs a second person's approval before it takes effect.
- Conflicting roles: the person who creates a vendor should not approve payments to that vendor. The system should block such combinations, not merely warn.
- Configurable limits: approval thresholds and levels live in settings, not in code, so a policy change does not need a release.
- Delegation: an approver going on leave can delegate to a named colleague for fixed dates, and the record shows who approved on whose behalf.
- Escalation: requests waiting beyond an agreed time move to the next level automatically.
Plan single sign-on and the joiner, mover, leaver flow
Single sign-on (SSO) lets staff log in with their existing Microsoft Entra ID or Google Workspace account, usually through the SAML 2.0 or OpenID Connect standards. Password rules and multi-factor authentication are then enforced in one place, and disabling a user in the directory blocks their access to the application.
Decide these points early:
- Provisioning: are users created on first login, created by an admin, or synced automatically through SCIM, a provisioning standard many identity providers support?
- Role source: do directory groups map to application roles, or are roles assigned inside the application?
- Movers: when someone transfers from one plant to another, the old scope must be removed, not just the new one added.
- Leavers: what happens to their pending approvals and the records they own?
- Emergency access: a break-glass administrator account for when SSO is unavailable, tightly controlled and alerted on every use.
- External users: dealers, vendors and external auditors who are not in your directory need a separate login route and narrower rights.
Decide what the audit trail must record
An audit trail is only useful if it answers who did what, when, from where, and what changed. Plan it as a requirement, not an afterthought:
- Logins, failed logins and session ends.
- Every change to roles, scopes and approval limits.
- Master data changes with old and new values.
- Approvals, rejections and delegations.
- Exports, bulk downloads and record deletions, with deletions preferably reversible.
Logs should be append-only, readable by auditors but not editable by admins, and kept for a period agreed with your compliance team. If the application records books of account, check the audit trail (edit log) requirements under company law with your auditor; the Ministry of Corporate Affairs publishes these rules on mca.gov.in.
Mistakes that cause access control failures
- Checking permissions only in the user interface: hiding a button does not stop someone calling the API directly. Every rule must be enforced on the server. Broken access control sits at the top of the OWASP Top 10 for good reason.
- Hard-coding role names in code: new roles then need a developer.
- Reports that ignore data scope: a user blocked from a record on screen can still see it in an export.
- Shared admin logins: the audit trail then shows “admin” instead of a person.
- No access review: schedule a periodic review in which managers confirm who in their team should keep each role.
How EthicsComputer can help
Our enterprise software development work starts with a discovery workshop where roles, data scopes, integrations and audit needs are mapped and signed off with the architecture. If your systems must exchange data with ERP, HRMS or Tally, see our API development and integration service, and for an independent check of access control before go-live, web application VAPT tests for broken authorisation. Teams planning wider access policy can also read our zero trust architecture guide.
Mapping roles and approvals across several entities or plants?
Share your organisation structure and approval rules, and we will help you turn them into an access design your IT and audit teams can review.
About the author
Vinay Grover founded EthicsComputer in Rohtak, Haryana in 2018 and leads its cybersecurity, software and AI work for clients across India and abroad. EthicsComputer is ISO 9001, ISO/IEC 27001 and ISO 20000-1 certified.
