Acumatica Data Loss Prevention — A Complete Guide

Data loss prevention in Acumatica is less about a single feature and more about closing off the many small ways data leaves the system without anyone noticing — an export nobody logged, an integration with too-broad an API scope, an attachment quietly synced to a personal cloud drive. Acumatica gives you the primitives to control most of these; DLP is the discipline of actually turning them on and reviewing them.

Restricting export and print access

Every grid in Acumatica supports export to Excel by default, and every user with access to a screen can generally export whatever that screen shows them. Access rights on the Access Rights by Role (SM201020) screen let you restrict this per role — you can grant a role "View Only" without export, which stops the casual bulk-export path while still letting people do their job on-screen. This matters most for screens exposing customer PII, banking details, or payroll data, where "can see it in the UI" and "can download 50,000 rows to a laptop" should not be the same permission.

Restricted fields

Beyond screen-level access, Acumatica supports field-level security through the same role-based access configuration — specific fields on a DAC can be hidden or masked for roles that don't need them, independent of whether the role can see the rest of the record. This is the right tool for something like a partial bank account number that a sales rep never needs but AP does.

Attachment and file controls

Files attached to Acumatica records — invoices, contracts, ID scans — are stored either in the SQL Server FileStore or, if configured, in Azure Blob/S3-backed storage. Two things matter for DLP here: who can attach and detach files (a role-scoped permission, not universal), and where that storage sits — an on-prem FileStore under your own backup and access policy is a different risk profile than a loosely-configured public blob container. If you've wired attachments to external storage, verify the bucket or container is not publicly readable; this is a common oversight when storage is set up quickly during a go-live.

Generic Inquiries and reporting exposure

Generic Inquiries are one of the easiest ways sensitive data leaks past screen-level controls, because a GI can join across tables a user would never be granted direct screen access to, and its results can still be exported. Auditing which GIs expose PII or financial detail, and confirming the GI's own access rights are scoped to the roles that legitimately need it, closes a gap that's easy to miss because GIs are usually built ad hoc by power users rather than reviewed like a screen customization.

Audit trail as the detective control

Access rights are the preventive control; the audit trail is the detective one. Acumatica's audit history (configured per-DAC field) records who changed what and when, which won't stop a bulk export but will show you, after the fact, who viewed or modified a specific customer's sensitive fields — useful both for incident response and for periodic access reviews that ask "does this person still need to see this."

A practical checklist

None of the above needs custom code. It needs a deliberate pass through roles, exports, attachments, GIs, and integration users, on a recurring schedule rather than once at go-live.

Wrapping up

Acumatica's DLP posture is only as good as the last access review. Screen rights, field rights, integration user scope, GI exposure, and attachment storage all drift over time as roles are added and staff change — the fix is not a tool purchase, it's putting a recurring review of exactly these five things on someone's calendar.