Acumatica Incident Response Runbook

Acumatica Incident Response Runbook is the Acumatica security topic that is invisible until it is breached. By the time you have a security incident, the questions are being asked at the board level and the answers are due yesterday. This guide is what to do before that point. It is the threat model, the controls, the operational hygiene, and the runbook that keeps the data safe and the auditors happy.

The threat model

Start with a clear threat model. Who can attack, what do they want, how do they get it?

The controls

Acumatica's security model is layered. The layers, from the outside in:

1. Network. Firewall, VPN, IP allowlist for the admin surface.
2. Authentication. Strong passwords, 2FA, SSO via Azure AD or Okta.
3. Authorisation. Role-based access control at the screen, row, and field level.
4. Audit. Every change logged, every login logged, every sensitive action logged.
5. Encryption. TLS in transit, encryption at rest for the database, field-level encryption for sensitive fields.
6. Data lifecycle. Retention policy, archival, secure deletion.

// Acumatica password policy
Minimum length: 12 characters
Require: upper, lower, number, symbol
Rotation: 90 days (privileged), 180 days (standard)
Lockout: 5 failed attempts, 15-minute lockout
Reuse: cannot reuse last 5 passwords

For the broader authentication configuration, see the 2FA and password policies guide and the Azure AD SSO guide.

API security

The REST API is the most common attack surface. The controls:

• OAuth 2.0, not cookie auth. For server-to-server; cookie auth only for trusted internal integrations.
• TLS everywhere. No HTTP, no self-signed certs in production.
• Rate limiting. Per-client rate limits, per-IP rate limits, exponential backoff on retry.
• IP allowlist. For the most sensitive endpoints (admin actions, fiscalisation), restrict to known IPs.
• Input validation. Acumatica does this; do not bypass it.

public class SecureApiClient
{
    private readonly HttpClient _http;
    public async Task<T> Send<T>(HttpRequestMessage req)
    {
        var token = await GetAccessToken();
        req.Headers.Authorization = new AuthenticationHeaderValue("Bearer", token);
        req.Headers.Add("X-Correlation-ID", Guid.NewGuid().ToString());
        var resp = await _http.SendAsync(req);
        resp.EnsureSuccessStatusCode();
        return await resp.Content.ReadFromJsonAsync<T>();
    }
}

For the broader OAuth pattern, see the OAuth setup guide. For the API security model, see the REST API definitive guide.

Row-level security

Acumatica's row-level security controls which rows a user can see within a screen. The configuration:

• Branch restrictions. The most common; restrict users to one or a few branches.
• Customer / vendor restrictions. Sales reps see only their customers; purchasing sees only their vendors.
• Custom restrictions. A custom DAC field on the user that determines which records they see.

For the full row-level security playbook, see the row-level security best practices and the GI row-level security guide.

Encryption

Three layers of encryption to consider:

public string Encrypt(string plaintext)
{
    if (string.IsNullOrEmpty(plaintext)) return plaintext;
    var key = _vault.GetKey("pii:encryption-key");
    using var aes = Aes.Create();
    aes.Key = key;
    aes.GenerateIV();
    var iv = aes.IV;
    using var encryptor = aes.CreateEncryptor();
    var plainBytes = Encoding.UTF8.GetBytes(plaintext);
    var cipherBytes = encryptor.TransformFinalBlock(plainBytes, 0, plainBytes.Length);
    return $"{Convert.ToBase64String(iv)}.{Convert.ToBase64String(cipherBytes)}";
}

For the broader secrets management pattern, see the secrets management guide.

Audit and monitoring

You cannot defend what you cannot see. The minimum audit configuration:

• Field-level audit on every field that contains PII, financial data, or access control data.
• Login audit — every login, every failed login, every password change.
• Action audit — release, approve, reject, cancel, void, delete.
• Configuration audit — every change to a role, a user, a workflow.

For the broader audit configuration, see the audit trail guide.

The incident response runbook

When (not if) a security incident happens, the runbook:

1. Detect. The alert fires. Confirm the incident is real (not a false positive).
2. Contain. Disable the affected user / API key / IP. Isolate the affected system.
3. Eradicate. Remove the attacker's access. Patch the vulnerability.
4. Recover. Restore from clean backup. Rotate all credentials. Verify integrity.
5. Notify. Notify affected parties (customers, regulators) per the regulatory timeline.
6. Post-mortem. Document the incident; identify the root cause; implement the control that would have prevented it.

Regulatory compliance

Most Acumatica deployments in Africa are subject to local data protection regulations (Kenya DPA, Rwanda data law, South Africa POPIA). The compliance checklist:

• Data mapping. What data do you collect, where is it stored, who has access?
• Data subject rights. How do you handle access requests, deletion requests, portability requests?
• Breach notification. What is the timeline, who do you notify, what is the format?
• Cross-border transfer. Are there restrictions on where data can be stored and processed?

For the broader compliance patterns, see the GDPR guide.

Wrapping up

Security is a discipline, not a product. The threat model, the controls, the audit, the runbook, the compliance — each is a habit, not a checkbox. The cost of doing it well is small and ongoing; the cost of doing it badly is large and sudden. Invest in the habit.