What a controlled handover must establish
Before responsibility transfers or start-up begins, the project and receiving authority should be able to answer a defined set of questions.
- Which system and boundary are being transferred?
- What milestone or operating state has been accepted?
- Who controls the system before and after handover?
- Which tests and acceptance criteria have been completed?
- What remains outstanding?
- Which limitations or temporary conditions remain active?
- Are operating procedures and emergency responses available?
- Are operators competent, briefed and authorised?
- Are utilities, consumables, spares and maintenance support available?
- Are alarms, trips, interlocks and protection in the required condition?
- Is the intended start-up sequence approved and understood?
- What conditions require the activity to stop or return to a safe state?
- Which records demonstrate the accepted configuration?
- What support remains available after transfer?
A handover is credible when the receiving team understands what it is accepting, what remains and how the system will be controlled after responsibility changes.
1. Define the handover milestone
Begin by defining the exact decision being made. Handover may refer to different stages and should not be treated as one universal event.
Examples may include:
- construction to commissioning;
- mechanical completion acceptance;
- release for pre-commissioning;
- commissioning to operations;
- temporary operational use;
- phased subsystem acceptance;
- start-up authorisation;
- performance-test release;
- warranty-period transfer;
- final project handover.
The milestone should identify:
- system and boundary;
- transferring authority;
- receiving authority;
- accepted condition;
- intended next activity;
- outstanding obligations;
- validity or review period.
The word “handover” is insufficient unless the responsibility, system state and evidence being transferred are defined.
2. Confirm the system boundary and configuration
The receiving team should be able to identify the physical and functional limits of the accepted system.
Confirm:
- system and subsystem boundaries;
- supplying and receiving systems;
- isolation points;
- control and communication interfaces;
- shared utilities;
- package boundaries;
- temporary supplies;
- equipment excluded from the transfer;
- connected systems not yet accepted;
- final operating configuration.
Use approved drawings, system definitions, marked-up diagrams or boundary registers where available.
3. Verify completion and commissioning evidence
The handover decision should be supported by accepted evidence rather than summary status alone.
Evidence may include:
- completion certificates;
- inspection and test records;
- commissioning procedures;
- commissioning results;
- functional-test records;
- performance-test results;
- vendor reports;
- alarm and trip tests;
- protection verification;
- software and configuration records;
- punch summaries;
- approved deviations;
- temporary-condition records;
- acceptance certificates.
Confirm that:
- the correct system is identified;
- records are current and accepted;
- superseded results are excluded;
- failed or incomplete tests remain visible;
- conditions attached to acceptance are recorded;
- database status agrees with the evidence and field condition.
A signed certificate should represent accepted technical evidence, not replace it.
4. Define the required operating state
The final system condition should be agreed before responsibility changes.
The accepted state may be:
- isolated;
- preserved;
- available for commissioning;
- available for controlled start-up;
- standby;
- operating;
- temporarily operational;
- available with restrictions;
- unavailable pending further work.
Record where applicable:
- operating mode;
- selector positions;
- valve and damper positions;
- energisation status;
- pressure or process condition;
- software and settings status;
- alarm and protection status;
- temporary configurations;
- preservation condition;
- connected-system status.
The receiving authority should not have to reconstruct the system state from informal notes or individual recollection.
5. Review punch items and outstanding work
Open work should be assessed according to its effect on start-up, operation, protection, access, maintainability and final acceptance.
Separate:
Blocking items
Conditions that prevent safe start-up, meaningful testing, required protection, controlled operation or acceptance by the receiving authority.
Controlled outstanding items
Conditions that may remain with documented ownership, limitation, monitoring, completion date and approval.
Close-out items
Work that does not affect safety, function, protection, access, maintainability or the accepted operating condition but still requires completion and evidence.
For every outstanding item, record:
- description;
- location or tag;
- technical consequence;
- owner;
- required completion date;
- temporary control;
- operating limitation;
- closure evidence;
- approving authority where required.
6. Control deviations and temporary conditions
Temporary supplies, jumpers, bypasses, overrides, simulated signals, provisional repairs and altered settings may affect the accepted system condition.
Every active temporary condition should identify:
- purpose;
- technical basis;
- owner;
- approval;
- physical identification;
- operating limitation;
- monitoring requirement;
- expiry or review date;
- removal or permanent-resolution action;
- restoration evidence.
The receiving team should understand:
- why the condition exists;
- how it affects operation;
- what must not be done;
- who may change it;
- when it must be removed;
- what evidence closes it.
Temporary conditions should become more visible at handover, not less visible.
7. Confirm procedures and operating information
Operations should receive controlled information that represents the installed and accepted system.
Relevant documents may include:
- operating procedures;
- start-up and shutdown procedures;
- emergency procedures;
- isolation instructions;
- maintenance procedures;
- inspection requirements;
- control narratives;
- cause-and-effect information;
- alarm and trip schedules;
- equipment manuals;
- lubrication requirements;
- preservation instructions;
- vendor recommendations;
- known limitations.
Confirm that:
- current revisions are available;
- procedures reflect approved changes;
- field configuration matches the documented basis;
- abnormal conditions are addressed;
- temporary conditions are identified;
- operators know where controlled copies are held.
A procedure that describes a superseded configuration cannot support safe transfer or operation.
8. Confirm personnel, competence and authority
The receiving organisation should have the people, competence and authority needed to control the system.
Review:
- operating personnel;
- control-room personnel;
- maintenance support;
- discipline specialists;
- commissioning support;
- vendor representatives;
- safety personnel;
- emergency-response support;
- accepting authority;
- escalation contacts.
Confirm where applicable:
- role;
- competence;
- authorisation;
- shift coverage;
- briefing status;
- access approval;
- communication arrangements;
- limitations on independent operation;
- required supervision;
- post-handover support period.
Do not treat attendance at a briefing as automatic proof of competence or operating authority.
9. Complete operator familiarisation and training
Training should be based on the real system, its operating modes, hazards, interfaces and limitations.
Familiarisation may include:
- system purpose and boundaries;
- equipment identification;
- normal operating sequence;
- control stations;
- alarms and indications;
- trips and protective functions;
- local and remote modes;
- abnormal conditions;
- emergency shutdown;
- isolation points;
- temporary conditions;
- maintenance access;
- vendor limitations;
- outstanding work;
- required records.
Training evidence may include:
- attendance;
- competence assessment;
- practical demonstration;
- simulator or tabletop exercise;
- vendor confirmation;
- controlled sign-off.
Operations should understand how the system behaves, not only where its controls are located.
10. Verify alarms, trips and protective functions
Start-up should not proceed unless the required alarm, trip, interlock and protection status is understood and controlled.
Confirm where applicable:
- alarm configuration;
- alarm priorities;
- trip settings;
- permissives;
- interlocks;
- inhibits;
- overrides;
- bypasses;
- emergency stops;
- shutdown interfaces;
- cause-and-effect response;
- communications;
- time synchronisation;
- event recording.
Any active inhibit, bypass, override or simulation should have:
- purpose;
- approval;
- owner;
- operating limitation;
- monitoring requirement;
- removal point;
- final restoration evidence.
11. Confirm utilities, consumables and supporting services
Start-up and early operation may depend on services outside the primary system boundary.
Review where applicable:
- permanent electrical supply;
- temporary electrical supply;
- control power;
- instrument air;
- service air;
- hydraulic power;
- cooling services;
- fuel;
- lubricants;
- chemicals or test media;
- ventilation;
- drainage;
- communications;
- lighting;
- waste handling;
- environmental controls.
For each dependency, confirm:
- required condition;
- owner;
- availability period;
- capacity or limitation;
- contingency;
- restoration or transfer responsibility.
A system is not ready for controlled operation when a required supporting service exists only as an expectation.
12. Confirm maintenance, spares and technical support
The receiving organisation should be able to support the system after responsibility transfers.
Review:
- preventive-maintenance requirements;
- initial maintenance intervals;
- lubrication schedules;
- preservation removal;
- specialist tools;
- calibrated instruments;
- critical spares;
- consumables;
- replacement filters, seals and gaskets;
- vendor support;
- warranty contacts;
- technical-query support;
- software backups;
- settings records;
- diagnostic information.
Identify any limitation that could prevent:
- continued safe operation;
- recovery from a fault;
- required maintenance;
- restoration after shutdown;
- protection of warranty conditions.
Operational handover should consider support for the first failure or maintenance need, not only the first successful start.
13. Prepare the start-up plan
The start-up plan should define how the system will move from its accepted starting condition into the intended operating state.
The plan should establish:
- scope and boundary;
- starting condition;
- sequence;
- responsible authority;
- communication method;
- required personnel;
- connected-system readiness;
- utilities;
- hold points;
- expected observations;
- acceptance criteria;
- abnormal-condition response;
- stop criteria;
- safe restoration method;
- final operating condition.
Where several systems start together, define:
- sequence owner;
- dependency order;
- communication protocol;
- interface confirmation;
- pause points;
- recovery responsibility.
Start-up should be treated as a controlled system transition, not as the final unchecked step after construction.
14. Define hold points and stop criteria
The team should know in advance which conditions require review, pause or termination of the activity.
Hold points may be required before:
- energisation;
- introduction of pressure;
- introduction of process material;
- automatic operation;
- connection to another system;
- removal of temporary controls;
- performance testing;
- transfer to unattended operation.
Stop criteria may include:
- unstable operation;
- unexpected alarm or trip;
- loss of communication;
- loss of required utility;
- protection unavailable;
- abnormal noise, vibration, leakage or temperature;
- boundary change;
- unsafe access;
- conflicting instruction;
- unplanned system response;
- unclear authority.
For each hold or stop condition, define:
- who makes the decision;
- how the system is made safe;
- who is notified;
- how evidence is preserved;
- what approval is required before resuming.
15. Conduct a start-up readiness review
The review should confirm that the approved starting condition, people, procedures, interfaces and controls are present immediately before the activity.
Review:
- accepted system boundary;
- completion status;
- punch status;
- procedure revision;
- permits and isolations;
- operating authority;
- personnel and vendors;
- utilities;
- controls and protection;
- connected systems;
- test equipment;
- temporary conditions;
- emergency arrangements;
- restoration plan;
- weather or environmental limitations;
- open actions.
The review outcome should be recorded as:
Ready
All mandatory conditions are met and the activity may proceed under the approved plan.
Ready with controlled conditions
The activity may proceed with explicitly approved limitations, monitoring, ownership and expiry conditions.
Not ready
One or more unresolved conditions prevent safe or meaningful execution or leave the system state uncontrolled.
Do not record a conditional approval when the unresolved condition is actually a blocker.
16. Execute start-up under controlled authority
During start-up, responsibility for changing the system state should remain clear.
Maintain:
- one identified controlling authority;
- agreed communication channels;
- step confirmation;
- hold-point release;
- operating-log entries;
- recorded observations;
- control of deviations;
- visibility of temporary configurations;
- stop-work authority;
- safe restoration capability.
Do not make several uncontrolled adjustments when the expected response is not achieved.
Where a result differs from the approved basis:
- Stop at a safe condition.
- Record the observation.
- Preserve available evidence.
- Confirm the system state.
- Obtain technical review.
- Approve any revised instruction.
- Brief affected personnel.
- Resume only when authorised.
The start-up record should show what changed, who authorised it and what system condition existed at each important decision point.
17. Confirm stable operation and acceptance
One successful start does not necessarily demonstrate stable or acceptable operation.
Verification may include:
- repeated start and stop cycles;
- operation at the required condition;
- automatic and manual modes;
- alarm and trip response;
- connected-system response;
- standby changeover;
- control stability;
- communications;
- leakage or integrity;
- observation over an appropriate period;
- expected operator intervention;
- final restoration or operating mode.
Record:
- operating condition;
- readings and observations;
- procedure and test references;
- temporary conditions;
- deviations;
- limitations;
- witnesses;
- acceptance decision;
- final configuration.
Acceptance should demonstrate repeatable intended function under the conditions that matter to operation.
18. Transfer control and post-handover support
After acceptance, communicate the exact point at which operating control and responsibility transfer.
Record:
- date and time;
- system and boundary;
- transferring authority;
- receiving authority;
- accepted operating state;
- outstanding work;
- temporary conditions;
- limitations;
- support contacts;
- warranty arrangements;
- action owners;
- required future reviews;
- document location;
- escalation route.
Post-handover support may include:
- commissioning attendance;
- vendor attendance;
- defect response;
- trend review;
- early-life inspection;
- operator coaching;
- punch closure;
- warranty coordination;
- technical-query resolution;
- performance follow-up.
Handover should not create a support gap at the moment the system first enters sustained operation.
Completion, readiness, start-up and handover are separate decisions
Systems completion establishes the accepted physical and documentary status of the system.
Commissioning readiness confirms that the system, procedures, people, utilities, interfaces and controls support a defined commissioning activity.
Start-up readiness confirms that the approved operating transition can proceed under controlled authority.
Operational handover transfers the accepted system state, evidence, limitations and responsibility to the receiving organisation.
These decisions may occur close together, but one should not be treated as automatic proof of another.
Clear gates prevent incomplete evidence or unresolved responsibility from being transferred into operation.
Worked example: handover of a standby auxiliary system
The following simplified example illustrates the handover and start-up preparation method without replacing project-specific procedures, technical limits or competent operating authority.
Accepted boundary
The subsystem includes the standby equipment, local and remote controls, associated utility connections, protection functions and the defined interface with the receiving system.
Completion status
Construction and commissioning records are accepted. The required functional sequence has been demonstrated through the approved procedure.
Outstanding items
Several minor identification and final-document formatting items remain. They do not affect operation, protection, isolation, maintenance access or the accepted system configuration.
Temporary condition
A temporary monitoring instrument remains installed for an agreed early-operation observation period. Its purpose, owner, operating limitation, removal date and restoration requirement are documented.
Operations preparation
Operators have completed system familiarisation, reviewed alarms and trips, confirmed the normal and emergency procedures and identified escalation contacts.
Start-up decision
Ready with controlled conditions.
Operating limitation
The system may enter standby service while the temporary monitoring arrangement remains under the approved control process.
Close-out
After the observation period, the temporary instrument is removed, the final configuration is verified and the handover record is updated.
The example shows how a system may transfer with a controlled temporary condition without concealing the remaining obligation or weakening operating authority.
Safe handover and start-up checklist
- Define the exact handover milestone.
- Identify the transferring and receiving authorities.
- Confirm system and subsystem boundaries.
- Record the accepted system configuration.
- Verify completion and commissioning evidence.
- Confirm the required operating state.
- Classify outstanding items by consequence.
- Assign owners and closure evidence.
- Record deviations and temporary conditions.
- Confirm current operating and emergency procedures.
- Verify personnel competence and authority.
- Complete operator familiarisation.
- Confirm alarms, trips, interlocks and protection.
- Confirm utilities and supporting services.
- Confirm maintenance requirements and specialist tools.
- Confirm critical spares and consumables.
- Establish vendor and technical support.
- Prepare the controlled start-up plan.
- Define hold points and stop criteria.
- Confirm connected-system readiness.
- Confirm permits, isolations and operating authority.
- Conduct the start-up readiness review.
- Record Ready, Ready with controlled conditions or Not ready.
- Execute under one controlling authority.
- Record deviations and system-state changes.
- Confirm stable and repeatable operation.
- Record the final configuration.
- Transfer control at a defined date and time.
- Communicate limitations and outstanding obligations.
- Maintain early-life and warranty support.
- Remove or formally transfer temporary conditions.
- Update the final handover record.
Minimum handover record
The record should allow another competent person to understand what was transferred, which evidence supported the decision and which obligations remained.
- project or asset;
- system and subsystem;
- boundary definition;
- handover milestone;
- handover date and time;
- transferring authority;
- receiving authority;
- accepted system state;
- completion certificates;
- commissioning results;
- punch summary;
- deviations and concessions;
- temporary conditions;
- software and configuration status;
- alarm and protection status;
- procedure revisions;
- utilities status;
- training and competence status;
- maintenance requirements;
- spares and support status;
- operating limitations;
- outstanding actions;
- owners and target dates;
- expiry or review requirements;
- warranty contacts;
- document location;
- final acceptance signatures.
Common handover and start-up failure patterns
Certificate-only handover
Responsibility transfers through a signed certificate without sufficient review of the field condition, supporting evidence or remaining limitations.
Unclear operating state
The receiving team is given the system without an agreed record of energisation, selector positions, protection status, temporary conditions or connected-system availability.
Late operations involvement
Operators first engage after testing is complete, leaving procedures, access, alarms, maintenance needs and practical limitations insufficiently reviewed.
Start-up without stop criteria
The sequence defines the intended actions but not the conditions requiring pause, technical review or safe restoration.
Invisible temporary conditions
Bypasses, temporary supplies, monitoring equipment or provisional repairs remain active without clear ownership, expiry or removal evidence.
Support gap after transfer
Commissioning and vendor support withdraw immediately after handover, leaving early operational faults, punch closure and warranty actions without effective ownership.
Transfer an understood and supportable system
Safe handover and start-up preparation connect technical completion with practical operating control.
When the boundary, configuration, evidence, procedures, people, protection, limitations and support arrangements are visible, the receiving organisation can make a reasoned acceptance decision and control the system after transfer.
When handover is treated only as a certificate or calendar milestone, unresolved uncertainty is passed into start-up and early operation.