GRC Training Class

Auditing:

Generally, SAP performs an audit every 6 months (April and November) or yearly once, auditors from
SAP will perform the audit to ensure the company/organization is following rules and regulations, and
policies, auditors can check the approvals for every activity performed in SAP, financial transactions,
balance sheet, etc.,

SOX Compliance Act:

Enron (Natural Gas 1985-2001), WorldCom (Telecom Service 1983-2002), etc., have committed financial
frauds and went bankrupt, due to which organization got closed, and the CEO, CFO, and Employees who
were involved in the fraud have been sentenced to jail and thousands of employees lost jobs, Investors
lost the money, etc.,

SOX act was introduced in 2002 by the US-based congress government and was signed into law by
President George W. Bush on July 30, 2002, and was sponsored by Senator Paul Sarbanes & Michel G.
Oxley to protect companies from financial fraud, SOX compliance is an Act that states that every
company/organization should be responsible to provide accurate proof of their financial reports during
auditing.

 A mechanism that is defined to manage risk more efficiently and to ensure that the risk is not
open.
 Making the management liable for any kind of fraud in the organization
 Few Sox acts 302, and 404 are important from AC (access control) perspective.
 302 act states that the chief executive officer (CEO) and chief financial officer (CFO) must review
and sign the financial reports quarterly and make sure that the company is following rules and
regulations as per the SOX compliance act.
 SOX Section 404 specifically focuses on internal controls over financial reporting and also this act
states that every company should provide evidence documents for the financial activities
(approvals, financial data, etc.,) during auditing.

1. Introduction to GRC, why GRC is required, and its usage:

GRC – Governance, Risk, Compliance:

Governance:
Governance refers to the establishment and enforcement of policies, procedures, and controls to guide
and regulate the organization's activities. GRC dictates how activities should be conducted and how
decisions should be made.

EX: User management, outlining the criteria for creating user IDs. These policies may include rules
regarding naming conventions, access levels, and the information required for user roles, etc.,

 SAP GRC is a powerful SAP security tool that is used to ensure your company meets data security
and authorization policies.
  Every organization will follow some rules and regulations to run the business efficiently and
responsibly to avoid frauds from happening.
 GRC is a set of solutions and products that helps to manage enterprise resources in a way that
minimizes risk, build trust, and lowers compliance cost.
 When a risk is identified, a proper Risk Management approach is defined.
 Priority is given to risk removal (remediate), If a risk can’t be removed from the system, then a
proper mitigation plan is created.
 GRC will make sure the organization is following Rules & Regulations, Guidelines, Acts.

Advantages:

 To ease the day-to-day security activities and to simplify the day-to-day reports for managers
and auditors, for that SAP introduced GRC.
 GRC will identify authorization risks in ABAP backend systems to prevent users to commit fraud
because we have a risk database that comes with GRC installation.
 To reduce the cost of continuous compliance and control

Risk:

Any action that causes financial loss or process disruption/deviation will be considered as a risk.

A user should not be able to execute certain actions or certain combinations of actions, a user should
only be allowed to perform actions within users’ roles and responsibilities.

Since we have more than 50K actions (T-Codes), some actions are risk in nature; to define them as Risks
we use the GRC system.

EXs of Risks:
 Creation of vendor & Make payment to the vendor is a Risk.
 Creation of Purchase order & Post-Good Receipts is a risk.

These risks need to be segregated; no user should have access to two critical activities in the business
process.

Note:
1. Action – T-code
2. Permission – Authorization Object

Note: GRC is having a policy, which is to make backend/remote/plugin systems “GET CLEAN & STAY
CLEAN”, with the help of ARA component we can make backend system to GET CLEAN and with the
help.
EAM, BRM, and ARM components we can keep backend system to STAY CLEAN
2. Software Components and plugin’s required in GRC system to connect to backend systems :

GRCFND_A (GRC Foundation for ABAP) GRC Frontend System

Connectors (RFCs)

ECC /S4 Hana BW CRM

Backend System Backend System Backend System

