Вы находитесь на странице: 1из 2

SAP Audit of SOD

Every 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 Compliance


Transactions 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 nonhierarchical (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 Compliance
Roles 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
Compliance
Common 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.

Вам также может понравиться