SAP Audit of SODEvery company has unique necessities and the objective is to develop the strategy that best balances the risk, maintenance aspects and the number of personal in the company who are working on the security team. The role development is a collaborative effort between functional, technical, training and testing teams. Since role definition affects all these teams. Here are the general guidelines for defining the roles. usefulness and competence of operations trustworthiness of internal management reporting and external financial reporting Compliance with applicable laws and regulation. Segregation of Duties (SoD). Protecting sensitive data.Following primary principles SAP Audit ComplianceTransactions will be assigned to Single Roles that represents the activity to be performed. This approach will contribute towards ensuring consistency in how access to specific functionality is provided to end-users.Full authorization within a transaction will not be given unless detailed access controls are required, as determined by the associated process risk, Security qualifiers are both hierarchical (company code, sales organization) and non-hierarchical (document type, account group).The SAP Security team will execute SAPs Role Derivative functionality to ensure the Base Role design at the transaction level can NOT be modified during localization. The basic functionality represents a key element to achieving adequate internal controls and SAP Audit ComplianceRoles will be developed following a 3-Tiered Architecture. All three levels together make up a composite Role. The Three Tiered approach is designed to be flexible, easier to maintain, will facilitate future systems migrations and easy SAP Audit ComplianceCommon Role provides access to common transactions for any user logging on to the SAP system. The Security team owns this level since the transactions to be put in it are activities that support the general use of the SAP system. Some examples of these activities are access to print, online help, SAP office, etc.Display Access provides each functional team with the flexibility to incorporate all display transactions of non-sensitive data that any end user would need in a specific SAP module. This provides another efficient way to make a change for a group of users. Going forward, as new releases / functionality are introduced, this core level should remain stable. Most changes would affect only job roles. As a result, then any integration or regression testing will proceed at a quicker rate and SAP Audit compliance will be easier.Task Based Roles defines those transactions and authorizations that make the job unique in the system. Any sensitive, company-specific access is placed in this role. Creation, deletion, or change level would be put into this level. Any display transactions, which involve company sensitive data, would be candidates as well. Additionally, it provides a place to put any cross- application access needed to support fringe or crossover users without affecting other users. Some functional roles may need to run transactions, which might be in another module, so the job role is a good place to put these types of transactions.All effort should be made to make all the roles in the system SAP Audit Compliant.