a. GRCFND_A – GRC Foundation for ABAP (GRC), by default GRCFND_A will get you AC (access
control), PC, and RM components. (For PC and RM, the respective content should be loaded
additionally which is available in the Service Market Place (SMP)

b. GRCPINW – It will connect the NetWeaver based systems – ABAP systems (other than HR) – It
needs to be available in both GRC and S4 HANA project.

c. GRCPIERP – Connect the HR system and in-case if PC is implemented, this plug-in is required in the
ECC box as well, better to Implement both the plug-ins in the ECC box even though HR system is
present or not for best practice – to connect to backend HR system.

3. Different types of components in GRC in AC (Access Control) and its versions :

GRC Access Control: The primary solution set in the SAP GRC Portfolio. It has 4 components.

 ARA – Access Risk Analysis

 EAM – Emergency Access Management
 ARM – Access Request Management
 BRM – Business Role Management

VIRSA (ABAP) SAP GRC 5.0, 5.2, and 5.3 SAP GRC 10.0, 10.1, 12
(Java based version) (ABAP)
Compliance Calibrator (CC) Risk Analysis & Remediation ARA – Access Risk Analysis
(RAR)
Fire-fighter Super User Privilege EAM – Emergency Access
Management (SPM) Management

Access Enforcer (AE) Compliant User Provisioning ARM – Access Request

(CUP) Management

Rule/Role Expert Enterprise Role Management Business Rule Management

(ERM) (BRM)
GRC 10.0. 10.1, 12 Advantages:

 Unified solution page – You never need to login to the applications separately in GRC 10.0 and
higher versions whereas in GRC 5.3 and in lower versions we have separate system for each
component, so it becomes difficult to configure GRC system. The latest version of GRC is GRC 12.0
 Role based FFID is introduced by using decentralized option in GRC EAM from 10.0 versions
onwards.
 It is easy to configure all the components and use GRC system.
 The 4 components are inter-linked. There is a strong relationship between these components.
 MSMP with BRF+ Workflows for access requests has been introduced in GRC 10.0 version
onwards.
 It supports HANA (HANA DB, S/4 HANA)

4. Best Approach for GRC implementation: ASAP Methodology

ASAP – Accelerated SAP

GRC is not a software version that can be installed and used directly. Various configurations are required
that needs inputs from the business.

a. Project Preparation – In this phase we will Identify the scope, team (stakeholders) who are
involved in the implementation of the respective application, conduct meetings with the
stakeholders (investors, employees, customers, suppliers, communities, governments, or trade
associations. An entity's stakeholders can be both internal/external to the organization, identifying
clear project objectives.

b. Blue Printing – In this phase we gather requirements and define ASIS process (Current Process
following in the system), and TOBE process (Future process to be followed in system), every small
requirement will be captured, and this document will be reviewed and accepted by the client.

c. Realization phase – In this phase we will start building the system. First development system will
be configured and in parallel the QAS will also be setup for testing purpose.

d. Testing – Roles will be tested in different testing phases like UT, SIT, UAT (S4 Hana Perspective),
for GRC we will have only one round of testing.
 e. Final Preparation – In this phase we will prepare the Production System and do all the relevant
configuration (that are required directly in the production), will do a sanity check (Checking
weather initial configuration is working fine or not)

f. Go Live – In Go-Live, Users will start using the GRC application.

g. Support – We would be supporting the users, Hypercare support.

Differences between the waterfall methodology and agile methodology in SAP implementation

The main difference is that Waterfall is a linear system of working that requires the team to complete
each project phase before moving on to the next one while Agile encourages the team to work
simultaneously on different phases of the project.

Difference between greenfield and brownfield implementation?

While a Greenfield approach represents a complete reengineering—a new implementation of your SAP
ERP, a Brownfield approach is more like an upgrade—system conversion.

 Go Live can be either a “Big bang” or “Phased go-live”

 Big Bang – Where all the 4 modules go live at a time.
 Phased Go-live – 1-2 modules will go-live first, and once it is stabilized then the other modules will
go live. It can be in 2, 3, or 4 phases

Configurations
5. Different types of configurations:

a. Baseline configuration - (One time configuration)

b. Connector Specific configuration - (repetitive task that we do every-time to add/connect a new
system)
c. Application Specific configuration - Every application (component) should be configured as per
the business needs (whenever there a new business requirement then you can come back and
make configurations)

Baseline (one-time/Initial) configuration:

NOTE: Once the system is handover by the BASIS team, ensure that the GRCFND_A and the respective
plug-ins are installed in the systems.

Important NOTE: Majority of the GRC configurations are done in SPRO t-code, which prompts the
changes to be captured in a TR. If there is a change management process, ensure that you have at least
Multiple TRs handy.

a. Activate Applications (SPRO  IMG  GRC  General Settings  Activate Applications in

client

b. Activate ICF Services (Internet Communication Framework Services) (T-code – SICF)

Ensure to activate PUBLIC, BC, and GRC nodes and to active nodes for that we need to right click on the
service node and click on Activate service.

ICF services are required to be activated for the NWBC to function/work properly; every link in NWBC is
Web-Dynpro application.

c. Activation of BC Sets (T-code – SCPR20)

BC (Business Configuration) sets are pre-delivered configurations by SAP; we must activate BC sets
because it will update the GRC standard data to GRC standard tables.

We need to select the BC set and activate BC set using Activate BC set icon in SCPR20 t-code.
  Table SCPRACTP – it will show the activated BC sets in GRC system.
 Table SCPRACTR – it will show the tables in which BC sets data is updated.

d. Activation of SMICM services and Workflow Settings

SMICM  Activate HTTP and HTTPs

e. Creation of WF-BATCH user

We need to create a workflow background user to perform workflow related activities, since this user
will perform all workflow activities, we need to assign full access i.e., SAP_ALL, SAP_NEW profiles.

Connector Specific Configuration:

a. Create Connectors (RFC connections) (it is always recommend having a Bi-directional RFC
communication) (Means backend system to frontend system (GRC system) and vice-versa)

Backend system – Your ABAP stack system (For EX: ECC, BI, SRM, CRM etc.,)

NOTE: S_RFC and S_RFCACL authorization objects are not part of your SAP_ALL & SAP_NEW profiles. In-
case if you are assigning these composite profiles to the communication user, ensure to assign a
separate role with S_RFC, and S_RFCACL.

b. Maintain Connectors & Connection Types (SPRO  IMG  GRC  Common Component
Settings)

Define Connector Select the connection type (For EX: SAP) and then double-click
Define Connector. Add the newly created RFC connection here.
Define Connector Groups Connector Groups = Landscapes
Logical: Grouping of similar systems
Cross: Grouping of dissimilar systems
 Assign Connector to Connector Use this option to add the newly created connector to the
Group respective connection group

c. Maintain Connection Settings (SPRO  IMG  GRC  Common Component Settings)

In this step, we will have to define the Integration Scenarios, if you don’t integrate these Scenarios then
you can’t work with GRC components, so it is mandatory to integrate these scenarios to connectors,
here we will have to add connecters to integration scenario.

SAP GRC has 5 integration scenarios by default. They are:

AM _ Automatic Monitoring (AM) this scenario which is

required for process control.
AUTH _ Authorization Management (ARA)
PROV _ Provisioning (ARM)
ROLMG _ Role Management (BRM)
SUPMG _ Super User Privilege Management (EAM - Fire-fighter)

Note: It is recommended to add the connector (RFC Connection) to all the 4 integration scenarios
irrespective of the utilization

There are some inter dependencies on how the application handles some scenarios so it is required that
all the connectors to be used with GRC Access Controls should be associated with all 4 scenarios (PROV,
SUPMG, AUTH, ROLEMG)

Table: GRFNCONNSCNLK – to see the integration scenarios connected to the connector

d. Setup the GRC configuration parameters

Parameters define the way your application should function/work, for EX: Default values, settings etc.

To setup the parameters go-to SPRO  IMG  GRC  AC  Maintain configuration settings

NOTE: It is advised to add all the relevant parameters of component irrespective of the settings (default
value is also okay, if you are not going for custom value)

e. Maintain Connector Settings (SPRO  IMG  GRC  AC)

In this step, define the role of the connector (For EX: Development, or Quality etc.)

Add the newly created connector in this step and ensure to enable PSS (password self-service) in-case if
you want the users to automatically reset their password using the Password self-service portal.

f. Schedule the Synchronization Jobs (SPRO  IMG  GRC  AC  Synchronization jobs)

Authorization Sync By running Authorization Sync job, we will get all the
transaction codes, and the associated authorization
objects data into the GRC repository.
 Data from SU24 and from USOBX_C & USOBT_C tables

GRAC_PFCG_AUTHORIZATION_SYNC
Repository object Sync By running Repository object Sync job, we will get
Profiles, Roles, and User’s data.

NOTE: First time, you should run the repository object

sync job in Full Sync mode (Once the full sync is
successful, you can run the job every hour/day – based
on the business requirement in incremental sync mode)

Full Sync Mode: It will pull all the Profiles, Roles, and
User’s data (for the first time we need to run this)

Incremental Sync Mode: It will pull the data from the

last successful sync to the time we run the job.
(Ex: only new or changed users from the last execution)

GRAC_REPOSITORY_OBJECT_SYNC
Action Usage Sync By running Action Usage job, we will get all the t-codes
executed by users.

GRAC_ACTION_USAGE_SYNC
Role Usage Sync By running Role Usage Sync job, we will get all the roles
executed by users.

GRAC_ROLE_USAGE_SYNC

Note:

 Unless the Authorization sync job is successful, don’t run the repository object sync.

 Whenever you create users, roles or profiles and assignment to users you need to run
Repository Sync Job to fetch the data to GRC system.

 If we don’t maintain connector settings in AC, then SYNC jobs will not run properly so make sure
connector settings are properly maintained in SPRO.

Frequency of the jobs:

Authorization sync – In general, we run the Authorization sync once in a month.

Repository sync

 1st Time should be a Full sync.

 Full sync is scheduled once in a month.
  Incremental sync is scheduled at least once in a day (normally after your
PFCG_TIME_DEPENDENCY job)

PFCG_TIME_DEPENDENCY – User Comparison – It will remove the roles that are expired for the users.
Normally scheduled to run at 00:00 hours.

Jobs that need to be scheduled:

Application Specific Configuration:

EAM – Emergency Access Management

Introduction of EAM and its usage

 This concept is known as Fire-Fighter in VIRSA, Super User Privilege Management (SPM) in
GRC 5.3 and it got renamed as Emergency Access Management (EAM) from GRC 10.0
onwards, now we are in GRC 12.
 It is used to access critical t-codes/actions outside the user’s regular/normal access.
 EX: SCC4 (Client opening/closing) by basis team, SE38 (to debug the program in case of
bugs) by ABAP team

Different Types of users in EAM

a. Administrator:

 Admin will configure entire EAM component/application (GRC consultants)

 Admin will create owner, controller, FF (Fire-fighter), FFID
 Admin will map the FFID to owner, controller, FF (Fire-fighter)
 Admin will built/create the reason codes.

b. Owner:
  Owner is the responsible person to review the business justification and for approving the
FFID access to firefighter users.
 Owner can extend the validity period of FFID to FF

c. Controller:

 When FF carries/performs any t-codes using FFID, all logs will be displayed to controller in
NWBC, and we can even create a workflow for controller to receive the FF logs.
 Controller basically monitors all the logs and controller can question FF on any activity that
he finds risk on the usage of FFID.

d. FFID (Fire-fighter ID)

 FFID contains elevated access (Critical access) which are needed to be performed for critical
activities on need basis.
 FFID should be of user type “service”, because for service user password rules will not be
checked during login time, so it will not prompt to change the password. Whereas for Dialog
user password rules will be checked during login time, it will prompt to change the
password. User should not change the FFID password like their own user IDs, only
administrator can reset the password of FFID which is way SAP recommends creating FFID
with “Service” user type.

e. FF (Fire-fighter):

 FF is a normal dialog user in a system; FF is the one who requires FFID to carry out
emergency (critical) access, that FFID is decided by owner.
 2. SAP Standard roles for Admin, Owner, Controller, FFID, and FF.

Please refer below link or file.

SAP Standard roles in GRC.xlsx or SAP Standard roles in GRC File

3. Two Types of EAM:

Centralized and Decentralized (ID Based)

Centralized:

 FFID user will be created in backend systems (ECC, S4 Hana, BI etc.,) and that FFID access will be
assigned to users (FF) in GRC frontend system.
 User has to login to GRC system to use centralized EAM using t-code GRAC_EAM/GRAC_SPM
 Above t-code should be used by users to access EAM launchpad page, where users will be able
to see the FFIDs assigned to users, and users can login to FFID there.
 FF Owner, FF controller, Fire-fighter and their roles must be maintained in GRC system.
 FFID user and its roles must be maintained in the Backend/remote system.

Decentralized:

 User has to login to backend/remote system to use FF access using t-code /N/GRCPI/GRIA_EAM
  To enable the de-centralized EAM, we must set the configuration parameter 4015 to YES.
 Even though the Firefighting are de-centralized, the admin activities are still needs to be done
from the GRC system.
 Decentralized EAM can be used even if GRC is down, so it's recommended to have both
centralized and decentralized EAM.
 User can use FF access from the remote system itself, no need to login to (GRC) system.
 FF access must be just maintained in remote system.
 FF owner must be maintained just in GRC system to approve the FF access.
 FF controller must be maintained in both GRC and remote system.

4. Different ways of providing FF access, difference between ID based Vs. Role Based of providing
Fire-fighter access:

ID Based (FFID) Role-Based (FF Role)

 Only one user can use FFID at a  Multiple users can use the FF
time role

 Knows exactly when FFID is being  Difficult to differentiate

used as user must login through between FF tasks and normal
FFID tasks as no separate login is
required to use FF role.

 Better tracking of FF tasks, logs  Time consuming to track FF

through reports along with tasks as we will not have
reason codes specific log reports for FF tasks,
reason codes

 FFID is created in the remote  The Fire-fighter roles created in

system, and FFID can be assigned remote system; it will be
to users from GRC system (FFID assigned directly to users in
can be assigned in two ways – remote system.
manually from NWBC or by
raising ARM super user request)

 Reason codes are required in ID  No reason codes are required

based Fire fighting in role-based Fire fighting

 FF user needs to login to GRC  FF user can directly login to

system to use FFID with remote system and use FF role
GRAC_SPM/EAM t-code

Note: Drawback of using centralized EAM, if GRC system is down, we can’t use FFID (we can’t login to
backend systems using GRC system)

Please refer below link for more information.

https://www.linkedin.com/pulse/grc-ac-10-emergency-access-management-eam-basic-munish-kumar

5. NWBC t-code, work centres, application folders, application links:

 T-code NWBC: Net Weaver business client

 Different tabs are available in NWBC, and they are called as “Work centres”.
 In Work-Centre we will have “application folder, in application folder we will have
application links.

6. Mapping a user as owner, controller in GRC:

 We will have to define users as owner, controller in NWBC.

 For Owner: NWBC  Setup Work-Centre  Access owners application folder  Access
control owners application link  Go to create  Select user ID and select owner types 
Fire-fighting ID owner for ID based & Fire-fighting role owner for role based.
 For Controller: NWBC  Setup Work-Centre  Access owners application folder  Access
control owners application link  Go to create  Select user ID and select owner types 
Fire-fighting ID Controller for ID based & Fire-fighting role controller for role based.

7. Mapping of owner to FFID:

 NWBC  Setup Work-Centre  Emergency Access Assignment  Owners  Go to create

 Select FFID  Assign owner to FFID.

8. Mapping of controller to FFID:

 NWBC  Setup Work-Centre  Emergency Access Maintenance  Controller  Go to

create  Select FFID  Assign controller to FFID.
9. Different ways controller can receive the logs of FFID.

 Email, workflow, log display

 Email: will send an email notification to the Controller with a link to the Firefighter Session
log
 Workflow: Workflow will create a work item in the Controller Work Inbox. This is the one we
need to choose for making the submission of logs review available for the Controller.
 Log Display: means the Controller will personally run the report.

10. Mapping of FFID to normal user (Firefighting):

 NWBC  Setup Work-Centre  Emergency Access Maintenance  Fire-fighter  Go to

create  Select FFID  Assign Fire-fighter to FFID

11. Creation of reason codes:

 NWBC  Setup Work-Centre  Emergency Access Management  Reason Codes  Go to

create  Define reason codes along with description.
EX:
Development/Debug task
AMS activity
Payroll activities
Month-end closing activity

12. Usage of additional activity, message box options in EAM Launchpad:

 Additional Activity Box: After logging into FFID, in case if we want to perform extra t-codes
which are not maintained initially in actions column, we can come back and we can enter
the details in additional activity box.

 Message Box: when someone is already using FFID, since you will not be able to login to
same FFID as only FF user can login to FFID at a time, that time you can use this message box
option to send message to FF user as it is emergency for me etc.,

 Note: Admin can also end the FF session and we can give that FFID to someone else in
emergency cases (but it is not recommended to close any FFID session without consulting
with FF user)

13. Traffic Signals in EAM launchpad:

 Red: FFID is in use by FF (somebody is using FFID)

 Yellow: Issue with password, user inactive status for FFID
 Green: No one is using FFID, we can login to FFID

14. Tables related to EAM:

 GRACOWNER: We can see all owners, controllers, FFID’s, mitigation monitor, mitigation approver
etc., maintained in GRC centrally for all components (EAM, ARA, BRM, ARA)
 GRACFFOWNER: We can see owners for FFID.
 GRACUSER: We can see all FFID’s here.
 GRACFFUSER: We can see FFID’s assigned to FF and its owners.
 GRACUSERCONN: To find out the user ID against connector.

15. Set up of EAM Parameters in GRC & Backend system.

Please refer below link or file.

GRC Parameters.xlsx

File: GRC Parameters

Note: Make sure you maintain all the parameters maintained in GRC in Backend system as well and for
EAM application make sure to maintain FFID role in below node
SPRO IMGGRCAccess ControlEmergency Access Management

16. Important parameters in EAM:

 4000 Parameter:

1) We can decide whether we use ID based Fire-fighter or Role based Fire-fighter.

2) If the parameter value is set to “1” then ID based Fire-fighter is used, if the parameter value is set
to “2”, then role-based Fire-fighter is used.

 4010 Parameter:

There would be many users in backend system (plugin), to differentiate FFID users from normal
users, we assign default role SAP_GRAC_SPM_FFID in backend (plugin) system.

 4015 Parameter:

1) This parameter is introduced in GRC 10 service pack 10 (SP10)

