Journal Online

Using Microsoft Office in Analyzing SAP SoD

and Beyond
Haiyan Chen, CISA, CIA, In essence, segregation of duties (SoD) calls for DIFFERENT MEANS
is head of IT internal audit the separate performance of conflicting activities Once the important systems, manual activities
in the group internal audit in systems, and/or the manual performance and potential SoD risks are identified and
department of Sodexo. He has by different individuals, to prevent a single prioritized, the auditor should focus on the
many years of experience in individual from conducting an unauthorized specific systems or manual activities that pose the
information systems design, or wrongful act and then concealing it. SoD is most difficulty for the auditor to evaluate SoD
audit and data analytics. He an essential internal control in all businesses conflicts. In most situations, a business system,
welcomes comments because it serves as a foundational part of an especially an ERP system, would be the most
or suggestions at organization’s internal control infrastructure difficult one for the auditor to evaluate SoD. The
[email protected]. on which other internal controls are built. As a auditor is no longer able to rely on traditional
result, assessment of SoD has been an important techniques, such as interview, observation and
task for both auditors and managers. examination of documents, to evaluate SoD in a
At the same time, properly assessing SoD business system because most activities are either
has increasingly become a challenge in today’s automated or computerized. Instead, the auditor
businesses, due to increasing reliance on has to use different audit techniques, including:
complicated information systems, especially • Understanding the concept and design of a
enterprise resource planning (ERP) systems, and business system, especially an ERP system, to
deficient knowledge of the new forms of risks provide for user access rights at different levels
posed by computerized business processes. (what a user can do) in different areas (what a
user can see)
SAME RISK-BASED APPROACH • Identifying where user rights and authorization
The overall approach to the assessment of information are stored. These user access rights
SoD does not change over time, whether or and authorizations are often stored in multiple,
not business systems are involved. The auditor but related, database tables.
must identify and prioritize risks throughout the • Obtaining the user rights and authorization
business process across both business systems information either directly, if the auditor has
and manual processes. The auditor simply cannot access to the information, or indirectly with the
afford to evaluate SoD within a single business help of IT personnel
system without assessing SoD risks across other • Analyzing and evaluating SoD status and
related systems or manual activities. By focusing conflicts using tools. It is very possible for an
on a single system, the auditor may miss SoD auditor with good skills in daily productivity
conflicts that are not visible within the single tools, such as Microsoft Access and Excel, to
system. use such tools in analyzing SoD even for an
As a result of the comprehensive SoD risk ERP system. The preconditions are that the
assessment, the auditor should prioritize the auditor understands the user authorization
potential SoD risks based on established concept and can obtain related data about user
risk-rating criteria, such as potential impacts to authorizations in the system. Commercial tools
the business and likelihood of occurrence. Such for managing and analyzing SoD in different
risk-based prioritization allows the auditor to ERP solutions are available, but they are usually
focus on one or more important business systems quite expensive and require implementation.
and related business activities in which SoD Thus, they may not be usable or available
conflicts may most likely occur with the highest to the auditor.
adverse impacts.

