Expert Tips To Simplify And Automate

Your User Access Request Process

David Denson
PwC
IN THIS SESSION

• In this session, we will discuss effective strategies that have been

utilized at other implementations to simplify the access request
process, focusing on the 10.X versions of GRC AC. The discussions
will include:
• The common challenges experienced at each stage of the access
request process.
• Functionality that can be utilized to assist end users with the access
request process.
• How to customize access request screens to better agree with
business requirements and terminology.
• Learn effective strategies that have been utilized at other
implementations to simplify the request process.
WHAT WE’LL COVER

• Common Challenges
• Approver Experience Enhancements
• Customizing Access Request Views
• Utilizing BAdIs To Enhance GRC
• Implementing an Effective Role Design Strategy
• Custom Reporting
• Modifying GRC AC User Interface
• Help Center
• Request Mitigation Policy
• Wrap-up
COMMON CHALLENGES – REQUEST ACCESS

• Some of the common challenges/frustrations experienced by end

users while requesting access include:

There are so many fields I have to enter data in and I am transferring to a new job, I’ll just copy Bob’s
tabs to navigate, this takes forever! access and I should be fine.

I am a new user and there are so many roles and This request status report is very confusing, how
systems for me to choose, I have no clue which roles do I figure out who needs to approve my request?
I need …

I need to help out during close and know the transactions /

organization values I need access to, but how do I find the associated
roles in GRC?
COMMON CHALLENGES – APPROVE ACCESS

• Some of the common challenges/frustrations experienced by end

users while approving access include:
Navigating GRC is very difficult as there are This is a reporting risk, do all of these
too many links and I cannot find the one really need to be routed to me for
that I need! mitigating control assignments?

Why do I have to run a risk analysis in every I do not have the information I need to make
request / when I make a change to an informed decision whether this user
the request? actually needs access to this role.

I get so many requests for approval, many of which are

mapped to the user’s job position. What value is there I need additional field XX in these reports
in my approval of these types of requests? to properly understand them.

The user selected every available role, What is this role being
The approval form is cumbersome and does why is it my responsibility to analyze requested and why is it coming
not readily display the information I need. this request? to me?
WHAT WE’LL COVER

• Common Challenges
• Approver Experience Enhancements
• Customizing Access Request Views
• Utilizing BAdIs To Enhance GRC
• Implementing an Effective Role Design Strategy
• Custom Reporting
• Modifying GRC AC User Interface
• Help Center
• Request Mitigation Policy
• Wrap-up
APPROVER EXPERIENCE ENHANCEMENTS

• Exception Based Routing

– To reduce the number of irrelevant requests that route to your approvers,
consider using custom routing rules to perform checks on requested access prior
to routing to approvers. This approach will require an accurate and valid user
data source.
• Examples:
– Upon submission, confirm the user is an appropriate business area for the
role being requested (i.e. if requesting a JE entry role, confirm the user is
in Finance).
– For dollar value roles (i.e. PR/PO roles), confirm the user is at an
appropriate organizational level for the role they are attempting
to request.
You can utilize the SAP provided classes to build custom rules, just insert
your business logic in the P_PROCESS method. Access request processes
are included in the CL_GRAC_RULEAPI_*_ACCREQ classes.
APPROVER EXPERIENCE ENHANCEMENTS
(CONT.)

• Exception Based Routing

– Custom rules can be developed for use during approval workflow
to perform validations on requested access
User submits • Selectable roles can be limited based on a user’s organization or position,
request for allowing them to only select from roles that are mapped to their area.
access
in GRC

• Based on the user’s organization / position, are the pre-approved requirements

Is pre- met for the user to have access to the requested role? If not, requests can be
approved routed to exception approvers that can assist the user with requesting
criteria met? appropriate access or determining if the request is a valid exception.

• Based on the validation checks, user has submitted a valid request for access.
Valid request These requests can then be routed to the approver for approval or
for access auto-provisioned.
APPROVER EXPERIENCE ENHANCEMENTS
(CONT.)

• To enhance the approver experience, the following recommendations are