2) This parameter decides whether we use Centralized EAM or Decentralized EAM
3) If the parameter is set to “YES”, then decentralized is used and FF can directly use logon
pad in backend (plugin) system if ID based, if role based, FF could use roles.

17. Configuration of EAM parameters needed for role-based FF:

 The configuration parameters 4003, 4004, 4005, 4006 are required for role-based FF as well
as ID based FF.
  If the parameters set to “YES”, role-based log update program will retrieve the
corresponding logs to GRC from plugin system using Fire-fighting log sync job.

18. Different types of reports in EAM:

 NWBC  Report & Analytics  Emergency Access user Management reports here we will
have 6 different reports available.

a. Consolidated log report:

 When we configure controller with log display option, all the logs executed by the FF will be
shown here.
 To update all the transactions performed by the FF using FFID to GRC, we need to perform
“Fire-fighting Log Sync” Job.
 When we configure controller with Workflow or email option and to update all the
transactions performed by the FF using FFID to GRC, we need to perform “Fire-fighting
Workflow Sync” Job, logs will be sent to respective controller via link or inbox.
 Different types of logs available in consolidated log report:

a) Transaction logs (STAD)

b) Change Logs (CDHDR, CDPOS)
c) Audit logs (SM20)
d) System Logs (SM21)
e) OS command logs (SM49)
f) All system logs – will show all above logs.

