The security and GRC strategy for any SAP Implementation project should encourage compliance to the policies and procedures relating to IT Security and governance processes, change control procedures, software security standards and other external regulatory compliance frameworks such as SOX. The table below illustrates the guiding principles for the security and GRC design:

SOD

Job responsibility combinations that present a risk to corporate assets, dominating a business process / transaction, or increase exposure of fraudulent activities are separated from each other.

• Improves organizational, business process and IT control alignment

• Prevents unintentional errors or fraud and facilitates timely detection of errors that may occur

• Internal controls to manage that no single person has too much influence over a business transaction or operation

• Reduces the number of manual reviews and reconciliations

• Analysis performed at single role, composite role, and user levels throughout the implementation

• Single roles built free of SOD conflicts

• Separation of display and maintain transactions

Least Privilege Role Design

Roles are designed to grant access that is limited to what is required for users to perform their job responsibilities.

• Each transaction maps to a single security role Aids in complying with regulatory, privacy, and industry requirements

• Access is granted based upon existence in trusted identity source, alignment with job responsibilities, and training completion

• Sensitive transactions are restricted from end user security roles

• Transaction codes and Fiori applications are documented in process flows and functional specifications (RICEFW) and associated with business roles

• Transactions should be grouped by activities or tasks and assigned to one role

• Single roles should be grouped by job function and assigned to composite roles

• Roles should be granted to users that represent their specific job function(s)

Change Control Process

A strong change management policy is vital when maintaining good SAP Security practices

• Security modifications should be performed in the development system and transported to required areas of the SAP landscape. This will allow consistent roles throughout the system. Security transports will be subject to MSC’s change control process for quality control and testing and will be imported by the basis team

• The role change management process may need to be rationalized to reduce unnecessary overhead and allow the Security team to better meet business service level agreements

Development and Customization

Leverage standard SAP role design as much as possible. Security should be involved in the creation, customization, and implementation of custom development and new functionality to facilitate the inclusion of acceptable security controls and standards.

• Custom tables and custom programs should be assigned to authorization groups and custom transactions

• Custom transactions are secured via standard or custom authorization objects

• Direct table updates should not be performed in an environment ?

• Audit logging should be enabled for non-transactional tables (e.g., master data, mapping)

• Reduce customizations (modifications) beyond standard functionality