The quarterly user access review for Oracle EPM usually runs like this. An administrator exports users and groups from the identity domain, exports application security from ARCS or Task Manager, looks each person up in Active Directory for title, status and manager, splits the result into a tab per business unit, sends the tabs to approvers, chases them for two weeks, catches the self-approvals by eye, removes access by hand, then exports again to prove the removals happened. Three to four weeks a quarter, and an evidence file that an auditor can still pick apart. Here is why it takes that long, and what the file needs to contain.
Where the four weeks go
The join. Nothing in Oracle EPM gives you one list of who has what. The identity domain knows groups and roles, the application knows its own security (ARCS teams, preparer and reviewer assignments, Task Manager roles), and the directory knows whether the person still works for you and who they report to. Every quarter someone joins the three by hand, with lookups.
The routing. Who approves which users lives in a group-naming convention and in one person's memory. Splitting the list into business-unit tabs is an hour; working out who the approver is for the lines that do not fit the convention is a day.
The chase. Approvers get a spreadsheet by email with a two-week deadline. Reminders, escalations and the discovery that one approver is on leave happen in week two and three. Self-approvals, where an approver's own line sits on their own tab, are caught by whoever reads carefully.
The removal and the proof. Lines marked remove are keyed into the identity domain and the application one at a time. Then the same exports are run again so that the removals can be shown. If a removal was missed, the auditor finds it before you do.
The assembly. The before file, the approval emails, the after file and the screenshots go into a folder for the audit request. They were produced on different days with different column orders, and they do not quite reconcile to each other.
The three pieces auditors look for
Strip away the format and every audit request for an access review asks for the same three things.
1. The population: a before snapshot. The report of who had access on the day the review started, with proof of how it was produced: the parameters the report was run with, the first and last page or record, and the date and time it was taken. This is what tells the auditor the review covered everyone, not a subset, and that nobody edited the list before approvers saw it.
2. The decisions: every line with an approver. For each user, who decided keep or remove, when, and that the approver was not deciding about their own access. An approval email that says "approved" is a decision about a file; it is not a decision about a line, and when the file has been re-sorted or added to since, it is not evidence of anything in particular.
3. The outcome: removals done, shown on an after snapshot. The same report, with the same parameters, run after the removals, so that the auditor can see the users marked for removal are gone, inside the quarter, with a ticket or log for each removal. The administrative and native accounts get the same treatment as their own listing, because that is usually a separate control.
Why the before snapshot matters more than the approval email
Auditors treat the review workbook as information produced by the entity: before they rely on it, they test whether it is complete and accurate. A workbook assembled from several exports, enriched by lookups and rearranged into tabs is a derived document, and the auditor has to be able to trace it back to the system reports it came from. If the report, its parameters and its timestamp are not in the file, the approvals above it rest on a population nobody can verify. That is the finding you see most often: not that the review was skipped, but that the evidence cannot show what was reviewed.
The practical consequence is that the first hour of the review decides the quality of the evidence. Freeze the population: run the system reports, keep them unedited with their parameters and timestamps, and route copies, never the originals.
What a campaign changes
Run as a campaign, the same review takes one pull instead of three exports and a join; a routing rule by business unit, or to each user's manager from the directory, instead of tabs; a reviewer workbench where each line is decided, signed and timestamped and self-approval is blocked; removals executed through the APIs and confirmed by a re-pull; and an evidence pack produced from the campaign's own records: before snapshot, every decision, removals, after snapshot, exceptions. The approvers still get their two weeks. The administrator's four weeks become a day to launch and an hour to close.
What to do this quarter
- Freeze the population on day one: system reports with parameters and timestamps, kept unedited; copies go to approvers.
- Write the approver matrix down, or decide that the user's manager approves and make sure the manager field is populated in the directory extract.
- Collect decisions per line, with the approver's name and date, not per email; block anyone from approving their own line.
- Re-run the same reports after removals and reconcile line by line to the decisions.
- Give the administrators and native accounts their own listing, reviewed by someone who is not an administrator.
EPM Auditor runs the review as a campaign, from the extracts you already pull to the evidence pack in the form your audit requests ask for. About EPM Auditor.