b. Invalid Super user report:

It will show all invalid FFID’s (means validity expired)

c. FF log summary report:

It shows summary report (means not detailed report) like who logged on to FFID, what
transactions FF used by using FFID.

d. Reason code & Activity report:

When logging into FFID, what reason codes were selected by FF & what transactions are
used (weather t-codes are relevant to that reason code used or not)

e. Transaction log & Session details:

It will show what transactions FF executed, how many sessions he opened using FFID.

f. SOD conflict report for FFID’s:

It will show what type of SOD critical t-codes used by FF through FFID (critical transactions
assignment is based on ARA)
Note: All reports will work only when we maintain parameters in maintain configuration settings in SPRO
t-code.

Important answers to remember in EAM.

19. What is the process for requesting a Fire-fighting ID?

a. Manually:

 User (Firefighting) will request access to the Fire-fighting ID through FFID form by providing
all the relevant information for the respective usage of FFID (business justification)
 The Fire-fighting owner will review the business justification and accept/reject the request.
 If the request is accepted, the Fire-fighting ID will be assigned to the user manually by
ADMIN in NWBC  Setup  Emergency access assignment  Fire-fighter IDs or NWBC 
Setup  Emergency access maintenance  Firefighters.
 Upon completion of the activity, Fire-fighting Controller will receive the transaction
