GRC TRAINING:

RISK OWNERS

Table of Contents
GRC ROLES & RESPONSIBILITIES RISK OWNERS ................................................................................................... 3
RESPONSIBILITIES REFERENCE ..................................................................................................................................... 3
SAP SECURITY AND GOVERNANCE PROCEDURES ................................................................................................... 4
PROCESS 1: NEW OR AMENDED ROLES ........................................................................................................................ 6
PROCESS 2: MITIGATION ANALYSIS ........................................................................................................................... 18
PROCESS 3: NEW USERS AND USER ROLE PROVISIONING ............................................................................................... 28
PROCESS 4: FIREFIGHTER USERS AND ROLES ............................................................................................................... 34
PROCESS 5: PERIODIC COMPLIANCE REVIEWS.............................................................................................................. 47
GRC REPORTING .................................................................................................................................................. 55
JOB AIDS ............................................................................................................................................................ 56
Job Aid 01 Risk Violations ............................................................................................................................. 58
Job Aid 02 User Analysis ............................................................................................................................... 77
Job Aid 03 Violations Comparisons ............................................................................................................... 94
REFERENCE AIDS ................................................................................................................................................. 103
Reference R1 Access GRC Reporting............................................................................................................ 105
GRC TERMINOLOGY ........................................................................................................................................... 114
GRC ROLES & RESPONSIBILITIES......................................................................................................................... 124
GRC SOD ANALYSIS STEPS .................................................................................................................................. 129
GRC FORMS ....................................................................................................................................................... 136
EXAMPLE FORM A: GRC MITIGATION CONTROL CHANGE REQUEST ................................................................................ 137
EXAMPLE FORM B: GRC FIREFIGHTER CHANGE REQUEST ............................................................................................. 140
EXAMPLE FORM C: SAP USER OR ROLE CHANGE CHECKLIST .......................................................................................... 143
GRC CHANGE EVENTS ........................................................................................................................................ 148

GRC Training Risk Owners

GRC Roles & Responsibilities Risk Owners
Risk Owners will carry out the following tasks as part of their GRC-related responsibilities:

Provide guidance on:

o

acceptable level of risk related to SODs and critical access

adequacy of compensating (mitigating) controls

Ensure control processes are in place:

o

Regular access review

Mitigation processes, including specific reports.

Final approval on new/amended Mitigation Control definitions and assignment to Risk / User
combinations.

Approve recertification of mitigating controls supported by Role Owner and Compliance Officer.
Where designated as a FireFighter ID owner, will approve assignment of FireFighter ID to users.

Responsibilities Reference
TASKS
Maintain Risk Awareness : Role Owner emails Risk Owner of
major role changes
Provide guidance on acceptable risk during the Mitigation
Analysis process
Final approval of Mitigation Control definition based on Role
Owners recommendations
Overall monitoring of control processes / reports
Final approval of Mitigation Control assignment to users
based on Role Owners recommendations
Approve assignment of FireFighter IDs to users
Final approval of periodic recertification of Mitigating
Controls

PROCESS & STEP

1.14

REPORTS
01 Risk Violations
02 User Analysis
03 Violations Comparisons

PROCESS
5
5
5

FORMS
A: GRC Mitigation Control Change Request

PROCESS & STEP

2.5

WORKFLOW OR EMAIL-TRIGGERED ACTIONS

Email for Mitigation Changes if designated as Monitor

PROCESS & STEP

2

2.1.c
2.5
2.8, 5
3.8
5.M.2, 5.Q.10
4.5
5.A.3

GRC Training Risk Owners

SAP Security and Governance Procedures

GRC Training Risk Owners

PURPOSE OF THIS DOCUMENT
The SAP Security and Governance Procedures are documented in five flowcharts. The sections in this document
describe the details of each step.

CONTENTS
Process 1: New or Amended Roles
Process 2: Mitigation Analysis
Process 3: New Users and User Role Provisioning
Process 4: FireFighter Users and Roles
Process 5: Periodic Compliance Reviews

GRC Training Risk Owners

Process 1: New or Amended Roles

Risk
Owner

MIT SAP Security & GRC Process : 1. New or Amended Roles

14
MAINTAIN
RISK
AWARENESS

FYI EMAIL

FYI EMAIL

Role Owner

START

1.a
Initiate proposal for
New / Amended
Roles

5
Approve Role Build /
Amendment

9
Approve Role Build /
Amendment

In PROD

13
Close Out
RT TICKET

RT
NEW TICKET
Email requesting
Promotion to PROD

FYI
EMAIL

All paperwork

R/3
Security Admin

START
6
Process 3
Role
Provisioning

1.b
Initiate proposal for
New / Amended
Roles

BA / BSA

YES

FROM
7, 11

End User

New SOD Risks

identified ?

3
Process 2
Mitigation
Analysis &
Design

FROM
7, 11

IN TEST

GRC-ARA
report

2
Role Design review
and GRC-ARA
Simulations

10
Process 3
Role
Provisioning
and QA

NO

4
Finalize
Role Design / Redesign
and
run GRC-ARA

Email -ready for test

IN PROD

NO
Some minor fixes
are required

USER LEVEL
GRC-ARA
report

USER LEVEL
GRC-ARA
report

NEW ROLE
DESIGN

ROLE
MINI-SPEC

FILED

YES
7
SAP TEST
Test
New/Changed Role
and
run GRC-ARA

Test OK ?

YES

11
SAP PROD
GRC-ARA review
And
Support USER

Feedback
and
TEST RESULTS

8
SAP TEST
Test the role

STEP
3

NO
Some minor fixes
are required

NO
Additional SOD Risks Identified

NO
Additional SOD Risks Identified

TEST PLAN

Test OK ?

Feedback

12
SAP PROD
Confirm role works

STEP
3

STEP
6

GRC Training Risk Owners

Process 1: New or Amended Roles
The New or Amended Role process is for the scenario where a new or amended business role is needed, and includes the high-level steps for initial
investigation, design, development and GRC Access Risk assessment.
The requirement SAP Access Role maintenance can be identified during the following business events, with the first two being the most frequent and
represented in the flowchart. The process for the other triggering events is almost the same, with any differences documented in the text.
1. Departmental reorganization.
2. New or changed job duties within a department.
3. New SAP functionality which is not expected to be included in common roles but is needed for several users with different access
and does fit into an existing role. This may be :
o Small changes, for extra functionality in existing applications
o Larger, project-related changes where a whole new application is rolled-out, and probably multiple SAP Access roles.
4. Audits, Compliance and other reviews this would be less common.
5. SAP Access role redesign / tidy-up (triggered from technical reviews).
6. Removal of functionality from roles (no SOD risk issues).

Roles & Responsibilities for Process 1:

Risk Owner :

Maintains awareness of role changes and potential for new risks

Role Owner :

Initiates proposals for role changes, approved role changes, closes out role change process

BA / BSA :

Involvement in several steps

o

Performs preliminary role change analysis

Creates role design / redesign documentation and test plan

Tests new roles in TEST including GRC-ARA simulation

Supports end-user in Production.

8

GRC Training Risk Owners

R/3 Security Admin:

Builds roles and provisions role (see process 3).

SOD Coordinator:

Indirectly involved if there is any Mitigation requirements see Process 2.

GRC Admin:

Indirectly involved if there is any Mitigation requirements see Process 2.

End User:

Test their User in SAP Production.

Reports available to support the Process 1:

Rept. 5 R/3 SUIM
Rept. 6 GRC

Roles by Role Name

User to Role relationship

Rept. 7 GRC
Rept. 8 R/3 SUIM

Role relationship with User

Users by User ID

Rept. 9 GRC
Rept. 10 GRC
Rept. 12 GRC

Count of Authorizations
Action Usage by User, Role, Profile
User Level access analysis

Rept. 13 GRC
Rept. 14 GRC

User Level access analysis simulation with added / removed actions, roles, profiles.
Role Level access analysis

Rept. 15 GRC

Role Level access analysis simulation with added / removed actions, roles, profiles.

TCODE SU01D

Display User information with Roles and Profiles tab

The following report are also available, but will be less frequently used in the MIT environment:
Rept. 16 GRC
Rept. 17 GRC

Profile Level access analysis

Profile Level access analysis simulation with added / removed actions.

GRC Training Risk Owners

Process 1: New or Amended Roles - Detailed Steps
P.1
STEP

Business Role

Responsibility /
Action

Output

Details

Role Owner

Initiate proposal for

New/Amended
Roles.

a. Role Owner identifies a potential need for a new role due to :

Email to BA/BSA
and Risk Owner,
SAP Security Admin
and MIT Audit
RT Queue new
task

Departmental Reorganization new roles are needed to reflect

completely new, permanent job duties, and old roles probably can be
deactivated.

New or changed job duties may be combined roles or split role or

just completely new. This is less likely where provisioning is managed
with Composite roles which can have existing roles added / removed
without the need for a new role.

New SAP functionality which does not easily fit into an existing role.

b. Role Owner communicates (email) potential need to BA/BSA and Risk

Owner.
c. The requirement may be triggered from a technical role redesign
proposed by SAP Security Admin.
Note that MITs has made more use of composite roles in the redesigned
VPF access. The composite role is where several roles are linked together to
represent a job position or a specific users duties.

10

So some minor User access changes can be managed by adding or

removing roles from the composite role.
This would be identified by the Role Owner in simpler cases, or by the
BA/BSA for more complicated cases see step 2.

GRC Training Risk Owners

P.1

Business Role

Responsibility /
Action

Output

Details

BA/BSA

Role Design review

and GRC-ARA
simulations

GRC-ARA Risk
simulation reports

For existing risks,

assessment of
existing Mitigation
Controls to new
tcode combination.

a. For major changes, e.g. complete business reorganization or new major

multi-role applications being rolled out, there will always be a need for
everyone to be involved, like the SOD project had.

STEP
2

If new Risks, kickoff a full risk

assessment (see
next step =
Process 2).

b. For minor changes, the BA/BSA will review the current role design (GRC
and SUIM reports) and decide if any new Roles are necessary to achieve
the business changes. Where there are any new action tcodes (create,
change, post etc.), or new combinations of tcodes due to composite role
changes, a GRC-ARA SOD analysis is required for :

The proposed new / changed role

The users for whom the change will be made

The GRC-ARA simulation can use the current user in PROD, plus any
tcodes (entered) or existing roles (in DEV, TEST/QA or PROD).

SAP R/3 Security Admin may need to advise on additional

authorizations (permission level) which may reduce the risk.

The BSA may need to advise on alternative tcodes (actions) and

standard SAP equivalents of custom Z transactions.

The proposed design can be workshopped, including bringing up any

SOD issues and recommendations for mitigation. (See details in
Process 2: Mitigation Analysis).

c. In defining design requirements for the request, the BA/BSA works with
the Role Owner and Risk Owner.

to mitigate risks and SODs wherever possible,

reaching out to the GRC Analysis Team when input is required

d. Check any existing Mitigation Controls related to the current role, and
check the detail of the new tcode combinations. It is possible the existing
Mitigation Control does not fully cover the new tcodes.

11

GRC Training Risk Owners

P.1

Business Role

Responsibility /
Action

Output

Details

BA/BSA

Mitigation Analysis

See Process 2
Flowchart for details

Also, see Flowchart for Process 2 for more details.

STEP
3

Risk Owner
Role Owner

a. Mitigation analysis is required where :

SOD
Coordinator

New SOD Risks are reported

Existing SOD Risks remain, but are changed due to the new tcodes

New Critical transactions (actions) are reported.

b. Detailed SOD Risk analysis will confirm if :

risk is low level and is acceptable, or

existing mitigation could apply / still applies, or

a new mitigation control can be defined, or

a new mitigation process may need to be developed

o

new report

system enhancement

system configuration change

additional SAP Access restrictions permission level

new manual process.

c. The output of this step will be one or more role redesigns and potentially
a new Mitigation Control if the Risk remains after the role redesigns.
Note the Risk may have been avoided due to Remediation :

12

Several roles and related user assignments were changed

The tcode causing the issue was put in a FireFighter role.

GRC Training Risk Owners

P.1

Business Role

Responsibility /
Action

Output

Details

BA/BSA

Finalize role Design /

Redesign ad run GRCARA simulation

Role Mini-Spec

a. Prepare Role Design / Redesign documentation including :

New Role Design

spreadsheet

GRC-ARA
Simulation reports

Test plan and test

cases

STEP
4

Composite Role changes

o

Existing Composite Role: roles to be added or removed

New Composite Role to be created and its roles

Changes in assignment of Composite Roles to User

Single Role changes

o

New Single Roles

Transaction Codes (Actions) to be added or removed

Authorizations (Permissions) to be added, removed or

changed

FireFighter roles for back-up of new/amended role

o

New FireFighter roles

Existing FireFighter roles - changes to tcodes and other

authorizations.

Assignment of new FireFighter Roles to Users (see Process 4)

Mitigation documentation (part of Process 2: Mitigation Analysis).

GRC-ARA SOD Risk Analysis Role and/or User simulation Report 13

and 15, where possible.

b. For major redesigns or new complex applications, the supporting

documentation must include full GRC-ARA analysis probably on the new
Roles built in DEV. This step is not included in the flowchart.

13

GRC Training Risk Owners

P.1

Business Role

Responsibility /
Action

Output

Details

Role Owner

Approve Role Built /

Amendment

a. Email SAP Security

Admin
b. SAP Mini-Spec for
Access Change
request

a. Give the initial go ahead for new/amended role.

STEP
5

Check GRC-ARA simulation results (printed report)

Review detailed Mini-Spec / SAP Access Change request

Email SAP R/3 Security Admin

o Give approval to proceed and RT #
o
o

SAP Security
Admin

Process 3 : New
Users and User Role
Provisioning
In TEST system

Email to BA/BSA
when complete
Amended Role
Saved copy of
current role
Update RT Ticket

Include New Role Design document (for new roles)

Include Role Mini-Spec (for new / amended roles)

a. IS&T have a process for managing RT tickets, their prioritization and

execution, including a QA review prior to approval of transports going
into Production. The details of this process are not documented here.
b. Here are the action steps specific to the Role Change requests :

14

Review all supporting documentation for completeness and for

correspondence with the RT ticket description.

Determine if this request involves the already redesigned roles, or

the old roles. For amending original roles, proceed with the old
provisioning process.

Identify any potential overlap with the RoleDB

For any new roles, determine naming convention and check the
proposed assignment to composite roles (and related users) or users.

Build or amend the role in SAP Development, move it to TEST/QA,

and then assign to a test user, alias or to a composite role.
o Take a safety copy of any existing role being amended
o This can be iterative where role design is incomplete or
incorrect.

Perform basic unit testing.

Advise BA/BSA the new / amended role is ready for testing

GRC Training Risk Owners

P.1

Business Role

Responsibility /
Action

Output

Details

BA/BSA

Check role build,

GRC-ARA and assist
user with testing

GRC-ARA
simulation reports
Functionality test
results
Updated RT-related
documentation

a. Check role build / amendments in TEST/QA system

SUIM report
b. Run GRC-ARA SOD Risk simulation Report 15 on the Role & Report 13 on
all Users to be assigned the role.
Use the new/amended Role from TEST/QA system, User from
PROD system.
If any new risks are reported, check the reason and revisit the
Mitigation process (Step 3).
c. Assist the business User with testing the role functionality in SAP TEST/QA
system (see Step 8.)
d. Update RT-related documentation with test results.
e. Email Role owner when business user has accepted the changes.

Functionality test
results

a. Test the new/amended role functionality in TEST/QA system

STEP
7

End user
and/or BA

b. If there are any issues :

Role Owner

Review simulations if no issues, approve

move to SAP
Production.

Email to SAP
Security Admin
Updated SAP
Access Change
request form
Update RT Ticket

Go back to Step 6 for minor changes (e.g. a previously

unidentified permission is required for a new tcode).
Go back to Step 4 for any major changes e.g. additional or
alternative tcodes are required. [Not shown on flowchart].

a. Review all the paperwork, including Simulation reports.

b. Follow-up any issues.
c. If all is good, send email to SAP R/3 Security Admin to request promotion
to PROD.
Include any special requests e.g. staggered roll-out to several
users at a time, which is more difficult when using Composite
Roles.

15

GRC Training Risk Owners

P.1

Business Role

Responsibility /
Action

Output

Details

SAP Security
Admin

Role provisioning and

Transport QA review

a. IS&T have a process for managing RT tickets, their prioritization and

