SAP IT General Controls

Detailed Testing Guide

Population | Sampling | IPE | Screenshots | Evidence

March 2026

FOR INTERNAL AUDIT AND COMPLIANCE USE ONLY

SAP ITGC Detailed Testing Guide Population | Sampling | IPE | Screenshots

Table of Contents

1. Introduction & Testing Framework

2. Control 1 – Creation / Modification of User Access
3. Control 2 – User Revocation (Off-boarding)
4. Control 3 – Periodic User Access Review
5. Control 4 – Privileged Access Management
6. Control 5 – Authorized Database Access
7. Appendix – IPE Validation Framework & Sample Size Reference

Confidential | 2026 Page 2

SAP ITGC Detailed Testing Guide Population | Sampling | IPE | Screenshots

1. Introduction & Testing Framework

This guide provides step-by-step audit procedures for testing five critical SAP IT General Controls (ITGCs). For each control the
guide documents: (a) the control objective and risk statement, (b) how to define and obtain the population, (c) sample size
selection using AICPA / IIA guidance, (d) Information Produced by the Entity (IPE) requirements and validation, (e) detailed
testing procedures, (f) a complete list of required screenshots, and (g) common findings with remediation guidance.

What is IPE?
IPE (Information Produced by the Entity) refers to any report, extract, or data file generated from the client's systems and used
as audit evidence. Because the client produces this information, the auditor must validate its completeness and accuracy before
relying on it. Failure to validate IPE is one of the most common PCAOB inspection findings.

Validation Step Procedure Evidence to Retain

Completeness check Agree record count to an independent source (e.g., SM04 Screenshot of count comparison
active user count vs SU01 export row count)

Accuracy check Trace 3–5 sample records from the extract back to the Side-by-side screenshots (extract row + SAP
source screen in SAP to confirm fields match screen)

Parameters verification Screenshot the selection parameters / filters used when Screenshot of report selection screen with
running the report before extracting parameters

Date / period verification Confirm the report covers the full audit period (not truncated) Report header showing date range

Authorization to produce Note who ran the report and confirm they had appropriate User ID visible in screenshot; access
read-only access confirmation

AICPA Sample Size Reference (Low Control Risk Assumption)

Population Size Sample Size Sampling Method Rationale

1 – 24 All items 100% testing Population too small for sampling; test every item

25 – 52 15 Random / MUS Typically covers quarterly controls with full-year scope

53 – 240 25 Random Standard sample for monthly or event-driven controls

241 – 1,000 40 Random / Stratified Higher population warrants larger sample; consider
stratification by risk

1,001 + 60 Random / Stratified Large populations; stratify by department, role, or time

period

Note: Sample sizes above assume a tolerable deviation rate of 5% and expected deviation rate of 0%. Increase sample size if prior year
deficiencies exist or if the control is rated as high-risk.

Confidential | 2026 Page 3

SAP ITGC Detailed Testing Guide Population | Sampling | IPE | Screenshots

2. Control 1 – Creation / Modification of User Access

Control Objective
New SAP user accounts and role modifications are created only upon receipt of an authorized, documented request. The roles
assigned in SAP must match the approved roles in the request. The individual requesting access, the approver, and the IT
administrator who action the change must be three separate individuals.

Control Frequency
Event-driven (each provisioning occurrence throughout the year).

Key Risk
Unauthorized or excessive access is granted without proper approval, enabling unauthorized transactions, data manipulation, or
fraud.

Relevant T-codes
SU01 (User Maintenance), SU10 (Mass User Maintenance), SUIM (User Information System – Users by Role / Profile), SM04
(Active Users List), SU53 (Authorization Check Failure).

A. Population Definition
The population consists of ALL SAP user account creation events AND all role/profile modification events that occurred during
the audit period (typically 12 months). This includes new joiners, internal transfers receiving new roles, and any ad-hoc role
additions throughout the year.

Population Element How to Obtain Fields to Include

New user accounts created SU01 → display user → change log; or SUIM → Users → User ID, user name, creation date, created by,
Users by Logon Date; or SE16 → table USR02 filtered by client, validity dates
creation date

Role / profile assignments SUIM → Roles → Roles by User; SE16 → AGR_USERS User ID, role name, assigned date, assigned by,
added table (role assignments with from/to dates); or SAP GRC valid from/to
Access Control provisioning log

Mass user changes SU10 → audit log; SM20 security audit log filtered for user Change timestamp, changed by, field changed,
master record changes (event class USER) old value, new value

B. Sample Size & Selection

Population Size Sample Size Sampling Method Rationale

1 – 24 events All 100% testing Full population tested; document each item

25 – 52 events 15 Random selection Use random number generator; cover at least one event
per quarter

53 – 240 events 25 Random selection Ensure spread across full 12-month period

241+ events 40 Stratified random Stratify by department or role type; select proportionally

Practical tip: Always include at least one privileged/admin account creation in the sample if any exist. Separately test any bulk/mass user
creations (SU10) as they carry higher risk.

C. IPE – Reports & Validation

Confidential | 2026 Page 4

SAP ITGC Detailed Testing Guide Population | Sampling | IPE | Screenshots

IPE / Report Name T-code / Path Fields Required Validation Steps

User creation extract SE16 → USR02 or BNAME, ERDAT (creation date), 1) Count rows vs SM04 active users count.
(USR02 / SU01 log) SU01 change log ERNAM (created by), USTYP, 2) Trace 3 records to SU01 display screen.
GLTGB (validity end) 3) Screenshot selection parameters (date
range = full audit period). 4) Confirm extract
was run with read-only ID

Role assignment report SE16 → AGR_USERS UNAME, AGR_NAME, FROM_DAT, 1) Agree total role assignments to SUIM
(AGR_USERS) TO_DAT, ORG_FLAG role-by-user count. 2) Trace 3 sample
assignments to SU01 role tab. 3)
Screenshot SE16 selection screen with
date filter visible

SUIM user-by-role report SUIM → Users → User ID, role, validity dates, user type 1) Cross-check count to AGR_USERS
Users by Role Name export. 2) Confirm report date range covers
full audit period. 3) Screenshot SUIM
selection screen