execution, and change logs for review.
 Fire-fighting Controller will review the logs and gives his comments and close the request.
 The fire-fighter logs can be updated by running FF log sync job.

b. Workflow (Automation):

 User will raise access request for superuser access in NWBC  My Home  My Profile 
Access request by filling up all the required details.
 Upon the successful submission of the request, a FFID workflow gets triggered, and it will go
the respective stages for approvals, once the request is approved in every stage, the request
will be auto-provisioned (automation) and FFID will be assigned to the FF (End-User)

20. Steps to do after a new FF ID is created and checks to do if FFID is not available in GRC:

1) Ensure that the FF role (as per parameter 4010) is assigned to the FF ID user.
2) Run repository object sync job in the GRC system in incremental mode.
3) Goto NWBC  Setup  Owners and assign the owner, controller to the FF ID
4) All the FFID’s will be shown in GRACUSER Table
5) Once FFID is mapped with owner, controller, FF run “EAM master data sync” job to fetch the
information to plug in system.

EX:
 FF_BASIS, FF_FIN, FF_SD (Module level)
 FF_NRANGE, FF_FMAS, FF_SNOTE, FF_SAPCLI (Task Level)
NOTE: In case if you don’t see the owner listed, ensure to provide him FF Owner access in the Access
Control Owners POWL. Also, ensure that the respective role is assigned in the backend system.

IMPORTANT – The FFID should have access to S_RFC auth object to connect to the backend system
(which would be available in FFID standard role)

21. Checks to do if FF complains that he is not able to login to FFID in EAM dashboard even after
assignment of FFID to FF:

FFID is in use by another FF, the other FF is trying to login to same FFID as he is unable to see red status
in EAM dashboard, so he tries to login, that time check weather all roles assigned to FF are properly
generated or not, compared/not.

22. Check to do when FF login throws the error “Invalid FFID”:

 Make sure the role maintained in 4010 parameters, is assigned to FFID in plug-in system.
 When validity of the FFID is expired.

23. Checks to do if FF are not able to login to FFID:

1) Check whether FFID is with Service user type or not, if FFID is with other user types then
this issue will occur, then you should change it back to service user type.
2) FFID might be locked in the plug-in system, make sure FFID is active (not locked)
3) FFID password might be deactivated, make sure FFID password is in active status.

24. Checks to do when login to FFID throws error “receiver doesn’t exist”:

Check weather controller is having valid EMAIL ID or not, if not make sure valid EMAIL ID is maintained
to controller user ID in SU01.

25. Checks to do when assert condition violated dump error on maintaining owner, controller, FF:

