Why the Handover Matters as Much as the Content
There is a specific moment in every pharma automation project when the SI's relationship with the validation package changes fundamentally: the moment it is handed over to the client. Before handover, the documents are the SI's working materials — they can be revised, updated, and improved. After handover, they are the client's GMP controlled records. The handover is not just a file transfer; it is a formal transfer of custody over controlled documents that will live in the client's quality management system for the retention period required by regulation.
A QA manager receiving a validation package for a system that will now be under their site's quality system has a legitimate expectation that the package arrives in a controlled, complete, and navigable state. If they receive a ZIP file named "FINAL_docs_v3_ACTUAL_FINAL.zip" containing a mix of approved, draft, and superseded documents with inconsistent naming conventions, their first action will be to send it back — and their second will be to question whether the project was managed to the same standard as the documents suggest.
The validation package handover is one of the clearest signals a client receives about the SI's quality culture. An SI who hands over a well-structured, complete, clearly named package with a transmittal record demonstrates that they manage documentation with the same rigour as they manage engineering. This impression outlasts the project — it is what gets you recalled for the next one.
What Goes Into the Handover Package
The handover package is not the same as the validation package. The validation package is everything produced during the project. The handover package is the defined, version-controlled, approved subset that transfers to the client as GMP records. Understanding the distinction matters because the handover package must not contain draft documents, superseded revisions, working files, or internal SI communications. It contains only approved final documents.
A complete handover package for a typical PLC/SCADA pharma project contains the following categories:
File Naming and Folder Structure
File naming is the single easiest aspect of a documentation handover to get right, and the one most commonly handled carelessly. The correct approach is the one that allows any document to be located within ten seconds, by someone who has never seen the package before, using only the document number or document type.
The naming convention for controlled documents in the handover package should follow the pattern: [Document Number]_[Document Type]_[Revision] — for example, VP-SYS-001_Validation_Plan_RevA.docx. For executed protocols that have physical signatures: IQ-SYS-001_Installation_Qualification_Executed_RevA.pdf. The PDF format for executed and approved documents prevents accidental editing after signature — never hand over wet-signed protocols in editable Word format.
The folder structure should mirror the project lifecycle phases: a Planning folder, a Design folder, a Testing folder, and a Closeout folder. Calibration certificates and as-built drawings can sit within the Testing folder or in a Supporting Evidence subfolder. The critical rule is that there is only one version of each document in the package — the approved final version. If a client opens the package and finds both VP-SYS-001_RevA and VP-SYS-001_RevB, they have a document control problem to resolve before they can accept the package.
The Transmittal Record
The transmittal record is the document that formally lists every item in the handover package, with its document number, title, revision, and status. It is signed by the SI and acknowledged by the client. Its purpose is to create a formal, dated record of exactly what was handed over and when — which protects both parties.
From the SI's perspective, the transmittal record documents that a complete, approved package was delivered. If a client later claims a document was missing or that an earlier revision was provided, the signed transmittal record is the evidence that the correct package was delivered on the stated date. From the client's perspective, it is the formal acceptance record that triggers the transition of document ownership to their quality system.
Without a transmittal record, documentation disputes are resolved by email chains, memory, and shared drive timestamps — none of which constitute controlled evidence. An SI who delivers documentation without a transmittal record has no formal evidence of what was delivered, when, or in what state. A one-page transmittal list, signed by both parties, eliminates this risk entirely at negligible cost.
Format Requirements for Executed Protocols
Executed protocols — FAT, SAT, IQ, OQ, PQ — occupy a special category in the handover package. They are not just approved documents; they are witnessed records of physical testing. The handover format for executed protocols has specific requirements that differ from planning and design documents.
The preferred format for executed protocols in the handover package is scanned PDF of the wet-signed original. All handwritten entries, initials, signatures, and deviation references must be legible in the scan. A 300 DPI scan minimum is required for text to remain readable when a reviewer prints the document. If the executed protocol contains attached evidence — photographs, printouts, oscilloscope traces, historian data exports — these should be included as appendices within the same PDF, not as separate files that can become separated from the protocol they evidence.
If the client uses an electronic quality management system that requires document import, confirm the required format before finalising the package. Some EQMS platforms require specific PDF/A archival format. Delivering standard PDF when PDF/A is required means the client's document control team must convert every file before import — a friction point that reflects poorly on the handover.
What Happens After Handover — Your Retained Copy
After the validation package transfers to the client's quality system, the SI should maintain their own retained copy of everything in the handover package. This is not a quality requirement — it is a commercial and legal protection. The retained copy is what you refer to if a dispute arises about what was delivered, what the system was designed to do, or what test evidence exists for a specific requirement.
The retained copy should be stored in the SI's document management system under the project reference, with access restricted to appropriate personnel. It should not be modified after handover — it represents the exact state of the package at the point of transfer. Any subsequent changes to documents (following a post-handover change control, for example) should be stored as separate revision records alongside the original, not as overwrites.
The SI's obligation to the handover package does not end at delivery. If the client identifies a documentation error after handover — a wrong revision referenced in the traceability matrix, a calibration certificate filed against the wrong tag number — the professional response is to raise a change control, correct the document, and issue a revised handover transmittal for the corrected document. What is not acceptable is to email a corrected file without formal documentation of what changed and why.
The Validation Summary Report (VSR-SYS-001) serves as the primary closeout document that lists all validation activities completed, all deviations closed, and the system's declared validated state — it is the anchor document of the handover package. The framework's document numbering system (VP-SYS-001 through PRR-SYS-001) provides the consistent naming convention that makes a handover package immediately navigable. The 29 controlled documents in the framework are structured to be handed over as a coherent package — not assembled from miscellaneous outputs at project end.