strongly encouraged:
– Notifications
• In the notifications that are sent to the approver, do not just use the standard
notifications in GRC. You can set up a different notification for each action in
each stage of the approval path by adding additional message classes (see SAP
Note 1637900 for more details).
• If multiple approvers share approval duties for roles, do not give the link
directly into the approval request, but rather set up a view and provide a link
directly to their work inbox.
• Be sure to include either instructions on how to approve / reject the request
or note where to go for further instruction (i.e., help center).
You can replace the long URL links in your notifications with hyperlinks by
utilizing the following HTML format: <a href = %Variable% or URL> Your
Keyword for hyperlink </a>.
APPROVER EXPERIENCE ENHANCEMENTS
(CONT.)

• Work Inbox
– To pull more relevant fields into the work inbox, such as user
name/ID, requester name/ID, stage, and request type, switch the
default query from ‘All’ to ‘Access Management’ (this can be done
for all users by accessing the work inbox in Customizing mode).
– To have the items in the work inbox refresh automatically, you can
utilize t-code/npowl_cockpit.
• Find the GRFN_INBOX application, click on ‘Register Query’,
choose the query to maintain and click ‘Maintain Query’, then
change the option for the ‘Refresh Type’ to ‘On Every Page Visit’.
– You can also maintain this option for other tables in GRC.
APPROVER EXPERIENCE ENHANCEMENTS
(CONT.)

• Remediation/Mitigation Stage
– To present the risk analysis reports in a more “business friendly” view, you can utilize
parameter 1048 to have the analysis ran in business view.
– When configuring the ruleset, make sure that only permissions that are relevant to
your environment are enabled (you can utilize ST01 to determine needed
authorizations), otherwise this can lead to false positives in your reports.
– For any non-critical risks that are expected to have job level conflicts that cannot be
avoided, applicable mitigating controls should already be available for assignment (or
you can utilize mitigation policy functionality to not require mitigation of
these risks).
– If you have multiple rulesets in your environment, you can utilize the “Request
Multiple Rule set” BRF+ application to configure when each ruleset is selected
for analysis.
If your company leverages Process Control (PC), the integration between PC &
AC can bridge the gap in determining if mitigating controls being assigned are
still valid and effective.
APPROVER EXPERIENCE ENHANCEMENTS
(CONT.)

• Remediation/Mitigation Stage
– Occasionally, you may receive a risk analysis that is nearly impossible
to decipher.
• A simple method to determine what remediation options are
available (besides integration with third-party tools) is to pull the
analysis into Excel and utilize pivot tables or use Access Databases to
compare results to functions and identify remediation options.
4000+ Lines Easily Identify Available Remediation Options
WHAT WE’LL COVER

• Common Challenges
• Approver Experience Enhancements
• Customizing Access Request Views
• Utilizing BAdIs To Enhance GRC
• Implementing an Effective Role Design Strategy
• Custom Reporting
• Modifying GRC AC User Interface
• Help Center
• Request Mitigation Policy
• Wrap-up
CUSTOMIZING ACCESS REQUEST VIEWS

• Why does this matter? I do not have the information I need to make
– Through GRC form customization, an informed decision whether this user
we can realize the following actually needs access to this role.
benefits:
• Ease the requesting process by
reducing the time it takes to There are so many fields I have to enter data
submit a request in and tabs to navigate, this
• Present only relevant takes forever!
information to the user, reducing
user confusion and frustration
during the request process The approval form is cumbersome and does
• Reduction in the data points not readily display the information I need.
needing to be reviewed eases
the review process for approvers
• Deliver all required information
the reviewers need to make an
informed decision
CUSTOMIZING ACCESS REQUEST VIEWS (CONT.)

• There are several ways to customize the displayed information on GRC

access request screens:
– End User Personalization
• Hide, allow edits, require data entry, or specify default values for
selected fields.
• Standard configuration functionality.
– Administratively customize the view configuration
• Allows you to hide objects, add new objects, change object text, and
apply default values by directly configuring the access request views.
• Considered a development function and should be performed
with care.
– IdM / Fiori Integration
• Integrate with an IdM solution or Fiori to provide a more customizable,
simplified interface to meet your end user requirements.
CUSTOMIZING ACCESS REQUEST VIEWS (CONT.)

• End User Personalization (EUP)