The configuration parameter 4000 is missing in SPRO; make sure you maintain the parameter with
specific value.

26. Checks to do when login to FFID throws “role expired for FFID” error occurs:

Make sure that the role maintained in 4010 parameter is assigned with proper validity date or not in the
plug-in system, if not maintain role with proper validity.

27. Synchronization (Sync) Jobs in EAM:

a) Fire-fighter Log Sync Job: This sync is used to pull FF logs into GRC system from backend system
for “log display” option.
b) Fire-fighter workflow Sync Job: This sync is used to pull FF logs into GRC system from backend
system for “Workflow & Email” option, for “workflow” option controller will receive email
notification with link, in links FF logs will be there and for “Email” option, controller will receive
FF logs in his work inbox folder in NWBC.
 c) EAM Mater data sync job: Whenever a new assignment is done in GRC system, ensure to run
the EAM Master Data Sync job which will push the assignments information to the respective
backend systems.

ARA (Access Risk Analysis) - GET CLEAN

 ARA was called Risk Analysis & Remediation (RAR) is GRC 5.3 and Compliance calibrator in
VIRSA.

 ARA is implemented on a development system in GRC, connect the ECC/S4 Hana Production
and give the risk status to the management.

 Risk Addressal plan:

I. Remove excess access (users with SAP_ALL and SAP_NEW – review them)
II. Identify the roles that give excessive access and then remove them.
III. Perform Risk Analysis and give the output to the business to properly identify the
controls like preventive control remediation (removing the risk) and detective control
mitigation (accepting the risk with a control in place)

Usage of Access risk analysis:

 A solution that can identify Risks at the user & role level.
 Risk Management at the authorization level can be implemented effectively using ARA.

a) Risk Identification – ARA comes with pre-defined Ruleset (Risk Database)

b) Risk Addressal – We take a decision on whether the risk should be removed (remediation)
or accept the risk with proper controls in place (Mitigation)

1. One-time configuration/initial application configuration for ARA:

 Identify the Rule sets that needs to be activated (activate them using SCPR20)

 Below rule sets should be activated in the system (mandatory)

a) GRAC_RA_RULE-SET_COMMON - Rule Set for Common rule

b) GRAC_RA_RULE-SET_SAP_BASIS - BC Set for AC Rules - SAP BASIS
c) GRAC_RA_RULE-SET_SAP_R3 - BC Set for AC Rules for SAP R3

I. Ensure that all the connector specific configuration is completed, ensure that the sync
jobs are successfully completed for the specific connectors before you move on with
the next steps of configuration.

a. Maintain Connector and connector Groups (SPRO  IMG  GRC  AC)

Here we need to create Connector Group and we need to add connectors to connector
group.
 b. Maintain mapping for actions & Connector groups (SPRO  IMG  GRC  AC)

In this step, define the connector group and the actions performed on each of the
connector under the connector group.

NOTE: In-case if a new connector group is created, ensure to add it before adding the
connectors

Select the connector group and double-click “Assign Default Connector to Connector
Group”.

II. Root/sub organizations in the system.

a. Creation of Root/sub-Organisation structure:

SPRO  Reference IMG  GRC  Shared Master Data Settings  Create root Organisation
Hierarchy

Note: For the first time we must create Organisation and one child Organisation structure in
SPRO, from next time onwards we can do from NWBC also, path is as below

NWBC  Setup  Organisations  Organizations

2. Important terminology used in ARA:

 Risk in General: Any action that helps to commit fraud, process disruption is a risk in GRC.

 Action: In GRC we call t-code as action

 Permission: in GRC we call authorization object as permission

  Ruleset: Ruleset contains rules generated from the risks. All rules that are generated from
risks are stored in risk database i.e., (Ruleset)

 Creation of Ruleset: NWBC  Setup  Access Rule Maintenance  Rule Set  Select create
and provide mandatory fields details and save.

 Function: Function will have group of similar actions

 Creation of Function: NWBC  Setup  Access Rule Maintenance  Functions  Here we

must provide all mandatory fields details and then add actions and you can select permission
too for the t-code.

Note: In above screenshot we can see “Analysis Scope” field option where we have two options, they
are as follows

Single System When the Analysis scope is selected as Single system, it means
the risk is existed within the same system.
Cross System The risk is occurring in 2 different systems and not within the
same system.

For EX: Creating/maintaining vendors in Ariba/SRM and releasing

payments in ECC system.
 Access Risks: There are three types of Risk Types, they are as follows.

a) (SOD Risk (Segregation of duty)): Basically, SOD is a conflict between two or more different
activities that the user is performing/authorized to perform, SOD will have two or more
functions in it.

Creation of SOD (Segregation of Duties): NWBC  Setup  Access Rule Maintenance 

Access Risks  Here you provide all mandatory fields details and then add functions, rule
sets, risk owners.

b) Critical Action: A t-code on its own is a risk, that t-code is called a critical action.
EX: SCC5 (delete a client), OB52 (delete today’s transaction data) etc.,

Creation of Critical Action: Path is the same as SOD Risk, for critical action you just need to
change risk type to Critical Action as below.
 c) Critical Permission: A authorization object on its own is a risk, that authorization object is
called as critical permission.
EX: S_TABU_DIS with SS, * Table authorization group, S_USER_GRP with 02 activity etc.,

Creation of Critical Permission: Path is same as SOD Risk; here you just need to select risk
type as Critical Permission

 Rules: The rules generated from the combination of two functions in SOD (Risk) are called as
rules, please find below table, from below table in ARA we will add two or more functions and
generate rules (possible risks from functions)

Function 1 Function 2
PFCG ZA01
SU01 ZA02
SU10 ZA03
SU12 ZA04
ZA05
EX: Create 2 new functions with the t-codes in set # 1 and set # 2

