The CIC BIM Protocol: A three-part approach to BIM

John Ford, business information manager at Carillion, offers his advice on the often misunderstood CIC BIM Protocol and how it should be deployed correctly.

The CIC BIM Protocol is one of the most misunderstood, yet one of the important tools that is to be used on every BIM Level 2 project – it ties into many of the other standards such as PAS 1192-2. Implementing this protocol correctly will resolve a huge variety of problems. 

The Protocol is broken up into three parts:

Part 1  A non-editable legal document provided by the CIC which focuses on obligations of the two primary parties, the employer and the suppliers, and how they collaborate and use each other’s information.

Part 2  Appendix 1, the Model Production Delivery Timetable (MPDT). Only models identified in the MPDT are covered by the non-editable legal document above.

Part 3  Appendix 2, the information requirements, based upon PAS 1192-2 and also known as the Employer’s Information Requirements (EIRs). 

When anyone mentions the “BIM Protocol”, invariably people think of Part 1 above, not realising that Parts 2 and 3 – which form its appendices – makes up 90% of the bulk of the BIM Protocol. The Protocol was created because there were a few concerns that needed to be fully addressed when using BIM Level 2 on projects. These are:

  • Clear obligations between employer and their suppliers through contracts and subcontracts.
  • Clear roles and responsibilities.
  • Filling of any responsibility gaps that traditional roles don’t do or don’t do well.
  • Clear defined information requirements.
  • Clear defined stages of when information is to be exchanged to what definition.
  • Protocols around how information should be exchanged.
  • Collaboration agreements and plans.
  • Intellectual property rights when concerning data-rich models.

The BIM Protocol addresses all of the above, but only when you take the time to review and complete it. As mentioned, Parts 2 and 3 make up the bulk of the protocol, but on many projects these appendices are left blank in the protocol or with minor touch-up to the templates provided by the CIC. The templates for the appendices are guides of what you should place there and have been expanded upon since in other standards, as explained below. 

Part 2 of the protocol, the MPDT, has a significant part to play on BIM Level 2 projects, but is often neglected. I have seen many attempts by many disciplines at producing an MPDT. And I have also seen no attempt by many disciplines at producing an MPDT.

The purpose of the MPDT is to establish what information models you want, who is supplying them, when and to what level of detail is required, so that the models can do what they are meant to do. This can vary significantly depending on the company and what stage of the project it is at.

A bad MPDT, for example, would contain a blanket statement that “MEP” is one of the model deliverables. But it will contain no breakdown, and so it will not shed any light on the exact models that are needed. It is basically saying that everything MEP needs to be modelled and that there are no specific requirements that a company needs to focus on.

A better MPDT might list “MEP”, but will then break it down into realistic sub-elements, like listing maintainable MEP assets. This can even be done using the NBS Toolkit that can have added advantages such as being able to define your expectations around level of detail (LOD) as a guide.

Without being clear and having a reason/purpose for having something modelled, why model it? Being precise in what is needed ensures that the right information is delivered at the right time. This defined list can also be used to audit those deliverables to ensure delivery is as expected. It’s easier to audit 50 highly prized sub-model elements than it is a blanket term like MEP/everything.

Part 3 of the protocol also has a key part to play on a project. The CIC does provide a very basic template for what should go into this appendix. But my advice is to throw that away as PAS 1192-2 clause 5.3 gives better guidance on what needs to be defined here.

So project teams should ensure that appendix 2 of the protocol contains Information Requirements based on PAS 1192-2. You would be surprised how many leave the standard CIC appendix 2 template in place, and sometimes it’s not even filled in. But not having a well-defined EIR is usually the failing point of many BIM Level 2 projects.

So when should the CIC Protocol be used?

The CIC Protocol should be used whenever a contract is formed on a BIM Level 2 project, between two parties, the employer and their supplier, referred to as the project team. So if you are a building client, and you are about to appoint a designer or contractor, then the Protocol should be placed within the contract agreements, which includes the updated appendices. If you are appointing more than one designer or contractor, it should be placed into each agreement.

If you are that contractor, and you have just received the BIM protocol from your client, you need to include the protocol into any agreements you form with your subcontractors, consultants, or suppliers.

And if you are one of the subcontractors, the same rule applies to you too. You need to ensure the Protocol is applied to any of your agreements with your suppliers that have a deliverable that contributes to the deliverable imposed upon you by your employer.