SAP GRC provisioning log (if GRC Access Control Request ID, requestor, approver, role, 1) Agree approved request count to SU01
GRC used) → Access Request approval date, status creation count. 2) Confirm no requests with
'Approved' status lack a corresponding
SU01 account. 3) Screenshot GRC report
parameters

D. Step-by-Step Testing Procedures

Step 1 – Obtain & validate population

Run SE16 on table USR02 with ERDAT (creation date) filtered to the audit period. Export to Excel. Validate completeness:
compare row count to SM04 active user count and SU01 total user count. Document any variance. Screenshot the SE16
selection parameters screen before exporting.

Step 2 – Select sample

Apply random number selection (use =RAND() in Excel or an audit software random function) to identify the required sample
items. Document the selection methodology and seed.

Step 3 – Obtain access request documentation

For each sampled user, request the original access request ticket from the ITSM tool (ServiceNow, Remedy, JIRA, etc.). The
ticket must show: requester name, date of request, roles/access requested, approver name, and approval date/timestamp.

Step 4 – Verify segregation of duties in the provisioning process

Confirm that the user who REQUESTED access, the APPROVER, and the IT admin who ACTIONED the change in SU01 are
three different individuals. Flag any instance where the same person performed two or more of these roles as a finding.

Step 5 – Verify role match

Open SU01 for the sampled user. Go to the Roles tab. Screenshot all assigned roles. Compare the roles shown in SAP to the
roles approved on the access request ticket. Flag any roles present in SAP that were not on the approved request.

Step 6 – Verify timeliness

Compare the approval date on the request ticket to the account creation date in SAP (ERDAT in USR02 or the change log in
SU01). Flag any accounts created BEFORE an approval exists or more than 2 business days after approval (or per policy SLA).

Step 7 – Check for role modifications

Separately review the SU01 change log (SU01 → display user → Environment → Change Documents) for any role additions
post-creation. Apply the same approval-verification steps above to each modification event in the sample.

Step 8 – Document results

Confidential | 2026 Page 5

SAP ITGC Detailed Testing Guide Population | Sampling | IPE | Screenshots

For each sample item, complete the testing workpaper showing: user ID, event date, approver, roles approved vs assigned,
segregation confirmation, and pass/fail conclusion.

E. Required Screenshots Checklist

Screensh Screen / T-code What to Capture Why Required

ot #

SS-1.1 SE16 / USR02 selection Full selection screen showing date range (= audit IPE validation – proves extract covers
screen period), client, and row count result correct period and population size

SS-1.2 SU01 – Logon Data tab User ID, validity dates, user type, lock status Confirms account parameters match what
(sample user) indicator was approved

SS-1.3 SU01 – Roles tab All roles assigned to the user with valid-from / Role match test – compare to approved
(sample user) valid-to dates request

SS-1.4 SU01 – Change Change history showing who made each change Proves the IT admin who created/modified
documents (sample user) and when (Environment → Change Documents) the account

SS-1.5 Access request ticket Full ticket showing requester, approver, date, roles Primary approval evidence for segregation
(ITSM) requested, and approval status test

SS-1.6 SUIM – Users by Role SUIM selection parameters showing role searched IPE validation for role-assignment
report (selection screen) and date filters completeness

SS-1.7 SM04 – Active users Total active user count for population completeness IPE completeness check – reconcile to
count reconciliation USR02 extract count

F. Common Findings

Common Finding Risk Rating Typical Root Cause Remediation

Role assigned in SAP not on High IT admin granted additional access at Remove unauthorized roles immediately;
approved request their discretion or copied roles from update provisioning procedure; implement
another user GRC preventive SoD check

Requester = Approver (lack of High Manager self-approves access for their Update access request workflow to enforce
segregation) own account; no secondary approval different approver; re-test after remediation
required by policy

Account created before approval Medium-High IT created account based on verbal Enforce system-level workflow gate; no
exists instruction; ticket raised retrospectively provisioning without an approved ticket

No formal access request found Medium-High Informal email or verbal requests used; Implement mandatory ITSM ticket workflow;
no ticketing system for SAP provisioning retrain IT provisioning team

Confidential | 2026 Page 6

SAP ITGC Detailed Testing Guide Population | Sampling | IPE | Screenshots

3. Control 2 – User Revocation (Off-boarding)

Control Objective
SAP user accounts are promptly disabled or deleted when an employee is terminated, resigns, or is placed on extended leave.
Access is revoked within the policy-defined SLA (typically same business day to 24 hours from the official termination date
recorded in the HR system). No terminated user should have any active login capability in SAP.

Control Frequency
Event-driven (each employment termination or departure event).

Key Risk
Terminated employees or contractors retain active SAP access, enabling unauthorized transactions, data exfiltration, or
sabotage after departure.

A. Population Definition

Population Element How to Obtain Fields Required

All employee terminations in HR system / payroll system termination report. Alternatively, Employee ID, SAP User ID, termination date,
audit period request from HR team a listing of all leavers (terminations, termination type (voluntary / involuntary),
resignations, retirements, contract ends) during the period. department

Corresponding SAP Cross-reference HR termination list to SU01 account status. SAP User ID, account lock date, lock reason,
accounts for terminated Run SUIM → Users → Users with Logon Date after last logon date, current validity end date
users Termination Date as a negative test.

Contractor / vendor account Separate contractor management register or procurement Contractor ID, SAP User ID, contract end
terminations system. SAP service accounts with defined expiry dates from date, SAP validity end date
SU01.

B. Sample Size & Selection

Population Size Sample Size Sampling Method Rationale

1 – 24 terminations All 100% testing Small population; test all items

25 – 52 terminations 15 Random Include mix of voluntary and involuntary terminations

53 – 240 25 Random Ensure coverage across all four quarters

241+ 40 Stratified Stratify by department and termination type; over-sample

high-risk roles (finance, IT, HR)

Important: In addition to the standard sample, ALWAYS perform a 100% exception check (negative test) by running SUIM to identify any
terminated user who had a SAP login AFTER their termination date. This is separate from the sample test and should cover the full population.

C. IPE – Reports & Validation

IPE / Report Name T-code / Path Fields Required Validation Steps

HR termination extract HR system Employee ID, name, SAP User ID, 1) Agree count to HR management report
(SuccessFactors / SAP termination date, last working day, total leavers. 2) Trace 3 records to HR
HCM / Workday) termination reason system screens. 3) Screenshot extraction
parameters (date = full audit period). 4)
Confirm HR team sign-off on completeness

