ERP Security Audit UAE: What It Actually Tests

TL;DR. An ERP security audit tests five things: access, segregation of duties, change control over custom code and transports, interfaces to other systems, and where the data goes. In the UAE it also has to answer to the UAE Information Assurance Standards for the control set and to the PDPL for personal data leaving the country. The finding that recurs everywhere is the same: a small number of users hold combinations of permissions that let one person complete a payment cycle alone, and nobody knew because the permissions were granted through nested roles rather than directly.

ERP is where the money is, which is why the audit is different from every other technical audit an organisation runs. A vulnerability scan asks whether an attacker can get in. An ERP security audit asks whether an insider who is already in, with legitimate credentials, can move funds, alter a master record, or delete the trace of having done so. The threat model is authorised access used in an unauthorised combination.

Access: who has what, and why they still have it
Segregation of duties: the conflicts that pay out
Change control: custom code and transports
Interfaces: the accounts nobody owns
Data: residency, and what the PDPL asks
What the audit produces, and what it costs

                    ┌────────────────────────────────┐
                    │  ERP security audit scope      │
                    └───────────────┬────────────────┘
                                    │
        ┌───────────────┬───────────┼───────────┬───────────────┐
        ▼               ▼           ▼           ▼               ▼
  ┌───────────┐  ┌────────────┐ ┌────────┐ ┌──────────┐ ┌─────────────┐
  │ Access    │  │ Segregation│ │ Change │ │Interfaces│ │ Data and    │
  │ who has   │  │ of duties  │ │ custom │ │ what     │ │ residency   │
  │ what, why │  │ conflicts  │ │ code,  │ │ talks to │ │ what leaves │
  │ still     │  │ that pay   │ │ trans- │ │ it, with │ │ the country │
  │           │  │ out        │ │ ports  │ │ what     │ │ and why     │
  └───────────┘  └────────────┘ └────────┘ └──────────┘ └─────────────┘
        │               │           │           │               │
        └───────────────┴───────────┼───────────┴───────────────┘
                                    ▼
                       Evidence per finding, dated,
                    traceable to a control identifier

The five areas an ERP security audit covers

1. Access: who has what, and why they still have it

Every ERP audit starts here and most of the findings originate here. The question is not whether an access control model exists, because it does, they all ship with one. The question is whether the model still describes reality after a decade of role changes, mergers, projects and emergency grants.

Four patterns account for most of what a first audit finds. Standing privileged access, where administrative rights were granted for a go-live in 2019 and never withdrawn. Nested role inheritance, where a role that looks innocuous confers a sensitive permission three levels down, which is why an audit has to test effective permissions rather than assigned roles. Orphaned accounts belonging to people who left, which survive because the leaver process ends at the identity provider and the ERP has its own user store. And shared accounts used by teams, which end the audit trail at the moment it matters, because every action attributes to the account rather than to a person.

The test is mechanical: resolve every user to their effective permissions, then ask the business owner to justify each sensitive one. The justification step is where the audit gets its value, because roughly a third of them cannot be justified by anyone still employed.

2. Segregation of duties: the conflicts that pay out

Segregation of duties is the heart of the discipline and the part most often reduced to a checkbox. The control is not that duties are separated in the org chart. It is that no single person can execute an entire value transfer alone, and that the system enforces it rather than the culture.

Three conflicts matter more than the rest, because they are the ones that convert directly into loss. Create a vendor and release a payment. Change vendor bank details and approve a payment run. Post a journal entry and approve the same entry. Everything else on a standard conflict matrix is real and secondary.

The query below is what the test looks like in practice. Role and permission names differ per product, and the shape does not: resolve effective grants, self-join on the user, and look for the pair.

sql

-- The conflict that actually matters: one person who can both create a
-- vendor and release a payment to it. Roles differ per ERP; the shape
-- of the query does not.

WITH grants AS (
    SELECT u.user_id, u.display_name, r.role_id, p.permission
    FROM   user_role  u
    JOIN   role_perm  r ON r.role_id = u.role_id
    JOIN   permission p ON p.permission_id = r.permission_id
    WHERE  u.valid_to IS NULL          -- current grants only
)
SELECT   g1.user_id, g1.display_name,
         g1.permission AS creates_vendor,
         g2.permission AS releases_payment
