Here's the honest reason CSA adoption stalls: nobody is afraid of the guidance, they're afraid of the moment an inspector says "show me why you only tested this much".
It's worth facing that question directly, because it has a good answer — provided you built the record while you were deciding, not afterwards. These are the questions that come up and the evidence that settles them.
The questions
"Why did you test this function this way?"
The answer is your risk assessment, and it needs to be a sentence, not a score: what could go wrong, how bad would it be, and would anyone notice before it mattered. A rating of "low" with no reasoning behind it is the weakest thing in any CSA package.
"Who decided that, and were they qualified?"
Named roles — process owner, QA, and someone who understands the system technically. A risk assessment authored by one person alone is the most common structural weakness. See roles and responsibilities.
"Show me an unscripted test."
They will pick one. You need the charter written beforehand, the trail of what was done, the findings, and who accepted them — covered in unscripted testing under CSA.
"You relied on the vendor here. What did you check?"
Your supplier assessment, what specifically you leveraged, and the rationale for considering it sufficient. "They are a large vendor" is not a rationale.
"What did you test harder because of this approach?"
This is the question that separates real CSA from reduced effort — and the one teams least expect. If everything got lighter, the assessment did no work.
The evidence that answers them
- A risk assessment with written rationale per function, approved before testing.
- A validation plan that states which testing method applies to which risk level, and why.
- Traceability from requirement to the evidence that covers it — whatever form that evidence took.
- Supplier assessment records for anything leveraged.
- Test records that a stranger could follow, scripted or not.
- Deviations raised during testing, investigated properly rather than closed quietly.
Notice that none of this is unusual. It is the same package, with the risk reasoning promoted from an annex to the centre.
How to sound credible
Lead with patient impact, not efficiency. "We concentrated testing where an error could affect product quality" lands very differently from "CSA let us reduce documentation". Both may be true; only one is the reason.
Don't claim CSA is a regulatory requirement. It is FDA guidance describing an approach. Saying "the FDA told us to test less" invites a correction you do not want.
Have a failure ready. Show a case where the approach found something and you acted on it. Evidence that testing works beats any explanation of method.
Be straight about limits. If an area was leveraged from a vendor and you did not independently test it, say so and explain the basis. Inspectors respond far better to a clearly stated, justified decision than to a vague implication of coverage.
For the preparation routine, see preparing for a GxP audit. For the approach itself, moving from CSV to CSA and GxP software.
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.