A recipe is modified after a development trial, but the report only retains the cycle name. The subsequent process finishes without alarms, and the batch is linked to a PDF that does not identify the version used. The machine may have correctly executed its logic, but the connection between approved parameters, actual configuration, and treated material is missing. It is this connection that automation must make verifiable.
1. Defining the boundaries of the computerized system
The system comprises more than just the PLC. Consider the HMI, independent recorder, historian, server, database, user management, time synchronization, backups, and interfaces with MES or quality systems. Identify where data originates, where it is transformed, and where it is stored. A flow diagram must also describe interrupted communications and temporarily autonomous operation.
Distinguish between process control and document management. A recipe approved in the quality system does not prove that the same parameters are active in the PLC. A correct record in the PLC does not prove that the export preserved all events. Interfaces are part of the intended use and must be included in the evaluation.
[REGULATORY REQUIREMENT] EU GMP Annex 11 requires a risk-based lifecycle approach for computerized systems used in GMP activities. The current text listed by EudraLex at the time of verification is the 2011 version; any proposed revisions should not be presented as requirements already in force.
2. Transforming process strategy into verifiable states
Describe the sequence as states and transitions: ready, load identified, conditioning, exposure, drying or cooling, completion, anomaly, and shutdown. For each transition, define necessary conditions, timeouts, recorded events, and output status. Behavior must be understandable even without reading the source code.
The transition to exposure must reflect the validated strategy. If it depends on multiple measurements, clarify how missing or invalid values are handled. The loss of a signal must not be accidentally interpreted as meeting the condition. The same principle applies to cycle end, discharge authorization, and transition to a more critical area.
[GEP] Use a cause-and-effect matrix for critical interlocks and alarms. Document the event, phase, action, safe state, and reset conditions. The matrix supports development, review, and testing, reducing discrepancies between the functional specification, the program, and the standard operating procedure.
3. Managing recipes and parameters as controlled configurations
Each recipe must have an identity, version, status, and scope of use. Separate development, test, and production recipes with rules that prevent the unintended use of unapproved configurations. Define which parameters are fixed, which are selectable, and which are modifiable within authorized limits.
The revision must compare previous and new content, the rationale, impact, and required approvals. The cycle record must identify the version actually executed and preserve the values necessary to reconstruct the sequence. Recording only the "component cycle" name does not allow for distinguishing between different configurations with the same label.
Consider the moment the recipe is loaded into the controller. If a change is approved while a cycle is already running, it must be clear which version governs that cycle. Tests must verify that updates or synchronizations do not silently change the parameters of an active sequence.
4. Designing access consistent with responsibilities
Define roles for the operator, supervisor, maintenance, administrator, and auditor. Assign the necessary privileges to activities and distinguish cycle execution from configuration changes. Evaluate the separation of duties for critical operations, taking into account the site structure and documented compensatory measures.
Accounts must allow actions to be attributed to authorized individuals. Shared credentials reduce this capability and require a concrete assessment of system limitations. Supplier service access must have a purpose, authorization, duration, and logging consistent with site procedures.
Test access creation, modification, deactivation, and expiration, in addition to ordinary login. Verify what happens to an open session when a role is revoked and how unused accounts are managed. Administrative functions must be included in the verification because they can modify the controls upon which trust in the data relies.
5. Making the audit trail useful for review
The audit trail must allow one to understand who performed an action, when, on which element, and with what result. For significant changes, retain previous and new values, and the justification when required. The tracking configuration must be protected and verified for functions that can influence the process or records.
Not all entries have the same meaning. A recipe change, an alarm disabling, a clock change, and a failed login attempt support different assessments. Define which events are reviewed per cycle, which periodically, and which require immediate intervention. The frequency must be justified by risk and usage.
An export function must maintain the order, identity, and context of entries. Verify filters, pagination, and time ranges to avoid an apparently complete printout omitting events. Also preserve the ability to retrieve original data: a screenshot is not a general substitute for the electronic record.
6. Linking alarms, aborts, and restarts
An abort interrupts or brings the sequence to a safe state according to a defined logic. A restart may involve resuming, a new sequence, or a prohibition on continuation, depending on the process. These behaviors must be established during development and validated; they cannot depend solely on the operator's preference at the time of failure.
Define which events render the cycle's performance undemonstrable, even if they do not cause mechanical damage. Loss of critical data, recipe error, or failure to verify a condition may require different management than a simple warning. The final message must correctly represent the status and not erase previous history.
Upon restart after power loss, the system must recognize the status of the interrupted cycle and make the stored information available. Tests must evaluate the different moments of the sequence. A successful PLC restart demonstrates technical availability, not the compliance of the load present during the interruption.
7. Defining the original record and copies
Establish which data constitute the record necessary for GMP decisions and where they reside. Include load identification, recipe version, actual values, events, metadata, and pertinent approvals. If the record is distributed, document connections and retention responsibilities.
A PDF can be a useful copy for review, but one must demonstrate that it retains the necessary information for the intended use. Dynamic data, audit trails, or non-exported details may require the availability of the original system or an adequate archive. The choice must be justified, not based solely on the ease of printing.
Verify the completeness and accuracy of transfers to the historian or MES. Consider duplicates, delays, out-of-order records, and temporary network loss. Reconciliation rules must make problems visible, preventing a report from being declared complete when part of the data is missing.
8. Essential test matrix
| Function | Scenario to verify | Expected evidence |
|---|---|---|
| Recipe | Change approved before and during a cycle | Applied version unambiguous and controlled |
| Access | User without privilege attempts a critical change | Action prevented and pertinent tracking |
| Alarm | Loss of a critical measurement during exposure | Response, outcome, and data consistent with specification |
| Communication | Interruption between PLC and recording system | Gap detected and reconciled recovery |
| Backup | Restore on authorized configuration | Readable, intact, and usable data |
| Clock | Authorized change or loss of synchronization | Reconstructible timeline |
The scenarios are an operational basis [GUIDEGXP RECOMMENDATION], not an exhaustive regulatory list. The plan must include system-specific risks and criteria defined before execution. A satisfactory test must demonstrate the required behavior, not just the absence of an error message.
9. Backup, recovery, and business continuity
The backup must include the data and configurations necessary for recovery. Identify recipes, programs, parameters, users, certificates, and relevant components according to the architecture. Protect copies and verify that the process works. The presence of a file in the destination folder does not prove that restoration is possible.
Restore tests must show that the recovered system is usable and that records remain complete and readable. Define test execution conditions to avoid effects on production. Document the version, environment, sample data, and result, with an assessment of the test limitations.
Business continuity must clarify what to do when the electronic system is unavailable. A temporary manual procedure is acceptable only if planned, adequate, and capable of preserving necessary controls. Do not introduce retrospective records lacking evidence to cover up data loss.
10. Example: complete report, incomplete data
In an illustrative case, the PDF reports the positive outcome of the PLC, while the historian lost the connection during a critical phase. The reconstruction shows that the controller possesses some local data, but the printing system does not signal the gap. The team suspends automatic acceptance and evaluates the availability of the original evidence.
The investigation distinguishes physical performance from record completeness and verifies whether local data allow for reliable reconstruction. The correction includes flagging incomplete transfers and a reconciliation procedure. Subsequent tests include connection loss, recovery, and prevention of duplicates.
The operational lesson is that the report format must not create an appearance of completeness superior to the data available. The final result must explicitly state the status of the record and any exceptions. The quality system decides on the material based on actual evidence, not the document's layout.
11. Validation and supplier management
Evaluate the supplier's competence, development processes, version management, and support. Manufacturer documentation and testing can contribute to verification if adequate and reviewed. The site's responsibility for GMP use is not transferred by purchasing a package labeled "validated."
[GUIDANCE] GAMP 5, second edition of 2022, offers a framework of good practices for computerized systems. It is not a law nor an automatic software certification. The level of evidence must be proportional to the risk, intended use, and knowledge of the system.
Link URS, specifications, risk assessment, tests, and deviations. Define release criteria and responsibilities for maintaining the validated state. A list of executed tests is not enough if it is unclear which requirements it covers and which risks remain open.
12. Changes, obsolescence, and periodic review
Software updates, patches, hardware replacements, migrations, and interface changes can influence control or data. The change control must evaluate the impact, necessary tests, recovery plan, and documentation update. The definition of "equivalent" must be supported by relevant characteristics, not just the commercial model.
The periodic review considers incidents, access, performance, backups, changes, documentation, and supportability. Also evaluate external dependencies and discontinued components. Plan for retrofit before an urgent replacement forces decisions without sufficient evidence.
The main red flags are uncontrolled shared accounts, unversioned recipes, non-reviewable audit trails, backups never restored, and reports that hide gaps. Good automation makes the relationship between approved configuration, user actions, executed process, and stored data visible.
13. Criteria for delivery to production
Before release, verify that the installed configuration matches the one tested and that production recipes are approved. Confirm the availability of procedures, user training, anomaly management, and administrative responsibilities. Open deviations must have a documented impact assessment and an authorized decision, preventing a list of residual activities from hiding unproven critical functions.
Deliver a recoverable baseline of software and configurations, with references to versions and tests. The site must know how to obtain assistance and which supplier interventions require prior authorization. Also establish how to verify the absence of unexpected changes after remote access or maintenance.
An effective handover includes an operational demonstration with users: load selection, startup, reading the record, managing an exception, and retrieving archived data. The ability to perform these activities confirms that the system is usable according to procedures. It does not replace validation but can highlight organizational gaps before productive use.
References and pathways
Sources verified on September 23, 2026: EU GMP Annex 11, current version listed, and Annex 15; ISPE GAMP 5, second edition 2022, official catalog. The matrices in this article are original and do not reproduce proprietary procedures.
Learn more about Sterilization & Depyrogenation Systems, cycle monitoring, sterilizer qualification, and Automation & Digital Systems.