execution, including a QA review prior to approval of transports going
into Production. The all the details of this process are not documented
here, just the ones relating to the roles.
o Ensure roles in DEV and TEST/QA are matching
o Ensure existing role to be amended in PROD is backed up
o Check all paperwork for release is complete, coordinate with BSA
as appropriate.
o Request Transport QA review and promotion to PROD
o Check transports were imported and briefly review roles.

STEP
10

Email to BA/BSA
and Role Owner
when complete
Update RT Ticket

b. Email status to Role Owner

NOTE: It is also possible there is a need to tweak the RolesDataBase

interface with SAP Production i.e. stop a profile coming over for the
users affected by the role changes.

11

BA/BSA

Run User level GRC

simulation for all
users expected to be
assigned the new
role. Potential risk
that RolesDB profiles
causes an issue see
Step 17.

GRC-ARA
simulation reports.

Repeat of step 7 except BA/BSA does not have access in PROD so cannot
confirm anything is working.

12

End user

Test role
functionality in
Production

Functionality test
results

Repeat of Step 8.

16

GRC Training Risk Owners

P.1

Business Role

Responsibility /
Action

Output

Details

Role Owner

If no issues, close out

the change request

a.
b.
c.
d.

STEP
13

14

Risk Owner

Maintains awareness
of role changes and
their
implementation.

Email to SAP
Security Admin
Updated RT
Signed off SAP
Access request?

RT ticket can be closed out

Courtesy email to all involved
Paperwork check (or confirm with BA/BSA) all is filed
Mitigation: additional coordination required if new / amended
Mitigations were required see Process 2: Mitigation Analysis.

Maintains general awareness of SAP access within business area. Look out for
any new issues at next SOD Review.

17

GRC Training Risk Owners

Process 2: Mitigation Analysis

18

GRC
Admin

MIT SAP Security & GRC Process : 2. Mitigation Analysis

SOD
Coordinator

FILE

1.b
Contribute to
Workshop

GRC Mitigation Control and Assignments

GRC
Notification

1.c
Provide
Guidance

Risk
Owner

6
Enter MC in GRC and
assign to Risk/User
combination

5
Approve Mitigation
Control and Risk/
User Assignment

8
Review of Control
monitoring

Results Filed

Feedback

R/3
Security Admin

Role
Owner

START
See
Process 1
Step 3

4
Recommend
Mitigation Control
and Risk/User
Assignment

1.d
Contribute to
Workshop and
Finalize

7
Carry Out SOD
Analysis &
Mitigation
Control Review
Periodically

2.g
Update Controls
Checklist

1.e
Contribute to
Workshop

2.e
Process 3
SAP Access
Provisioning

FORM :
MITIGATION
CONTROL
CHANGE REQUEST

1.a
Document Risk issue
and Manage Mitigation
Workshops

BA AND/OR
BSA

2.f
Implement new
manual control

2.d
IS&T
Development

Additional reports

UPDATED
IS&T
MINI-SPEC

Existing controls
are adequate ?

Yes

3
Prepare Mitigation
Control request

FOR NEW MITIGATION CONTROLS

No

New Tcodes , Report Ids etc

2
Design New
Mitigation
Controls

2.a
Prepare Functional
Specs for IS&T
Development and/or
Configuration

2.b
Prepare SAP Access
Change request for
additional permissions

TEST PLAN

2.c
Test developments

TEST RESULTS

GRC Training Risk Owners

Process 2: Mitigation Analysis
The Mitigation process described in this flowchart is for the scenario where a new or amended business role is needed, and a new GRC SOD Risk is
identified and cannot be avoided.

See Process 1: New or Amended Roles - which described when role changes occur and where the SOD Risk Analysis and then this Mitigation step
fits in.

When a new SOD Risk is identified, there can be several outcomes:

a. Mitigation is not required :
a. Role change is not made risk cannot be mitigated
b. Functionality is added to a different user, creating no new Risk require some additional role redesign, to move tasks between several
end-users.
c. Functionality is added to Emergency Access Firefighter Role
b. Mitigation is required
a. There is an existing Mitigation Control which applied to the Risk (and to the exact combination of tcodes creating the risk).
b. A new Mitigation Control definition is required based on :
existing business and/or system control processes
new control processes
new / amended Mitigation Control reports
new manual procedures
amended system configuration or enhancements providing additional restrictions
c. additional Authorization (Permission Level) restrictions to be added to the SAP User security role
c. Where mitigation is required, the GRC system needs to be updated
a. A new GRC Mitigation Control definition
b. Assignment of existing or new Mitigation Controls to the Risk/User combination

20

GRC Training Risk Owners

Note: this process is initiated when a potential SOD risk has been identified and is seems like it cannot be avoided and so needs to be mitigated. It
may also be that a critical transaction is assigned and so is being reported as a risk. This implies a remediation process has already been gone
through, with the following steps, but none of which are acceptable or possible:

Consider assigning the transaction code to a different user where there will not be an SOD issue
If the specific user really needs the new transaction code assignment, then consider removing the assigned tcodes which are triggering the SOD.
Investigate using any alternative transaction codes which deliver the functionality but do not trigger the SOD issue.
For critical transactions, it may be that they are acceptable within a specific business area, but not outside that. It is proposed that MIT will
have a GRC report to monitor this situation.

Roles & Responsibilities for Process 2:

Risk Owner:

Provide guidance for level of MIT risk acceptance and formally approve Mitigation Controls.

Role Owner:

Assist BA/BSA with Mitigation Control definition; propose final Mitigation Controls and User Assignments to Risk Owner.

BA / BSA :

Involvement in several steps

o

Manage Mitigation workshops / meetings

Assist in design of any new Mitigation Controls

Document existing and new Mitigation controls prepare GRC MC Change Request for Role Owner

SOD Coordinator :

Contribute to Mitigation workshops / meetings

R/3 Security Admin :

Contribute to Mitigation workshops / meetings , and provision access to any new Mitigation Control reports

GRC Admin :

Update GRC Mitigation Controls and Risk/User assignments

21

GRC Training Risk Owners

Reports available to support the Process 2:
Rept. 11a GRC
Mitigation Control report lists Mitigation Controls
Rept. 11b GRC
Mitigated Object report - lists assignment of Mitigation Controls to Risk/User combinations
Rept. 12 GRC
User Level access analysis
Rept. 13 GRC
Rept. 14 GRC
Rept. 15 GRC

User Level access analysis simulation with added / removed actions, roles, profiles.
Role Level access analysis
Role Level access analysis simulation with added / removed actions, roles, profiles.

The following report are also available, but will be less frequently used in the MIT environment:
Rept. 16 GRC
Profile Level access analysis
Rept. 17 GRC
Profile Level access analysis simulation with added / removed actions.
Some important GRC concepts relevant to SOD Risk identification:
1.

In SAP Access control and related GRC risk analysis, there can be two levels of access to review :
i.

SAP Transaction Code (GRC Activity) level, like :

FB01 : Post a financial document
ME22 : Change a Purchase Order
FS00 : Create, change, display a GL Account master records

ii.

SAP Authorization (GRC Permission) like a RolesDB qualifier, but can be more than that.
Financial Document Posting : Company Codes allowed
Financial Document Posting : Customer usage restriction (e.g. not allowed to post to Sponsored Accounting customers)
Purchase Order Type : only allowed to access NB purchase orders
GL Account Master Maintenance: only allowed Display, not Create or Change no matter what tcode is provisioned (like FS00).

iii.

Note that one SAP transaction usually checks many different SAP authorizations e.g. checking that a financial posting is allowed to
specific objects like: a Company Code, FI Document Type, Customer account, GL Account, Prior Posting Period, Profit Center, Fund, etc.

22

GRC Training Risk Owners

Not all of the standard SAP authorization checks are being used at MIT and the SAP R/3 Security Analyst is able to identify what is
called up by standard SAP and what is used at MIT.
2. The way the GRC system identifies an SOD issue is by having a rule set of pre-defined data :
i.
SOD Risks with an id like X099 and a description like Create a fictitious Vendor and post a fictitious Vendor invoice.
ii.
Combination of Functions which create the risk: e.g. ZAP01 = Create Vendor master WITH ZAP02 Post a Vendor Invoice.
iii.
Activities (transaction codes) which the Function contains, e.g. :
Function ZAP01 may have 4 transaction codes like;
FK01, FK02, XK01, XK02.
Function ZAP02 may have many transaction codes like :
FB60, FB65, FB01, FB02, F-xx
So there are 4 x 5 = 20 possible combinations of transaction codes triggering the SOD issue.
3. There is no way of avoiding looking into the reported combinations of transaction codes which the user actually has and were reported. In most
cases the pre-defined is reporting a clear and specific issue no matter what the combination of transaction codes. In that case an existing
Mitigation Control for the same risk (by for another User) should apply to this user being reviewed. However :
i.
In the example above, say that User 1 had transaction codes FK02 + FB02 and so Risk X099 was reported. Neither of these transaction
codes is create/post, and the business risk for these may be lower than having FK01 + FB60. So any Mitigating Control assigned to User
1 for risk X099 may not apply to User 2 who has FK01 + FB60 for the same Risk = X099 .
ii.
Additionally, User 2 may have additional restrictions only creating Sponsor Vendors, or only posting to non-Sponsor vendors. So any
Mitigating Control description will be different and so will need a new GRC mitigating Control definition.
4. In GRC risk analysis, always report at the Permission level. If some Activities (transaction codes) are not additionally defined with a Permission
(authorization) level, they will still be shown in the Permission level report.
5. The GRC system manages Mitigating Controls in two steps :
i.
Define a Mitigating Control, with a unique id and description
ii.
Assign the Mitigating Control to a combination of Risk + User(s).
So the GRC system can report to the Risk Owner any new users with
the Risk who have not yet been assigned to the Mitigating Control.

23

GRC Training Risk Owners

Process 2: Mitigation Analysis - Detailed Steps
P.2
STEP

Role

Responsibility /
Action

Output

Responsibility / Action

1.a

BA/BSA

Document the risk

issue and manage
the Mitigation
Workshops /
Process

a. Describe the Risk and the exact combination of tcodes causing the
risk.
b. If possible, quantify / evaluate the risk in the MIT business
environment see also 1.c Risk Owner contribution.
c. Review existing Mitigation Controls for the SOD Risk or similar SOD
Risks evaluate if they might apply.
d. Also, the risk may already be subject to a Mitigation Control, but
that may not apply to a new combination of tcodes reported for the
same GRC Risk.
e. Identify other business system controls (manual or automated)
relevant to the risk.
f. Prepare and manage a brief workshop meeting to review the
information gathered and make a recommendation.
g. Document the results of the workshop.

Documentation of risk issue

and existing possible
mitigations
Work plan and potential
workshop agenda
Workshop results i.e.
decision on what to do
Workshop results sent to
Audit - for their information.

1.b

SOD
Coordinator

Contribute to
workshop

None

a. Contribute to the understanding of the risk and possible mitigations

1.c

Risk Owner

Provide Guidance

None

a. Provide guidance on the significance of the risk and the relative

importance of mitigation and therefore level of resource that can
be justified to mitigate the risk.
b. Potential suggestions for end-user role redesign or organizational
adjustments, to eliminate or minimize risks.

1.d

Role Owner

Contribute to
Workshop and
Finalize Workshop
results

1.e

SAP Security
Admin

Contribute to
Workshop

None

a. Contributes to workshop
Email to BA/BSA formally
summarizing the workshops b. Finalizes the workshop ensures preliminary design is acceptable.
outcome / decision.
a. Provide any technical assistance information on addition
permissions, RolesDB interactions.

24

GRC Training Risk Owners

P.2

Role

Responsibility /
Action

Output

Responsibility / Action

BA/BSA

Design new
Mitigation
Controls

Detailed Workshop results

with all proposed action
items listed and reasons for
rejecting alternatives.

Design the proposed Mitigation approach and detailed activities

required to implement the additional controls :
a. New manual processes
b. New/amended mitigation control reports
c. New/amended SAP enhancements
d. Changes to SAP configuration
e. Additional Permission-level restrictions

2.a-g

BA/BSA

Mitigation
Control
development

New manual process

New mitigation report with
new tcode
System enhancements
Changed SAP configuration
Additional SAP Security
permissions

See details in following 2.a g steps

STEP

2.a.i

BA/BSA

SAP Development
- Prepare MiniSpec

Functional Specification
Test plan

Prepare Functional Mini-Specification for SAP Development :

a. new / amended report
b. new / amended enhancement.
Create or amend a test plan.

[Link]

BA/BSA

IMG configuration
change - Prepare
Mini-Spec

Functional Specification
Test plan

Prepare Functional Mini-Specification for SAP IMG configuration change

Create or amend a test plan.

2.b

BA/BSA

SAP Access
Change Request
additional
permissions

FORM : SAP Access Change

Request

Prepare SAP Access Change Request additional permissions

Create or amend a test plan.

2.c

BA/BSA

Test configuration
and reports

Test results

Test new / amended configuration and reports

25

GRC Training Risk Owners

P.2

Role

Responsibility /
Action

Output

Responsibility / Action

IS&T
Development
or BSA

Develop reports,
enhancements
and make config
changes

New/amended report
New/amended
enhancement
Changed configuration

There are no additional processes here. The standard IS&T processes

apply to these.

Updated
See Process 3. New Users
and User Role Provisioning

For Mitigation-related activities :

Implement and
document new
manual control

Manual Process
documentation
Updated Controls Checklist

Implement and document new manual control.

Ensure all new controls which require periodic review are added to any
Controls Checklist which may be managed for the business area.

STEP
2.d

2.e

SAP Security
Admin

2.f

Role Owner

Amend
permissions
Add tcodes

Amend permission-level data to restrict existing end users

Add new tcodes for Mitigation reports to user roles

BA/BSA

Prepare
Mitigation Control
(MC) request

FORM : Mitigation Control

Request : MC Definition
and/or Assignments

Prepare Mitigation Control (MC) request :

a. New / Amended MC definition with details from Step 2 above.
b. New / Amended MC assignments - MC : Risk/User combinations

Role Owner

Recommend
Mitigation
Controls

Send MC Request as it
should have all the details.
Risk Owner may provide
feedback.

Inform Risk Owner of workshop final outcome confirming the

proposed mitigation approach is still valid.

Approve
Mitigation Control
and Risk/User
assignment

Request to add/amend in GRC

Mitigation Control definition

Mitigation Control
assignment to Risk/User
combination

Enter approved
Mitigation Control
definition and/or
Risk/User
assignments.

Updated MC definition
and/or assignments
Automated email for
assignment changes

Risk Owner

GRC Admin

a. Check final result was as advised from workshop results, review MC

definition and assignment.
b. Request GRC Administrator to update the GRC system with the new
/ amended MC definition and new/amended assignments to users.
Update GRC system :

26

Mitigation Control definition and/or

MC assignments to Risk / User combinations

GRC Training Risk Owners

P.2

Role

Responsibility /
Action

Output

Responsibility / Action

Role Owner

Periodic : Carry
out SOD analysis
and Mitigation
Control review

Signed off Checklist and

supporting documentation
(reports, screen prints etc.)

Role Owner or delegate carry out periodically :

a. Where specifically mentioned in Mitigation Controls, confirm that
general business control processes e.g. Bank Reconciliations are
still in place.
b. Specific Mitigation Control processes (manual or supported by
reports).

Risk Owner

Review results of
mitigation control
processes and
signs off checklist.

Completed and filed

checklist and supporting
documentation.

a. Review results of mitigation control processes and

b. If there is a period review checklist, signs off checklist has been
completed for the period under review.
c. Additionally, check that any exceptions reported were adequately
followed up.

STEP

27

GRC Training Risk Owners

Process 3: New Users and User Role Provisioning

28

MIT SAP Security & GRC Process : 3. New Users & User Role Provisioning
Risk
Owner

8
APPROVE ASSIGNMENT
OF MITIGATION
CONTROL

MITIGATION
CHANGE
REQUEST

Role Owner / User Manager

NEW / AMENDED
USER

3
ROLES DB
UPDATE

2
PREPARE
REQUEST

2A NEW USER
DETAILS

2B CHANGE
DETAILS

NEW HIRE
TEMPORARY STAFFING
CONSULTANTS

TRANSFER IN
TRANSFER OUT
JOB CHANGE
RESIGNATION / TERMINATION
ROLE REDESIGN
LOCK USER
RT ticket

R/3
Security Admin

NEW KERBEROS
USER

1
Warehouse
SAP

NEW
SAP USER

5
ASSIGN / DE-ASSIGN
COMPOSITE ROLE
IN PRODUCTION

End User

GRC / ADMIN

4
RolesDB
SAP
Interface

