EEHA Data Handover: Why the Gap Between Construction and Operations Persists
Every industrial facility, whether oil and gas, mining, chemical or manufacturing, moves through the same broad lifecycle: Concept (Stage 1), FEED (Stage 2), Engineering (Stage 3), Construction (Stage 4), Commissioning (Stage 5), Operations (Stage 6), Decommissioning (Stage 7)*. Somewhere between Commissioning and Operations, a handover happens that gets far less attention than it deserves, and it’s the one that determines whether a client can actually meet its ongoing compliance obligations for Electrical Equipment in Hazardous Areas (EEHA).
The pattern is common enough that McKinsey has flagged it at an industry level, not just an EEHA-specific one: in many cases, capital project delivery still runs on a “siloed use of PDF-equivalent documents and myriad spreadsheets,” creating manual work and rework with no way to trace discrepancies back to their source. This isn’t a problem Inspectivity invented to sell software against. It’s the acknowledged state of capital-project data management, and EEHA compliance is one of the places it bites hardest.
The biggest issue isn’t that the EEHA data doesn’t exist – it’s that it exists in too many places, across different systems requiring input or handling across different stakeholders, with each managing it for their own immediate needs. In nearly 20 years working across EEHA projects globally, I’ve never seen the full dataset managed cleanly from start to finish and ultimately handed over to the client in a genuinely operations-ready format.
Stephen Vanderdeyl, Engineering Director, SKN
The lifecycle context
Concept and FEED set the design basis. The pointy end of the lifecycle follows: Engineering (Stage 3), Construction (Stage 4), Commissioning (Stage 5), and Operations (Stage 6). That’s where EEHA equipment is selected (by Engineering), installed and inspected (by Construction) and managed long-term (by the Operator), and it’s where this article focuses. On some projects, QA/QC or verification of EEHA data also occurs during Engineering and Construction, either by the EPC or by a 3rd party on the client’s behalf.
The stakeholder cliff-edge
In Stages 3 to 5, five parties can be in the room: the EPC, equipment vendors, 3rd Party QA/QC inspection providers, the client, and the regulator. The EPC runs the project. It completes the engineering, coordinates vendor inspections, manages site inspections, and owns the data those inspections generate.
The 3rd Party QA/QC verifications during engineering and construction are genuinely admin-intensive. This is where documentation is gathered and verified across multiple OEM sources rather than one, and where a further round of inspections gets recorded. It’s also where an extra layer of complexity can creep in: QA/QC inspection isn’t always contracted through the EPC. On some projects, the client contracts it directly to a specialist vendor of their own choosing. Another stakeholder and another data source outside the EPC’s system entirely – one more thing to reconcile at handover rather than one less.
Then Stage 6 begins, and the room empties. It’s just the client and the regulator now. The EPC that built the systems, ran the inspections, and held the data has moved on to its next project. This isn’t a gradual handover of responsibility; it’s a cliff-edge: full project-team support one day, none the next, while the client’s compliance obligations start immediately.
What actually gets collected
During Engineering, Construction and Commissioning, EEHA equipment is selected (Engineering), procured and installed (Construction) to satisfy hazardous area requirements. That process generates a genuinely large volume of data: equipment nameplate details, certification records, vendor factory acceptance testing, 3rd party QA/QC inspection results (where used), site inspection results, and condition information gathered as equipment is installed. This data is critical to supporting a safe, compliant start-up. It’s also, at this stage, sitting inside the EPC’s own systems, or a separately contracted QA/QC vendor’s, not the client’s.
The core problem
When the EPC hands over, that data doesn’t arrive as a structured, queryable dataset. It arrives as Excel spreadsheets, PDF inspection reports and PDF certificates, assembled the way the EPC’s own systems happened to produce them, not the way the client’s ongoing EEHA management process needs them.
The client now owns Stage 6 obligations, without a fully searchable digital record, to clearly demonstrate EEHA legal compliance to the regulator. In practice, this means scraping and reassembling data from disparate documents just to answer basic questions: what equipment is installed where, what condition it was in at handover, and what its certification status actually is. In many cases, the client can’t easily put their hands on the information they’re legally required to maintain.
EEHA legal compliance starts in the Engineering phase but must be consistently maintained throughout the Construction and Commissioning phases, using one system that aligns with what the Operator requires to safely operate and maintain the facility post-handover. Often the Operator doesn’t know what they don’t know and blindly accepts the EPC systems, which are designed to engineer and construct a facility, not operate it.
Adrian Carr, Principal Electrical Engineer
Why it happens
This isn’t EPC negligence. Two things compound to create the gap: a contracting gap, and a tooling gap.
A contracting gap
EPC contract scope typically stops at Commissioning, and rarely specifies that EEHA data be delivered as a structured, system-ready dataset rather than a document package. Nobody in the contract is accountable for handover in a format Stage 6 can actually use.
McKinsey’s framing of the broader problem points at the fix directly: capital projects need a “single source of truth (SSOT) for all stakeholders,” built through digital-native engineering rather than reassembled from documents after the fact, with better collaboration between engineers, subcontractors and operators as the payoff. EEHA data is a specific, high-stakes instance of exactly that gap.
A tooling gap
The contracting gap is compounded by a tooling one. During Engineering, Construction and Commissioning, EPCs typically run their program through a Completions Management System (CMS), sometimes called a Commissioning and Completions Management System (CCMS), a category of platform purpose-built to track, test and hand over assets through mechanical completion, pre-commissioning, commissioning and start-up. Tools in this category, such as Prometheus Group’s Co-Console, CxPlanner, WinPCS and Octave’s OnSite Completions, are genuinely good at what they’re built for: work packages, test sheets (MCC, FPT, SAT, SIT), certification tollgates, punchlists, and assembling the electronic handover package, to allow reporting on systems to demonstrate completions progress, not EEHA compliance.
What they’re not built for is EEHA. EEHA is a complex compliance standard with its own structured data model, zone classification, gas group, temperature class, IS barrier calculations, ongoing inspection cycles, and potentially Risk-Based Inspection (RBI). In a CMS/CCMS, EEHA equipment is typically tracked as one more line item in a construction checklist, not as a live compliance register (with an appropriate data model behind it). And because these platforms are oriented toward construction and commissioning close-out rather than a multi-year operations compliance cycle, whatever EEHA data they do hold is structurally difficult to hand over into whatever system the client runs in Stage 6.
Where 3rd party QA/QC and Ex inspections are used, they compound this further: additional documentation has to be gathered and verified across multiple OEM sources. That data has to be reconciled back into the completions platform, or it doesn’t make it into the handover package at all.
The result is that EPCs will select the right completions tool for their own requirements, i.e., finishing construction and commissioning on time and to specification, and, without anyone deciding it deliberately, the wrong tool for the client’s job: running EEHA compliance for the next twenty-plus years. That’s a second instance of the same root cause as the contracting gap: nobody in the contract is accountable for requiring a system that also serves Stage 6, not just Stages 4 and 5.
An industry-recognised problem
The industry has recognised the broader data-handover version of this at a standards level too. The Capital Facilities Information HandOver Specification (CFIHOS) exists precisely because information delivered by multiple EPCs, suppliers and contractors arrives in inconsistent naming conventions, structures and formats, requiring significant manual reconciliation before an owner-operator’s systems can use it. A formal industry standard doesn’t get built around a minor inconvenience.
The cost of the status quo
The status quo isn’t free. Research from FIATECH and the Construction Industry Institute, cited by Siemens Teamcenter, estimates owner-operators spend 2 to 4 per cent of total project cost manually correcting and re-keying operations and maintenance data at handover. On an AUD 300 million project, that’s AUD 6 to 12 million in hidden data entry and validation costs. The same research suggests a more automated, periodic handover approach could cut that cost by around 60 per cent.
Inspectivity sees the practitioner-level version of that statistic repeat at the start of nearly every EEHA compliance implementation. Before a digital, or even manual, EEHA system can run properly, the operator first has to set up and build a Hazardous Area Equipment Register from whatever the EPC handed over. In the majority of cases we see, that register starts life missing and unclean.
Typical gaps:
- Missing core fields – Serial Numbers, installed Zone classification data (gas group, temperature class, ingress protection, ambient temperature, IS Barrier information, location details, system rated current/group, date of manufacture), barrier calculation data such as IS cable loop length, and motor specifications such as power rating.
- Incorrect and inconsistent data – manufacturer names duplicated across multiple permutations of the same name, non-standard selections for various properties or blatantly incorrect information that has been missed because the CMS does not validate this information at the point of entry.
- Missing Last Inspection Dates – condition history that should anchor the compliance clock is frequently absent or needs to be pulled from thousands of individual PDF reports.
- Certificates and inspection records bundled, not linked – equipment certification documents and inspection records delivered as bulk PDFs, requiring manual linking back to each item of equipment. On its own, a major administrative burden.
The net result: when an operator’s EEHA system actually goes live in Operations, the first compliance cycle, typically four years, is spent re-gathering information that was already collected during Engineering, Construction and Commissioning but never handed over in a usable form. Every inspection in that first cycle takes longer as a result. That’s both expensive and less safe, with more time on-site per asset, at a time when qualified technicians are already scarce (see our analysis of the technician shortage and the compliance risk it creates when inspection backlogs build up).
A related, often underestimated cost sits in historic inspection records. Initial Detailed Inspection data frequently exists only on paper or as a flat PDF report, not as accessible digital data. Importing this history into a digital system afterwards is a costly exercise, and even where it’s done, the result is often little more than a digital wrapper around the same flat PDF, with photos missing entirely.
This gap matters beyond administrative convenience. Without a complete, clean initial inspection history, RBI isn’t possible; in our experience, regulators won’t approve an RBI approach without it. That locks clients into more frequent, more resource-intensive inspection cycles than necessary, indefinitely, purely because the historic data was never captured cleanly in the first place.
The fix
The fix isn’t a Stage 6 technology purchase made after the fact; it’s a contracting decision made earlier, and it has two parts. First, build EEHA management tooling into EPC contract scope from Stage 3 kickoff, so equipment and inspection data are captured into one system as it’s generated, not reconstructed from a document dump at the end. Second, don’t assume the EPC’s CMS/CCMS is that system (it typically isn’t built for it). A completions platform can stay the tool of record for construction and commissioning close-out while a purpose-built EEHA system runs alongside it for equipment and inspection compliance data; the two solve different problems and don’t need to be forced into one. Handover then becomes a transfer of a live, structured EEHA dataset rather than a translation exercise out of a completions checklist. Even simpler: handover a digital source of truth, which can be as simple as a software license transfer.
Every hour a technician spends re-establishing data that already existed is an hour not spent on compliance. That’s not just inefficient; with the industry already short on qualified electricians, it’s a safety cost operators can’t afford to keep paying.
Paul Eddison, Inspectivity Co-founder
How Inspectivity supports this
Inspectivity’s platform gives EEHA data a single home from the point it’s first captured, whether that’s a vendor inspection during Construction, a site inspection during Commissioning, or an ongoing compliance check once operations begin. Equipment records, certification data and inspection condition information stay structured and accessible throughout, rather than being locked inside EPC-specific systems and documents that need to be reverse-engineered at handover. Where a project brings Inspectivity in early, at Stage 3 rather than Stage 6, the handover becomes a system transfer, not a data recovery exercise.
Recommendations for teams starting this conversation
- Ask the EPC, before contract execution, how EEHA data will be structured and delivered at handover, not just what will be delivered. In fact, tell the EPC what you as the Operator require in the way of EEHA handover.
- Ask specifically which system will hold EEHA data between Stages 3 and 5. If the answer is “our CMS/CCMS” and nothing else, ask how that system’s data model handles the complexity of the EEHA Compliance Standard, and not just completion checklists.
- Ask who is responsible for delivery of the data, certificates, drawings, etc and whether these are readily available to all stakeholders throughout the project lifecycle.
- Clarify how 3rd Party QA/QC inspection data reaches the same system as everything else.
- Specify a system-ready data format in the contract scope, not a document package, for equipment and inspection records.
- Involve the Stage 6 compliance owner early enough to define what “usable” data looks like for their ongoing obligations.
- Treat the Stage 5 to Stage 6 handover as a named project milestone with its own acceptance criteria, not an administrative afterthought.
The gap between Stage 5 and Stage 6 is well understood by anyone who has lived through it from the client side. It’s solvable, but only if it’s addressed in the contract that governs Stages 3 to 5, not discovered as a problem once Stage 6 has already started.
*The stage numbering used throughout this article is arbitrary for easy identification of a phase of work and not related to an industry standard.

