APP-01

Control Description

Application changes are tested in a non-production environment prior to production implementation, and evidence of testing sign-off is documented and retained.

Risk

Changes to application systems or programs that are not properly tested may introduce errors, software defects, or vulnerabilities into the production environment.

Implementation Details

Implementation details:

• Enforces a rigid 3-tier SAP landscape (Dev -> QA -> Prod) where production client settings are locked via SCC4 (repository and cross-client customizing set to Modifications not allowed).

• Physical configuration and code changes originate natively within the SAP Development environment, generating transport requests prefixed with the development System ID (SID).

• In SAP ChaRM or Cloud ALM, change tracking is synchronized by assigning or automatically generating these transport requests within the change document/feature workflow.

• In traditional ticketing setups (ServiceNow/Jira), the physical transport is linked to the ticket using the transport short text as a cross-reference.

• Transports are migrated from Development to QA for testing using the Transport Management System via STMS.

• Functional and user acceptance testing (UAT) results, along with risk assessments, are documented and retained as evidence inside the tracking/ALM system.

• Prior to production deployment, formal management approval is secured directly within the workflow gate.

• Segregation of Duties (SoD) is strictly maintained; developers are restricted from importing their own transports into production.

• Production imports are executed exclusively by authorized Basis personnel or automated pipelines (often leveraging SAP GRC Firefighter IDs) via STMS or STMS_IMPORT.

• Complete audit trails are retained, cross-referencing transport movement logs in STMS_HISTORY against approved ticket or workflow approval timestamps.

Test Procedures

A) Test of Design

• Inquire of relevant IT management and change management personnel to understand the design of the change control process, including the integration between SAP transport mechanisms (via STMS) and tracking/ALM systems (ServiceNow, Jira, SAP ChaRM, or SAP Cloud ALM).

• Inspect the enterprise Change Management policy and workflow configurations to verify that they mandate documented non-production testing, formal management approval gates prior to production deployment, and Segregation of Duties (SoD) ensuring developers cannot import their own transports.

B. Test of Operating Effectiveness (ToE)

Audit Objective: Verify that the designed controls over testing, approvals, and transport execution operated consistently and effectively throughout the audit period.

1- Population Extraction: Extract the complete population of transports migrated to Production using STMS_HISTORY across the audit period.

2- Sample Selection: Select a representative sample of production transports (typically 25 for the year).

3- Testing and Evidence Verification: Trace each sample transport ID back to its tracking record (ServiceNow, Jira, ChaRM, or Cloud ALM).

4- Inspect the record to verify that explicit functional or UAT testing scripts and results are attached and dated prior to the production deployment.

5 - Approval Gate Verification: Inspect the tracking workflow or ticket to ensure that formal management approval metadata is present and timestamped before the production import time recorded in STMS_HISTORY.

6- Segregation of Duties (SoD) Verification: Cross-reference the developer ID against the user who executed the production import via STMS, STMS_IMPORT, or an authorized SAP GRC Firefighter ID to confirm that developers did not move their own changes into production.