6
ASSIGN USER TO
CORRECT GRC CUSTOM
USER GROUP

9
ASSIGN / DEASSIGN
USER/RISK TO
MTIGATION CONTROL

7
CONFIRM IN
PRODUCTION

END

GRC Training Risk Owners

Process 3: New Users and User Role Provisioning
The Role Provisioning process described here is primarily for the scenario where SAP User access is assigned or amended, within the current role
definitions. Of course there can be new roles (see process 1) which would require assignment. Secondarily, for completeness, some additional SAP
User administration is briefly included here, and often has to precede the role assignments. Also, the MIT Roles Database is referred to in places, but
its detailed administration is not included in this flowchart, nor is Kerberos Id assignment for new hires etc.
The requirement for SAP Role provisioning changes are most often identified during the following business events:
1
2
3
4
5

Departmental reorganization
New or changed job duties for a user including transfers to different departments / business areas.
New hire
Temporary Staffing, where SAP access is required.
Resignation / termination / semi-permanent leave

Less common situations are:

6
7
8
9

New roles have been defined (see Process 1) - e.g. for new Functionality - which need to be assigned to users
Audits, Compliance and other reviews require changes (usually removal of access, which may also require role redesign)
General role redesign / tidy-up - triggered from technical reviews or MIT RolesDatabase redesign.
Removal of functionality from roles (so usually no SOD risk issues) so they can be assigned more widely.

Additional User provisioning requirements which are not specifically role related:

New and existing users new / changed administrative data: name, address, defaults/PIDs, account number, validity period etc.
Changes to User Group (SAP core) and Custom User Group (in GRC only)
Lock / unlock user
Reset password

Note the following points relating to the VPF business areas which have affected the process of SAP access management:

30

GRC Training Risk Owners

Typically each person has a unique set of job duties, and a Composite Roles is created for this.
o The Composite Role has a number of Single Roles assigned to it.
o So each VPF business area has a number of single roles between 5 and 10 which are combined in different combinations into
Composite Roles to reflect the different job duties.
o Additional common roles can be included in the Composite Role.
o Where access is provisioned from the MIT Roles database, this access is added to the SAP User as an additional Profile and is not
adjusting the single or composite roles definitions as such.
In the cases where there are users with identical access requirements, they have been assigned the same Composite Role.
There are some VPF User FireFighter roles see Process 4 which are used for emergency back-up requirements, rather than building the
access into the regular users role or amending a user.
In general, the process of making minor changes to individual user access has been eliminated. There are tested and complete business roles,
and these are assigned through Composite Roles. So any requested minor access change would be a role change see process 1 unless it was
complete assignment or de-assignment of a role in a Composite role.

Roles & Responsibilities for Process 3:

Risk Owner
Role Owner / User Manager

SAP R/3 Security Admin

GRC Admin

Requests assignment / deassignment of User in GRC Mitigation Control

Requests new SAP user, assignment / deassignment of roles
This includes VPF Roles and IS&T Support roles.
Assignment of Users to GRC EAM FireFighter roles is covered in Process 4.
Several tasks :
Assignment of roles to composite roles and Composite Roles to Users
Performs the maintenance of SAP User admin data
Manages MIT custom RolesDatabase interface to SAP User security.
Manager user-related GRC data at the request of the Risk Owner assignment of Users to MCs

31

GRC Training Risk Owners

Process 3: New Users and User Role Provisioning - Detailed Steps
P.3
STEP

Business Role

Responsibility /
Action

Output

Details

1a

AUTOMATED

KERBEROS
/WAREHOUSE

New SAP User

New SAP User automatically created from various sources, including

Warehouse. Basic admin information and some basic ESS etc. access
profiles are assigned.

2a

Role Owner /
User manager

Request new user

Email / Form with

details

Provide Admin details: Kerberos Id, Name, MIT address, validity period
etc.
Provide Role Assignment information: Composite Role or variation of role
combinations required. Note: if any role changes were required, this
would have gone through Process 1 and 2 first to define the new role,
with any SOD analysis as required.
TEMPORARY STAFFING may need 2 composite roles potential SOD.

2b

Role Owner /
User manager

Request user role

change

Email / Form with

details

2c

Role Owner /
User manager

Request user admin

data change

Email / Form with

details

User manager

RolesDB provisioning

Updated RolesDB

R/3 Security
Admin

RolesDB SAP
interface

Updated User
access

Provide Role Assignment information: Composite Role or variation of role

combinations required. Note: if any role changes were required, this
would have gone through Process 1 and 2 first to define the new role,
with any SOD analysis as required.

Provide changes to User Admin data information rare.

Update RolesDB with required information

Any SAP-relevant RolesDB provisioning will result in the SAP User having
additional profiles assigned, in addition to the profiles generated from
the assigned SAP Security roles.

32

GRC Training Risk Owners

P.3

Business Role

Responsibility /
Action

Output

Details

R/3 Security
Admin

Maintain businessrelated roles to user

Assign Roles for VPF, this is now a Composite Role which has a
number of roles relating to the VPF business area. In some cases, a VPF
user is unique and so effectively has a job or user specific composite role.
o New User : add composite role
o Transfer In : add composite role (confirm removal of ld composite
role)
o Transfer Out : remove composite role
o Job Change : remove old Composite / add new Composite
o Consultants : validity period approval for PRODUCTION access
(several IS&T approvers required)
o Temporary Staff: potential SOD if two composite roles assigned.
o Termination with Prejudice : Lock immediately

GRC Admin

Assign user to GRC

Custom User Group

Updated user
assignment

Assign user to GRC Custom User Group

End User

Confirm access

Email

Confirm changed access in Production

Risk Owner

Approve assignment
of GRC MC

MC change form

Request assignment of Mitigation Control to Risk User combination.

GRC Admin

Update User/Risk ->

MC

GRC updated

Update assignment of Mitigation Control to Risk User combination.

STEP

33

GRC Training Risk Owners

Process 4: FireFighter Users and Roles

34

Business User
changes

FF USER OR
ROLE CHANGES

NEW
FUNCTIONALITY

RT TICKET

RT TICKET

RT TICKET
FF ACTION
REQUIRED

FIRE FIGHTER
CONTROLLER

FIREFIGHTER
OWNER

MIT SAP Security & GRC Process : 4. FireFighter Users and Roles

6
REQUEST
FF ACTION FROM
BA OR BSA

8
REVIEW ,
QUESTION,
FOLLOW-UP

RT TICKET

R/3
Security Admin

1A
CREATE
SAP R/3
FIREFIGHTER ROLES

2
CREATE
SAP R/3
FIREFIGHTER USER

1B
CHANGE SAP R/3
FIREFIGHTER ROLES

NEW
SAP R/3
FIREFIGHTER
USER
FF_XXX_01

3
SAP GRC
SYNCH

GRC ADMIN

TCODE is
Update or
Display ?

Update

Display

END

4A
CREATE
GRC FFID
(SAME ID AS R/3 F
USER)

4B
ASSIGN
GRC FF CONTROLLER
TO
GRC FF ID

1C
UPDATE
IS&T SUPPORT ROLES

SAP R/3
IS&T SUPPORT
USER

4C
ASSIGN
SAP KERBEROS USER
TO
GRC FF ID
AUTO
EMAIL

GRC FF
CHANGE
REQUEST

5A
AMEND USERS
GRC SYSTEM
ACCESS (OWNER,
CONTROLLER,
FIREFIGHTER)

5B
AMEND ASSIGNMENT
GRC FF CONTROLLER
TO
GRC FF ID

ACTION LOG

5C
AMEND ASSIGNMENT
OF SAP R/3 USER
TO
GRC FF ID

FIREFIGHTER

Sent at time
of login
7
USE
LOG INTO R/3
FIREFIGHTER FROM
GRC
BACK-UP FF NEEDED

Log built hourly

Email sent after logout

9
LOG REVIEW
AT ANY TIME

END

GRC Training Risk Owners

Process 4: FireFighter Users and Roles
This section covers the special circumstances where users and roles are created for emergency FireFighter use and for changes to IS&T Support roles.
Where the term FireFighter is used here, it relates to the use of the GRC-EAM (Emergency Access Management) functions which have some special
features which require administration and monitoring.
The features in use at MIT are:

Special SAP R/3 FireFighter Users and Roles typically with limited update functionality. Access rights to the R/3 FF Users are pre-assigned in
GRC-EAM to specific business users who need occasional or emergency access to functions which would otherwise create SOD issues if
permanently assigned. Some Firefighter Users have roles with more access than others - see the various FFID types described below.
The firefighter logs into the GRC-EAM system with their SAP Kerberos User ID run the transaction /n GRAC_SPM; they will see the Firefighter
launch pad, with the pre-assigned FireFighter user. The firefighter logs in to the pre-assigned Firefighter user, which allows them to access SAP
R/3 to perform the emergency or back-up business functions. When finished, they log out of their SAP R/3 session, and then log out of SAP GRC.
o A FFID can be shared, but can only one person can log into it at a time.
o The FireFighter ID Owner determines the appropriate assignment for the Firefighter ID.
o The FireFighter Controller for that FFID is notified when it is used
o The FireFighter User actions are logged and reviewed by FireFighter Controller or Delegate when the Firefighter logs out.
All SAP Users which are set up for FireFighter usage will be named like FF_XXX_NN where XXX = the business area letters (can be a few more
characters if needed) and NN is a sequential number. User Type = SERVICE and special role assigned to identify it as a GRC FireFighter (see step
2A).
Synch job synchronizes R/3 user assignment data with production GRC. The GRC Admin creates a FFID in the
NWBC (NetWeaver Business Client) interface with the same id as the R/3 User. All Firefighter users must have their own personal SAP IDs
manually created in GRC. The different

FFID types have different roles in R/3:

o
o

Business User FFID: has limited update transactions, specific to the business areas or job duties for the users being backed-up. This
would have SODs when combined with business users standard role.
Business Analyst FFID: has update transactions with broad business access roles are either Finance/Logistics or HR/Payroll focused.
Will always have SODs are they are broad access to deal with any issues. At MIT these are Composite Roles combining all the standard
business roles for the business area.

36

GRC Training Risk Owners

o
o
o

Note:
Note:

IS&T BSA FFID and BSA Manager FFID: has update transactions with broad business access roles are either Finance/Logistics or
HR/Payroll focused. Will always have SODs are they are broad access to deal with any issues.
IS&T Basis Admin FFID: has some special access over and above what they already have.
IS&T Developer FFID and Developer Manager FFID: has update transactions with broad business access to deal with any issues and
these will always have SODs. The roles are either Finance/Logistics or HR/Payroll focused and some Developer FFIDs and the Developer
Manager FFID include EDI and Workflow support access,
Support User in IS&T BSA: has display only transactions with broad business access, so should never have an SOD for these.
Regular BA users: display only transactions with broad business access, so should never have an SOD for these.

After the initial FireFighter process set-up, the ongoing administration consists of:

More frequently
Creation of SAP Kerberos ID in GRC for Firefighters
GRC Assignment of SAP Users to FireFighter Ids (adding and removing assignment)
SAP R/3 FireFighter Role maintenance new functionality for the business needs to be added, and discontinued functionality removed.
Less frequently
GRC Assignment / de-assignment of FireFighter Ids to FFID Controllers
New SAP R/3 FireFighter Users when there are additional FFID Controllers

Some additional MIT-specific background points related to FireFighter design:

The FireFighter SAP R/3 users do not have Kerberos ids, so they are created by SAP R/3 Security Admin, and no profiles are provisioned through
Warehouse or RolesDB.
So that automated monitoring of BA and BSA FireFighter Id usage can go to the appropriate business manager, separate FireFighter Users have
been set up for each business area manager (the FFID Controller). Typically the same role is assigned to several FF R/3 Users, as the BA/BSA
needs the same access no matter which manager requested the FireFighter usage.
Use of FF will require an RT Ticket to be created and justification and details of its usage are documented there.

37

GRC Training Risk Owners

GRC FireFighter terminology

R/3 FireFighter User:

FireFighter

- the R/3 User called up by GRC when the FireFighter requests access via GRC it cannot be accessed in SAP R/3 directly.

- the business user, BA or BSA or BSA Manager or IS&T Developer or IS&T Developer Manager, SAPADM user or SAPADM

manager who needs access to the R/3 FireFighter User in Production.

FireFighter Id

FireFighters R/3 Role Owner

- like the standard R/3 Security Role Owner will usually be the same as the FireFighter ID Owner.

FireFighter ID Owner

- requests/approves GRC assignment of Users to FF Ids. GRC functionality for FFID Owner is not being used.

FireFighter ID Controller

- informed of FF usage at start and end of session and reviews logs. Typically the Business Role Owner.

FireFighter ID Controllers Delegate

- the GRC object used to control access to the R/3 FireFighter User it links the R/3 FireFighter User to the FireFighter.

Not currently being used at MIT.

Roles & Responsibilities for Process 4:

SAP R/3 Security Admin

GRC Admin
FFID Owner

FFID Controller

FireFighter

Maintain FireFighter and Support Users in SAP, and their assignment to MIT personnel
Maintain FFIDs and assignments - also can maintain R/3 Users.
Requests user assignment to FFIDs and any new FFIDs
For VPF, this varies per business area. May be Risk Owner or Role Owner.
For IS&T, these are Frank and Siobhan
Review FFID actions.
For VPF, this is Controller or Director level. May be Role Owner or Business Area manager.
For IS&T this is Bart

38

GRC Training Risk Owners

Process 4: FireFighter Users and Roles - Detailed Steps

P.4

Business Role

Responsibility /
Action

Output

Details

1a

R/3 Security
Admin

Create FireFighter
Roles

Roles

There are several types of FF roles :

Business Analysts (BA)
IS&T Business System Analysts (BSA)
IS&T Basis Role
IS&T Developers
IS&T Managers
Business users limited and specific to each requirement (mostly for
back-up)
The Role Provisioning process (requesting, approving, auctioning, and testing)
is no different to any other role except that SOD issues are not relevant.

1b

R/3 Security
Admin

Maintain FireFighter
Roles

Roles updated

Changes should be infrequent, once the system matures :

STEP

Add new Functionality

Remove
The Role Provisioning process (requesting, approving, auctioning, and testing)
is no different to any other role except that SOD issues are not relevant.
There are special designated approvers for changes to FF roles :

1c

R/3 Security
Admin

Maintain IS&T
Support Roles

Roles updated

FFID Owner for BAs

FFID Owner for IS&T FireFighters
FFID Owner for Business FF = Risk Owner of the business area?

IS&T Support Roles

These are Display only roles and are in daily use.

They are not part of the FireFighter control process.

The Role Provisioning process (requesting, approving, auctioning, and testing)

is no different to any other role. There must be NO SOD ISSUES in these
roles.
39

GRC Training Risk Owners

P.4

Business Role

Responsibility /
Action

Output

Details

R/3 Security
Admin

Maintain FireFighter
Users

The R/3 FireFighter Users are generic in that they are assigned to anyone /
more than one person via the GRC system. See Step 4.c
New R/3 FireFighter Users will be infrequent - perhaps if there is a whole new
area of SAP implemented.

STEP
2A

Users updated
Business Roles
assigned
FireFighter role
assigned

Creation of R/3 FF Users is a manual process (cf. regular Kerberos R/3

users are automatically created during MIT on-boarding.)

The R/3 FireFighter User is assigned the special FireFighter role with some
RFC access privileges (identified in the GRC system parameter 4010 as
Z_SAP_GRAC_EAM_FFID). This identifies the FireFighter R/3 User to GRC
as a FireFighter.
Also the User Type = SERVICE, as the login is activated/controlled by a call
from the GRC system when the user logs into the FF ID from GRC.

2B

R/3 Security
Admin

Lock/Unlock R/3
Users

R/3 User locked or

unlocked

Like any other R/3 User, the R/3 FireFighter user can have validity periods (not
used much at MIT) or can be locked / unlocked to control access.

Basis / GRC

Synch systems : SAP

to GRC Repository

GRC = ECC

Users are created in Production so may be locked until needed.

An automated process makes sure that the GRC system has up-to-date
information from SAP R/3 about roles and users. In this case, specific to
FireFighters :

40

The FireFighter R/3 User needed for step 4.A

The Business R/3 Users are needed for step 4A, 4B and 4C
Any new FireFighter roles in case GRC-ARA analysis is needed (not at
MIT).

GRC Training Risk Owners

P.4

Business Role

Responsibility /
Action

Output

Details

GRC Admin

Maintain FFIDs

The GRC FFID attribute settings are central to the control and usage of the
FireFighter roles in R/3

