Enterprise SAP GRC Compliance and Security Training

SAP Governance, Risk and Compliance (GRC)
Compliance and Security Training
July 2016
v2.0
Objectives and key goals
Provide foundational knowledge of SAP GRC
Tool
Explain the actions required from compliance

managers to support access management
controls in SAP GRC
Walkthrough SoD, SA reports
Mitigating control creation and assignment
Periodic review process, role and

responsibilities.
At the end of this training, each compliance manager should have the
necessary information to use SAP GRC to support access management
processes
| SAP GRC Compliance Manager - Introduction and Training (Module 1 of 4) Confidential | 2
Agenda and schedule
Welcome and introductions 30 minutes

Overview of SAP GRC 30 minutes
Segregation of Duties in SAP GRC 1 hour
Break 15 minutes
Access Request Approvals 1 hour
Lunch 1 hour
Periodic Monitoring Reports 1 hour
Q&A 30 minutes
TOTAL 5hrs 45 mins

Agenda and schedule

Break 15 minutes
Lunch 1 hour
Q&A 30 minutes
TOTAL 5hrs 45 mins

What is SAP GRC?
SAP GRC is an access management solution that enables organizations to effectively
manage SAP user access requests, segregation of duties/sensitive access
requirements and emergency access. SAP GRC has four key components that work in
tandem to achieve this purpose:
SAP GRC 10 Access Control Components

Access Risk Emergency Access Request Business Role
Analysis (ARA) Access Management Management
Management (ARM) (BRM)
(EAM)
Enables periodic
access reviews and Enables user Enables role
facilitates risk Enables detailed access requests to maintenance and
mitigation monitoring of SAP applications role review
Firefighter workflows
activities
Segregation of Duties
Segregation (SOD)
of Duties andand Sensitive
Sensitive Access
Access RuleRule
SetsSets
Provides visibility to access violations

The four components of SAP GRC enable various activities
pertaining to access management
Access request management Access risk analysis

Primary focus of
Segregation of Remediation /
Duties / Sensitive Mitigation of
New User Modify Access Reviews Access
Request Existing Terminate Violations
this group
Access Existing
Access
Global SOX and User Access
Access Approval GxP Rule Set Reviews
Lock / Unlock
User Design (Role User
Maintenance Assignments)
Preventative SoD Check
Business role management Emergency access management

(Will discuss at high level)
Disable Role
I/T Focused
Create New Modify

Role Existing Role Emergency Emergency
Access Access
Request and Monitoring
Recertify Provisioning and Review
Role Approval Role

Compliance manager training course
The following topics will be included in the Compliance Manager training:
GRC Overview Module 1
Segregation of duties - Module 2
Approving user access Module 3

Overview of SAP
GRC Rule Set Periodic Reviews Module
Approving access 4
Mitigating Controls in requests
Types of reports to be
SAP GRC reviewed using SAP
Assigning Mitigating
Controls GRC
Approver delegation Remediation Options
Adhoc reporting
Systems in Scope

Overview of SAP
Approving access 4
Controls GRC
Adhoc reporting
What we have completed as part of this
project

Overview of SAP
Approving access 4
Controls GRC
Adhoc reporting
Module objectives and key goals
Provide an overview of SAP GRC Rule Set and its

different components
Explain the design of the J&J GRC Rule Set
Explain an Access Risk and how to

address/remediate
Explain a Mitigating Control and how to create one in

the system
At the end of this training, each compliance manager should be able to

understand the different components of Rule Sets, Access Risks, Mitigating
Controls and the relations between them.

Agenda and schedule

Break 15 minutes
Lunch 1 hour
Q&A 30 minutes
TOTAL 5hrs 45 mins

Overview of SAP GRC Rule Set

Rule Set Components
The below diagram displays the different elements of Rule set.
Business Scenario: An individual having access to maintain purchase orders and
manage goods receipts can lead to fictitious and fraudulent invoices
Rule Set
Maintain Purchase Order

Access Risk
Vs Manage Goods Receipt
Functions Maintain Purchase Order Manage Goods Receipt
Actions ME21N Create ME22N Change MIGO Goods MB01 Post Goods
(SAP Transaction Purchase Order Purchase Order Movement Receipt on PO
Codes)
Permissions Create PO for Create PO for Create GR for Create GR for

(SAP Authorization Company Code Purchasing Area Company Code Purchasing Area
Objects)
Organizational Create PO for Create GR for

Rule Company Code Company Code
(SAP Org Level Field 1000 1000
Values)
Access Risk
Risks are created when individuals have access to one or more functions that
would allow them to perform an activity which may lead to financial
misstatements or operational inaccuracies.
To limit risk exposure to the organization, users with such access should be
limited as much as possible and monitored in a system.
There are two types of Access Risks
Segregation of Duties (SOD)
Two or more conflicting system access and/or Manage Process
Goods Payments
manual responsibilities should be segregated Receipt
when it places a user in a position of being able
What is the Risk?
to handle a responsibility inappropriately without May result in fictitious and fraudulent
others knowing. invoices
Sensitive Access (SA)

Certain activities in a system are sensitive Maintain
Customer
because they allow access to confidential Master Data
information What is the Risk?
If used inappropriately, would cause a Inappropriate access to sensitive
data
significant adverse impact financially or
operationally.
SAP GRC Rule Set: Recap
The rule set has a Functional and Technical components
Risks are created when individuals have access to perform an

activity which may lead to financial misstatements or operational
inaccuracies.
There are two types of Risks: Segregation of Duties (SOD) and
Sensitive Access
Each Risk contains one or more functions.
Each Function contains Actions and Permissions
Functions defined at Permission level ensures more accurate results
when generating the Access Risks Analyses
Organizational rules allow you to report on users that have

access to a specific organization in SAP. It is currently set-up for
only the Sensitive Access rule set

Overview of J&J Rule Set

J&J Rule Sets
There are four different rule sets defined for J&J to address global segregation
of duties and sensitive access that collectively create the Global rule set.
Other rule sets are a subset of the Global rule set and leverage the same
content.
Global Primary
Global SoD access risks will be evaluated during user provisioning.
SoD Risks This rule set will also be used for the periodic SoD review.
Global Global Sensitive access risks are not evaluated during user provisioning.
Sensitive Access This rule set will be used for the periodic sensitive access review only.
SoX Risks Subset of the global SoD and Sensitive Access rule sets which contains
only SOX relevant risks. This rule set can be used for ad hoc reporting.
Subset of the global SoD and Sensitive Access rule sets which contains only
GxP Risks risks GXP relevant risks. This rule set can be used for ad hoc
reporting.

Global vs. Local

The J&J rule sets contain global and local elements.
Platform Components of the rule set

All SOD risks must be global. Any additional SoD risk that is identified
must be evaluated for inclusion in the global rule set.
All standard SAP transaction codes and objects within SoD risks must
Global be global.
The transactions listed in functions include all transactions that can be
used to execute a conflicting or sensitive function, whether assigned,
in-use or not used.
Custom sensitive access activities used by a platform or organization

Local Custom transaction codes defined for a specific platform
Custom objects defined for a specific platform
When user executes a risk analysis report, the global components will automatically
be combined with the applicable local components.

