Know who entered the ERP, what they accessed, and what they changed

The capability inside Simor ERP

System Audit records login and logout, page viewing, denied access, data changes, exports, and cleanup execution. Access to the audit area is reserved for Auditor and SuperAdmin roles. Financial Audit remains separately located in Accounting for FinanceAuditor and SuperAdmin responsibilities.

The distinction matters: an export or denied page request is operational-security evidence, while a changed journal or financial integrity event needs accounting context.

Investigations users commonly need

An investigation begins with a question, not a download of every event. Examples include who last changed a record, whether a user reached a restricted page, what was exported before an account was disabled, or why a cleanup job removed old entries. Filters should narrow by user, event, area, object, outcome, and time without exposing unrelated data.

Role history changes the interpretation

A successful action should be evaluated against the permissions assigned at that time. Current roles may differ from historical roles, so role assignment and removal history can be important evidence. Denied access is also useful: it demonstrates that a control intercepted an attempted action rather than proving a breach.

Sign-in information supports dormant-account review and investigation, but login events alone do not describe business activity. Page views, data changes, exports, permission failures, and administrative operations need distinct event types. Sensitive values, credentials, tokens, and unnecessary personal information should not be copied into log messages.

Retention, performance, and cleanup

Audit volume grows quickly. Retention should reflect operational, contractual, privacy, and legal needs, with older records archived or removed through an authorized process. Cleanup must create its own record showing scope, policy, actor, and result; otherwise maintenance becomes a way to erase evidence silently.

Simor ERP can record Login/Logout, page access, denied requests, data changes, exports, and cleanup activity. System Audit is restricted to Auditor and SuperAdmin roles, separate from the FinanceAuditor view used for financial evidence. Implementation should test enforcement at the server layer, not only whether a menu item is hidden.

Background reading: Microsoft guidance on security, database logging, retention, and segregation of duties and security and role audit reports.

Why was access denied?

Review the user, role, requested area, time, and applicable permission. Repeated denials may indicate incorrect setup, training needs, or suspicious behaviour.

Who exported this information?

Exports can move data outside normal screens. Record the user, time, page or dataset, and relevant filters where the implementation supports them.

What changed before the problem appeared?

Connect data-change events with the business record and surrounding activity. An audit record should assist investigation without exposing sensitive values to unauthorized reviewers.

Avoid two audit extremes

Under-logging leaves important actions unexplained. Over-logging creates noise, privacy exposure, storage growth, and slow investigations. Define event categories, severity, retention, access, archive, and cleanup rules according to operational and legal requirements.

Validation scenarios

Alerting should be selective. Repeated denied access, unusual bulk exports, privileged role changes, or cleanup outside the normal schedule may deserve prompt review, while routine page views can remain searchable evidence without generating constant notifications.

• Successful and failed login, logout, and session expiry.
• Allowed and denied access to a protected page.
• Create, update, status change, and attempted unauthorized action.
• Export by an authorized user and blocked export by another role.
• Role or user-status change followed by permission enforcement.
• Cleanup or archival with protected retention boundaries.

Customization and integration

Simor Soft can adapt event categories, search filters, dashboards, alerts, retention, archive, identity integration, and incident workflows. The design should capture useful evidence without claiming that logging alone prevents misuse.

Example: investigating an unexpected export

An administrator may need to determine whether a user signed in, reached a restricted page, changed filters, exported a dataset, or was denied access. A useful system audit record separates these events and captures the actor, time, action, relevant object, outcome, and request context without storing secrets or unnecessary personal data.

The investigation should connect activity with the role and permission model that applied at the time. A denied action can demonstrate that a control worked; a successful export may be legitimate but still require review because of its scope. Retention and cleanup jobs must also be auditable so evidence does not disappear without policy and authorization.

Test the workflow with a failed login, role change, rejected page request, record edit, bulk export, and privileged cleanup. Confirm that Auditor and SuperAdmin access is enforced outside the user interface, that ordinary users cannot rewrite the records, and that filters can isolate the sequence without presenting unrelated sensitive information.

Security-event and audit-log verification

Use separate test accounts to generate successful login, failed login, logout, page view, denied access, record creation, update, export, role change, and cleanup events. Confirm that timestamps, user identity, action, object, outcome, and useful context are present while passwords, tokens, and unnecessary sensitive values are absent.

Change a user’s role midway through the test and verify that later investigation can understand both permission states. Disable the account, attempt access again, and review dormant-user indicators. Auditor and SuperAdmin roles should be able to investigate, while ordinary users should neither browse nor modify protected history.

Apply retention and cleanup to a controlled date range. The operation should report what was archived or removed, under which policy, by whom, and with what result. Performance should remain acceptable with realistic event volume and filters, because an audit log that cannot be searched is weak operational evidence.

Connect audit with access control

Review Financial Audit, read about ERP roles and permissions, or inspect Simor ERP security and licensing.