Your First CSA Program: What to Build First

If you're starting from nothing, the order you build things in matters more than the templates you pick.

When a company decides it needs a computerized-system assurance program, often after an audit finding, a new system or a first inspection on the horizon, the instinct is to start with templates. Someone finds a validation plan, a test script format and a summary report from a previous employer, and the program is declared under way.

It feels like progress. It usually isn't. Templates encode decisions: how much testing a function needs, who approves what, what counts as evidence. If you adopt them before you've made those decisions, you inherit someone else's answers, and very often those answers are the heavy, script-everything habits that Computer Software Assurance (CSA) was meant to move away from.

Here is the order I recommend, and why.

1. Policy and governance

Start with a short validation (or assurance) policy that says what the program covers and how decisions get made. It doesn't need to be long. It does need to settle:

• Scope: which systems are in, which are out, and how that's decided.
• Accountability: who owns each system, who owns the process it supports, and what Quality approves versus what IT approves.
• Risk philosophy: a clear statement that assurance effort is proportional to risk to patient safety, product quality and data integrity.
• Regulatory basis: the regulations and guidance the program is built against, for example 21 CFR Part 11, EU GMP Annex 11, GAMP 5 (Second Edition) and FDA's Computer Software Assurance guidance.

A note on that last item. FDA's CSA guidance was finalized in September 2025 and updated in February 2026. It's formally written for medical device production and quality management system software. Pharmaceutical and biologics companies widely apply its risk-based principles as well, and GAMP 5 (Second Edition) supports the same thinking. Your policy should say which framework you're applying and on what basis.

2. System inventory and GxP impact assessment

You can't apply risk-based assurance to systems you haven't listed. Build an inventory of every computerized system that could touch regulated work. For each one, record:

• What it's used for: the intended use, in plain language.
• Whether it's GxP-relevant, and why or why not.
• Whether it creates, modifies or stores GxP records.
• The system owner and process owner.
• Its current state: validated, partially documented or not assessed.

Expect surprises. Spreadsheets, cloud tools bought on a credit card and, increasingly, AI assistants show up here. The inventory is also your first real view of the size of the work ahead.

3. A risk method

Next, decide how you'll assess risk, at the level of features and functions, not just whole systems. A LIMS isn't uniformly high-risk. The function that calculates a reportable result is, and the function that changes a screen color isn't.

Keep the method simple enough that people will actually use it. FDA's guidance separates functions into high process risk and not high process risk. Many companies add a middle tier. Whatever you choose, map each risk level to a default set of assurance activities, for example:

• High risk: scripted testing with predefined acceptance criteria, and independent review.
• Medium risk: unscripted or scenario-based testing with documented objectives and recorded results.
• Low risk: reliance on vendor evidence and configuration verification, with the rationale recorded.

This mapping is the core of your program. Everything downstream depends on it.

4. SOPs

Only now are you ready to write procedures, because only now do you know what they need to say. A typical starter set includes:

• Computerized system lifecycle and assurance (the master procedure)
• Risk assessment
• Supplier and vendor assessment
• Testing and objective evidence, including unscripted testing
• Change control and configuration management
• Periodic review
• Incident and deviation handling for computerized systems
• Data integrity and audit trail review
• System retirement and data migration

If your organization uses or plans to use AI tools in regulated work, plan for an AI-specific procedure too, or at least a section of the master SOP. Retrofitting one later is harder.

Write SOPs to describe decisions and responsibilities, not to prescribe every keystroke. An SOP that hard-codes a particular test format will drag you back toward over-documentation.

5. Templates, last

With policy, risk method and SOPs in place, templates become simple. They're just the forms that capture decisions your procedures already describe. A good template set for a CSA program is short: an assurance plan, a risk assessment, a test record that supports both scripted and unscripted testing, and an assurance summary report.

If a template field doesn't map to a decision in your procedures, delete it.

6. Pilot, then roll out

Before rolling the program out across the inventory, run it on one or two real systems: ideally one moderately complex system and one simple one. You'll find gaps in your risk method, steps in your SOPs nobody can follow, and template fields nobody fills in. Fix them, then train people and roll out.

Training matters more in a CSA program than in a traditional CSV program. Teams used to scripting every step need permission, and practice, to apply judgment. Use examples from your own pilot.

Common mistakes

• Copying templates from a previous company. You import their risk tolerance along with their formatting.
• Treating CSA as "less testing." It means testing where it matters. High-risk functions may get more rigorous assurance than before.
• Skipping the inventory. Without one, you can't show an inspector that your program covers what it should.
• Leaving Quality out of the risk method. IT can build the method, but Quality has to own the risk decisions.
• Ignoring periodic review. A system that was assured once and never looked at again won't stay in a controlled state.

The short version

Policy, inventory, risk method, SOPs, templates, pilot. Each step answers questions the next one depends on. Build in that order and your templates will reflect your own decisions instead of someone else's.