ISACA JOURNAL VOLUME 4, 2010 1

 The SAP R/3 ERP solutions (e.g., SAP R/3 release 4.6C or nonstandard authorization checks depending on the specific
4.7) from SAP have some of the most flexible but complicated organization’s configurations. If an organization uses
user access and authorization design. SAP R/3 solutions standard tools, such as Profile Generator, to create necessary
are also used in many organizations globally. As a result, authorizations (i.e., authorization objects, fields, values) for
the auditor may find it useful to understand the SoD audit roles and profiles in SAP R/3, both the standard and any
techniques for the SAP R/3 environment and use a similar nonstandard authorizations required will be included in the
method toward other business systems or ERP solutions. generated profiles for assignment to users. However, some
organizations may choose to manually “tweak” the standard
SAP R/3 AUTHORIZATION CONCEPT authorizations generated by SAP R/3 for a more granular
In a nutshell and at a conceptual level, the SAP R/3 ERP level of access. As a consequence of such authorization
solutions use the so-called authorization objects, related customization, a user who is originally assigned an “Add”
fields and values of the authorization objects to manage or “Modify” transaction may now have read-only access
user access rights both in terms of what a user can do (e.g., despite that the name of the transaction suggests otherwise.
add, modify, delete, display) and what a user can see (e.g., For example, the user is no longer able to create a vendor
companies, account groups, document types). To successfully even though the user appears to have the “create vendor”
perform an activity such as adding a vendor, a user needs the transaction assigned. From an SAP R/3 SoD analysis
correct authorization objects, fields and values. Any missing perspective, the auditor must be aware of the possibility of
or incorrect authorization object, field or value may make it such authorization customization and include it in the SoD
impossible for the user to successfully perform the activity. analysis, even though this will take more time and effort.
Figure 1 summarizes the typical authorization checks Otherwise, certain false alarms may result from the analysis.
SAP R/3 performs when a user tries to run a standard Finally, it is also critical to know that SAP R/3 solutions
transaction. Customized transactions or other activities are able to turn off authorization checks globally or partially.
may have additional authorization checks depending on It is not meaningful to analyze SoD in a system in which the
configurations in SAP R/3 and/or programming design. global authorization check is deactivated. Additionally, there
It is important to note that in SAP R/3 solutions are other configurations in SAP R/3 solutions that may affect
both standard and customized transactions can require user access and results of SoD analysis. For example, an

Figure 1—SAP R/3 Authorization Concept

Layer 1
Authorization Object, Field and Value Check: Authorization
✓ Transaction code (e.g., FK01) assigned? Check
Run “transaction”:
FK01: Create New Fail Pass
Vendor
Layer 2
STOP Authorization Object, Field and Value Check: Authorization
✓ Access Level (Add) OK? Check
✓ Company allowed?
✓…

Fail Pass

STOP Go

2 ISACA JOURNAL VOLUME 4, 2010

