Acumatica PII Discovery and Scanning

Before you can encrypt, mask, or honor a deletion request for personal data in Acumatica, you first have to know where it lives — and in most instances that map does not exist. PII accumulates in predictable places (Contacts, Employees, CRM records) and in unpredictable ones (a custom UsrNationalID field bolted onto a DAC three customizations ago, a scanned passport sitting in a Case attachment). Discovery is the unglamorous first step every data protection program skips, and it is the one that determines whether a subject access request takes an afternoon or a month.

Where PII actually lives in Acumatica

Structured PII is concentrated in a small set of DACs: Contact and BAccount hold names, emails, and phone numbers for customers and vendors; EPEmployee and the HR module hold national ID numbers, bank account details, and salary history; CRM Leads and Opportunities duplicate a lot of the same contact data outside the core AR/AP tables. Each of these is easy to inventory because the schema is known and stable.

The harder problem is unstructured PII: free-text Notes on any record, Activities logged against a Case, and file attachments — scanned IDs, signed contracts, email threads pasted into a support ticket. None of it is indexed as personal data by Acumatica itself, so a column-based inventory will miss all of it.

The Usr field blind spot

The single most common gap I find on real instances is a custom field added years ago by a customization that nobody documented as sensitive. A field like UsrPassportNo, UsrKraPin, or UsrNextOfKinPhone gets added to a DAC extension to solve an immediate business need, ships, and is never revisited. Nobody adds it to a data classification list because there wasn't one at the time.

This is why discovery has to run against the live schema, not against tribal knowledge of "what the system does." Every developer who has inherited an Acumatica instance with five years of customizations behind it has found at least one field like this.

A discovery pass with a Generic Inquiry

You don't need a third-party DLP tool to get a first-pass inventory. A read-only Generic Inquiry (or direct SQL against a reporting replica, with sign-off from whoever hosts the database) against the system catalog will surface every column whose name looks like PII, structured or custom:

-- Run against a read-only replica, not production
SELECT
  t.TABLE_NAME,
  c.COLUMN_NAME,
  c.DATA_TYPE
FROM INFORMATION_SCHEMA.COLUMNS c
JOIN INFORMATION_SCHEMA.TABLES t
  ON t.TABLE_NAME = c.TABLE_NAME
WHERE c.COLUMN_NAME LIKE '%Email%'
   OR c.COLUMN_NAME LIKE '%Phone%'
   OR c.COLUMN_NAME LIKE '%NationalID%'
   OR c.COLUMN_NAME LIKE '%Passport%'
   OR c.COLUMN_NAME LIKE '%KraPin%'
   OR c.COLUMN_NAME LIKE '%SSN%'
   OR c.COLUMN_NAME LIKE 'Usr%'   -- catches undocumented custom fields
ORDER BY t.TABLE_NAME, c.COLUMN_NAME;

Every row that comes back under the Usr% filter needs a human to look at it and decide: is this PII, and if so, does it need masking or encryption. That triage step is manual by necessity — name matching gets you the candidate list, not the verdict.

Scanning unstructured content

Notes, Activities, and attachments require content scanning rather than schema scanning, because the PII is embedded in free text or in files rather than in a typed column. There's no built-in scanner for this in Acumatica, so it typically means exporting Case Activities and attachment text (via OCR if they're scanned images or PDFs) and running them through regex patterns tuned for the identifiers your customer base actually uses: email regex, phone number patterns for the markets you operate in, and national ID formats — Kenya's national ID and KRA PIN format, for example, are structured enough to match reliably, as are most East African formats.

This pass is noisier than the schema scan and produces false positives, but it's the only way to catch PII that support agents pasted into a ticket rather than entered into a proper field.

Why this matters for compliance

Kenya's Data Protection Act (enforced by the ODPC), Nigeria's NDPA, and Rwanda's data protection law all share the same precondition: you cannot honor a subject access or erasure request, and you cannot demonstrate compliance to a regulator, if you don't know where personal data is stored. Discovery isn't the compliance program — it's the prerequisite that makes the rest of the program possible. Once you have an accurate inventory, the natural next step is deciding which fields need field-level encryption or masking, and which can be handled with access restrictions alone.

Wrapping up

Discovery is boring compared to encryption or masking, which is exactly why it gets skipped — and why it's the step that actually determines whether the rest of a data protection program works. Run the schema scan against structured DACs and every Usr-prefixed field first, since that's where years of ad hoc customization work hides sensitive data nobody tracked. Once you have that inventory, the decision for each field becomes concrete: encrypt it with field-level encryption if it's genuinely sensitive and queried rarely, mask it in the UI if people need to see a version of it but not the raw value, or — the option people forget — decide the field shouldn't have been added at all and get rid of it.