STEP
4A

FF Ids in GRC-EAM

In this step the following updates are made in the GRC-EAM system :
o The FFID is created with the same naming convention as the SAP
R/3 FireFighter user - like FF_FAR_01.
o The FFID is assigned to the matching SAP R/3 FireFighter User.
o The FFID is assigned to an FFID Owner at MIT this is mostly for
information only, as the FFID Owner will not be logging in to GRC
to maintain user assignment.
o Additional information for the FFID can be added if required.
The GRC FFIDs are mostly set up during the initial phase of the GRC project,
and is related to the business organization, so additions will be less frequent.
4B

GRC Admin

Assign FFID
Controllers

FF Id assigned to
FFID Controller
(SAP R/3 User)

GRC Admin

Assign FFID to SAP

Users

NOTE : FFID
Controller
Delegates not
currently used at MIT
4C

In this step an FFID is assigned an FFID Controller (which is another R/3 User) :

FF Id assigned to
SAP R/3 Users

The FFID Controller is emailed when the FFID user logs in and logs out
with a link to the FFID detailed usage logs after logging out.
For the VPF business areas, the VPF business managers are the FFID
Controllers for the Business FF, BA FF and BSA FF.
For non-VPF areas, there are FFID Controllers in IS&T so that the BSA FFID
usage can be monitored.

In this step an FFID is assigned the R/3 User who is the actual FF person - and
this is a different R/3 user than the FFIDs Controller.
An FFID can be assigned to several R/3 users
An R/3 User can be assigned to several FFIDs
The assignment can be for a limited period.

41

GRC Training Risk Owners

P.4

Business Role

Responsibility /
Action

Output

Details

5A

GRC Admin

Grant appropriate
access to the GRC
system

Assign GRC access

rights to R/3 Users

There are several types of GRC users who need specific access privileges in
GRC predefined in GRC access roles :
a. FFID Owners (although MIT is not really using this feature) GRC
Role = Z_FFID_OWNER
b. FFID Controllers GRC Role = Z_FF_CONTROLLER
c. FFID Users those who have to log in to the FFID. GRC Role =
Z_FF_ENDUSER
d. Other MIT users who may want to run FF-related reports.
This data will typically need updating as users change their job positions or
when they join / leave the MIT workforce.

5B

GRC Admin

Amend FFID /
Controller
assignment

FF Id assigned to
different Controller

This assignment will typically need updating where the FFID Controller
changes jobs, leaves MIT or if there is a Departmental Reorganization.
o Change the assignment (an FFID has only one Controller)
An RT Ticket is required, plus a new Form GRC FireFighter ID Assignment
Change request.
Note: if this reassignment is made after the event, the FFID logs can still be
reviewed through FRC-EAM reporting.

5C

GRC Admin

Amend FFID / SAP

User assignment

FF Id assigned to
different SAP Users

This assignment in GRC will need updating when the R/3 User changes jobs,
leaves MIT or perhaps if there is a Departmental Reorganization.
o Add an assignment with a future Valid From date if known in
advance.
o Remove an assignment ad amend the Valid To date if move is
know in advance?
An RT Ticket is required, plus a new Form GRC FireFighter ID Assignment
Change request.

STEP

42

GRC Training Risk Owners

P.4

Business Role

Responsibility /
Action

Output

Details

FireFighter
Controller /
Business
Manager

Request FF usage

RT ticket

An RT Ticket is required where the business manager has requested support

from BA/BSA etc. - with justification and details of expected usage.

7a

SAP User

Log into the FFID

RT ticket, if not
already created
Email to FFID
Controller

The Business FireFighters performing back-up / unusual work do not need a

ticket. Otherwise there is an RT Ticket either from step 6. or created by the
BA or BSA based on email from the Business Manager (FireFighter Controller).
Also, a Reason Code is selected when logging in to the FFID, and additional
information can be entered by the FireFighter.
When the FFID is used,

STEP

7b

SAP User

Log out of the FFID

an email is sent immediately to the FFID Controller

an activity log is started and is updated hourly

Where there is an RT Ticket, any additional / unexpected FireFighter usage

will be noted on the RT ticket by the FireFighter.
When the user logs out of the FFID, within the hour the activity log is updated
and an email is sent to the FFID Controller with a link to the Activity Log for
that FFID and time period it was used.

43

GRC Training Risk Owners

P.4

Business Role

Responsibility /
Action

Output

Details

FFID
Controller

Review, Question,
Follow-up

STEP
8

Approval or action
list

Reporting
Actions

Review FFID usage

and Activity Logs at
any time

Reports some of
the standard
reports will be used
Log Summary and
Consolidated Log
(see next two
pages)

44

The email from GRC to the FFID Controller is a request for approval and a
link to the details action log.
Action logs are reviewed looking for unusual activities in general, and
activities inconsistent with the
o Business FireFighters have limited, pre-approved access, so it is
unlikely that anything will result from review of the logs alone.
o For the other FireFighters, any master data changes or financial
postings need to be reviewed and approved a common
technique for this is printing the log and initialing each line that
was verified. In SAP the master data change history and financial
documents are available for review at any point afterwards.
The reviewers options are to :
o Request the FireFighter to provide more details
o Approve the whole log.
o Hold the log i.e. not approve it yet. The work item will stay in
their GRC inbox for subsequent processing.
Additional notes can be made on the log for any action to be taken.

GRC Training Risk Owners

45

GRC Training Risk Owners

46

GRC Training Risk Owners

Process 5: Periodic Compliance Reviews

47

RISK OWNER
OR DELEGATE

MIT SAP Security & GRC Process : 5. Periodic Compliance Reviews

M2
REVIEW
MITIGATION
REPORTS

ACTION
REQUIRED ?

ROLE OWNER

YES

M1
RUN & REVIEW
MITIGATION
REPORTS

Q 10
MONITOR STATUS

FIN
NO

Step
Q4

A3
APPROVE
RECERTIFICATION OF
GRC MITIGATION
ASSIGNMENTS

FIN

Q2
REVIEW
SOD ANALYSIS

M3
TAKE REMEDIAL
ACTION

REMEDIATION
REQUIRED ?

YES

NO

NEW
MITIGATION
REQUIRED ?

NO

STATUS
EMAIL

STATUS
EMAIL

YES
Q4
PROCESS 2
MITIGATION
ANALYSIS &
ASSIGNMENT

A
MONTH-END

Q5
REVIEW
ROLE & USER
ASSIGNMENTS

Step
A3

ACTION
REQUIRED ?

A2
PROPOSE
RECERTIFICATION OF
GRC MITIGATION
ASSIGNMENTS

NO
MEETING

SOD
COORDINATOR

R/3 SECURITY & GRC

ADMIN

YES
RT
TICKET

RESULTS IN
UPDATED
GRC MCS

Q3
ROLE
MAINTENANCE
AND / OR
PROVISIONING

NEW OR
AMENDED
GRC-ARA
MITIGATION
CONTROL

RT
TICKET

Q8
PROCESS 4
FIREFIGHTER
MAINTENANCE

A1
PROVIDE A LIST OF
MITIGATING
CONTROL
ASSIGNMENTS

Q6
PROCESS 3
ROLE
PROVISIONING

GRC-ARA
REPORT
ANALYSIS

C
ANNUAL
RT
TICKET

B
QUARTER END

Q1
RUN
GRC-ARA RISK
ANALYSIS

Q9
COORDINATE AND
VERIFY COMPLETION

FIREFIGHTER
OWNER

NO
Q7
REVIEW
FFID
ASSIGNMENTS

FF CHANGE
REQUEST

YES

ACTION
REQUIRED ?

GRC Training Risk Owners

Process 5: Periodic Compliance Reviews
This section covers the different activities which are periodically carried out to ensure the mitigation controls are in place and the various access-related
and mitigation-related user assignments are still valid.
1. Monthly

: Operation and verification of Mitigation Controls, including :

1.1. Reports specifically designed to provide mitigation control for SOD issues or monitoring Critical Actions
1.2. Other general business controls (typically reports) which were incorporated in the Mitigation Control definition.
2. Quarterly
2.1.
2.2.
2.3.
2.4.

GRC-ARA
GRC & R/3
GRC-ARA
GRC-EAM

3. Annual

: Access Analysis , including :

- reviewing Access Risk Analysis (SOD and Critical Action) reports
- checking User / Role and Role / User assignments and Single Role / Composite Role assignments
- checking User / Risk to Mitigation Control assignments
- checking FireFighter and FireFighter Controller assignments
: recertification of GRC Mitigation Controls

3.1. GRC-ARA - recertification of GRC Mitigation Controls definitions

Roles & Responsibilities for Process 5:

SAP R/3 Security Admin

GRC Admin
FFID Owner
Role Owner
Risk Owner
SOD Coordinator

Maintain FireFighter and Support Users in SAP, and their assignment to MIT personnel
Assist in the review of FFIDs assignments and Mitigating Control Assignments.
Ensure all FFIDs are correctly assigned to Controllers and to FireFighters (Business, BA, BSA, IS&T Manager, etc.)
Ensure all owned roles assignments are valid, and all users for that business area have appropriate roles
Check that mitigation controls are in place and operating effectively.
Execute GRC-ARA reports and provide interpretation to Role Owner and Risk Owner.

49

GRC Training Risk Owners

Process 5: Periodic Compliance Reviews - Detailed Steps

P.5

Business Role

STEP

MONTHLY

M1

ROLE OWNER

Responsibility /
Action

Output

Details

Review mitigation
reports

Mitigation reports

M2

RISK OWNER

Ensure all mitigation

controls are in place
and functioning

Signed-off checklist
Email to SOD Coordinator

50

Mitigation reports may be specific for GRC issues or general

(existing for the business).
The reports may be executed by different people, but the Role
Owner / Business Area manager brings them all together and
checks for explanations and follow-up actions.
The assumption is that the Mitigation Control report identified
some unusual activity (master data creation/changes and/or
financial postings). This would be followed up by Role owner to
determine if it was
o unusual but not an issue
o a mistake which may or may not need correcting /
reversing / reposting
o a deliberate attempt
Role owner (usually a business area manager) or delegates run the
Mitigation Control reports for the SAP users in their business area.
These list out, per user, any unusual activity related to the specific
SOD risk.

GRC Training Risk Owners

P.5

Business Role

Responsibility /
Action

Output

Details

M3

ROLE OWNER

Take remedial action

Depends on the issue

Role owner and Risk Owner decide on any remedial action. This
may include :
o Correcting / reversing / reposting data
o Better training / job aids
o Amending the Mitigation Control report to filter out the
exact item if it is not so unusual.
o Worst case : investigate the historical posting activity of
the user

QUARTERLY

Q1

SOD
COORDINATOR

Execute and interpret

the GRC-ARA risk
analysis reports

Execute GRC-ARA Report 12 - Risk Analysis User level for each

User Group or for each Custom User Group to show any
unmitigated risks
o Note: use option Show All Objects to ensure all users are
listed with or without violation.
Prepare a summary document providing interpretation of any SOD
or Critical Risk results.
If this is a new issue, also determine what has changed in the
users access to trigger this.
Assist Risk Owner with interpretation of the four recommended
Access Dashboard Reports:
o GRC Report 1 Risk Violations
o GRC Report 2 User Analysis
o GRC Report 3 Violations Comparisons
o GRC Report 4 Access Rule library

STEP

GRC-ARA report
Analysis interpretation

51

GRC Training Risk Owners

P.5

Business Role

Responsibility /
Action

Output

Details

ROLE OWNER

Review analysis and

initiate action

STEP
Q2

Sign-off
Request for action where
required
Email final status to SOD
Coordinator

Role Maintenance
Role Provisioning

ROLE OWNER
RISK OWBER
BA AND BSA
GRC ADMIN

GRC Mitigation
Control definition ,
approval,
maintenance and
assignment

Q5

ROLE OWNER

Validate role and

user assignments

GRC reports
If required, request for
role provisioning change

Q6

R/3 SECURITY
ADMIN

Amend role
provisioning to user

Amended user access

Q3

Q4

R/3 SECURITY
ADMIN

Provide a sign-off where there were no unmitigated risks (i.e. a nil

report)
Assist the SOD Coordinator to review any new issues which would
have occurred because of deliberate or accidental changes :
o User has new roles assigned (e.g. their composite role has
a new role assigned)
o One of the users roles has new actions or permissions
o User has new profiles from RolesDatabase
Initiate any request for :
o Role amendments
o Role provisioning amendments
o Mitigation Control creation and assignment to Risk/User.

Amended roles or
composite roles
Amended user/role
assignments

See GRC Process 3 for details.

New or existing Mitigation

Controls defined and
assigned in GRC

See GRC Process 2 for details, including :

52

Definition, review and approval (business side)

Creating a new GRC Mitigation Control definition in GRC
Assigning the Mitigation Control to the Risk / User combination.

NOTE : MONTHLY FOR NEW SYSTEM MOVE TO QUARTERLY

Several GRC and R/3 SUIM reports will be used for this:
o Roles for a User
o Users for a Role

See details of Process 3: New Users and User Role Provisioning

GRC Training Risk Owners

P.5

Business Role

Responsibility /
Action

Output

Details

FIRE FIGHTER ID
OWNER

Confirm FFID
assignments to
Controllers and
FireFighters

STEP
Q7

Confirmation of
assignments
If required, request to
amend assignments

Q8

GRC ADMIN

Amend FFID
assignments

Report showing updated,

correct assignments

Q9

SOD
COORDINATOR

Quarterly GRC
Review Status &
Closure

Email to Risk Owners

Q10

RISK OWNER

Status monitoring

N/A

ANNUAL

A1

GRC ADMIN

Provide information
on MC assignments

Risk / User Mitigation

Control report

53

GRC-EAM Reports
o FFID controller assignment (business manager)
o FFID user assignment (business user, BA, BSA, BSA
manager, Developer etc.)
A change request will be need for any changes :
o FFID Controllers may have transferred / resigned / retired
o Firefighters may have transferred / resigned / retired

See GRC Process 4: FireFighter Users and Roles.

Summary of results and action items (closed or still open) for the
review per risk owner.

Maintain awareness of status of the review.

Monitor the overall situation with the four recommended Access
Dashboard Reports (assisted by SOD Coordinator) :
o GRC Report 1 Risk Violations
o GRC Report 2 User Analysis
o GRC Report 3 Violations Comparisons
o GRC Report 4 Access Rule library

Generate the Risk / User Mitigation Control report per Risk

Owner
o GRC-ARA Report 11a Mitigation Control Report = List
o GRC-ARA Report 11b Mitigated Object Report
Report by User / User Group
o GRC-ARA Report 12 Risk Analysis User level
Run with option showing Invalid users assignments
(MC assigned but no longer have the risk).

GRC Training Risk Owners

P.5

Business Role

Responsibility /
Action

Output

Details

ROLE OWNER

Review and propose

recertification

STEP
A2

A3

RISK OWNER

54

Identify any MCs that are no longer in place - rare

Identify any assignments that are no longer valid these will not
be recertified should be unusual, but could be due to job
transfers / resignations not fully processed.
Propose the recertification list to the Risk Owner

Review and approve recertification list.

Advise GRC Admin to recertify the MCs

GRC Training Risk Owners

GRC Reporting

55

GRC Training Risk Owners

Job Aids

56

GRC Training Risk Owners

PURPOSE OF THIS DOCUMENT

Procedures on execution of each of the GRC Reports in scope for Business Analysts are documented in reporting Job
Aids. The Job Aid for each report provides details on execution for each step of the report. For some reports, multiple
report execution scenarios have been identified.
CONTENTS
01 Risk Violations
02 User Analysis
03 Violations Comparisons

57

GRC Training Risk Owners

Job Aid 01 Risk Violations

USE
This report can be used to gain insight into MITs overall exposure to risk. The report provides an overview of risk violations across all MIT ECC systems.
INFORMATION
Risk count by risk level and process.
RELATED PROCESSES

Process 5: Periodic Compliance Reviews

SPECIFIC SCENARIOS

Step 14A: Analyze report data by Risk Level. (Pie Chart)

Step 14B: Analyze report data by Business Process. (Table)
Step 14C: Analyze report data by Business Process. (Bar Graph)

58

GRC Training Risk Owners

Step
1

Description
Navigate to the Reports
and Analytics tab.

Click on the Risk Violations

report located in the Access
Dashboards section.

Screenshot

59

GRC Training Risk Owners

The report will show risk