FROM     grants g1
JOIN     grants g2 ON g2.user_id = g1.user_id
WHERE    g1.permission IN ('VENDOR_CREATE', 'VENDOR_BANK_EDIT')
  AND    g2.permission IN ('PAYMENT_RELEASE', 'PAYMENT_RUN_EXECUTE')
ORDER BY g1.display_name;

The conflict that converts directly into loss

Two refinements separate a useful result from a long list nobody acts on. First, filter by whether the user has actually exercised the permission in the period, because a theoretical conflict held by someone who has never used either half is a lower priority than an active one. Second, check for the conflict across the approval chain rather than only within a single user, since a manager who can approve their own delegate's work reconstitutes the conflict at one remove.

Where a conflict cannot be removed, and in a finance team of six it frequently cannot, the answer is a compensating control with evidence: a report of every payment released by a user who could also create the vendor, reviewed and signed by someone outside the chain. An unmitigated conflict is a finding; a mitigated one with no evidence of the review is the same finding with extra steps.

3. Change control: custom code and transports

No ERP runs as shipped. Custom code, configuration and reports move from development to production through a transport mechanism, and that mechanism is a control surface most audits underweight.

What gets tested: whether a developer can move a transport into production alone, whether production is open for direct modification, whether custom code containing authorisation checks was reviewed by anyone other than its author, and whether emergency changes have a retrospective approval path that is actually used rather than a policy describing one.

The recurring finding is not malice, it is convenience. Production is left open for a project, a support pack, a year-end fix, and never closed. The evidence question follows immediately: if production is open, every subsequent control claim about the system rests on the assumption that nobody used it, and that assumption cannot be evidenced.

4. Interfaces: the accounts nobody owns

The ERP does not stand alone. It exchanges data with banking platforms, payroll, warehouse systems, e-commerce, business intelligence, and increasingly with an AI assistant somebody connected during a pilot. Each interface authenticates as something, and that something is usually a technical account with broad permissions, a password that has not changed since the integration was built, and no named owner.

The audit inventories every interface, resolves what each account can actually do, and asks who owns it. It also asks what the interface transmits, because an integration built to read three fields frequently ends up reading a whole table after a later change, and nobody re-scoped the permission.

Where an interface reaches a system outside the country, the technical question becomes a regulatory one, which is the next section.

5. Data: residency, and what the PDPL asks

An ERP holds employee records, customer records, and in many organisations health or financial data belonging to identifiable people. That places it squarely inside the UAE Personal Data Protection Law, and it makes the interface inventory above a transfer inventory as well.

Three questions come out of this reliably. Which processing activities in the ERP involve personal data, and is each recorded in the record of processing activities. Where does that data physically go, counting backups, disaster recovery, support access from an offshore team, and the reporting layer, since a report warehouse in another region is a transfer whether or not anyone called it one. And what is the lawful basis and transfer condition for each, documented before the transfer rather than after a question about it.

For entities in DIFC or ADGM the applicable law differs, and for entities in critical sectors the UAE IA (NESA) Standards apply on top, with the ERP falling under the technical control families for access control, logging and cryptography. A single audit can answer for all of them provided the control set is mapped once rather than tested three times.

6. What the audit produces, and what it costs

A useful ERP security audit produces four artefacts: an effective permission map per user, a conflict matrix with the exercised conflicts marked, a findings register where each finding names the evidence examined and the control identifier it maps to, and a remediation plan sequenced by exposure rather than by ease.

Timing depends almost entirely on one variable, whether the permission data can be extracted programmatically or has to be assembled from screens. With extracts, a single-instance audit runs three to five weeks. Multi-instance estates, or estates where a system integrator holds the access, run longer and start with a data access negotiation rather than with the audit.

What it should not produce is a report that the ERP is insecure. Every ERP with ten years of history has these findings; the question the board is actually asking is which of them can be closed this quarter and which need a process change that takes a year. We do this work as part of information security assessments in Dubai, and where the finding turns out to be structural rather than technical it moves into IT security governance in the UAE.

What an ERP Security Audit in the UAE Actually Tests

Contents