organization may choose to use posting tolerance for financial different transactions and the types of entries in the previous
accounting users. If a user is assigned a zero tolerance, USOBT_C table. This is where standard authorization
the user will not be able to post a financial accounting checks can be deactivated through configuration, which
document in SAP R/3 solutions, even if the user has all other basically overrides standard SAP R/3 authorizations. The
authorizations. This article does not cover all the possible auditor should check this table to make sure no major
situations in which the SAP R/3 SoD analysis may be affected. authorization deactivation exists in this table.
The auditor must evaluate whether such circumstances exist • TOBJT—Description of authorization objects that help the
when performing the detailed SoD analysis. auditor understand what the authorization is about (e.g.,
account groups, company codes, document types)
SAP R/3 AUTHORIZATION TABLES AND RELATIONSHIPS • USR02—SAP R/3 user login data, containing username,
As configuration-driven ERP solutions, SAP R/3 solutions account type, account status, expiration date, etc. The
store all the user authorization information (e.g., auditor needs to differentiate a normal user from a back-end
authorization objects, fields, values, profiles, roles, users) in system or communication account. The auditor may also
several database tables that are related to each other. want to focus on active users.
There are many tables related to user access and • USER_ADDR—Containing general user information
authorizations in SAP R/3. The following are key tables that including first name, last name, department, address, etc.
store users’ authorization or related data in SAP R/3: • TSTCT—Containing transaction names, which are more
• UST04: User masters—Containing all profiles to which meaningful to the auditor than the transaction codes. This
each SAP R/3 user is assigned table contains names in multiple languages. The auditor
• UST10S: User master: Single profiles—Containing all should use his/her preferred language to display the
authorizations to which each (simple) profile is assigned transaction names in the analysis.
• UST12: User master: Authorizations—Containing all • AGR_USERS—Containing roles assigned to users. The
authorizations including authorization objects, fields and auditor can use this table and the AGR_PROF table to
values. This is the ultimate table where actual SAP R/3 user analyze authorizations assigned through roles to users, by
access rights are stored. linking them to the key authorization tables.
There are also a few important reference tables to provide • AGR_PROF—Containing profiles for each role
additional information necessary for the SoD analysis, for Figure 2 lists both the key tables and some reference tables
example: as well as their relationships that are important to the SoD
• UST10C—Containing composite profile to single profile data generation and analysis described in subsequent sections.
mappings. Composite profiles are mainly from older releases (Please note: Not all the tables listed will be covered in this
of SAP R/3 solutions and are rarely used in more current article.)
SAP R/3 solutions, such as release 4.6C and 4.7. Examples
of composite profiles include SAP_ALL and SAP_New, PERFORM SOD ANALYSIS USING MICROSOFT OFFICE
which are highly privileged default profiles in SAP R/3. The After the auditor understands the SAP R/3 authorization
auditor should link table UST04 to this UST10C table to concept and where authorization data are stored in various
check if any normal user is assigned any composite profile, SAP R/3 tables, the auditor should be ready to evaluate SAP
especially the default ones. If yes, the composite profiles R/3 SoD by following the following steps (see figure 3).
must be converted to the corresponding simple profiles
before further SoD analysis Obtain Data
• USOBT_C—Containing default or required authorization To perform the SAP R/3 SoD analysis, the auditor should
objects, fields and values for transactions. This is an obtain contents for the previously mentioned tables—ideally
important table for SAP R/3 to determine what kind of as part of preliminary requests prior to the audit. The auditor
authorizations a user must have to run a transaction. should request whole tables that are in an easily importable
• USOBX_C—Containing information regarding what format such as tab-delimited text files or in table format, e.g.,
specific authorization objects are checked by SAP R/3 for in Microsoft Access. To ensure consistency, reusability and
ISACA JOURNAL VOLUME 4, 2010 3
 Figure 2—SAP R/3 Tables Related to Authorization and SoD Analysis

UST04: UST10S: UST12:

Authorization
Key Tables User -> Profiles Profiles -> Authorizations
Authorizations
BNAME: User OBJCT: Authorization objectivity
PROFN: Profile
Auth: Authorization number
PROFILE: Profile OBJCT: Authorization object
FIELD: Authorization field
Auth: Authorization
VON: Authorization value FROM
BIS: Authorization value TO

USR02:
User Logon Data USOBT_C:
Transactions -> TSTCT:
BNAME: User
Required Authorization Transaction Text
USTYP: User type
UFLAG: User status NAME: Transaction TCODE: Transaction
USER_ADDR:
OBJECT: Authorization object TTEXT: Description
GLTGB: User expiry date User Address
FIELD: Authorization field
BNAME: User
LOW: Authorization value FROM
NAME_FIRST: First name
Reference HIGH: Authorization value TO
Tables NAME_LAST: Last name
DEPARTMENT

Figure 3—SAP R/3 SoD Evaluation Process

Obtain SAP Import Data

Authorization Clean Files Into
Data Data Files Access

Create “Transaction Analyze SOD

by User” Table Level 1

Generate “Transaction
by Authorization Level Analyze SOD
by User” Table Level 2

(Optional)

Generate “Transaction Analyze SOD

by Authorization Level Level 2
by Company Company-specific
by User” Table

4 ISACA JOURNAL VOLUME 4, 2010