Example of Global vs. Local Elements in J&J Rule Set:
Global Sensitive Access Rule Set
Post Journal Entries
F-01
Global Enter Sample Document
Elements F-02
Global Enter G/L Account Posting
permissions are
included with ABAD_OLD
the Standard Asset Retire from Sale w/
Tcodes Customer
ZFIR35
Custom Tcode
Local ZFIE14
Elements Custom Tcode
Local
permissions are ZFIR36
included with Custom Tcode
the Custom
Tcodes 19
Risk Levels
The following risk levels are defined in the J&J rule sets:
Low Medium High Critical

Risks which would Moderate risks that Risks which have Restricted to
have a limited would result in a significant impact to Sensitive Access
impact to financial, control weakness. financial, risks
operational, or operational, or
compliance. These risks still compliance. Differentiates
have an operational between SOD and
Can be mitigated impact and require These risks cannot Sensitive Access
using general / high at least a specific be pre-mitigated at risks in the system.
level monitoring mitigating control. the role level.
controls or accepted
and monitored

Navigating the J&J Rule Set
Navigating the Rule Set in GRC

Rule Sets, Functions and Access Risks can be viewed under Setup tab
in GRC.

Rule Sets
The four rule sets defined for J&J can be found within the Rule Sets link
on the Setup tab.
1 2
1
Rule Set ID: The identification
code for the rule set.
2
Description: A short
description of the rule set.

Functions
The functions defined within the J&J rule sets can be found within the
Functions link on the Setup tab.
To display additional detail about
the Function, highlight the
desired line item and click Open.
1 2 3
Function ID: The identification code for

1
the function.
Description: A short, plain text

2 The actions (Tcodes) associated with the
description of the function that identifies functions are present in the Actions tab of
the nature of the function. function definition. The permissions
3
Business Process: The Business (authorizations objects) associated with those
Process of the Function actions will be in the Permissions tab.

Access Risks
The access risks defined within the J&J rule sets can be found within the
Access Risks link on the Setup tab.
To display additional detail about
the risk, highlight the desired line
item and click Open. Refer to the
next slide for examples.
1 2 3 4 5 6
1 Access Risk ID: The identification code of the risk

2 Description: A short, plain text description of the risk and its purpose.
3 Risk Level: The severity of the risk. Risk Levels include Low, Medium, High and
Critical.
4 Risk Type: The nature of the risk. Risk types include SoD risk, Critical Action risk or
Critical Permission risk.
5 Function ID: The identification code of the function that is contained within the
risk.
6 Business Process: The business process of the risk.

Access Risk Details
Functions Tab: The conflicting functions that constitute the risk will be present
here.
Rule Sets Tab: The rule set with which the risk is associated will be present in
this tab.
Risk Owners Tab: The individual(s) who have oversight responsibility and final
approval authority for any steps taken to update the risk will be listed in this tab.

J&J Rule Set Naming Standards
Naming Standards
Access Risks and Functions follow a global naming standard as described
below.
Name of
the field Length Explanation Example
item
<Business Process(2)><Sequence(2/3)>
Business Process: 2 characters denoting the Business Process for AR01 Process GL
SOD Risk
4/5 example, AR for Account to Report Master File Changes
ID
Sequence: 2/3 characters to denote the numeric sequence, as example,
01, 02, 121 etc.
Sensitive Naming standard is same as SOD Risk ID, only difference is Sensitive SACO03 Sensitive
6/7 Access Risk ID will always have a prefix of the text SA at the beginning. Access for Maintain
Access
Risk ID Cost Center
<Designation(1)><Domain(1)><Business Process(2)><Sequence(2)>
Designation: 1 character refers to the platform, for example J for Global,
B for Back to Basics
Domain: 1 character refers to the domain, for example S for Supply JFAR01 Maintain A/R
Function 6 Chain, F for Finance Payment Run
Business Process: 2 characters denoting the Business Process, for
example AR for Account to Report
Sequence: 2 characters to denote the numeric sequence, as example, 01,
02 etc.

Rule Set Changes
Why are Rule Set changes necessary?
Business process or compliance requirements have changed
A custom transaction code or authorization object has been created/modified

in the system.
An access risk report is showing incorrect results (potentially due to wrong

rule set definition)
J&J Rule Set Change Process
J&J GRC Center of Excellence (CoE) is responsible for the rule set
maintenance, and will be performed at scheduled times throughout the year. As
the Compliance Manager, you are responsible for the following activities in the
rule set change process:
Identify the need for a rule set change
Complete the rule set change request form
Send the change request form to GRC CoE Team
J&J Rule Set: Recap
There are four different rule sets defined for J&J to address global
SOD and sensitive access for SOX, GXP, and operational risks
Each rule set contains global and local elements
Risk ranking criteria is used to differentiate between SOD and Sensitive

Access risks
High risks cannot be premeditated at the role level
Low level risks can be accepted and monitored
Access Risks and Function IDs follow a naming convention to quickly
identify the relevant Business Process
Compliance manager is responsible to identify the need for a change

in J&J Rule Set and initiate the change process.

Addressing Risks

Identify Risks using the J&J Rule Sets
The J&J rule sets are used to identify risks in two different ways.
Preventative: The rule sets are used to identify new risks when a
new/change user access request is submitted.
Displays SOD risks which will occur from the access requested
Organization is required to take appropriate action prior to
approving the request
Detective: Rule Set is used to run risk analysis reports on users and
roles to review open SOD risks or sensitive access
Risk Analysis reports are run periodically or on an ad-hoc basis
Organization is required to take necessary actions to address the
open access risks Current Scope

Addressing Risks
Addressing Risks
Unmitigated Access Risks increase the chance of errors and irregularities in the
system. There should not be any unmitigated access risks in Production system.
There are 2 ways to address Access Risks.
Eliminate the Risk: The risk can be completely eliminated from the system
by removing roles from the user, altering the authorizations of the role, or
changing the rule set.
Mitigate the Risk: The organization can accept the risk and assign a control
to mitigate the risk at the role or user level.
J&J methodology for addressing risks:

As a primary option, the risk should be eliminated where possible.
However due to organizational restrictions, not all the risks can be
eliminated from the system. In these situations, mitigating or
compensating controls need to be created and assigned to users.

Mitigating Control
Global vs Local Mitigating Controls
Mitigating Controls are built at two levels in J&J:

Platform Components of the rule set
Controls are mapped to the J&J Parent Organization and assigned to Access
Risks which commonly occur across the organizations
Global Controls can only be used as reference templates which can be adopted by
local organizations. Local ownership is required.
The GRC CoE is responsible for maintaining the global mitigating controls.
Local Controls may include system generated reports or manual procedures

which cater to local regulations/compliance and control requirements.
A local control may exist in conjunction with a global control for the same
Local
Access Risk.
The LE/Regional Compliance team is responsible for maintaining, assignment
and monitoring of local controls.

Mitigating Control
SAP GRC does not make a distinction between compensating and mitigating
controls. Therefore, Mitigating Control is intended to refer to both.
Mitigating Control ID naming standards
The Mitigating Control ID is used to identify the organization and business

