What is an Exchange Information Requirement (EIR)
A client-side guide to the document that drives what the supply chain must deliver
Overview
The Exchange Information Requirements (EIR) is the document through which an appointing party ,the organisation commissioning a project specifies what information the supply chain must deliver, in what format, to what standard, and at what point during the project.
Under BS EN ISO 19650, the EIR is included in procurement documentation and forms part of the contract, making the information it specifies a defined, mandated deliverable rather than an informal expectation.
The EIR is the primary mechanism through which an estates-owning organisation translates its internal information needs as defined in the Organisational Information Requirements (OIR) and Asset Information Requirements (AIR) into a contractual obligation on the supply chain.
Without it, contractors will produce information to their own standards, which typically serve design and construction rather than the operational needs of estates and FM teams.
What is in an Exchange Information Requirement?
The EIR is a client-produced document the appointing party's responsibility, not the contractor's. It defines the information requirements for a specific project appointment, setting out what the lead appointed party must produce and deliver in order to meet the client's needs.
Under BS EN ISO 19650-2, the EIR is issued as part of the tender documentation, so bidders can plan for information delivery from the outset and price for it accordingly.
A key principle of the standard is that the EIR should be lean requesting the minimum information necessary to meet each relevant obligation. Anything above this minimum is, in the standard's own terms, waste.
This has important practical implications for clients: a well-constructed EIR is not the longest possible specification of every data point the organisation could conceivably want. It is a focused, purposeful document that requests only what the organisation will genuinely use.
In plain english
The EIR is the client's order to the supply chain: this is the information we need, in this format, by these dates.
It is the project-level expression of the organisation's broader information requirements derived from the OIR and AIR, not invented from scratch on each project.
It should be lean: requesting only what is genuinely needed, because anything beyond the minimum is a cost and a burden on the supply chain, which ultimately comes back to the client.
Where the EIR sits in the hierarchy
The EIR is the project-level document in BS EN ISO 19650's hierarchy of information requirements. It sits below the OIR and AIR, which define the organisation's strategic and operational needs, and above the BIM Execution Plan (BEP), which is the supply chain's response to it.
In practice, many organisations produce an EIR without a documented OIR or AIR behind it.
The result is an EIR that is either too vague to drive useful information from the supply chain, or too generic copied from a previous project or a template to reflect the organisation's actual operational needs.
An EIR grounded in a proper OIR and AIR is qualitatively different: it requests the right information, in the right format, because those decisions have been made deliberately rather than by default.
What must an EIR contain under BS EN ISO 19650?
BS EN ISO 19650-2 sets out three categories of content that the EIR must address: management information, commercial information, and technical information. Together, these cover every aspect of how information will be produced, exchanged and accepted on the project.
Management information
This section addresses the processes and governance arrangements that will govern information management on the project. It should include:
• Standards — which information standards will apply, including classification systems (typically Uniclass in the UK) and naming conventions
• Roles and responsibilities — who within the appointing party's organisation is responsible for reviewing and accepting information, and how the lead appointed party should structure their information management team
• Planning and management of information — the approach to information delivery, including the requirement for a Master Information Delivery Plan (MIDP) and Task Information Delivery Plans (TIDPs)
• Collaboration — how parties will work together, share information and coordinate across disciplines during delivery
• Health, safety and security — any specific requirements relating to sensitive information, particularly relevant on government, healthcare and higher-risk building projects
Commercial information
This section defines the deliverables the supply chain is contractually required to produce and the schedule by which they must be delivered. It should include:
• Information deliverables — a clear schedule of what must be produced at each project stage, including models, asset registers, drawings, O&M documentation and commissioning records
• Information exchanges — the defined points in the project programme at which information must be shared with the appointing party for review and acceptance
• Client acceptance criteria — the standards against which delivered information will be checked and the process by which it will be formally accepted or rejected
• Competence assessment — what the appointing party expects from bidders in terms of information management capability, as assessed at tender stage through the pre-appointment BEP
Technical information
This section covers the specific technical requirements that govern how information is produced and structured. It should include:
• Level of information need — the detail required for different asset types at each project stage, defined in a way that is directly usable by the supply chain
• Common Data Environment — the platform to be used, the folder structure, access arrangements for the appointing party, and the workflow that governs how information moves through shared, published and archived states
• Coordination and clash detection — requirements for model federation, clash avoidance and design coordination
• Software and file formats — what software is acceptable for information production, and in what formats information must be exchanged and delivered at handover
• Asset data requirements — the specific data attributes, classification and format requirements for the asset register, typically cross-referenced to the AIR and specifying the exact import format for the client's CAFM system
The asset data section is where most EIRs are weakest
• Management and technical requirements around models and drawings are well understood by most contractors.
• Asset data requirements — the structured information that estates teams actually need to operate the building are consistently the least developed section of EIRs produced without a documented AIR behind them.
• A weak asset data section in the EIR almost always produces poor asset information at handover. The fix is to develop the AIR first, then derive the asset data section of the EIR from it directly.
The EIR in the BS EN ISO 19650-2 appointment process
The standard sets out a clear sequence of activities in which the EIR sits at the beginning of
the process:
Assess organisational need: the appointing party reviews the OIR, AIR and existing information to establish what is needed for the project.
Produce the EIR: the appointing party develops the EIR for inclusion in tender documentation.
Invite to tender: the EIR is issued to bidders as part of the procurement package. Bidders respond with a pre-appointment BEP.
Assess the pre-appointment BEP: the appointing party reviews bidders' responses to the EIR as part of the tender evaluation.
Appoint: the successful bidder's pre-appointment BEP is agreed and incorporated into the appointment.
Mobilise: the lead appointed party develops the post-appointment BEP in response to the agreed EIR.
Deliver: information is produced and exchanged in accordance with both the EIR and the post-appointment BEP.
Common mistakes with the EIR
1. Producing it without a documented AIR
The most consequential mistake. Without an AIR behind it, the asset data section of the EIR defaults to whatever the person writing it thinks is reasonable which is rarely grounded in how the FM team actually uses the data or how the CAFM system is structured. The EIR then cannot produce consistently usable information because the requirements were never derived from actual operational need.
2. Copying a previous project's EIR without adapting it
Template EIRs and previous project documents are useful starting points, but they must be tailored. A previous project's EIR may reference a different CAFM system, a different classification structure, or information exchange points that do not match the current project's programme. Generic requirements produce generic and often unusable information.
3. Requesting more than is genuinely needed
BS EN ISO 19650 explicitly frames the EIR as a lean document. Requesting information the organisation will never use is not harmless it increases the contractor's cost, dilutes focus on what actually matters, and produces larger, harder-to-manage information packages at handover. Every requirement in the EIR should be traceable to a genuine operational need.
4. Specifying outputs without specifying acceptance criteria
An EIR that lists what must be delivered but does not define what 'acceptable' looks like gives the appointing party no defensible basis for rejecting non-conforming information.
Acceptance criteria, completeness checks, format validation, attribute population thresholds, should be defined in the EIR alongside the requirements themselves.
5. Issuing the EIR after appointment
An EIR issued post-appointment is an instruction, not a contract requirement. The supply chain has already priced the job, established their team and set up their workflows. Compliance with requirements introduced at this stage is dependent on goodwill rather than contract, and retrospective requirements invariably result in lower quality compliance than those established at the outset.
6. Never reviewing the BEP against the EIR
The EIR and the BEP are two sides of the same accountability structure. If the appointing party does not actively review the post-appointment BEP against the EIR, and does not monitor compliance during delivery, the EIR's requirements have no practical effect regardless of how well they were drafted.
Why clients ask Lynefield to support their EIR development
Producing an EIR that is genuinely grounded in operational need rather than one that fulfils a contractual box-tick requires both information management expertise and a detailed understanding of how the organisation's estates and FM function actually works.
Most organisations find that writing the EIR well is harder than it looks, because it sits at the intersection of procurement, information management and operational knowledge that rarely sits in one place internally.
Lynefield works exclusively on the client side, developing EIRs that are derived from the organisation's OIR and AIR, aligned to the CAFM system and operational processes, and structured to give the supply chain clear, deliverable requirements that produce usable information at handover.
If your organisation is preparing for a capital project and does not yet have a documented EIR we would be glad to help.
Frequently Asked Questions
Is 'Exchange Information Requirements' the same as 'Employer's Information Requirements'?
They serve the same purpose and share the same acronym (EIR), but they are not identical. 'Employer's Information Requirements' was the PAS 1192 term. 'Exchange Information Requirements' replaced it when BS EN ISO 19650 was published in January 2019.
The new term reflects a broader understanding of the EIR as governing information exchange between all parties throughout the project, not only from contractor to client. PAS 1192 has been withdrawn; BS EN ISO 19650 is the current standard.
Who is responsible for producing the EIR?
The appointing party or the client organisation. This is a clear requirement of BS EN ISO 19650-2. The EIR is not the contractor's document; it is the client's specification of what they need.
Where clients lack the internal resource or expertise to produce a well-constructed EIR, they typically appoint a client-side information manager to develop it on their behalf.
What is the difference between the EIR and the BEP?
The EIR is the appointing party's document: it specifies what information is needed, in what format, to what standard and by when. The BIM Execution Plan (BEP) is the lead appointed party's response: it describes how those requirements will be met. The EIR comes first and drives the BEP.
A BEP produced in the absence of a clear EIR will default to the contractor's standard approach, which may not align with the client's operational needs.
Does the EIR need to be updated during the project?
The EIR is established at tender and forms part of the appointment. It should not change frequently significant changes carry contractual implications and require formal agreement with the lead appointed party.
However, where major scope or programme changes affect information requirements, the EIR may need to be updated and re-agreed. The BEP, which is a live document, is the more appropriate mechanism for managing how evolving requirements are delivered during the project.
Can the same EIR be reused on multiple projects?
A documented EIR provides a valuable baseline that can be adapted for successive projects, rather than written from scratch each time. However, it must be tailored: different project types, procurement routes, programme structures and contractor capabilities all affect what a well-constructed EIR should say. An EIR that was right for one project should be reviewed and adapted before being applied
Need help turning this into a useable document?
Lynefield helps estates and capital teams develop proportionate information requirements that suppliers can understand, price and deliver. While providing usable deliverables at handover that align with existing systems and processes.
Related Guides
The following guides from the Lynefield Knowledge Hub explore topics covered in this guide in greater depth:
• What is a Digital Twin?
• What are Organisational Information Requirements?
• What is an Asset Information Requirement?
• What is a BIM Execution Plan?
• What is COBie?
• Why BIM handovers fail