SU01 user status extract SE16 → USR02 or BNAME, UFLAG (lock flag), GLTGV / 1) Reconcile active user count to SM04. 2)
(USR02) SUIM export GLTGB (validity dates), TRDAT (last Filter locked accounts – confirm UFLAG=64
logon date) (admin lock) for terminated users. 3)
Screenshot SE16 selection screen

Confidential | 2026 Page 7

SAP ITGC Detailed Testing Guide Population | Sampling | IPE | Screenshots

IPE / Report Name T-code / Path Fields Required Validation Steps

Security audit log – SM20 → filter event User ID, login timestamp, terminal / IP 1) Run for each sampled terminated user.
post-termination logins class AU1 (successful address, client 2) Confirm no successful logins on or after
login) for terminated termination date. 3) Screenshot SM20 filter
user IDs parameters and results

SAP GRC Access Control – GRC → Access Request ID, triggered by (HR 1) Agree GRC termination events to HR list.
user termination workflow (if Request → integration / manual), completion 2) Confirm automated HR-to-GRC
applicable) Termination requests date, accounts revoked integration ran for all events. 3) Screenshot
GRC workflow completion status

D. Step-by-Step Testing Procedures

Step 1 – Obtain HR termination population

Request the complete termination listing from HR for the audit period. Validate the extract is complete by agreeing the count to
the HR management dashboard or annual headcount report. Screenshot the HR report selection parameters showing the full
12-month date range.

Step 2 – Cross-reference HR list to SAP

Map each terminated employee's HR user ID to their SAP User ID. For any gaps (HR record with no SAP User ID), enquire with
HR/IT whether the employee had SAP access. Document the mapping.

Step 3 – Select random sample

From the full population apply random selection. Ensure the sample includes at least one involuntary termination (termination for
cause) if any exist, as these carry highest risk.

Step 4 – Check account lock in SU01

For each sampled user, open SU01 (Display User). Navigate to Logon Data tab. Confirm: (a) the account shows a lock indicator,
(b) the lock type is 'Administrator Lock' (not just password lock), and (c) the lock date is on or before the termination date per the
policy SLA. Screenshot the Logon Data tab for each sample item.

Step 5 – Calculate lock timeliness

Create a workpaper column: Lock Date minus Termination Date. Per policy, this should be ≤ 0 days (same day) to ≤ 1 business
day. Flag any item where the gap exceeds the policy SLA.

Step 6 – Check for post-termination logins (SM20)

For each sampled user, run SM20 (Security Audit Log) filtering on the user ID and date range from the termination date onward.
Confirm zero successful login events (AU1) appear after the termination date. Any login after termination is an automatic High
finding.

Step 7 – Full-population negative test (SUIM)

Run SUIM → Users → Users by Logon Date with the date range set to AFTER the earliest termination date in the period.
Cross-reference results against the HR termination list. Any terminated user appearing in the SUIM logon report (i.e., they logged
in after the audit period started) must be investigated and each occurrence documented.

Step 8 – Contractor / expiry date check

For contractor accounts, open SU01 and confirm the account validity end date (Gltgb) is set to the contract end date. Screenshot
the Logon Data tab showing the expiry date.

E. Required Screenshots Checklist

Confidential | 2026 Page 8

SAP ITGC Detailed Testing Guide Population | Sampling | IPE | Screenshots

Screensh Screen / T-code What to Capture Why Required

ot #

SS-2.1 HR system termination Full extraction screen showing date range = audit IPE – population completeness and period
report period, total record count, extraction timestamp validation

SS-2.2 SU01 – Logon Data tab User ID, lock indicator, lock type, lock date / Primary test evidence – lock date vs
(each sampled user) admin-lock date, validity end date termination date comparison

SS-2.3 SU01 – Last logon date Last logon date stamp on Logon Data tab Confirms last system activity; should
field precede termination date

SS-2.4 SM20 – Security audit log Filter parameters: User = sampled user ID, Event = IPE validation – proves the correct filters
(filter screen) AU1 (Successful Login), Date = termination date were applied
onward

SS-2.5 SM20 – Results (zero Empty result screen or list of events post-termination Confirms no logins after termination date
records expected)

SS-2.6 SUIM – Negative test SUIM report parameters showing the date filter used IPE validation for negative test
selection screen for the full-population login check completeness

SS-2.7 SUIM – Negative test Result list (should contain no terminated users); or Full-population exception identification
results annotated list of any exceptions found evidence

SS-2.8 SU01 – Contractor validity Logon Data tab showing Gltgb (valid to) date for Confirms time-bound access for
end date contractor accounts non-employees

F. Common Findings

Common Finding Risk Rating Typical Root Cause Remediation

Account not locked on termination High Manual HR-to-IT notification process; Implement automated HR-to-SAP
date (SLA breach) delays in ticket routing; no automated provisioning integration; daily reconciliation
integration job; escalation alerts for breaches

Successful login after termination Critical Account not locked at all; shared Immediately lock account; investigate
date credentials; VPN/SSO bypass of SAP session; assess whether unauthorized
auth transactions occurred; consider fraud
referral

Account not deleted / remains High Account locked but not removed; no Implement 30-day post-lock deletion policy;
active for months post-exit clean-up process; forgotten service schedule regular orphaned-account
accounts cleanup runs

Contractor with no expiry date set Medium SU01 provisioning template used without Set mandatory expiry date for all
expiry date; no contractor governance non-employee accounts; automate expiry
policy notifications

Confidential | 2026 Page 9

SAP ITGC Detailed Testing Guide Population | Sampling | IPE | Screenshots

4. Control 3 – Periodic User Access Review (Recertification)

Control Objective
Business process owners (managers, not IT) formally review and certify the SAP access held by their direct reports at least
quarterly or semi-annually. Access that is no longer required is identified and revoked in a timely manner. The review produces
documented evidence of manager sign-off for each user reviewed.

Control Frequency
Periodic – quarterly or semi-annually (per organization policy).

Key Risk
Users accumulate excessive access over time due to role changes, promotions, or project assignments that are never cleaned
up ('access creep'), increasing fraud and error risk.