Now here’s something to consider. The original protocol received from the employer will only have the Information Requirements from that employer. But what about your requirements? There are going to be many instances where more information is required than what the employer has requested.

For example, the building employer might only want information linked with FM and operations so will be typically focused on that, where as a contractor might want information related to design or construction elements that will help teams better coordinate and collaborate with one another.

So what you can do at this point is add to the BIM Protocol. One way is by adding to the appendix 1 and 2 of the protocol with your version as an addendum. You must be very careful, however, not to delete anything from the original EIR and only add to it. Another way to do this is through the incorporation of the Building Execution Plan (BEP) as defined in PAS 1192-2 clause 7.2 into appendix 1 and 2. A good BEP as per PAS1192 should contain all of the Information Requirements originally defined in the EIR in its various sections, it will then expand on the standard methods and processes as defined in PAS1192.

Should the BIM Protocol be changed from the original CIC version?

Part 1 of the Protocol shouldn’t be changed and is considered a standard document for use on BIM Level 2 projects. Many try to change this document, often because they don’t understand it. Remember that part 1 only affects “information models” and only those models listed in appendix 1.

So you don’t need to expand part 1 to cover anything else, such as documents, or other material types or any other groups of people outside of the scope of the basic “employer-supplier” relationship. This can be captured in a separate part of the contract or within Part 3 of the Protocol if necessary.

Unless you find a direct clash with some of your other contract documents or processes, this document should not be changed. If it is changed, then all parties need to be clear what those changes are as the supply chain will be familiar with the CIC version and understand its impacts, your changes will effect this and possibly effect yourself when reviewing your changed protocol against that of your employer.

Appendix 1 and 2, however, do need to be changed from the original CIC guide versions. The more time is spent on these appendices, the better likelihood that a project will reap the benefits.

The CIC Protocol should be used whenever a contract is formed on a BIM Level 2 project. So if you are a building client, and you are about to appoint a designer or contractor, then the Protocol should be placed within the contract agreements, which includes the updated appendices. – John Ford, business information manager, Carillion

