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

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 too many links and I cannot find the one that I need! This is a reporting risk, do all of these really need to be routed to me for mitigating control assignments? Why do I have to run a risk analysis in every request / when I make a change to the request? I do not have the information I need to make an informed decision whether this user 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 in my approval of these types of requests? I need additional field XX in these reports to properly understand them. 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? What is this role being requested and why is it coming to me?

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 request for access in GRC 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. Is preapproved criteria met? 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. Valid request for access 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.

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

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.) Customize Access Request Views

CUSTOMIZING ACCESS REQUEST VIEWS (CONT.) What is IdM? Identity Management (IdM) tools are enterprise-wide, crossapplication 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 *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.

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

IMPLEMENTING AN EFFECTIVE ROLE DESIGN STRATEGY An effective, healthy role design is a MUST before attempting to roll out the GRC Access Request Management (ARM) Module. Who What Where 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. Effective SAP role design 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 could have more automation and information Role Change Management needs risk and quality controls Needs improved emergency support process 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 Security & Provisioning Processes SAP Role Architecture Org Structure & Governance Effective SAP Security Design Misalignment of IT vs. Business Objectives Needs Strategic Security Design Decisions Needs Role or Security Design Ownership 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

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 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. 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 Supported by User Access Review Cons: No native reporting of user to BR No mass loading of user to BR Not tied to a system may cause user confusion

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.

BUILD CUSTOM REPORTING There are many options to build custom reporting in GRC such as: Custom Report Development BW Integration Crystal Reports This request status report is very confusing, how do I figure out who needs to approve my request? 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.

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 Applications

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? Trial and error? Am I actually going to have to read the SAP security guide? Please don t say ST01!

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.

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 crossapplication (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.

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.

Medium 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. Low High Critical Definition 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. 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. 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. 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. Mitigating Control Required? N/A (No users should have this access) Yes Yes No

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.

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 david.j.denson@pwc.com 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