A. Population Definition

Population Element Source Fields Required

All access review SAP GRC Access Control → Access Review Campaign log; Campaign ID / name, review date, reviewer
campaigns conducted in the or manual review evidence repository (SharePoint, email (manager), number of users reviewed, access
audit period archive, shared drive) removed Y/N

Users included in each GRC campaign detail report or manual review spreadsheet User ID, user name, role/access listed,
campaign manager decision (certify / revoke), date of
decision

Access removals actioned Post-review ITSM tickets for revocations, or GRC automated User ID, role removed, removal date, removed
following review revocation log by, days between review decision and SU01
lock/role removal

B. Sample Size & Selection

Access reviews are periodic controls. The sample approach differs from event-driven controls:

Population Size Sample Size Sampling Method Rationale

1 review per year 1 (100%) Full review Single occurrence; test the one review in full

2 reviews (semi-ann) 2 (100%) Full review Both occurrences must be tested; select sample of users
from each

4 reviews (quarterly) 4 (100%) All occurrences All 4 must be tested; select user-level sample from each
campaign

User-level sample 25–40 users Random from each campaign For each campaign occurrence, randomly sample users
within each campaign reviewed; confirm manager certification and any
revocations

C. IPE – Reports & Validation

IPE / Report Name T-code / Path Fields Required Validation Steps

GRC Access Review SAP GRC → Access Campaign name, start/end date, 1) Confirm campaign dates align with policy
Campaign report Control → Periodic reviewer, status (complete/open), % frequency. 2) Confirm status = 'Complete'
Review → Campaign reviewed, items revoked for all campaigns in period. 3) Screenshot
Monitor campaign monitor showing all campaigns
and statuses. 4) Trace 3 user decisions to
GRC detail screen

Confidential | 2026 Page 10

SAP ITGC Detailed Testing Guide Population | Sampling | IPE | Screenshots

IPE / Report Name T-code / Path Fields Required Validation Steps

Manual recertification SharePoint / email / User ID, role, manager name, 1) Verify spreadsheet completeness against
spreadsheet (if GRC not shared drive – request certification date, decision current SU01 active user count. 2) Confirm
used) from control owner (keep/remove), signature or email manager name matches org chart. 3)
approval Confirm date is within the review period. 4)
Screenshot the spreadsheet header
showing version, date, manager name

Post-review revocation ITSM tickets or GRC Ticket number, user ID, role removed, 1) For every 'revoke' decision in the review,
evidence automated revocation date actioned, actioned by confirm a corresponding SU01 change
log exists. 2) Calculate days between review
decision and SU01 change. 3) Screenshot
SU01 change documents post-review

SUIM current role SUIM → Roles → User ID, role, valid from/to 1) For users where access was marked
assignment report Roles by User 'revoke', confirm role no longer appears in
SUIM. 2) Reconcile SUIM count to GRC
campaign count. 3) Screenshot SUIM
selection and output

D. Step-by-Step Testing Procedures

Step 1 – Confirm review was performed for all required periods

Obtain the list of all access review campaigns from GRC or the control owner. Confirm the number of reviews matches the policy
frequency (e.g., 4 quarterly reviews for a January–December audit year). If any campaign is missing, this is a control gap /
non-performance finding.

Step 2 – Confirm business manager (not IT) performed the review

For each campaign, check the reviewer field. The reviewer must be the business manager / process owner, NOT an IT or SAP
team member. If IT performed the review, this is a segregation deficiency (IT should not certify their own access grants).

Step 3 – Verify completeness of the review

Compare the number of users included in the campaign to the total active user count from SU01 at the time of the review. All
active SAP users must be covered. Flag any users excluded from the review. Screenshot the campaign user count and SU01
active user count for reconciliation.

Step 4 – Select user-level sample from each campaign

Within each campaign, randomly select 25 users (or all if fewer than 25). For each selected user obtain the manager's
certification decision (Certify / Revoke) and the date of the decision.

Step 5 – Verify revocations were actioned

For every user in the sample where the manager decided to REVOKE access, check SU01 or the ITSM ticket to confirm the
access was actually removed. Calculate the number of days between the revocation decision date and the SU01
lock/role-removal date. Flag any revocation not actioned within the policy SLA (typically 5 business days).

Step 6 – Check for access certifications that should have been revoked

For a selection of users marked as 'Certified', cross-check their current roles against the HR system to confirm they are still in the
same role. If a user was certified but has since moved roles or been terminated, flag as a review quality deficiency.

Step 7 – Assess overall review quality

If >90% of users were simply 'rubber-stamped' as certified with no removals at all, perform additional inquiry with the control
owner. A review with zero removals across a large user base may indicate a superficial review rather than genuine
recertification.

E. Required Screenshots Checklist

Confidential | 2026 Page 11

SAP ITGC Detailed Testing Guide Population | Sampling | IPE | Screenshots

Screensh Screen / T-code What to Capture Why Required

ot #

SS-3.1 GRC Campaign Monitor All campaigns in the period with: name, frequency, Confirms all required review cycles were
(or equivalent) start date, end date, status (complete/incomplete), completed by business managers
reviewer name

SS-3.2 GRC Campaign detail – User ID, role listed, manager decision Primary evidence of manager review
user-level decisions (certify/revoke), decision date for sampled users decision for each sample item

SS-3.3 SU01 – Logon Data / For each revoked user: SU01 screen showing role Confirms revocation decisions were actually
Roles tab post-revocation removed or account locked, with change date actioned in SAP

SS-3.4 SU01 Change Change log entries showing role removals Timeliness evidence: days between
Documents – post-review post-review decision date decision and action
changes

SS-3.5 Manual review Document title, review period, manager name, date Authenticates the review document and
spreadsheet header (if no signed, signature or email thread confirms manager (not IT) performed it
GRC)

SS-3.6 SUIM – current role SUIM search result for a revoked user showing role Confirms the revocation is fully reflected in
assignments for revoked no longer assigned SAP authorization layer
users

F. Common Findings

Common Finding Risk Rating Typical Root Cause Remediation

Access review not performed for High No formal process; control owner Implement SAP GRC Access Review
one or more required periods turnover; manual burden without GRC campaigns with automated reminders;
automation assign deputy control owners

