Case Study: Building the Business Case for

SAP Security Role Redesign at Beam Suntory

Ivanka Gajecky
Beam Suntory
Produced by Wellesley Information Services, LLC, publisher of SAPinsider. © 2016 Wellesley Information Services. All rights reserved.
In This Session

• Hear how Beam tackled the challenges of outdated role structures

• Walk away with a framework to help you determine if role redesign is appropriate for your
organization
• See how to identify the key project considerations, establish timelines, and secure
executive support
• Understand the key variables to consider when estimating the effort and resources
needed to plan and execute a role redesign project
• Get key decision points for performing Access Control design and role design in a phased
approach (separately vs. together)

1
About Beam Suntory

As the world’s #3 premium spirits

company, Beam Suntory is Crafting the
Spirits that Stir the World. Owned by
Suntory Holdings Limited, Beam
Suntory has a dynamic portfolio with
unparalleled expertise in whisky, led by
Bourbon and Japanese Whisky, and
global strength across many key
categories including tequila, vodka,
cognac, rum, and cordials.

2
About Beam Suntory (cont.)

Single SAP instance globally

Presence in Japan, North America, EMEA, Asia Pacific, and South America

Centralized and decentralized business functions

Approximately 2,500 users

Finance, Order-to-Cash, Supply Chain, Master Data, Manufacturing modules

3
What We’ll Cover

• Using a framework to help you determine if role redesign is appropriate for your
organization
• Identifying the key project considerations, establishing timelines, and securing executive
support
• Understanding the key project variables
• Establishing decision points for performing Access Control design and role design in a
phased approach (separately vs. together)
• Understanding success factors and next steps
• Wrap-up

4
Current State
• In the case of Beam Suntory, the current SAP security structure is creating challenges for the business and
may become unsustainable
• The next few slides show some of the key challenges the current state presents:

KEY CHALLENGES

The volume of existing SoD conflicts increases fraud risk and inefficiency

ROOT CAUSE ISSUES

• Outdated role structure is a root cause for many SoD conflicts in the environment
• Periodic SoD reviews and mitigating controls programs require excessive amounts of time to resolve
• Lack of centralized mitigating control management means that duplication of effort occurs

5
Current State (cont.)

KEY CHALLENGES

Processes to request, approve, and provision user access are difficult and time consuming

ROOT CAUSE ISSUES

• If governance process maturity is low, additional business ownership is needed
• Current roles are complex and inefficient:
 Transactions are duplicated across roles
 The number of roles assigned approaches maximums allowed by SAP
• Current roles are not always aligned with tasks users perform in the system to complete job responsibilities, making
some business stakeholders unsure of what to request/approve while others rely on “tribal knowledge”

6
Current State (cont.)

KEY CHALLENGES

Current role structure inhibits SAP as a platform for growth

ROOT CAUSE ISSUES

• Loss of productivity resulting from the current role structure inhibiting the ability to serve business agility in
a systematic, process-driven way
• Misalignment between the current role structure and business processes increases security risk as new
users are added to SAP

7
How We Got Here

IT has historically assumed

ownership for SoD risk and
security roles rather than the
business Governance processes are not
The SAP environment has also
able to maintain a business-driven
changed significantly
security model

The business has evolved, While small security

including consolidation of key remediation projects have been
business processes, since the completed periodically, a
current role design was project to address root cause
implemented in 2007 issues has not been performed

Above are some of the key factors that contributed to the current state
8
SAP Security Remediation Approaches

Beam Suntory is currently following the “Bottom-Up” Approach

Source: www.protiviti.com/en-US/Documents/White-Papers/Risk-Solutions/Designing-SAP-Application-Security-Protiviti.pdf, slide #2

9
Framework Approach

3. Secure Leadership Support for

1. Assess Current State >> 2. Determine Options >> Desired Options

Understand key challenges and root

cause issues

PEOPLE PEOPLE PEOPLE

• Average employee’s level of understanding of roles • User Education • Make decisions on proposed actions
design • Roles and responsibilities
• Maturity of data or process owner’s risk ownership • Reorganization

PROCESS PROCESS PROCESS

• Roles-based provisioning • Streamline user provisioning process • Secure resources for implementing process
• SAP Roles Governance Process  For example, approvals changes
 Relationship to Business Process Governance  Workflow tools
• User provisioning process

