ERP Authorization & Control Reference

SAP · Oracle E-Business Suite · Microsoft Dynamics 365 Finance & Operations — authorizations mapped to controls, with extraction and testing guidance. Generated from ai/../js/grcai-erp-auth.js ·

Read the coverage statement first. This reference is deliberately limited to objects whose existence and purpose are confirmed. It is not exhaustive, and an object being absent here does not mean it is invented. Where a platform is not covered, the assistant is instructed to say so rather than improvise — that is the whole point of the document.

1. Coverage and confidence

2. How to extract the listing before you test it

Testing begins with a defensible population. These are the extraction paths per platform.

3. SAP — authorization objects mapped to controls

An authorization object is what actually grants capability in SAP. A role name is not evidence of access, and a transaction code alone does not prove a user can complete the action.

3.1 SAP tables an auditor pulls evidence from

3.2 SAP transactions — what each is actually for

4. Oracle E-Business Suite

4.1 Core tables

4.2 Columns and join paths

Table names alone are not enough: generated SQL was joining FND_FORM_FUNCTIONS on a menu_id it does not have, and filtering on a non-existent effective_date. These are the columns and the correct paths.

4.3 Higher-risk access

4A. Oracle Fusion Cloud ERP

5. Microsoft Dynamics 365 Finance & Operations

5.1 Core security tables

5.2 Higher-risk access

3A. SAP business processes — FI / MM / SD

Transactions per process with the SOD risk that matters and the evidence to collect. These are not one-to-one authorization mappings. A transaction fires several authorization checks and an object governs many transactions — where the exact check matters it must be traced in the target system (STAUTHTRACE, ST01, SU53, role analysis in PFCG).

5B. NetSuite

5C. Infor LN

5E. Workday · PeopleSoft · Salesforce · ServiceNow

Business and IT/privileged access for each, with the evidence sources. None of these platforms uses SAP-style transaction codes — do not look for one.

5G. JD Edwards · Sage · Epicor · IFS · Business Central · D365 CE · SAP Business One

Confidence differs materially across these — read the marker on each. JD Edwards is documented to table level; Sage, Epicor and IFS are concepts only, with no schema object names asserted. None of these platforms uses SAP-style transaction codes.

JD Edwards is deny-oriented. Security records generally subtract from an open baseline and resolve user → role → *PUBLIC. Reading a JDE security listing as a grant list inverts its meaning, and a permissive *PUBLIC record can silently undo user-level restriction.

Microsoft mid-market and SAP Business One

Product	Security model / higher-risk IT access	Confidence

5H. Platforms NOT covered by this reference

The architecture extends to these, but no verified content exists for them. The assistant is instructed to say so and defer to vendor documentation and your own system export rather than naming objects it cannot confirm.

Platform	Security model (shape only — names require confirmation)

6. Testing approach that applies to every ERP

State the control objective and the criteria before selecting anything. Without criteria there is no basis on which a finding can be an exception.
Establish the population and its completeness. Reconcile the listing to a source of record. Record the system, client/instance, extraction date, extractor and exact selection.
Separate capability from activity. Access shows what a user could do; logs show what was done. They are different tests needing different evidence.
Expand the access model fully. SAP: role → authorization object → field values. EBS: responsibility → menu → function, plus data-security grants. D365: role → duty → privilege → entry point. Stopping at the name understates access.
Test the exception, not the count. An exception is not automatically a control failure. Establish root cause, whether it recurs, its population impact, and whether a compensating control genuinely operated before concluding.
Do not attribute a sample size to a framework. SOX, PCAOB, ISO 27001, COBIT and PCI DSS do not prescribe one. Sample size follows your methodology, the population, control frequency, expected and tolerable deviation, and the assurance sought.

On unverified objects. If the assistant names an authorization object, table or transaction that is not in this reference, it is instructed to say it needs confirmation in the client system. In SAP, SU21 lists authorization objects and SE93 shows what a transaction actually starts — confirm there rather than accepting a plausible-looking name.