Most teams agree with CSA in principle and then don't move. Not because the guidance is unclear, but because nobody wants to be the person who reduced testing the year before an inspection.
That's a fair worry, and it's also the reason the transition needs to be a plan rather than an announcement. Here is how we'd sequence it, what actually changes in your procedures, and how to bring QA along instead of arguing with them.
What CSA actually changes (and what it doesn't)
CSA doesn't lower the bar. It moves the effort. The old habit was to script and document every function to the same depth regardless of what the function did. CSA says: think first about what could go wrong and who it would hurt, then put your rigour there and use lighter methods everywhere else.
What doesn't change, and it's worth being blunt about this with anyone nervous:
- The system still has to be fit for its intended use, and you still have to show it.
- Part 11 and Annex 11 still apply in full — audit trails, access control, signatures.
- Change control, periodic review and training obligations are untouched.
- You still need traceability from requirement to evidence. See what actually changed with CSA.
What does change is the defence. Under old-style CSV the answer to "why did you test it that way?" was "because we test everything that way". Under CSA the answer is a documented risk decision — which is a stronger answer, but only if the decision is actually written down.
A sequence that works
1. Pick one system, not a policy
Do not start by rewriting your validation SOP. Start with one upcoming project — ideally a configured commercial product, medium risk, with a team that won't panic. Run it CSA-style alongside your existing procedure and keep both sets of evidence.
2. Write the risk thinking down first
Before any testing, record for each function: what happens if this is wrong, would anyone notice, and therefore how hard are we going to test it. That record is your CSA package. See GxP risk assessment.
3. Test high-risk functions harder than you used to
This is the part teams skip and it's the part that makes CSA credible. If you are testing low-risk functions less, you should be testing the dangerous ones more — challenge cases, negative cases, boundary conditions. A package that reduced effort everywhere is not CSA; it's just less work.
4. Compare the two packages honestly
At the end, put them side by side: hours spent, defects found, where each approach found them. This comparison is what convinces QA and management, and it is far more persuasive than any guidance document.
5. Then change the SOP
Only now. Update the validation procedure to describe the approach you have just proven, with the risk-assessment step as a gate. Retire the "test everything" language.
Bringing QA with you
QA scepticism is usually rational. They are the ones who face the inspector. Three things help more than argument.
- Put QA in the risk assessment, not just the approval. If they set the risk ratings with you, the testing that follows is their decision too.
- Show them the failure mode you are protecting against. CSA's real argument is that exhaustive scripted testing of trivial functions consumes the time that should have gone into the risky ones. That is a quality argument, not a cost one.
- Agree what "too little" looks like in advance. A written floor — always scripted for these categories — makes the rest easier to accept.
If the cost argument comes up, keep it secondary. Teams that sell CSA on savings end up with packages that look like savings. See risk-based testing under CSA.
What makes CSA look like cutting corners
- Risk ratings with no rationale. A score without a sentence is indefensible two years later.
- Everything rated medium. If nothing is high risk, nobody believes the assessment.
- Unscripted testing with no record. The method is legitimate; undocumented testing is not. See unscripted testing under CSA.
- Leveraging vendor evidence you never looked at. Leverage is allowed; blind reliance is not. See supplier qualification.
- Applying CSA retrospectively to justify a thin old package. CSA governs how you decide effort going forward, not how you re-explain the past.
When you are ready to defend the approach, defending CSA in an inspection covers the questions. The wider tooling picture is in GxP software, and CSA services if you want help running the first one.
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.