– Navigation path: SPRO > Governance, Risk and Compliance > Access Control >
User Provisioning > Maintain End User Personalization
– 999 (Default) EUP ID is used for Access Request submission screen, but you can
configure additional EUP IDs and assign to approver stages and template
request IDs.

You can utilize the characters #!# in the default value field to pull in a dynamic value for an
attribute. For example, if your SNC value needs to be p:clientx.com\userid, you can use
p:clientx.com\#!#USERID_L#!# to provision the value for each user.
CUSTOMIZING ACCESS REQUEST VIEWS (CONT.)

• Configure Access Request Views

– To enter admin mode after navigating to the desired Web Dynpro
application, enter “&SAP-CONFIG-MODE=X” at the end of the URL.
This is the case for all access request screens EXCEPT for the
approver view.
– To enter admin mode for the approver view, enter the string
“&SAP-CONFIG-MODE=X&OBJECT_ID=ACCREQ/123” to the end of
the URL.
By default end users are allowed to personalize their interface, which can pose a risk, especially
when utilizing End User Login (EUL) functionality as a shared user ID is used. You can disable
this option globally in the ‘WD_GLOBAL_SETTINGS’ service via t-code SICF (Drill down to
/default_host/sap/bc/webdynpro/sap/ and right click on WD_GLOBAL_SETTINGS, click Test
Service, check box next to “Do not allow Personalization by the User).
CUSTOMIZING ACCESS REQUEST VIEWS (CONT.)

• Customize Access Request Views

CUSTOMIZING ACCESS REQUEST VIEWS (CONT.)

What is IdM?
• Identity Management (IdM) tools are enterprise-wide, cross-
application solutions that automate and increase the transparency
around user access and entitlement administration. IdM tools offer a
wide range of functionality, including:
– Automated provisioning to
new and existing users
– Automated password resets “Virtual” Composite
grouping for A/P
Clerk

– Single sign-on
– Ability to customize forms and
Underlying Roles (SAP
and/or Non-SAP)

functionality to enhance the Flexibility to select

some or all of the
underlying tasks

user experience
SAP FIORI – WHAT IS IT?

An SAP front-end tool that….

• Offers a single, role based entry point for end
users to access business functionality in a simple,
coherent and responsive fashion
• Makes about 400+ SAP transactions available out
of the box -> included as part of license cost
• Can be used on multiple platforms (desktop,
idevices, etc) without additional programming
• Makes it possible for end users to access
business functionality on their mobile devices
either in the Intranet (VPN) and/or the Internet.
Allows for customizing screens and functionality
to meet customer’s specific business needs
SAP FIORI – BENEFITS AND DRAWBACKS

Drawbacks
• SAP Fiori is not a mobile platform. With SAP
Benefits Fiori, you do not see terms like offline
• Increased end user adoption and improved synchronization management, device
user satisfaction due to dramatically management etc. which are functionalities that
improved user experience a typical mobile platform provides
• SAP Fiori apps are multi-platform without • SAP Fiori apps are not native to the device they
programming additional screens -> a very are running on
attractive low TCO option • SAP backend only – currently, Fiori is designed
• Leverages existing SAP investments by to run with SAP backend only
providing instant value to all employees
and processes
 COMMONLY USED APPLICATIONS

• SAP has delivered a number of mobility applications for GRC –

Access Controls:
– Check Request Status*
– Access Approver*
– Request Access*
– Request for Others
– Compliance Approval
– Role
– Access User
– Access Risk
– Mitigation Control
*Most commonly used Fiori apps by customers
SIMPLIFIED ACCESS REQUEST

• Access Request Management

– New access request and
approver forms
• Streamlined interface
• Improved search
• Embedded side-panels
– Existing form customization
improvement
• Role search improvements

In order to utilize the new “Simplified” screens in GRC 10.1, you must have a
browser that is HTML5 and CSS3 compliant. Examples of such browsers
include Internet Explorer 9+, Chrome, and Firefox.
WHAT WE’LL COVER

• Common Challenges
• Approver Experience Enhancements
• Customizing Access Request Views
• Utilizing BAdIs To Enhance GRC
• Implementing an Effective Role Design Strategy
• Custom Reporting
• Modifying GRC AC User Interface
• Help Center
• Request Mitigation Policy
• Wrap-up
 UTILIZING BADIS TO ENHANCE GRC

