PeopleSoft Internal Audit Software Consulting

Internal audit's test plan for a PeopleSoft environment has to start from the platform's three-layer security model: permission lists grant access to pages, component interfaces, PS Query access groups, and Process Scheduler process groups; roles bundle permission lists around a job function; and user profiles are assigned roles either directly or dynamically through role-query rules driven by HR data. A well-formed internal audit test plan treats each layer as a separate test object rather than collapsing them into a single access review, because a conflict can exist at the permission-list level (two incompatible permission lists bundled into one role) even when the role names themselves look reasonable on a summary report.

A recurring internal audit finding in PeopleSoft environments is that no one currently owns a canonical inventory of what each permission list actually grants, because permission lists accumulate through cloning across projects and upgrades. Before internal audit can test segregation of duties meaningfully, it typically needs to commission or perform a permission-list-to-page/component mapping exercise — either through PeopleSoft's own security reporting pages, a scripted PS Query against PSAUTHITEM and related security tables, or a third-party SoD ruleset tool — because the delivered PeopleTools Security interface shows individual mappings clearly but does not synthesize them into a conflict report.

The three tests that recur across nearly every PeopleSoft internal audit programme are a segregation-of-duties conflict test against permission-list combinations, an access recertification test confirming role owners have reviewed and affirmed or revoked user assignments on a defined cadence, and a workflow approval test confirming the PeopleSoft Approval Workflow Engine enforces a defined approver above a materiality threshold before a transaction posts. Each of these tests depends on data internal audit has to actively extract — PeopleSoft does not surface an SoD conflict report, a recertification queue, or an approval-exception report as delivered functionality, so the internal audit platform or supporting PS Query has to be built to produce them.

Sampling for these tests is more granular in PeopleSoft than in platforms with a flatter role model, because a sample of "users with access to AP" is not precise enough — internal audit needs to sample at the permission-list combination level to determine whether a specific incompatible pairing (voucher entry and payment posting, for example) was actually exercised, not just theoretically available. This is where an internal audit platform that can join PeopleSoft security extracts to transaction-level activity data earns its cost over a purely access-based test, because it lets internal audit distinguish an unused conflict from one that was actually used to bypass a control.

Workpaper documentation for PeopleSoft internal audit testing needs to preserve the specific permission list, role, and user profile identifiers involved in a finding, not just a narrative description, because remediation happens at that configuration layer and a vague finding ("some users have excessive AP access") cannot be acted on by the PeopleSoft security team without the underlying IDs. Internal audit platforms that support structured, linked findings — tying a finding to the specific permission list or Component Interface implicated — produce remediation tickets that are directly actionable rather than requiring a second investigation to translate the finding into system changes.

Internal audit teams working with PeopleSoft instances that have been in continuous production for a decade or more should expect the first rigorous testing cycle to surface a meaningful volume of findings, not because the organization has been careless, but because permission lists, roles, and Component Interface security accumulate access debt through successive project teams with inconsistent standards. Framing that first cycle's volume of findings honestly in planning documents and audit committee reporting — as a one-time catch-up rather than an ongoing control failure rate — is a documentation practice that materially affects how the results are received.