How to Audit User Access in a Business System

An access audit is a structured review of who can log into a business system and what they are allowed to do once inside. It is not a security penetration test and it is not a review of the permission model itself. It answers a narrower question: given the roles and permissions currently configured, are the right people holding the right level of access right now?

Most business systems accumulate access drift over time. Staff change departments, take on temporary responsibilities, leave, or are granted broad permissions during an implementation that are never tightened afterwards. An audit catches that drift before it becomes a compliance problem or a security incident.

Plan access around these control points

What an access audit actually covers

A thorough audit examines four things. First, the list of active user accounts and whether each account maps to a current employee or legitimate external user. Second, the role or permission set assigned to each account. Third, evidence that each assigned permission is required for the person's current duties. Fourth, a record of any administrative actions, such as permission changes or bulk imports, that took place during the audit period.

The audit does not redesign the permission structure. That is a separate piece of work covered under role-based or attribute-based access control planning. The audit simply checks whether the existing structure is being applied correctly.

When an audit is normally triggered

Access audits happen for several reasons. Regulatory requirements in sectors such as finance, healthcare and legal services often mandate periodic reviews. A supplier or client may request evidence of access control as part of a contract. Internal policy may set a quarterly or six-monthly cycle. Alternatively, an audit may be triggered by a specific event: a departure under difficult circumstances, a merger, or the discovery of a misconfigured permission during routine use.

Regardless of the trigger, the mechanics of the audit remain the same. What changes is the level of formality and the documentation required.

Preparing the data

Before reviewing anything, you need a reliable export of user accounts and their permissions. Most CRM systems, portals and admin panels can produce this, but the format and completeness vary. You typically need: username or email, full name, role or group membership, last login date, account status (active, suspended, locked), and the date the account was created or last modified.

If the system cannot export this directly, check whether the database can be queried safely in a read-only capacity. Avoid asking a supplier to email a spreadsheet of user data without considering whether that transfer itself creates a data-handling risk.

Reconciling accounts against a source of truth

The next step is comparing the system's user list against an authoritative record, usually the HR system or a staff directory. Look for accounts belonging to people who have left the organisation, accounts created for contractors whose engagements have ended, and duplicate accounts for the same person. Also check for service or integration accounts that may have been set up with excessive privileges and no clear owner.

For each mismatch, record the discrepancy and the action needed: deactivation, permission reduction, or confirmation that the account is legitimate despite not appearing in the HR feed.

Reviewing permission levels

With a clean account list, review what each person can actually do. Group accounts by role to make this manageable. If fifty people share the same role, verify the role once rather than fifty times. The question for each role is whether every permission in that role is necessary for the duties those people perform.

Pay particular attention to accounts with administrative or superuser access. These should be few in number, each with a named owner and a documented reason for holding that level of access. If a developer or supplier account has admin rights, check whether those rights are scoped to a non-production environment and whether they are removed after the work is complete.

Checking last-login activity

Accounts that have not logged in for an extended period are a common finding. An account dormant for six months or more usually indicates someone who has changed role or left without their access being removed. Dormant accounts with elevated permissions are a higher priority than dormant read-only accounts, but both should be investigated.

Some systems record only successful logins. If that is the case, a dormant account might still be active through an API token or a saved session. Check whether the system tracks token usage separately.

Documenting the findings

The output of an audit should be a record that a non-technical stakeholder can understand and that an external reviewer can verify. For each finding, note the account, the issue, the risk level, the remedial action and the person responsible for carrying it out. Retain this record for the period required by any applicable regulatory or contractual obligation.

Access-control mistakes and checks

Treating the audit as a one-off exercise

The most frequent mistake is running a single audit to satisfy a compliance request and then not repeating it. Access drift is continuous. Without a scheduled cycle, the system will return to the same state within months. Build the audit into operational routines rather than treating it as a project with an end date.

Auditing without the ability to fix what you find

Discovering that a former employee still has admin access is only useful if someone has the authority and the technical means to revoke it immediately. Before starting an audit, confirm who can make permission changes, whether those changes take effect instantly or require a deployment, and whether there is an approval process that might delay a urgent revocation.

Relying on the system's own reports without verification

Some systems provide a built-in access report. These are useful starting points but they reflect what the system believes its own configuration to be, which may not match reality. A permission might be assigned at group level and overridden at user level in a way the report does not show. Cross-check the system report against a direct database query or a secondary log where possible.

Overlooking integration and API accounts

Human users are the most visible accounts, but API keys, service accounts and webhook credentials often hold broad permissions and are rarely reviewed. Include these in the audit. For each, identify the owning system or team, the purpose, the permissions granted and whether the credentials have been rotated within a reasonable timeframe.

Ignoring shared or generic accounts

Accounts such as "info@", "admin" or "reception" are common in smaller organisations. They undermine the purpose of an audit because there is no individual accountability. Where they exist, document why they are necessary, who currently knows the credentials, and whether the same outcome could be achieved with named accounts and appropriate role assignments.

Key checks to include in every audit

• Every active account maps to a known person or a documented service requirement.
• No departed employee or ended contractor retains active access.
• Administrative accounts are individually assigned, justified and kept to the minimum necessary.
• Dormant accounts above a defined inactivity threshold are flagged for review or deactivation.
• API and integration accounts have identified owners and have had their credentials rotated within the policy period.
• Permission changes made since the last audit have a corresponding request or approval record.
• Findings from the previous audit have been resolved or explicitly accepted as residual risk.

Limitations to bear in mind

An access audit confirms what permissions are assigned, not whether those permissions are correctly implemented in the application code. A user might be assigned a "read-only" role while a bug in the system still allows them to edit records. The audit also does not confirm whether users are sharing credentials, which would make the account-level review unreliable. For systems where credential sharing is a known risk, supplement the access audit with behavioural checks such as impossible travel patterns or concurrent logins from different locations.

Finally, an access audit is a point-in-time snapshot. Between audits, access can change. Combining the periodic audit with automated controls—such as deactivating accounts when an HR record changes or alerting when a new admin account is created—reduces the window of exposure.