The severity rating on the bulletin is the vendor's problem, not mine
Every quarter, Oracle's Critical Patch Update and SAP's Security Patch Day land with the same problem built in: forty or fifty individual entries, and Oracle's CVSS baseline or SAP's own priority rating marks a large share of them at the top of the scale. If I patched in the order the vendor handed me, I would be opening several emergency maintenance windows at once and pulling testing resources off unrelated work to chase a rating that knows nothing about my environment.
That rating is calculated against the product in the abstract, against what the vulnerability could do to any installation anywhere, on any network. It has no idea whether the affected component sits behind a firewall with no public route, or whether it is the same module driving your supplier portal. Systems that have accumulated years of custom code also take longer to test safely once a patch does land, which is one more reason clean core keeps coming up as a budget conversation and not just an architecture slide.
I have owned patch management across an ERP estate running Oracle E-Business Suite alongside SAP ECC and S/4HANA for several years now, and the only way through a bulletin like that without freezing the whole change calendar, or ignoring half of it, is a fixed order of questions asked the same way every time: internet exposure first, authentication requirement second, blast radius third, and how close the system sits to closing the books or moving an order from quote to cash, last.
Ask what the internet can already reach
The first filter has nothing to do with the vulnerability itself. It is whether the affected system has a listener facing the public internet. Before I open the bulletin, I pull the current list of externally reachable endpoints from the network team's firewall rule export: the supplier self-service portal, the B2B EDI gateway, the customer-facing Fiori apps, any EBS iSupplier or iRecruitment instance sitting behind a reverse proxy without a VPN requirement.
Anything in the bulletin touching a component on that exposure list moves to the top of the queue regardless of how the vendor scored it. A patch rated moderate for a component reachable from any browser on the open internet outranks a patch rated critical for a module that only talks to other systems inside the data center over a private network. I do not re-litigate that ranking every quarter. It is a standing rule, because an internet-facing endpoint is the one an attacker does not need a foothold to reach in the first place.
Ask whether an attacker needs credentials first
Once I have separated the exposed components from everything else, the second question is authentication. Both bulletins already carry this detail, you just have to go looking for it. Oracle's Critical Patch Update lists an access vector and an authentication requirement in the risk matrix for each CVE, and SAP's Security Notes carry a CVSS vector string where the privileges-required field tells you the same thing. A flaw that needs no valid account beats a flaw that needs one, even when the second flaw carries a higher base score.
The reasoning is simple. An unauthenticated vulnerability on an exposed system means the only barrier between an outside attacker and your ERP is the patch itself. An authenticated one means the attacker needs a working username and password first, and that gap gives you room for other controls, such as forced password rotation and login monitoring, before it turns into a breach. Those controls do not make the authenticated flaw safe to ignore. They just mean it does not jump the line ahead of the one with no lock on the door at all.
Then work out what a compromised system can reach
Exposure and authentication tell you how easily someone gets in. Blast radius tells you what happens after they do, which is close to the same question you would ask in the first thirty minutes of a platform incident: what does this system talk to, and what could it touch on the way through.
On the SAP side, I pull the RFC destination list and the trusted system relationships for the affected instance, checking which systems can call into it without a fresh login and whether any of those trust relationships cross from a sandbox or development client into production. On the Oracle side, I check the EBS interface register for the same pattern, tracing which batch jobs and inbound web services move data between the affected instance and everything downstream of it.
A patch on a system with a trust relationship reaching into the general ledger, or a service account carrying broad access, outranks a patch on a system that is functionally an island, even when the island's CVSS score is higher. This is the step where the integration map earns its keep, because you cannot judge blast radius from memory once an estate has grown past a handful of interfaces. If nobody can answer, in under five minutes, which systems trust the one in front of you, that is a gap worth closing before the next bulletin lands, not during it.
Only then weigh the close and the order-to-cash flow
The fourth question is the one people want to ask first, and it is the one I ask last on purpose: how core is this system to closing the books or to the order-to-cash cycle. A patch that touches the general ledger consolidation engine or the pricing and billing flow feels urgent because everyone in finance and sales operations will notice if it breaks. But urgency to the business and urgency to security are different measurements, and letting the first one override exposure and authentication means patching an internal, credentialed system in the middle of the month while an internet-facing, unauthenticated flaw on a lower-profile system sits open.
Process centrality actually decides things as a tiebreaker and as a scheduling constraint. When two patches tie on exposure, authentication, and blast radius, the one sitting on the system that runs the close or the order flow gets the earlier maintenance window, because an emergency patch applied three days before month end, with no time to test the consolidation run afterward, is its own kind of incident. I have had a controller ask me, the week before quarter close, why a patch could not wait ten days. The honest answer was that it could, once I had confirmed it failed the first three questions and there was no exposed, unauthenticated path to that system. That conversation is a lot easier to have when you can point to the order you used instead of a gut call.
Turn the four questions into a sheet you actually fill out
None of this holds up as a mental exercise run line by line while you are paging through a forty-page PDF. I keep one row per patch on a working sheet: the CVE or SAP note number, a yes-or-no for internet exposure, a yes-or-no for authentication required, a rough blast radius score from one to three based on trust relationships and interface count, and a rough process centrality score from one to three for whether the system touches close-the-books or order-to-cash activity. Sort on those columns in that order and the schedule writes itself, with exposed and unauthenticated paths landing at the top no matter what the vendor's own severity column says.
Building that sheet depends on already having the exposure list and the interface map on hand before the bulletin arrives, along with a clear read on what needs a login and what does not, rather than stitching all of that together the afternoon the bulletin lands. That is really an argument for keeping an accurate record of system exposure refreshed on its own schedule, rather than reconstructed from memory during a fire drill. Bulletin triage moves fast once that groundwork already exists, and drags every single time it does not.
What to do with the patches that don't make the first wave
A patch that loses on all four questions does not disappear. It moves into the next scheduled maintenance window with the rest of the quarter's normal-priority work, and I still track it against the vendor's own recommended timeline so it does not quietly age past a year unpatched. The same discipline carries into the long stretch of support after go-live, where the systems that felt urgent at launch are often the ones nobody rechecks once the project team moves on.
Next time a bulletin lands with every line marked critical, do not start reading it top to bottom. Pull the exposure list first, run every entry through the same four questions, and let the schedule come out the other end already sorted. The vendor's severity column was never going to do that part for you.
