Validate SAP S/4HANA - and keep it validated in operation.
ERP systems such as SAP S/4HANA carry the GxP core processes, from manufacturing through release to the distribution of medicinal products and medical devices. That makes them some of the most critical systems in a company. Here, too, what gets validated is the application in its process, against the intended use. Cloud operating models such as RISE with SAP do not change that obligation, but they do change the division of labor: SAP runs the platform; the evidence stays with the operator. We bring order to these responsibilities, extend SAP Activate with the validation perspective and factor operations in from day one.
What SAP takes on and what stays with you.
With RISE with SAP (S/4HANA Cloud Private Edition), a company rents operations and the technical platform. SAP's contractual Roles & Responsibilities catalog divides the work into service categories, and its default rule is unambiguous: whatever is not purchased or provided as a standard service is the customer's responsibility. For the GxP operator that means: what gets validated is the application in its process, and that obligation stays with the operator under RISE as well.
| Layer | SAP (RISE) | With the operator |
|---|---|---|
| Technical platform (data center, OS lifecycle, database upgrades, infrastructure security) | standard service | supplier oversight per EU GMP Annex 11: assess the evidence, including for subproviders |
| GxP services (Installation Qualification, regulated change and configuration management, Periodic Review) | paid Optional Services ("must be specifically contracted for") | agree contractually, assess, and embed them in your own QMS |
| Functional testing and acceptance of changes, including SAP-applied security notes | Excluded Task ("can only be performed by the customer") | entirely with the operator |
| Validation against the intended use | no SAP offering | the core of the operator's duty: demonstrating fitness for purpose in the operator's own process |
This dividing line is our reading, and it is consistent with GAMP: the platform below rests on qualified infrastructure, while verification and validation of the application sit above it. SAP's catalog itself never speaks of validation. The substance stays the same. Verification at the application level cannot be delegated to SAP, and supplier oversight stays with the operator, including where SAP uses hyperscalers as subproviders.
From standard to validated system.
SAP's implementation methodology, SAP Activate, reaches the target state through Fit-to-Standard workshops. What we found missing in our own projects was the validation perspective, which is exactly why we extended the methodology: the Fit-to-Standard decisions yield intended use, requirements and risk assessment in a single pass. Standard before configuration, effort scaled by risk.
- 1
Audit & assessment
The current state of ERP validation and operation; processes, master data and authorization concepts assessed as the starting point.
- 2
Fit-to-Standard & intended use
The workshops establish what the standard covers and record what the system is needed for in the process. The intended use comes from the process: the intent the system is built, adapted and extended for. After implementation, the operator checks whether the system meets that intent.
- 3
Requirements & risk analysis
Requirements management as the central element; risk analyses weigh processes and functions by patient, product and data integrity risk. This includes identifying organizational risks: requirements the system does not cover, or covers only with disproportionate effort, are named and mitigated at the process level.
- 4
Validation
Process-oriented documentation, a risk-based test strategy and data integrity including 21 CFR Part 11 and EU GMP Annex 11: electronic records, audit trail, access and master data management.
- 5
Operations & application management
IT qualification and operating processes: transport, authorization and configuration management, plus change and process management along defined interfaces between business and IT.
- 6
Periodic evaluation
The validated state is reconfirmed periodically so the system stays under control across its lifecycle.
At the customer's request, AI can support the project, for instance in drafting test cases and documentation. We can also lay the groundwork for it: a use case embedded in AI Governance, with human oversight of every decision.
Validation effort by type of adaptation.
ERP systems are highly configurable. Documentation and testing effort grows with the depth of adaptation, from the standard scope in use through configuration to WRICEF custom development.
| Adaptation type | Standard | Configuration | WRICEF custom development |
|---|---|---|---|
| What it is | standard scope of the ERP system in use | parameterized adaptation within the standard | company-specific extension (Workflow, Report, Interface, Conversion, Enhancement, Form) |
| Documentation effort | lowest effort | increased effort | highest effort |
| When to use it | use the standard where it meets the requirement | only where the standard falls short | only where necessary, and then documented and tested appropriately |
| Validation effort | follows GxP relevance and risk analysis | follows GxP relevance and risk analysis | follows functional complexity and identified risk |
Clean Core is, first of all, technology: extensions live on the SAP Business Technology Platform (BTP) instead of in the core. The evidence still follows the nature of the change, with extensions and integrations verified against their specification and namespaces keeping template and localization cleanly apart. The BTP itself is Platform as a Service and is treated like outsourced infrastructure: continuously monitored, with a monitoring plan established once. That plan changes with your own application, not with every platform update the provider ships. In our SAP projects, this platform control is an integral part of operational planning. How that holds up at enterprise scale is documented in our S/4HANA template case study.
What does the cloud change for the validated state?
Cloud operating models change the cadence in two ways: SAP Cloud ALM receives daily production updates, with no opt-out and no customer maintenance windows. The Private Edition, by contrast, keeps the familiar release mechanics, just in quicker succession. A one-off validation holds in neither case. The answer is the risk-based approach the FDA has formulated in Computer Software Assurance. GAMP 5 supplies the methodology for it, grounded in quality risk management per ICH Q9(R1). In our projects, we translate that approach to the release models of the SAP cloud.
Mainstream maintenance for both SAP ECC and Solution Manager 7.2 ends in 2027. The S/4HANA migration and the ALM tool change therefore coincide. If you introduce SAP Cloud ALM, plan the validation toolchain right along with it.
SAP compliance, supported end to end.
The real work sits between methodology and contract.
GAMP 5 (Second Edition) covers cloud infrastructure, external providers and shared responsibilities. Translating the methodology into the contractual and release reality of the SAP cloud is project work.
That is where we work: we extended SAP Activate in our own projects with the missing validation perspective, introduced S/4HANA as a private cloud platform at enterprise scale with clean namespace separation between template and localization, and connected validation tools to the SAP toolchain through the standard APIs. We know the methodology behind this from the inside, having served on the Core Team of the GAMP 5 Second Edition.
Frequently asked questions about SAP S/4HANA validation.
No. SAP runs the technical platform; GxP services such as Installation Qualification or Periodic Review are paid Optional Services. Functional testing and the acceptance of changes are contractual Excluded Tasks and, per SAP's own catalog, can only be performed by the customer. Validation against the intended use remains the operator's duty.
The GxP option is a separate subscription, and thus a building block, not the evidence. Its scope is set out in the non-public addendum to the customer contract and, according to SAP, includes services for qualification and conformity with 21 CFR Part 11 and EU GMP Annex 11. What it delivers must be precisely agreed in the contract and then assessed. It does not replace demonstrating fitness for purpose in your own process.
No, but every release is assessed. Change control and the regression strategy decide what needs retesting. The provider's evidence feeds into that assessment, with no need to repeat the testing. The measure remains risk-based: the effort stays no greater than the risk justifies.
Surprisingly little at first: what evidence is required is still determined by the nature of the change, whether it sits in the core or on the BTP. What is new is the view of the platform itself: the BTP is Platform as a Service and belongs in supplier oversight. SAP's BTP white paper, by its own stated purpose, supports the vendor assessment. SAP itself assigns it no greater role.
Last updated:
Plan migration and validation together.
Whether it is a RISE transition, an S/4HANA migration or the move to SAP Cloud ALM: in an initial consultation we establish where your project stands and how you produce the evidence, from migration through to live operations. Free of charge, about 30 minutes.
Arrange an initial consultation
