I have participated in International Code Council (ICC) code development since 2007. Code development has been a source of frustration, growth, defeat, success, pride and above all camaraderie. Even though we don’t always agree, I have found my fellow code development stakeholders to be extremely passionate, smart and giving individuals. 

The recent process changes for the development of the 2027 International Energy Conservation Code (IECC) are welcomed by some and disliked by others.  

Prior to the development of the 2024 IECC the IECC was developed alongside all other ICC codes under Council Policy 28.  That changed starting with the 2024 IECC when the process became a standards development process.

Most participants in the 2024 process would agree that the change resulted in a bigger time commitment, greater opportunity for discussion and refining of changes, less code official participation, very little improvement to energy efficiency, and a lot of process confusion.

The process for the 2024 and the start of the 2027 IECC development cycle was defined by ICC Council Policy 12.  But earlier this year the ICC Board of Directors added 3 sub policies to provide specific procedures depending on the type of standard being developed: (A) for ANSI standards, (B) for Standards Council of Canada standards, and (C) for ICC standards.  The IECC is considered an ICC standard and follows ICC Council Policy 12C procedures.  

Despite the added procedures the committee has wrestled with the consistent handling of modifications, lack of scope clarity, and subgroup* level procedures.  

The process seems to also be struggling with the voting procedures in that they are very restrictive. Subgroups only require a majority vote to approve, modify or disapprove a code change and send their recommendation on to the main committee but the committee requires a 2/3 vote to approve or modify a code change proposal but only a majority vote to disapprove a proposal. This is true not just for a final vote but to move items into the second public comment draft.

Code change proposals can (and have) received a majority vote at the subgroup level but did not receive a 2/3 vote at the main committee. A proposal can even be approved by a majority vote at both the subgroup and main committee but fail to move forward. Unfortunately, some really good proposals that would have benefited from public input in the current process are going to fail to make it into the public comment draft unless a proponent can bring new information to the table to convince the committee to move it forward during the committee balloting process (not a likely scenario).

A balloting process follows the initial committee actions allows committee members to confirm their vote on the code proposals that were approved or to try and overturn or further amend the action by convincing at least 1/3 of the committee to reconsider and overturn the action. Chances of this occurring are slim. As mentioned above also allows proponents of disapproved proposals to try and convince the committee to change their position on the proposal and move it on to public comment but once again, chances are slim.  

After completion of the balloting process the ICC staff will develop a public comment draft with the intent that it will be available for 30 days starting around the middle of November.  Only approved changes in the public comment draft will be available for comment.

Subgroups and the committee will then commence a second round of actions related to the comments received, likely beginning early 2026.  This second round of committee action should be completed mid 2026 and result in what will be the 2027 IECC.  

ICC plans to publish the 2027 IECC late 2026.

My thoughts thus far . . . I think I can safely say that I still prefer the code development process that allows greater participation from code officials and does not require the extremely high workday time commitment. On average I spent 4 hours a day, four days per week, February through June (a lot of time). Council Policy 28 which governs the code development process is also much more clear and easier to follow, not to mention it is also stood the test of time.  I also do not like the high bar for proposals to move forward in the standard development process.  The code development process only requires a majority vote by the committee to move a code change proposal forward to the next step and allows for two committee hearings and modifications opportunities which provides ample opportunity for refinement of proposals.  In short, I would love the old process to come back for the IECC.

* Subgroup not subcommittee per the new CP12C procedures.