When employees have more access than they need, accidents happen—a clerk might accidentally delete important customer data, or a disgruntled staff member could steal client information. A real scenario: a Delhi-based logistics company gave all warehouse staff access to the pricing module; one employee copied prices to start a competing business. Beyond theft, you fail customer audits (e-commerce platforms now require proof of access controls), lose contracts, and face RBI/financial sector penalties if you handle regulated data. Your insurance may not cover breaches caused by negligent access management.
Find where your organisation is today. Be honest — the self-assessment is only useful if it reflects reality.
Absent
You find that almost everyone who uses a software system has the same broad permissions—all accounting staff can approve payments, all HR staff can view everyone's salary, all sales staff can modify prices. No one has documented who should have what access, and you don't know why each person was given their current permissions.
Initial
You have a basic list of who has access to which systems, but permissions are set generically (e.g., 'accountant' role gets a fixed set of permissions). You manually check this list maybe once a year, and there's no formal process for removing access when someone changes jobs or leaves the company.
Developing
You have documented which permissions each job role should have (e.g., 'junior accountant can view invoices but not approve payment' vs. 'senior accountant can approve up to ₹50,000'). When new people join, you use these role descriptions to set their access, but you don't regularly review whether current permissions still match what people actually do.
Defined
You review access rights every quarter or when someone changes roles; you compare what people have access to against what their job actually requires and remove extra permissions. You have a form that managers sign off on when approving access for new hires, and you keep records of approvals.
Managed
Your access review is monthly or tied to quarterly business reviews. When someone changes roles internally, you formally review their access before and after the move. Your application or system keeps audit logs showing who accessed what data, and you spot-check these logs monthly for unusual activity.
Optimised
Access rights are reviewed automatically every month using data from your HR system and job descriptions; managers get alerts about staff whose access doesn't match their current role. You have automated rules in place (e.g., contractors' access expires automatically after their contract end date), and access changes are logged in a central audit system that's checked by leadership or an external auditor quarterly.
| Step | What to Do | Who | Effort |
|---|---|---|---|
| 0 → 1 | List every person and every software system they use, then write down what permissions each person currently has. Interview system administrators or IT staff to understand why each person got those permissions. | IT person or business owner (with IT help) | 3-5 days |
| 1 → 2 | For each software system (accounting software, HR system, CRM, etc.), define job roles and the specific permissions each role should have. Write this down in a simple spreadsheet or one-page document per system. Have department heads review it and sign off. | IT person with input from department heads | 1-2 weeks |
| 2 → 3 | Create a quarterly access review calendar: pick one system each month, list all users, compare their actual permissions to what their current role should have, and remove excess access. Have the department head sign off on the review. Keep copies of these reviews. | IT person with department manager sign-off | 2-4 weeks (ongoing quarterly effort: 2-3 hours per quarter) |
| 3 → 4 | Enable audit logging in your key software systems (accounting, HR, customer databases). Set up a monthly report showing who accessed sensitive data (e.g., salary information, customer contact details) and review it for unusual patterns. Document and investigate any suspicious access. | IT person with CFO or data owner review | 1-2 months (setup) + 2-3 hours monthly |
| 4 → 5 | Integrate your HR system with your software applications so that when someone's role changes in HR records, their access rights automatically update; set expiry dates for contractor access; set up an automated monthly report to leadership showing access exceptions. Bring in an external auditor annually to verify the system is working. | IT vendor or consultant with IT staff oversight | Ongoing (implementation 2-3 months, then 1-2 hours monthly) |
Documents and records that prove your maturity level.
- Written access control policy: which permissions each job role should have in each system (spreadsheet or document, signed by department heads)
- User access list: for each system, a current list of all users and their permissions, refreshed every quarter
- Quarterly access review records: signed-off documentation showing that you checked who had access vs. what they should have, dated and approved by managers
- Role change log: when staff move jobs internally, a record showing their old permissions were revoked and new ones were assigned (and by whom, and on what date)
- Audit logs from key systems: at least 6-12 months of records showing who accessed what data, when, and what they did (if your system supports this)
Prepare for these questions from customers or third-party reviewers.
- "Show me a list of all the different job roles in your company and tell me exactly what permissions each role has in your accounting software. How did you decide these permissions?"
- "Pick one person at random—an accountant, sales person, and HR staff member. Show me what access they have right now. Do they need all of it to do their job?"
- "When a person gets promoted or changes departments, walk me through the process you use to update their access. Do you remove access they no longer need?"
- "If I look at your audit logs for your customer database or salary records, will I be able to see who accessed them, when, and whether the access was appropriate for their role?"
- "When was the last time you reviewed who has access to your systems? What did you find, and what did you change?"
| Purpose | Free Option | Paid Option |
|---|---|---|
| Track and manage user access to cloud applications (Salesforce, SAP, Workday, Office 365, etc.). Shows you who has what access and flags unusual patterns. | Okta open-source tools or your system's built-in user management (limited reporting) | Okta Identity Platform (₹1,50,000–5,00,000/year), Microsoft Entra ID Premium (₹10,000–50,000/year per user) |
| Audit and compliance: collect logs from all your software systems and highlight suspicious access (e.g., someone accessing salary data at 2 a.m.). | Wazuh (open-source SIEM, requires setup time) | Splunk (₹5,00,000+/year), Microsoft Sentinel (₹10,000–50,000/month), Datadog (₹3,00,000+/year) |
| Manage access to on-premises servers and databases. Useful if you have a local server with customer or financial data. | Linux built-in tools (sudo, SSH key management) or Active Directory Community Edition | Microsoft Active Directory/Windows Server Licensing (₹20,000–2,00,000/year), Delinea (formerly Thycotic) Privilege Manager (₹3,00,000+/year) |
| Simple spreadsheet-based tracking for small teams: document roles, permissions, and review dates without spending on new tools. | Google Sheets, Excel with shared review process | — |
- Giving all employees in a department the same broad permissions because it's 'easier than managing individual access'—this creates risk because one disgruntled employee can damage the entire department's data.
- Never removing access when people leave or change jobs. Many Indian companies lose data through old employee accounts because no one tracked who had permissions and never formally revoked them.
- Creating role-based permissions once and never revisiting them as the business grows. A person hired as 'junior' five years ago may have accumulated permissions beyond their actual job, and no one realized it.
- Assuming that because access is restricted, there's no need for audit logs. When something goes wrong, you have no way to trace who did what, making investigations and customer breach notifications very difficult.
- Not involving managers in access review. Finance or IT decide what access is 'right,' but only the manager knows what their team members actually do day-to-day, leading to permissions that don't match reality.
| Standard | Relevant Section |
|---|---|
| DPDP Act 2023 | Section 8(2)(e): requirement to implement and maintain reasonable security standards including access control and need-to-know basis; Section 6(2): processing data only for stated purposes |
| CERT-In 2022 | Section 4.3: 'User access management and accountability'; Section 5: requirement for organizations to maintain access logs |
| ISO 27001:2022 | Annex A: A.8.1 (User access management), A.8.2 (User responsibilities), A.8.3 (Password management); Clause 6.2 (Define security requirements including access controls) |
| NIST CSF 2.0 | Govern (GV) and Protect (PR) functions: AM.1 (Asset management), AC.1 (Access control policies), AC.2 (Physical and logical access control) |
Ready to assess your organisation?
Answer all 191 questions and get your NIRMATA maturity score across all 12 pillars.
Start Free Self-Assessment →