CSV to CSA: the first 90 days, honestly scoped

Every CSA transition plan I have been handed fails the same way. It tries to move the whole estate at once, it starts by rewriting SOPs, and it treats the guidance as the hard part. Six months later the templates have new headers, the reviewers still ask for screenshots, and somebody senior is asking what the programme actually delivered.

Here is the version that works. It fits in one quarter, it touches three system categories rather than fifty, and it ends with evidence rather than a proposal.

Days 1 to 30: decide, do not draft

The first month produces almost no documents, and that is deliberate. It produces decisions.

Pick three system categories, not the estate. Choose ones where you have volume, because you need repetition to build a habit, and where the risk profile varies, because you need people to feel the difference between a function that can hurt product and one that cannot. Laboratory systems, a document management platform and a piece of manufacturing support usually give you that spread.

Write the function-level risk rules your reviewers will actually apply. This is the heart of it. Computer Software Assurance judges risk at the function level rather than the system level, which sounds like a small distinction until you try to apply it on a Tuesday afternoon with a package in front of you. Your rules have to answer, in plain language, what makes a function high impact, what evidence each level earns, and what a reviewer does when two people disagree.

Name the one person who settles disagreements. Unresolved disagreement is what stalls these programmes, not missing documentation. When two senior people hold different views on a borderline function and nobody can close it, the safe default returns, and the safe default is the old way. Give someone that authority in writing.

Days 31 to 60: move the habit, not the SOP

Your SOPs can say CSA and your organisation can still be doing CSV. The gap lives in the reviewer.

Think about what you are asking of that person. They have spent fifteen years being told that evidence means a picture of the screen, and that the auditor's favourite question is "show me". Now you want them to accept a documented rationale instead, and to sign their name to a lighter package. Nobody has told them what enough looks like, and nobody has said they will be supported when an inspector questions it. Of course they ask for everything.

So train quality, validation and IT in the same room, on your own systems. Re-tier real functions from your own inventory and argue about the borderline cases until the rules sharpen. Keep everything the room produces, because that output is your first set of worked examples and it is worth more than any template pack.

Then have reviewers practise. Give them three packages built the new way and let them review under supervision, with someone in the room who has defended these decisions to an inspector. The first time a reviewer accepts documented critical thinking instead of a screenshot, and nothing bad happens, your transition becomes real.

Days 61 to 90: prove it once

Run a single system end to end the new way. One system, all the way through, with the scope right-sized and the vendor evidence leveraged where the supplier has earned it.

Write the transition rationale into your Validation Master Plan while you do it. An inspector will ask why your approach changed, and the answer needs to live in a controlled document rather than in a slide deck or somebody's memory. One clear section covering what changed, why, and how existing systems transition is enough.

Then measure. Effort spent against a comparable package from last year, cycle time, review iterations. On common system categories the documentation reduction usually lands between 25 and 50%, but your number matters more than mine, because your number is what makes month four an easy conversation with your leadership.

What to do when a site refuses to move

One will. Usually the one with the most inspection history and the most to lose, and their reluctance is rational rather than obstructive.

Do not start with that site, and do not fight it. Run the first quarter somewhere more willing, then take the measured outcome to the reluctant site with its own numbers attached. Resistance built on inspection anxiety is not moved by policy; it moves when a peer site shows a lighter package that survived scrutiny. If the site still holds out after that, let it transition at its next revalidation cycle rather than forcing a date, and record that decision. A governed exception is defensible. An ungoverned one is a finding waiting to happen.

The trap

Rewriting every SOP before anyone has run a single system the new way. It feels like progress, it consumes the whole quarter, and it produces documentation describing a practice nobody has yet performed. Documentation follows the habit. In twenty years of this work I have never seen it succeed in the other order.

Where this sits in the bigger picture

Ninety days gets you a working method on three system categories and the internal proof to fund the rest. A full estate-wide operating model takes longer. On a comparable multi-site programme the CSA operating model went live in four months using the DRIVE discipline, and the first quarter alone returned a 23% reduction in validation effort with 36% faster system deployments.

If the same estate also has AI arriving in it, sequence CSA first. The risk-based habit you build here is exactly the habit AI validation depends on, and teams that try both at once tend to finish neither.

Questions teams ask