SAP publishes security notes on a monthly cycle, on the second Tuesday of the month. For teams running SAP this means a recurring decision: which notes apply to our environment, which must be applied immediately, and which can wait for the next service window.
We take that work over - from analysing the notes, through assessing the impact on a specific SAP landscape, to rolling out patches and running regression tests.
A raw list of SAP notes does not answer the question of what to do in a specific environment. We filter notes against the components, versions and configurations actually in use, and deliver the result as a prioritised list of actions rather than a bulletin to interpret yourself.
The period between a note being published and a patch being applied is a window in which the vulnerability is publicly known and remains open. A standing monthly process shortens that window, because the analysis does not start from scratch each time.
Regular, documented handling of security notes is one of the things auditors ask about in the context of NIS2, DORA and the Polish KSC. Each cycle leaves a record: what was analysed, what was applied, and on what basis the remaining items were deferred.
The monthly note review is repetitive work that competes for time with development projects. Handing it to an external team removes a standing, recurring obligation from the in-house team.
After each Patch Day we review the published notes, verifying CVSS ratings, vulnerability descriptions and exploitation conditions. We identify the items relevant to components actually present in the client environment.
We map notes to specific systems, versions, enhancement packages and configurations. The result is a list of items that apply to the given environment, separated from those that do not.
We split notes into those requiring immediate action, those for the next service window, and those handled on the planned cycle. Priority is based on the CVSS rating, system exposure and business process criticality.
We apply notes in non-production environments, verify the effects, and then carry out the production rollout in an agreed window. Regression testing scope is set according to process criticality.
Some notes concern vulnerabilities whose equivalents may also exist in custom code. We scan custom ABAP using the SAP Code Vulnerability Analyzer to catch analogous patterns outside the standard.
From each cycle we prepare a record: notes analysed, decisions taken, patches applied, and items deferred together with the rationale. The document can support an internal, external or regulatory audit.
The cycle begins on the day the notes are published, that is the second Tuesday of the month. We review the published security notes and make an initial separation between items relevant to the supported environments and those that do not apply.
We then carry out the impact assessment. Notes are mapped to the client's specific systems, versions and configurations, and for critical items we verify the conditions under which the vulnerability can be exploited.
On this basis we prepare a rollout plan split into immediate actions, items for the next service window, and handling on the planned cycle.
Patches are applied first in non-production environments, then in production during an agreed window, with regression testing scope matched to process criticality.
The cycle closes with a report: what was analysed, what was applied, what was deferred and on what basis. We comment on the same Patch Day publicly in our "Security Tuesday with SNOK" series.
Technology stack
Partnerships backed by our team's certifications. Full authorisation for delivery and support.
SAP publishes security notes on the second Tuesday of each month. Outside that cycle, SAP may publish a note off schedule if a vulnerability is critical and requires an immediate response.
No. Some notes concern components a given organisation does not use, so they require no action at all. Among the rest, priority depends on the CVSS rating, system exposure, the conditions for exploiting the vulnerability, and business process criticality. That is why the first step is assessing the impact on the specific environment rather than applying the entire list.
The regulations do not name SAP Security Patch Day explicitly, but they do require vulnerability management and evidence that the organisation handles it in a structured way. A documented, repeatable process for handling security notes is practical evidence of such management. We cover this in more depth as part of the NIS2, DORA and KSC compliance audit.
Yes. SAP notes concern the standard, but similar vulnerability patterns - missing authorisation checks, SQL injection or path traversal, for example - often appear in custom ABAP code as well. The cycle therefore includes scanning custom code, among other things using the SAP Code Vulnerability Analyzer.
Yes. Some organisations commission only the analysis and prioritisation, and carry out the rollout with their own SAP Basis team. The reverse model is also possible, as is full handling of the cycle on our side.
We comment on every SAP Security Patch Day in our "Security Tuesday with SNOK" series. Below is the full archive of analyses, newest first.