IT team performed the review High Business owners unaware of Re-assign review ownership to business;
instead of business managers responsibility; IT fills the gap for provide training; update RACI; re-perform
convenience review with correct owner

Revocation decisions not actioned Medium-High Manual workflow between review tool Automate revocation from GRC to SU01;
within SLA and SU01; no escalation process add SLA breach alerts; re-test after fix

Large proportion of 'certify' Medium Managers not reviewing in detail; review Implement mandatory justification field for
decisions with no removals process too burdensome; lack of certifications; audit a random sample of
(rubber-stamp risk) accountability certified access for reasonableness

Confidential | 2026 Page 12

SAP ITGC Detailed Testing Guide Population | Sampling | IPE | Screenshots

5. Control 4 – Privileged Access Management

Control Objective
Access to SAP superuser profiles (SAP_ALL, SAP_NEW), Basis administrator functions, and emergency/FireFighter IDs is
restricted to the minimum number of authorized individuals. All privileged access usage is pre-approved, time-limited, logged by
the system, and the logs are independently reviewed after each use by a control owner who is separate from the user of the
privileged access.

Control Frequency
Standing privileged access – reviewed periodically (quarterly). FireFighter ID usage – reviewed after each use (event-driven).

Key Risk
A user with SAP_ALL or unrestricted Basis access can create accounts, change configurations, post any transaction, view all
data, and delete audit logs — bypassing every application control. Unmonitored privileged access is the highest-risk ITGC
exposure.

A. Population Definition

Population Element How to Obtain Fields Required

Users with SAP_ALL or SUIM → Profiles → Users by Profile – search for SAP_ALL User ID, profile name, assigned date, client,
SAP_NEW profiles and SAP_NEW separately. Also SE16 → UST04 user type
(user-profile assignments)

Users with critical Basis SUIM → Authorization Objects → Users with Authorization User ID, authorization object, field values, role
authorization objects Values – objects: S_DEVELOP (production), S_RZL_ADM, name containing the object
S_ADMI_FCD, S_TABU_DIS with sensitive tables

FireFighter / Emergency SAP GRC → Firefighter → Log Report (GRACFFLOG); or FF ID, user who checked out FF ID, checkout
Access IDs and all usage SE16 → GRACFFALL for FF activity log table date/time, return date/time, reason/ticket,
events approver

Privileged ID usage in SM20 – filter on privileged user IDs for the full audit period, User ID, event class, event description, date,
Security Audit Log event classes: DU (user master changes), AU (logon), BU time, client, terminal
(authorization failures)

B. Sample Size & Selection

Privileged access testing uses a combination of full-population review (for standing access) and sampling (for FF usage events):

Population Size Sample Size Sampling Method Rationale

SAP_ALL / SAP_NEW 100% (all holders) Full population Small population; test ALL holders; each represents critical
holders risk

Basis admin privilege 100% or top 5–10 Full or judgmental If population > 10, judgmentally select highest-risk roles
holders

FireFighter usage All events 100% Low frequency; all events must be reviewed
events (1–24)

FF usage events 15 Random Cover all FF IDs used; ensure each ID sampled at least
(25–52) once

FF usage events (53+) 25–40 Random stratified Stratify by FF ID and user; ensure no single user
dominates the sample

C. IPE – Reports & Validation

Confidential | 2026 Page 13

SAP ITGC Detailed Testing Guide Population | Sampling | IPE | Screenshots

IPE / Report Name T-code / Path Fields Required Validation Steps

SUIM – Users by Profile SUIM → Profiles → User ID, profile name, validity dates, 1) Run separately for SAP_ALL and
(SAP_ALL / SAP_NEW) Users by Profile Name user type, client SAP_NEW. 2) Cross-check count to UST04
SE16 export. 3) Screenshot SUIM selection
screen with profile name parameter clearly
visible. 4) Confirm report date = run date
(point-in-time access check)

GRC FireFighter Log Report SAP GRC Access FF ID, reason code, user, checkout 1) Agree FF log count to SE16
Control → Firefighter date/time, return date/time, activity GRACFFALL total rows for the period. 2)
→ Log Report performed, approver Trace 3 events to GRC FF detail screen. 3)
Screenshot GRC log selection parameters
(date range, all FF IDs selected). 4) Confirm
extract is complete (check row count before
and after applying date filter)

SM20 – Security Audit Log SM20 → filter by user User, date, time, event class, 1) Confirm audit logging is enabled: run
for privileged IDs ID list, event = DU* / description, terminal, client SM19 and screenshot log-active status. 2)
AU* Screenshot SM20 filter parameters showing
user IDs and date range. 3) Confirm log
retention covers full audit period

UST04 – User-to-profile SE16 → table UST04 BNAME (user), PROFILE, MANDT 1) Filter for SAP_ALL and SAP_NEW. 2)
assignment table (client) Reconcile count to SUIM. 3) Screenshot
SE16 selection screen. 4) Note any users in
production vs non-production

D. Step-by-Step Testing Procedures

Step 1 – Identify all SAP_ALL / SAP_NEW holders

Run SUIM → Users by Profile for SAP_ALL and SAP_NEW across ALL clients (especially production – typically client 100 or 200
in ECC). For each holder: confirm there is a documented business justification and senior management approval (CISO or IT
Director level). Screenshot the SUIM output showing user IDs and validity dates.

Step 2 – Verify minimum necessary principle

Question whether each SAP_ALL holder genuinely requires this level of access. SAP_ALL should be limited to: emergency
break-glass accounts (locked when not in use) and maximum 1–2 senior Basis administrators with a documented business case.
Flag any developer, functional consultant, or business user with SAP_ALL as an automatic High finding.

Step 3 – Check SAP_ALL accounts are locked when not in use

For standing SAP_ALL accounts (emergency/break-glass), confirm the account is locked in SU01 except during approved use
windows. Check the SM20 log to see if the account was unlocked at any time during the period — if so, confirm it aligns to an
approved emergency event.

Step 4 – Review FireFighter ID governance

Obtain the GRC FireFighter configuration: (a) list of FF IDs, (b) roles assigned to each FF ID, (c) list of users authorized to check
out each FF ID (FF User assignment), (d) list of FF Owner IDs (the individuals who review FF logs). Screenshot the GRC FF
configuration screen.