A BAdI (Business Add-in) is a custom enhancement that can be inserted to

accommodate user requirements. There are many provided BAdIs, but the most
commonly used include:
• GRAC_ACCREQ_SEARCH_CRITERIA – Access Request Role Search Criteria
• GRAC_ACCREQ_ROLE_SEARCH – Role Search Restrictions
• GRFN_MSMP_NOTIFICATION_ES – MSMP Notification Override
BAdIs allow you to
• GRFN_MSMP_END_OF_PATH_NOTIF – End of Path Notification customize the
• GRFN_MSMP_APPROVER_VALID_ESI – Approver Validation application without
• GRFN_MSMP_ESCALATE_OVERRIDE_ES – Escalation Override making core code
modifications,
• GRFN_MSMP_ESCAPE_OVERRIDE_ES – Escape Override reducing the risk of
• GRFN_MSMP_REQUEST_FINISHED_ES – Request Finished Extension impacting the
customization
• GRAC_TRG_VERIF – Training Verification when applying
• GRAC_TEMPLATE_ROLE – Creation of Template Roles fixes or Support
• GRAC_BUSINESS_SHELL_ROLE – Business Role Provisioning Override Pack upgrades.
• GRAC_ACREQ_ITEM_VALIDATE – Override Role Assignment Validation for Provisioning Actions
UTILIZING BADIS TO ENHANCE GRC (CONT.)

• The Access Request Role Search Criteria & Access Request Role Search
Restriction BAdIs can be utilized to guide users to the correct
role assignments.
– The Access Request Role Search Criteria BAdI can be utilized to default in
the search fields most relevant to your environment. This provides easy
to use default search parameters leaving advanced search for
advanced users.
– The Access Request Role Search Restriction BAdI can be utilized to
restrict role search results to only those roles applicable to
the user.
If you have an accurate user data source, you can pull user restriction fields directly into the
request via field mapping (i.e. company, employee type, etc), have the field configured as a role
attribute, and use the role search restriction BAdI to limit the role search results to only roles
mapped to the user’s restriction field, reducing the risk of users selecting irrelevant roles for
their position.
WHAT WE’LL COVER

• Common Challenges
• Approver Experience Enhancements
• Customizing Access Request Views
• Utilizing BAdIs To Enhance GRC
• Implementing an Effective Role Design Strategy
• Custom Reporting
• Modifying GRC AC User Interface
• Help Center
• Request Mitigation Policy
• Wrap-up
IMPLEMENTING AN EFFECTIVE ROLE DESIGN
STRATEGY

• An effective, healthy role design is a MUST before Who What Where

attempting to roll out the GRC Access Request Management

(ARM) Module.
– Why?
Effective
• Environments with large numbers of unused roles, SAP role
high t-code duplication between roles, and design
inconsistent naming convention will make role
selection extremely difficult for end users.
• Roles with intra-role SoD conflicts will cause delays in
the provisioning process while being evaluated for
mitigation / remediation.
• Remediation efforts will be very time consuming if
you do not have focused, task based roles with secure
org level values at the core of your role design. This
will allow remediation activities to be at the user
assignment level and reduce role maintenance
activities needed.
IMPLEMENTING AN EFFECTIVE ROLE DESIGN
STRATEGY (CONT.)

Comprehensive SAP Security Design

• User provisioning process Key Challenges • Misalignment of IT vs.
could have more Business Objectives
automation and • Needs Strategic Security
information Design Decisions
• Role Change Management • Needs Role or Security
needs risk and quality Org Structure
Security & & Governance
Design Ownership
controls Provisioning
• Needs improved emergency Processes
support process • Complex Security Design
• Needs more flexibility to
SAP Role respond to ongoing changes
• Management KPIs for Architecture
Security Design are not • Needs scalability to grow
established with organization
• Needs automation for • Needs more efficient Role
ongoing monitoring and Build Approach
recertification procedures • Needs Documentation of
• Needs improved SOD Effective SAP Security Control Points
and/or Mitigating control Security Design • Inherent Segregation of
frameworks Duties Risk
IMPLEMENTING AN EFFECTIVE ROLE DESIGN
STRATEGY (CONT.)