TECHNOLOGY TECHNOLOGY TECHNOLOGY

• Complexity of role structure • Revise role design • Revise role design
• Enhance SoD/Access Control tools or technology • Automation
Prioritize significance of key challenges
and root cause issues

10
Framework Approach (cont.)
3. Secure Leadership Support for
1. Assess Current State 2. Determine Options
Desired Options

Understand key challenges and root cause issues

PEOPLE
• Average employee’s level of understanding of roles design
• Maturity of data or process owner’s risk ownership

PROCESS
• Roles-based provisioning
• SAP Roles Governance Process
 Relationship to Business Process Governance
• User provisioning process

TECHNOLOGY
• Complexity of role structure

Prioritize significance of key challenges and root cause issues

11
Framework Approach (cont.)
3. Secure Leadership Support for
1. Assess Current State 2. Determine Options
Desired Options

PEOPLE
• User Education
• Roles and responsibilities
• Reorganization

PROCESS
• Streamline user provisioning process
 For example, approvals
 Workflow tools

TECHNOLOGY
• Revise role design
• Enhance SoD/Access Control tools or technology

12
Framework Approach (cont.)
3. Secure Leadership Support for
1. Assess Current State 2. Determine Options
Desired Options

PEOPLE
• Make decisions on proposed actions

PROCESS

• Secure resources for implementing process changes

TECHNOLOGY
• Revise role design
• Automation

13
Decision Points — To Determine If SAP Roles Redesign
Is Right for You

SECURITY CHALLENGE

Symptoms experienced Options to resolve are

(header) discussed (Total SAP Roles Agree to Move YES Start building
Redesign, including Roles, Forward with business case and
Governance, and Roles Redesign plan
Provisioning Process)
a. No Role-Based Permissions
NO

Symptoms
Options to resolve are
b. Users can’t determine their continue
discussed (low level)
roles needed unresolved

c. Top-Down Complaints to
people doing user
provisioning (low level)

WORKER PEOPLE INVOLVED ORG LEADERS INVOLVED

14
Decision Points — To Determine If SAP Roles Redesign
Is Right for You (cont.)
The cycle continues until frustration with SAP end-user satisfaction and lack of
mitigating controls efficiency reaches executive awareness
Symptoms Experienced Results
• No Role-Based Permissions • SAP end-users satisfaction
• Users can’t determine their roles needed • Controls efficiency
and help desk or Business Process
Owners are overwhelmed
• Top-down/executive complaints to people
doing user provisioning

Options to Resolve are Implemented

• Small changes made
• Don’t address root cause
• Symptoms continue
• Maintain the status quo

15
Decision Points — When High Frustration Level/Executive
Awareness Is Reached

Agree to Move YES

Options to Resolve Discussed Build Business Case and
Forward with SAP
at Executive Level Implementation Plan
Roles Redesign

NO

Return to Symptoms
Experienced Cycle

16
Why Change Now?
Below is an overview of the objectives and expected outcomes of a role redesign project:

EXPECTED OUTCOME

Reduce fraud risk by eliminating role level SoD conflicts and reducing
user level SoD conflicts

KEY OBJECTIVE Increase productivity by reducing the time spent reviewing SoD
Align security roles with tasks conflicts
users perform in the system to
complete their job responsibilities
Increase productivity by reducing reliance on mitigating controls
(“Get Clean”)

Increase productivity by streamlining processes to request, review,

approve, and provision access and simplifying the role structure

17
Why Change Now? (cont.)
Below is an overview of the objectives and expected outcomes of a role redesign project: (cont.)

EXPECTED OUTCOME

Align ownership for managing SoD risk and related governance

processes with the business

KEY OBJECTIVE Improve control and decision making related to SAP access and
security with enhanced governance processes
Strengthen governance
processes
Increase productivity by reducing execution time for governance
(“Stay Clean”)
processes via automation (GRC)

Reduce SoX risk and effort with enhanced governance processes

18
Why Change Now? (cont.)
Below is an overview of the objectives and expected outcomes of a role redesign project: (cont.)

EXPECTED OUTCOME

Improve efficiency by reducing complexity in the security model

KEY OBJECTIVE
Improve time-to-market with changes to the SAP platform

Enable SAP as a platform for

achieving business objectives Improve scalability for future growth by streamlining roles and
governance processes

Improve IT performance against related service level agreements

