CSV per GAMP 5 (2nd edition): Less documentation, more data integrity

Computer system validation has a bad reputation: too often it stands for stacks of test scripts that nobody reads. The second edition of GAMP 5 clears this up and brings the actual purpose to the fore, namely robust data integrity at a proportionate level of effort. The framework is not new, but it is thought through more consistently.

Risk drives the effort

The core remains the risk-based approach. Three questions govern it: what does a failure mean for the patient, for product quality, for the integrity of the data? Where the answer is harmless, work stays lean. Where it is not, testing goes deep. The typical mistake in projects is not too little effort, but effort spread evenly.

Categorisation and supplier leverage

Assignment to the GAMP software categories determines the path: infrastructure (1), non-configured standard software (3), configured products (4) and bespoke development (5). The higher up the scale, the more can rest on the supplier's work, provided a qualified assessment supports it.

• Determine the category before testing, not afterwards.
• Assess and use supplier documentation instead of rebuilding it.
• Test what carries risk, not what is easy to test.

What the second edition genuinely changes

Three areas carry new weight. Iterative and agile development is treated as the normal case rather than an exception. Cloud and service models get their own space, including the question of what the provider delivers and what remains your own responsibility. And data integrity is no longer a chapter off to one side, but a design requirement. The FDA is pursuing the same direction with Computer Software Assurance.

Critical thinking instead of templates

The most important change is cultural. What is called for is engineers who think, not form-fillers. A test case that exists only because the template has a line for it costs time and proves nothing. Conversely, a brief, well-argued check is worth more than twenty pages of evidence about a non-critical function. What is required is the rationale, not the volume.

Less documentation, more data integrity: this is not a contradiction, but the goal.

The lifecycle begins after go-live

Validation does not end with PQ. Changes run through change control, periodic review checks whether the assumptions still hold, and backup together with restore must not be asserted but tested. The end belongs to it as well: when a system is replaced, it has to be clear how the data stays readable across the retention period. Replacements fail on that more often than on the migration itself.