The four most important systems engineering standards (2025 update)

Standards play a particularly important role in the safety-critical area and are required by the client or legislator. I would therefore like to provide an overview of the most important standards below.
There are a number of organizations that publish standards. In addition to the well-known ISO (International Organization for Standardization), there are many others that often cooperate with ISO or even publish standards together. These include DIN, IEC, DOT, IEEE and many more.
In the following, I abbreviate the names of the standards and choose only one organization and leave out the year, language and the like. So "ISO 15288" instead of the actually correct designation "ISO/IEC/IEEE 15288:2023(en)".
There are also many domain-specific standards, for example the well-known ISO 26262 "Road vehicles - Functional safety". Instead, I prefer to describe the domain-neutral standard (if it exists), in this case IEC 61508.
And finally: the list is not complete, and "important" is subjective. And there is of course a lot of literature on the subject. A good starting point is any relevant standard, as these always cite other related standards. INCOSE also has a Overview of SE standards and a special issue (Insight Connect, April 2014). Research is also being conducted in this area. For example, the paper "A review of systems engineering standards and processes" (2008) provides an exciting historical outline.
Everything clear? Then let's go!
ISO 15288 is so important that I have already written a separate article about this and will certainly do so even more frequently in the future, because this is actually the entry point for serious systems engineering. INCOSE has already recognized this, which is why the INCOSE SE manual also places great emphasis on conformity with ISO 15288. Therefore, my recommendation is to study the SE manual as well as ISO 15288, which is somewhat easier to digest.
The title actually already says what the standard says: It is primarily about the processes that must exist in order to be able to carry out systems engineering. And there are a lot of them: 25 processes, 123 artifacts and 403 activities (refers to an older version). As not all projects require this scope, the adaptation of the process is an important aspect that is also described.
It is also important what it does not say. In particular, there is hardly any mention of methodology. This makes sense, as there are many different development methods. Furthermore, the topics of quality and project management are only touched on, as there are separate standards for these.
Finally, there are a few "related" standards. Interesting here is the ISO 29110which covers the same topic for small organizations. And the ANSI/EIA-632 (Processes for Engineering a System) is an older standard that now coordinates with ISO 15288. And ISO 12207 corresponds to 15288 for software (and not systems). It has been harmonized so that software development according to ISO 12207 is also compliant with ISO 15288.
Of this series of standards, ISO 9001 is probably the best known. It defines the minimum requirements for an organization's quality management. It is hard to imagine that an organization can develop complex systems without having implemented the requirements of 9001. For safety-critical developments, however, the requirements go far beyond ISO 9001. This is where IEC 61508 comes into play (see below).
The series of standards is initially designed to be neutral. There are usually other standards for the various domains and sectors, such as ISO 10006 for quality management in projects.
This standard forms the basis for a number of industry-specific adaptations. ISO 26262 from the automotive sector is certainly one of the better known.
Nowadays, safety is becoming increasingly important, both in terms of functional safety and security. Recently, I have been hearing more often that the standard is not (or no longer) adequate for today's developments. This is also clear from the name (electrical systems): modern systems typically consist of mechanics, electronics and software. The standard lacks precision and a high level of detail, particularly with regard to the continuous safety check across these three areas.
Not all functional safety standards are derived from IEC 61508. DO178 (aviation) is independent. Here is a Overview of safety standards in various industries.
Professional project management is also essential for successful systems engineering. For this reason, references to the project manager and the project plan are also regularly found in the other standards. However, project management is so extensive that there is a separate standard for it.
As a guideline, ISO 21500 refers to a number of other standards. DIN 69901, which covers not only processes but also methods, is particularly important in Germany.
Is something missing? Discuss with us!
We have now familiarized ourselves with the most important standards and gained a rough overview of the jungle of standards. Have I forgotten anything important? Or do you have any suggestions or further information? Then Just start a discussion.







Hello Mr. Jastram,
I believe that their selection in the area of safety is strongly limited to electrical engineering. Ad hoc I can think of a few more:
- DIN EN ISO 12100 -Safety of machinery - General principles for design - Risk assessment and risk reduction (ISO 12100:2010); German version EN ISO 12100:2010
- DIN EN ISO 13849 : Safety of machinery - Safety-related parts of control systems (successor to 61508/511)
I can also recommend reading the VDI memorandum: http://www.vdtuev.de/themen/industrie_und_anlagensicherheit/erfahrungsaustausch_zues/vdi-denkschrift-zur-technischen-sicherheit resp. https://www.vdi.de/technik/fachthemen/technische-sicherheit/
Furthermore, there is also the point of documentation in the field of systems engineering. i.e.
- DIN EN IEC/ISO 82079-1 : Preparation of instructions for use - Organization, content and presentation - Part 1: General principles and detailed requirements
- DIN Technical Report 146
So much for the divisional aspects, not to go too far.
In my opinion, what systems engineering needs are methods of representation and classification systems in order to be able to categorize and describe the dependencies and interfaces of the system from and to the disciplines and framework conditions involved.
Here, most methods and tools are simply too linear and do not allow enough dimensions of a complex system to be mapped.
Tools that I have come across in my search for the solution I have not yet found are: Mindmapping, Colon Classification, BPMN, UML, asset labeling systems.
Hello Mr. Schmitz,
> I believe that your choice in the area of safety is very much limited to electrical engineering.
That's right. That certainly has something to do with my experience-related „operational blindness“. On the other hand, I would also say that this type of system is orders of magnitude more difficult (keyword: Therac-20 -> Therac-25).
> DIN EN ISO 13849 : Safety of machinery - Safety-related parts of control systems (successor to 61508/511)
I didn't have this DIN on my radar yet, but I've just found a comparison. 61508 and 13849 seem to be completely independent of each other, which is actually stupid.
> I can also recommend reading the VDI memorandum: http://www.vdtuev.de/themen/industrie_und_anlagensicherheit/erfahrungsaustausch_zues/vdi-denkschrift-zur-technischen-sicherheit resp. https://www.vdi.de/technik/fachthemen/technische-sicherheit/
I'll have a look on my next train journey, it looks very interesting, thank you.
> Furthermore, there is also the point of documentation in the area of systems engineering. i.e.
The question for me was where to stop: after all, 15288 stipulates that documentation must be covered, just not how. You could probably write a whole book on this topic.
> In my opinion, what systems engineering needs are methods of representation and classification systems in order to be able to categorize and describe the dependencies and interfaces of the system from and to the disciplines and framework conditions involved.
> Here, most methods and tools are simply too linear and do not allow enough dimensions of a complex system to be mapped.
I fully agree with that. That is certainly also the reason why so much is happening in SE at the moment. The approaches we've used so far don't scale particularly well.
> Tools that I have come across in my search for the solution I have not yet found are: Mindmapping, Colon Classification, BPMN, UML, asset labeling systems.
I don't know Colon Classification yet, I'll have to have a look.
I see three layers that we have not yet mastered optimally: (1) Processes (What do I have to do?), (2) Languages (What do I have to do it with?), (3) Methods (How do I have to do it?). Tools sit on top and support the whole thing. There is still a lot to do, especially in the area of methodology.