Sie sind auf Seite 1von 61

Expert Advice for

Developing a
Segregation of Duties
(SoD) Risk Matrix
Within a Global
Heinrich Wilking
Turnkey Consulting

© Copyright 2013
Wellesley Information Services, Inc.
All rights reserved.
In This Session …

• Provide practical tips for how to create an SoD risk matrix that
meets the compliance requirements of a global organization
• Explain how to communicate the development of an SoD risk
matrix effectively in a virtualized global organization and engage
with business and audit stakeholders
• Use SAP Access Control access risk analysis (ARA) within
access request management (ARM) and for mitigations
• Use ARA for clean role development using GRC AC business role
management (BRM)
• Consolidate compliance reporting using SAP solutions for GRC
as a single technology layer

What We’ll Cover ...

• Some background about the project

• Compliance and Segregation of Duties
• Create the Company’s SoD risk matrix
• Risk analysis and mitigation controls processes
• Consolidated compliance reporting using SAP GRC as a central
point for cross-system SoD analyses
• Wrap-up

Project Background

• The company is a global mining and chemical company

• Businesses in more than 60 countries
 Many acquisitions recently

 Some small country businesses with organizational

limitations for strict segregation of duties adherence
 Different regional compliance requirements

• More than 10 years SAP experience in some countries

 Mainly ERP

 Some experience with SAP GRC 5.3

 With a portfolio of various non-SAP applications

 Business processes not consistent across all businesses

 Audit reported SoD conflicts in legacy environment

Project Background (cont.)

• New global greenfield SAP implementation

 With complete new global business process

 More than 50 new business processes in blueprint

 SoD risks not covered – not unusual!

 Various SAP applications included, e.g.:

 ERP, CRM, SCM, CLM, BW/BI, HR, PI, Solution Manager

 Plus non-SAP applications

• Little central physical project office with virtual and remote teams
 In key businesses

 In different time-zones across the globe

 Strong need to use collaboration technology

What We’ll Cover ...

• Some background about the project

• Compliance and Segregation of Duties
• Create the Company’s SoD risk matrix
• Risk analysis and mitigation controls processes
• Consolidated compliance reporting using SAP GRC as a central
point for cross-system SoD analyses
• Wrap-up

What Is Segregation of Duties All About?

• Why are segregation of duties controls important to the business?

Segregation of Duties is the separation of incompatible duties that could
allow one person to commit and mask fraud that may result in financial loss
or misstatement of accounts

 Entail separation of specific duties in a business process cycle

so that not one person performs all the areas of that cycle, e.g.:
 Maintain bank accounts and approve payments

 Avoid users with extensive authorisations within SAP

 Provide transparency of access risks in user provisioning
 Balance risks and business requirements based upon SoD

Segregation of Duties

• The three dimensions of SoD

 Bridging these dimensions is essential

 Not trivial; requiring knowledge of business processes,

systems, and controls

Business and Business

Compliance processes
Environment Tasks

Systems Legal structure

Applications SAP client
Authorizations Org Unit


Segregation of Duties (SOD)

Where a combination of two or more Example:
transactions could lead to the risk of error or Access to vendor creation and
fraud, segregation of duties is required to vendor payments; they could create a
prevent a single user from having that
fictitious vendor and make fraudulent
combination of access

Sensitive Access
Sensitive Access is a single transaction that could
Example: present a risk to the business if used
inappropriately. Such transactions should only be
Post Inventory Differences
provided to people who are experienced in the
relevant area.

Compliance and Segregation of Duties

• Sarbanes-Oxley and other regulatory requirements are forcing

companies to increase their awareness and accountability of their
employee’s actions within the companies and markets in which
they operate
 The number of incidents with poor management of SoD risks is
increasing; examples are in the press
 Auditors and corporate management increasingly require the
business to manage SoD risks
• SOX compliance becomes more regional as part of globalization
 EuroSOX, J-SOX, UK Anti-Bribery Act, etc.
 With more local compliance variations to come
 Country-specific
 Germany:“Bilanzmodernisierungsgesetz” (BilMoG)
Compliance and Segregation of Duties (cont.)

• New laws and prosecution of security violations is bringing a new

awareness to monitoring and controlling security and systems
access within organizations
 Lack of Segregation of Duties is resulting in Fraud Risk, Failed
User Management Processes, or Incorrect Accounting
 Application-specific and cross-application SoD required to
address business processes
 Disclosure of sensitive information and corporate intellectual
