Case Study: How Jabil Built Its Global

Governance Structure to Achieve Long-Term

SAP Access Control Success

Roberto Bayon
Jabil
Produced by Wellesley Information Services, LLC, publisher of SAPinsider. © 2016 Wellesley Information Services. All rights reserved.
In This Session

• This session walks you through the formation of Jabil’s global governance organization,
which was established to orchestrate its 15,000-user security redesign project and
oversee the company’s long-term SoD conflict minimization program. Hear how Jabil
successfully approached the standardization of SAP roles and the provisioning
processes used to achieve it, and explore how the company:
 Secured senior management support for its governance organization

 Selected its governance team and divided roles and responsibilities, including how it
defined technical and functional SAP GRC ownership for its SAP Access Control, and
SAP Access Violation Management systems and processes
 Manages user provisioning, business role management, SoD management, and
firefighter access
 Managed its multi-phase rollout

 Handles ruleset reviews and communication with external auditors

1
What We’ll Cover

• Background
• Overview of the SAP security redesign project
• Our governance structure
• Communication as part of a robust governance plan
• Governance as part of a multi-phase rollout
• Segregation of duties quantification
• Involving external auditors
• Revisiting the lessons learned by project work streams
• Wrap-up

2
Company Overview

3
Global Expertise and Intelligent Supply Chains, Engineered for
Growth

Automotive
Digital Home
Enterprise and Infrastructure
Industrial and Energy
Networking and Telecommunications
Printing
Point of Sale
Storage
4
Our SAP Environment

SAP Production Remediation Key

Active Users Complexity
System Option Considerations
Sensitive Data, SoD,
ECC 15,112 Redesign Now High
Role Architecture
Sensitive Data, Role
BW 2,335 Redesign Next Medium
Architecture
Importance

More Granular
GTS 152 Low
Access Needed
SOLMAN 118 Low Role Architecture

XI 45 Low --

SRM 5,306 Low --

SNC 7,166 Low --

5
Objectives

• Long-Term Objective
 To proactively manage SAP application access risk by implementing governance
processes, monitoring tools, and a sound security architecture
• Short-Term Objectives
 To reduce SoD conflicts

 To achieve and maintain an effective logical access environment

 To protect Jabil’s assets; No employee or group of employees should be in a position

to both perpetrate and conceal errors or fraud in the normal course of their duties

6
Challenges in the Current Environment

• Key challenges included:

 Lack of defined ownership and accountability when evaluating SAP access during the
user setup or modification processes
 Users with excessive access beyond the scope of their job responsibilities

 Users reviewing and approving their own access

 Access for terminated employees not being removed in a timely manner

 Lack of ownership and authority to maintain user access management process

7
SoD Risk Management Maturity

5 Monitoring of Actual Financial Exposures

for SoDs
End
Optimized Security
State
4 • Proactive SoD management and SoD-free Roles
• Security reflects responsibilities and organizational structure
RISK REDUCTION

Proactive Checks
3 • Custom ruleset and SoD access checks during provisioning
• Use of mitigating controls

Limited Analysis Starting

2 • Periodic SoD access checks with GRC tool
• Inadequate or incomplete SoD ruleset
State

Periodic Checks
1 • Manual SoD reviews (matrix-based)
• Reporting on false positives

TIME
8
Our Roadmap to Improving SAP Security

Short Term: Remediate and enable technology Long Term: Continuous monitoring and Governance

Upgrade Governance and

Update SoD Access Control Standardized
ruleset from 5.3 to 10.1 processes

Remediate Redesign SAP AVM

high-risk issues Security Implementation

9
How Did We Go from Stage 2 to Stage 5?
Projects
SAP Access Management • Create global SAP role governance process and security strategy with standards for global
Governance and Strategy role template, role-naming conventions, change control, and role provisioning

SAP ECC Security • Create new roles free of SoD conflicts and develop restrictions for custom transitions
• Establish mitigating controls for people who require role assignments that cause an SoD
Role Redesign conflict

Access Controls • Create an SAP automated user provisioning process with an automated SoD conflict check
(SAP GRC 10.1) utilizing a newly redesigned SoD ruleset with integrated mitigating control documentation

Access Violation • Implement continuous monitoring technology to detect and determine financial impact of
Management SoD violations

10
Project Organization Structure

Jabil Steering Committee

Proper representation CFO, COO, CIO, SVP Controller, SVP Finance CFO, SVP Operations,
VP Risk and Assurance, VP Global Operations, Senior Director IT
Steering Committee Jabil and Consulting Firm
Executive Lead