• High Level – Two Design Approaches

– Job-Based Approach = Security is built and provisioned based
upon positions/jobs for a group of users (i.e., A/P Manager).
– Task-Based Approach = Security is built upon small definable tasks
executed within the system (i.e., A/P Invoice Processing). Several
task roles make up a user’s access. Also known as activity-based
approach.
• Preferred Model:

Task-Based Approach
IMPLEMENTING AN EFFECTIVE ROLE DESIGN
STRATEGY (CONT.)

• What is the main complaint regarding task-based roles by

end users?

I have to add all 20

roles I need access to
one-by-one?!?!?
ACCESS REQUEST TOOLS

• We now have tools available that can be utilized to assist users in getting
the access they need. These functionalities should be utilized for new user
requests and job transfers:
– Template requests
If you have the ability
– Model User Access and timing to allow for
ABAP development
– Business Roles activities, template roles
are a great alternative
that allows you to
automatically add roles
based on attributes and
perform validations on
the requested access. To
enable template roles,
you must implement the
GRAC_TEMPLATE_ROLE
BAdI.
ACCESS REQUEST TOOLS (CONT.)

• Template Requests
– Can be used to build a pre-populated access request for users
to select
– Pre-populate access request with roles, request, type, user
information, etc.
– Can specify a default EUP ID to be used for the template
Pros:
• Simple process for new users if they know
Cons: which template to select
• Cannot restrict who can make changes to • Provides additional flexibility for users to
other templates remove/add additional roles to
• Roles will be sent to all role approvers for the request
approval
• Time consuming task to set up
• Can be difficult for users to know which
template to use
ACCESS REQUEST TOOLS (CONT.)

• Model User Access

– Functionality can be used to set up a user with the same access as
another user. This is most effective by setting up “template users” in the
system that have the access needed for a specific position that end
users can copy to their ID.
Pros:
• Simple process for users needing the same
Cons: access as the template ID or another user
• Can lead to excessive access if using to • Provides additional flexibility for users to
copy other users remove/add additional roles to
• Can remove access a user currently has if the request
the model user does not have the same
roles assigned
• Can allow circumvention of
request restrictions
ACCESS REQUEST TOOLS (CONT.)

• Business Roles
– Business roles are “virtual” containers that only exist in GRC. These roles
are searchable from the role search menu within an access request and
can contain roles for
multiple systems.

Pros:
• Business friendly names Cons:
• Users granted all access associated with the • No native reporting of user to BR
business role • No mass loading of user to BR
• Adding or removing a technical role can be • Not tied to a system – may cause
“pushed” to end users user confusion
• Can map one approver to the business role
• Flexibility to remove single role assignments
when needed
• Supported by User Access Review
ACCESS REQUEST TOOLS (CONT.)

• The most effective way to utilize business roles

are as role “templates” to be used in conjunction
with task-based roles.
– Business roles should be “SoD free”.
– Built with the core roles for a position at the
“local level” to include organizational levels
needed and to route to approvers familiar with
the user and the access contained in the role.
– Review business role approvers with the task
role owners to confirm they approve of these
users approving access to the roles
they “own”.
– Can utilize your user mapping to build
business roles.
– Should utilize the detailed description field to
clearly document what the role allows users to
do (in business language) and who the role is
intended for.
– Idle target state – 80/20
ACCESS REQUEST TOOLS (CONT.)

• Default Roles
– You can set up logic to automatically add roles to a request based
on set request or role attributes
– You can choose whether default roles are based on role attributes
or request attributes or both
• Role Attributes – Based on attributes or master data elements
of the roles selected by the user. Default role is added to the
request immediately.
• Request Attributes – Based on attributes within the header
data of the request. Default roles are not added until after
request submission.
• Due to limited logic, best if used for “general end user” type roles or
enabler roles based on request attributes.
WHAT WE’LL COVER

• Common Challenges
• Approver Experience Enhancements
• Customizing Access Request Views
• Utilizing BAdIs To Enhance GRC
• Implementing an Effective Role Design Strategy
• Custom Reporting
• Modifying GRC AC User Interface
• Help Center
• Request Mitigation Policy
• Wrap-up
BUILD CUSTOM REPORTING