property can result in negative impact on a company’s market
 Driving the need for proactive segregation of duties and
control over access to data

What We’ll Cover ...

• Some background about the project

• Compliance and Segregation of Duties
• Create the Company’s SoD risk matrix
• Risk analysis and mitigation controls processes
• Consolidated compliance reporting using SAP GRC as a central
point for cross-system SoD analyses
• Wrap-up

Approach to Segregation of Duties

• The company decided to develop an SoD risk matrix as part of the

systems and business process implementation
 Identify SoD risks of to-be business processes to:

 Avoid SoD risks as an after-thought

 Allow business process changes before configured within

the systems
 Manage SoD implementation costs efficiently

• Take the business process blueprint documents by:

 Interpreting more than 50 process documents

• Proposal for managing SoD within small business entities

• Validate the technical feasibility of the SoD matrix within GRC AC
ARA 10.0
Approach to Segregation of Duties (cont.)

• High-Level Process Flow for SoD Risk Analysis within GRC

User requests Line Manager
change to System No conflict –
approves the Security System
their SAP change and
access based reviews Security
submits to request actions
on business System
role against rules request
Security team

Conflict not Business risk Line Manager Conflict exists –

champion accepts or System
cannot be
mitigated – reviews business decides to Security rejects
reject request to rationale, risk, escalate access request to line
line manager and controls requirement manager

GRC Governance Request rejected

Request valid. Committee OR
Present to GRC reviews. Is risk approved and System Security
Governance acceptable/ passed to System actions request
Committee. mitigated? Security to action
Approach to Segregation of Duties (cont.)

• How does SoD integrate within SAP AC modules?

Access Request
ARM Management

Emergency Access
Business Role
Management BRM EAM Management

Reporting &

Approach to Creating the SoD Risk Matrix

• Step 1 – Review of the 50 process documents

• Step 2 – Identification of SoD and Sensitive Transactions
• Step 3 – SoD and Critical Transactions agreement with Business/
Validation workshops
• Step 4 – Create SoD risk matrix
• Step 5 – Definition of mitigating controls
• Step 6 – SoD and Mitigating Controls Upload within GRC
• Step 7 – Config of Compliant Role Dev Workflow
• Step 8 – Documentation
• Step 9 – Testing

Project Steps to Segregation of Duties, Step 1

• Review SoD risks of the 50 process documents

30 May Jul Oct Nov

1 2 3 4
Prep Detailed Design Design
High-Level Design Process Design
Phase •

• “Fit Gap” Design


Workshops – high-level
Set up Design
Bizz Proc walkthroughs
Design Customer Workshops –
Approach Finance Process design and Prototyping
Workshop Supply Chain Work- Customer
shops Finance ration SoD Risks
Prioritised Supply Chain Work- included
Scope shops
Plant System and
walkthroughs of
Workshops – “Fit Gap” workshops
Identify SoD Risks integrated
Project Steps to Segregation of Duties, Step 2

• Identification of SoD and Sensitive Transactions

 Utilize SoD input
 Legacy SoD risk matrix
 Audit SoD findings
 Standard SAP SoD risk matrix for basis component and
IT risks
 Standard SoD risk matrix can be too general for business
process or transaction SoD risks
 Is based on standard SAP business processes = most SAP
implementations are not standard
 Some SoD risks not relevant to the organization, e.g., small
 Web applications not included, e.g., CRM with UICOMP
Project Steps to Segregation of Duties, Step 3

• SoD and Critical Transactions agreement with Business/

Validation workshops
 8 workstreams identified

 About 15 virtual participants plus project team per workstream

 Structure of workshops per workstream:

1. W/s Initial presentation of SoD draft by project team

2. W/s Analysis and suggested changes by business

Some 50 workshops held,
3. W/s Final questions
1,5-2 hours per workshop
4. W/s Internal Audit over a period of 5 weeks
5. W/s final validation

6. SoD Conflicts Validation Workshops

Experience from Business/Validation
• All workshops held using Web collaboration tools
• Managing 15 participants online requires strong discipline and
tough workshop management
 Strong communication and conflict management skills are a
• Time zone impact not to be underestimated
• Exclude conflicts from the workshop and deal with them
• Planning of this many workshops within a short time-period
requires excellent multitasking skills

Project Steps to Segregation of Duties, Step 4

• Create SoD risk matrix

 Mix of ABAP and Web applications

 T-Code analysis was not an option as this was a greenfield