Risk # 1 – PFCG & ZA01

Risk # 2 – PFCG & ZA02… so on
Risk # 25 – SU12 & ZA05

SOD Risk 1 = Function 1 + Function 2 & then generates the Rules

Select RISK ID and generate rules, it will generate the rules with the combination of functions.

Rules generation will update the “Global” (or the selected) ruleset with 20 new rules that are generated
from SOD Risk # 1

 Rule Library: Where all the Rulesets are stored.

 Risk Levels: Severity of the risk 1. Critical 2. High 3. Medium 4. Low

There would be “Businesspeople” in each module, they will confirm the severity of the risk and
they are called as “Risk owners”.

 Remediation: After identification of risks with users and roles, we remove the risks from them, it
is called remediation (removal of risk from roles & users)
EX: Let’s say there is a role with conflicting actions and same role was assigned to two or more
people, then we will discuss with client and decide and divide the conflicting actions into
different roles and those different roles will be assigned to different users to avoid risk

 Mitigation: Accepting the Risk & implement a control to manage/monitor the risk effectively
through the mitigation controller ID (MID), MID will have two users 1. Mitigation approver
2. Mitigation monitor assigned to MID.

EX: Let’s say there is only one user is present who could perform the activities, that time we
don’t option to remediate the risk, that time we will go with mitigation and assign MID which
will have mitigation approver and mitigation monitor

 Mitigation Approver: This user will approve the risks in mitigation control, whether it can be
assigned to user or not.

 Mitigation Monitor: This user will monitor the mitigated risk for the user through MID, user will
receive logs and this monitor can check the logs and question the user who used risk in case of
any doubt.

 Risk Owner: There would be “Businesspeople” in each module, they will confirm the severity of
the risk and they are called as “Risk owners”

 Execution: Execution will display the existing violations that user has through different roles
 Simulation: Simulation will show the possible violations with the new action/role to existing
user. EX: Let’s say user is already having 2 roles assigned to him, when user requests for new
role to be assigned to him/her, then we will check if any risks are coming with the new role

 Organization Rule (False Positive):

I. To define the Risk which are false positives.

II. Org Rules are not pre-delivered as they are business specific.
III. Once after implementing ARA, if you hear from the business that a specific risk is a FP,
then the org rule can be created (mention the Risk ID and the Org element which is
creating the conflict

EX: A user has authorization to

- Create Purchase Orders (Co 1000)

- Release Payments (Co 2000)

If you look at the action level, it is a pure SOD. But if you also consider the org element,
then this is not a risk at all. Since GRC ARA can identify risks only at the
action/permission level, Org elements/values are not considered, which will show it as a
risk.

 Supplementary Rule (False Negative)

SAP will show some actions as no-risk, but it is RISK those scenarios are called as
Supplementary rules (False Negative)

EX: Lets say there are 3 functions. F1 with SU01, SU10, F2 with PFCG, F3 with SUPC then in
SU01 & PFCG will not show as risk.

 Risk Analysis Type:

Action Level Risk Analysis will show you the conflicts at the transaction
code level.
Permission Level Risk Analysis will show you the conflicts at the authorization
object level. There is a possibility that conflicts can be
defined at the authorization object level.

For EX: A user who has authorization to DEBUG in

S_DEVELOP should not have the authorization to maintain
tables (S_TABU_DIS).

By default, the Action level is also included in the permission

level as S_T-CODE is also an authorization object, and all the
t-codes are maintained here.
Critical Action Risk Analysis will show all the critical transaction codes.
Critical Permission Risk Analysis will show all the critical authorization objects.
 Critical Role/Profile The critical roles/profiles can be defined by the admin and
when you run this report, it will show the users/roles that
have the critical roles & profiles.

NOTE: Offline Risk Analysis (It is highly recommended to disable this option in the production systems.)

1) Online Risk Analysis (or) Online (Real-time) Risk Analysis (or) Ad hoc Risk Analysis – When
you perform the RA in online mode, the role/profile assignments of the user will be picked up
by the RA from the backend system. Hence this is also called as a real-time RA.

2) Offline Risk Analysis – The data that is available in the GRC repository will be used (that date
would be the date when you have last performed repository sync job)

NOTE: When you need to run risk analysis for mass number of users, it is highly
recommended that you run Repository object sync job in Full sync mode and then perform
the RA for mass users/roles.

 Creation of mitigation control id (MID):

 Usage: When a risk is mitigated, it will be further monitored by Mitigating (Internal)

Control Owner/approver and the Monitor, and those two users are available in MID, so
MID will be assigned to user.

 MID’s are shared data which means it can be used to AC (Access Control), PC (Process
Control), RM (Risk Management)

 To create a new mitigating control, which fields are mandatory:

NWBC  Setup  Mitigating Controls  Mitigating Controls  here we need maintain

mandatory field’s details as below.

Mandatory Fields required to create a MID.

I. MID
II. Organization
III. One or more risks
IV. Control Owners (at least 2 owners are required)
V. Business Process, Sub process
 Important Parameters in ARA

Please refer below link

GRC Parameters.xlsx

Or File: GRC Parameters

5. Questions and checks to do in ARA:

a) What is the primary difference between online (Ad hoc) and offline Risk Analysis?

 When the RA is performed in online mode, it gets the assignment data from the backend
system. However, offline will use the data which is there in the GRC repository.

b) In-case if RA is required for a mass number of users/roles, what is the best approach?

 Perform the repository object sync (Users, Roles, Profiles) in full sync mode and then run the RA
for the mass users in offline mode. This will not create any performance issues on the backend
system.

