SAP S/4HANA Security and Project Challenges

Organizations need to be aware of the SAP S/4HANA security challenges as they prepare for the year 2025 SAP deadline for converting SAP ECC and other older SAP systems to SAP S/4HANA.  The 2025 deadline is to implement the SAP S/4HANA (application) and not just to implement the SAP HANA in-memory database.   Of course, the standard system development lifecycle processes should be followed, as well.  Below is a listing to assist in a successful migration to SAP S/4HANA:

1. Do not treat SAP S/4HANA as just an update.  Treat it as a “Major Project.”  Organizations are devoting multiple months and even multiple years to the change.  Custom code and security will need to be updated.  Dedicate a budget of skilled IT and business resources and adequate time to set the foundation for project success.
2. Involve the organization’s SAP Security group at the beginning.  Even when an outside implementer is assisting in the project, the internal SAP Security group should be driving policies, standards and controls to ensure a successful project.  Transaction changes are found throughout the SAP S/4HANA Business Processes.  But, many of the transactions remain the same.  Existing roles should be leveraged as much as possible as a starting point.
3. Internal Audit and External Audit should be involved early in the project.  Auditors will work with the project team by advising on security and control requirements.  Do not hesitate to request the auditors to review security and controls prior to- and after go-live.
4. Spend time reviewing the “Simplification List for SAP S/4HANA” whitepaper written by SAP.  SAP S/4HANA is simplifying the SAP environment and preparing for future innovations.  These changes are documented within this 900 plus page reference document.
5. Ensure the added and removed transactions and SAP tables are properly updated and tested in the SAP security roles.
6. Custom SAP reports need to be thoroughly identified, evaluated, updated and tested.  Organizations need to be aware of their custom code but need to evaluate the future usage.  Valuable time and resources should not be wasted if the custom reports will no longer be used in SAP S/4HANA.  Custom reports that will be used need to be updated and tested.   
7. If possible, try to avoid implementing SAP S/4HANA close to the end of the fiscal year.  Surprises will likely come up, causing possible delays in the project or increased cleanup after go-live.  This would be a good rule to live by for any major project, though, especially for organizations that must comply with the Sarbanes-Oxley Act.
8. Plan to be compliant with production controls on “Day One.”  For example, the formal production transport change management process with the production restricted client settings should be in place at go-live.  Client settings should be set to enforce logging as well.  Security settings and processes should also be restricted and established, including configuring password settings according to company policy, enforcing the production security provisioning processes (adding and removing access), appropriately restricting the SAP_ALL profile and other privileged access, evaluating if Service accounts can be changed to System accounts, and performing a formal users and roles approved security baseline prior to go-live. 
9. Developer Keys are no longer used in SAP S/4HANA.  Organizations need to re-evaluate their segregation-of-duties of transports.  Developer keys in the past may have mitigated a transport risk (for example, the Basis Team having developer access in the development environment and the ability to push transports to the production environment but did not have a developer key). However, for SAP S/4HANA, organizations may need to implement a mitigating control to validate that the same user is not creating and moving the same transport to the production environment.
10. SAP GRC controls need to be updated.  The segregation-of-duties (SOD) rule set needs to be updated with the transactions being added and removed.  SOD conflicts should also be evaluated for conflicts within SAP S/4HANA.  Extra attention should be devoted to the vendor maintenance authorizations.  SAP consolidated vendor management maintenance within the “BP” transaction.  Mitigating controls should be considered to address SOD conflicts that access cannot be separated.  The firecall process should also be reviewed to ensure only appropriate users can request firecall accounts that provide reasonable elevated access.