process the control is related to. If the ID is not defined correctly, it will be very
difficult to assign the control. The format for the Mitigating Control ID in J&J is as
following:
< Organization Number> <Process Area> <Numeric Sequence> <Identifiers>
Organization Number: 4 digits representing the Organization Unit (Management Reporting
Company / MRC)
Process Area: 2 characters denoting the process area, e.g. IT for Information Technology
Numeric Sequence: 4 digits numeric sequence, e.g. 0001, 0002 etc.
Identifier for local/global control: L for Local and G for Global
Identifier for Manual/Configuration control: M for Manual and C for Configuration
Example
A global and manual mitigating control for organization MRC 4160 and Process Area
Account to Report has the Mitigating Control ID 4160AR0001GM.
If there are multiple Mitigating Control IDs for the same organization and process area,
the Mitigating Control IDs would be 4160AR0002GM, 4160AR0003LC etc.
Addressing Risks: Recap
There should not be any unmitigated access risks in Production

system. There are 2 ways to address Access Risks.
Eliminate the Risk
Mitigate the Risk
Mitigating Controls are built at a Global and Local level in J&J
Mitigating Controls follow a naming convention to quickly identify the

relevant Organization and process area.

Creating, Approving and
Reviewing Mitigating Controls

Mitigating Control: Key Attributes (1 of
2)
When defining a mitigating control, there are key attributes that must be
included. These attributes allow for the control to be searched easily
and assigned to an appropriate conflict
1
Mitigating Control ID: Unique ID of a
specific mitigating control.
1
2 Organization: Organization Unit
(MRC) to which the control belongs.
3
Process/Sub-Process: Business
2
Process and Sub group of the process
3 which is tied to the control activity.
4 Notes: This is a free text box where
the actual control steps should be
documented.
5
4 Access Risks: This is the Risk ID(s)
which is mitigated by the control.

Mitigating Control: Key Attributes (2 of
2)
Control Owner (Approver): The person responsible for executing the actual control
6
steps (if manual) to make sure the control is performed. The Control Owner is also
responsible for reviewing the periodic mitigating control reports to confirm
appropriate assignment of controls to Roles and Users.
Control Monitor: The person responsible for executing the actual control steps (if
7
manual) to make sure the control is performed. If the control monitor determines that
the control is no longer operating effectively, action must be taken to find an
alternative control.

DCM to Mitigating Control Mapping
Each Mitigating Control in GRC will map to a control listed in the
DCM
DCM controls matrix 3 1
2
2
GRC Mitigating Controls

Process Workflow: Mitigating Control Creation
The request to create new mitigation control will require approval from
the control owner. If the request is approved, the mitigating control is
available in the system.
If a new Mitigation Control request is rejected, the Compliance
Manager has to find a different Mitigating Control to address the risk or
remediate by removing access from the user.
Request
Rejec
Closed
t
No
Compliance GRC triggers

Manager an approval Mitigating
Approve
submits new workflow to Control
creation?
Mitigation the Control Owner
Control Owner
request
Ye Mitigation
s Control ID
Appro gets
ve created in
GRC

Screen Navigation: Mitigating Control
Creation
Mitigating Control Creation
A new Mitigation Control can be created or existing Mitigating Controls
can be modified through the Mitigation Controls link under Setup tab
in GRC.

Screen Navigation: Mitigating Control Creation
The General tab contains information related to the control name and
organizational alignment.
Key points about General tab
Follow the naming standards for

Mitigating Control ID.
Organization (MRC) can only be

selected from the available list.
The correct Process and Subprocess

can be selected from the drop down list.
The control steps should be

documented under Note section. If the
mitigating control is already defined in
the organizations Document Control
Matrix (DCM), the DCM reference
should be included in this section.

Screen Navigation: Mitigating Control Creation
The Access Risks tab contains the risks that are mitigated through this
control. The Owners tabs lists the owners of the control.
Key points about Access Risks tab
Add one or more Rows to assign

the Risk ID(s) which will get
mitigated by the control.
The Rule ID field should always
have value *.
Key points about Owners tab
A Control Approver and Control Monitor are required for each control
The same user could be defined as Approver and Monitor

Mitigating Control Creation- Recap
Creation of a new mitigation control requires approval from the

control owner
An Approver and Monitor are required for each control; this can be
the same individual
Controls can have multiple Monitors
If a mitigating control is already defined in the organizations

Document Control Matrix (DCM), the DCM reference should be
included in the notes section.

Creation Approval
Each mitigating control is assigned an Approver when it is defined. This Approver is
responsible for approving any changes to the control as well as assignment to roles
and users.
A single compliance manager may submit and approve a mitigating control

creation, if they are the appropriate Owner for the selected organization.
Once the mitigating control is submitted for creation, SAP GRC will automatically route
it to the Approvers Work Inbox for review and approval. An email notification will also
be sent.

Approval Creation
Validate the data on the General tab.
Key Points:
Validate that the control ID has been assigned following the proper naming convention.
Refer to slide 28 for mitigating control ID naming standards.
Determine if there are any existing mitigating controls in the SAP GRC mitigating controls
library which are similar or duplicative to the control requested to be created.
Validate if the control is applicable to the organization and meets

audit/regulatory/compliance requirement
Approval Creation
Validate the data on the Access Risks and Owners tabs.
Key points about Access Risks tab
Review for risk IDs defined to

confirm the control properly
mitigates the risk.
Key points about Owners tab
Review the Approver and Owners for appropriateness.

Confirm the mitigating control monitor responsible for executing the control is not in
violation of the risk IDs being addressed.
Approval Creation
Approve the Mitigating Control Creation or update
Key Points:
Based on the review of the control, the mitigating control owner will either approve or reject
the creation of the control.
It is mandatory to add comments in the Notes section prior to approval or rejection.

Mitigating Control Approval - Recap
Validate proper naming convention of Control ID.
Look for similar controls that already exist in the SAP GRC controls
library or duplicative to the control requested to be created.
Validate if the control is applicable to your organization
Confirm if the control meets audit/regulatory/compliance

requirement.
Review for risk IDs defined to confirm they are properly mitigated by
the control
Confirm the mitigating control monitor responsible for executing the
control is not in violation of the risk IDs being addressed.

Periodic Review of Mitigating Controls
It is the responsibility of the local compliance organizations to perform

periodic review of the mitigating control library defined in GRC.
Each time a control for an organization is reviewed in the Document

Control Matrix (or a similar document), the corresponding control in
the SAP GRC system should also be checked.
This will occur in line with each organizations policies and

procedures for control definition.
In case of any change required in mitigating control definition,

change of owners/monitors or change in frequency of reports, the
Mitigating Control create/change workflow process should be
followed.

Other Actions:
Approver Delegation

Approver Delegation : Screen Navigation
For times when you will be unable to approve access requests (i.e. out on
holiday), SAP GRC gives you the option of forwarding your approvals to
someone else.
The delegation screen can be found in the My Home section of SAP GRC.
The next slide provides an overview on delegating your approval authority.

Approver Delegation : Screen Navigation
Approver Delegation
This screen lists the delegated approver IDs and the validity period for
which those approvers will be active.
Click Delegate to create
a new Approver
Delegation
Key points about Approver Delegation
Access should only be delegated to someone at

the manager level and above, also having same
approval accesses.
Entering the validity dates is mandatory and will

be monitored by I/T.
Access should be delegated for a specific period

of time and must not exceed 30 days.

Objectives and key Goals
Review Compliance Manager
activities as it relates to periodic
review
Discuss the remediation options