implementation and mix of SAP and non-SAP systems
 SoD structure followed the business processes:

 O2C

 P2P – Supply Chain

 Accounting

 HR

 Inventory Management

 Plant Systems and Quality Management

SoD Risk Matrix Terminology

• Risks
• Functions
• Actions
• Permissions
• Rules

Structure of an SoD Risk Matrix

Rule Set Company SoD Rule Set

Maintain Purchase Orders

Risk and Manage Goods Receipt

Functions Maintain Purchase Orders Manage Goods Receipts

Actions ME21N – Create ME22N – Change MIGO – Goods MB01 – Post

Purchase Order Purchase Order Movement Goods Receipt
on PO

Permissions Create PO for Create PO for Create GR for Create GR for

company codes purchasing area company code purchasing area

SoD Risk Matrix Terminology – Risks

• A risk is an opportunity for physical loss, fraud, or disruption to

processes or operations caused by individuals performing a
specific activity
• A risk is linked to a business process
• Risks define the access that will be configured in the ruleset for
monitoring (“top-down” approach)
• Important to identify and document all relevant business risks
• A risk is comprised of one or two functions
• Sensitive Access risk is one function
• Segregation of Duties risk consist of two or more functions

SoD Risk Matrix Terminology – Functions

• Functions define the actions and permissions (authorizations)

required to perform a task (e.g., process payroll)
• A function can comprise of one or several actions
Risk ID Function 1 Function 1 Function 2 Function 2 Description of Risk
ID ID Risk Level
F001 GL02 Maintain G/L GL01 Post Journal Create fictitious G/L High
Master Entry account and
Records generate journal
activity or hide
activity via posting
S003 SD05 Sales Order, SD01 Customer Create fictitious High
Agreements, Master customer and initiate
or Contracts Maintenance fraudulent sales

Maintain GL Master Records FS01 Post Journal Entry FB01

Maintain GL Master Records FS02 Post Journal Entry FB05
Maintain GL Master Records ... Post Journal Entry ... 24
SoD Risk Matrix Terminology – Actions

• Actions are activities performed in the system to fulfill a certain

• In SAP, each action relates to a specific SAP transaction
 E.g., run off-cycle payroll

• In non-SAP systems, actions and program functions are protected

by permissions

SoD Risk Matrix Terminology – Permissions

• Authorisations in the system which allow users to perform

specific activities
 E.g., access to an SAP transaction MIGO to perform GR and
associated authorisations to cost centers, vendors, etc.
 Permissions terminology may be different in non-SAP systems

• Permissions are normally associated with an action, but they can

 E.g., write debug access (no transaction required in SAP)

SoD Risk Matrix Terminology – Rules

• Generated by the systems to report on risks within business

• Technical implementation of the risks within GRC AC ARA, so it
can be used for analyses
• A combination of risks, functions, actions, and/or permissions
• Users who meet the rule criteria will be identified in the system
 I.e., an SoD conflict

• Risks are split into action, permission, critical action, and critical

Visualization of the SoD Risk Matrix (Extract)

• Conflicting business functions

Visualization of the SoD Risk Matrix (Extract)
• SoD functions in SAP GRC AC ARA format

Visualization of the SoD Risk Matrix (Extract)
Function ID Function description Business Activity
BS02 BS02 – Basis Development Basis Development
BS03 BS03 – Basis Table Maintenance Basis Table Maintenance
BS04 BS04 – Basis Utilities Basis Utilities
BS05 BS05 – Client Administration Client Administration
BS06 BS06 – Configuration Configuration
BS07 BS07 – Create Transport Create Transport
BS08 BS08 – Maintain Number Ranges Maintain Number Ranges
BS09 BS09 – Perform Transport Perform Transport
BS10 BS10 – Security Administration Security Administration
BS11 BS11 – System Administration System Administration
BS12 BS12 – Transport Administration Transport Administration
BS13 BS13 – Maintain User Master Maintain User Master
BS14 BS14 – Maintain Profiles/Roles Maintain Profiles/Roles
BS15 BS15 – Basis Archiving Actions Basis Archiving Actions
BS16 BS16 – Basis Configuration Actions Basis Configuration Actions
BS17 BS17 – Basis Critical Actions Basis Critical Actions
BS18 BS18 – Basis Performance Monitoring Basis Performance Monitoring
BS19 BS19 – Basis Security Actions Basis Security Actions
BS20 BS20 – Profile Administration Profile Administration
BS21 BS21 – User/Role Maintenance User/Role Maintenance 30
Mitigating Controls Responsibilities