the possibility of automation if necessary, the auditor should Level 1: SoD Analysis Based on Transaction Codes
also make sure that the original SAP R/3 names for the tables Assigned to Users
and fields are not changed. The level 1 SoD analysis evaluates only SAP R/3 transactions
assigned to users without scrutinizing the specific
Clean Data authorizations underlying these transactions. This level
This is an optional step, dependent on the format of the SAP of analysis is rather straightforward to perform and takes
R/3 authorization data files obtained by the auditor. If the less time. It works quite well in organizations that do not
individual providing the data files downloads them directly from customize or tweak standard authorization values in SAP R/3.
SAP R/3 using standard SAP R/3 functionalities, the files may In those that do, there is a risk of “false alarms” in that some
have unnecessary lines before or after the field name row, which users actually cannot run certain privileged transactions,
must be the first row for correct importation into Microsoft contrary to what the analysis reveals.
Access. These unnecessary rows should be removed to ensure Figure 5 depicts the design for the auditor to generate the
that the auditor can import the files into Access successfully. data table necessary to perform the level 1 SoD analysis using
Microsoft Access. The design is based on the content of
Import Data Into Access figure 2. The key is to understand that in SAP R/3, the
The auditor should use standard features of Microsoft Access S_TCODE authorization object in the authorization table
to import SAP R/3 authorization data files that the auditor (UST12) indicates transaction code assignment.
has obtained and cleaned. The auditor should watch out for Based on this design, the auditor should be able to
import errors reported by Access to make sure that all the generate a “transactions by user” table, similar to what is
required data have been correctly imported. shown in figure 6.
The auditor should pay special attention to the use of
SAP R/3 SoD Analysis wildcards in the assignment of transactions, for example:
Addressing the layered authorization approach that SAP R/3 • “*” means all transactions
adopts, as described previously, the auditor should also • “S*” means all transactions starting with letter “S”
adopt a layered approach to analyzing SoD in SAP R/3. The • “F-01” to “FV70” refers to all transactions sorted
two levels of SoD analysis (figure 4) differ in terms of time alphabetically from “F-01” to “FV70,” inclusive
required, difficulty and reliability of the results. The auditor should make sure such wildcard assignments
are included in the SoD analysis. To do so, the auditor should
Figure 4—SAP R/3 SoD Analysis Levels design a way in Microsoft Access to replace these wildcard
transactions with the corresponding individual transactions
that are necessary for subsequent level 2 analysis.
More The auditor should then use the Pivot Table feature in
by Company
Microsoft Access or Excel (if the data have been exported
LEVEL 2: SoD—
Transactions and into Excel) to visually and clearly display all the critical
Authorization Level
TIME/ by User transactions assigned to users in a “matrix” layout, similar to
DIFFICULTY
Level 1: SoD— what is shown in figure 7.
Transactions by The auditor should refer to a well-defined SoD conflict
User
rules or standards document tailored to the client’s
organization and risks in determining which critical SAP
Less
transactions should be included in the evaluation. Before
Less More looking into the details, the auditor should look for users
RELIABILITY with the highest number of critical transactions assigned (in
addition to users with “wildcard” transactions, as described
above), as well as for transactions with the most users

ISACA JOURNAL VOLUME 4, 2010 5

 Figure 5—SAP R/3 SoD Level 1 Data Generation
Authorization
Key Tables

UST04: UST10S: UST12:

User -> Profiles Profiles -> Authorizations
Authorizations = “S_TCODE”
BNAME: User OBJCT: Authorization Objectivity
PROFN: Profile
Auth: Authorization number
PROFILE: Profile OBJCT: Authorization object
FIELD: Authorization field
Auth: Authorization
VON: Authorization value FROM
BIS: Authorization value TO SoD Level 1 Table:
Transactions by
Users
USR02:
BNAME: User
User logon data
VON: Authorization value
BNAME: User TSTCT:
FROM (Transaction)
USTYP: User type Transaction text
BIS: Authorization value TO
UFLAG: User status USER_ADDR: TCODE: Transaction (Transaction)
GLTGB: User expiry date User address TTEXT: Description
TTEXT: Description
BNAME: User
NAME_FIRST: First name
Reference
Tables NAME_LAST: Last name
DEPARTMENT

Figure 6—Transactions by User Table Layout