and report approval and sign-off
Explain how to generate ad hoc

reports
At the end of this training, each Compliance Manager should be

able to understand the importance of the periodic review.
The Compliance Manager should understand how to extract and

review reports, select the correct remediation option for open
violations, and approve the reports.

Agenda and schedule

Break 15 minutes
Lunch 1 hour
Q&A 30 minutes
TOTAL 5hrs 45 mins

SoD /SA Reporting

Ad Hoc Reporting Overview
Why do we need Ad-hoc Reporting?
Ad-hoc reporting facilitates the review of SOD and sensitive access for the
user population.
Compliance managers can run risk analysis reports using their own filters and
save the report outputs.
What are the Ad-hoc Reports available to run?

Compliance Managers can run different ad-hoc reports from Access
Management tab of the GRC page.
Report Name Report Output

SOD Access Risks, Sensitive Access Risks and Mitigation
User Level Risk Analysis
Controls at User level
Role Level Risk Analysis SOD Access Risks and Mitigation Controls at Role level
User Level Simulation Risk Simulates the impact of access changes on SOD and
Analysis Sensitive Access Risks at the User level.
Role level Simulation Risk Simulates the impact of changes on SOD and Sensitive
Analysis Access Risks at the Role level.

Access Risk Analysis: User and Role
Access Risk Analysis
The Access Risk Analysis report provides a listing of conflicts at user or role level.
Input the desired search criteria using the filters to meet your analysis need.
Based on the type of analysis, select the appropriate Rule Set.

Access Risk Analysis Criteria
Use the filtering criteria to input the desired values
1 3
4
2
1 Field items are changeable by selecting criteria from the drop-down listings.
2 Operators are changeable by selecting a different operator from the drop-down

listings.
3
Copy a search line by selecting the +. Adding a duplicate search line acts as an
OR.
4
Delete a search line by selecting the -.

Access Risk Analysis Criteria
2
4
If selecting the Multiple Selections operator, click on Add Selections to add

1
multiple values.
2
Individual Values can be entered or removed using the Add/Remove buttons.

3
A text file can be uploaded to enter multiple values in one shot.
4
Values can be selected or excluded based on the tab it is included on.

Access Risk Analysis
Based on the type of report required, various report options can be selected.
The Access Risk Analysis type displays mitigated and unmitigated conflicts
Select Permission Level for SOD analysis
Select Critical Action and Critical Permission for Sensitive Access
The Mitigating Analysis displays valid and invalid mitigating control

assignments
If the expected report output is

large, run the report in
background mode.

Access Risk Analysis Simulation: User and Role
Access Risk Analysis Simulation
Simulation reports analyzes the impact of access changes for SOD and Sensitive
Access risks at the user and role level. The report is executed in steps.
The first step defines the analysis criteria (same as Access Risk Analysis). The
user or role on which the simulation will be run is specified
The second step defines the access change at the Role, Action, or Profile level
Action. Additional Criteria can be selected to refine the analysis.
Additional Criteria Description

Exclude Values Performs simulation as if the values were removed from the role or user.
Risk from Simulation
Displays only new risks caused by the simulated access change
only
Analyzes the impact to users assigned role on which simulation is run. (Role
Include Users
Simulation Only)
Include Composite Analyzes the impact on Composites Roles which include the role on which
Roles simulation is run. (Role Simulation Only)
Include Business Analyzes the impact on Business Roles which include the role on which
Role simulation is run. (Role Simulation Only)

Access Risk Analysis User / Role Level
Simulation
Access Risk Analysis Simulation
1 Select the mode in

which the analysis is
run.
2
Select the desired

Additional Criteria
3 options.
Review the
Permissions defined
for the added Actions,
Roles and Profiles.

Periodic Review Process

Periodic Review
Unmitigated SOD conflicts and sensitive access increase the risk of errors and
irregularities. They are not permitted in the production system.
The majority of this risk is managed by the Access Request process in GRC, however,
additional periodic review is required.
Addressing Risk through Period Reporting

On periodic basis, the Compliance Managers are responsible for extracting and reviewing
the below reports to ensure no open issues exist.
SOD Violation Report User Mitigating Control Report User

Level Level
Sensitive Access Report Mitigating Control Report Role
User Level Level
All organizations will follow the global periodic access review process, but there is flexibility
built in to allow organizations options to choose how to break down the reports and choose
reviewers.

Process Flow
CoE
GRC CoE
GRC
Compliance
Compliance
Manager //
Liaison
Manager
Liaison
Report criteria must be reviewed for completeness and accuracy before they are run in
SAP GRC
The reviews will be split based on platform requirements (this can happen either through
the SAP GRC criteria, or manually by the compliance managers)
The review must be completed within 30 days of the report being sent
All completed reviews are stored in a central location and managed by the CoE CoE
Roles & Responsibilities
There are three specific groups of people that participate in the periodic review processes
in the previous slide. The GRC CoE retains overall accountability for the process, but each
group has important responsibilities.
This group of individuals would Based on the type of review,
The GRC CoE will oversee the be either the compliance this would be role owners or
completion of periodic reviews at a managers for that platform, or users managers.
global level to maintain compliance specifically identified platform
Reviewers
Platform/Review Coordinators
GRC CoE
with global standards liaisons It is also possible for

compliance managers to
It is the CoEs responsibility to: It is the Coordinators perform the review directly if
responsibility to review: they have proper knowledge at
that level
Validate report criteria,
Maintain the global including who the
procedures and controls The Reviewer has the
reviewers are, before
best knowledge of the
each report iteration is
job and tasks executed
Generate and share run
by his/her team
reports
members and the roles
Break down reports (if needed for that job
Validate that all platforms necessary), and send
have performed a to reviewers Must have a backup
complete review, and
defined
escalate where Follow up with, and
necessary collect results from Executes the review
Reviewers (both the
and provides the
Maintain central review and any
results to the Review
repository of completed resulting access
Coordinator
reviews requests)

Obtaining Periodic Reports
The periodic reports will be provided to Review Coordinators by the GRC Production
Services Team. If necessary, the interactive original report can be viewed in SAP GRC by
navigating to the Access Management tab in SAP GRC. Select Background Scheduler
under Scheduling.
GRC Production Services Team captures the screenshots of each job variant which will be
used to generate reports for periodic review. The screenshots are sent to the Review
Coordinators to review and validate for completeness and accuracy.
Upon successful generation of the reports, the GRC Production Services Team will post the
result to the CoE SharePoint site, and inform the Review Coordinators.
It is the responsibility of each Review Coordinator to further distribute periodic review reports
to the appropriate reviewers, and to follow up to receive the necessary feedback.
The individual signed reviews should be sent to GRC COE for CIA audit

Escalation Process
A key control for the overall review process, is that the review process be completed in a timely
manner. In order to support the execution of this control, both the Review Coordinators and
GRC CoE will play a role in the escalation process:
First follow up after 14 days, and a second follow up after 21 days. Both of these follow ups
are the responsibility of the Review Coordinators.
If there is still no response by 28 days, the GRC CoE will escalate the issue to site
management and leadership
After 45 days, any users for which a response has not been received are eligible to be
locked. Discussions with the Review Coordinators and site leadership will happen before the
access is locked.
All reviews, and remediation actions that come from the reviews, should be completed within
60 days of the report being provided for review.