Jabil and Consulting Firm Audit

Project Lead Internal and
Identifying and involving all External
required resources

Communications Governance Lead Lean Team GRC Access Control Functional IT

Project Management
Leads

Financial Controls Regional

Site Resources Technical IT
Team Coordinators

11
What We’ll Cover

• Background
• Overview of the SAP security redesign project
• Our governance structure
• Communication as part of a robust governance plan
• Governance as part of a multi-phase rollout
• Segregation of duties quantification
• Involving external auditors
• Revisiting the lessons learned by project work streams
• Wrap-up

12
Enabling Governance with Task-Based Role Architecture
A tier approach will help ensure users get access in a structured way to minimize potential for risk and excessive
access, and to enable consistent governance processes:

Critical Access Tier 4: Critical Access (Critical Sensitivity): Activities performed via Firefighter,
Information Services, or restricted business functions.

Functional
Tier 3: Update Activity Access (Medium–High Sensitivity): Activities which allow
Access update access are grouped by sub-process area and divided into single roles based on
the activity performed. Restrictions to Organizational Elements (Company Codes,
Plants, etc.) can be performed here.

Company Restricted
Display Display Tier 2: Display Access (Low Sensitivity): Activities which allow display and reporting
only access. These activities may be grouped at the process or sub-process level. One
or more display roles can be given to a user and provide a display common to all.

User General
Tier 1: User General Access (No Sensitivity): Activities common to all users, such as
printing and inbox, are grouped together into a single role.
13
Project Timeline
FY 2015 FY 2016
Jan Feb March April May June July Aug Sept - Aug

SAP Access Management Governance and Strategy

SAP ECC Security Role Redesign – Pilot Global Rollout

Go-Lives

Transactional Analysis
Requires Significant
Workshops Participation from Pilot
Sites
SoD Remediation

Build and Technical Test

Pilot Plants:
• Penang Functional Testing and UAT
• JPG Wuxi
• Guadalajara User mapping
• Corporate IT
Go-Live and
Hypercare

Custom Transaction Development

GRC 10.1 Access Current GRC 5.3 environment Pilot User Provisioning Workflow
Control Implementation upgraded Go-Live GRC Global Rollout

14
What We’ll Cover

• Background
• Overview of the SAP security redesign project
• Our governance structure
• Communication as part of a robust governance plan
• Governance as part of a multi-phase rollout
• Segregation of duties quantification
• Involving external auditors
• Revisiting the lessons learned by project work streams
• Wrap-up

15
Key Governance Changes
• No formal process to manage SoD ruleset
• Monthly FF log review
• Manual process to provision FF accounts
• Manual process to remove users from SAP
• No process to monitor role changes
INFORMAL
TODAY
Lack of defined controls to mitigate key SAP security
risks within the Jabil environment
• Governance Committee will approve all SoD ruleset changes
• Investigating more frequent FF log review through GRC
• Auto-provisioning of FF accounts through GRC
• Integrate termination process through GRC to remove users from SAP
• Monitor role changes and transaction additions through GRC
CONTROLLED
TOMORROW
Defined governance controls to keep SAP security risks
from recurring
16
Governance Structure
Governance Lead (New)
• Cross-functional team consisting of Ops, IT, Finance, RAS,
and HR
Governance Committee (New)
• Governance Committee
• Provides guidance for the standards and IT Finance Operations HR Audit
requirements for key domains
• Gives authority to the governance team to administer
the program Governance Team
(*New*)
• Approves ruleset changes
• The Governance Team reports directly to the Governance Communication
Committee and provides updates about day-to-day
Governance activities
Regional / Divisional Controllers
• Information from the Governance Team is communicated
Site SMEs
to the user community and supported through the SMEs,
BPOs, Site Leads, and Security Team IT Security / GRC team

17
Introduction to Key Components of Governance

There are few key pillars when designing a governance model for
SAP access management. These pillars focus on key areas such as:

Strategic Vision/Alignment
• M&A/Compliance Alignment

Policies/Procedures/Training
• Approval Requirements
• User and Role Provisioning Requests
• Temporary Access

Risk Management
• SoD Ruleset Updates/Remediation/ITGCs

KPIs and Metrics

• SoD Violations/Firefighter Usage/Log Approvals/Provisioning SLAs

At this point, the majority of the processes have been initially designed
but these need to be agreed upon, communicated, and embedded into
the GRC tools, SAP security architecture, and overall organization
supporting this process long-term.
18
Governance Committee Responsibilities
Governance Committee provides guidance for the standards and requirements for processes to support:

