A patch is a code-correction for a specific version of an SAP product. Support Packages are a collection of one or more patches. We all have experienced the time and work that can come with implementing new SAP support packages. I would like to take the support packages that are related to transaction codes as an example.
It is possible that the implementation of a transaction code related support packages leads to changes in existing and creation of new transaction codes.
If old transactions are removed from the SAP system and are replaced with new ones after you have implemented SAP support packages, it means that you have to make changes in the SAP security related items. Not only should the roles be changed, but you should also update your GRC rule set.
In my other Blog - "Who is doing what in the SAP system", you can read how you can analyze and get insight into the usage of the transaction codes in the SAP systems. Once this information is clear you can start by adjusting the roles that have the old transactions in them, and replace them with the new transaction codes. Sounds simple? Well, to be honest, it is simple.... even better... you can fully analyze the usage of transaction codes and roles and then automate the role updating and building task with CSI Role Build & Manage. Even if no changes to transaction codes is done it is still a good exercise to check if users are using the assigned transaction codes. If this is not the case, the "need-to-know"and need-to have" principle can apply and the (critical) authorizations can be removed from the users.
But how about updating the GRC rule set? If you focus on auditing on transaction code level first (and including the authorization objects with field values, off course). You can never be sure you a reporting and auditing the real risks. How do you know that your rule set contains all the correct and critical transaction codes. In this example, if the SAP support package makes changes to the transaction codes, you must make changes to the GRC rule set.
That's why I recommend to focus on the data elements, that is, the authorizations instead of the transaction codes. If you focus on the users having access to critical data elements it does not matter if the get this access via transaction code "A" or via transaction code "B" because they have access to the data, they just maybe cannot start it with the audited transaction code (and probably use another transaction code like a custom transaction code that is not being audited instead).
Using CSI tools you will get a clear insight in inconsistencies, not only in the roles or role assignments, but even in the GRC rule set. If a user is assigned to the data element (authorizations), but not to the transaction code, this can be an inconsistency in the role or the rule set.
If the user is assigned to the data element (authorizations) and transaction code, but is not using the transaction code, the access to the functionality can be removed from this user. (figure below)