• There are many options to build custom reporting in GRC such as:
– Custom Report Development
This request status report is very confusing,
– BW Integration how do I figure out who needs to approve
my request?
– Crystal Reports
• There is another simple, quick alternative if the options above are not available to
you, SQVI queries!
– Relatively simple to build
– Transportable
– Can build security around the reports
– Can be built into the GRC NWBC view as an application

Is a standard report just missing one key field that your business users need? You can
add a column in a standard report utilizing view cluster ‘VC_GRFNREPCOLUMNSC’ via
SM34. Just be sure to check it after an upgrade/applying OSS notes.
BUILD CUSTOM REPORTING (CONT.)

• An example of the most frequently requested report is a more detailed

“Request Status” report that shows the status of the request and the
outstanding approvers.
– Provided reporting functionality requires a user to dig through lengthy,
technical audit logs to find answer a simple question – “Where is
my request”?!?
BUILD CUSTOM REPORTING (CONT.)

• You can build reports to fill some of the missing gaps in business role
reporting, such as:
– Business role to user report
– Single roles provisioned without a business role (helpful during
periodic reviews)
– Report showing which approver approved role assignments
– Business role to t-code report

In addition to creating a custom report as shown in the take home materials, you
could also create a custom report by utilizing view cluster VC_GRFNREPCUST via
SM34 and add to the desired Launchpad as a Web Dynpro ABAP application.
WHAT WE’LL COVER

• Common Challenges
• Approver Experience Enhancements
• Customizing Access Request Views
• Utilizing BAdIs To Enhance GRC
• Implementing an Effective Role Design Strategy
• Custom Reporting
• Modifying GRC AC User Interface
• Help Center
• Request Mitigation Policy
• Wrap-up
MODIFYING GRC AC USER INTERFACE

• Introduction to GRC AC Security

– GRC AC 10.0 is an ABAP based system Launchpads
and uses standard SAP NetWeaver®
authorization system.
• Security roles are maintained
through PFCG and assigned directly
to user master records – i.e., SU01.
• SAP NetWeaver Business Client

Applications
(NWBC) is the “front-end” user
interface and is accessed via
internet browser.
• Security roles are maintained
through PFCG on the “backend” –
SAP GUI.
• Roles and authorizations within
them control what is visible and
what the user can do within each
application (Web Dynpro) in NWBC.
MODIFYING GRC AC USER INTERFACE (CONT.)

• There are multiple options to customize the user interface in GRC

• PFCG role menu structure
• PFCG role authorizations
• Modify Launchpads

When removing applications from end user views, best practice is to attempt to
remove them by utilizing role authorizations first. If the authorization is shared with
an application the user needs, then you may need to customize the Launchpad.
MODIFYING GRC AC USER INTERFACE (CONT.)

• PFCG role menu structure

• The Menu tab of a PFCG role and the
folders within it control the Work
Centers (folders) that are displayed
in NWBC
• Does not provide authorizations
• Contents of each standard SAP
delivered work center can be modified
by changing the Launch Pad
(next section)
MODIFYING GRC AC USER INTERFACE (CONT.)

• PFCG role menu structure (cont.)

You can also directly add individual web

dynpro applications in place of a launch pad
MODIFYING GRC AC USER INTERFACE (CONT.)

• PFCG role authorizations

– Each application shown under the Launchpads is controlled by an
associated authorization object.
– For example, cross application authorization object CA_POWL restricts
access to the entire POWL* iViews within the NWBC tabs (similar to
S_TCODE) for some applications.

*POWL – Personal Object Work List

MODIFYING GRC AC USER INTERFACE (CONT.)

• PFCG role authorizations

– While restricting access to certain types of sensitive reports, such as
Firefighter Log reports, is controlled by authorization object GRAC_REP.
MODIFYING GRC AC USER INTERFACE (CONT.)

• So now, you may be asking yourself, “How do you determine the

relationship between authorizations and the 120+ GRC
applications?”

Please don’t
Trial and error?
say ST01!
Am I actually
going to have
to read the SAP
security guide?
MODIFYING GRC AC USER INTERFACE (CONT.)

• The below tables can be joined via SQVI to create a query to pull the
relationship between each application and the related
authorization object(s)!