User Provisioning Processes and Management

SAP access requests related to new employees and transferred employees,
including how SoD violations will be managed

SoD Management
Ongoing management and maintenance of the Jabil SoD ruleset

Role Management Governance

Defining ownership and management of role changes,
updates, and creation based on business needs and Lead/Team
architecture

Temporary Access Management

Defining how Firefighter accounts will be accessed, managed, and
reviewed

Change Management
Enforcing strong control of SAP GRC changes based on future business needs

19
Governance Responsibilities Across the Organization
Core Access Management (R) – Responsible (A) – Accountable
Governance Elements (C) – Consulted (I) – Informed

EM GC GL GT STS RQ AS
Governance: Policies and Procedures I C A R C C C/I
Governance: Training and Communication I C A R I/C I/C C/I

User Provisioning C C/R R R R A

Role Management C A R R I R

SoD Management C A R R R C/R

Elevated Temporary Access C A I C I R

GRC Tool Maintenance/Change Management C A C I I R

EM: Executive Management STS: Security Team

GC: Governance Committee RQ: Requestors
GL: Governance Lead AS: SAP ECC Security
GT: Governance Team
20
 Governance Around User Provisioning
D01 – New User Access Request (Future)

User’s Manager will

End
receive email
notification about
Requestor

Request Rejected (Email

Submits request in GRC request Create user and notify user
Start sent to Requestor via
(via link in ServiceNow) and requestor of access
GRC)

SoD Check Performed

Role Approver (Sensitive Role Approver,

in GRC No No
Functional Area SME, Site SME)

Evaluate Role Assignment

Approve Role
and Adjust Roles if Needed Request Modified? No Yes SoD Violation?
Assignment
(SoD or Incorrect Role)

Yes
Yes
SoD Check Performed
in GRC

Remediate
Yes and Adjust
Roles?
Governance Team

No

Reject Request (Email sent Can violation Associate a mitigating

End No Yes Approve request
to Requestor via GRC) be mitigated? control

21
Governance Around Firefighter

1 Review and limit who has FF access

2
Move T-codes out of FF to restricted/Sensitive roles and Firefighter
limit who gets those roles Reduction

3
Regular review of FF logs with escalation if not reviewed
within a specific time

22
What We’ll Cover

• Background
• Overview of the SAP security redesign project
• Our governance structure
• Communication as part of a robust governance plan
• Governance as part of a multi-phase rollout
• Segregation of duties quantification
• Involving external auditors
• Revisiting the lessons learned by project work streams
• Wrap-up

23
Communication of Project Plan

Governance Tasks
Define Security Governance Program
Ensuring all tasks are
Complete preparation work for program understood
Form Governance Committee
Develop Governance team and vision
Develop SAP provisioning processes Setting realistic dates
Develop New Employee, Contractor, Temporary Employee SAP Access Provisioning Process for each task
Develop Current Employee (new or change access) SAP Provisioning Process
Develop SAP User Removal Provisioning Process
Develop User Access Review Process
SoD Management
Ruleset Maintenance
Violation Remediation
Role Management – Ownership
Temporary Access Process
Temporary Firefighter access
Firefighter log reviews
Develop GRC Change Management process
Governance Pilot Rollout
24
Communicating Goals and KPIs (Example)
A significant component of governance includes the ability to communicate progress or potential delays. It is important
to define KPI to measure and communicate with your key audiences:
Area of Success Measures/KPIs Qualitative Factors
SoD Conflict-Free Roles • End of Project: 100% SoD conflict-free roles for all plants that are on SAP as of February
2015
• Pilot: 100% SoD conflict-free roles for Penang, Guadalajara, JGP Wuxi, and Corporate IT
Total SoD Conflicts • Total number of SoD conflicts are reduced by >90% • Mitigating controls will be utilized as it
• Total number of unique SoD risks are reduced by >80% makes sense and tracked by site
Ease of Maintenance • 98% of T-Codes are only in one role, making it easy to select roles • Master roles that are easy to maintain
and are based on tasks, not positions

Business Disruptions and • Go-Lives: There are minimal business disruptions and all critical items are resolved within • Testing: All critical issues remediated
Testing 1 hour before go-live
• Testing: The number of issues that arise is <15% • Ongoing: Firefighter roles used
appropriately as a mitigating process
Governance Processes • Automated SoD checks administered by GRC tool utilizing improved ruleset • Maintain SoD conflict-free roles
(“Stay Clean”) • Defined and implemented processes with policies and procedures that include an through governance strategy
escalation path • Centralized role maintenance
• Documented and tested mitigating controls when applicable for agreed upon SoD Conflicts
• Access is granted within 5 to 7 days
25
 Communicating Changes to Governance Policies (Example)