violations information for
the latest period, across all
systems (to which GRC is
connected) and user groups,
at the user level. The count
will be given by permission
(i.e. each instance of a
violation will be counted,
even if it is a repeated
violation for a user).
The report data must be
appropriately filtered to
provide information that
can be of use to MIT.

60

GRC Training Risk Owners

In the report filters section,

click on the drop down for
Year/Month to select the
time period for which data
is required. In this case,
2013/05 is selected.

61

GRC Training Risk Owners

In the report filters section,

select the system for which
information is required.
Click on the search icon next
to System. Since the
desired selection is PS1
(Production), select the
connector for PS1. Click on
OK.

62

GRC Training Risk Owners

In the report filters section,

click on the drop down for
Analysis Type to select the
security object (user, role or
profile) for which data is
required. In this case, User
is selected.

63

GRC Training Risk Owners

In the report filters section,

select the user group for
which information is
required. Click on the search
icon next to User Group.
Enter search criteria to
search for the desired user
group. In this case, VPF-T*
is entered to search for all
VPF user groups starting
with T.
Click on Start Search.
Select the desired user
group from the search
results. In this case, VPFTAX is selected.
Click on OK.

64

GRC Training Risk Owners

In the report filters section,

click on the drop down for
Violation Count by to
select the count
methodology required for
the report. In this case,
Access Risk is selected to
count unique violations per
user.

Click on Go to execute the

report based on the criteria
that have been defined.

65

GRC Training Risk Owners

10

The report shows that there

are a total of 4 users in the
VPF-TAX user group. The
report also shows that these
4 users have 0 unmitigated
violations. No pie chart,
business process table, or
business process bar graph
are shown due to the fact
that the violation count is 0.

66

GRC Training Risk Owners

11

In the report filters section,

select another user group
for which information is
required. Click on the search
icon next to User Group.
Enter search criteria to
search for the desired user
group. In this case, VPF-T*
is entered to search for all
VPF user groups starting
with T.
Click on Start Search.
Select the desired user
group from the search
results. In this case, VPFTRAVEL is selected.
Click on OK.

67

GRC Training Risk Owners

12

Click on Go to execute the

report based on the
updated criteria that have
been defined.

68

GRC Training Risk Owners

13

The report shows that there

are a total of 8 users in the
VPF-TRAVEL user group.
The report also shows that
these 8 users have 12
unmitigated violations.
The graphic displays are
populated based on
information regarding the
12 unmitigated violations.
The User Level analysis
report (12), reports that:
8 users have
unimitigated Basis
Critical Transactions
2 users have
unmitigated Finance
SODs
2 users have
unmitigated
Procure to Pay SODs

69

GRC Training Risk Owners

14A-1

Analyze report data by risk

level.
Scroll over the different
pieces of the pie chart to
see information about
unmitigated violations at
each risk level.
Click on the Medium risk
level piece of the pie chart
for more information about
medium risks.

70

GRC Training Risk Owners

14A-2

Analyze the data. This data

can also be exported. See
the Export Data from GRC
reference document (R8) for
further information.
Access Risk: The 4-digit ID
representing each mediumrisk (as defined in the
standard rule set) for which
violations exist
Description: Business
description of the Access
Risk
Business Process: The 4digit ID representing the
Business Process to which
the Access Risk has been
mapped in the standard rule
set
Business Process
Description: The business
description for the Business
Process to which the Access
Risk has been mapped in
the standard rule set
No. of Violations: The
number of violations for
each Access Risk that exist

71

GRC Training Risk Owners

14A-3

Click on the No. of

Violations link for each
Access Risk to view the
Users that have violations
for that Risk. In this case,
clicking on 1 for Access
Risk F028 shows the 7 VPFTRAVEL Users that have
related violations.

72

GRC Training Risk Owners

14B-1

Analyze report data by

Business Process.
Scroll over the different line
items of the Business
Process Table to see
information about
unmitigated violations for
each Business Process.
Click on the Finance risk
level row of the Table for
more information about
Finance Risks.

73

GRC Training Risk Owners

14B-2

Analyze the data. This data

can also be exported. See
the Export Data from GRC
reference document (R8) for
further information.
Access Risk: The 4-digit ID
representing each FinanceRisk (as defined in the
standard rule set) for which
violations exist
Description: Business
description of the Access
Risk
Risk Level: The risk level
defined for each Access Risk
in the standard rule set
No. of Violations: The
number of violations for
each Access Risk that exist

74

GRC Training Risk Owners

14C-1

Analyze report data by

Business Process.
Scroll over the different bars
of the Business Process Bar
Graph to see information
about unmitigated
violations for each Business
Process.
Click on the BS00 Risk bar
of the Graph for more
information about Basis
Risks.

75

GRC Training Risk Owners

14C-2

Analyze the data. This data

can also be exported. See
the Export Data from GRC
reference document (R8) for
further information.
Access Risk: The 4-digit ID
representing each Basis-Risk
(as defined in the standard
rule set) for which violations
exist
Description: Business
description of the Access
Risk
Risk Level: The risk level
defined for each Access Risk
in the standard rule set
No. of Violations: The
number of violations for
each Access Risk that exist

76

GRC Training Risk Owners

Job Aid 02 User Analysis

USE
This report can be used to gain insight into MITs overall exposure to risk. The report provides an overview of user violations across all MIT ECC systems.
INFORMATION
Risk count by risk type and user.
RELATED PROCESSES

Process 5: Periodic Compliance Reviews

SPECIFIC SCENARIOS

Step 13A: Analyze report data by Mitigated Users. (Pie Chart)

Step 13B: Analyze report data by Risk Level. (Pie Chart)
Step 13C: Analyze report data by Critical Actions, Roles and Profiles. (Bar Graph)

77

GRC Training Risk Owners

Step
1

Description
Navigate to the Reports
and Analytics tab.

Click on the User Analysis

report located in the Access
Dashboards section.

Screenshot

78

GRC Training Risk Owners

The report will show risk

violations and critical
actions, roles and profiles
information for the latest
period, across all systems
(to which GRC is connected)
and user groups, at the user
level. The violation count
will be given by permission
(i.e. each instance of a
violation will be counted,
even if it is a repeated
violation for a user).
The Critical Actions and
Roles section will state the
number of each that were
evaluated for the selected
user group.
The report data must be
appropriately filtered to
provide information that
can be of use to MIT.

79

GRC Training Risk Owners

In the report filters section,

click on the drop down for
Year/Month to select the
time period for which data
is required. In this case,
2013/05 is selected.

80

GRC Training Risk Owners

In the report filters section,

select the System for which
information is required.
Click on the Search icon
next to System. Since the
desired selection is PS1
(Production), select the
Connector for PS1; if
necessary, *PS1* can be
used as search criteria to
find the correct connector
for PS1. Click on OK.

81

GRC Training Risk Owners

In the report filters section,

select the user group for
which information is
required. Click on the
Search icon next to User
Group.
Enter search criteria to
search for the desired user
group. In this case, VPF-T*
is entered to search for all
VPF user groups starting
with T.
Click on Start Search.
Select the desired user
group from the search
results. In this case, VPFTAX is selected.
Click on OK.

82

GRC Training Risk Owners

In the report filters section,

click on the drop down for
Violation Count by to
select the count
methodology required for
the report. In this case,
Access Risk is selected to
count unique violations per
User.

Click on Go to execute the

report based on the criteria
that have been defined.

83

GRC Training Risk Owners

The report shows that there

are a total of 4 Users in the
VPF-TAX user group. The
report also shows that these
4 Users all have mitigated
violations.
In the Critical Actions and
Roles section, the report
shows:
4 Users were
analyzed
The users were
evaluated for
violations against
775 Critical Actions
and 1 Critical
Role/Profile
0 VPF-TAX Users
have Critical Actions
0 VPF-TAX Users
have Critical
Roles/Profiles

84

GRC Training Risk Owners

10

In the report filters section,

select another user group
for which information is
required. Click on the
Search icon next to User
Group.
Enter search criteria to
search for the desired user
group. In this case, VPF-T*
is entered to search for all
VPF user groups starting
with T.
Click on Start Search.
Select the desired user
group from the search
results. In this case, VPFTRAVEL is selected.
Click on OK.

85

GRC Training Risk Owners

11

Click on Go to execute the

report based on the
updated criteria that have
been defined.

86

GRC Training Risk Owners

12

The report shows that there

are a total of 8 Users in the
VPF-TRAVEL user group.
The report also shows that
these 8 Users have 11
mitigations, as well as 11
instances (9 High Risk + 2
Medium Risk) of Users with
unmitigated violations.
NOTE: Each type of
Violation SOD, Critical
Transaction, etc. is
counted only once per User.
Thus, a User with only 2
SOD, contributes 1 to the
violation count. And a User
with 1 SOD and 1 Critical
Action, contributes 2 to the
violation count.
In the Critical Actions and
Roles section, the report
shows:

8 users were analyzed

The users were
evaluated for
violations against 775
Critical Actions and 1
Critical Role/Profile
8 VPF-TRAVEL users
have Critical Actions
0 VPF-TRAVEL users
have Critical
Roles/Profiles

87

GRC Training Risk Owners

13A-1

Analyze report data by

mitigated users.
Scroll over the different
pieces of the pie chart to
see information about
mitigated violations as well
as unmitigated violations at
different risk levels.
Click on the Mitigated
Users piece of the pie chart
for more information about
VPF-TRAVEL users that have
Mitigated Risks.

88

GRC Training Risk Owners

13A-2

Analyze the data. This data

can also be exported. See
the Export Data from GRC
reference document (R8) for
further information.
User ID: User ID of the user
with a Risk that has been
mitigated
User Name: User name
associated with the user ID
User Group: User group
code
Access Risk ID: The 4-digit ID
representing each mediumrisk (as defined in the
standard rule set) for which
violations exist
Risk Description: Business
description of the Access
Risk
Control: The 10-digit ID
representing the Mitigating
Control applied for the User
with the Access Risk
Monitor: The user ID of the
Monitor responsible for the
Mitigating Control
89

GRC Training Risk Owners

13B-1

Analyze report data by risk

level.
Click on the High risks
piece of the pie chart for
more information about
VPF-TRAVEL Users that have
high risk level risks.

90

GRC Training Risk Owners

13B-2

Analyze the data. This data

can also be exported. See
the Export Data from GRC
reference document (R8) for
further information.
User ID: User ID of the user
with a Risk that has been
mitigated
User Name: User name
associated with the user ID
User Group: User group code
Access Risk ID: The 4-digit ID
representing each medium-risk
(as defined in the standard rule
set) for which violations exist
Risk Description: Business
description of the Access Risk
Business Process: The 4-digit ID
representing the Business
Process to which the Access
Risk has been mapped in the
standard rule set
Business Process Description:
The business description for
the Business Process to which
the Access Risk has been
mapped in the standard rule
set

91

GRC Training Risk Owners

13C-1

Analyze report data by

Critical Actions, Roles and
Profiles.
Scroll over the different bars
of the Bar Graph to see
information about Critical
Actions and Critical
Roles/Profiles.
Click on the Critical Actions
bar of the Graph for more
information about Critical
Actions violations.

92

GRC Training Risk Owners

13C-2

Analyze the data. This data

can also be exported. See
the Export Data from GRC
reference document (R8) for
further information.
User ID: User ID of the user
with a Risk that has been
mitigated
User Name: User name
associated with the user ID
User Group: User group
code
Access Risk ID: The 4-digit ID
representing each mediumrisk (as defined in the
standard rule set) for which
violations exist
Risk Description: Business
description of the Access
Risk

93

GRC Training Risk Owners

Job Aid 03 Violations Comparisons

USE
This report can be used to gain insight into the progress MIT is making with respect to reducing and mitigating risk exposure. The report provides an
overview of violations remediation/mitigation progress.
INFORMATION
Violation count and comparison over time.
RELATED PROCESSES

Process 5: Periodic Compliance Reviews

SPECIFIC SCENARIOS

N/A

94

GRC Training Risk Owners

Step
1

Description
Navigate to the Reports
and Analytics tab.

Click on the Violations

Comparisons report located
in the Access Dashboards
section.

Screenshot

95

GRC Training Risk Owners

The report will show risk

violations information over
time, across all systems (to
which GRC is connected) on
a monthly basis, at the user
level. The count will be
given by permission (i.e.
each instance of a violation
will be counted, even if it is
a repeated violation for a
user).
The report data must be
appropriately filtered to
provide information that
can be of use to MIT.

96

GRC Training Risk Owners

In the report filters section,

click on the drop down for
Calendar Type to select the
reporting periods by which
data will be reported. In this
case, Monthly is selected.

97

GRC Training Risk Owners

In the report filters section,

click on the drop down for
From to select the start of
the time period for which
data is required. In this case,
2013/01 is selected. Next,
click on the drop down for
to to select the end of the
time period for which data
is required. In this case,
2013/05 is selected.

98

GRC Training Risk Owners

In the report filters section,

select the System for which
information is required.
Click on the Search icon
next to System. Since the
desired selection is PS1
(Production), select the
Connector for PS1; if
necessary, *PS1* can be
used as search criteria to
find the correct connector
for PS1. Click on OK.

99

GRC Training Risk Owners

In the report filters section,

click on the drop down for
Analysis Type to select the
Security Object (User, Role
or Profile) for which data is
required. In this case, User
is selected.

In the report filters section,

click on the drop down for
Violation Count by to
select the count
methodology required for
the report. In this case,
Access Risk is selected to
count unique violations per
User.

100

GRC Training Risk Owners

Click on Go to execute the

report based on the criteria
that have been defined.

101

GRC Training Risk Owners

10

The report shows the steady

decrease in Access Risk
violations in MITs
Production System since the
start of the SOD/GRC
initiative. A cleanup of the
majority of the VPF Areas
has yeilded a cleanup of
12% of the PS1 system.

102

GRC Training Risk Owners

Reference Aids

103

GRC Training Risk Owners

PURPOSE OF THIS DOCUMENT

Procedures on repetitive tasks and actions related to GRC Reports are documented in reporting Reference Aids. Each
Reference Aid provides details on execution for a particular repeated action.
CONTENTS
R1 Access GRC Reporting

104

GRC Training Risk Owners

Reference R1 Access GRC Reporting

Step
1

Description
Install Mozilla Firefox ESR
(Extended Support Release)
17 by pressing Ctrl + Click on
the link.
Click the Download button
next to Firefox 17 ESR for
Windows.

Screenshot
[Link]

You will see a pop-up

message.
Click the Run button.

105

GRC Training Risk Owners

A Running Security Scan

message will appear at the
bottom of the screen.
Then the Mozilla Firefox
Setup Window will appear.
Click Next.

106

GRC Training Risk Owners

Leave the Setup Type option

as Standard, which is the
default.
Click Next.

107

GRC Training Risk Owners

A screen with the

installation location on the
C drive will appear.
Click the Upgrade or Install
button.

108

GRC Training Risk Owners

The Firefox Installation will

run for a few seconds.
Leave the Launch Firefox
Now button selected.
Click the Finish button.

The installation will

complete, and you will
should the Mozilla Firefox
icon in the upper left corner
of the MIT homepage.

109

GRC Training Risk Owners

10

If you do not see the Firefox

icon there, go to
Start/Programs/Firefox, or
double-click on the Firefox
icon on the taskbar.
Paste the URL for
NetWeaver Business Client
(NWBC) for GRC Test/QA
into your Firefox browser.

[Link]

110

GRC Training Risk Owners

11

You will see a pop-up

message requesting you
select your certificate for
the browser.
Click OK.

111

GRC Training Risk Owners

12

Please Note: If you receive

an error related to not
having a valid certificate for
Firefox, enter the URL below
into your browser.
[Link]
In the fields under Identify
Yourself, enter your Name,
Kerberos ID, and Employee
ID.
Click Next.
You will see your Certificate
appear.
Click OK.

112

GRC Training Risk Owners

13

The NetWeaver Business

Client (NWBC) screen will
open.
Select the Reports and
Analytics Tab at the top.
This is where we will start
running GRC Reports during
GRC training class.

14

If you see a message in the

upper left corner of the
NWBC screen at any time
which says Firefox
prevented this site from
opening a pop-up window,
click the Options button in
the upper right corner, and
select Always allow for the
site [Link].

113

GRC Training Risk Owners

GRC Terminology
Term

Short term

Action

Source

Meaning

Example

GRC

A business function step, usually an SAP ECC transaction code.

FB01 Post an FI Document

F-65 Park an FI Document
ME21 Create a Purchase Order

Action Level

Access Risk

Risk

GRC

Term for analysis of risks at the SAP transaction code level, without
looking at additional permissions (R/3 authorizations) which could
otherwise eliminate the risk.