Roles Responsibilities
Report/Audit • View Risks and Mitigation Controls
• View Ruleset
• View audit reports
• View security reports
Business Process • Identify and validate risks
Owners • Validation and ownership of mitigating controls

Tech • Own technical RAR implementation and maintenance

Administrators • Manage security process and administration

GRC Coordinator • Perform periodic testing of rules (Risk Analysis Simulations)

• Perform risk assessment on a regular basis
• Review mitigating controls
GRC Admin • Own the ruleset
• Manage change control over the ruleset
• Responsible for ruleset sign-off and periodic review
• Manage change control over Mitigating controls
• Manage background jobs and reprocess errors

What We’ll Cover ...

• Some background about the project

• Compliance and Segregation of Duties
• Create the Company’s SoD risk matrix
• Risk analysis and mitigation controls processes
• Consolidated compliance reporting using SAP GRC as a central
point for cross-system SoD analyses
• Wrap-up

SoD Risk Analysis Within the Request
Workflow (Selected Option)

Requester Create and


Review Perform Risk
Request Analysis

Access Risks
Modify Approve
Request Access?
No Yes
Approve User
Request? Provisioning


No Reject Request
Request Closed

Project Steps to Segregation of Duties, Step 5

• Definition of mitigating controls

 Small entities have difficulties avoiding SoD due to its size

 Options

 The SoD risk is still valid

 Define mitigations by using controls that compensate for the

risks, e.g.:
 Use neighbor countries to ensure a 4-eye principle

 Delegate controls to a higher org-level

 Automate controls through GRC PC or specific ABAP

 Be pragmatic and concentrate on importance of SoD risks

What Are Mitigating Controls?

• Mitigating controls are controls that, when put in place, mitigate

the associated risk of an SoD control
 NOT relevant for sensitive access risks

• Are master data records that can be assigned per risk

• Often used when:
 Segregation of tasks is not feasible (e.g., small businesses)

 Cost of remediation is deemed too high

• Each mitigating control is usually applicable for a single risk and

can be:
 Global, if applicable to all users for that risk

 Local, if applicable to one user or group of users (as

determined by territory or job function, etc.)
Mitigating Controls Decision Tree

Is this a new SoD New SoD Does a control exist

Risk or a new user Risk in GRC that
identified for an mitigates the new
existing SoD Risk? risk?
Yes No
Existing SOD Risk

Does a mitigating
Yes Assigning
control linked to the
risk apply to the
Control to
new users

Does a control exist

Creating Yes in the control
framework that
mitigates the risk?
Define a new
control and
add to the

Creating Mitigating Controls

• Define naming convention to allow easy ID

Specify Control ID of controls

• Control Definition
Enter Description • Why/What/Who/Frequency

• Select appropriate Business Unit that the
Assign Business Unit mitigating control applies to

Assign Approver and • Select management approver from list of

individuals maintained for each Business
Monitor Unit and enter relevant monitor ID

• Assign the associated risk IDs to the

Assign Risk IDs control

Mitigating Control Creation and Assignment
Does a Does a
Unmitigated Control Linked No
Control Exist
in the Control
risk identified to the Risk in Framework
GRC Apply to
on a user the New Users
that Mitigates
the Risk?

Is it a
Send Details of Local Global or Fill in “New
GRC Risk Mitigating Control Local
Local Mitigating Control”
and Control Assignment to “GRC Mitigating
Form and Send to
Support” “GRC Support”

Send Details of Local Send Details of

Mitigating Control Global Mitigating
Assignment to “GRC Control Assignment
Support” to “GRC Support”

Control Define a New

Control and Add
Framework to Control
Assign Create New Create New Assign Process
Mitigating Mitigating Control Mitigating Control Mitigating
GRC Control to Record for that Record for that Control to All
Individual User risk in GRC risk in GRC Users (* Value) GRC

Periodic Mitigating Controls Review

Step 2: Is Step 3: Does Step 4: Is

Review Step 1: Does Mitigating Mitigating
Yes Mitigating Yes Yes Yes
Mitigating Mitigating
Control Still Control Still
Controls Control Still
Mitigate Applicable for
Exist? Associated Associated
Report Effectively? Risk? Users?
No No No No

GRC Risk Does Any Other