The table below shows the total risks monitored per business cycle across multiple rulesets, companies need to define
what is important to measure and communicate:
Business Cycle Jabil’s Previous Ruleset Leading Practice Ruleset Jabil’s Customized Ruleset

Finance 4 9 19
Materials Management 0 7 4
Order to Cash 46 29 44
Procure to Pay 63 28 51
HR/Payroll 0 14 7
IT (Basis) 6 5 6

Governance process around ruleset:

• Reviewed on annual basis and when new transactions are introduced to the system
• Obtain feedback from the business
• Proposed changes are reviewed by the Governance Team
• Sent rule changes to auditors with specific reason why actions were taken
*Risks will be included in Jabil Customized Ruleset
26
Communicating Project Goals and Achievements (Example)

Pilot – Segregation of Duties Risk Reduction

SoD Risk Pre-Go-Live Post-Go-Live
Analysis (4,000 Users) (4,000 Users) Reduction Visual Representation of Statistic

SoD Risk #1 SoD Risk #1

Unique User
237,988 15,938 93% SoD Risk #2 SoD Risk #2
Risk Exposure
SoD Risk #3 SoD Risk #3
3 Risks 1 Risk

Users with
3,486 420 88%
SoD Risks

6 Users 1 User

27
What We’ll Cover

• Background
• Overview of the SAP security redesign project
• Our governance structure
• Communication as part of a robust governance plan
• Governance as part of a multi-phase rollout
• Segregation of duties quantification
• Involving external auditors
• Revisiting the lessons learned by project work streams
• Wrap-up

28
Timeline
SAP Redesign

Complete Security Assessment
Project Kick-off Meeting
Participate in Workshops
User Mapping
Role Design for Pilot Sites Role Migration
Role Build for Pilot Sites Pilot Sites Go-Live
Functional Testing (Unit and UAT) Hyper-care Support
Apply Lessons Learned to Global Rollout

PREPARATION ENABLEMENT SUSTAIN

Process Design Ongoing Oversight
Determine Governance Objectives
Gap Assessment and Decisions Governance Objectives
Develop Project Plan
Process Improvement
Governance

Identify Governance Team P&P Development

Validation (where needed)
Evaluate Current State
Training

Key Milestone PREPARATION ENABLEMENT SUSTAIN

JANUARY – APRIL ’15 MAY – JULY ’15 AUGUST ’15 AND BEYOND

29
What We’ll Cover

• Background
• Overview of the SAP security redesign project
• Our governance structure
• Communication as part of a robust governance plan
• Governance as part of a multi-phase rollout
• Segregation of duties quantification
• Involving external auditors
• Revisiting the lessons learned by project work streams
• Wrap-up

30
SoD Quantification to Manage Residual Risk

SAP Access Control

SAP Access
• SoD Management
• • Automated Provisioning
Define
SoD Risks
• Emergency Access Management
Users with
SoD
Violations
SoD Quantification
Real Exceptions • Executed SoD transactions and
• quantification of real violations
Define

AVM was implemented to assist in the ongoing monitoring and governance of our SAP Environment:
31
Access Violation Management (AVM) Implementation
Our AVM implementation phases include:
Current State
• Current methods quantify 42
of the 90 Segregation of
Duties (SoD) risks that are
quantifiable.
• Methods rely on both
automated and manual
methods.
Short-Term Phase 1 – Aug.
• Achieve additional automated
SoD risk coverage and
efficiency in conjunction with
current quantification
methods.
• As well as continuing current
quantification tests.
Long-Term Phase 2 and 3
• Replace current test with AVM
tests.
• Analyze what SoD risks will
remain after the role redesign
and configure additional
automated quantification
tests.
32
 SoD Quantification Approach

1)
1 Identify number of users with authorization access to high SoD risk (Jabil defined ruleset)
2)
2 Determine if users have executed transactions from both sides of the SoD (each function)
3)
3 Quantify identified high-risk SoD violations (e.g., users who have edited the vendor master record and created or changed a purchase order to that same vendor)
a. Use third-party tool to extract transactional tables and analyze SoD occurrences (impact)
b. Manually analyze remaining SoDs with transactional occurrence identified in Step 2 should no compensating controls exist
4
4) Determine if violations that have been quantified are material
5
5) If yes, determine if compensating controls exist and they are operating effectively
6)
6 If no compensating control exists, investigate and evaluate further with applicable business owners