Step 5 – Test FireFighter usage sample

For each sampled FF usage event: (a) confirm a pre-approved ticket/reason code exists for the checkout, (b) confirm the
checkout duration was reasonable (not weeks-long), (c) confirm the FF Owner reviewed the log after the session (GRC log
review workflow completion), (d) confirm the activity in the log matches the stated purpose of the checkout.

Step 6 – Test FF log review timeliness

The FF Owner (reviewer) must review activity logs within 24–48 hours of FF ID return. Compare the FF return timestamp to the
GRC log-review completion timestamp. Flag any reviews completed more than 2 business days after the session as a timeliness

Confidential | 2026 Page 14

SAP ITGC Detailed Testing Guide Population | Sampling | IPE | Screenshots

exception.

Step 7 – Review SM20 for unauthorized privileged activity

Run SM20 for all privileged user IDs covering the full audit period. Look for: (a) logins at unusual hours (outside business hours),
(b) user master record changes (DU events) without a corresponding change ticket, (c) authorization object changes, (d) table
browser access (SE16/SE17) on sensitive tables (HR, payroll, financial). Document and investigate any anomalies.

E. Required Screenshots Checklist

Screensh Screen / T-code What to Capture Why Required

ot #

SS-4.1 SUIM – Users by Profile: Selection screen (profile = SAP_ALL, client = Complete list of SAP_ALL holders; IPE
SAP_ALL production) AND results list showing all holders, completeness validated against UST04
valid dates, user type

SS-4.2 SUIM – Users by Profile: Same as above but for SAP_NEW profile Confirms SAP_NEW holders — separate
SAP_NEW risk profile from SAP_ALL

SS-4.3 SU01 – SAP_ALL Logon Data tab for each SAP_ALL holder showing Confirms emergency accounts are locked
account lock status lock indicator (and lock date for break-glass at rest
accounts)

SS-4.4 GRC FireFighter FF ID list with: roles assigned, authorized users, FF Governance structure evidence; confirms
configuration screen Owner (log reviewer), active/inactive status owner is separate from FF user

SS-4.5 GRC FF Log Report – GRC log selection parameters: date range = full IPE validation – proves all FF activity in the
selection screen audit period, all FF IDs included period was captured

SS-4.6 GRC FF Log – individual FF ID, checked-out by, date/time, reason code / Primary evidence for each sampled FF
usage detail (sampled ticket #, activities performed, return date/time usage event
event)

SS-4.7 GRC FF Log Review FF Owner review workflow status = 'Reviewed', Confirms independent post-use review was
completion (sampled reviewer name, review completion date/time performed and is timely
event)

SS-4.8 SM20 – filter parameters Filter screen showing: user ID list (privileged IPE validation for security audit log review
for privileged ID review accounts), event classes (AU, DU, BU), date range = scope
full audit period

SS-4.9 SM19 – audit log active SM19 screen confirming security audit logging is Confirms log completeness – prerequisite
status enabled (Active = Yes) and filters cover all clients for SM20 testing

F. Common Findings

Common Finding Risk Rating Typical Root Cause Remediation

Business / functional users Critical Convenience; emergency access never Remove immediately; redesign roles;
assigned SAP_ALL removed; poor role-design leading to implement GRC FireFighter for legitimate
SAP_ALL workaround emergency needs

FireFighter logs not reviewed after High FF Owner unaware of responsibility; Configure mandatory GRC log review
use GRC workflow not configured; manual workflow; escalation email to CISO if review
process broken not completed within 48 hrs

Multiple users sharing a single FF High Convenience; insufficient FF IDs Create individual FF IDs per person; never
ID provisioned for the team size share credentials; non-repudiation is lost
with shared IDs

Confidential | 2026 Page 15

SAP ITGC Detailed Testing Guide Population | Sampling | IPE | Screenshots

Common Finding Risk Rating Typical Root Cause Remediation

SAP_ALL assigned to developer in Critical Developer needed emergency fix; Remove S_DEVELOP and SAP_ALL from
production access never removed; no FireFighter production; implement change
alternative in place management procedure for emergency
patches

Confidential | 2026 Page 16

SAP ITGC Detailed Testing Guide Population | Sampling | IPE | Screenshots

6. Control 5 – Only Authorized Users Have Access to the Database

Control Objective
Direct access to the SAP database (SAP HANA, Oracle, or Microsoft SQL Server) is restricted exclusively to authorized
database administrators (DBAs) who require it for their job function. End-users, business analysts, functional consultants, ABAP
developers, and application support staff must NOT have direct database-level credentials. All legitimate system access occurs
through the SAP application layer, which enforces all authorization checks.

Control Frequency
Periodic review of database user accounts (minimum semi-annually) + event-driven review of any new DBA account creations.

Key Risk
Direct database access completely bypasses SAP's authorization layer. A user with direct DB access can read all financial data,
modify transaction records, delete audit entries, and extract confidential data (HR, payroll, vendor master) without any SAP-level
controls preventing or logging the activity.

A. Population Definition

Population Element How to Obtain Fields Required

All database user accounts SAP HANA Studio or HANA Cockpit → Security → Users; or Username, user type (standard/restricted),
(SAP HANA) SQL: SELECT USER_NAME, USER_STATUS, privileges granted, last login, active/inactive
LAST_SUCCESSFUL_CONNECT FROM [Link] status, creation date

All database user accounts SQL: SELECT USERNAME, ACCOUNT_STATUS, Username, account status, created date, last
(Oracle) CREATED, LAST_LOGIN, PROFILE FROM DBA_USERS login, profile, granted roles
ORDER BY USERNAME

Database privilege / role HANA: SELECT * FROM SYS.GRANTED_ROLES WHERE Grantee (username), privilege or role, admin
assignments GRANTEE = ''. Oracle: SELECT GRANTED_ROLE, option Y/N, grantor
ADMIN_OPTION FROM DBA_ROLE_PRIVS WHERE
GRANTEE = ''

SAP application layer – OS / OS-level: /etc/passwd for UNIX (SAP system user accounts); OS username, group membership, last
DB-level admin accounts Windows: local admin group members on DB server password change, account status