Periodic Reports Overview

Periodic Reports Overview
The below reports are explained in slides 11 to 14. A live demo will be provided
to further understand each report.
SOD Violation Report User Mitigating Control Report User

Level Level
Sensitive Access Report Mitigating Control Report Role
User Level Level
The frequency of the reports is semi-annual
Refer to the Quick Reference Guide and FAQ document for detailed
information on reviewing the reports.

SOD Violations Report: User Level
The User Level SOD violation report displays users in a specific organization
who have an unmitigated segregation of duties conflicts. Any conflicts that
appear on this report must be addressed before the review is completed.
Key Points
There should be very few risks in this report due to upfront controls that prevent access
violations during the user access request process . An open violation will exist due to
the following circumstances:
A role is changed which now causes a conflict with another role assigned to a user
The mitigating control assigned to user expires
A change in the rule set creates a new conflict for a user
Any unmitigated conflicts identified in this report must be remedied during the review
cycle
Sensitive Access Report: User Level
The User Level Sensitive Access report displays users in an organization and
their access to Sensitive Functions. If any user is found to have inappropriate or
excessive access, that access should be removed.
Key Points
This report will be generated based on the specific organizational access that a user has
in the system and will be split up based on organization and business process.
The report must be reviewed to determine if any users have inappropriate access to a
function/organization:
Determine if access to the sensitive function/transaction is required as part of the
users job responsibilities.
Recommend or confirm removal of access if it is deemed to be
inappropriate/excessive.

Mitigating Controls Report: User Level
The User Level Mitigating Controls report displays the users who have SOD
violating access in an organization and the Mitigation Control assignments to
them.
Key Points
Mitigating Controls must be reviewed in detail to:
Validate if the users that are associated to mitigating controls are valid for their
organization
Review the period for which the Mitigation Controls are assigned to the user.
Analyze if the violating access needs to be retained or removed.

Periodic Reports: Recap
Unmitigated SOD conflicts and excessive sensitive access are not permitted in the
production system.
Report Coordinators are responsible for the remediation and review process of periodic
reports to ensure no open issues exist.
Validate that there are no unmitigated SOD conflicts in production
Validate that users do not have inappropriate access to sensitive functions
Validate if assigned Mitigating Control are valid for the organization
Based on the review, remediation activity will be performed.
The GRC CoE is accountable for the global process, and for making sure that the
review is completed within the specified time period for the platform.

Report Navigation

Reviewing Reports
Report Formats
The Access Risk Analysis report can be viewed in different formats to display
different levels of information. The format can be changed using the drop down
list.
Format Features
Executive
Displays the unique Risk IDs and the number of associated conflicts
Summary
Management Displays the user or role and their associated unique Risk ID(s)
Summary (***Recommended starting format***)
Summary Displays the user or role, Risk ID, Risk Level and conflicting Action.
Displays all the information included in the summary format as well as the
conflicting functions, permissions, and Roles/Profiles (for users) where
Detail
the specific permissions are available. This is also where you can see
organizational rules when running sensitive access reports

Reviewing Reports
Drill Down
Detailed information can be found about an object by clicking on hyperlinked

names.
The long risk description and the

functions involved in the conflict is
displayed if the Access Risk ID is
clicked.

Remediation Options
for SoD and Sensitive Access
Reports

Remediation Options for SoD & Sensitive
Access
Remediation
Option
Questions to Ask Who to Contact
User Is the user appropriately assigned to

Users manager and user can provide
Assignment the role?
clarification around users job
(Remove role What other (non- conflicting)
responsibilities.
from user) transactions are within the role?
Role Owner can provide additional
Would the user need them?
information around the role and its
Has the user used the conflicting
purposes
access?
Apply Mitigating Mitigating control owner can provide

Control (last Is the mitigating control in the current
additional information about the
resort after DCM control framework?
control
considering other Are we introducing a new step in the
The CoE can assist in selecting the
business process?
options) appropriate control to mitigate the risk
Modify Role
Role Owner can provide additional
Who else is assigned to the role who
Design might get impacted?
information around the role and its
purposes. They can also recommend
Is there a need to create a separate
changes.
role?
Security can assist the Role Owner, if
Are there alternative roles available?
neededactivities listed to fully
Access violations may require a combination of the remediation
resolve
Modify theSet
Rule violation.
Is the false positive caused by The CoE can provide insights around
Utilize detailed information fromdecisions
systemic design the reports to determine
or a one thethe
rulebest remediation
set and coordinate options.
with SMR
Consult with theoff?users managers and role/function owners to suggest changes
Remediation Options: User Access
Modification
A user access modification should be performed if SOD or Sensitive Access risk
violations are found and the user does not require the access involved in the
conflict.
Determine if the access is required

Review the role assigned to the user causing the conflict in the Detailed
format.
Determine if the user requires this access to perform their job responsibilities:
Review if the user has executed any of the SoD Transaction codes within
the role
Consider the other Transaction codes in the role not involved in the conflict
Consult the users Manger and Role Owner, if necessary.
Next Steps
If a user modification is required, submit a New/Change Access request.
If a user modification should not be performed, refer to different remediation
options.
Remediation Options: Mitigating Control
Assignment
Initiate a mitigating control assignment if the SOD risk violations found can not be
eliminated from the user due to a business requirement.
Determine if a mitigating control is required

Review the risk associated to the user in the Management Summary format.
Check to see if there are existing valid mitigating controls for the risk. Critical
access risks do not have mitigating controls.
Validate whether the user has any additional access that could bypass the
mitigating control.
Review the details of the mitigating control to ensure it is associated to the
correct organization and it properly mitigates the SOD violation.
Next Steps
If a mitigating control assignment is required, submit a mitigating control
assignment request.
If a new mitigating control is required, submit a request to create a new
mitigating control.
If a mitigation control cannot be assigned, choose a different remediation
Remediation Options: Role Design
Change
Initiate a role design change if the SOD or Sensitive Access risk violations found
can be fragmented into multiple roles.
Determine if a role design change is needed

Review the risk and role in the Detailed format of the report.
Consider the transaction codes and authorization within the role
Check with the role owner to determine if role modifications are feasible.
Consider all of the users assigned the role
Next Steps
If a role design change is required, follow the change management process to
alter the Business or Technical role
If a role design change should not be performed, refer to different remediation
options.

Remediation Options: Rule Set Update
Initiate a rule set update if inconsistencies are found in the risk definition or if
incorrect transaction codes or authorization objects are defined in the rule set.
Determine if a rule set update is required

Review the risk in the Management Summary format to ensure that
transaction codes and authorization objects are relevant.
Click on the hyperlinked risk to view additional information
Next Steps
If inconsistencies are found in risk definition or incorrect t-codes/authorization
objects are defined in rule set, submit a rule set change request.
There are functional and technical change request that will need to be raised
depending on the circumstance. Refer to the Work Instruction document for
the step by step process of rule set change

Remediation Options
for Mitigating Control Reports

Remediation Options for Mitigating
Control Reports User Level
Determine if the Mitigating Control assignment is valid
Review the mitigtaing controls assigned to the user to determine if the
controls are valid for their organization.
Review the period for which the Mitigating Controls are assigned to the user.
Determine if the control assignment must continue or a replacement control
needs to be assigned.
If the control assignment is no longer valid:

Analyze if the violating access can be removed. Consult the users Manager
and submit a New/Change Access request.
If the access can not be removed, determine an alternate remediation option
to address the open violation:
If the mitigating control is still appropriate, update the validity date.
If the mitigating controls is no longer appropriate for that user/risk, you
must take additional actions to remediate the risk (refer to slides 20 to
24 for detailed information around the remediation options).

Remediation Options for Mitigating
Control Reports Role Level
Determine if the Mitigating Control assignment is valid

Review the mitigtaing controls assigned to the roles to determine if the
controls are valid for their organization.
Review the period for which the Mitigating Controls are assigned to the role.
Determine if the control assignment must continue or a replacement control
needs to be assigned.
If the control assignment is no longer valid:

Consult with the role owner to determine whether the mitigating control
assignment is still appropriate.
Determine the appropriate remediation option to address the open violation:
Apply a mitigating control
Modify the role design
Refer to slides 20 to 24 for detailed information around the remediation
options.

Remediation Options: Recap
Remediation activities must be performed on any options issues that

exists.
Utilize detailed information from the reports to determine the best option.
Change the format of the report to view different levels of information.
Click on the hyperlinked object name to view additional details.
Determine what remediation option(s) is the most appropriate.

User access modifications
Mitigating control assignments
Role design changes
Rule set update

Report Approval and Sign Off

Report Approval, Sign Off, and Storage
Report Approval and Sign Off
If remediation activities are necessary, the Review Coordinator will list with
completion dates the necessary corrective actions based on the feedback of
the reviewers(i.e. create mitigating control or request removal of access). At
the time of signing off on the review, the review coordinator will submit CA list
After all actions are completed, GRC COE will provide an updated report.
The Review Coordinator will sign off on PDF report (with all remediation
activities completed).
Key Points to Remember

Save initial access reports received with violations and updated access
reports showing that the access violation was resolved.
Documents will be electronically signed, signed off as per standards for
electronic documentation defined in 21 CFR Part 11
Documents must be stored in a centralized CoE site
http://teamsna6.jnj.com/JJC/GRC/platforminfosite/Shared%20Documents/Forms/AllItems.aspx

Process Overview SOD SA Review
DS-SOP-18845
Platform Compliance New!

Reviewers All
All review
review
1 3 3 evidences
evidences
will
will be
be
GRC Prod
Prod Send review
review stored
stored
GRC Send
centrally
centrally
Support team
Support team evidence, action
evidence, action with
with COE
COE
creates reporting
creates reporting plan to
plan to Platform
Platform
variant form
variant form POC
POC
1 3 4
Platform POC
Platform POC
Platform POC
Platform POC
verifies
verifies Platform POC
Platform POC split
split
signs off review
signs off review
completeness of
completeness of and distribute
and distribute to
to Signed copy or review reports,
report overall
report overall and
and
report variants
report variants Compliance
Compliance evidence of reviews, action plan
provides action
provides action
and approves
and approves thethe Managers
Managers are retained centrally
plan to
plan to COE
COE
reporting criteria
reporting criteria
Approve 4
Access certified
Access certified
Approve and retained
and retained
2
GRC Prod
GRC Prod Support
Support GRC Prod
GRC Prod
schedules automatic
schedules automatic Support team
Support team
jobs in
in GRC
GRC system
system toto Access removed
Access removed
jobs uploads the
uploads the report
report
generate the reports by GRC request,
by GRC request,
generate the reports in the
in the COE
COE Share
Share
and performs
performs Reject created by
created by
and point
point
completeness validation
completeness validation Business
Business oror
Platform
Platform
Security
Security

Your Role Step 1
Reporting Variant Form
A kick off call is scheduled by the GRC Production Support team with Platform POC to initiate the review and
formalize the following:
Expectations during the review cycle
Agree upon the job variant (criteria such as Legal Entity, Organization Access etc.). Refer Periodic
Reporting Criteria Form1 embedded below
GRC Production Support team will verify the completeness of reporting variant form and suggest
amendments, if any
The reporting variant form capturing the agreed upon criteria to run the report will be digitally signed off by
Platform POC, GRC COE and GRC Production Support POC
GRC Production Support team will store the evidence of review (sign off) in the COE share point folder
https://jnj.sharepoint.com/teams/GRC/PeriodicReview/Shared%20Documents/Forms/AllItems.aspx
Periodic
Reporting Criteria For
The Platform Security Team is the most qualified to review the user groups &
organizational values used in the report criteria and platform security team will contact
local compliance team if required.

Your Role Step 2
Generation and Sharing of SOD SA Report/s
Using the criteria in the reporting variant form, GRC Production Support team will execute the SOD SA report in
GRC
GRC Production Support team will perform a completeness check on the report generated and provide a
summary of the analysis performed on the report. The analysis covers aspects such as total users, unmitigated
users, users with deleted/blank user groups. The report will be uploaded in the COE share point folder.
GRC COE will ensure that the respective Platform POC/s has access to the COE share point folder
GRC Production Support team will notify the Platform POC/s regarding the successful updation of the reports
in the COE share point folder (including the report location in the folder)
How do I address
the SOD SA
Conflict??

Your Role Step 3
Review of SOD SA Report/s
The platform POC/s are responsible to retrieve the reports, split up the reports where necessary, and obtain the
necessary input from compliance managers to complete the reviews. Some of the key review aspects for
POC/s may include but not limited to
Gather the review comments from users managers and role/function owners
Ensure the review is completed 30 days from the distribution of the broken down reports
In-case the review is not completed in 30 days (refer above), the POC/s will escalate non-compliance
and inform GRC COE regarding the delay
Detailed review of the report by the compliance managers may include but not limited to
Analyse each SOD SA scenario based on the degree of complexity and extent of conflict in a given
environment using the combination of Functions
Review and validate if the users that are associated to mitigating controls are valid for their organization
The period for which the mitigation control/s are assigned to the user whether the control assignment
must continue or be replaced
Analyze if the violating access needs to be retained / removed.
Platform POC will provide review evidences from compliance managers to COE. These evidences will be
stored centrally by GRC Production Support team in the COE Share point

Your Role Step 3: Executing the Review
Executing the Review
Leverage the report and perform following activities
Filter for Risk IDs that need to be remediated basis the report and analysis performed above
Transform data into LHS-RHS format
Retain columns for User ID, Access Risk ID, Rule ID, Function Description and Role/Profile; delete all
other columns.
Remove duplicates for entire data sheet

Compare consecutive lines and lookup values using IF statements to transform sequential lines into side-by-
side form.
Perform IF operation for columns User ID, Risk ID, Rule ID and lookup Function ID and Action
Multiply result for all lookup columns
Add second IF condition formula to lookup and add values from consecutive row for Functions and
Role/Profile

Filter out rows with 0 in Function and Role/Profile and rename original function column to LHS Function role
to LHS Role and new columns as RHS.
Create pivot table with data and transform to tabular form
Evaluate from a "functional" lens which side of the risk users should have access to and which side they
should not. Based on that decision, you can remediate risk by identifying which roles should be removed from
access.
Once appropriateness for a user/role, you move to reviewing t-codes within the access (leverage same method
to populate T-codes). This review would be to verify that no excessive access is assigned to the user. Using
statistics into the report can help to determine unused t-codes that may be removed from access
Removing a single transaction from access can result in a reduction of several violations

