Computer System Validation & Software Assurance
Validating a system takes months, costs more than the system, and produces a binder nobody opens until an inspector asks for it. So changes get avoided, and the systems stay old — which is its own risk.
You already know CSA exists. The problem isn't the guidance.
Scope
- eQMS
- Document management
- ERP
- Clinical systems
The real reason CSA adoption stalls
Why haven't we moved from CSV to CSA?
Nobody has ever been written up for over-documenting.
Why it stalls
Moving to a risk-based approach means somebody signs the decision that less documentation is defensible for a given system. That person is the one standing in front of an inspector eighteen months later, explaining why a function was tested with a scenario rather than a scripted protocol. Meanwhile the SOP still says CSV, and rewriting the SOP requires the same signature.
So the guidance moved and practice didn't. Most quality organisations are still applying full CSV to a SaaS document management system, because that's what the SOP says and nobody wants to be the person who changed it.
What unblocks it
The thing that unblocks it isn't courage. It's a documented rationale that holds up. A risk assessment an inspector can follow, tied to intended use and process risk, with the assurance activity proportionate to what was assessed. Once that exists and is defensible, signing it is a normal decision rather than a career one.
That's what we build.
What CSA actually changed
What is Computer Software Assurance and how is it different from CSV?
FDA finalised Computer Software Assurance guidance in September 2025, and issued an updated version in February 2026 aligned to the Quality Management System Regulation, which took effect on 2 February 2026 and brings ISO 13485:2016 into 21 CFR 820 by reference.
The shift is from uniform documentation to proportionate assurance. Effort follows intended use and process risk. High process risk gets scripted or hybrid testing. Risks that aren't high can be covered with leaner methods — including exploratory and scenario testing. Vendor test evidence becomes usable for lower-risk functions rather than something you repeat yourself.
What CSA is not.
It is not permission to test less. High-risk production software receives more scrutiny under CSA, not less — the change is where the effort goes, not how much there is. Anyone selling CSA as a cost reduction has misread it, and your inspector has not.
What hasn't changed.
Part 11 controls stand exactly where they were: audit trails, electronic signatures, access controls, data integrity. CSA changes the assurance approach around them, not the controls themselves.
Where AI enters, and why it matters now
The February 2026 guidance explicitly brings automation tools, data analytics, and AI/ML systems into CSA scope where they're used for production or quality purposes.
That creates an obligation most validation programmes have no method for. An AI tool used in a quality process is non-deterministic, updates without your involvement if it's SaaS, and doesn't produce the same output twice — which is awkward for an approach built on scripted expected results.
We work on both sides of that. We assure AI systems entering your quality processes, and we use AI in the assurance work itself — requirement analysis, risk assessment support, and test generation — under the same rationale we'd defend to an inspector.
If you're adopting AI in a GxP context and your validation approach hasn't been asked to handle it yet, it will be.
What we do
- Risk assessment and rationale.Intended use, process risk, and the assurance activity that follows from it — documented so the decision is defensible rather than personal.
- Proportionate assurance.Scripted testing where process risk warrants it. Scenario and exploratory testing where it doesn't, with the reasoning recorded.
- Part 11 controls verification.Audit trail integrity, electronic signature binding, access control, and ALCOA+ data integrity across the record lifecycle.
- Vendor evidence assessment.Deciding what supplier documentation you can rely on, and what you genuinely need to re-test. This is where most of the wasted effort in traditional CSV sits.
- SOP alignment.A CSA-based approach that contradicts your validation SOP helps nobody. We work on the procedure alongside the practice.
- Maintaining the validated state.Assurance is a lifecycle, not an event. Change assessment that doesn't restart the whole exercise every release.
Systems we validate — and don't
We do
- eQMS and electronic document management
- ERP in GxP scope
- Clinical systems (CTMS, EDC, eTMF)
We don't
- LIMS
- Manufacturing execution and production floor systems
- Software that is itself a medical device
That second list is deliberate. Shop-floor and laboratory systems need specialists with that domain, and SaMD follows a different regulatory route entirely — CSA explicitly excludes it.
One point of precision on clinical systems.CSA is scoped to production and quality system software. CTMS, EDC and eTMF sit under GCP and Part 11 rather than inside CSA's formal scope. The risk-based reasoning transfers cleanly and we apply it — but we won't tell you the guidance covers them when it doesn't.
Where our experience comes from
Our validation work has been on quality and business systems in GxP scope — eQMS and document management, ERP, and clinical systems — under 21 CFR Part 11 and GAMP 5 categorisation.
Delivered by this team
- 12months· 9 QA engineers · USCustomer engagement platform — compliance, security and functional testing
- 12months· 5 QA engineers · USHealthcare AI analytics framework — data quality across the processing pipeline
- 4months· 3 QA engineers · USSample management platform — formal IQ/OQ, API and data quality testing
Three pharma and life-science engagements, delivered by this team. Ask on the first call about who would do the work and what they have done before, and we will give you a straight answer.
The business case
For the budget conversation.
Cost of staying with full CSV
- EffortUniform documentation applied to systems that don't warrant it
- Change avoidanceRevalidation cost makes teams avoid upgrades, so systems age past support
- Digital initiativesCloud, SaaS and AI adoption stalls behind a validation approach that can't keep pace
- Inspection readinessVolume of documentation is not the same as quality of evidence, and inspectors know the difference
The saving isn't in doing less work. It's in stopping the work that was never proportionate to the risk, and putting that effort where an inspector would actually look.
Where we're not the right fit
Manufacturing execution and LIMS. Not our systems.
SaMD and medical device software. Different regulatory route, needs a device specialist.
Anyone wanting CSA framed as a documentation reduction exercise. That's a misreading, and we'd rather lose the work than write a rationale we couldn't defend.