Overview of ETSI Standards Development Process


This post aims to share information about the ETSI Standards development process to people who are unfamiliar with the work ETSI does. Also, I add my own insights from my experience of the work at ETSI though it is limited at the moment but should still prove useful.


The objective of the ETSI Standards Making Process (SMP) is to convert market needs for standardisation in the ICT area into ETSI deliverables (specifications, standards, norms, guides, reports) used in the market place.

The input to the process is an existing (as yet known or unknown) market need for standardization. The output is the broad application of the produced deliverables in the market place.

The SMP consists of several elements with their own distinct objectives, inputs and outputs. Each process is defined to the level of which operational tasks are performed, and wherein the ETSI organisation they are performed.

The whole ETSI organization is in one way or the other involved in either operation of the SMP or in direct or indirect support of it. The main technical activities are performed in the Technical Bodies of the Technical Organization. The main direct support for those activities is provided by ETSI Operations (OPS) Division of the ETSI Secretariat.

The operation of the SMP in the Technical Organization is governed by the ETSI Directives, in particular the Technical Working Procedures, and the ETSI Drafting Rules. The processes, tasks and procedures of the ETSI Secretariat are governed by the Secretariat's Quality Management System documentation, notably that of ETSI Operations (OPS) Division.


[inception - an act, process, or instance of beginning (as of an institution, organisation, or concept)]

The times when initiatives to standardisation were taken only when products and services were already available are since long gone. This is particularly the case for telecommunications where standardization precedes or goes hand in hand with the design and development processes.

The input to this sub-process is "what's going on in the marketplace", with "marketplace" having a broad interpretation, including development in the research and academic circles.

The output is a new standardization area, given to an existing or a new Technical Body. The formal output is the Terms of Reference (ToR) and/or a Project Requirements Definition (PRD) document, approved by the ETSI Board or, in the case of an ETSI Partnership Project with an external organisation, approved by the ETSI General Assembly.

[conception - the capacity, function, or process of forming ideas or abstractions or of grasping the meaning of symbols representing such ideas or abstractions; an idea or general notion; the originating of something (as an idea or plan) in the mind]

The creation of a new standardization area or ISG is manifested by the establishment of the new Technical Body or the amendment of the Terms of Reference of the Project Requirements Definition of an existing.

The identification, definition, approval and adoption of work items are the main elements of the conception phase (even if work items may have been envisaged already during the inception process).

The input is identified by standardisation needs in the area. These work items may either be entirely new, leading to new deliverables, or a new version of an existing deliverable ("maintenance work item"). The output is a work item, adopted by the ETSI Membership.

A proposal for a work item may come from inside or outside the Technical Body. The Technical Body may approve the work item if at least four ETSI Members volunteer to support the work. The adoption is formally done by the ETSI Membership (the existence of new work items is made known via the ETSI Web site and Members who disagree with the item may within a 30 day period oppose its adoption into the ETSI Work Programme.


[drafting - pres part of draft - to make a preliminary or tentative version, sketch, or outline (as of  literary composition or other documents)]

A work item in the ETSI Work Programme is intended to lead to one (or more) ETSI deliverable(s).

A Technical Body is free to organise its work in any way it wishes, within the rules of the Technical Working Procedures, including creating Working Groups to which the tasks of drafting parts of the Technical Body's work programme are given.

The drafting usually takes place in a small team (Rapporteur Group) led by a Rapporteur. The work is largely done by "correspondence", i.e. by an exchange of documents via the ETSI DocBox server and LISTSERV email exploder facilities. 

On a side note while the rapporteur is in charge of assembling the work documents and will often write and contribute content/text to it they are not meant to single handily write the entire document. The process requires involvement and engagement from all parties. 

When the draft by the Rapporteur Group is considered ready, the draft deliverable is handed over to the Working Group (when it exists) for approval. The formal approval for further processing or, in the case of ETSI Technical Specifications or ETSI Technical Reports, approval and adoption can only be done by the Technical Body, either at a meeting or by correspondence.

From my experience, this process can either go through smoothly or you find yourself spending a whole working day stuck on single paragraph arguing over wording, context and meaning. Ideally, it is best to handle these kinds of issues during the drafting/writing process. Which means following the updates and working versions that are made available. Plus during conference calls to discuss ongoing work you heed the requests for comment and feedback. All meetings and documents should be accessible through the members ETSI site. So, unless the working group is lax in that regard being unable to find out when meetings and online calls are happening and locating the latest drafts is not an excuse to stay uninformed of what is happening.

Some drafting activities for a Technical Body are performed by Specialist Task Forces (STF) located at the ETSI Secretariat.

The adaptation of specifications from external bodies (Publicly Available Specifications (PAS)) to the ETSI deliverable structure follows the same rules, but will normally be performed by the PAS provider, as defined in the Guidelines the for adoption of Publicly Available Specifications.


[adoption - the taking of an outsider into a family, clan or tribal group]

While the drafting process is, in principle, the same for all ETSI deliverables, the process elements of the adoption process depend on the type of deliverable being processed.

ETSI Technical Specification, ETSI Technical Report, ETSI Special Report, ETSI Group Report  and ETSI Group Specification.

For ETSI Technical Specifications (TS),  ETSI Special Report (SR) ETSI Group Specification (GS), ETSI Group Report (GR) and ETSI Technical Reports (TR), the Technical Body approval and adoption take place at the same time (one combined decision). The publication is then the only element in the adoption process.


Votes are successful if at least 71% of the weighted votes cast are in favour of the draft. This applies to all types of documents, except for some Group Specifications. For European Standards the vote of each nation is weighted as agreed by the ETSI General Assembly. For other types of document, the vote of each ETSI member is weighted as agreed between the members.


The approved standard is published by the ETSI Secretariat, whose permanent staff are based at their headquarters. The Secretariat works closely with those drafting the document and is responsible for ensuring that the relevant procedures have been followed. This helps to guarantee the high quality of the final document. This is mainly done through a group called 'Edit Help' who will proof-read the document and ensure that it applied to ETSI standards drafting rules. To minimise the pain of having to correct all the red-highlights they will make it is best to families yourself with the ETSI writing guidelines beforehand. 


This is an important part of the standardisation process. It is how ETSI adapts its standards to evolving technology and the developing needs of the market place.

Their standards are updated as required to take account of the latest developments and revised versions are published.


Hopefully, this proves interesting and useful. I would encourage looking through the ETSI site to learn more about the standards development process. Also, it is worth checking other SDOs such as CEN-CENELEC, ISO, NIST and IEEE of how they develop standards. Plus, while ENISA is not an SDO it does supports the development of ICT security standards and certification frameworks in Europe as the work they do in it that area is worth checking. There are broad overlaps but key differences in procedure.  



Popular posts

Balancing functionality, usability and security in design

Personal Interest - Unbuilt fleets of the Royal Navy

Personal Interest - RAF Unbuilt Projects