For further analysis the permissions against t-codes can be analysed to determine whether authorization
object and filed level updates can remove risk.
Where applicable a permission-level analysis may also include analyzing organization-level accesses to
determine whether the conflict is for accesses across multiple non-conflicting organizations. Such cases may
be classified as false-positives.
Document the assessment in the form of action plans
On a parallel basis, GRC Production Support team will follow up with the POC/s on the status of the review
(activity is undertaken on a fortnightly basis)
There should be zero unmitigated SOD conflicts in production environments, except for
non-High risks at the role level . Any conflicts that appear on this report must be addressed
before the review is completed.

Your Role Step 4
Review of Action Plan
Compliance reviewers send the reviewed report/s with finalized and agreed upon action plan/s to the Platform
POC/s.
The review is documented in the form of a sign off on the access reports provided. Review must be completed
within 30 days of start of review.
The POC/s review the action plan for accuracy prior to sending the report to COE.
Action plan if any, will be sent to the GRC Production Support team in the pre-defined format. Refer the
embedded file. GRC production team will implement the action plan in the next 30 days from the day the
action plan is received
Pre defined
Format
Documents are electronically signed as per standards for electronic documentation

defined in 21 CFR Part 11

Timelines and Protocol

Projected Timelines
SOD SA Review Apr17 May17 Jun17 Jul17
Review Initiation
Review Completion by Platform
Overall Review Completion
Activity Responsibility Medium
Kick Off GRC Production Support Team Over Call
Finalize the reporting variant and provide sign off Platform POC Email
Upload the sign off of reporting criteria form GRC Production Support Share Point
Sharing of SOD SA Report GRC Production Support Team Email, Share Point
Share evidence of SOD SA review reports to compliance managers Platform POC Email
Upload evidence of SOD SA review by compliance managers GRC Production Support Team Share point
Completion of Review(Sign off) and Action Plan Update Platform POC Email, Share Point
Upload the sign off on the periodic review reports GRC Production Support Team Share point
Completion of Implementation of Action Plan GRC Production Support Team Email, SharePoint
Questions
Appendix
Security relevant Ad-hoc reports
Where are the Ad-hoc Reports available to run?
Users can run different ad-hoc reports from Report and Analytics tab of the GRC
page.
What are the Ad-hoc reports available to run?

The following reports are relevant for compliance managers-
# Report Name Report Type Information provided in report
This dashboard provides drilldown statistics of requests that have been

created in a particular period using GRC Access Controls. This dashboard
1 Access Requests Dashboard
can be useful to assess provisioning trends and volumes which can be
analyzed to evaluate effectiveness of security design.
The Access Provisioning dashboard gives drilldown information about actions

that were taken as a part of completion of requests in a given period
2 Access Provisioning Dashboard
example how many roles were assigned, how many deleted, how many users
were created, deleted, etc.
Tabular Report
3 List Action in Roles Lists all T.Codes in a given role.
(downloadable)
Sometimes roles are incorrectly maintained due to which there are

Compare Action in Menu Tabular Report
4 inconsistencies in role Menu and S_Tcode values. This report compares the
and Authorization (downloadable)
two.
This report enables you to compare users with different roles to find
Tabular Report
5 Compare User Roles differences in accesses available to them. Useful in troubleshooting
(downloadable)
authorization issues.
Security relevant Ad-hoc reports
# Report Name Report Type Information provided in report
Tabular Report List of roles available per user. You can generate list for all
6 User to Role relationship
(downloadable) roles/users or selectively.
Role Relationship with Tabular Report
7 For condition rules where roles are linked to user groups
user/user group (downloadable)
Tabular Report Provides details of changes for roles with timestamp and Changed by
8 PFCG change history
(downloadable) details.
Master to Derived role Tabular Report

9 Lists Master-Derived relationship
relationship (downloadable)
Single to Composite Role Tabular Report

10 Lists Single roles in a composite role
relationship (downloadable)
Action usage by User, Role Tabular Report
11 Lists t.code usage for Users, in Roles and Profiles.
and Profile (downloadable)
Tabular Report Provides complete list of accesses (actions and permissions)

12 Count authorization in Roles
(downloadable) available in a role.
Tabular Report Provides complete list of accesses (actions and permissions)

13 Count authorization in Users
(downloadable) available for a user.
List Expired and Expiring Tabular Report Lists invalid/expired role assignments for users and also expiring
14
Roles for Users (downloadable) accesses in the current month.
Embedded Action calls in Tabular Report

15 Provides list of transactions which gets called by any program
Program of SAP System (downloadable)
List Actions in Roles but not Tabular Report Provides list of Tcodes in Roles, but not in rules. This data can be
16
in Rule (downloadable) used to enhance Rulebooks
Report Navigation
Report Formats
The GRC reports can be viewed in different formats to display different levels of
information. The format can be changed using the drop down list.
Format Features
Executive The executive summary lists each risk as a single line item and
Summary displays the total number of conflicting actions that produced the risk.
The management summary lists each risk as a single line item and
Management
displays the risk severity level. (***Recommended starting
Summary
format***)
The summary report lists all conflicting actions that produce the risk in
Summary
a one line item.
Displays all the information included in the summary format as well as
the conflicting functions, permissions, and Roles/Profiles (for users)
Detail
where the specific permissions are available. This is also where you
can see organizational rules when running sensitive access reports
Report criteria basics
1 3
4
2
1 Field items are changeable by selecting criteria from the drop-down listings.
2 Operators are changeable by selecting a different operator from the drop-down
3
listings.
4 Copy a search line by selecting the +. Adding a duplicate search line acts as an
5
OR.
Delete a search line by selecting the -.
Report criteria basics
2
4
If selecting the Multiple Selections operator, click on Add Selections to add

1
multiple values.
2
Individual Values can be entered or removed using the Add/Remove buttons.

3
A text file can be uploaded to enter multiple values in one shot.
4
Values can be selected or excluded based on the tab it is included on.

Reviewing Reports
Detailed information can be found about an object by clicking on hyperlinked

names.
The long risk description and the

functions involved in the conflict is
displayed if the Access Risk ID is
clicked.
Security relevant reports
Access Requests
Access Requests dashboard provides drilldown statistics of requests that have been created
in a particular period using GRC Access Controls.
This dashboard can be useful to assess provisioning trends and volumes which can be
analysed to evaluate effectiveness of security design.
This dashboard is located at NWBC -> Report & Analytics Tab -> Access Dashboards.
Click on specific area of the
pie chart to drill down into
detailed information.
The access request trends

can be analyzed for a
particular period, system,
process or request type.
Access Provisioning
The Access Provisioning dashboard gives drilldown information about the actions that were
taken as part of completion of requests in Access Request Approval Workflow. The information
includes:
Number of requests with objects assigned, removed or retained via New/Change access requests
workflow in GRC.
Number of users processed via GRC.
Click on
This dashboard is located at NWBC -> Report & Analytics Tab -> Access specific area of the
Dashboards.
chart to access detailed
information.
The access request trends