GRC

A GRC Access Risk is a description of a unique situation a Critical

Action /Role or a Segregation of Duties (SOD) breakdown.

The system has a delivered set of critical technical actions

(like SE16, SM30 to amend database files) and roles, and
these can be added to.
The SOD risk will always have two parts, like Create Fictitious
Vendor and Enter a fictitious Invoice. Each SOD Access Risk
can be assigned a Risk level and can be activated /
deactivated.

There is a pre-defined list of 454 SOD risks - each has a combination

of conflicting GRC Functions assigned, or a critical action and its
related permission.
Access Risk Analysis

ARA

GRC

The part of the GRC package which is used to analyze for access risks
- specifically access to powerful / critical transactions and
Segregation of Duties (SOD) breakdowns.

114

SOD Risk H0164

is the combination of :
Function HR03 Modify Employee
Payroll Data
AND
Function HR14 Enter time data

GRC Training Risk Owners

Term

Short term

Source

Meaning

Example

Access Rule

Rule

GRC

A system-generated object with a single pair of tcodes & related

permissions, based on the combination of GRC Functions which were
defined as the Access Risk. Each Access Risk has one or more
Access Rules generated for it.

Access Risk F028 is defined as

having access to both Function
AP02 (47 tcodes) AND Function
GL01 (69 tcodes) together. So
Access Risk F028 has over 3200
generated Access Rules.

Access Rule set

Rule set

GRC

A pre-defined set of :

GLOBAL
ZAUDIT

Access Risks and assigned Function combinations, against which

a User or Role can be checked for potential SOD breakdown
issues.
Critical roles, critical profiles and critical actions mostly focused
on semi-technical system access.

A system may have several rule sets, e.g. SAP-delivered, External

Audit, MIT modified, and the risk analysis reports can be run using
any one rule set at a time. Also, rule sets can be compared to each
other for differences.
Authorization
Profiles

Profiles

SAP

In earlier SAP releases, a users access was defined through creating

and assigning manually created Authorization Profiles. The current
SAP release defines user access by having job-related Roles from
which the R/3 Security Profile Generator then generates a large
Profile (for each Role). Thus, when a Role is assigned to a user, the
corresponding Profile is also assigned and the system uses this to
determine the users authorized access.
At MIT, the process of creating Authorization Profiles without an
associated Role has to be continued for those parts of SAP R/3
access which are provisioned from the RolesDB system.

115

SAP_ALL
Z#:JV_FY

GRC Training Risk Owners

Term

Short term

Source

Meaning

Business Analyst

BA

MIT

The VPF Business Analyst (BA) is a member of the VPF Financial

Systems and Data team who helps in the operational management
of financial systems, processes, reporting, and data.
Also, the BA supports the GRC/SOD review process by validating the
business access requirements in the area they support.

Business End User

End User

MIT

An SAP system user for whom access needs to be provided.

GRC

A very high level categorization which is used to group Access Rules.

MIT

IS&T Business System Analyst IS&Ts counterpart to the VPF

Business Analyst providing more technical support, or can be both
the BA and BSA support in areas where there is no designated BA.

Business Process
Business System
Analyst

BSA

Example

Accounts Payable, HR & Payroll

Also, now supports the GRC/SOD review process in terms of

simulations and action/permission knowledge.
Composite Role

SAP

This is type of R/3 Security Role which is a combination of other

Roles and can be assigned to one or more users. A typical MIT
composite Role will have several different shared Roles and one or
more unique ones as well, creating a unique combination of access
authorizations.
These composite Roles more closely match one or more users'
complete access requirements, making Role provisioning easier as it
can mostly be done at the Composite role level, reducing the
complexity for the Role Owner. Note: authorization profiles
provisioned from the MIT Roles Database system are in addition to
those from the composite Roles, so GRC-Access Risk Analysis always
needs to be performed at the User level to get a complete analysis.
Naming convention: Z_DDD_C_X where DDD is the MIT department,
C indicates it is a composite role, and X is descriptive of the role
(see example to the right).

116

Z_VPF_C_ADMIN_COMMON

GRC Training Risk Owners

Term

Short term

Source

Meaning

Example

Critical Role
Critical Profile
Critical Action

Critical

GRC

Roles, Profiles and Transaction Codes (GRC Actions / Permissions)

can be tagged as "critical" to ensure inclusion in access reviews
(compliance and technical).
If required, Mitigation Controls can be assigned to the critical risk.

Role = SAP_ALL
Tcode/Action = FB01 with
Permission 01 (Post)

Custom User Group

User Group

GRC

GRC has a Custom User Group for use in filtering reports.

This is in addition to the SAP R/3 users User Group field.

VPF

ESS

ESS

SAP

Web-based portal for Employee Self Service functionality

GRC

Reporting exceptions can be defined : e.g. Organization / Access risk

Exception Access
Rules
FireFighter logs

Logs

GRC

Action logs recorded in SAP R/3 when a user checks-in to the GRC
FFID.

Firefighter Role

Role

SAP

An SAP R/3 Security Role assigned to the FireFighter R/3 Users.

Different types of FireFighter need different access and Roles.

FireFighter R/3 User

FireFighter

SAP

A special SAP R/3 business user provisioned with the SAP R/3
Security FireFighter Role. There are several different types of
FireFighter :

Business User where the FF role is limited to back-up actions,

or special actions that would otherwise have created an SOD
issue if combined with a users existing role.
VPF Business Analyst - broad access for emergency VPF
Financial Systems support
IS&T Business System Analyst broad access for emergency
IS&T support
IST&T Basis additional technical access not usually needed.
FireFighter R/3 User naming convention: FF_XXX_NN where XXX =
the business area letters and NN is a sequential number. The User
Type = SERVICE and so cannot be used directly in SAP; instead it is
called up from GRC-EAM.
117

Not currently used at MIT.

GRC Training Risk Owners

Term

Short term

Source

Meaning

Example

Firefighter ID

FFID

GRCEAM

A GRC-EAM identifier used to manage access to the Firefighter R/3

User :

each GRC FFID is assigned to a Firefighter R/3 User (and so

indirectly to the assigned R/3 access role).
regular SAP users are assigned to the GRC FFID, when they have
been approved as having a back-up or a support function that
requires FireFighter access.
The Firefighter R/3 User can only be entered / checked into via the
GRC-EAM system, and an R/3 user only has access to the FFIDs they
have been assigned to. When finished their work, the user checksout of the FFID in GRC system.
When a FireFighter Id is used, an email is sent to its assigned FFID
Controller and the FireFighters actions in R/3 are logged for review.
Firefighter ID
Controller

FFID
Controller

GRCEAM

An MIT person (currently only in VPF or IS&T) who performs the

process of monitoring FireFighter usage both the checking-in
activity and the review of action logs.

Firefighter ID Owner

GRCEAM

Not currently made use of by MIT but is a required assignment for

a FFID. At MIT, this will be the same as the FFID Controller.

Function

GRC

A GRC Function identifies a medium-level business process and will

have one or many transaction codes (GRC Actions) assigned, with
additional permission level definitions where appropriate.
Also, a transaction code may be assigned to several functions, if it
has the implied business flexibility.
GRC has approximately 200 pre-delivered functions that are used to
define the mostly SOD-related Access Risks.

GRC Power User

Power User

MIT

BSAs, BAs and some Role owners will use most of the reports in GRC
- so they are known as the "Power Users" in respect of the report
usage and training requirements.

118

PR02 Maintain Purchase Order with permissions to create or

change.
HR04 Enter Employee Time Data.

GRC Training Risk Owners

Term

Short term

Source

Meaning

GRC system

GRC

GRC

SAPs Governance, Risk and Compliance software system MIT is

currently using the following components.
GRC-ARA : Access Risk Analysis this analyzes access in SAP ECC
Security Profiles, Roles and Users to see if there are (a) any
critical features (transactions, roles, profiles) and (b) any potential
Segregation of Duties breakdowns, as well as reporting details of
user access and role / profile assignments.

GRC-ARA
GRC-EAM

Example

GRC-ARA also has a what-if simulation reporting capabilities,

to analyze risks for proposed role / user changes.
GRC-EAM: Emergency Access Management also known as
FireFighter user management. See entries under FireFighter.
MIT Roles Database

RolesDB

Mitigation Control

Mitigation

MITs custom system for managing some of the cross-system access,

including some SAP access. SAP access is provisioned through an
automated process, mapping RolesDB rules to SAP R/3 Security
profiles, which are then assigned to the R/3 User.
GRC

The Mitigation Control object contains an explanation of how a

specific Access Risk (SOD or Critical risk) has been mitigated. Each
Mitigation Control has a unique id.

At MIT, the same access risk can exist in different areas but
may be mitigated differently, so there is a separate
Mitigation Control for each Risk / User Group combination,
where the User group may be VPF-Property, or VPFAccounts Payable.
Where the same risk is mitigated the same was across all of
MIT user community, the same Mitigation Control can be
used for all users.
The Mitigation Control identifier is assigned to the appropriate
combination of Access Risk and User to whom it applies.

119

General MIT business control:

bank reconciliation performed by
VPF independent of VPF AR
Cashiers.
New SOD mitigation reports (for
otherwise unmitigated access):
VPF AP report xxxx.

GRC Training Risk Owners

Term

Short term

Source

Permission Level

Permissions GRC

Meaning

Example

In standard SAP Security, the transaction-level checks may include

an additional check of an "Authorization" which is like an MIT
"Qualifier" - to restrict that user to by Company Code, or types of
Customers, or FI Document Types and additionally allows access
restriction by system activity, like create, change and display, where
the transaction itself can allow access to all activities if not restricted
by the authorization.

Action / Transaction Code : FS00

Maintain GL Account Master
(Allows : Create, Change, Display,
Lock, Delete)

In GRC these lower-level authorization are called "Permissions".

The Access Risk Analysis reports should be executed at this level, as
this will reduce the number of risks reported compared to the
Action level reporting, where the permission distinguished
between create, change and display.
Profile Generator

PFCG

SAP

SAP ECC access management tool used to generate access roles and
the Authorization Profiles based on roles.
The process whereby system access is provided to users.

Provisioning

Specifically for SAP this encompasses the procedures for requesting,

analyzing risk, approving and executing changes to roles, profiles and
their assignment to users. Three systems are involved: SAP ECC,
MIT RolesDB, and SAP GRC.
Risk Level

GRC

Risk Owner

For each defined GRC Risk, an associated risk level is assigned - high,
medium or low. This is used in Dashboard and other GRC report
filtering.
For each business area at MIT, the Risk Owner is the person who has
the responsibility for ensuring the business system controls are in
place and functioning, and any and all appropriate follow-up actions
are taken.
In the GRC/SOD context this includes periodic reviews of system
access, SOD analysis as well as any SOD-related mitigation controls.

Risk Violations

Violations

GRC

Access risk - can be analyzed at User, Role or Profile level.

120

Permission / Authorization: only

given Activity = 03 (Display). No
access to Activity = 01 (Create) or
02 (Change) etc.

GRC Training Risk Owners

Term

Short term

Role

Source

Meaning

Example

SAP

An SAP access control object used to group together actions

(transaction codes) and permissions (authorizations) to represent all
or part of a business job role.
MIT has several roles per user, e.g. those which are: common to all
MIT users, common to all business area (e.g. VPF-FAR) users,
common to a group within the business area (e.g. Cashier), or finally
a role specific to only one job duty for only one or a few users.
See also Composite Role definition.

Z_VPF_S_AR_MANAGER

Role Owner

Roles Database

For each business area at MIT, the Role Owner is the person who has
the responsibility for managing the SAP access roles specific for their
area: requesting role changes and role / user reassignments.
RolesDB

MIT

An MIT custom system to manage access across many of MITs

computer systems, including SAP.
The SAP access focus relates to provisioning common Roles and
related Profiles (with common actions and permissions) and
additional qualifier profiles the latter relates to controlling
access at organizational levels or other SAP system attributes.
The qualifier provisioning is managed by the MIT business users
who have provisioning rights.
Currently, some RolesDB common Roles are blocked for the SAP
users who have already had their Roles in SAP re-engineered as part
of the SOD project.

SAP Access Control

SAP Authorization
SAP ECC
SAP Core
SAP 6.0

SAP R/3
Security

SAP

SAPs core system access control functionality using: Users, Roles,

Profiles and Authorizations.
The SAP software used by MIT for Financial Accounting,
Procurement and HR/Payroll. ECC stands for Enterprise Core
Component, and 6.0 is the software release level.

121

Z_VPF_S_DOCUMENT_REVERSE

GRC Training Risk Owners

Term

Short term

Source

Meaning

Example

SAP User Group

User Group

SAP

Each SAP R/3 user is defined in the SAP system. One of the SAP
Users attributes is the User Group field which MIT is using to
identify a group of users for analysis.
Some GRC-ARA reports make use of this User Group for selection.
Additionally, GRC has a Custom User Group.

VPF-FAR

Segregation of Duties

SOD

GRC

System access is expected to support the business requirement that

no single user should have end-to-end business process access,
otherwise there is risk of internal fraud occurring.
In some high risk areas, access to only several steps in a process are
enough to cause a Segregation of Duties breakdown.

Ability to create a Vendor Master

and any one of: create a Purchase
order, post an invoice, generate a
payment.

Simulation

Simulation

GRC

The GRC-ARA simulation tool is a "what if" access risk analysis - it

simulates adding more access (actions and permissions) to existing
Users, Roles or Profiles.

What if tcode ME21N (Create a

Purchase Order) is added to User
FREDX, or to Role
Z_VPF_S_AR_MANAGER.

The simulation can also specify access to be removed e.g. what if

transaction FCH9 Void Check were removed from a user who
currently has it.
SOD Coordinator

MIT

A person in VPF who has been designated to coordinate several of

the GRC-related processes.

SUIM

SUIM

SAP

An SAP R/3 transaction which calls up a menu of authorizationrelated reports of Users, Roles, Profiles, Authorizations.
Note: each item on the menu requires access to be granted, as it
links to a different SAP transaction code like S_BCE_68001421
which in turn call up the related RSUSRxxx program.

Transaction code

tcode

SAP

The SAP ECC system users "transaction code" for each business
action - usually all menu lines have a transaction code behind them
to call up the dialog (online) function.
In GRC, these are called Actions.

122

FB01 Post an FI Document

FB02 Change an FI Document
FB03 Display an FI Document

GRC Training Risk Owners

Term

Short term

Source

Meaning

Example

User Master

User

SAP

This is the SAP system user master record or Logon Id the naming
convention at MIT is to match the MIT Kerberos Id, based on the
users name.

PAMELAS

Workflow ECC

In SAP ECC, workflow is automated for some financial

postings/documents. Users enter financial transactions and they are
work flowed in custom MIT programming to approvers inboxes.

Workflow GRC

GRC functionality for approving access change requests - currently

not implemented.

123

DALET
VACHA

GRC Training Risk Owners

GRC Roles & Responsibilities

ROLE
RISK OWNER
Gerry OToole
Basil Stewart
Tricia Sullivan
Mullen
James Walsh
Allen Marcum
Bart Dahlstrom

RESPONSIBILITY
Provide guidance on - Simon
o acceptable level of risk related to SODs and
critical access
o adequacy of compensating (mitigating) controls
Ensure control processes are in place : - Karon
o Regular access review
o Mitigation processes, including specific reports.
Final approval on new/amended Mitigation Control
definitions and assignment to Risk / User combinations.
- Simon
Approve recertification of mitigating controls
supported by Role Owner and Compliance Officer. New

124

ACCESS-RELATED ACTIONS
Review high-level GRC-ARA
reporting
Monitor the execution of the
access-related business control
processes

FORM/REPORT USE
High level GRC Dashboard
reports
Final sign-off on Mitigation
Control change request
form.

GRC Training Risk Owners

ROLE
ROLE OWNER
John Larkin
Donna Cairns
Eileen DesRosiers
James Walsh
Chris Durham
Sara Malconian
Long Tran
Kathy McGrath
Kevin Miligan
Pamela Schickling
Jo Anne Chute
Tricia Sullivan
Mullen
Ann Harvey
Danielle Khoury
Jo Lynn Whitlock
Siobhan
Cunningham
Frank Quern
Ron Parker
Wai Ming Li