I cannot even
begin to show my
excitement…
MODIFYING GRC AC USER INTERFACE (CONT.)

• Be careful when removing authorizations to hide links as these may

control actions users can perform within the application and also
may be shared with other applications.
MODIFYING GRC AC USER INTERFACE (CONT.)

• It may be required to customize the end user interface to further restrict

access where it is not possible via authorizations alone –
– Authorization object GRAC_BGJOB with ACTVT = 03 makes the following
two applications visible.
• Only viewing the jobs – “Background Jobs” and not scheduling –
“Background Scheduler” is desired.

Access may be restricted by creating

a custom Access Management
Launch Pad without the link
“Background Scheduler”.
MODIFYING GRC AC USER INTERFACE (CONT.)

• Modifying a Launch Pad

– Performed under t-code
LPD_CUST
– Allows you the ability to add,
hide, or change applications
shown under the Launch pad
(i.e. My Home tab).
– Can also rearrange the order /
layout of the applications
shown.

You should never modify the SAP provided Launchpads, but rather copy an existing Launchpad
using the “Save As” feature and modify to your requirements. If you are creating a new work
center, you will need to create the associated Web Dynpro components, associate them to a
Launchpad, and associate the Launchpad to a PFCG role.
WHAT WE’LL COVER

• Common Challenges
• Approver Experience Enhancements
• Customizing Access Request Views
• Utilizing BAdIs To Enhance GRC
• Implementing an Effective Role Design Strategy
• Custom Reporting
• Modifying GRC AC User Interface
• Help Center
• Request Mitigation Policy
• Wrap-up
HELP CENTER

• The Help Center is a very useful tool that can be utilized to guide and assist users
through various GRC tasks, such as requesting access.
– The content within the help center can be configured to be application specific
(only shows for defined applications) or cross application (shows for
all applications)
• The four sections included
within the help center include:
– Notes
– Frequently Asked Questions
– Worth Knowing
– Learning Content
HELP CENTER (CONT.)

• Within the current view, the user can access the Help Center to
obtain content-specific assistance with the task they are performing.
HELP CENTER (CONT.)

• Note section:
– Allows users to add personalized notes.
– Notes are application-specific and will only display in the application
they were made (i.e., Access Request notes would only be viewable
through accessing the help center within the access request
submission screen).
– Notes are user-specific and cannot be viewed by other users.
HELP CENTER (CONT.)

• Frequently Asked Questions section:

– Allows users to select a question to expand the answer.
– Ability to add questions is based on authorizations of the user.
– Questions can be application specific or cross-application.

To authorize users to manage Help Center content centrally (cross-application), they will need
access to S_TABU_DIS (auth group SHC) and S_WDHC_ADM (Action “A”). SAP provided role is
SAP_BC_WDHC_ADMINISTRATOR.
HELP CENTER (CONT.)

• Worth Knowing section:

– Can provide links to helpful information, such as SAP Help or internal
documentation (SharePoint).
– Click the link opens the URL.
– Links in this section can be application specific or cross-application (or both).
HELP CENTER (CONT.)

• Learning Content section:

– Can provide links to training
documentation created for the
application (i.e., link to
SharePoint).
– Links in this section can be
application specific or cross-
application (or both).

You can translate help center content via t-code SHC_TRANSLATION. To authorize users to
translate Help Center texts, they will need access to S_WDHC_ADM (Action “T”). SAP provided
role is SAP_BC_WDHC_TRANSLATOR.
WHAT WE’LL COVER

• Common Challenges
• Approver Experience Enhancements
• Customizing Access Request Views
• Utilizing BAdIs To Enhance GRC
• Implementing an Effective Role Design Strategy
• Custom Reporting
• Modifying GRC AC User Interface
• Help Center
• Request Mitigation Policy
• Wrap-up
REQUEST MITIGATION POLICY

• When routing requests with SoD conflicts contained within them,

there may be some instances where risks do not require mitigation,
such as non-critical, reporting-only risks.
• The mitigation policy feature allows you to define logic within GRC
you can use to drive the behavior of the approval process based on
the attributes (i.e., risk level) of the risk identified during the risk
analysis performed for an access request.
– This allows you specify which risks require mitigation and which
risks do not require mitigation.
REQUEST MITIGATION POLICY (CONT.)