19
Analysis of Options

OPTION PROS CONS

1. Maintain the • No additional cost • Known issues will not be addressed
Status Quo – • No risk of impacting other key initiatives • Security model will likely become
Address role • No organizational or technical changes to be required unsustainable
issues at a • No further reduction in fraud/SoX risk
later date or • Limits value achieved by SAP GRC
not at all

20
Analysis of Options (cont.)

OPTION PROS CONS

2. Remediate • Addresses high-priority SAP role issues • SoD violations and sensitive access issues
SAP Roles – • Demonstrates willingness to improve SAP security will continue to grow
Address high- controls • May have limited impact on the current state
risk issues and • May reduce complexity in SoD and access review • Requires time from business owners to
quick wins processes approve and test changes
• May reduce the likelihood of some SoX exceptions • Requires focused coordination with other
• Less expensive than Option 3 in the short run (although SAP, although impact is expected to be low
will have to be repeated every year or so) • Costs will be incurred with potentially less
• May be culturally more acceptable value achieved
• Limited reduction in fraud/SoX risk
• Limits value achieved by SoD tools such as
SAP GRC

21
Analysis of Options (cont.)

OPTION PROS CONS

3. Redesign • Reduces fraud risk by removing SoD conflicts and access • More expensive option initially
SAP Roles – issues from roles • Requires investment of business process
Perform a • Reduces the likelihood of SoX exceptions owner time to approve and test role design
comprehensive • Clarifies SoD and access review processes to help • Requires time from SAP team to approve and
role redesign ensure business approvers understand what they are test role design
approving • Requires focused coordination with other SAP
• Maximizes investments in Roles Governance tools, such initiatives, although impact is typically low
as SAP GRC Access Control, by cleaning up existing
SoD and access issues
• Enhances process capability maturity for SAP security
• Improves the efficiency of SAP security administration
and maintenance

22
What We’ll Cover

• Using a framework to help you determine if role redesign is appropriate for your
organization
• Identifying the key project considerations, establishing timelines, and securing executive
support
• Understanding the key project variables
• Establishing decision points for performing Access Control design and role design in a
phased approach (separately vs. together)
• Understanding success factors and next steps
• Wrap-up

23
Project Activities — Key Project Considerations

• FACTORS REQUIRED FOR PROJECT EXECUTION (SHORT-TERM) AND ONGOING COMPLIANCE (LONG-TERM) SUCCESS
 Examples:
 Obtain senior leadership support to secure resources and funding, align with corporate strategy to ensure long-term compliance
 Involvement of all stakeholders inside and outside IT

• TIMING
 Find times during the year when a critical number of stakeholders and participants have bandwidth

• CULTURAL CHALLENGES
 Slow implementation
 Break the project into pieces

24
Project Involvement — Key Business Activities

PARTICIPATION REQUIRED RESOURCES REQUIRED

1. Participate in Role Validation Workshops

• Key Business Process Users

Initial planning activities are being performed to analyze transaction
code usage and create draft role templates to be used as a starting • Key Site SMEs
point for discussion during:
• T-code Placement Workshops
• Controllers
 Validate task-based template roles
 Identify transaction to role mapping
• Org Value Workshops • IT Functional Team (2-3 Team Members)
 Validate org level values required in Security Roles

• IT Key Users (2-3 Team Members)

25
Project Involvement — Key Business Activities (cont.)

PARTICIPATION REQUIRED RESOURCES REQUIRED

2. Testing and Role Mapping of Redesigned Security Roles

• Functional Unit Testing • Business UAT/Role Mapping Coordinator

 In order to validate that the roles are technically functioning as
expected, key stakeholders will be required to participate in unit
testing efforts • IT UAT/Role Mapping Coordinator
• User Acceptance Testing
 In order to validate that the users will be able to perform their job
responsibilities using the new security roles, business users to
execute transactions from their day-to-day responsibilities • Business UAT Testers – Key End Users
• User Mapping
 Conduct mapping workshops to assign business roles to end
users • IT UAT Testers – Key End Users

26
What We’ll Cover

• Using a framework to help you determine if role redesign is appropriate for your
organization
• Identifying the key project considerations, establishing timelines, and securing executive
support
• Understanding the key project variables
• Establishing decision points for performing Access Control design and role design in a
phased approach (separately vs. together)
• Understanding success factors and next steps
• Wrap-up

