Ask a PeopleSoft team how fast they patch, and you’ll hear “we’re current within a quarter.” Ask them to prove it with dates — Oracle’s release date, your test apply date, your production apply date — and the number turns into a story.
CISA set the real benchmark in June: CVE-2026-35273 hit the KEV catalog on June 12 with a remediation deadline of June 15. Three days. And as Monday’s Digest covered, Oracle now ships Critical Security Patch Updates monthly, with the next on August 18.
Here are the five places the time actually goes, and how to measure each one.
1. You’re still planning around four dates a year
Oracle isn’t. Since May 28, CSPUs land on the third Tuesday of February, March, May, June, August, September, November and December, on top of the quarterly CPUs — with a pre-release announcement the Thursday before each one.
🔗 Critical Patch Updates, Critical Security Patch Updates, Security Alerts and Bulletins (Oracle) https://www.oracle.com/security-alerts/
Measure it: count the security windows on your change calendar for the next 12 months. If the answer is 4, you have designed a 30-60 day lag into every critical fix Oracle ships between quarters. Add the eight CSPU dates, and subscribe to Oracle’s security alert email so the Thursday pre-release reaches a human, not a shared mailbox.
2. Nobody owns the triage window
Between Oracle’s release and your first decision, the patch is public — and so is the vulnerability class. July’s CPU carried 1,449 patches across 1,235 CVEs, of which PeopleSoft took 84, with 45 exploitable over the network without credentials.
🔗 Oracle July 2026 Critical Patch Update Addresses 1,235 CVEs (Tenable) https://www.tenable.com/blog/oracle-july-2026-critical-patch-update-addresses-1235-cves
Measure it: for the last CPU, write down the release date and the date a named person first read the advisory. If that gap exceeds 48 hours, the problem isn’t patching — triage is nobody’s job. Assign it by name, with a backup.
3. You patch the whole CPU or nothing
The all-or-nothing apply is the biggest source of delay: a full CPU means a full regression test, and a full regression test means a quarter. Oracle built CSPUs to break that coupling — targeted fixes in a smaller format, with quarterly CPUs staying cumulative.
Measure it: take July’s PeopleSoft CVE list and mark which entries touch components you actually run. Sites without Global Payroll Switzerland, FIN Common Objects Brazil or In-Memory Project Discovery are testing patches for code they will never execute. A component-scoped applicability list turns a quarterly project into a two-day change.
🔗 Oracle CPU July 2026 Security Update Review (Qualys ThreatPROTECT) https://threatprotect.qualys.com/2026/07/22/oracle-critical-patch-update-july-2026-security-update-review/
4. Your test environment isn’t a copy of production
Every team that misses a window tells the same story: it broke in test, we ran out of time, we deferred. Usually because test drifted — different PeopleTools patch level, different customizations, data from two refreshes ago.
Measure it: run a diff today. Compare PeopleTools release and patch level, applied bundle list, and customization inventory between test and production. Every difference is a false test result waiting to cost you a weekend. It is also the strongest argument for container-based Update Images: an environment you rebuild in a pipeline stops drifting, because it stops being a pet.
5. Your clock starts at the advisory — the attacker’s started earlier
The arithmetic from the last big one: Mandiant observed exploitation of CVE-2026-35273 between May 27 and June 9. Oracle’s advisory came June 10. Even a perfect response was two weeks late, because the race started before the gun.
🔗 Active Exploitation of the Oracle PeopleSoft Zero-Day (Rapid7) https://www.rapid7.com/blog/post/etr-active-exploitation-of-oracle-peoplesoft-zero-day-cve-2026-35273/
Measure it: pick your two most exposed components and ask what compensating control protects them while unpatched. If the answer is “the patch,” you have no answer. Perimeter blocks, egress restrictions and disabled unused services buy the days you don’t have.
Do this once, then make it repeatable
Build one dated table: for the last four Oracle security releases, record release date → triage date → test apply date → production apply date. Four rows, one afternoon. Almost nobody has it.
That table ends the argument. It gives you a real mean time to patch, shows leadership where the days go, and when the next KEV entry lands with a three-day deadline you will already know whether three days is possible — instead of finding out on the day.
Next Thursday: 5 ways to audit PeopleSoft roles and permission lists before someone else audits them for you.
🌐 Join the Community
Subscribe at www.peoplesoftcloud.com for weekly PeopleSoft, ERP, and cloud platform guidance — the Monday Digest for what happened, Thursdays for what to do about it.