Your ERP concentrates the most sensitive financial, payroll, procurement, and commercial data in your organisation. Yet one question surfaces consistently during internal audits: how many active user accounts in your ERP actually belong to people who left the company six months, a year, or longer ago?
ERP access governance — the living process that defines who gets which rights, when, and for how long — is the blind spot of most implementation projects. IT teams configure roles at go-live, then day-to-day management falls back on managers who don’t report departures, HR running a separate process, and an overstretched IT department approving access requests without removing old ones. Within a few years, the actual state of active rights in the ERP diverges completely from organisational reality.
This article does not cover Segregation of Duties (SoD) controls in themselves — for that, read our guide to the 12 SoD controls to implement before your annual audit. The focus here is the governance process: how to structure onboarding, account lifecycle, periodic reviews, and offboarding so that ERP rights permanently reflect your organisational reality.
Why ERP Access Governance Is Neglected — and Dangerous
Ghost Accounts: A Concrete and Underestimated Risk
A “ghost account” is an ERP user account that remains active after its owner has left. This phenomenon is far more widespread than most organisations realise. Internal audits of mid-market companies without a formalised offboarding process regularly uncover accounts belonging to employees or contractors who departed more than six months ago — still active, still carrying unrevoked rights. This is not a theoretical extrapolation; it is a recurring finding from internal auditors and ERP integrators during pre-audit assessments.
Ghost accounts create several overlapping risks:
- Fraud risk: A former employee who remembers their credentials can continue accessing the ERP after departure. If the account isn’t monitored, activity can go unnoticed for weeks.
- GDPR risk: An active account grants access to personal data of employees, customers, and suppliers. Article 5(1)(f) of the GDPR requires integrity and confidentiality of data, which includes restricting access to authorised persons only.
- NIS2 risk: The NIS2 Directive requires essential and important entities to implement access controls and identity management policies under Article 21(2)(d). Orphaned accounts constitute a direct non-compliance.
- SOX risk: For US-listed groups and their significant subsidiaries, Sarbanes-Oxley Section 404 requires documented and periodically reviewed access controls. Accounts not revoked upon departure are an audit finding with impact on Internal Control over Financial Reporting (ICFR).
How This Differs from SoD Controls
The SoD matrix defines which combinations of rights are incompatible. Access governance defines which process ensures that the right users have the right rights at the right time. The two topics are complementary: a perfect SoD matrix is useless if some active accounts are ghost accounts, or if roles accumulate unchecked with each internal move.
Phase 1 — Onboarding: Creating an ERP User Account Safely
The Access Request RACI Matrix
Creating an ERP account should never be an informal action triggered by an email to IT. For an account to be created with the right rights — and nothing more — four roles must be clearly assigned using a RACI matrix:
| RACI Role | Actor | Action |
|---|---|---|
| Responsible | ERP Admin / IT | Creates the account, assigns profiles, documents in the access register |
| Accountable | IT Director or CISO | Validates that the request complies with the access policy and SoD matrix |
| Consulted | Business Manager | Confirms the modules and permission levels strictly needed |
| Informed | HR | Receives confirmation that the account is created — sync with the employee file |
The access request form must include at minimum:
- Full name and HR identifier of the future user
- Start date and expected duration (permanent, fixed-term, contractor with mandatory end date)
- ERP module(s) concerned and requested permission level
- Suggested role profile or template (never “full access to finance” but “Junior Controller profile”)
- Business manager signature (formal approval)
That last point is critical: the request must not say “give them access to accounting” but “apply the Junior Controller profile, which grants read access to journals and entry rights for expense reports, with no approval rights”. The precision of the requested profile is what prevents rights drift from day one.
Predefined Role Templates and Non-Accumulation Rules
Ad-hoc access requests are the enemy of governance. Each exception creates a unique profile that is hard to maintain and impossible to verify in bulk during a recertification campaign. Best practice is to define role templates by job function, aligned with your SoD matrix:
- Junior Buyer: purchase request entry, supplier catalogue lookup, no order approval or payment access
- Procurement Manager: order approval up to a defined threshold, supplier management excluding creation, no access to the payment module
- Financial Controller: read access to all journals, BI export, no accounting entry or approval rights
- Warehouse Operator: inbound and outbound stock movements, no access to purchase prices or pricing terms
In SAP, these templates correspond to roles configured via transaction PFCG. In Odoo, they are the access groups configurable per module. In Dynamics 365, they are security roles.
Core non-accumulation rules to embed in your templates at go-live:
- Supplier creation AND supplier payment approval: prohibited
- Purchase order entry AND goods receipt AND supplier invoice approval: at least two of these functions must be held by distinct profiles
- ERP user creation AND access rights approval: the administrator must not be their own approver
Phase 2 — Account Lifecycle: Managing Role Changes and Scope Updates
Handling Promotions and Internal Transfers
The real problem in access governance is not onboarding, which is at least partially addressed at go-live. It is the silent modification of rights during internal moves that generates drift.
The common mistake: when someone is promoted, the manager asks to add the new rights but forgets to flag the old rights for removal. After two or three transfers, the user accumulates rights that no longer correspond to any current role. In audit language, this is called silent privilege creep, and it is one of the most common findings during access reviews.
Recommended process for any role change:
- The manager or HR triggers an access modification request — using the same form as the initial request, with an explicit field for “rights to remove”
- The ERP admin applies the new profile and explicitly removes the old profile in the same operation
- The change is documented with date and management approval
- The user receives email confirmation (audit trail and awareness)
In SAP, transaction SU01 allows modifying a user’s roles and enabling automatic lockout after N days of inactivity (parameters login/failed_user_auto_unlock and login/password_expiration_time in the logon profile). In Odoo, user management lives under Settings > Users & Companies > Users — archiving the account preserves the audit trail; deletion removes it.
Temporary Rights: Delegation and Substitution Access
Managing extended absences is a particularly delicate edge case. When a procurement manager goes on six-month parental leave, their replacement needs those rights — but only for the duration of the absence, and without stacking incompatible rights if they already hold another position.
Recommended rules for temporary access:
- Maximum duration without explicit renewal: 3 months. Beyond that, the request must be renewed with fresh manager approval confirming the situation hasn’t changed.
- Mandatory review on the absent employee’s return. The temporary account must be deactivated on the day of return — not a week later.
- No stacking with incompatible permanent rights. A senior accountant temporarily covering for the CFO must not end up approving their own journal entries.
These temporary access grants must be logged in a separate register (a spreadsheet suffices for SMEs), with start date, expected end date, and the identity of the person responsible for the review.
Phase 3 — Periodic Review: Running an Access Recertification Campaign
Recommended Frequency
Access reviews are mandatory for entities subject to SOX, NIS2, ISO 27001, and SOC 2. Frequency varies by risk profile of each user population:
| User Profile | Recommended Frequency |
|---|---|
| All active users | Annual |
| ERP administrators and super-users | Quarterly |
| Profiles with extended financial rights (CFO, senior financial controllers) | Quarterly |
| Contractor and integrator accounts | At end of each engagement + quarterly review |
| Service accounts and batch accounts | Semi-annual |
A “continuous” event-driven review is triggered by departures and role changes. It does not replace scheduled periodic reviews; it complements them.
Conducting the Review with Business Managers
The access review cannot be carried out by IT alone: business managers are the only people who know whether a given user still needs a given access. The recommended four-step process:
Step 1 — Export active accounts
Export from the ERP the full list of active accounts with their last login date, role profile, and creation date. In SAP, transaction SUIM generates this report. In Odoo, a query on the res.users table filtered on active = true produces the equivalent. In Dynamics 365, the report is available from the Power Platform admin centre.
Step 2 — Send the questionnaire to managers
For each user on their team, the manager answers a simple question: “Does this user still need these ERP rights?” with three options:
- Retain: the rights match the current role
- Modify: certain rights need to be added or removed (specify which)
- Revoke: the user no longer needs access to this module or to the ERP
Step 3 — Apply decisions and document
Each modification or revocation decision is applied within five business days and documented with the date, identity of the person who made the change, and management approval.
Step 4 — Campaign closure report
A summary document is produced: number of accounts reviewed, modifications applied, revocations, manager response rate. This document is the evidence that the review took place — essential for ISO 27001, SOC 2, or SOX audits.
Phase 4 — Offboarding: 7 Steps to Deactivate an ERP Account Without Leaving a Trace
Offboarding is the most critical and most frequently botched step. Here is the seven-step process:
-
Early notification (D-5 to D-1 before departure): HR informs IT of the effective departure date along with the list of systems the user can access. This trigger must not depend on the manager’s initiative — it must be automatic, via an HR workflow or integration with the HRIS.
-
ERP account deactivation on departure day, before the employee leaves the premises: the account is deactivated, not deleted. In SAP, transaction SU01 allows locking a user. In Odoo, use the archive function via Settings > Users > Archive. Account deletion should be avoided: it destroys the audit trail of past actions, which can be problematic during a tax audit or internal investigation.
-
Transfer of pending tasks: verify that no approvals or in-flight workflows are blocked on this account. If so, reassign them to the appropriate owners before the deactivation takes effect.
-
Revocation of peripheral access: API tokens, mobile ERP access, associated VPN sessions, supplier or customer portal credentials. These peripheral accesses are frequently overlooked, yet they can provide indirect routes into ERP data.
-
Account archiving: the deactivated account and its historical rights are retained in ERP logs for a duration corresponding to applicable legal obligations. For details on retention periods by country and framework, see our guide on ERP audit trail obligations.
-
Contractor accounts — accelerated timeline: deactivation must occur on the last day of the engagement, with no grace period. VPN access and API tokens must be revoked same-day. A contractor who retains active ERP access after their engagement ends exposes the organisation to GDPR, contractual, and liability risk in the event of an incident.
-
Deactivation logging: the deactivation itself must be traced — date, time, identity of the admin who performed it, reason (voluntary departure, termination, end of contract). This log is the proof that the offboarding process worked, verifiable during an audit.
Note on service accounts: accounts used for batch jobs, system integrations, or APIs do not follow the human offboarding process. They must be inventoried separately, protected by regular password rotation — ideally via a PAM solution, as described in our Zero Trust and IAM guide for ERP — and reviewed during dedicated semi-annual campaigns.
IGA Tools: Which Identity Governance Platform to Use?
IGA (Identity Governance and Administration) refers to software solutions that automate and centralise access management. The market breaks into three tiers based on company size and budget:
Native solutions in major ERPs:
- SAP GRC Access Control: comprehensive solution for SAP ECC and S/4HANA environments. Includes real-time SoD conflict analysis, approval workflows, and automated recertification campaigns.
- Oracle Identity Governance (OIM): Oracle’s equivalent for E-Business Suite and Fusion Applications environments.
Third-party solutions with ERP integration:
- Saviynt: cloud IGA platform with native connectors for SAP, Salesforce, ServiceNow, and major ERP systems.
- SailPoint IdentityNow: SaaS solution with machine learning capabilities to detect access anomalies.
- Omada: specialised in Microsoft environments (Entra ID, Dynamics 365) and SAP, well-suited for European mid-market companies.
For SMEs and mid-market companies without an IGA budget:
| Company Size | Recommended Approach |
|---|---|
| SME (< 100 ERP users) | Access tracking spreadsheet + monthly ERP export + formalised email workflow |
| Mid-market (100–500 users) | ITSM ticketing tool (GLPI, Jira Service Management) + ERP export + structured quarterly review |
| Large enterprise | Dedicated IGA solution (Saviynt, SailPoint, Omada, SAP GRC) |
The tool is not the essential element: what matters is the existence of a formal, documented, and consistently applied process. A rigorously maintained spreadsheet is more useful during an audit than an IGA solution that was poorly configured and never used.
Template — ERP Access Process Sheet
This summary table can serve as the basis for your internal process document, versioned and approved by your CISO:
| Triggering Event | Required Action | Owner | Maximum Timeframe |
|---|---|---|---|
| New hire / role start | Access request + manager approval + account creation | ERP Admin / IT | Start date |
| Internal role change | Add new rights + remove old rights | ERP Admin / IT | 5 business days |
| Extended absence (> 1 month) | Create temporary access for substitute with expiry date | ERP Admin / IT | Before absence begins |
| Return from absence | Deactivate substitute’s temporary account | ERP Admin / IT | Day of return |
| Employee departure | Account deactivation, peripheral access revocation, archiving | ERP Admin / IT | Departure day |
| Contractor end of engagement | Account deactivation, VPN and API token revocation | ERP Admin / IT | Last day of engagement |
| Quarterly review | Active account export + manager questionnaire + decision application | IT / CISO | Within 15 calendar days |
Quarterly IT/CISO Control Checklist:
- Active accounts with last login > 90 days: identify, send to managers for retain-or-revoke decision
- Contractor accounts: verify each account has a current end-of-engagement date in the access register
- Service and batch accounts: verify passwords have been rotated within the last six months
- ERP administrator profiles: verify the admin account is not used for daily business operations
- Number of users with “super-user” or equivalent profile: maintain at the strict justified minimum
- Accounts locked for more than 30 days: decision to permanently deactivate or retain with documented justification
Well designed and consistently applied, ERP access governance is one of the highest-return security measures available. It does not require a large software budget for an SME or mid-market company: it requires a clear process, assigned responsibilities, and execution discipline. That is precisely what most organisations lack when an external auditor opens the access register.
To go further, read our Zero Trust and IAM guide for ERP and our guide to the RACI matrix in ERP projects.
Download our complete ERP guide — 60 pages of methodology, scoring grids, and operational templates to frame your ERP project or prepare your next access audit.
