When Testing Isn't Validation: What an FDA Warning Letter Gets Right About Release Testing
A biologics manufacturer's warning letter contained a citation most life sciences professionals will recognize on sight, even if the specific language sounds unfamiliar: failure to validate a process where the results of processing cannot be fully verified by subsequent inspections and tests. That phrase, drawn from 21 CFR 1271.230(a), sets up a distinction worth sitting with, because it defines exactly when validation becomes non-negotiable rather than a documentation nicety.
The condition is doing the work here. Validation is required because subsequent inspections and tests cannot fully verify the result. When a process's output can be fully verified afterward, release testing can legitimately carry that weight. When it cannot, release testing alone was never going to be enough, no matter how thorough it is.
This particular finding involved a tissue-based product, an HCT/P (human cell and tissue-based product) manufacturing process that the FDA found had not been validated to ensure it prevents the introduction, transmission, or spread of communicable disease. The mechanism behind the finding is what gives the principle its teeth. The release test that would confirm a unit is free of infectious agents is destructive: run the test, and that unit is no longer available for sale. Testing every unit to achieve full verification would mean destroying every unit, leaving nothing left to sell. Full verification through release testing was never a real option for this product type.
The manufacturer's defense leaned on a specific figure: 100% of its product, they said, underwent microbiological contamination testing. Taken at face value, that claim sounds like exactly the kind of full verification the regulation treats as a legitimate alternative to validation. It is worth examining rather than accepting at face value, because the test involved is destructive. Testing every unit produced would mean destroying every unit produced, which is not a testing program any manufacturer can actually run and still have product to sell. Read against that constraint, "100% tested" more plausibly describes every batch undergoing release testing on a sample basis than every unit surviving a test built to consume it.
That distinction carries real weight. If the manufacturer genuinely had tested every unit, that would constitute verification, and full verification is a legitimate alternative to validation precisely because it confirms the result directly rather than through a validated process. The FDA's response, that this in-process testing does not replace the requirement to validate, only makes sense once the testing being described falls short of that standard. The FDA's rejection of the manufacturer's defense is itself telling: it points to release testing operating at the batch level, not the kind of exhaustive, unit-by-unit verification the manufacturer's language implied.
The assumption underneath this finding is a common one, and it is not limited to tissue-based products. A release-test result on a sample is only representative of the batch it came from when the process that produced that batch has already been proven capable. The manufacturer treated its release testing as though this were automatically true. The FDA drew the line explicitly: it is not automatic. It depends on validation having already established that the process reliably produces the result you are testing for.
Release testing confirms a batch. It does not prove a process. That distinction holds regardless of how destructive the test is, though destructive testing makes the stakes impossible to ignore. It applies just as directly to any process where the cost, time, or practical constraints of full verification make sampling the only realistic option, which describes far more of a typical life sciences operation than the tissue-based product example that generated this warning letter.
If your organization is currently relying on release testing to do work that only validation can do, that reliance is not always obvious from the inside. It tends to surface in exactly the way it did here: an inspector asks a question your process was never actually built to answer, and the answer you have is a testing program rather than a validated process behind it.
This is precisely the kind of gap our validation spot check is built to catch, and precisely the kind of judgment we build into organization-wide validation training. Not because release testing is unimportant. It is a necessary control. But it was never designed to carry the weight of proving a process capable, and treating it as though it can is a finding waiting to happen.
If your team is working through where release testing ends and validation begins, that is a familiar question, and exactly the kind of question we help organizations work through at Brayearst Validation Consulting.
