Is your Oracle EBS change review actually governance-ready?

Use this checklist to assess whether your Oracle E-Business Suite change review process consistently identifies security-impacting and control-impacting changes, evaluates downstream access and SoD risk, involves the right reviewers, and retains evidence through final resolution.

Complete it with Oracle EBS application, security, IT risk, Internal Audit and business control owners where possible. Record the evidence behind each answer rather than scoring the process from memory.

How to score

• Yes — 2. The requirement is documented, consistently performed, and supported by evidence.
• Partial — 1. The activity happens in some cases, depends on manual judgment, or isn’t supported by consistent evidence.
• No — 0. The requirement isn’t defined, isn’t performed, or can’t be evidenced.

Critical items represent gaps that can prevent the organisation from identifying or resolving a material change. Any zero on a critical item is a priority even if the total score looks acceptable. This checklist has 45 checks, 32 of them critical, and a maximum score of 90.

1. Scope of in-scope changes

#	Governance check	Critical?	Score: 0, 1, or 2	Evidence or action
1	We have an approved definition of security-impacting and control-impacting Oracle EBS changes.	Yes
2	Our scope includes changes to Responsibilities, including Menu and Function changes, including inherited access through submenus and Responsibility assignments.	Yes
3	Our scope includes Request Groups, Request Sets, and Concurrent Programs.	Yes
4	Our scope includes Profile Option changes at the relevant site, application, Responsibility, organization, and user levels.	Yes
5	Our scope includes changes to Menu and Function exclusions.	No
6	Our scope includes changes to Operating Unit, Inventory Organization, Ledger, and other organizational security.	Yes
7	We classify changes as routine, security-impacting, control-impacting, or critical using defined criteria.	Yes
8	We can show that the same scope is applied across modules, teams, and reporting periods.	No

Section maximum: 16

Warning signs for this section

• No approved definition of security-impacting or control-impacting changes exists.
• Menu, Function, Request Group, Profile Option, exclusion, or organizational security changes are outside the review scope.

2. Sensitive setup and privileged capabilities

#	Governance check	Critical?	Score: 0, 1, or 2	Evidence or action
9	We maintain a current inventory of sensitive setup Functions and privileged capabilities.	Yes
10	We maintain a current inventory of high-risk Concurrent Programs and Request Sets.	Yes
11	Changes involving SYSADMIN, System Administrator, Application Developer, and similar administrative Responsibilities receive separate review.	Yes
12	We assess custom Responsibilities based on their underlying Functions and Concurrent Programs, not only their names.	Yes
13	Changes to user administration, Responsibility administration, security configuration, and sensitive setup receive enhanced approval.	Yes
14	Temporary privileged changes are time-bound, approved, and verified after removal.	No
15	We can identify when a Menu or Request Group change introduces a privileged capability into an existing Responsibility.	Yes
16	Privileged changes are reviewed on a tighter timeline than routine changes.	No

Section maximum: 16

Warning signs for this section

• Privileged and sensitive setup changes aren't separately identified.

3. Impact assessment process

#	Governance check	Critical?	Score: 0, 1, or 2	Evidence or action
17	We have documented criteria for determining whether a change affects effective access, SoD, privileged capability, or key controls.	Yes
18	Our analysis traces changed Menus, Functions, and Request Groups to affected Responsibilities.	Yes
19	Our analysis identifies the active users and accounts affected by the change.	Yes
20	Our analysis considers Operating Unit, Inventory Organization, Ledger, and other relevant organizational scope.	Yes
21	We test whether the change creates, changes, or resolves SoD conflicts.	Yes
22	We assess whether the change invalidates an existing control assumption or changes how a key control operates.	Yes
23	Business process owners review changes that affect financial or operational process risk.	Yes
24	Control owners review changes that affect a SOX, ITGC, or other key control.	Yes
25	The impact assessment ends in a clear decision and required next action.	Yes

Section maximum: 18

Warning signs for this section

• Changes aren't traced to affected Responsibilities and users.
• SoD and key-control impact aren't assessed.
• Business or control owners aren't involved when process risk changes.

4. Evidence, approvals, and follow-through

