Validate SAP S/4HANA - and keep it validated in operation.
ERP systems such as SAP S/4HANA carry the GxP core processes - manufacturing, release and distribution of medicinal products and medical devices - which makes them the most critical systems in the 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 transparency and support both strategy and implementation - risk-based, along the standard, with operations planned 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 - with one unambiguous default rule: 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 does not move into the contract.
| 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 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 in the own process |
Reading this dividing line as qualification below - the platform resting on qualified infrastructure - and verification and validation of the application above is our interpretation: consistent with GAMP, while the catalog itself never speaks of validation. The substance is unaffected either way. 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 picture through Fit-to-Standard workshops - what it lacks is the validation perspective. That is exactly why we extended the methodology in our own projects: 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 document, at the same time, what the system is needed for in the process. The intended use is captured where the decisions are made.
- 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 at disproportionate effort, are named and mitigated through the process.
- 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 including transport, authorization and configuration management; change and process management along defined interfaces between business and IT.
- 6
Periodic evaluation
The validated state is reconfirmed periodically - the system stays under control across its lifecycle.
At the customer's request, AI can support the project - 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.
Modern 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 - 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 nature of the change, and the evidence it requires, stay the same. Extensions and integrations are verified against their specification; namespaces keep template and localization cleanly apart. How that holds up at enterprise scale is documented in our S/4HANA template case study.
What does the cloud change about the validated state?
Cloud operating models run on a different clock - in two ways: SAP Cloud ALM is deployed to production daily, with no opt-out and no customer maintenance windows; the Private Edition, by contrast, keeps the familiar release mechanics, just at a denser cadence. A one-off validation holds in neither case. The answer is the risk-based approach that Computer Software Assurance and GAMP 5 lay out, grounded in quality risk management per ICH Q9(R1) - the effort stays no greater than the risk demands. In our projects, we translate that approach onto the release models of the SAP cloud.
Mainstream maintenance for SAP ECC and Solution Manager 7.2 both ends in 2027 - the S/4HANA migration and the ALM tool change 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 - RISE it does not name. 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. The methodological frame is the one we helped write: 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 the Periodic Review are paid Optional Services. Functional testing and the acceptance of changes are contractual Excluded Tasks - by SAP's own catalog, they can only be performed by the customer. Validation against the intended use remains the operator's duty.
It is a building block, not the evidence: a separate subscription whose scope sits in the non-public addendum to the customer contract - according to SAP, with services for qualification and conformity with 21 CFR Part 11 and EU GMP Annex 11. What it delivers needs to be agreed precisely in the contract and assessed; it does not replace demonstrating fitness in your own process.
No - but every release gets assessed. Change control and a risk-based regression strategy decide what needs retesting; the provider's evidence is drawn on rather than repeated. The yardstick is the one the CSA guide and GAMP 5 apply: the effort stays no greater than the risk demands.
First of all, only the technology: custom development lives on the BTP instead of in the core - the nature of the change and the evidence question stay the same. Extensions and integrations are verified against their specification, and namespaces keep template and localization apart. SAP's BTP white paper, by its own stated purpose, supports the vendor assessment - it is not validation evidence.
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 the evidence succeeds risk-based - operations included. Free of charge, about 30 minutes.
Arrange an initial consultation