RESPONSIBILITY
Identify potential access changes, aligned to the
business areas functions, organization and Segregation
of Duties requirements. - George
o New or amended role definition.
o User assignments to new or amended roles
Assist the SOD Coordinator with the assessment of
new risks associated with proposed changes - Simon
Formally request Production access changes (role
activation and user/role assignment) when the GRC risk
analysis is completed and documented. - New
Manage changes to SAP access from the RolesDB,
where appropriate. Note: there is usually no SAP
Security Admin involvement in this step. - George
Request assignment of users to Firefighter roles in GRC
Siobhan, Sandy
Advise SAP Security of any Transfer Out / Termination New
Conduct regular reviews of : - New
o Roles for the business area who has them
o Users per business area what roles they have
o Users per business area what Risk/ Mitigation
combinations are assigned
o GRC-ARA (SOD) analysis
o Assignment of Business Back-up FireFighter
roles to Users
Monitor access logs for business user "FireFighter" and
IS&T Support role usage - New

125

ACCESS-RELATED ACTIONS
Initiate change requests SAP
access
Initiate change requests GRC
mitigations

FORM/REPORT USE
FORM : Access Change
Request
FORM : Mitigation Control
request form Risk/User
assignment

Keep Risk Owner aware of all

proposed changes and status

Review SOD Risk simulation

results provided by BA/BSA for
proposed role changes

Various GRC reports may

be a GRC Super User
SAP ECC SUIM reports limited use.

Perform Role and User level

access analysis with support
from BA and/or BSA.

GRC Training Risk Owners

ROLE
BUSINESS ANALYST
(BA)
Mirella Villa
Leslie Wright
Scott Ball
Lody Petriv

BUSINESS SYSTEM
ANALYST (BSA)
Ken Levie
Kristen Hann
Bob Casey
Keyur Patel
Sandeep Nadendla
And others

SAP END USER

All VPF users

RESPONSIBILITY
Assist the Role Owner and Risk Owner with : - Simon
o Analysis of changes to risks due to changes in
roles or user/role assignments
o Redesign of Role in terms of business-relevant
information
o Understanding the Risk as reported by GRCARA i.e. why there is a potential SOD issue.
Document Mitigation Control and send to GRC team,
after approval of Role Owner and Risk Owner - Simon
Testing new/changed access BA/BSA
Essentially the same as the Business Analyst, plus providing
assistance with :
Alternatives for Actions (tcodes) or Permissions
(Authorizations) - BSA
Categorizing Z transactions - BSA
Prepare mini-specs for any additional mitigation system
development (configuration, enhancements or reports)
- BSA
Manage transports for any development technical
objects. - BSA
o Test new/amended access - same
o Report missing authorization- same
o Report access in excess of job requirements- same
o Report breakdown of mitigating controls e.g. user
finds they can approve own Requisitions above the
limit, or can approve own JVs. - same

126

ACCESS-RELATED ACTIONS
Perform GRC-ARA simulations or
review simulation results
Perform Role and User level
access analysis in GRC
Create/update SAP Access Role
design documents.

FORM/REPORT USE
FORM : Mitigation Control
request initial definition
and creation

Same as Business Analyst, plus :

o More use of SUIM???
o Access to use SU56 on Production
users and run Z auth reports

GRC Super User

SAP ECC SUIM reports

Email to Role Owner any issues.

N/Av

GRC Power User reporting

SAP ECC SUIM reports

GRC Training Risk Owners

ROLE
SOD COORDINATOR
Lody Petriv
On Demand Epiuse
AMS Remote
Consulting (Simon &
Suman) for 6-12
months under
current contract
hours

BSA Manager =
IS&T Role Owner
Siobhan
Cunningham
Frank Quern
GRC ADMIN
Sara Quigley
Ron Parker
George Petrowsky
Rich Katkowski
Quian Kang

RESPONSIBILITY
Coordinate monthly SOD Analysis reviews - Karon
Coordinate Quarterly User Access reviews - Karon
Business lead for GRC, including :
VPF Roles : for new/amended roles, coordinate
SOD Issue resolution involving Risk Owner, Role
Owner, Audit, as well as support from BA / BSA
o Also, identify any additional mitigation
controls required if new risks are to be
accepted.
Ensure mitigation controls are in place before user /
role access change is effective. - Simon
Support the Risk Owner and Role Owner by
providing information from GRC system Suman,
JD
Support the process for recertification of mitigating
controls. - New
Advise SAP Security Admin, GRC Team and Director of
Financial Systems and Data- when there are new or
amended IS&T Support users - Siobhan, Frank

ACCESS-RELATED ACTIONS
Run GRC and SUIM reports

FORM/REPORT USE
GRC Power User reporting

FORM : Access change

request

No access-related actions as such, but

provide :
o Confirmation to Role Owner
that a Mitigation Control is
assigned to the users as
requested.
o Risk and Function definition
information on request
o Explain results from any GRC
Dashboard or detailed report.

Manage rulesets, including adding Z transactions Sarah

Manage Mitigation Controls and their related Risk/User
assignments - Sarah
Manage access to GRC functionality and reports- Sarah
Manage GRC updates - Sara
Manage Fire Fighter to User assignments. - Sarah
Provide information on reporting, report results and
GRC ruleset contents as requested. - Sarah

127

Request user assignments to

Support roles

Potentially any report from

GCR

GRC Training Risk Owners

ROLE
SAP SECURITY
ADMIN TEAM
Ron Parker
George Petrowsky
Rich Katkowski
Quian Kang
Sara Quigley

MIT Audit

Ongoing Oversight
Committee Chair
Gerry OToole
Basil Stewart
Tricia Sullivan
Mullen
Bart Dahlstrom
James Walsh
Allen Marcum

RESPONSIBILITY
Execute properly approved SAP User Access change
requests : Admin Team
o Amend Roles
o Amend User / Role assignment
o Amend Profiles
o Amend RolesDB / SAP interface
o Amend Firefighter Roles
o Provide User Aliases for testing new/amended roles
Admin Team
Redesign Roles for efficiency or to separate functions
which were bundled. May be in conjunction with
RoleDB changes. Admin Team
Periodic reviews of - MIT Audit
o SOD risk mitigation controls
o SAP access change process controls
o User access

SOD / GRC Champion

Speaks to overall approach with PWC Audit

128

ACCESS-RELATED ACTIONS
o Confirm SAP access changes to
Role Owner
o Move access through
Development, QA and Production
landscape
o Advise Role Owners when any
technical role redesign / cleanup is performed as user access
testing will be required.

FORM/REPORT USE
Any report from SAP
Reporting from GRC?

Power User of GRC reports

GRC Training Risk Owners

GRC SOD Analysis Steps

PURPOSE OF THIS DOCUMENT

This document sets out the steps required to understand the Segregation of Duties risks and their actual
impact within the specific business environment. The details here support the high-level GRC Process 2
Flowchart presented during GRC training.
The details below describe the users (BA, BSA, Risk Owner, Role Owner, SOD Coordinator, SAP Security
Admin) who will be involved in each step. The steps are broken down into phases of the task :

Phase A
Phase B
Phase C

Steps 1 7
Step 8
Steps 9 11

Risk understanding
Role redesign and SOD analysis
Mitigation Strategy

DETAILED STEPS USERS INVOLVED AND ACTIONS

INFORMATION INPUT

ROLE DESIGN / REDESIGN STEPS

PHASE A

PREPARATION ( 1 7 )

Audit

1. Understand the business operations :

Business Analyst

a. Business activities, scope, value, volume, risk.

Business Systems Analyst

b. Business systems , including manual steps outside the computerized

systems and any automated processes
c. Any Key Performance Indicators affecting employee remuneration.
d. Business events which involve employees with access to MIT resources
and business processes which could be subject to misappropriation /
fraudulent activities:
Cash and Treasury
Stores inventory
Equipment and Fixed Assets
Req-to-check/payment : inwards goods/services consumption
Order-to-cash : outwards goods/services
Service provided internally
HCM : HR and time data affecting Payroll
e. Where relevant, any external legal / regulatory requirements for fiscal
reporting, trade restrictions, privacy / data protection, disclosures etc.

Page 129 of 148

GRC Training Risk Owners

INFORMATION INPUT

ROLE DESIGN / REDESIGN STEPS

Audit

2. Business Risks and related Control Objectives

Risk Owner
GRC system

a. High level control objectives for completeness, accuracy, authorization,

timeliness, quality, privacy etc
b. Identification of major risk areas relevant to the MIT business area,
including the GRC Ruleset with its Risk definitions.
c. Determine if there are any Audit findings (internal & external) which are
still unaddressed.

Business Management

3. Organizational Structures relevant to the processes

HR

a. Business Organization Chart

IS&T

b. System Org hierarchies and system approval structures and limits

c. Current job incumbents and vacancies and temporary staffing
d. Reality Check : the actual supervision / management in place

Business Management
HR

4. Job Descriptions relevant to the business processes

a. Identify the business process steps the user is currently responsible for.
b. Identify any requirements for confidentiality (personal data, financial
data, contract bidding, etc) relating to the user / job position.
c. Reality Check : shared UserIds
d. Reality Check : multiple UserIds (not at MIT due to unique Kerberos Id).

Business Management
Audit

5. Published Policies and Procedures

a. Identify procedures requiring control and what the control procedure is.
b. For each procedure, summarize into bullet points in process step
sequence, with system / person / action
c. Reality Check : make sure the procedure is still in use.
6. Actual users and system usage

IS&T - Security

a. List of current users, by User Group (matching the MIT business area)

Business Analyst

b. List of transaction codes executed by SAP UserId over a 1 or 2 year

period. (Job changes will make this less useful).

Business Systems Analyst

(Role Owner to an extent)

Review the list of business process identified for the users and

assign any major action tcodes for data maintenance,

logistics/financials postings / approvals, and
identify remaining tcodes not associated with a business process.
c. Identification of any Emergency Access the user has - managed in GRC or
Page 130 of 148

GRC Training Risk Owners

INFORMATION INPUT

ROLE DESIGN / REDESIGN STEPS

in any other way.
d. List of roles / composite roles assigned to the users
e. Additional Authorizations used to restrict access by organizational,
functional, or business classification.
This may include authorizations provisioned through the MIT
custom Rules Database
Once a role is created, the Profile Generator requires values for
the Authorization Objects used by the tcodes in the role.
f.

Additionally, IS&T can list the Authorization Objects called for a

transaction code.

7. Business Controls and Risk Mitigation

Audit
Business Analyst

a. Dual actions required by procedures or in use e,g. entry & independent

approval of entered data (master data and financially-relevant
transactions).
b. Any organizational segregation of duties e.g. Master Data users are a
separate group of users from the Financial Transaction Entry users.
c. The usual business procedures for reconciling business activity e.g. cash
receipts, check stationery, warehouse physical inventory, fixed assets
inventory.
d. Detective, like independent review of reports - and who performs the
review. Often there are exception reports which focus on specific risks
for the users.
e. Configured or programmed system restrictions.

Audit
IS&T
Audit
Business Analyst

f.

Activity logs and reviews, and the data being reviewed is protected from
change / deletion. Typically reports of master data changes, financial
transactions, overdue open items, unblocked invoices).

g. Additional access restrictions - e.g. users activity is limited to specific GL

Accounts, Vendors / Customers, FI Document Types or dollar amounts
which may reduce the risk.

Business System Analyst

PHASE B

ROLE REDESIGN Role Build and SOD Analysis (8)

8. Analysis of actual Segregation Of Duties

All of the above

GRC Risks definition

a. Understand the expected / best practices SOD requirements for the SAP
UserIds, based on the actual business area being reviewed and the actual
business systems in place .
b. Use Standard SOD rulesets for identifying Risks and Function-level
Page 131 of 148

GRC Training Risk Owners

INFORMATION INPUT

ROLE DESIGN / REDESIGN STEPS

definitions the function level clash is usually like Vendor Master +
Invoice Entry.
c. Understand the High Risk or Critical activties in GRC.

IS&T

d. Redesign of SAP Roles and UserIds

Remove all unused SAP transaction codes and other SAP
Authorizations from the roles
Match additional Authorizations to any restriction requirements
(organizational and accounting restrictions)
Identify and set up any new users (if there is additional staffing
to help with maintaining SOD).
Assignment of all expected roles to a user - check tcodes match
actual job duties, no more and no less
This is mostly managed at MIT with Composite Roles so
several single roles are assigned to a Composite role.
In smaller operational areas there may be one
Composite Role per user, reflecting a unique mix of job
duties per user.

Business Management

Business Analyst
Business Systems Analyst

e. Review of redesigned SAP Roles (preliminary review per Role, and then
per User with all roles and Roles Database profiles assigned) for any SOD
Issues
SOD breakdowns reviewed identify real risk / processing
scenario for the SOD in the specific environment.
Uses Standard SOD rulesets for identifying activity-level (tcode)
and permission-level SOD breakdown.

Business Management
IS&T Security

Audit
Business Management

f.

Consider remediation possibilities - looking at either side of the function

clash for the SOD risk :
Adjusting several roles / job duties to avoid an SOD
Move one or more of the tcodes to a FireFighter role
Have another business area manage a function
Use alternative tcodes which do not have the same risk.

g. Review of total physical business environment, including business

processes across systems where SAP is not the only system in the
business process.
There may be an SOD where the user performs two actions, one
in each system, which would be reported as an SOD if both
actions were managed in SAP.

Page 132 of 148

GRC Training Risk Owners

INFORMATION INPUT

ROLE DESIGN / REDESIGN STEPS

PHASE C

MITIGATION STRATEGY ( 9 11)

Audit

9. Understand the exact scenario possible for the reported Risk

Business Analyst

a.

Business Systems Analyst

Look at the exact tcode combinations reported for the Risk. Each Risk
has two conflicting functions and each function can have several
tcodes.
Where there are a large number of combinations, they can
usually be grouped to simplify the analysis.
Look at the tcode combination in conjunction with the GRC Risk
description, it sometimes helps to focus on a specific issue.

b. Check if the GRC system already has a Mitigation Control defined for this
Risk. If there is one, make sure the same tcode combinations were
involved. If there is a major difference in the conflicting tcodes, the
Mitigation Control may not be valid for the new users under analysis.
c. Determine if any of the combinations are not a significant risk for MIT.
For the combinations remaining, outline the process steps needed for
the user, with no collusion, to benefit from the potential SOD.
d. In some cases a multi-step scenario is needed, and a mitigating control at
any one step may be adequate.
e. Double check with Audit if the issue has been reported and/or already
addressed or risk is formally accepted by management to be within
acceptable levels.
Information gathered
above
Audit
Business Analyst
Business Systems Analyst

10. Review of SOD issues and any effective mitigating control processes already
in place. This may include
a. workflowed approvals, independent release or activation processes,
or dual control master data
b. workflowed / emailed notifications of activity
c. regular business post-facto report review, including reconciliations ,
activity reporting and exception reporting
d. other SAP Authorizations (GL/Customer/Vendor accounts, document
types, Fixed Assets, organizational, table access)
e. transactional value limits
f.

configured restrictions (document types, field restrictions)

g. programmed restrictions, including validations or upload program

checks.
11. Recommendations for addressing remaining SOD issues :
Audit

a. Improved SOD within SAP user business roles potential for business
Page 133 of 148

GRC Training Risk Owners

INFORMATION INPUT
Business Management
Audit

ROLE DESIGN / REDESIGN STEPS

user role changes but not always possible.
b. Improved procedural controls e.g. detective report reviews

Business Analyst
Business Analyst
Business Systems Analyst
IS&T Development

c. Additional lower-level preventative / limiting controls such as :

Authorizations e.g. restricted access based on account
assignments (GL Accounts, Vendors, Customers, Plants, FI
Document Types etc)
Configuration / Enhancements like

Business Analyst
Business Systems Analyst
IS&T Development

Data Entry validations

FI Document Type settings

SAP dual control activations

Workflows

d. Custom processes / enhancements with inbuilt restrictions preventing or

limiting the SOD issue :
Screen variants for restricting and/or forcing data and options
Functionality limitations
Specific data tables or data
Special checks like prevent entering invoices for Vendors
created by the same user.

Risk Owner

e. Ensure controls are in place has to be evidenced and testable.

Page 134 of 148

GRC Training Risk Owners

Example of a Sales related SOD risk matrix, showing conflicting functions. Risk rating (High, Medium, Low) is for illustration purposes only.

Page 135 of 148

GRC Training Risk Owners

GRC Forms

Page 136 of 148

GRC Training Risk Owners

Example Form A: GRC Mitigation Control Change Request

Page 137 of 148

GRC MITIGATION CONTROL CHANGE REQUEST

Please use this form to request changes to the SAP GRC Mitigation Controls for new / amended descriptions,
and for new / amended assignments to Risk/User combinations.

ACTION REQUIRED

- check with Y all applicable