27
Project Activities — Key Project Variables
TECHNICAL DETAILS
• Number and types of systems in
scope (ECC, BW, SCM, etc.)
• Current role definition details
(composite, parent/child)
• Compliance requirements
• Business requirements for SoD
violations (i.e., small offices,
decentralized processes)
• Use of Identity Management system
RESOURCE NEEDS
• Analyst level/workers
• Subject Matter Experts
• Business process owners
• Data owners (if different)
• Compliance function
• SoD administration function
• User provisioning function
• Internal Audit
CULTURAL CONSIDERATIONS
• Centralized vs. decentralized
functions
• Hierarchical vs. matrix organization
• Risk Appetite
• Speed of change tolerance
28
 Stakeholder Participation Requirements — Example
The table below summarizes typical resource commitments by phase for each primary stakeholder. Input
from the right stakeholders and the right time is critical to the success of the project.
IMPACT ON KEY STAKEHOLDERS
Phase Redesign Team SAP Security and Basis Team Bus. Process Owners/ Role Owners * Internal Audit PMO
Preparation High High Low Low Medium
Blueprinting High High High Medium Medium
Realization Medium High High Low Medium
Go-Live High High Medium Low Medium

* Participation from Business Process Owners and Role Owners would be in the form of input within role design review workshops, user acceptance testing, confirmation of user mappings, and any
necessary SoD resolution and mitigation decisions

LEVEL OF EFFORT EXPECTED COMMITMENT

High • Dedicated resources take responsibility for executing key tasks

• Attends design sessions to review and approve proposed role design

Medium • Performs user acceptance testing of new roles
• Provides oversight and guidance (third-party consultant)
Low • Is aware of key activities/status and completes limited tasks as needed

29
Access Control Reporting — Requirements
Below are some of the key factors that contributed to the success of the role redesign project

Aligning ownership Business-driven Enhancing Simplifying roles to

for SoD risk and project with resources governance reduce the time
security roles with dedicated to processes to ensure invested in
business process participate in new roles stay clean managing SoD risk
owners designing, testing,
and deploying new
roles

REDESIGN PROJECT
30
What We’ll Cover

• Using a framework to help you determine if role redesign is appropriate for your
organization
• Identifying the key project considerations, establishing timelines, and securing executive
support
• Understanding the key project variables
• Establishing decision points for performing Access Control design and role design in a
phased approach (separately vs. together)
• Understanding success factors and next steps
• Wrap-up

31
Decision Points Around Access Control Design

Should access control design or role re-design be done first?

SAP Access Control implementation methodology can be interpreted as recommending first to assess and fix issues to “Get Clean”

See next slide

32
Decision Points Around Access Control Design (cont.)
Minimal Time Continuous Access Effective
to Compliance Management Oversight and Audit
(Get Clean) (Stay Clean) (Stay in Control)

Risk Identification Enterprise Role Compliant User Super User Privilege Periodic Access
and Remediation Management Provisioning Management Review and Audit

Rapid, cost-effective, Enforce SoD Prevent SoD Close #1 audit issue Focus on remaining
and comprehensive compliance at violations at with temporary challenges during
initial clean up design time runtime emergency access recurring audits

Risk analysis, remediation, and prevention services

Cross-enterprise library of best practice Segregation of Duties rules

33
Decision Points Around Access Control Design (cont.)
SHOULD ACCESS CONTROL DESIGN OR ROLE RE- SHOULD ACCESS CONTROL DESIGN AND ROLE RE-
DESIGN BE DONE FIRST? DESIGN BE DONE TOGETHER OR SEPARATELY?

• In addition to SAP’s implementation methodology, the following • Business Needs

minimum items should be considered for helping to ensure  Compliance
success:
 Efficiency
 Business Needs
 Business requirements
 Timing when compliance achievement is required
 If “Get Clean” and “Stay Clean” are both requirements,
 Culture doing them together makes sense
• IT effectiveness
 Timing when compliance achievement is required
 Access control design and remediation may be quicker in the
short term
• Culture
 Appetite for change
 Degree to which status quo is acceptable

34
A Word About Compliance

• Speed to Required Compliance of SoD can be influenced by:

COMPLIANCE
 Going public

 Fraud incidents
 Internal mandate