c) What is the difference between Action Level and Permission Level Risk Analysis?

 Both are to identify the SOD (conflicting) risks. Action level will only determine the conflicts at
the t-code level, wherein Permission Level will identify the conflicts at the Authorization object
level.
 Note that when you do the RA at the permission level, action level is also included as S_T-CODE
is an authorization object.

 Hence it is always recommended to select Permission level by default.

d) What is the difference between Intra Level & Extra Level Conflicts?

 Intra level is a conflict when we risk is coming from one role directly and Extra level conflict
is with assignment of 2 or more roles (User, or Composite Role)

e) What is the difference between Intra Level & Extra Level Mitigation?

 Mitigation can be either done in two ways one is at the role level (intra level mitigation) or
another is at the user level (extra level mitigation)

f) What is the difference between a Rule & a Risk?

 Rules are logically generated from the physical risks in the GRC system. Risk contains one
or more functions and is physical in nature.
 If a risk has 2 or more functions – Segregation of Duty
 If a risk has 1 function – Critical Action/Permission

g) Difference between doing Risk Analysis from Simulation and execution:

 Risk from simulation means the simulation results (it will only display the results of risks or
violations which will be obtained/coming from the combination of users existing
assignments (roles) plus the new assignments (roles))

 Risk from execution means the execution results (it will display the results of risks
obtained/coming from old assignments as well as new assignments, it will be consolidation
violation results

h) Important Parameters in ARA

Please refer below link

GRC Parameters.xlsx

Or File: GRC Parameters

i) Business processes and risks in Business process:

SD: Create Vendor (XK01/MK01) and initiate payment (F110, F-53) is risk

MM:

1. Creating purchase requisition (ME51N) and release purchase requisition (ME54N) is risk
2. Creating Purchase Order (ME21N) and release purchase order (ME28/ME28N) is risk so on…
 j) Transportation control for Business Units/Organisations Units & Mitigation Control

 There is no transport mechanism to move Business Units/Organisations Units & Mitigation

Controls from one landscape to another landscape in the GRC suit, because it is a master data.
So, no transport requests can be created.

k) Checks to do when owners are not available in Mitigation Control:

 Check if the owners are assigned with proper roles or not in SU01 in GRC system and in
NWBC access control owners.
 Check if the owners are mapped to an organisation unit or not.

l) Checks to do whether in RISK ID’s rules generated or not:

 Create a new RISK ID (Status should be Active) in GRC system and don’t generate the rules,
then this ID will be available in GRACSODRISK Table
 Now check the GRACACTRULE table with your new RISK ID, you will not find any RULE ID
entries for the RISK ID
 Now generate rules for your newly created RISK ID, then check both the tables
GRACSODRISK, GRACACTRULE you can find the data in both the tables.

Note: Whenever you create RISK ID, entry will only be updated in GRACSODRISK Table,
only when you generate rules for RISK ID then we can see the RULE ID entries in
GRACACTRULE table

m) What happens when RISK ID is deleted from ARA, from which tables the data gets deleted.

 Deleting the Risk doesn’t delete the rules associated with it in GRACACTRULE table. When
Risk is deleted, it will only delete the entries in GRACSODRISK table, not from
GRACACTRULE.

n) Maintenance of Critical Roles & Critical profiles in NWBC:

Path for Critical Roles: NWBC  Setup  Critical Access Rules  Critical Roles  Select
Create and provide mandatory fields as below.
 Path for Critical Profiles: NWBC  Setup  Critical Access Rules  Critical Profiles  Select
and create and provide mandatory details as below.

Note: For every link (Rule Set, Function, Access Risk, Critical roles, Critical profiles we can see “Change
History” tab, where we can see change related to it

o) How to ignore/exclude critical roles/profiles while running batch/ad-hoc RA:

 If configuration parameter 1031 set to “Yes”, the application collects a list of all critical
roles & profiles maintained in NWBC and will ignore critical roles/profiles while running
batch/ad-hoc RA.
 Basically, the exclusion is made based on flagging the critical roles/profiles to be ignored.

SPRO  Reference IMG  GRC  Access Control  Access RA  Execute Batch RA

p) Checks to do when no actions are available when the user performs the action level
simulation for a user/role.

The authorization sync job, repository sync job was not scheduled for the connector which is
used for simulation.

q) What are the mandatory fields for creating Function ID?

a) Function ID
b) Business Process
c) Analysis Scope
d) Description

r) What are the fields mandatory for creating RISK ID?

a) Access RISK ID
b) Risk Type
c) Business Process
d) Description
e) Risk Level
f) Status

s) Tables related to ARA:

 GRACFUNC – We can see the list of functions.

 GRACFUNCT – We can see the description for functions.
 GRACFUNCACT – We can see the actions in functions.
 GRACROLE – We can see the Critical roles defined in GRC system.
 GRACROLET – We can see the description for Critical roles.
 GRACPROFILE – We can see the Critical profiles defined in GRC system.
 GRACPROFILET – We can see the description for Critical profiles.
 GRACSODRISK – We can see SOD risks in system.
 GRACSODRISKT – We can see the description for SOD risks.
 GRACSODRISKOWN – We can see the Risk owner for SOD risks.
 GRACACTRULE – We can see the rules for RISK ID
 GRACOWNER – Master table to see all the owners in the GRC system (Which are
maintained by Access control owners)
 GRACUSERCONN – We can see the Users specific to the connector (backend system)
 GRACSODRISKRS – Risks in Rule set
 GRFNCONNSCNLK – Connector versus integration scenarios
 GRFNCGRPCONLK – Connector group versus connectors
 GRACCONNSTAT – List of RFC’s in GRC AC control