SAP system users with DB These are SAP's own service accounts; confirm they use Account name, password last changed, who
access (e.g., SAPABAP1, secure passwords and are not shared with human users knows the password (documented in
SAPHANA) password vault)

B. Sample Size & Selection

Unlike event-driven controls, database access is a point-in-time population review. The objective is to test ALL accounts, not a
sample — because each unauthorized account represents a complete control bypass:

Population Size Sample Size Sampling Method Rationale

DBA accounts All 100% review DBA population should be tiny; test every account
(expected: 2–5)

DB user accounts All 100% authorization check Every DB user must be on the authorized DBA list
(total DB users)

DB privilege All critical 100% for admin/DBA roles Focus on SYSDBA, DBA role, SAP_INTERNAL; any grant
assignments privileges of these is critical

New DB accounts All or 25 100% or random All new DB accounts require an authorized change ticket
added in period

Key principle: The authorized DBA list should be a very short list (typically 2–5 individuals). If the DB user list contains dozens of accounts, the
control is likely deficient by design.

Confidential | 2026 Page 17

SAP ITGC Detailed Testing Guide Population | Sampling | IPE | Screenshots

C. IPE – Reports & Validation

IPE / Report Name T-code / Path Fields Required Validation Steps

SAP HANA DB user extract HANA Studio → USER_NAME, USER_STATUS, 1) Run SQL query and capture full result (all
[Link] view, or LAST_SUCCESSFUL_CONNECT, users). 2) Screenshot the SQL query AND
HANA Cockpit → User CREATOR, CREATE_TIME, the result set. 3) Confirm result was run on
Management USER_DEACTIVATED production HANA system (check system ID
in connection string). 4) Agree row count to
DBA team's authorized list. 5) Trace 3
records to HANA Cockpit user screen

Oracle DB user extract SQL*Plus or SQL USERNAME, ACCOUNT_STATUS, 1) Screenshot SQL query with connection
Developer: SELECT * CREATED, LAST_LOGIN, details (instance name visible). 2) Export
FROM DBA_USERS; DEFAULT_TABLESPACE, results to Excel. 3) Agree total user count to
SELECT * FROM GRANTED_ROLE DBA register. 4) For any unknown account,
DBA_ROLE_PRIVS; request creation authorization record

Authorized DBA list IT Security team – Name, employee ID, SAP User ID, 1) Obtain current authorized DBA list from
formal DBA DB username, authorization date, IT security or Basis team. 2) Confirm each
authorization register; approver, business justification person on the list has an HR job title
HR job title consistent with DBA function. 3) Confirm
confirmation each was formally authorized (IT Manager
or CISO approval). 4) Screenshot
authorization register / email approvals

DB access review evidence IT Security Review date, reviewer (must be IT 1) Confirm review was performed in the
semi-annual or annual Manager or CISO level), accounts audit period. 2) Confirm reviewer is at
access review for DB reviewed, any removals appropriate level. 3) Screenshot or copy of
accounts review sign-off. 4) For any account
removed, confirm DB-level deletion was
completed

SCC4 – SAP client settings SAP T-code SCC4 Client number, client name, change 1) Run SCC4 and screenshot all clients. 2)
option, client role, protection level Confirm production client shows 'Changes
to Repository and cross-client customizing
objects not allowed'. 3) Confirms
application-layer protection complements
DB-layer review

D. Step-by-Step Testing Procedures

Step 1 – Extract complete database user list

Coordinate with the SAP Basis / DBA team to run the database user query on the PRODUCTION database. For SAP HANA: run
the SQL against [Link]. For Oracle: run against DBA_USERS and DBA_ROLE_PRIVS. Critically: screenshot the query
AND the connection details confirming you are on the production system (system ID, hostname).

Step 2 – Obtain the authorized DBA list

Request the formal list of individuals authorized to have direct database access from the IT Security Manager or CISO. This
should be a formally maintained register, not a verbal list. If no formal register exists, this is itself a finding.

Step 3 – Compare DB user list to authorized DBA list

For EVERY account in the database user extract, confirm it appears on the authorized DBA list. Any database account not on the
authorized list is an immediate exception requiring investigation. Also check: are all authorized DBAs actually in the DB? (To
ensure the authorized list is current.)

Step 4 – Verify authorization for each DBA account

For each DBA account on the authorized list, confirm: (a) there is a formal approval document (manager / CISO sign-off), (b) the
approval is still current (not expired or for a former employee), (c) the employee's HR job title is consistent with a DBA role (flag if

Confidential | 2026 Page 18

SAP ITGC Detailed Testing Guide Population | Sampling | IPE | Screenshots

a business user or developer is listed as an authorized DBA).

Step 5 – Review DB privilege assignments

For each DB user account, check the privileges assigned. Flag any non-DBA account with: SAP HANA – CATALOG READ,
DATA ADMIN, USER ADMIN, or OPERATOR system privileges; Oracle – DBA role, SYSDBA, CREATE USER, DROP USER,
ALTER USER.

Step 6 – Check SAP system service accounts

Confirm SAP's own service accounts (SAPABAP1, SAPHANA, SAPDBA) use secure, non-default passwords stored in a
password vault. Confirm no human user knows these passwords directly. Request the password vault policy and last rotation
date.

Step 7 – Check for last login anomalies

Review the last login date for each DB account. Flag: (a) any account with no logins in >90 days (potentially orphaned/unused —
consider for deletion), (b) any account with a last login date after a person's termination date.

Step 8 – Verify SCC4 production client lock

Run SCC4 and confirm the production SAP client is set to 'Changes and transports for client-specific objects not allowed' (or
higher protection). Screenshot the SCC4 output. This is a complementary application-layer control to the DB access restriction.

Step 9 – Confirm periodic DB access review was performed

Obtain evidence that a formal DB access review was conducted in the audit period. Confirm the reviewer is at an appropriate
level (IT Manager or CISO). Confirm any accounts identified for removal were actually removed from the database.

E. Required Screenshots Checklist

Screensh Screen / T-code What to Capture Why Required

ot #

SS-5.1 HANA SQL query + SQL query text (SELECT * FROM [Link]) Confirms the query was run on
connection info AND connection string / system ID showing PRODUCTION system; IPE authenticity
production database

SS-5.2 [Link] / Full result set: all DB usernames, status, last login, Complete population of database accounts
DBA_USERS query result creation date (exportable to Excel) for authorization check

