This is a ready-to-use handover record for the moment a validated computerized system moves from the project team to the people who will run it every day. Replace every <<FILL: ...>> placeholder with your own specifics, attach the actual documents each line references, and route the record through your normal review and approval. A worked filled specimen follows the template so you can see how a completed version reads. Verify each cited regulation against the current source before you rely on it. This content is educational reference to adapt to your own quality system, not legal or regulatory advice.
1. Purpose of this record
This record documents the formal transfer of a computerized system from the project team that specified, built, and qualified it to the operational team that will own, run, and maintain it. Handover is the moment accountability moves: before it, the project owns the system’s fitness for use; after it, the system owner and the quality unit do. An incomplete or informal handover is how systems enter operations with nobody clearly responsible for keeping them in a validated state, which is one of the more common roots of later data integrity and change control findings. This record exists so that moment has a date, a named owner on each side, and evidence rather than a verbal assurance that “operations has it now.”
2. Scope
This record applies to the single system named in the header at the point it transitions from project or validation ownership to operational ownership, whether that is at initial go-live, after a major upgrade that effectively re-platforms the system, or when operational ownership moves between functions or sites. It covers documentation transfer, configuration baseline transfer, known issues, credentials and environment access, training, operational procedure readiness, and support arrangements. It does not itself qualify the system; qualification is complete and approved before this record is opened. It does not replace the System Decommissioning and Retirement Plan used at the other end of the system’s life, or the SOP: Periodic Review of GxP Computerized Systems that governs the system once it is operating, both of which this handover feeds into.
3. Responsibilities
4. Section A: Validation documentation and configuration baseline
Where A4 lists an open item, it is carried forward into the system’s operational risk register, not left to live only in the validation file. State the register reference here: <<FILL: risk register reference>>.
5. Section B: Credentials, environments, and technical handover
A validated configuration transferred without working access to run it is not yet operational. This section is frequently skipped in practice and is worth its own check.
6. Section C: Operational readiness
7. Acceptance criteria and conditional go-live
A complete handover has every item in sections 4 through 6 marked Delivered and Confirmed, with no open item in section 4 left undisclosed to the incoming owner. That is the target for every handover.
Where a small number of non-critical items are not yet closed at the planned go-live date, and the system owner and QA agree the residual gap does not put GxP data or the validated state at risk, the handover may be conditionally accepted rather than delayed or accepted silently with the gap unrecorded. Conditional acceptance requires all of the following:
- Every open item is listed by number, with a named owner and a committed closure date no later than
<<FILL: e.g. 30 days>> after go-live.
- No open item touches section 4 (validation documentation, configuration baseline, known issues) or item C4 or C5 (periodic review entry, incident escalation path). These are never conditional; a system does not go live without them.
- QA has reviewed each open item individually and confirms in writing that the residual risk is acceptable for the interim period.
- The conditional acceptance is itself tracked to closure the same way a CAPA is tracked, and this record is not closed until every conditional item is closed and re-confirmed.
8. Sign-off
9. References
21 CFR 211.100 and 211.180 (production and control procedures; general records requirements), for the expectation that procedures and records governing a system are established and available before it is relied on.
EU GMP Annex 11, Computerised Systems, clause 4.3 (a current, accurate description of the system) and the periodic evaluation clause, which assumes an operational baseline exists to evaluate against.
ISPE GAMP 5, Second Edition (2022), which treats operation and maintenance as a distinct lifecycle phase with its own entry criteria, of which a documented handover is a practical expression.
ICH Q10, Pharmaceutical Quality System, for the general principle that knowledge generated during development and qualification is retained and transferred rather than lost at a project boundary.
Confirm the current version and clause numbers of each reference before issue.
10. Records generated
11. Revision history
Filled specimen
The following shows the record completed for an example environmental monitoring data system moving from project to operational ownership. The company, system, names, and numbers are illustrative; replace them with your own.
Conditional acceptance
QA reviewed the single open item (training for 2 of 6 users, both experienced analysts already trained on the predecessor system) and confirmed in writing that the residual risk for a seven-day gap was acceptable, since the two untrained users would not use the system unsupervised in that window. No open item touched sections 4, C4, or C5. The record was signed conditionally accepted on 2026-08-24 and closed on 2026-08-29 once training was confirmed complete.
Common inspection findings this record prevents
- A system goes live with no documented handover at all; when asked who owns it, the project team says operations and operations says the project team.
- The configuration baseline is referenced as “in the validation report somewhere” with no indexed, retrievable location, so the first change assessment cannot establish what was actually qualified.
- Known issues accepted during qualification are never carried into an operational risk register and resurface months later as an unexplained “new” defect that triggers a redundant investigation.
- Default administrator credentials from the vendor are still active in production because nobody explicitly confirmed they were rotated.
- The system is in daily GxP use before it appears on the periodic review schedule, so its first review is late by definition.
- A verbal “go-live is fine” stands in for a signed record, and six months later nobody can produce evidence that operational readiness was actually confirmed.
- A handover is treated as complete while training, access, or SOP gaps are quietly tolerated with no documented risk acceptance and no closure date.
How to adapt this record
- Set your record-numbering scheme, and confirm the validation summary report reference before opening the record.
- Tune sections 4 to 6 to the categories your organization’s SOPs already define, and point the SOP references in section 6 to your real, in-effect procedures rather than draft ones.
- Decide your own threshold for what may go through conditional acceptance under section 7, and keep the carve-outs (validation documentation, configuration baseline, periodic review entry, incident escalation) unless you have a documented reason to change them.
- Attach the actual evidence, not a description of it: the baseline document, the inventory entry screenshot, the training records.
- Confirm every regulation in section 9 against the current published version before issue.