can be analyzed for a
particular period, system or
approver.
List of actions in roles
This report provides the list of actions in roles.
The report is useful for security teams to analyze the actions with in roles
This report is located at NWBC -> Report & Analytics Tab -> Role Management Reports.
Input the search

the criteria as per
your analysis
need.
Compare Action in Menu and Authorization
This report performs comparison between the transactions in Role menu and the S_TCODE
authorization object.
This report is useful to analyse security design and resolve inconsistencies in role Menu and
S_TCODE object.
Enter the
application type,
landscape and
role name.
Compare User Roles
This report enables you to compare users with different roles to find differences in accesses
available to them.
This report is useful in troubleshooting authorization issues.
Enter System
Select Source
Type as User ID
and enter values
in Source Value
and Target value
User to Role relationship
This report gives you the list of users available per role or profile. The report lists only the
technical roles.
This is one of the key reports while performing periodic user access reviews.
Enter System and

role name
Role Relationship with user/user group
This report is used for condition rules where roles are linked to user groups.
This report is useful to review the role to user group mapping as it is one of the key ARM
features used at J&J.
Enter System and

user ID or user
group
PFCG change history
This report provides details of changes for roles with timestamp and Changed by details.
This report is helpful for audit purposes to verify if there are any changes made to the roles in
the audit period.
Enter System and

Role name
Master to Derived role relationship
This report give you the relations between master to derived roles.
The report helps analyze the role design for systems belonging to your platform.
Select Application
Type, System and
Role name
Single to Composite Role relationship
This report provides the lists of single roles in a composite role.
The report helps analyse the role design for systems belonging to your platform.
Enter System and

Role name
Action usage by User, Role and Profile
This report gives you the lists of t-code usage for Users, in Roles and Profiles.
This report serves as a substitute for ST03N report.
This report is located at NWBC -> Report & Analytics Tab -> Security Reports.
Action usage by User
Enter System and

Action
Select Report by as
User and enter User
ID
Action usage by User, Role and Profile
(Contd.)
The analysis can also be performed at the Role level.
Action usage by Role
Enter System
Select Report by
as Role and enter
role name
Count authorization in Roles
This report provides a complete list of accesses (actions and permissions) available in a role.
This report is useful for rationalizing roles and/or review authorizations on a periodic basis.
Enter System and

Role name
Count authorization in Users
This report provides a complete list of accesses (actions and permissions) available for a user.
It is useful for user access rationalization, by removing redundant or excessive accesses
The report can be

extracted for a
particular system
and user
List Expired and Expiring Roles for Users
This report provides the lists of invalid/expired role assignments for users along with the list of
accesses expiring in the current month
This information can be used for access clean-ups and user-role recertification.
Enter System,
User ID and check
expired or expiring
roles box
Embedded action calls in programs of SAP
systems
This report provides list of transaction codes being called by any program of SAP system.
This report is useful review of rule set completeness.
The report is located at NWBC -> Report & Analytics Tab -> Audit Reports.
The report can be extracted

for a system, program or a
transaction code.
List Actions in roles but not in Rule
This report provides list of transaction codes that are present in roles but are not part of or
active in your rule set.
This data is useful in enhancing rule books, particularly while reviewing coverage of custom
transactions in your rule set.
The report is located at NWBC -> Report & Analytics Tab -> Audit Reports.
The report can be extracted

for a system or a specific
role.
Process Workflow: New/Change Access Request
All new/change access requests are required to be approved by the users manager and the role
owner(s)
The Compliance Managers approval is only required if the New/Change access request
contains SoD risks.
If the request is approved, it will be sent for provisioning (automated or manual).
Request
Rejec Rejec Rejec
t t t rejected;
notification
User /
sent to user
Requester User
submits
Users Approv Role/Functi
Manager e on Owner Provisioni
Access
Request ng
Approv
e
Note: Requests with medium LE/Regio
Mitigation
and low level risks will be SoD nal
Control Approv
mitigated at the role level and will Foun Yes Complian
Assignme e
be done at the time of d ce
nt
rollout/implementation. Manager
No
Assignment steps explained on next slide

Enterprise SAP GRC Compliance and Security Training

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Enterprise SAP GRC Compliance and Security Training

Uploaded by

Copyright:

Available Formats

SAP Governance, Risk and Compliance (GRC)

Compliance and Security Training

Explain the actions required from compliance

Walkthrough SoD, SA reports

Mitigating control creation and assignment

Periodic review process, role and

Welcome and introductions 30 minutes

| SAP GRC Compliance Manager - Introduction and Training (Module 1 of 4) Confidential | 3

Welcome and introductions 30 minutes

| SAP GRC Compliance Manager - Introduction and Training (Module 1 of 4) Confidential | 4

SAP GRC 10 Access Control Components

| SAP GRC Compliance Manager - Introduction and Training (Module 1 of 4) Confidential | 5

Access request management Access risk analysis

Business role management Emergency access management

Create New Modify

| SAP GRC Compliance Manager - Introduction and Training (Module 1 of 4) Confidential | 6

GRC Overview Module 1

Segregation of duties - Module 2

Approving user access Module 3

Approver delegation Remediation Options

GRC Overview Module 1

Segregation of duties - Module 2

Approving user access Module 3

Approver delegation Remediation Options

GRC Overview Module 1

Segregation of duties - Module 2

Approving user access Module 3

Approver delegation Remediation Options

Provide an overview of SAP GRC Rule Set and its

Explain the design of the J&J GRC Rule Set

Explain an Access Risk and how to

Explain a Mitigating Control and how to create one in

At the end of this training, each compliance manager should be able to

| SAP GRC Compliance Manager - Introduction and Training (Module 1 of 4) Confidential | 10

Welcome and introductions 30 minutes

| SAP GRC Compliance Manager - Introduction and Training (Module 1 of 4) Confidential | 11

| SAP GRC Compliance Manager - Introduction and Training (Module 1 of 4) Confidential | 12

Maintain Purchase Order

Functions Maintain Purchase Order Manage Goods Receipt

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

Organizational Create PO for Create GR for

Sensitive Access (SA)

The rule set has a Functional and Technical components

Risks are created when individuals have access to perform an

Organizational rules allow you to report on users that have

| SAP GRC Compliance Manager - Introduction and Training (Module 1 of 4) Confidential | 15

| SAP GRC Compliance Manager - Introduction and Training (Module 1 of 4) Confidential | 16

| SAP GRC Compliance Manager - Introduction and Training (Module 1 of 4) Confidential | 17

Global vs. Local

Platform Components of the rule set

Custom sensitive access activities used by a platform or organization

| SAP GRC Compliance Manager - Introduction and Training (Module 1 of 4) Confidential | 18

Global Sensitive Access Rule Set

Post Journal Entries

Low Medium High Critical

| SAP GRC Compliance Manager - Introduction and Training (Module 1 of 4) Confidential | 20

Navigating the Rule Set in GRC

| SAP GRC Compliance Manager - Introduction and Training (Module 1 of 4) Confidential | 21

| SAP GRC Compliance Manager - Introduction and Training (Module 1 of 4) Confidential | 22

Function ID: The identification code for

Description: A short, plain text

| SAP GRC Compliance Manager - Introduction and Training (Module 1 of 4) Confidential | 23

1 Access Risk ID: The identification code of the risk