SAP validation has a reputation for being enormous, and the reputation is earned — but not for the reason most people assume. The volume does not come from SAP being hard to validate. It comes from teams validating all of SAP because nobody was willing to write down which parts of it are GxP-relevant.
An S/4HANA implementation touches finance, procurement, planning, warehouse and quality. A small fraction of that is GxP. Scoping that fraction honestly is the difference between a proportionate validation and a project that runs for a year and still cannot answer a simple question about batch genealogy.
This is the approach we take on SAP validation.
Scope by GxP impact, not by module
Module boundaries are an SAP concept, not a regulatory one. Scoping by module either pulls in vast amounts of financial functionality that has no GxP relevance, or excludes something material because it happens to live in a module labelled otherwise.
Scope by the decision instead. Which transactions can affect the identity, strength, quality or purity of product, or the records that demonstrate them. In most pharmaceutical implementations that resolves to a recognisable set: batch management and genealogy, quality management inspection lots and usage decisions, goods movements that change material status, shelf life and retest date handling, warehouse management where it controls segregation of quarantined stock, and the master data that governs all of it.
Everything else is business-critical and not GxP-critical. Those are different kinds of important, and conflating them is what makes SAP validation unmanageable.
Master data is the real risk
This is the finding we see most often and the one teams are least prepared for. In SAP the material master, the batch determination rules, the inspection plan and the shelf-life configuration do more to determine GxP outcomes than any transaction does. A wrong field on a material master produces consistently wrong behaviour across every batch, silently, until somebody notices.
So the controls worth testing hardest are the ones around master data change: who can change a GxP-relevant field, whether the change requires approval, whether the change is logged in a way a reviewer can interrogate, and whether change logging is actually switched on for that field. The last point is the trap — SAP change logging is configurable at field level, and a field whose logging was never enabled has no history at all, retrospectively.
Produce a list of GxP-relevant fields, confirm logging is enabled for each, and test that a change to one appears where a reviewer would look for it. That exercise finds more real problems than a month of transaction testing.
Authorisations, segregation of duties and why it fails
SAP authorisation design is genuinely complex, and GxP adds a requirement that the business case does not: segregation between the person who performs an action and the person who approves it, enforced by the system.
The usual failure is not a badly designed role. It is the accumulation of access over time, and the emergency access that was granted once and never withdrawn. A role design that was correct at go-live and has not been reviewed in two years is not a control any more.
Test the design, then test the reality. Can one user both create a batch and make its usage decision. Can one user release stock from quarantine and also change the inspection result that put it there. Then ask who currently holds those combinations in production, which is a different question from what the role design intended, and usually has a less comfortable answer.
Classification: standard, configured, or written for you
SAP is a configurable commercial product, which makes the core of it GAMP 5 category 4. The parts that matter for classification are the parts that are not standard: ABAP developments, user exits, BAdIs, custom reports, interfaces and workflow extensions. Those are category 5 and carry category 5 depth.
Most implementations have more of this than the project believes, because developments accumulate through hypercare and after. An inventory of custom objects touching GxP-relevant processes is a prerequisite for a defensible validation plan, and producing it is usually faster than arguing about scope without it. GAMP 5 Second Edition consulting is where we do this.
Where CSA changes the economics
SAP is the clearest case for the FDA's Computer Software Assurance guidance, finalised in September 2025 and reissued in February 2026. The guidance establishes that assurance effort should be proportionate to risk, and that unscripted testing and vendor evidence are legitimate assurance activities rather than concessions.
For SAP that means three things. Standard, unmodified SAP functionality that the vendor tests and documents is a candidate for a vendor-evidence path — you assess it and record the assessment rather than re-proving that standard goods movement posts correctly, which is what supplier qualification is for. Low-risk GxP-relevant functionality can be covered by unscripted testing with a record of what was examined and found. And scripted testing concentrates on custom developments, master data controls, authorisation enforcement and the interfaces.
This is where the test volume actually falls, and it falls a long way. The condition is that the reasoning is written down. A risk-based approach without documented reasoning is indistinguishable from an under-tested system, and an auditor is entitled to treat it as one. CSA services exists to make that reasoning the deliverable.
Interfaces, and the batch status problem
SAP rarely stands alone. It exchanges data with MES, LIMS, warehouse systems and sometimes directly with equipment. The GxP-relevant interfaces are the ones carrying batch status, quality results and material movements.
Test the failure modes rather than the transfers. A quality result arriving for a batch already released. A goods movement that posts in SAP and fails downstream, or the reverse. A batch status change that does not propagate, leaving two systems disagreeing about whether material is quarantined. That last one is the serious one: if SAP says released and the warehouse system says quarantined, the physical outcome depends on which screen somebody looked at.
Reconciliation is the control, and it needs to be a scheduled, evidenced activity rather than something discovered during investigation.
Keeping it valid through change
S/4HANA systems change continuously — transports weekly, upgrades on a regular cadence. A validation approach that treats go-live as the end produces documentation that is wrong within months.
What works is making impact assessment cheap enough that it stops being skipped. If assessing a transport means a person reading every approved document to work out what it touches, it will be skipped for anything that looks small, and the validation documentation will never be told. That is not negligence, it is effort, and the fix is to reduce the per-change cost rather than to write a sterner procedure.
Set the periodic review interval before go-live, schedule the first one, and keep the traceability between requirements, risk and evidence live rather than rebuilding it each time. A matrix maintained by hand reports whatever it was last told.
If you are inheriting an SAP estate
Three questions give you an honest read. Is there a current list of GxP-relevant custom objects. Is change logging enabled on every GxP-relevant master data field. And who, in production today, holds a combination of authorisations that breaks segregation of duties.
Those three cover most of what actually goes wrong, and none of them requires a full re-baseline to answer. SAP validation and audit readiness are the practices, and book a demo if you want a view on a specific implementation.
Where to go next
Explore GxP Copilot for AI-native validation, TraceDraft for source-traceable clinical documentation, or book a demo to see either on your own data.
