OS-01

Control Description

The operating system layer is configured to require passwords based on appropriate parameters (complexity, history, minimum length, expiration, lockout, etc.), which are enforced per company policy

Risk

Inadequate OS-level password enforcement may result in unauthorized operating system access, enabling privilege escalation, unauthorized modifications to SAP/HANA infrastructure, and circumvention of application-level controls

Implementation Details

Objective and Plain-English 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.

Test Procedures

Test of Design (ToD):
• Inquire of IT security and compliance management to understand the methodology 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.

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.

• Sample a selection of reviewed users and confirm that business owners or managers explicitly certified or rejected the sensitive access items using plain-English risk descriptions.

• Verify that any rejected or unapproved sensitive access was successfully revoked from the user IDs in the target application within a defined remediation window.