4 5 6
1 2 3

Mitigating Control CD01: All changes to the vendor master records are reviewed including creating vendors
33
Benefits of Access Violation Management
Before
• Put monitoring in place while planning
and executing on:
 Access Control Implementation
 Role Redesign
 Risk Identification, including definition
of the technical ruleset
• Prioritize activities by financial risk
exposure
During
• Extend risk monitoring for additional user
risks identified during the implementation
that cannot be removed
• Identifying areas of focus for role
redesign – across all relevant business
applications
• Prioritize activities by financial risk
exposure
After
• Automate mitigating controls with 100%
transaction monitoring and exception-
based reporting
• Enable business ownership of access
risks with clear, relevant reporting
• Increase transparency into real risk to the
business
• Drive process change when financial
exposure is too high
34
Access Violation Management (Example)
Potential SoD Exposure by Country Potential SoD Exposure by User/Company Code

XXX
San Jose
US SAMPLE
$9,066,289
9,470
5

35
What We’ll Cover

• Background
• Overview of the SAP security redesign project
• Our governance structure
• Communication as part of a robust governance plan
• Governance as part of a multi-phase rollout
• Segregation of duties quantification
• Involving external auditors
• Revisiting the lessons learned by project work streams
• Wrap-up

36
Involving External Auditors

• Communication is key. External auditors need to know the plan, understand the
remediation methodologies, and be given constant updates.
• Changing policies and procedures, requires documented business reasons
• Received buy-in on the new tools like AVM so auditors could place reliance on them
 Demonstrated completeness and accuracy for all tools

• Provided regular progress reports both formal and informal so the auditors were
comfortable that the overall project was on track
 This not only eased the minds of the auditors that we were resolving our deficiencies
but also allowed the auditors to better plan their annual audit around key areas of risk

37
What We’ll Cover

• Background
• Overview of the SAP security redesign project
• Our governance structure
• Communication as part of a robust governance plan
• Governance as part of a multi-phase rollout
• Segregation of duties quantification
• Involving external auditors
• Revisiting the lessons learned by project work streams
• Wrap-up

38
Lessons Learned: Governance

Difficulty getting all parts of organization to agree

Difficulty finding qualified person to be the Governance Lead

Training of team members who have other current responsibilities

Change in ownership from IT to the Governance Lead

Need to start early as establishing formal governance process is time-consuming

Communication progress to the Audit during key parts of the project

When creating an SoD Ruleset it is good to be conservative to start but be open to removing
risks throughout the project

39
Lessons Learned: Communication Is Key

Training Video Communication Example

40
What We’ll Cover

• Background
• Overview of the SAP security redesign project
• Our governance structure
• Communication as part of a robust governance plan
• Governance as part of a multi-phase rollout
• Segregation of duties quantification
• Involving external auditors
• Revisiting the lessons learned by project work streams
• Wrap-up

41
Where to Find More Information

• www.protiviti.com/en-US/Documents/White-Papers/Risk-Solutions/SAP-Access-Mgmt-
Governance-Getting-It-Right-Protiviti.pdf
 SAP Access Management Governance: Getting It Right, Making It Sustainable” (Protiviti, 2013).
 This white paper outlines a strategy to improve SAP access management efficiently and

establish a structure for governance that standardizes the management process and helps
minimize access control risks for the long term
• www.protiviti.com/en-US/Documents/White-Papers/Risk-Solutions/Designing-SAP-Application-
Security-Protiviti.pdf
 Designing SAP Application Security – Leveraging SAP Access Monitoring Solutions During
SAP Implementations, Upgrades or Security Redesign Projects” (Protiviti, 2014).
 This white paper provides six steps organizations should take when implementing SAP

application security using a top-down approach

• http://help.sap.com
 Follow Financial Management  SAP Access Control  SAP Access Control – SAP Best
Practices
42
7 Key Points to Take Home

• Without governance, any redesign will eventually revert back to unmanaged roles and
user provisioning
• Tools such as Access Control and Access Violation Management help achieve
governance Objectives
• Representation from executive leadership to ensure the right messaging is heard and
communicated to the broader organization
• Governance is the responsibility of a cross-function team (e.g., Finance, IT, Ops, HR …)
• Establish KPIs and use to drive changes or standards
• Ensure you get buy-in from external auditors by keeping them up to date of your progress
and intentions
• Identifying the right consulting partner to help bring leading practice and implement
changes
43
Your Turn!

How to contact me:

Roberto Bayon
roberto_bayon@jabil.com

Please remember to complete your session evaluation

44
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.

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