#	Governance check	Critical?	Score: 0, 1, or 2	Evidence or action
26	For each material change, we retain the before-and-after configuration.	Yes
27	We document the business reason and affected EBS objects, users, organizations, and processes.	Yes
28	We retain the security, SoD, and control impact assessment.	Yes
29	Reviewers and approvers are selected based on the change impact and their authority.	Yes
30	Request, implementation, review, and approval duties are appropriately separated for high-risk changes.	Yes
31	Decisions include rationale when a change is approved, rejected, modified, mitigated, or escalated.	No
32	Required remediation or mitigation has a named owner, due date, and status.	Yes
33	We verify completion against the final state in Oracle EBS rather than relying only on a closed ticket.	Yes
34	Overdue remediation and mitigation are escalated.	No
35	The full change record is centralized or linked so it can be retrieved without reconstructing it from multiple sources.	Yes
36	Evidence is retained according to the applicable audit and record-retention requirements.	No
37	We can reproduce the complete history for a sample change from request through final resolution.	Yes

Section maximum: 24

Warning signs for this section

• Remediation isn't assigned, tracked, and verified.
• The organization can't reproduce the complete history of a sampled material change.

5. Monitoring and process ownership

#	Governance check	Critical?	Score: 0, 1, or 2	Evidence or action
38	The change governance process has a named owner.	Yes
39	Technical, security, business, control, and remediation responsibilities are documented.	No
40	We track the number and status of security-impacting, control-impacting, and critical changes.	No
41	We track overdue reviews, remediation, and mitigation.	Yes
42	We review a sample of completed changes to test whether scope, assessment, approval, and evidence requirements were followed.	No
43	Repeat gaps and exceptions lead to process or control improvements.	No
44	The process doesn't depend on one Oracle administrator's knowledge or manual extracts.	No
45	Internal Audit, Oracle, security, and risk teams can access a consistent view of the evidence.	No

Section maximum: 16

Score your Oracle EBS change governance maturity

Section	Maximum score	Your score
1. Scope of in-scope changes	16
2. Sensitive setup and privileged capabilities	16
3. Impact assessment process	18
4. Evidence, approvals, and follow-through	24
5. Monitoring and process ownership	16
Total	90

Strong: 75% to 100%

Your process has defined scope, risk-based assessment, appropriate review, and traceable evidence.

What to do next: Focus next on the questions scored Partial and confirm that execution is consistent across modules and business units.

Inconsistent: 45% to 74%

Parts of the process work, but execution depends on the change type, team, or individual reviewer. Common weaknesses include incomplete scope, impact analysis that stops at the changed object, inconsistent business-owner involvement, or evidence spread across multiple systems.

What to do next: Prioritize critical items scored zero, then address the lowest-scoring section.

High risk: Below 45%

The process is unlikely to identify and evidence material Oracle EBS change risk consistently. Teams may have technical change records without a reliable way to assess affected access, SoD, or controls. Audit support is likely to depend on manual reconstruction.

What to do next: Start by defining in-scope changes, identifying privileged capabilities, and establishing a minimum impact-assessment and evidence standard.

What to fix first

1. Define scope. Agree on the EBS objects and events that can affect access, SoD, privileged capability, or controls.
2. Identify sensitive capability. Document sensitive setup Functions, administrative Responsibilities, and high-risk Concurrent Programs.
3. Standardize impact assessment. Trace each material change to affected Responsibilities, users, organizational scope, SoD, and controls.
4. Set review ownership. Define when Oracle, security, business, risk, and control owners must participate.
5. Connect decisions to action. Give remediation and mitigation an owner, deadline, escalation path, and final-state verification.
6. Centralize the evidence trail. Link the change, assessment, approval, decision, action, and verification so audit doesn't have to reconstruct it.

What this checklist reviews

• Your current in-scope change definitions
• Visibility into Responsibilities, Menus, Functions, Request Groups, Concurrent Programs, Profile Options, exclusions, and organizational security
• Security, SoD, and control-impact assessment
• Review and approval ownership
• Remediation and mitigation follow-through
• Evidence completeness and audit readiness

Read next

• Oracle EBS Change Governance Readiness Guide
• Oracle EBS change tracking and configuration governance