User
SAP User First Name Last Name Type Department Authorization Object From To Transaction Description
NAME_
BNAME NAME_FIRST LAST USTYP DEPARTMENT OBJECT VON BIS TTEXT
Joe Doe Joe Doe A Accounting S_TOODE *
Joe Doe Joe Doe A Accounting S_TOODE F-01 FV70 Enter Sample Document
Joe Doe Joe Doe A Accounting S_TOODE VD01 Create Customer (Sales)
Mike Smith Mike Smith A Purchasing S_TOODE S*
Mike Smith Mike Smith A Purchasing S_TOODE FK01 Create Vendor (Accounting)

6 ISACA JOURNAL VOLUME 6, 2009

 Figure 7—Transaction by User Pivot View for Level 1 SoD Analysis

From To Description User_1 User_2 User_3 User_4 User_5 Grand Total

VON BIS TEXT
* 9
F110 F110: Parameters for Automatic Payment 1 27
F-22 F-11: Enter Customer Invoice 1 1 49
F-27 F-27: Enter Customer Credit Memo 1 1 49
F-28 F-28: Post Incoming Payments 1 1 49
F-31 F-31: Post Outgoing Payments 1 1 49
F-41 F-41: Enter Vendor Credit Memo 1 1 49
F-43 F-43: Enter Vendor Invoice 1 1 49
F-52 F-52: Post Incoming Payments 1 1 49
F-53 F-53: Post Outgoing Payments 1 1 49
FD01 FD01: Create Customer (Accounting) 6
FK01 FK01: Create Vendor (Accounting) 6
FS00 FS00: G/L Acct Master Record Maintenance 1 1 1 68
FV70 FV70: Enter Outgoing Invoices 1 1 49
SU01 SU01: User Maintenance 2
XD01 XD01: Create Customer (Centrally) 6
XK01 XK01: Create Vendor (Centrally) 6

Grand Total 1 2 20 1 18 1010

assigned. This may allow the auditor to quickly focus on risky “transactions by user” table from the level 1 SoD analysis and
SoD areas. At the individual user level, the more numbers other related tables, should be used to generate the required
a user has corresponding to different transactions, the more data for the level 2 SoD analysis.
SoD conflict risk the user’s access may pose. Once the auditor generates the authorization data
Once again, the auditor should not forget to evaluate SoD necessary to perform the level 2 SoD analysis, the actual
conflicts from users’ access to other upstream or downstream analysis is identical to the level 1 SoD analysis, using the
systems or activities. Pivot Table feature in Microsoft Access or Excel. The
additional information available for the analysis is the actual
Level 2: SoD Analysis Based on Precise User Authorizations authorization level (e.g., add, modify, delete). The auditor
This level of SoD analysis in SAP R/3 is more reliable, but will be able to differentiate when a user is assigned a critical
requires more time and effort, especially for auditors not transaction with read-only access, which is less risky.
familiar with the usage of multiple table-related queries in Within the level 2 SoD analysis, the auditor can evaluate
Microsoft Access. users’ ability to access different companies’ records within
The design to generate data for the level 2 SoD analysis is SAP R/3. This is important, for example, in a shared service
depicted in figure 8. The key concept is to find the required model in which several companies share one single SAP R/3
authorization values for SAP R/3 transactions and match “instance” or system. It is certainly a risk for users from other
them with actual authorizations to determine whether users companies to be able to perform activities in the concerned
actually have the authorizations to run specific transactions. company. From an SoD perspective, what a user can see is
The aforementioned USOBT_C table, together with the also important, in addition to what a user can do. Evaluating

ISACA JOURNAL VOLUME 6, 2009 7

 Figure 8—SAP R/3 SoD Level 2 Data Generation

UST04: US10S: UST12:

User -> Profiles Profiles-> Authorizations
Authorizations
BNAME: User OBJECT: Auth. Objecty
PROFN: Profile
Auth: Authorization number
PROFILE: Profile OBJECT: Authorization object
FIELD: Authorization field
Auth: Authorization number
VON: Authorization value FROM
BIS: Authorization value TO

Temp. Table 2: Temp. Table 1: Level 2 SoD Table:

Required Actual Transaction and Authorizations
SoD Level 1 Table: USOBT_C: Authorizations Authorizations Level by User
Transactions by Transactions ->
Users Required Authorizations BNAME: User BNAME: User BNAME: User
BNAME: User NAME: Transaction VON: Authorization value OBJECT: Authorization object VON: Authorization value
FROM (Transaction) FIELD: Authorization field FROM (Transaction)
VON: Authorization value OBJECT: Authorization object
FROM (Transaction) FIELD: Authorization field OBJECT: Authorization object VON: Authorization value FROM OBJCT: Authorization object
LOW: Authorization value FROM FIELD: Authorization field actual FIELD: Authorization field
HIGH: Authorization value TO LOW: Authorization value FROM BIS: Authorization value TO LOW: Authorization value FROM
required required actual
VON: Authorization value
FROM actual
BIS: Authorization value TO

users’ access capabilities to different company codes in include the exceptional situations in the data tables before the
SAP R/3 measures what users can see. In some large level 1 or level 2 SoD analysis.
organizations, users may even be assigned to different vendor, It is also possible to automate both level 1 and level 2 SoD
customer or general ledger groups so that the users can data generation steps, as described here, as long as the auditor
only perform related transactions on their assigned vendor, makes sure the authorization tables and fields obtained use
customer or general ledger accounts. The level 2 analysis is standard SAP R/3 names. This makes sense if the auditor
able to reveal situations in which users can access only their needs to regularly evaluate SoD for identical business systems
assigned vendor, customer or general ledger account groups, such as SAP R/3. Automating time-consuming steps increases
similar to company code access, as described previously. efficiency and lowers manual mistakes.
Figure 9 depicts a simplified SoD level 2 analysis based on
an Access or Excel Pivot Table, including all the required and CONCLUSION
actual authorization levels by transaction code, for the auditor Evaluating SoD in a business application system is an integral
to determine whether a user can perform a transaction before part of evaluating SoD in interrelated business processes.
SoD evaluation is performed. The auditor should follow the same risk-based approach in
the evaluation process. The auditor must evaluate major SoD
Other Considerations conflicts both within the business system and across other
While the steps for level 1 and level 2 SoD analyses will connected systems or manual activities, based on well-defined
not change in practice, the auditor should always watch out and risk-justified SoD conflict rules.
for the exceptional situations (e.g., the use of “wildcard” Given the complicated nature of many business systems,
transactions and composite profiles) that may affect the especially ERP solutions, the auditor should use computer
SoD analysis. By using standard functionalities in tools such tools starting with those that are inexpensive and readily
as Microsoft Access or Excel, the auditor should be able to available, for example, those in the Microsoft Office suite, to

8 ISACA JOURNAL VOLUME 6, 2009

 Figure 9—Transaction and Authorization Level by User for SoD Level 2 Analysis
USER

01 – Add 01 – Add
02 – Change 02 – Change
03 – Display 03 – Display
* – All * – All User_1 User_2 User_3 … Grand Total Auditor Comments

AUTHORIZATION OBJECT
TRANSACTION DESCRIPTION FIELD REQUIRED VALUE ACTUAL VALUE
VON:
FIELD: Authorization
AUTHORIZATION OBJECT Authorization LOW: Authorization Value
Text DESCRIPTION field Value FROM-Actual FROM-Actual Count Count Count Count Count
FB60: Enter Accounting Document: ACTVT 01 * 1 1 4 ‘All’ (*) access granted to User_1, User_3…
Incoming Authorization for Account
Invoices Types 03 * 1 1 1 4 Read-only access granted to User_2

KOART $KOART * 1 1 1 4 All account types granted to User_1, User_3…

Accounting Document: ACTVT 01 * 1 1 4 ‘All’ (*) access granted to User_1, User_3…

Authorization for Business
Areas 03 * 1 1 1 4 Read-only access granted to User_2

GSBER $GSBER * 1 1 1 4 All business areas granted to User_1, User_3…