• Prior to implementing a mitigation policy, a risk classification system

needs to be clearly defined in order to group the risks to their
mitigating control requirements.
Definition Mitigating Control Required?
The functions being performed are directly next to each other in the
Critical

N/A
business process and the combination of activities results in the risk of a
financial reporting misstatement / fraud. (No users should have this access)
The functions being performed are directly next to each other in the
business process and there exists an advantage in perpetrating fraud for Yes
High

personal gain or altering revenue.

There exists a separation in the business process for the
Medium

duties/functions being performed; however, fraud is more attractive

Yes
than that of a low level risks and may result in personal gain or a
potential impact to revenue.
There exists a large separation in the business process for the functions
being performed and there are multiple areas where collusion would be
Low

No
necessary to perpetrate fraud. The resulting fraud is not attractive and
there exists no potential for personal gain.
REQUEST MITIGATION POLICY (CONT.)

• To use request mitigation policy, it is recommended that you set several

configurable items to the following settings:
– Parameter 1072 (set under “Maintain Configuration Settings” in SPRO), which
requires that critical risks be mitigated prior to approving an access request,
should be set to ‘Yes’.

– Within MSMP workflow, for the stage in your approval workflow that is
responsible for mitigation assignments / remediation, ‘Approve Despite Risk’
should not be checked and ‘Risk Analysis Mandatory’ should be set to ‘Yes’.
REQUEST MITIGATION POLICY (CONT.)

• To set up request mitigation policy, you must first determine the associated BRF
Function ID, which is noted under ‘Maintain AC Applications and BRFplus Function
Mapping’ in SPRO.

• Once you have the BRFplus ID, navigate to BRFplus (t-code BRF+), and enter the ID
under Workbench > Open Object.

The first time you access BRF+, make sure to change your User Mode to ‘Expert’.
REQUEST MITIGATION POLICY (CONT.)

• Create a decision table and implement your business logic. In this example, we are
enforcing mitigating control assignments for all risk levels except for ‘Low’.
• In the ‘MITIGATE_RISK’ column, set the value to ‘1’ to enforce mitigations and ‘2’ to
not require mitigations.

• Save and activate your newly created decision table and the associated
function. Under the function, you can simulate values to confirm that the
appropriate mitigation policy is being enforced.
WHAT WE’LL COVER

• Common Challenges
• Approver Experience Enhancements
• Customizing Access Request Views
• Utilizing BAdIs To Enhance GRC
• Implementing an Effective Role Design Strategy
• Custom Reporting
• Modifying GRC AC User Interface
• Help Center
• Request Mitigation Policy
• Wrap-up
WHERE TO FIND MORE INFORMATION

• http://www.pwc.com/us/en/sap-implementation.html
– PwC’s SAP Implementation Services
• http://scn.sap.com/docs/DOC-1570
– Harleen Kaur, “AC 10.0 – Business Role Management” (SAP
Community Network, August 2011)
• www.sdn.sap.com/irj/bpx/grc
– SAP Governance, Risk, and Compliance Solutions, Guides,
and Applications (Designing your SAP security processes)
7 KEY POINTS TO TAKE HOME

• Simplifying and enhancing your access request process is not a simple task!
• An effective, healthy role design is a MUST before attempting to roll out
the GRC Access Request Management (ARM) Module.
• A mix of task based “technical” roles and business role “templates” is a
good way to strike a balance between end user experience and flexibility in
your role design.
• You can meet reporting requirements without extensive
customization/integration with reporting tools.
• The Help Center is a great tool, don’t forget about it!
• Prior to implementing a mitigation policy, a risk classification system needs
to be clearly defined.
• Integrating GRC with an accurate HR data source can lead to further
automation in the request process.
YOUR TURN!

How to contact me:

David Denson
[email protected]

Please remember to complete your session evaluation

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.

©2016 PwC. All rights reserved. PwC refers to the US member firm or one of its subsidiaries or affiliates, and may sometimes refer to the
PwC network. Each member firm is a separate legal entity. Please see www.pwc.com/structure for further details.
This content is for general information purposes only, and should not be used as a substitute for consultation with professional advisors.
FOLLOW US

Thank you for your time

Follow us on at @ASUG365