• Each audit firm has their own methodology and toolkit for
SoD compliance
• The more your internal controls and compliance practices
are developed, usually the better the SoD result

35
What We’ll Cover

• Using a framework to help you determine if role redesign is appropriate for your
organization
• Identifying the key project considerations, establishing timelines, and securing executive
support
• Understanding the key project variables
• Establishing decision points for performing Access Control design and role design in a
phased approach (separately vs. together)
• Understanding success factors and next steps
• Wrap-up

36
Key Success Factors

Below are some of the key factors that contributed to the success of a role redesign project:

Aligning ownership for SoD risk and security roles with business process owners

Business-driven project with resources dedicated to participate in designing, testing, and deploying new roles

Enhancing governance processes to ensure new roles stay clean

Simplifying roles to reduce the time invested in managing SoD risk

37
What Questions to Ask Next?

Questions to Ask Next?

Where should the governance lead for this project reside?

What functions should be in scope?

What is the ideal timeline that meets business, compliance, and IT requirements?

How can we phase this project into smaller parts to match a pace that we can realistically achieve?

Are there other organizational activities that affect this project by competing for the same resources?

Do we have the right resources available for the success of this project?
Should there be any additional projects (e.g., Business Process Improvements) that should occur in addition to this
project?

38
What We’ll Cover

• Using a framework to help you determine if role redesign is appropriate for your
organization
• Identifying the key project considerations, establishing timelines, and securing executive
support
• Understanding the key project variables
• Establishing decision points for performing Access Control design and role design in a
phased approach (separately vs. together)
• Understanding success factors and next steps
• Wrap-up

39
Where to Find More Information

• “Designing SAP Application Security – Leveraging SAP Access Monitoring Solutions

During SAP Implementations, Upgrades or Security Redesign Projects” (Protiviti, 2014).
 www.protiviti.com/en-US/Documents/White-Papers/Risk-Solutions/Designing-SAP-
Application-Security-Protiviti.pdf
• Jonathan Levitt, “SAP Security Concepts, Segregation of Duties, Sensitive Access, &
Mitigating Controls” (PwC, March 2015).
 https://chapters.theiia.org/los-
angeles/Events/Documents/IIA%20%20Los%20Angeles%20%20SAP%20Security%20Pr
esentation%20.pdf
• The Segregation of Duties Concept on the SAP Help Portal
 https://help.sap.com/saphelp_grcac53/helpdata/en/17/76b1e9bb29435582eb8ef3366112
c6/content.htm

40
Where to Find More Information (cont.)

• SAP GRC Overview

 Paul Pessutti, “SAP GRC Overview” (SAP, 2006).

 www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/7021d9cc-1169-2a10-

da89-cdbb735bd5e7?QuickLink=index&overridelayout=true&19829864211026
 “Guide to the Sarbanes-Oxley Act: Managing Application Risks and Controls –
Frequently Asked Questions” (Protiviti, 2006).
 www.protiviti.com/en-US/Documents/Resource-Guides/ACE_FAQ_Guide.pdf

 Larry Carter, “Segregation of Duties and Sensitive Access: Leveraging System-

Enforced Controls” (Compliance Week, September 2014).
 www.complianceweek.com/sites/default/files/SoD-Sample.pdf

41
7 Key Points to Take Home

• If you are experiencing symptoms of frustration with SAP roles user provisioning,
consider that SAP Roles Redesign may be an option to resolve
• Business Risk Ownership and Support is critical for a successful SAP Roles Redesign
• Consider SoD tools such as SAP GRC Access Control for short-term compliance wins
when SAP Roles Redesign will be too labor intensive or time consuming
• Consider the key project variables to ensure a successful SAP Roles Redesign project
• Culture and appetite for change vs. status quo are important factors to overcome or use
to your advantage (depending on the case) – remember to consider
• Consider needs for performing Access Control and SAP Roles Design together or
separately
• Governance model of SAP Roles is a must for a successful SAP Roles Redesign project

42
Your Turn!

How to contact me:

Ivanka Gajecky
Email: Ivanka.Gajecky@beamsuntory.com
Phone: (847) 948-8888

Please remember to complete your session evaluation

43
Disclaimer
SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE (or an SAP affiliate company) in Germany and other
countries. All other product and service names mentioned are the trademarks of their respective companies. Wellesley Information Services is neither owned nor controlled by SAP SE.

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