What do teams get wrong about reviewing access to ERP and database systems like Lawson and MS SQL Server?

Teams often treat access review as a periodic checkbox instead of a control that must stay current with staffing and system changes. That leads to stale entitlements, inactive accounts, and missing evidence. The bigger mistake is relying on spreadsheets or ad hoc tracking, which do not scale well and make it harder to prove who had access, when, and why.

Access Review Fails When It Is Treated as a Snapshot

For ERP and database platforms, the mistake is assuming an access review is only about confirming names on a list. The real control is whether the list still matches current job roles, active projects, vendor relationships, and system ownership. If the review does not reconcile those changes, it will approve access that should already have been removed.

That is why access review quality depends on the underlying entitlement model, not just the reviewer’s diligence. When teams only check whether an account exists, they miss the difference between dormant access, inherited permissions, and direct grants that still allow sensitive functions such as posting, exporting, or administrative change.

Review the entitlement source, not just the exported user list, because inherited access can hide the real privilege path.
Check whether the business reason for access still exists, especially after transfers, role changes, go-live periods, and contractor offboarding.
Confirm that the review covers system-specific privileges, not only account status, because a valid login can still carry excessive power.

Why Spreadsheets and Ad Hoc Tracking Break Down

Manual tracking is usually the second failure point. Spreadsheets can work for a small population, but they become unreliable once access spans multiple environments, multiple approvers, and recurring recertification cycles. They also make it hard to prove whether the review was complete, timely, and based on the current system of record.

That matters for ERP and database systems because the evidence problem is as important as the access problem. If teams cannot show who reviewed which entitlement, what changed, and what was remediated, the review may look performed but still fail as an audit-ready control. A system-supported workflow gives you a better trail than email chains, copied tabs, and manually merged exports.

For teams that need a deeper reference point on governance, lifecycle, and visibility, Ultimate Guide to NHIs is useful because the same control failures show up whenever access is not continuously reconciled with actual use. The broader point is that review quality depends on inventory, ownership, and revocation discipline, not on the format of the tracker.

What Good Review Practice Looks Like for ERP and SQL Access

Good review practice starts with scoping the right access objects. For systems like Lawson and MS SQL Server, that usually means users, service or integration accounts, database roles, application roles, privileged groups, linked application access, and any indirect rights that can reach production data or change configuration.

Teams should compare what the identity can actually do against what the business claims it should do. A clean review asks whether the access is still needed, whether the level is still appropriate, and whether the account is tied to a real owner who can attest to its use. If the answer is unclear, the safe default is to investigate before certifying.

Map each account to an owner and a use case before the review begins.
Separate active human access from non-interactive or shared access so the reviewer sees the true risk profile.
Require evidence of removal for revoked access, not just a checkbox showing approval.
Reconcile reviews against HR, vendor, and application-change events so staffing changes are reflected quickly.

One practical signal is whether the team can produce a defensible, current evidence trail without reconstructing the decision from memory. If that takes manual detective work every cycle, the process is too brittle to trust.

Risk and Threat Considerations

Stale ERP and database access creates a direct path to unauthorized viewing, data extraction, and privileged change. The risk is highest where old accounts remain active, privileges accumulate over time, or shared and service-style access is not reviewed with the same rigor as named users.

Failure mechanism: Access reviews miss entitlements that are no longer justified, so removed staff, contractors, or former project participants retain valid access paths that can be abused deliberately or discovered later through internal misuse or compromise.

Impact: Unnecessary access expands the blast radius of a compromised credential, weakens segregation of duties, and increases the chance that financial, operational, or regulated data can be altered or exported without timely detection.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	6 — Access Control Management	Directly governs reviewing, approving, and revoking system access.
	8 — Audit Log Management	Supports proving who changed access and when on ERP and database systems.
	5 — Account Management	Applies to finding inactive, orphaned, or excessive accounts in review cycles.
Recommendation — Automate access recertification and remove unnecessary accounts and privileges promptly. Retain review and change evidence in logs that can be independently audited. Inventory and remove inactive or orphaned accounts before recertifying access.
NIST CSF 2.0	PR.AC — Identity Management, Authentication and Access Control	Covers maintaining current access and limiting privileges to business need.
	GV.RM — Risk Management Strategy	Applies because stale privileged access creates governance and exposure risk.
Recommendation — Align ERP and database access to current identity, role, and privilege requirements. Treat access review failures as measurable governance risk, not just administrative misses.

Practitioner Guidance

What to verify: Make sure the review covers the actual entitlement source, including role inheritance and indirect database permissions, not only exported account names. If a reviewer cannot trace the path from identity to effective access, the certification is not reliable.

Decision rule: If the account can reach production data, alter transactions, or administer the platform, treat missing ownership or stale business justification as a remediation item, not a review note. High-impact access should be removed or constrained before it is merely re-approved.

Practitioner takeaway: The goal is not to complete a periodic review, it is to keep access evidence aligned with real business need and real system behavior so stale privilege does not become accepted normality.