and Existing Control in
Control Framework
Control Mitigate
Associated Risk?
No Remediate Unmitigated Risk by Either:
Retain Evidence
1 – Requesting Removal of Conflicting of Mitigating
Perform Review of System
Access or Define and/or Request
Logs to Determine if
Assignment of a New Control that will
Control Review
Unmitigated Access has had
Mitigate the Risk Going Forwards
Impact on Financial Data and
(Relevant to Step 1, 2, or 4)
Action as Appropriate
2 – Remediate Existing Deficient Mitigating
Control (Relevant to Step 2 Only)

Generate Report Remediate Unmitigated Risk

in GRC Showing Send Mitigating
by Either Removing
GRC List of Mitigating Controls Report
to GRC Risk and
Conflicting Access or
Support Controls and Control Owner for
Assigning New Mitigating
Assignments to Control to Risk and GRC
Users and Risks Associated Users Process

Definition of Mitigating Controls

• Processes/workflows defined within the project

 Creation of mitigation controls

 Assignments of mitigations

 Control of mitigations

• Outside the project and after implementation of the systems

 Content for mitigations

 Mitigations for:

 Risks

 Org levels, e.g., for small countries

 Users groups with ongoing SoD conflicts within requests

Project Steps to Segregation of Duties, Step 6

• SoD and Mitigating Controls Upload within GRC

 Two options:

 Manual Entry

 Difficult to ensure correctness and completeness

 Upload/import to GRC

 Some configuration requirements

 Selected option within this project

 Testing is necessary

 Database overload identified during first upload due to large

upload file; some 12.000 line items on permission level

Upload of the Risk Matrix Has Various Files
in CSV Format
• Business processes: 12 processes
• Risk IDs and Risk Descriptions:
 149 defined across all systems and processes

• Risk Ruleset
• Functions: 81
• Functions combinations
• Rule Sets: 1
• Actions: 1.046
• Permissions: 12.000

Project Steps to Segregation of Duties, Step 7

• Config of Compliant Role Dev Workflow

 GRC AC Business Role Management (BRM)

 High-Level process configured within the project

 Allowing “SoD clean” role development for role developers

over the global systems roll-out phase
 Application of BRM outside the SoD Risk Matrix development
 BRM used by role developers during systems implementation

Compliant Role Dev Workflow Using BRM
Source SAP

Apply the SoD Risk Analysis


Project Steps to Segregation of Duties, Step 8

• Documentation
 Workshop documentation

 Make sure decisions and comments are documented, as life

is changing and so are business processes
 Commit W/s participants to their decisions

 Get formal approval from business owners

 Compliance requirement as business is responsible for risk

 Completeness check of uploaded Risk Matrix

 Complete number of risks, functions, actions, permissions

 Can be complex due to number of data records

 Develop completeness check tools

Project Steps to Segregation of Duties, Step 9

• Testing
 The main objective is that the created SoD Risk Matrix meets
the conflict of interest risks of the business
 Provides the correct results in:

 SoD Risk analyses within user access requests

 SoD compliance analyses of users and roles

 Define test environment

 Systems of risks, functions, user groups, business

 Watch out for custom developments, e.g., Z-transactions

 Must be listed in table SU24 to be included for Risk Analysis

in ARA
Test Scenarios (Examples)

2.1 Ruleset Generation

2.2 Risk Analysis – Single User
2.3 Ability to create new Function
2.4 Ability to create new risks
2.5 Ability to change rule Status
2.6 Risk Analysis – Single User
2.7 Risk Analysis – Multiple User
2.8 Risk Analysis – Single Role
2.9 Risk Analysis – Multiple Roles
2.10 Background Processing
2.11 SoD/SA Reporting – Foreground
2.12 SoD/SA Reporting – Background
2.13 Risk Analysis – Role Access Simulation
2.14 Risk Analysis – User Access Simulation
2.15 Risk Analysis Reports – Print/Export
2.16 Full Batch Risk Analysis (BRA) setup and Monitoring
2.17 Incremental Batch Risk Analysis (BRA) setup and Monitoring
2.18 Create Mitigation

What We’ll Cover ...

• Some background about the project

• Compliance and Segregation of Duties
• Create the Company’s SoD risk matrix
• Risk analysis and mitigation controls processes
• Consolidated compliance reporting using SAP GRC as a central
point for cross-system SoD analyses
• Wrap-up

Consolidated Compliance Reporting

• GRC AC is a centralized platform that allows:

 Integrated SoD reporting and analysis features

 Cross-system, cross-application coverage

 SAP and non-SAP systems

 Connectors from SAP and other vendors for non-SAP

