More than 70 agencies submitting payments; over 100,000 payment vouchers processed per day
Ran SafePaaS across an estate whose key systems in scope included PeopleSoft and SAP.
Key systems in scope PeopleSoft SAP Read the case studyTry segregation of duties, SailPoint, or Oracle ERP Cloud access review.
PeopleSoft coverage Federated identity governance
PeopleSoft access governance
SafePaaS governs segregation of duties, privileged access and configuration change inside PeopleSoft — reading User Profile, Role, Permission List, Menu, Component and Page, and testing policy against them.
Inside PeopleSoft, not beside it — the same rule book that governs every other system you run.
Role read as PeopleSoft defines it, down to the page Every snapshot re-tested in full, so a conflict reintroduced since the last one surfaces Across your estate PeopleSoft and every other system assessed together, so a duty held here and a duty held elsewhere meet One rule book applied across every system in the process, not one tool per application
Coverage at a glance
What SafePaaS reads, controls and monitors in PeopleSoft
| Area | Reads | Controls | Monitors |
|---|---|---|---|
| Access and segregation of duties | User Profile, Role, Permission List, Menu, Component and Page, and who holds each one | SoD rules at the level of the entitlement itself; request-time prevention; simulation of a role change before it is applied; emergency access with a reason and an expiry | New conflicts introduced by an entitlement change, expired assignments, and standing privilege nobody reviews |
| Transaction and configuration monitoring | Posted documents, change records, master data, and the configuration settings that decide how money moves | Policy on the settings that control the money — approval thresholds, tolerances and the terms applied to a payment | Duplicate payments, threshold splitting, a master-data change followed by a payment, and configuration drift from baseline |
| Audit, risk and compliance | Control test results, exceptions, approvals and the versioned PeopleSoft rule set | One PeopleSoft control mapped to SOX, ITGC and internal policy; exceptions with an owner and an expiry | Test status against each PeopleSoft control, and exceptions approaching expiry |
The entitlement model we read
A PeopleSoft user’s authority is six layers below the role name
SafePaaS reads the PeopleSoft security model as PeopleSoft defines it: user profile, role, permission list, menu, component, page. Each layer is resolved, not assumed.
Only the deepest layers say what a user can actually do, and where. Everything above them is a container.
- Layer 1 User Profile
- Layer 2 Role
- Layer 3 Permission List
- Layer 4 Menu
- Layer 5 Component
- Layer 6 Page
A container in this chain can be widened while keeping the name an access review sees, and the deepest layer differs with every assignment. That is why SafePaaS tests the authority a user actually resolves to, not the label attached to it.
What we detect here
Risks stated the way an auditor would raise them.
Four of many. The SafePaaS PeopleSoft rule set carries 291 rules, each rated HIGH, and every one of them is tested against your snapshot. Each is a combination the role name will not reveal — which is why it survives an access review and surfaces in an audit.
Example 01
A user who can create a supplier and pay it
Create Suppliers held with Create Payments, rated HIGH in the SafePaaS PeopleSoft rule set — the supplier pages, VNDR_ADDRESS among them, on one side and the pay cycle pages, PYCYCL_APPROVAL among them, on the other. Set-up and disbursement in one pair of hands.
Example 02
A voucher entered and approved by the same identity
Create Vouchers held with Approve Vouchers, rated HIGH — voucher entry (VCHR_HEADER_QV2) against mass voucher approval (AP_MASS_APPROVE). An approval step is only a control while someone else performs it.
Example 03
A payment created by whoever can change the bank information it uses
Create Payments held with Modify Bank Information, rated HIGH — the pay cycle pages on one side, the bank pages BANK_PNL1 and BANK_PNL2 on the other. The money and the account details it moves through sit with one identity.
Example 04
A journal entered and approved by the same identity
Enter Journal Entry held with Approve Journal Entry, rated HIGH — the journal entry page (JOURNAL_ENTRY1) against the approval worklist (WORKLIST). The ledger’s own approval step, bypassed by holding both sides of it.
Coverage in detail
How each area works in PeopleSoft
How does SafePaaS enforce segregation of duties in PeopleSoft?
SafePaaS Enterprise Access Monitor tests SoD rules against an ERP Snapshot of your PeopleSoft security model — user profile, role, permission list, menu, component, page — rather than against the live system, so a test is repeatable and a result is defensible.
Modules Enterprise Access Monitor Enterprise iAccess Enterprise Roles Manager ▸ Defines rules at the level of the entitlements themselves, not just the user list, so a conflict is found where it actually lives ▸ False-positive filters remove inactive users, expired assignments and end-dated roles before anyone reviews a result ▸ Detects conflicts that span PeopleSoft and the rest of your estate, so a duty held in one system and a duty held in another are assessed together rather than separately ▸ Enterprise Roles Manager simulates a role change before it is applied, so a change does not reintroduce the violation you just remediated ▸ Violations carry status — Open, Closed, Remediation, Exception — with workflow, reminders and ITSM ticketing ▸ Mitigation records the compensating control and its evidence where a conflict cannot be removed ▸ Emergency access is granted with a stated reason, a time box, and a log of everything done while elevated
How does SafePaaS detect risky PeopleSoft transactions and configuration change?
SafePaaS MonitorPaaS watches what actually happened in PeopleSoft — the posted document, the changed bank detail, the altered threshold — rather than only who could have done it.
Modules MonitorPaaS ▸ Transaction Monitor analyses posted documents for the patterns that indicate error or fraud, including duplicate payments and threshold splitting ▸ Configuration Monitor tracks change to the settings that control the money — approval thresholds, tolerances and payment terms ▸ Change Tracker records who changed a PeopleSoft configuration, when, from what value to what value, so an auditor gets the before and the after ▸ Master data monitoring catches the bank-detail change followed by a payment, which no access rule can see ▸ Findings route into the same violation workflow as SoD, so one queue holds both
What evidence does SafePaaS produce for a PeopleSoft audit?
SafePaaS ARCPaaS turns PeopleSoft control activity into the evidence an auditor asks for — the rule, the test, the result, the exception and its approval — without anyone assembling a spreadsheet.
Modules ARCPaaS ▸ Audit Manager holds the test, its result and its evidence against each PeopleSoft control, with the date and the approver ▸ Risk Manager ties a PeopleSoft access risk to the business process it threatens, so the finding is stated in a language the process owner recognises ▸ Compliance Manager maps one PeopleSoft control to every framework that claims it — SOX, ITGC, and internal policy — so it is tested once and reported many times ▸ Rules Repository keeps the PeopleSoft rule set versioned, so a change to a rule is itself auditable ▸ Exceptions carry a stated business reason, an owner and an expiry, not a permanent waiver
Connection
How does SafePaaS connect to PeopleSoft?
SafePaaS extracts through the platform’s own service interfaces — SOAP per security object, REST for transactions, or a direct database connection where the platform is not cloud-hosted.
Inside PeopleSoft → SafePaaS extraction SOAP services per security object returning XML; REST endpoints returning JSON for occurrences; a direct database connection where the platform runs on-premise.
Transfer → DataProbe The collected data is pushed out to SafePaaS through DataProbe.
Normalize → DataPaaS The transformation layer. Normalizes the data where required so one rule book can test it.
Result ERP Snapshot The point-in-time copy every module tests against — SoD, monitoring, certification and audit evidence alike.
What is read User Profile, Role, Permission List, Menu, Component and Page How data moves Everything collected lands in the FSOD_* open interface tables, and DataPaaS normalizes it from there First snapshot A baseline of every user, role and entitlement assignment, and the first SoD test result set against your own rule book Protection Traffic terminates behind a WAF and an API gateway; the snapshot is tenant-isolated at rest
What runs inside PeopleSoft Nothing Extraction runs through the platform’s own service interfaces, so no SafePaaS component is deployed into it.
Because every governance module tests the snapshot rather than the live system, the same rule book applies to PeopleSoft and to every other system in the same business process.
Coexistence
Does SafePaaS replace SailPoint, Entra ID or my existing IGA?
No — and that is the point of federated identity governance. What your identity platform cannot see is what a role permits once the user is inside PeopleSoft, because that answer lives six layers down in the security model PeopleSoft publishes.
Your identity platform owns
The account
Joiners, movers and leavers Birthright access The request workflow Provisioning a user into PeopleSoft, and recording that they hold a role SafePaaS owns
What the role permits
The entitlement behind the role name SoD across PeopleSoft and the rest of the estate Configuration and transaction change inside PeopleSoft Findings handed back to your IGASo a certification in your IGA reflects the entitlement rather than the role name, and an access request is checked for SoD before it is approved.
Proof
FAQs
What PeopleSoft teams ask first.
The security model as PeopleSoft defines it: user profile, role, permission list, menu, component, page. SafePaaS resolves the chain rather than recording the role name, because the role name is a container and the permission lives below it.
Go deeper on Oracle governance
Next step
See how SafePaaS governs a PeopleSoft estate
A working walkthrough against a demo environment, with a specialist who can map what you see onto the roles, organisation structure and audit pressure you actually have.
What the walkthrough covers How the entitlement chain is read as PeopleSoft defines it — user profile, role, permission list, menu, component, page An SoD conflict traced from the rule to the entitlements that create it How a role change is simulated before it reintroduces a remediated conflict Where SafePaaS sits relative to the IGA and GRC tooling you already run