SS-5.3 HANA Cockpit / Oracle User detail screen showing: username, user type, Confirms privilege assignments for sample
Enterprise Manager – privileges assigned, last login, active status accounts
individual user detail
(sampled)

SS-5.4 Authorized DBA register Formal list / register showing: name, DB username, Basis for comparison; confirms formal
authorization date, approver, current status governance of DB access

SS-5.5 DBA approval Manager or CISO approval email / form showing Access authorization evidence – confirms
documentation (sampled authorization for the sampled DBA account each DBA was formally approved
DBA)

SS-5.6 SCC4 – production client SCC4 screen showing production client protection Complementary application-layer control;
settings level (Changes not allowed or higher) limits direct DB impact via transport bypass

SS-5.7 DB access review sign-off Evidence that periodic DB access review occurred: Demonstrates ongoing monitoring of the DB
review date, reviewer, accounts confirmed / removed access population

SS-5.8 Password vault policy Password vault access log or policy screen showing Confirms SAP system accounts are
(service accounts) SAP service account passwords are vaulted and securely managed
rotated

F. Common Findings

Confidential | 2026 Page 19

SAP ITGC Detailed Testing Guide Population | Sampling | IPE | Screenshots

Common Finding Risk Rating Typical Root Cause Remediation

Developer or functional user with Critical Developer needed ad-hoc data fix; Immediately revoke; investigate all activity
direct DB access access never removed; no DB access since access was granted; implement DB
governance access governance policy

No authorized DBA register High Informal management of DB access; Create and maintain formal DB access
maintained assumption that 'only the DBA team has register; review and certify semi-annually;
access' without formal list CISO sign-off

SAP service account passwords High Passwords shared informally among Rotate all service account passwords
not vaulted / known to multiple team; no password rotation process; immediately; store in CyberArk or
people original default passwords equivalent vault; restrict access to vault

No periodic review of DB user Medium-High DB access treated as 'set and forget'; no Implement semi-annual DB access review;
accounts process to identify orphaned or include in IT Security review calendar;
excessive accounts assign reviewer (not the DBA team
themselves)

Legacy / service accounts with Medium-High Historical migration accounts; Disable immediately pending investigation;
DBA privileges and no owner test/sandbox accounts promoted to implement account ownership requirement
production for all DB accounts

Confidential | 2026 Page 20

SAP ITGC Detailed Testing Guide Population | Sampling | IPE | Screenshots

7. Appendix – IPE Validation Framework & Quick Reference

A. IPE Validation Checklist (Universal)

IPE Validation Step Procedure Evidence to Document

1. Identify the IPE Before testing begins, list every report/extract you will rely on IPE log in workpaper identifying each report,
as audit evidence. Each one must be separately validated. its source, and who produced it

2. Validate completeness Agree the record count in the extract to an independent Screenshot of count comparison with variance
count (SM04 active users, HR headcount, GRC campaign note (if any)
total). Any variance must be explained.

3. Validate accuracy Trace 3–5 records from the extract back to the live SAP Side-by-side screenshots: extract row + SAP
system screen. Fields must match exactly. screen for same user/event

4. Capture parameters Before exporting any report, screenshot the selection Screenshot of report parameter/selection
parameters screen. This proves the correct period, client, screen prior to extraction
and filters were applied.

5. Confirm coverage period The report header or parameters must show the extract Report header with date range; or parameter
covers the full audit period (not a partial period). screen showing FROM/TO dates = audit
start/end

6. Document who ran the Record the SAP User ID and name of the person who ran User ID visible in screenshot header; SAP
report each report. Confirm they had read-only access and are access confirmation for that user ID
independent from the control owners.

B. Master Screenshot Index – All 5 Controls

Ref Control Screenshot Description Purpose

SS-1.1–1. User Creation/Modification SE16/USR02, SU01 Logon+Roles+Change docs, Approval chain, role match, provisioning
7 ITSM ticket, SUIM, SM04 segregation

SS-2.1–2. User Revocation HR termination report, SU01 lock status + last login, Timeliness of lock; no post-termination
8 SM20 (filter + results), SUIM negative test logins; full-population exception test

SS-3.1–3. Access Review GRC campaign monitor, GRC user decisions, SU01 All review cycles completed; manager
6 post-revocation, SU01 change docs, manual (not IT) certified; revocations actioned
spreadsheet, SUIM post-revocation

SS-4.1–4. Privileged Access SUIM SAP_ALL+SAP_NEW, SU01 lock, GRC FF Minimum privilege; FF governance;
9 config, GRC FF log, GRC FF review, SM20 post-use independent review; audit log
(filter+events), SM19 active

SS-5.1–5. Database Access HANA/Oracle SQL + results, HANA Cockpit user Only authorized DBAs have DB access;
8 detail, DBA register, DBA approval, SCC4, DB formal governance; service accounts
review sign-off, password vault secured

C. Key SAP T-codes Reference

T-code Description Controls Relevant To

SU01 User master record – create, display, lock, change password, view All 5 controls
roles

SU10 Mass user administration Control 1, Control 2

SUIM User Information System – comprehensive access reports by user, All 5 controls
role, profile, authorization object

Confidential | 2026 Page 21

SAP ITGC Detailed Testing Guide Population | Sampling | IPE | Screenshots

T-code Description Controls Relevant To

SM04 Active users in the system (current logged-in users count) Controls 1, 2, 3

SM20 Security audit log viewer – logon events, user master changes, Controls 2, 4
authorization failures

SM19 Security audit log configuration – confirm logging is active Control 4

SE16 Data browser – direct table access (USR02, AGR_USERS, UST04, All 5 controls
GRACFFALL, etc.)

SCC4 Client settings – production client change protection levels Control 5

RZ10/RZ11 Profile parameter maintenance/viewer – login policy parameters Controls 1, 4

SE10/STMS Transport organizer / Transport Management System Change Management (complementary)

AGR_USERS Role-to-user assignment table with validity dates Controls 1, 3

(SE16)

UST04 (SE16) User-to-profile assignment table – check SAP_ALL holders Control 4

GRACFFALL GRC FireFighter activity log table Control 4

(SE16)

Confidential | 2026 Page 22