GAMP 5 gets treated as a regulation. It is not. It is an ISPE guidance framework describing how to validate computerised systems in proportion to risk, and regulators expect a risk-based approach rather than a fixed set of forms.
For a bench-scale instrument, that is good news: the framework explicitly supports scaling validation down when the system is simple and the risk is low. The trap is copying a template written for a manufacturing execution system onto a device that has one screen and three buttons.
What GAMP 5 actually asks for
Five things, in plain language:
- A written requirement. What the system has to do, in your process. One page is enough for a small device.
- A risk assessment. What happens if it fails or is misused, and how much control is needed.
- Supplier assessment. Whether the vendor’s development and documentation practices are adequate for the risk.
- Testing proportional to risk. Installation and operation checks, plus performance checks where the process matters.
- Change control and periodic review. The system stays validated after a firmware update, a repair or a process change.
Nothing in that list requires a fifty-page document for a thawing instrument. It requires that the five things exist and that they connect to each other.
Which software category applies
GAMP 5 sorts software by how much of it is custom:
| Category | What it is | Typical lab example |
|---|---|---|
| 1 | Infrastructure (OS, network) | The PC that exports data |
| 3 | Standard product, configured | A thawing instrument with configurable protocols |
| 4 | Configured product with some custom code | An instrument with a site-specific integration |
| 5 | Custom application | Bespoke LIMS module |
A bench thawing instrument with firmware, configurable parameters and a data export is normally treated as category 3 — a standard product configured for use. That classification lowers the documentation burden considerably: you are not validating software you wrote, you are verifying that the standard product is configured and used as intended.
If the instrument is integrated into a LIMS with custom code, the integration moves up a category, not the instrument.
A risk assessment you can finish in an afternoon
Score the failure modes on two axes — likelihood and impact — and write the result in a table:
| Failure | Effect on product | Detection | Control |
|---|---|---|---|
| Thaw runs too long | Viability loss, batch rejection | Run record, residual-ice target | Stored protocol, operator training |
| Sample loaded too warm | Viability loss | Protection temperature alarm | Guard refuses run; alarm logged |
| Wrong protocol selected | Variable results | Protocol name in record | Named protocols, access tiers |
| Data lost or altered | Traceability gap | Export file, printout | SD record, non-editable curve image, printed report |
| Unauthorised parameter change | Undetected drift | Audit trail | Three access levels, password expiry |
That table is the core of the validation package. It identifies what has to be tested in OQ and what has to be controlled in use.
Supplier assessment without a questionnaire marathon
For a category 3 device the supplier questions are short:
- Is there a quality system, and is the product CE marked?
- Is the firmware version identifiable, and are release notes available?
- What records does the instrument produce, and can they be exported unedited?
- How are defects reported and fixed, and what happens to validation after a firmware change?
- Is there a documented manual that matches the shipped version?
Kemesser instruments are CE marked, carry a model and serial on the nameplate, and produce an SD record plus a printed report on the compliance-grade models. Those facts answer most of the list without a vendor audit.
What to test, given the risk
For a category 3 thawing instrument, a proportionate package is:
| Phase | Scope |
|---|---|
| IQ | Identity, location, power, firmware version, documents, configuration baseline |
| OQ | Each function and each refusal condition: channels, protection guard, residual-ice target, access tiers, alarms, record output, sanitising |
| PQ | Three consecutive runs with the real container and material, acceptance criteria written in advance |
The OQ is where most protocols are too thin: they test that the unit heats, not that it refuses a warm sample. The refusal conditions are the controls identified in the risk table, so they belong in the protocol.
The validation note goes through each test and the acceptance criteria.
Data integrity: what ALCOA+ means for a small device
The principles are the familiar ones — attributable, legible, contemporaneous, original, accurate — plus complete, consistent, enduring and available. For a thawing instrument the practical questions are:
- Attributable: does the record include the operator, not just the device?
- Contemporaneous: is the record written at the run, or reconstructed later?
- Original: is the exported curve uneditable, or a screenshot?
- Enduring: is the SD file archived, or does it live on the instrument until it is full?
The ten-field printed report and the non-editable curve export exist to answer those four questions. A notebook page does not.
Four over-documentation traps
- Copying a manufacturing template. A 60-page validation plan for a bench instrument produces a document nobody maintains.
- Skipping the risk assessment. Without it, every test looks equally important and the protocol grows.
- Validating the software, not the use. For category 3, the question is whether the configuration matches your process, not how the firmware was written.
- Forgetting change control. After a firmware update or repair, the previous validation may no longer describe the system.
Where the equipment fits
The practical difference between models is how much of the risk table the instrument itself controls. The ThawLINE Pro covers protocol storage, three access levels, a printed ten-field report and a non-editable SD export; the base ThawLINE keeps the dry thaw and the record but with two access levels; ThawHome units control the thaw but provide no account or record structure, which moves those controls into your SOP.
That is the decision GAMP 5 is really asking you to make: which controls live in the instrument and which live in the process.
If you are writing the validation package and want the instrument’s parameter set and record fields to check against, send us the model and process and we will return the specification extract. The CE documentation checklist covers the import-side paperwork that usually sits alongside it.
<!– Facts: GAMP 5 categories and ALCOA+ are standard framework content; ThawLINE Pro three tiers, ten-field report, non-editable SD export; ThawLINE two tiers; ThawHome no account or record structure; CE marking from English brochures and knowledge base entity pages (2026-10-22). –>