New Mitigation
Control ?
New Risk/User
assignments ?

Amend the MC
description ?

GRC ADMIN
STATUS

Amend Risk/User
assignments ?

Document to be attached ?
.

DEV DD/MM/YY

Hyperlinks to be attached ?

TEST DD/MM/YY

.
Date Required in Production MM / DD / YY

PROD

Coordinated with other SAP R/3 Production transports Y/N ?

DD/MM/YY

MITIGATING CONTROL : GENERAL INFORMATION

GRC MC ID
GRC MC CONTROLLER
SHORT DESCRIPTION

Use format MC-XXX-12 where XXX is VPF Business Area

MC Controller Name : ___________________________

SAP User Id :
___________________________
Short description (max. 25 characters)

LONG DESCRIPTION

Long description in attached document ? If not, enter below :

2013 MIT

Page 1 of 2

GRC MITIGATION CONTROL CHANGE REQUEST

RISK / USER ASSIGNMENT to be added or removed ?
ADD

REMOVE

GRC RISK ID

SAP USER ID

User Name

ROLE OWNER - PROPOSER

Name

Telephone #

Kerberos Id

Date

Kerberos Id

Date

RISK OWNER APPROVER

Name

2013 MIT

Telephone #

Page 2 of 2

GRC Training Risk Owners

Example Form B: GRC FireFighter Change Request

Page 140 of 148

GRC FIREFIGHTER CHANGE REQUEST

Please use this form to request changes to the SAP GRC FireFighter assignments for existing or new FFIDs

ACTION REQUIRED

- check with Y all applicable

Amend assignment
-

FFID User

New FF ID and R/3

User and Role ?

Amend assignment
-

FF ID Controller

Amend assignment
-

FF ID Owner

GRC ADMIN
STATUS

Add / Remove GRC

EAM report user ?

Coordinate with other SAP R/3 Production transports ?

Date Required in Production > MM / DD / YY

PROD
DD/MM/YY

FIREFIGHTER CHANGES : GENERAL INFORMATION

RT TICKET ID

RT TICKET TITLE

RT TICKET ISSUE TYPE

GRC FIREFIGHTER CHANGES

REQUESTER

Name :

BUSINESS PROCESS OWNER / BA

Name :

IS&T BSA

Name :

REQUIREMENT / JUSTIFICATION

RELATED R/3 TRANSPORTS

2013 MIT

Page 1 of 2

GRC FIREFIGHTER CHANGE REQUEST

GRC FFID ASSIGNMENTS to be added or removed
NEW

SAP USER

FFID

FFID

FFID

KERBEROS ID

USER

CONTROLLER

OWNER

Add

Add

Add

Remove

Remove

Remove

Add

Add

Add

Remove

Remove

Remove

Add

Add

Add

Remove

Remove

Remove

Add
Remove

Add
Remove

Add
Remove

Add

Add

Add

Remove

Remove

Remove

Add

Add

Add

Remove

Remove

Remove

Add

Add

Add

Remove

Remove

Remove

Add

Add

Add

Remove

Remove

Remove

Add

Add

Add

Remove

Remove

Remove

Add

Add

Add

Remove

Remove

Remove

Add

Add

Add

Remove

Remove

Remove

Add

Add

Add

Remove

Remove

Remove

FFID

Existing
FFID

GRC FF ID

FIREFIGHTER ROLE OWNER - APPROVER

Name

2013 MIT

Telephone #

Kerberos Id

Date

Page 2 of 2

GRC Training Risk Owners

Example Form C: SAP User or Role Change Checklist

Page 143 of 148

SAP PS1 SECURITY CHANGE CHECKLIST

Please use this form to request or document changes to the SAP R/3 Security in Production (PS1) for changes to
Roles and for Role assignment to Users (pages 1 -3 ), FireFighter Users and roles (page 3) and for User
administrative data changes including lock/unlock and reset password (page 4).
For new Composite Roles or new FireFighter Users, please use one Change Request form per role or user.

ACTION REQUIRED

- check with X all applicable

LOCK / UNLOCK
USER (Page 4)
COMPOSITE ROLE
NEW
COMPOSITE ROLE
CHANGE

RESET PASSWORD
(Page 4)
SINGLE ROLE
NEW
SINGLE ROLE
CHANGE

NEW USER role

assignment

ADMIN STATUS

EXISTING USER
role change

Coordinate with other SAP R/3 Production transports ?

Coordinate with Roles Database changes ?

Coordinate with GRC FireFighter changes ?

PROD UPDATED
Date Required in Production > MM / DD / YY

DD/MM/YY

R/3 ROLE AND ROLE ASSIGNMENT CHANGES : GENERAL INFORMATION

RT TICKET ID

RT TICKET TITLE

RT TICKET ISSUE TYPE

R/3 SECURITY ADMIN

REQUESTER / ROLE OWNER

Name :

BUSINESS PROCESS OWNER / BA

Name :

IS&T BSA

Name :

REQUIREMENT / JUSTIFICATION

RELATED R/3 TRANSPORTS

2013 MIT

Page 1 of 4

SAP PS1 SECURITY CHANGE CHECKLIST

COMPOSITE ROLE CHANGES
COMPOSITE ROLE

2013 MIT

NEW

ADD

REMOVE

ROLE

SINGLE

SINGLE

GRC
ARA
ROLE

SINGLE ROLE

Page 2 of 4

GRC
ARA
USERS

SAP PS1 SECURITY CHANGE CHECKLIST

SINGLE ROLE CHANGES (USER AND FIREFIGHTER)

SINGLE ROLE (s) -

The role(s) to be changed.

.
.

ROLE DESIGN DOCUMENT

File name and location of Role Design document

(required for new roles)

LIST OF CHANGES TO EXISTING
ROLE

Description of Transaction Codes (added or removed) and/or Authorizations

(to be added, removed or amended)

GRC Risk Analysis Role ?

Simulation Provided / Needs to be run ?

GRC Risk Analysis Users ?

Simulation Provided / Needs to be run ?

NEW FIREFIGHTER USER

FF-XXX-NN

USER
ROLE DESIGN DOCUMENT

File name and location of Role Design document (optional)

FFID SET UP COMPLETED IN GRC ?

Date / Time :

ROLE OWNER - APPROVER (USER ROLES AND FIREFIGHTER ROLES)

Name

Telephone #

Kerberos Id

Date

GRC Verification SOD Coordinator (USER ROLES ONLY)

Name

2013 MIT

Telephone #

Kerberos Id

Date

Page 3 of 4

SAP PS1 SECURITY CHANGE CHECKLIST

USER STATUS : CHANGES

USER ID

PASSWORD RESET

Date / Time :

LOCK USER

Date / Time :
Reason :
Date / Time :

UNLOCK USER

Reason :

USER IDENTIFICATION DATA : CHANGES

USER ID

USER GROUP

GRC CUSTOM USER GROUP

NAME

WORKCENTER

Department
Building
Room

LOCATION

COMMUNICATION DETAILS

ACCOUNT NUMBER

:
:
:

Phone :
Fax
:
Email :
.

USER MANAGER - APPROVER

Name

2013 MIT

Telephone #

Kerberos Id

Date

Page 4 of 4

GRC Training Risk Owners

GRC Change Events

Page 148 of 148

MIT BUSINESS EVENTS TRIGGERING SAP/RDB AUTH CHANGES AND THE IMPACT ON GRC
Event triggering change

Type of change

SAP UserId and Auth changes

MIT Roles Database (RDB) changes

GRC changes, SOD Risk Analysis impact, FireFighter

The business event which

triggers a change in Users,
User Access, Role Design,
Mitigation Requirements, GCR
assignments (Mitigations and
FireFighters).

The type of change that is

triggered, in business
terms.

Exactly what SAP R/3 objects needs to be

amended and the type of amendment add,
remove, reassign, create, change etc.

Any changes that are expected in the MIT Roles

Database system. This is mostly managed by the
users management but may sometimes also
have a technical change component.

The actions and changes which will be needed in the

GRC system for Mitigation analysis, Mitigation
Control assignment and for FireFighter management..

Departmental reorganization

Job duty changes may

be substantial changes

Existing job position

New hire
Employee Transfer in
(new managers actions)

New or changed job duties

Role / composite role changes

User role combinations changed
Probably an existing User Group, but may
be a new one.

Replacement or
additional staff no other
changes

New job, new duties

New role / composite role

New role combination for the user
Probably an existing User Group, but may
be a new one.

User added to SAP with same roles for

sub-set of roles as an existing user
User added to SAP with new combination
or roles

New hire
Existing employee

Temporary staffing

Several types :

Existing job
Combination of jobs
Special
project/access

User added to SAP with same roles as an

existing user
For Transfer In, amend User Group.

Employee remains at
MIT, but moves to a
different DLC

Employee resigns, is
terminated or has taken longterm/permanent leave.

Employee no longer
needs access to SAP.
Note : procedure is
different for
terminations.

Roles can be removed from User

ESS access remains ??
User is deactivated (but not removed)
IS&T employee - deactivated in all SAP
systems

Non-employee leaves MIT

Student, associate,
consultant no longer
needs access

User is deactivated (but not removed)

Consultants deactivated in all SAP
systems

New SAP application

functionality added

Standard SAP or Z
tcodes to be added

Standard SAP tcodes add to roles

Business Users and related FireFighters
(for business, BA and BSA)
May require separate single role, to be
included in composite roles.

Employee Transfer Out

(prior managers actions)

Users job-related access to be removed

Variation : user performs old duties and
new duties for a while !

Probably a few RDB changes

If user role redesigned for the first time under
new process, update the RDB user list so that
some of the old common profiles are not
exported back into SAP.
User added to RDB or amended in to have the
same attributes as existing users

User added to RDB with appropriate

attributes.

Some additional provisioning may be needed

Potentially changed

Add UserId to mitigation assignment

No change but
include user Id in
selection for
Mitigation reports.

1. Roles Maintenance

Potentially changed

1. Roles Maintenance

Role analysis
User Analysis
Mitigation reassignments / deassignments and
Validity Date changes

Simulations of any new role combinations

Mitigation reassignments / deassignments after
periodic GRC reporting using Validity Dates.
May need FireFighter access

Users permissions removed , by ????

May be no change. If RDB already controls

similar auth/qualifier, then maybe new object
is added to RDB.

3. Role Provisioning
4. FireFighter

3. Role Provisioning

2. Mitigation
3. Role Provisioning
4. FireFighter
1. Roles Maintenance
2. Mitigation
3. Role Provisioning
4. FireFighter
Potentially changed

Mitigation/User assignment remains for historical

reporting. Amend Valid To date.
FireFighter de-assignments

User Id remains in
selection variant for
historical reporting.

2. Mitigation
3. Role Provisioning

No changes and Mitigation/User assignment

remains for historical reporting.

User Id remains in
selection variant for
historical reporting.

3. Role Provisioning

Custom Z tcodes identify SAP equivalent and

add to Ruleset (Functions) wherever SAP
equivalent is.
Role analysis
User Analysis

Potentially changed

1. Roles Maintenance

Page 1 of 3

1. Roles Maintenance
2. Mitigation

Amend Valid To date for mitigation assignment.

User Analysis where user is to retain old access
overlapping with new access.
FireFighter de-assignments

4.
5.

Roles Maintenance
Mitigation
Role Provisioning to
Users
FireFighter
Compliance reviews

Role analysis
User Analysis
Mitigation reassignments / deassignments with
validity dates
Possibly need New / Changed Mitigation Control
Possibly need reassignment of FireFighter IDs

Users old permissions removed by prior

manager at some point.
Users new permissions added by new
manager before job assignment commences

Process Flowchart
1.
2.
3.

In some cases Validity Period can be used instead of

de-assignment.

Mitigation Signoff

2. Mitigation
3. Role Provisioning
4. FireFighter

4. FireFighter

2. Mitigation

MIT BUSINESS EVENTS TRIGGERING SAP/RDB AUTH CHANGES AND THE IMPACT ON GRC
Event triggering change

Type of change

SAP UserId and Auth changes

MIT Roles Database (RDB) changes

GRC changes, SOD Risk Analysis impact, FireFighter

Mitigation Signoff

Process Flowchart

Functionality removed

No replacement, just
removal.
Change of tcode usage e.g.

May be no change. If RDB controls a related

auth/qualifier, then it can be removed from /
disabled in RDB.

Determine if a Risk was removed, and so the user

can be deassigned from a mitigation control.
Role analysis
User Analysis may be needed

Potentially changed

1. Roles Maintenance

If missing authorization is provided from RDB,

missing due to technical or provisioning error,
fix in RDB.

Potentially changed

1. Roles Maintenance

Unlikely to be affected , unless new authorization

is already added to GRC and causes an SOD
User analysis just to be sure

Assign SAP R/3 User to Firefighter ?

Should not be
affected

4. FireFighter

Role analysis
User Analysis
Unlikely to be removing risks, but it is possible
where unnecessary access was removed so
potentially may be able to deassign mitigations.

Should not be
affected

1. Roles Maintenance

New Mitigation Control created

Change assignment of Risk / Mitigation / User.

New control added

to Signoff
documentation.

2. Mitigation

Unchanged

2. Mitigation

May identify some assignments that can be

removed
Extend all valid assignments = recertify
Role analysis
User Analysis

Should not be
affected

N/A - GRC MAINTENANCE

Should not be
affected

N/A - GRC MAINTENANCE

Not affected

3. Role Provisioning

Typically tcodes are removed from a role.

Rare a role could be deactivated

See New Functionality Added for action

on any replacement tcodes. Cannot
assume replacements have the same SODs
as those replaced.

New SAP Authorizations,

role maintenance errors,
Roles DB errors

Affected role is updated all role users

are fixed

Firefighter assignment
changes

Request for User

Firefighter assignment

N/A

SAP Auth Role redesign

Technical behind the

scenes should not affect
the business

Role / composite role changes

Business or Audit controls

review

May have new reports may need new

tcode and role to be assigned to users to
run mitigation reports
Role removed from user(s)
Possible role redesign

Missing authorization

FV50 replaces F-65

FBCJ replaces ZCxx

Additional mitigation
controls to be added
and assigned.
Remove access
request from Audit

N/A

Some may be removed, if SAP Auth roles

becomes the controller

Possible change.

Mitigation Control periodic

expiry of User assignment and
subsequent recertification

Expiry dates for

Mitigation Control / User
Assignment need to be
extended

N/A

Ruleset changes MIT or PWC

Different ratings (H/M/L)

on risks, added/removed
critical transactions,
tcodes removed from
Function, etc

N/A

N/A

SAP annual system and

content changes

Additional Tcodes,
Functions and Rules
added to ruleset

N/A

N/A

Additional Tcodes, Functions and Rules added to SAP

delivered ruleset.

User locked, name changes,

etc

User locks / unlocks

Password Resets
User
information/name
Other ?

N/A

2. Mitigation

3. Role Provisioning

Note : if any new functionality is actually used, the

new tcodes would have been added to user roles see
New Functionality Added above.
User Master updated

N/A

N/A

Page 2 of 3

MIT BUSINESS EVENTS TRIGGERING SAP/RDB AUTH CHANGES AND THE IMPACT ON GRC
Event triggering change

Type of change

SAP UserId and Auth changes

MIT Roles Database (RDB) changes

GRC changes, SOD Risk Analysis impact, FireFighter

Mitigation Signoff

Process Flowchart

Identifies a changed user

with unmitigated SOD
Access Risk or critical
transaction

Correct provisioning error remove role

from user
?

Possible change most likely, a converted user is

still getting old common roles or was incorrectly
provisioned.

Potentially changed

2. Mitigation

Execution of mitigation
processes and their
review and sign-off by the
risk owner

May trigger a role change or a role

assignment change

N/A

Review of user access and

critical access

MONITORING AND
REPORTING
Ongoing Risk Analysis Review

Monthly Compliance review

Ongoing User Access reviews

May need to assign user to Risk/Mitigation

3. Role Provisioning

1. Roles Maintenance
3. Role Provisioning
5. Compliance review

May trigger a role change or a role

assignment change

N/A

1. Roles Maintenance
3. Role Provisioning
5. Compliance review

Firefighter usage
Ad Hoc reviews

N/A

Review of security logs ?

Maybe some limited use of SUIM reports

N/A

Review of Firefighter usage logs ?

4. FireFighter

N/A

Various informational reports who has what

role, what roles does a user have, what is in a
role, what are the differences between roles or
users, etc
ARA Simulations, in preparation for change
requests (User/Role reassignment or Role design).

2. Mitigation

Page 3 of 3

5. Compliance review