systems integration
 Make sure you understand SoD risks in each system and
risks cross-systems and applications

Consolidated Compliance Reporting (cont.)

• Several Report Options, including Dashboards, e.g.:

Action Level • Select to perform SoD analysis at action level

• Select to perform SoD analysis at action and

Permission Level permission level

• Use to analyse users with access to critical

Critical Actions functions (actions + permissions)

• Allows analysis of users with access to critical

Critical Permissions functions (only at the permissions level)

Critical Roles/ • Analyses users having access to critical roles or

Profiles profiles

Assignment of • Analysis of assignment of mitigating controls

mitigation controls
Consolidated Compliance Reporting (cont.)

• Each report type provides data in differing levels of detail

• The default report type can be set in “Configuration” tab
• Several “report format” options

Executive • Provides risk description and count of

Summary rules causing the conflicts

Management • Displays users along with conflicts


Summary • Displays users or roles and action conflicts

• Provides greatest detail of all the reports

Detail • Most useful for remediation activities
Running Risk Analyses

• To reduce the scope of report output, it is possible to exclude the

following from reporting:
 Critical roles
Config setting: Ignore Critical
 Critical profiles
Roles and Profiles = Yes
 Mitigated users

• Mitigated users are excluded by selecting the exclude mitigation


Note: you need to put an * after risk ID!

• Prefer using “Background” processing

What We’ll Cover ...

• Some background about the project

• Compliance and Segregation of Duties
• Create the Company’s SoD risk matrix
• Risk analysis and mitigation controls processes
• Consolidated compliance reporting using SAP GRC as a central
point for cross-system SoD analyses
• Wrap-up


• An SoD Risk Matrix development requires different competencies

 Business process

 SAP application knowledge

 Compliance expertise

• Input from business function is essential

• Standard SAP Risk Matrix is often not adequate and requires
• Mitigations can be used as compensating controls

GRC Glossary

SAP GRC SAP’s application for Governance, Risk Management, and Compliance
SAP GRC AC The Access Control component of GRC, having additional modules
GRC AC ARM AC component for Access Request Management. Latest terminology that replaces the
CUP and the UAM terms.
GRC AC UAM AC component for User Access Management workflows. UAM term is replaced by ARM.

GRC AC CUP AC component for Compliant User Provisioning workflows that support user access
requests, approval, and implementation processes
GRC AC RAR AC component Risk Analysis and Remediation, focuses on Segregation of Duties and
Critical Access controls as part of the provisioning and role design workflows

GRC AC ARA AC component for Access Risk Analysis. Latest terminology that replaces the RAR
GRC AC ERM AC component Enterprise Role Management, supports role design workflows, including
audit trails for requests for new roles or changes of roles, approval of changes,
mitigation of SoD rules (using RAR)
GRC AC BRM AC component for Business Role Management. Latest terminology that replaces the
ERM term.
GRC AC EAM AC component for Emergency Access Management. Latest terminology that replaces
GRC AC SPM AC component for temporary critical access called Superuser Privilege Management (IT
and business). This functionality is known as Firefighter in previous GRC AC releases.

Where to Find More Information

• SAP GRC Access Control 10


• SAP Community Network

• SAP Notes ( *)

 SAP Note 1696581 – Cross System SoD Analysis in AC 10.0

• Meeting Segregation of Duties and Mitigations


* Requires login credentials to the SAP Service Marketplace 56

7 Key Points to Take Home

• SAP GRC ARA covers SAP AND non-SAP systems for cross-
application SoD Risk Analysis and for global corporate business
processes, as well as for local processes
• Regulatory requirements force management of SoD risks
• Always involve business functions
• SoD risk management is an ongoing process
• Compensating controls are a good option for management of SoD
risks in small business entities
• GRC reporting provides managers with short, concise reports
about violations that require action
• Although SoD risk matrix is complex – development can be
achieved with limited effort
Your Turn!

How to contact me:

Heinrich Wilking
Please remember to complete your session evaluation

SAP, R/3, mySAP,, SAP NetWeaver®, Duet®, PartnerEdge, and other SAP products and services mentioned herein as well as their
respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and
service names mentioned are the trademarks of their respective companies. Wellesley Information Services is neither owned nor controlled by SAP.

Wellesley Information Services, 20 Carematrix Drive, Dedham, MA 02026
Copyright © 2013 Wellesley Information Services. All rights reserved.