Story for BIM+? Get in touch via email: [email protected]


  1. Thanks John

    A very informative article.


  2. @JohnFord,

    The concerns aired in a previous post on BIMPlus about the CIC BIM Protocol are also raised by Professor David Mosey in my recent publication, BIM Management Handbook.

    He states: ‘However, it is important to spell out that athough the CIC Protocol offers a balanced approach to the licensing of BIM models, it creates an additional burden on the client by making it the contractual gatekeeper of all model licences, leaving project team members without direct remedies in the event of breach of each other’s licences. The multi-party structure of the PPC2000 contract solves these problems by creating direct licences and mutual indemnities between all the project team members who sign it.’

    So, the client role of being licensing intermediary on behalf of all project members can be onerous without a more direct contractual mechanism for adjudicating license disputes between project members.

    Professor Mosey also expresses concerns over the exclusion from the Protocol of any warranty of electronic data: ‘It is worrying that the CIC BIM Protocol excludes any warranty as to the integrity of electronic data delivered, and also excludes liability in respect of any corruption or amendment of data after transmission.’

    These are valid issues and I don’t think that by highlighting them, there is an intention is to suggest that the CIC (or any other) BIM Protocol is unworkable. Instead, there is a need to complement it with additional contractual mechanisms which distribute risk and the responsibility for fairly resolving infringements on the permitted purposes for which model licenses were issued.

  3. @David Shepherd

    Thanks David for your comments, I also read the comments from Mosey, and yours in your published book, and as you said, they don’t appear to be objectionable to how the protocol is used in current forms of contract.

    The comments linked to the corruption of data after transmission is correct in my opinion, in terms of protecting the author from any risk after the fact they transmitted the intact data which, when in their hands was fine, but upon receipt by the receiver is compromised in some way.

    This clause is no different from conventional projects in my opinion, as information has always been exchanged and the risk of corruption or change has always been a risk and is covered by other legal protection. You cant blame an Architect for incorrect data that was correct before transmission but not when it leaves their hands, whether that be on a CDE or during transfer between digital systems or platforms like when you feed the model into a tool that might have to convert it. Obviously, evidence would need to be shown in such an event.

    But we have to remember that again, these clauses only cover those models covered in Appendix 1 and was only meant to protect models from unintended use.

    As for the licensing, if BS1192-1 is used, then permitted use should follow issue status`s, which Identifies what someone should use transmitted information for. If a project team member was to issue the employer (whether that be the primary employer or a contractor) a model with a clear intent of use, and that employer uses that model, or distributes that model that not linked to the original use, then I believe that its correct that they be the ones held responsible and so any disputes be raised with them directly first, rather than going directly to the other project team member who you don’t directly have a contract with.

    I will review the PPC2000 contract though and see how that can directly help in such cases linked to information modelling, management and exchange.

    I believe that no Contract is iron clad, and that there is always secondary risks when a contract tries to resolve the larger primary ones. I can’t say that I have found any issues linked to those you mentioned but I will keep them in mind.

  4. John,

    Useful article and one for great debate. I have literally just been writing about avoiding contractual confusion with BIM and have so far tried to avoid mentioning the CIC Protocol as it adds to this confusion and contract conflict. The CIC Protocol tries to cover issues that are decided at different times in the project and without cutting and pasting the whole document in general these are:

    1. Building Contract between the Client and Contractor e.g. NEC, JCT etc
    2. Pre-Contract Scope of Services and Appointments between the Client and the Consultants (RIBA, ACE etc)
    3. Post-Contract Scope of Services and Appointments between the Contractor and the Consultants for Design & Build (bespoke, RIBA, ACE etc)

    With correctly defined ERs set out in the Contract and matching EIRs that tie with the traditional Prelims requirements and roles and responsibilities, scopes and appointments that set out to deliver the ER/EIRs there should be no need for complex amendments to the contract. This will include pre and Post Contract BEPs, MIDP, TIDPs etc aligned with scopes and appointments (in the old days Designers Responsibilities Matrix).

    The issue we have is that there are too many poor ERs, poor EIRs (if any) and therefore poor BEPs, MIDPs and the rest of the associated Level 2 documents. We don’t want to be in a position where the CIC Protocol is thrown in to try to ‘fix’ the inadequacy of the other documents.

    The issue of data integrity and exchange is a problem, but should be defined in the documents above, including the role of the Information Manager (and associated Task Information Managers issuing information) ensuring that data transfer processes are robust and verification of data exchange can be carried out.


  5. This is a great de-construction and explanation. In your last section you have highlighted the recommendations and yes indeed the Protocol needs a revisit.

    **Part 1 of the Protocol shouldn’t be changed and is considered a standard document for use on BIM Level 2 projects. Many try to change this document, often because they don’t understand it. Remember that part 1 only affects “information models” and only those models listed in appendix 1.**

    Well distilled. You can take this and apply it to most forms of contract, the devil is in the detail Appendix 1 and 2

  6. @Adrian Shilliday
    I agree with your observations Adrian.
    It’s not only you that has Poorly Defined ERs or EIRs.
    And like any conventional project, you would need to work with the employer when such instances arise. Unfortunately, most do not and you end up agreeing to something that is not defined at all or ambiguous at best. As you know, this is often not the contract’s fault, this is the fault of those who don’t understand the contract that they are implementing.
    It all comes down to education, educating yourselves so you understand everything that’s been mentioned above, educating employers when they need it so that you have agreement on what’s to be delivered and how.

  7. @ John Ford

    I will drop you note with the work on this done for North West Construction Hub BIM SIG for comment.


  8. Good article John and I tend to concur with Adrian’s comments regarding the ERs.
    Its 2016 Folks. All BIM Understandings in place? Judging from what I have been reading lately it is not. Did we ever have the same problems when we switched from the drawing board to AutoCAD? Seems to me that while great things become apparent with this state of the art transformation yet again and again contractual burdens (mainly caused through misunderstanding BIM in many ways comes about)
    The CIC doc needs tweaking – yes but more important is agreeing the FULL scope, and that gentlemen has to come from the employer and his relevant consultants. BIM is pulling us hopefully all in one direction and clear collaboration, coordination and communication is required assisting and advising the Client. At the moment its like teaching the Client to drive and then offering him a circuit in a Formula 1 racing Car!!
    Is the built environment really ready this year for BIM or does it require an EOT?

  9. Unbelievable article Nick, very efficient and straight to the point. I’m not sure I fully understand the angle you are coming from though. Lots of confusing language used when simple terms would speak more sense. All in all a confusing but straight to the point article. Well done Nick.

  10. John:

    Thanks for this article. I’m BIM begginer and I have a lot of doubts.

    For example: The CIC is signed before or after that the BEP post contract is written?

    Regards (and sorry for my English)


Comments are closed.

Latest articles in Explainers