APP-06

Control Description

Management performs a periodic review of end-user sensitive access to applications using a defined ruleset (e.g., SAP GRC) to identify, evaluate, and remove inappropriate or critical risk exposures (such as critical IT or business functions).

Risk

Lack of periodic management review of application user access rights may result in users retaining excessive or inappropriate access to critical IT and business functions that is not commensurate with their job responsibilities.

Implementation Details

Objective and Philosophy:
•The primary objective of the sensitive access review is to evaluate high-risk privileges through intuitive, plain-English risk statements (e.g., "access to maintain general ledger accounts is restricted") rather than dumping raw technical role mappings (such as raw exports of table AGR_USERS), since cryptic SAP role names are often confusing to business reviewers.

Sensitive Access Ruleset Configuration & Risk Scoping:
• Management, business process owners, and IT security collaborate to configure a tailored single-function sensitive access ruleset within SAP GRC, mapping out specific high-risk transaction codes, authorization objects, and custom "Z" transactions into targeted risk definitions.

Core Risk Categories Configured in the Ruleset:

◘ Basis & Technical Administration: Restrictive technical capabilities mapped as single-function risks, including production debugging (DEBUG, SE30), user and role administration (SU01, PFCG), and transport management (STMS).

◘ Financial & Accounting Master Data & Postings: High-risk single functions such as independent creation or modification of vendor/customer master records, bank detail alterations, and manual journal entry overrides.

◘ Logistics, Procurement & Inventory: Sensitive operational functions allowing individuals to bypass dual controls, such as maintaining purchasing info records, overriding credit limits, or executing inventory write-offs.

◘ Periodic Review Campaign Execution: Management schedules recurring campaigns (e.g., quarterly or semi-annually) via SAP GRC Access Governance to present reviewers with clear, risk-specific statements (e.g., capability to perform Basis user administration or alter banking data) rather than generic role views, requiring explicit business owner certification or automated revocation of unneeded privileges.

User Population Rationalization:
• Prior to running risk analysis or launching review campaigns, management rationalizes the baseline user listing (extracted from table USR02) by filtering out expired, invalid, and locked user IDs, ensuring the review focuses strictly on active dialog and service accounts to eliminate noise and false positives.

Test Procedures

A) Test of Design (ToD):

• Inquire of IT security and compliance management to understand the methodology, population extraction criteria (including USR02 filtering for active dialog/service users), and ruleset design for sensitive access reviews.

• Inspect the SAP GRC configuration to verify that single-function sensitive access rules (covering Basis administration, financial master data, and procurement overrides) are active and mapped to plain-English risk definitions rather than raw technical roles.

• Review campaign schedule configurations in SAP GRC to verify that periodic review cycles (e.g., quarterly or semi-annually) are established.

B) Test of Operating Effectiveness (ToE):

• Obtain documentation, campaign sign-off logs, and audit trails for a completed periodic sensitive access review cycle during the period.

• Verify that the initial review population properly excluded inactive, locked, or expired user accounts.