PeopleSoft SOX Compliance Consulting

PeopleSoft security is built in three layers. A permission list is the smallest grantable unit — it defines access to specific pages, component interfaces, PeopleSoft Query access groups, process groups for the Process Scheduler, and sometimes row-level data through row security permission lists tied to business units or departments. Roles bundle one or more permission lists around a job function, and user profiles are assigned one or more roles, either directly or through a role-query rule that dynamically grants a role based on HR data (department, job code, supervisor level). For SOX purposes, this is the layer where segregation of duties lives or breaks: a role that carries both a permission list granting access to the AP voucher entry component and one granting access to the payment posting component is a direct SoD conflict, and PeopleSoft will honor it exactly as configured.

The practical complication is that permission lists in most long-running PeopleSoft instances were never designed as a coherent set. They accumulate — a new permission list gets cloned from an old one to grant one extra page, a role gets an additional permission list bolted on for a one-off project, and nobody goes back to remove it once the project ends. Because PeopleSoft's security interface (PeopleTools Security) shows permission-list-to-role and role-to-user mappings clearly enough on a single record, but does not natively cross-reference which combinations of permission lists create a segregation-of-duties conflict, that analysis has to be built or bought — either through Oracle's own GRC tooling, a third-party SoD ruleset product, or a custom PS Query-based conflict report maintained by internal audit.

PeopleSoft Query is the primary ad hoc reporting tool built into the platform, and it is also a control surface auditors frequently overlook on a first pass. A user with access to Query and to the right access group can construct a query that reads sensitive financial or HR data directly against the underlying tables, bypassing whatever field-level masking or approval workflow the transactional pages enforce. Query security is governed by access groups tied to permission lists, and in an instance where access groups were set up broadly years ago — commonly to unblock a reporting project — the actual query access footprint can be far wider than the transactional access footprint the SOX team reviewed. Any PeopleSoft SOX assessment needs to review Query security as its own control, not assume it inherits the discipline applied to the transaction pages.

Process Scheduler is the other commonly under-reviewed layer. Scheduled and on-demand batch processes — nightly interfaces, GL close jobs, payroll calculations — run under a defined process profile and operator ID, and PeopleSoft logs process instances with requestor, run date, and status in the Process Monitor. For SOX purposes, the relevant question is who can request, reschedule, or modify the run controls for financially relevant processes (a GL journal generator process, an AP payment posting process), because that capability functions as an application control override if it is not restricted and logged the same way manual transaction entry is. A recurring finding in PeopleSoft ITGC testing is a Process Scheduler operator ID shared across an IT team, which erases the individual accountability an auditor needs to sample against.

Component Interfaces (CIs) are PeopleSoft's mechanism for programmatic access to component data — used for integrations, batch loads, and custom pages built on top of delivered functionality. A CI inherits the security of its underlying component in principle, but a poorly configured integration user or a custom CI built without field-level edits can create a bypass around approval workflows that exist on the standard page. Auditors testing ITGCs in a PeopleSoft environment increasingly ask for a CI inventory: what integrations exist, what user or service account they run under, and whether that account's access was scoped to only what the integration needs or was granted broad component access for convenience during original build.

The single most common reality in PeopleSoft SOX engagements is that the instance being assessed is not a recent implementation — it is a customized, upgraded, patched environment that has been in continuous production for a decade or more, often in higher education, government, or a large enterprise that has resisted migrating off PeopleSoft because the customizations are deeply embedded in how the organization actually operates. That history means permission lists, roles, and CI security were shaped by successive project teams with different standards, and a fresh SoD review is almost never optional going into a first or renewed SOX cycle — it is close to guaranteed to surface access debt that nobody currently owns.