ISO 19650 workflows are the process rules that govern how information gets created, checked, shared and stored across a project’s lifecycle, not just the software used to manage it. The first practical move on any project is to define the organisational, asset and project information requirements and assign a CDE workflow owner before issuing the Exchange Information Requirements to tender. Everything else, including the BEP, MIDP and TIDP, exists to operationalise that decision.
TL;DR:
- Trace each Exchange Information Requirement through project, asset, and organisational needs; skipping project requirements can leave handover gaps in the required asset data.
- Agree container IDs, classifications, and status codes before production; transfers between different common data environments may require teams to reenter metadata manually.
- Build TIDPs by task team, combine them into an MIDP, and schedule authorisation reviews around project decisions, allowing time for expected model rejections.
- ISO 19650 requirements become enforceable only when a protocol enters the appointment contract; involve legal reviewers while drafting the EIR, not after signing.
- No formal international accreditation scheme verifies ISO 19650 compliance, so track internal measures such as scheduled status transitions, metadata corrections, and model rejections.
Table of Contents
- 1. What the ISO 19650 series covers across parts 1 to 5
- 2. Core workflow components: OIR, AIR, PIR and EIR
- 3. CDE workflow: metadata, status codes and transfers
- 4. Planning and responsibilities: BEP, MIDP and TIDP
- 5. Stepwise implementation: from gap analysis to assurance
- 6. Compact checklist and common pitfalls
- 7. Practitioner example: embedding ISO 19650 workflows with a remote team
- 8. Roles and responsibilities: appointing party, lead appointed party, appointed parties
- 9. Protocols, contracts and ISO 19650 obligations
- 10. Integrating ISO 19650 workflows with existing project tools
- 11. Typical workflow sequences across project phases
- 12. Common challenges and solutions in implementing ISO 19650 workflows
- 13. KPIs to measure workflow effectiveness and compliance
- 14. Balancing standardisation with pragmatism
- 15. How Xponexus Engineering supports ISO 19650-aligned delivery
- FAQ
- Sources
1. What the ISO 19650 series covers across parts 1 to 5
ISO 19650 is an international standard for managing information across the built-asset lifecycle, and it replaced BS/PAS 1192 when it was published. Part 1 sets out the concepts and principles, including the information management process and terminology used throughout the series. Part 2 governs the delivery phase: appointments, information exchange and the project team’s day-to-day obligations. Part 3 covers the operational phase once an asset is in use. Part 4 deals with information exchange mechanisms, and Part 5 addresses security-minded information management for sensitive projects.
Mapping these to project stages matters because teams often read Part 2 in isolation and miss that Part 1’s definitions govern how every later clause is interpreted. For clause-level detail, the UK BIM Framework guidance and BSI’s own standard pages are the two reference points worth bookmarking before you draft anything.
2. Core workflow components: OIR, AIR, PIR and EIR
The workflow centres on a hierarchy of information requirements that starts at the organisation and narrows down to a single appointment. Organisational Information Requirements (OIR) state what an organisation needs to know to run its business. Asset Information Requirements (AIR) translate that into what’s needed to manage a specific asset once built. Project Information Requirements (PIR) define what the project itself must produce to satisfy both. These three feed the Exchange Information Requirements, which the appointing party issues to structure the BEP and the information delivery plans that follow.
In practice, the chain works like this:
- An asset owner’s OIR might state a need to track plant maintenance costs across a portfolio.
- That becomes an AIR specifying which asset data fields must exist in the handover model.
- A project team turns that AIR into a PIR for the current build, then issues an EIR that tells appointed parties exactly which attributes, formats and timings to deliver.
Skipping straight to an EIR without tracing it back to a PIR is a common cause of information gaps that only surface at handover.
3. CDE workflow: metadata, status codes and transfers
A common data environment is a workflow first and a technology second: agreeing metadata, status codes and container structures comes before choosing a platform, not after. UK BIM Framework guidance frames the CDE as both the process and the technical solution supporting it, with metadata, status codes and container structures as the essential building blocks.
Each information container needs a unique ID, a classification and a status code that signals where it sits in the approval cycle, typically something like S (suitable for a given purpose), WIP (work in progress) or A followed by a number for authorised revisions. A few points worth building into any CDE setup:
- Assign unique container IDs and classification codes before production work starts, not retrospectively.
- Agree status code conventions across all appointed parties so an “A1” means the same thing to everyone on the project.
- Expect manual metadata re-registration when information moves between different CDE solutions on the same project.
Pro Tip: Write your metadata mapping rules into the BEP itself, so anyone federating models from a different CDE knows exactly which fields need manual re-entry.
For a fuller walkthrough of configuring these mechanics alongside document control obligations, see our guide to the common data environment.
4. Planning and responsibilities: BEP, MIDP and TIDP
The BIM Execution Plan is where EIRs become operational commitments. A usable BEP sets out the project’s information standards, the CDE workflow, the team’s capability and the delivery schedule. From there, the Master Information Delivery Plan (MIDP) aggregates every Task Information Delivery Plan (TIDP) into one schedule that tracks who delivers what, and when.
A practical sequence for producing these documents:
- Draft the BEP against the issued EIR, naming the CDE workflow and classification system to be used.
- Build individual TIDPs for each discipline or task team, listing their specific containers and delivery dates.
- Aggregate TIDPs into the MIDP so the lead appointed party can see the whole project’s information flow at once.
- Assign a responsibility matrix mapping each container type to the party accountable for producing and checking it.
- Align MIDP milestones to the project’s key decision points, rather than to arbitrary calendar dates, so information arrives when it’s actually needed for a decision.
UK BIM Framework guidance recommends structuring requirements so a master set can be filtered down to appointment-level EIRs, which avoids duplicated or contradictory asks across TIDPs. For a working template, our BIM Execution Plan checklist steps through BEP alignment against the EIR and MIDP/TIDP structure.
5. Stepwise implementation: from gap analysis to assurance
Moving from paper compliance to live operation follows a reasonably consistent sequence regardless of project size.
- Run a gap analysis against the relevant ISO 19650 clauses, checking current practice against the guidance for project delivery rather than assuming existing habits already comply.
- Configure the CDE workflow and agree metadata and status code conventions before any EIR goes out to tender.
- Issue EIRs to prospective appointed parties and evaluate their BEP responses against stated capability and capacity.
- Mobilise the team: deliver training on the agreed CDE workflow, finalise the BEP, and brief every task team on its TIDP obligations.
- Run internal audits at defined intervals, checking container status codes and metadata against the BEP’s own rules.
Mobilisation is where most teams underinvest. The standard’s own guidance on project delivery activities treats training and resourcing as a distinct activity, not an afterthought bolted onto kick-off.
Pro Tip: Build your first internal audit into the schedule before the project starts, not after the first milestone slips.
6. Compact checklist and common pitfalls
Before information starts flowing at volume, a short readiness check saves rework later:
- EIR issued and acknowledged by all appointed parties.
- CDE workflow configured, with status codes and classification agreed.
- BEP published and matched to the issued EIR.
- MIDP and TIDPs shared and understood by every task team.
- Training completed for the agreed CDE workflow and naming conventions.
- Acceptance criteria set for each information container type.
The most frequent pitfall is choosing software before agreeing the workflow, which forces the process to bend around a tool’s limitations rather than the reverse. A close second is leaving metadata rules undocumented, so each discipline invents its own container naming. A third is over-prescribing the BEP until it becomes a document nobody actually reads; practical guidance on moving from BS 1192 warns specifically against this.
Pro Tip: If your BEP is longer than the EIR that prompted it, trim it: length rarely correlates with compliance.
7. Practitioner example: embedding ISO 19650 workflows with a remote team
A consultancy appointing an embedded remote engineer can map that person directly into existing TIDP obligations rather than treating them as a separate resource. We integrate into a client’s BEP and CDE workflow from day one, producing calculations, drawings and BIM coordination outputs aligned to UK standards and Eurocodes, under NDA, with project kick-offs typically starting within 48 hours. The practical integration step is simple: brief the embedded engineer on the project’s EIR and status code conventions during onboarding, then treat their outputs exactly as any other appointed party’s containers for checking and authorisation. Our BIM coordination workflow mapping shows this in more detail.
8. Roles and responsibilities: appointing party, lead appointed party, appointed parties
ISO 19650 defines three tiers of responsibility that recur throughout every clause. The appointing party sits at the top, typically the client or asset owner, and is responsible for issuing the EIR and defining what information the project must produce. The appointing party doesn’t usually produce information directly; its job is to specify requirements clearly enough that delivery teams can price and plan against them.
Below that sits the lead appointed party, usually the main contractor or lead designer on a delivery team, who is responsible for coordinating the response to the EIR and producing the BEP. The lead appointed party must proactively authorise the delivery team’s information models before they’re shared further, and this authorisation role is one of the more demanding obligations in the standard, according to guidance on project delivery processes. Rejections during this authorisation step are a normal part of the iterative process, not a sign of failure, and should be built into the MIDP/TIDP schedule as expected iterations rather than treated as delays.
Appointed parties sit below the lead appointed party and are the individual organisations or disciplines actually producing containers: structural engineers, services consultants, specialist subcontractors. Each appointed party is responsible for its own TIDP and for meeting the status code and metadata conventions set out in the BEP. Clarity about which tier holds which responsibility matters most at handover, when disputes about who should have caught an error tend to surface. Setting out the responsibility matrix early, naming which tier authorises which container type, avoids most of that friction.
9. Protocols, contracts and ISO 19650 obligations
ISO 19650 itself is a standard, not a contract, so its obligations only bind a project when a protocol or contract clause makes them binding. A new ISO 19650 protocol template and accompanying legal guidance exist specifically to translate the standard’s requirements into enforceable contract terms, including an information particulars table and clauses covering the CDE, information transfer, security and level of information need.
Without a protocol appended to the appointment contract, an EIR is effectively a wish list with no mechanism to enforce delivery, checking or payment consequences for non-compliance. The protocol’s information particulars table is where project-specific detail lives: which CDE solution applies, which security requirements govern the project, and what level of information need is expected at each stage. Getting legal input on this table at the same time the EIR is drafted, rather than after contracts are signed, avoids a mismatch between what’s technically required and what’s contractually enforceable.
Readers managing public-sector bids should also check procurement-specific compliance requirements that sit alongside the protocol. Teams preparing £5m+ UK tenders sometimes need to satisfy both ISO 19650 protocol clauses and separate procurement checks, and guidance on avoiding common procurement failures covers the compliance risks that can trip up bids even when the technical BEP is sound.
10. Integrating ISO 19650 workflows with existing project tools
Most consultancies already run project management platforms, scheduling tools and document control systems before adopting ISO 19650 workflows, and the standard doesn’t require replacing any of them. The practical task is mapping the CDE’s status codes and container structures onto whatever system already tracks approvals, rather than running two parallel tracking systems that inevitably drift apart.
Where a CDE solution and a project management tool are different products, the metadata mapping has to be explicit: which field in the project tool corresponds to the CDE’s status code, and who updates it when a container moves from WIP to shared status. This is the same manual re-registration challenge that arises when federating across multiple CDEs, and it deserves the same treatment: documented rules in the BEP, not an assumption that the tools will sync automatically.
Scheduling tools benefit most from alignment with the MIDP, since delivery milestones in the MIDP should map directly onto the programme’s key dates rather than sitting in a separate BIM-only schedule that project managers never check. Document control systems need the clearest mapping of all, because status codes and revision controls duplicate much of what document control already tracks. Our guide to engineering document control covers how to keep that duplication from causing conflicting version histories.
11. Typical workflow sequences across project phases
The information flow looks different at each stage of a project, even though the underlying CDE and status code mechanics stay constant. At the brief and feasibility stage, the appointing party issues OIR and AIR-derived requirements, and the main workflow activity is drafting the PIR and initial EIR, with little container production yet underway.
During design, the lead appointed party coordinates TIDPs across disciplines, and the dominant workflow activity is iterative authorisation: containers move from WIP to shared status as each discipline checks coordination against others, then get formally authorised at defined milestones. This is usually the busiest phase for status code transitions, since early design containers change status multiple times before reaching a reviewed state.
At construction, the workflow shifts towards as-built verification: containers already authorised at design stage get checked against what’s actually been built, and any deviations trigger new container versions rather than edits to existing ones. Handover is where AIR requirements get tested directly, since the asset information model has to carry the attributes the original AIR specified, or the appointing party inherits a dataset that doesn’t answer the operational questions it was meant to answer.
Each phase transition is a natural point to review whether the BEP’s workflow still matches what the team is actually doing, since plans drafted at the brief stage rarely anticipate every coordination challenge that surfaces once design work is underway.
12. Common challenges and solutions in implementing ISO 19650 workflows
The most common challenge is sequencing: teams choose a CDE platform, then try to retrofit metadata and status code conventions around whatever the tool defaults to. The fix is procedural, not technical: agree the workflow on paper first, then select or configure a platform that can support it, even if that means accepting a less polished interface in exchange for a workflow match.
A second challenge is inconsistent status code interpretation across appointed parties, particularly on projects with multiple CDE solutions in use simultaneously. UK BIM Framework guidance is direct about this: transfers between different CDE solutions often require manual re-registration, and teams that don’t plan for this lose track of which version of a container is authoritative. The solution is documenting the mapping rules in the BEP before federation starts, not discovering the gap mid-project.
A third, quieter challenge is BEP over-prescription: documents that try to specify every eventuality become too long for task teams to actually follow, and compliance drops as a result. Practical adoption guidance notes that concise, targeted BEPs achieve better adoption than extensive manuals, and that training and governance integrated into mobilisation work better than documentation alone.
Finally, many teams underestimate how iterative the authorisation process is meant to be. Repeated rejections of delivery-team models during coordination checks aren’t a sign the process has failed; they’re built into the standard’s own activity sequence, and MIDP/TIDP schedules that don’t allow time for iteration set teams up to miss milestones through no fault of the information itself.
13. KPIs to measure workflow effectiveness and compliance
Measuring whether an ISO 19650 workflow is actually working comes down to a small number of practical indicators rather than a single compliance score, since no formal accreditation scheme verifies conformance against the standard itself.
Useful indicators to track include the proportion of containers meeting their agreed status code transitions on schedule, the number of manual metadata re-registrations required per federation cycle, and the frequency of model rejections during the lead appointed party’s authorisation step. A rising rejection rate partway through design, for instance, usually signals a coordination or briefing gap rather than a quality problem in any single discipline’s output.
Training completion against the BEP’s own requirements is worth tracking too, since mobilisation gaps tend to surface later as metadata inconsistencies rather than as an obvious training failure at the time. BSI’s own position is clear that no formal international accreditation scheme exists for ISO 19650 compliance, and that market certificates are advisory, based on an assessor’s expertise rather than an accredited audit. That means internal KPIs, tracked consistently project to project, carry more weight than any single external compliance mark. Third-party readiness assessments, such as those offered by TÜV SÜD, can usefully benchmark a team’s starting position, but they sit alongside internal tracking rather than replacing it.
14. Balancing standardisation with pragmatism
The standard rewards teams that keep the BEP short and enforceable rather than exhaustive. A twenty-page BEP that every task team has actually read beats a hundred-page manual nobody opens after kick-off. Standardise the essentials: status codes, metadata fields, container naming, and leave the rest flexible enough to fit the project. Capture lessons at close-out and feed them into the next BEP, because the standard’s own value compounds across projects, not within one.
— Mohammed
15. How Xponexus Engineering supports ISO 19650-aligned delivery
Configuring EIRs, CDE workflows and MIDP/TIDP structures is only half the challenge; having the capacity to produce review-ready containers against that structure is the other half. We work as embedded engineers within a consultancy’s existing workflow, so outputs slot into an agreed BEP and CDE rather than arriving as a separate stream to reconcile.
That capacity comes with a few practical advantages worth naming directly:
- Project kick-off typically starts quickly after appointment.
- Calculations, drawings and BIM coordination outputs align with appropriate standards.
- Engagements are protected by confidentiality agreements.
- Clients retain control over their client relationships while scaling capacity.
This is one route among several for teams needing extra capacity to meet ISO 19650 obligations, and it suits firms that want embedded output without a permanent hire. Explore our remote engineering support service to see how a kick-off would map to your current BEP.
FAQ
What are ISO 19650 standards?
ISO 19650 is an international standard series for managing information across the built-asset lifecycle, covering concepts, delivery, operation, exchange and security in Parts 1 to 5. It replaced the earlier BS/PAS 1192 framework in the UK and sets out how information requirements, the CDE and delivery plans should work together.
What is the workflow of BIM?
A BIM workflow under ISO 19650 starts with the appointing party issuing an EIR derived from organisational, asset and project information requirements. Appointed parties respond with a BEP, break delivery into TIDPs that aggregate into a MIDP, and exchange containers through a CDE workflow governed by status codes.
How to become ISO 19650 certified?
There’s no formal international accreditation scheme for ISO 19650 compliance, so “certification” in the market sense refers to advisory assessments rather than an accredited audit, according to BSI. Readiness assessments and training from providers such as TÜV SÜD can help a team benchmark its processes against the standard’s guidance ahead of a project.
How do protocols affect ISO 19650 contractual obligations?
ISO 19650 is a standard, not a contract, so its requirements only become enforceable when a protocol is appended to the appointment agreement. A dedicated protocol template and legal guidance translate EIR and CDE obligations into contract clauses covering information transfer and security.
What’s the most common mistake teams make with ISO 19650 workflows?
Selecting a CDE platform before agreeing the underlying workflow is the most frequent error, since it forces metadata and status code conventions to bend around a tool’s defaults. Guidance on the CDE is explicit that the workflow should be agreed first, with technology selection following it.
Sources
- BSI — ISO 19650: building information modelling (BIM)
- Centre for Digital Built Britain — OIR guidance
- UK BIM Framework — Guidance Part 2: Processes for project delivery
- RICS — How new protocol helps make sense of ISO 19650
Leave a Reply