Acumatica Incident Response Runbook

A security incident on an ERP is not a code problem, it is a time problem. The minutes between "something looks wrong" and "we have contained it" are where the damage is either stopped or compounded, and nobody makes good decisions inventing the plan while a compromised account is exporting your customer list. This is the runbook I keep for Acumatica: what to do, in order, using the tools the platform already gives you — the audit trail, login history, access rights, and API activity — so the response is mechanical rather than improvised.

What counts as an incident

Define this before you need it, because in the moment everything looks either trivial or catastrophic and neither judgement is reliable. An incident is any of: a login you cannot attribute to a real user, a role or access-rights change nobody requested, a mass export or bulk record change outside normal hours, a new integration or API user you did not create, or unexpected outbound email from the tenant. A single failed login is noise. Fifty failed logins against one account followed by a success is an incident. Write the list down and give it to whoever watches the system, so the escalation is triggered by a rule, not by a feeling.

Contain first, investigate second

The instinct to understand what happened before acting is the wrong one under active compromise. Containment comes first. In Acumatica that means, in order: disable the suspect user on the Users (SM201010) screen (set the account inactive rather than deleting it — you need it for the investigation), force a logout by revoking active sessions, rotate any shared or integration credentials the account could reach, and if an API token or OAuth client is implicated, revoke it under Connected Applications (SM303010). Only once the door is shut do you start reconstructing what came through it.

Reconstruct with the audit trail

Acumatica's built-in audit (configured under Audit (SM205510)) records inserts, updates, and deletes on the tables you have enabled it for, with the user, timestamp, and old/new values. If audit was turned on for the affected screens before the incident, this is your primary evidence. Pull the changes for the suspect user across the incident window and reconstruct the sequence. If you need to go wider than the audited tables, the platform login history and the AU audit history tables are queryable directly against the database.

-- Login history for a suspect user across the incident window
SELECT lh.Username, lh.LoginDateTime, lh.LogoutDateTime,
       lh.ClientAddress, lh.LoginResult
FROM   Login lh
WHERE  lh.Username = @Username
  AND  lh.LoginDateTime BETWEEN @From AND @To
ORDER  BY lh.LoginDateTime;

-- Field-level changes captured by the audit engine
SELECT ah.CreatedDateTime, ah.CreatedByID, ah.TableName,
       ah.FieldName, ah.OldValue, ah.NewValue
FROM   AUAuditHistory ah
WHERE  ah.CreatedDateTime BETWEEN @From AND @To
ORDER  BY ah.CreatedDateTime;

Treat these queries as read-only forensics. Run them against a replica or with care against production, and export the results to a file that lives outside the tenant — you want the evidence somewhere the attacker cannot reach even if they still have a foothold.

Check what access changed

A common second stage of an account compromise is privilege escalation: the attacker adds themselves to a powerful role or creates a fresh admin. Review recent changes on User Roles (SM201005) and Access Rights by Role (SM201025), and look for any user added to the Administrator role or granted rights to the integration and export screens. If your audit configuration covered the security tables, the who-and-when is already recorded; if not, this is the gap to close after the incident.

Assess data exposure

The hardest question a stakeholder will ask is "what did they see or take". Narrow it with evidence rather than guessing. Look at the request log and any Web Services / OData API activity for large or unusual pulls, check whether generic inquiries or reports were exported, and review email history for outbound messages the account sent. If you have request-level logging in front of Acumatica (a reverse proxy or WAF), correlate the suspect client address from the login history against response sizes to spot bulk extraction. Document what you can prove was accessed and, separately, what was reachable but shows no evidence of access — regulators and customers care about the distinction.

Recover and harden

Recovery is not just re-enabling the account. Rotate every credential the incident could have exposed, including integration users and any secrets stored in the tenant. Reverse unauthorised data changes using the audit old-values as the source of truth. Re-enable the user only after forcing a password reset and confirming two-factor is enrolled. Then close the specific gap that let it happen: if 2FA was optional, make it mandatory; if audit was off on the affected screens, turn it on; if a shared integration account was used interactively, split it into a service account with least privilege.

The runbook at a glance

Wrapping up

The value of a runbook is that it turns a panic into a checklist. None of the individual steps here are exotic — deactivate, query the audit, rotate secrets, reverse the changes — but doing them in the right order, quickly, and with the evidence captured is the difference between an incident and a disaster. Write your version down now, enable audit on the screens that matter, and make 2FA non-optional, so the worst day is one you have already rehearsed. If you want a second pair of eyes on your Acumatica security posture, reach out or keep reading through the rest of the Acumatica blog.