Expert Tips To Simplify And Automate
Your User Access Request Process
David Denson
PwC
•
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.
•
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
•
Some of the common challenges/frustrations experienced by end
users while requesting access include:
COMMON CHALLENGES – REQUEST ACCESS
There are so many fields I have to enter data in and tabs to navigate, this takes forever!
I am transferring to a new job, I’ll just copy Bob’s access and I should be fine.
This request status report is very confusing, how do I figure out who needs to approve my request?
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?
I am a new user and there are so many roles and systems for me to choose, I have no clue which roles I need …
•
Some of the common challenges/frustrations experienced by end
users while approving access include:
COMMON CHALLENGES – APPROVE ACCESS
What is this role being
requested and why is it coming to me?
I do not have the information I need to make an informed decision whether this user actually needs access to this role. Why do I have to run a risk analysis in every
request / when I make a change to the request?
This is a reporting risk, do all of these really need to be routed to me for mitigating control assignments?
I get so many requests for approval, many of which are mapped to the user’s job position. What value is there in my approval of these types of requests?
I need additional field XX in these reports to properly understand them.
Navigating GRC is very difficult as there are too many links and I cannot find the one that I need!
The approval form is cumbersome and does not readily display the information I need.
The user selected every available role, why is it my responsibility to analyze this request?
•
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
• 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.
APPROVER EXPERIENCE ENHANCEMENTS
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.
•
Exception Based Routing
–
Custom rules can be developed for use during approval workflow
to perform validations on requested access
APPROVER EXPERIENCE ENHANCEMENTS
(CONT.)
• Selectable roles can be limited based on a user’s organization or position, allowing them to only select from roles that are mapped to their area. User submits
request for access in GRC
• Based on the user’s organization / position, are the pre-approved requirements met for the user to have access to the requested role? If not, requests can be routed to exception approvers that can assist the user with requesting
appropriate access or determining if the request is a valid exception. Is
pre-approved criteria met?
• Based on the validation checks, user has submitted a valid request for access. These requests can then be routed to the approver for approval or
auto-provisioned. Valid request
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 Keywordfor 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’.
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.
•
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?
– Through GRC form customization, we can realize the following
benefits:
• Ease the requesting process by reducing the time it takes to submit a request
• Present only relevant
information to the user, reducing user confusion and frustration during the request process
• Reduction in the data points needing to be reviewed eases the review process for approvers
• Deliver all required information the reviewers need to make an informed decision
I do not have the information I need to make an informed decision whether this user
actually needs access to this role.
There are so many fields I have to enter data in and tabs to navigate, this
takes forever!
The approval form is cumbersome and does not readily display the information I need.
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.)
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
–
Single sign-on
–
Ability to customize forms and
functionality to enhance the
user experience
“Virtual” Composite grouping for A/P
Clerk
Underlying Roles (SAP and/or Non-SAP) Flexibility to select
some or all of the underlying tasks
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
Benefits
• Increased end user adoption and improved user satisfaction due to dramatically
improved user experience
• SAP Fiori apps are multi-platform without programming additional screens -> a very attractive low TCO option
• Leverages existing SAP investments by providing instant value to all employees and processes
Drawbacks
• SAP Fiori is not a mobile platform. With SAP Fiori, you do not see terms like offline
synchronization management, device
management etc. which are functionalities that a typical mobile platform provides
• SAP Fiori apps are not native to the device they are running on
• SAP backend only – currently, Fiori is designed to run with SAP backend only
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
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.
•
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
• GRFN_MSMP_END_OF_PATH_NOTIF – End of Path Notification
• GRFN_MSMP_APPROVER_VALID_ESI – Approver Validation
• GRFN_MSMP_ESCALATE_OVERRIDE_ES – Escalation Override
• GRFN_MSMP_ESCAPE_OVERRIDE_ES – Escape Override
• GRFN_MSMP_REQUEST_FINISHED_ES – Request Finished Extension
• GRAC_TRG_VERIF – Training Verification
• GRAC_TEMPLATE_ROLE – Creation of Template Roles
• GRAC_BUSINESS_SHELL_ROLE – Business Role Provisioning Override
• GRAC_ACREQ_ITEM_VALIDATE – Override Role Assignment Validation for Provisioning Actions
BAdIs allow you to customize the application without making core code modifications, reducing the risk of impacting the customization when applying fixes or Support Pack upgrades.
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.
•
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
• An effective, healthy role design is a MUST before
attempting to roll out the GRC Access Request Management (ARM) Module.
– Why?
• Environments with large numbers of unused roles, high t-code duplication between roles, and
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
Who Effective SAP role design What WhereIMPLEMENTING AN EFFECTIVE ROLE DESIGN
STRATEGY (CONT.)
• Misalignment of IT vs. Business Objectives
• Needs Strategic Security Design Decisions
• Needs Role or Security Design Ownership
• User provisioning process could have more
automation and information
• Role Change Management needs risk and quality controls
• Needs improved emergency support process Security & Provisioning Processes Org Structure & Governance SAP Role Architecture Effective SAP Security Design
• Complex Security Design
• Needs more flexibility to respond to ongoing changes
• Needs scalability to grow with organization
• Needs more efficient Role Build Approach
• Needs Documentation of Security Control Points
• Inherent Segregation of Duties Risk
• Management KPIs for Security Design are not established
• Needs automation for ongoing monitoring and recertification procedures
• Needs improved SOD and/or Mitigating control frameworks
Key Challenges
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:
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
– Model User Access
– Business Roles
If you have the ability and timing to allow for ABAP development 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
Cons:
• Cannot restrict who can make changes to
other templates
• Roles will be sent to all role approvers for
approval
• Time consuming task to set up
• Can be difficult for users to know which
template to use
Pros:
• Simple process for new users if they know
which template to select
• Provides additional flexibility for users to
remove/add additional roles to the request
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.
Cons:
• Can lead to excessive access if using to
copy other users
• Can remove access a user currently has if
the model user does not have the same roles assigned
• Can allow circumvention of
request restrictions
Pros:
• Simple process for users needing the same
access as the template ID or another user
• Provides additional flexibility for users to
remove/add additional roles to the request
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.
Cons:
• No native reporting of user to BR
• No mass loading of user to BR
• Not tied to a system – may cause
user confusion Pros:
• Business friendly names
• Users granted all access associated with the
business role
• Adding or removing a technical role can be
“pushed” to end users
• Can map one approver to the business role
• Flexibility to remove single role assignments
when needed
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.
•
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.
•
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
• There are many options to build custom reporting in GRC such as:
– Custom Report Development
– BW Integration
– 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
BUILD CUSTOM REPORTING
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.
This request status report is very confusing, how do I figure out who needs to approve my request?
• 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”?!?
•
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
BUILD CUSTOM REPORTING (CONT.)
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.
•
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 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 (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.
Launchpads
Applic
•
There are multiple options to customize the user interface in GRC
•
PFCG role menu structure
•
PFCG role authorizations
•
Modify Launchpads
MODIFYING GRC AC USER INTERFACE (CONT.)
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.
• PFCG role menu structure
MODIFYING GRC AC USER INTERFACE (CONT.)
• 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
• PFCG role menu structure (cont.)
MODIFYING GRC AC USER INTERFACE (CONT.)
You can also directly add individual web dynpro applications in place of a launch pad
• 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.
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.
•
So now, you may be asking yourself, “How do you determine the
relationship between authorizations and the 120+ GRC
applications?”
MODIFYING GRC AC USER INTERFACE (CONT.)
Trial and error? Please don’t say ST01! Am I actually
going to have to read the SAP security guide?
•
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)!
MODIFYING GRC AC USER INTERFACE (CONT.)
I cannot even begin to show my excitement…
•
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.
• 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.
MODIFYING GRC AC USER INTERFACE (CONT.)
Access may be restricted by creating a custom Access Management
Launch Pad without the link “Background Scheduler”.
• 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.
MODIFYING GRC AC USER INTERFACE (CONT.)
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.
•
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
• 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
•
Within the current view, the user can access the Help Center to
obtain content-specific assistance with the task they are performing.
• 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.
• 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.
HELP CENTER (CONT.)
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.
• 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).
HELP CENTER (CONT.)
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.
•
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
•
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.
•
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.
REQUEST MITIGATION POLICY (CONT.)
Definition Mitigating Control Required?
The functions being performed are directly next to each other in the business process and the combination of activities results in the risk of a financial reporting misstatement / fraud.
N/A
(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 personal gain or altering revenue.
Yes There exists a separation in the business process for the
duties/functions being performed; however, fraud is more attractive than that of a low level risks and may result in personal gain or a potential impact to revenue.
Yes
There exists a large separation in the business process for the functions being performed and there are multiple areas where collusion would be necessary to perpetrate fraud. The resulting fraud is not attractive and there exists no potential for personal gain.
No M e d iu m Low Hi gh Cr iti ca l
• 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.
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.
•
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
•
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)
WHERE TO FIND MORE INFORMATION
• 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.
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.
Disclaimer
©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.