Accounting Document: ACTVT 01 * 1 1 4 ‘All’ (*) access granted to User_1, User_3…

Authorization for Company
Codes 03 * 1 1 1 4 Read-only access granted to User_2

BUKRS $BUKRS * 1 1 1 4 All companies areas granted to User_1, User_2, User_3…

Accounting Document: ACTVT 01 * 1 1 4 ‘All’ (*) access granted to User_1, User_3…

Authorization for
Document Types 03 * 1 1 1 4 Read-only access granted to User_2

BRGRU (Blank) * 1 1 1 4 All document types granted to User_1, User_2, User_3

Summary: User_1, User_3 have full access to post incoming

invoices.
User_2 has read-only access only
FKO1: Create Vendor: Account ACTVT 01 * 1 1 4 ‘All’ (*) access granted to User_1, User_3…
Vendor Authorization
(Accounting 01 1 2 ‘Add’ access granted to User_2…

BRGRU (Blank) * 1 1 1 6 All account granted to User_1, User_2, User_3…

Vendor: Account Group ACTVT 01 01 1 1 1 6 ‘Add’ access granted to User_1, User_2, User_3…
Authorization
KTOKK (Blank) * 1 1 1 6 All account groups granted to User_1, User_2, User_3

Vendor: Application ACTVT 01 01 1 1 1 6 ‘Add’ access granted to User_1, User_2, User_3…

Authorization
APPKZ F * 1 1 1 6 All application granted to User_1, User_2, User_3…

Vendor: Authorization for ACTVT 01 * 1 1 4 ‘All’ (*) access granted to User_1, User_3…
Company Codes
01 1 2 ‘Add’ access granted to User_2…

BUKRS $BUKRS * 1 1 1 6 All companies granted to User_1, User_2, User_3…

Vendor: Central Data ACTVT 01 01 1 1 1 6 ‘Add’ access granted to User_1, User_2, User_3…

… Summary: User_1, User_2, User_3 have full access to create

vendor in accounting.
User_2 can only create vendor—OK
Grand Total 32 19 31 31 142 User_1, User_3 can create vendor and post invoices to the
vendors—Conflicts; User_2 can only create vendor—OK

aid the efficient and effective SoD evaluation. Once auditors become more comfortable and skillful with the methods
master the concept, design and steps in evaluating SoD in and tools, they can further improve and automate the SoD
complicated systems such as SAP R/3, they should be able to evaluation process, especially if the same types of business
apply the same approach to other ERP or business systems as systems are evaluated regularly. However, auditors must use
long as they take the time to understand the similarities and their judgment and knowledge in determining SoD risks based
differences in authorizations in different systems. As auditors on good understanding of the risks in the specific business.

The ISACA Journal is published by ISACA®. Membership in the association, a voluntary organization serving IT governance professionals, entitles one to receive an annual
subscription to the ISACA Journal.

Opinions expressed in the ISACA Journal represent the views of the authors and advertisers. They may differ from policies and official statements of ISACA and/or the IT Governance
Institute® and their committees, and from opinions endorsed by authors’ employers, or the editors of this Journal. ISACA Journal does not attest to the originality of authors’ content.

© 2010 ISACA. All rights reserved.

Instructors are permitted to photocopy isolated articles for noncommercial classroom use without fee. For other copying, reprint or republication, permission must be obtained in
writing from the association. Where necessary, permission is granted by the copyright owners for those registered with the Copyright Clearance Center (CCC), 27 Congress St.,
Salem, MA 01970, to photocopy articles owned by ISACA, for a flat fee of US $2.50 per article plus 25¢ per page. Send payment to the CCC stating the ISSN (1526-7407), date,
volume, and first and last page number of each article. Copying for other than personal use or internal reference, or of articles or columns not owned by the association without
express permission of the association or the copyright owner is expressly prohibited.

www.isaca.org

ISACA JOURNAL VOLUME 4, 2010 9