The Role of the FSM
You'll be surprised
2025-08-26 16 min Season 1 Episode 4
Description & Show Notes
Hello and welcome to a new episode of “Applied FuSa,” the podcast for FuSa pragmatists!
The role of the Functional Safety Manager (FSM) established itself shortly after the first version of ISO 26262 was published in 2011. Usually, this role is explicitly assigned in safety-relevant projects—meaning a single employee takes on the role of FSM.
And yet, to our surprise, the role of the FSM is not defined anywhere in ISO 26262.
“What??”
You heard that right: The role of Functional Safety Manager does not exist in ISO 26262. But there is the role of Safety Manager.
“Isn’t that the same thing?”
No, not really.
In this episode, we will compare the role of the Safety Manager with the widely established role of the FSM. We will also look at if and how ISO 26262 defines responsibilities and accountabilities for work products like the Safety Plan, the Development Interface Agreement (DIA), and the Safety Case.
Transcript
Hello and welcome to a new episode of “Applied FuSa,” the podcast for FuSa pragmatists!
The role of the Functional Safety Manager (FSM) established itself shortly after the first version of ISO 26262 was published in 2011. Usually, this role is explicitly assigned in safety-relevant projects—meaning a single employee takes on the role of FSM. And yet, to our surprise, the role of the FSM is not defined anywhere in ISO 26262. “What??” You heard that right: The role of Functional Safety Manager does not exist in ISO 26262. But there is the role of Safety Manager. “Isn’t that the same thing?” No, not really. In this episode, we will compare the role of the Safety Manager with the widely established role of the FSM. We will also look at if and how ISO 26262 defines responsibilities and accountabilities for work products like the Safety Plan, the Development Interface Agreement (DIA), and the Safety Case.
The topic is complex. So, I would like to start with a brief overview of this episode. We will first compare the role of the FS Manager, as it has been established in many companies, with the definition of the Safety Manager. There is in fact a significant difference when it comes to the extent of responsibility. What has become common practice—namely full responsibility for a range of work products (like the safety plan, DIA, safety case, and others) as well as responsibility for achieving functional safety in a project—goes far beyond what is defined in the standard. Does that make sense? Is it still compliant? Or have we all misunderstood the eye-so and been on the wrong track for years? By the end of this episode, we will understand why the role of the FSM actually makes sense—and also why it is not specified in this form in eye-so 26262.
Let’s begin by looking at the role of the FSM as it has been established in many companies since the first publication of the safety standard in 2011. First, it must be noted that the FSM is held directly responsible for a number of work products. Typically, this includes the DIA, Safety Plan, Safety Case, Release for Production Report, Tool Evaluation and Qualification Report, FS Confirmation Measures Plan, as well as the Competence Management Report. To ensure better understanding, the term “responsibility” needs to be clarified. It fundamentally refers to responsibility for work products that must be created during the course of product development. These work products often involve multiple team members with different roles. When we talk about responsibility, it’s important to distinguish between the responsibility for planning, coordination, and tracking on one hand, and the actual creation (execution) on the other. To differentiate between these two areas of responsibility, we will use the term ownership for the actual creation of the work product (the doing), and responsibility for planning, coordination, and tracking. In other words: Responsibility means being accountable for ensuring that the work gets done, whereas ownership means actually doing the work. For the work products just mentioned, the FSM assumes ownership. That means the FSM must create them personally. Since the FSM is responsible for the Safety Plan—and since all safety-related activities are planned within the Safety Plan—the FSM also takes on responsibility for all other work products. This extends the scope of responsibility far beyond what is defined for the Safety Manager.
So let’s turn to that topic for a moment. In Part 1 of the ISO, the role of the “safety manager” is defined as: “person or organization responsible for overseeing and ensuring the execution of activities necessary to achieve functional safety.” End of quote. There is also an additional note: “At different levels of the item’s development, each company involved can appoint one or more different persons by splitting assignment in accordance with the internal matrix organization.” End of quote. So it must first be emphasized that this is not a role defined for a single individual, but rather a role to which certain activities are assigned. Brief remark: It is a common misunderstanding—beyond the context of functional safety—that a role is always assigned to a single person within a project team. While this is often the case, it is by no means a necessity. A role generally represents a bundle of activities that are functionally related and therefore grouped under a common label—for instance, the role of the software architect, whose tasks typically do not need to be distributed among multiple people. So, a role can describe the tasks of a single individual, but it doesn’t have to. A role description can include activities that are carried out by several people. Back to the topic. The role of the safety manager includes all activities necessary to fully achieve functional safety for the respective product. Since such activities exist across all areas of expertise, many holders of roles already defined for product development and production will temporarily also take on the role of a safety manager. For instance, when the lead test engineer ensures that his team verifies all safety mechanisms using fault injection tests, he is, in that moment, acting as a safety manager. This is clearly emphasized in Part 2, in Note 2 to Clause 6.4.2.4: “As the term ‘safety manager’ is defined as a role, its assignment can be split between different persons depending on the organization.”
End of quote. Another very important aspect is Note 1 to Clause 6.4.6.1, also from Part 2: “The safety manager can delegate tasks to persons that possess the required skills, competences and qualifications.”
End of quote. This makes it clear: the role of the safety manager is primarily about assuming responsibility.
Let us now examine to what extent ISO 26262 actually defines responsibility for those work products for which the FSM role is assigned ownership—before we conclude with a comparative evaluation of the two roles. Let’s begin with the Safety Plan.
Part 2, Clauses 6.4.5 and 6.4.13 define requirements for the Safety Plan. However, there is no indication there of who is responsible for the Safety Plan. Only the required contents are specified. Considering that the Safety Plan encompasses all activities that must be planned and carried out in a project, it is clear that the main purpose of the Safety Plan is planning, coordination, and monitoring. Therefore, it is only logical to assign ownership of this work product to the safety manager. Regarding the role of the FSM, the Safety Plan is considered one of the most important documents for the FSM. In this respect, the two roles are consistent on this point.
Requirements for the Development Interface Agreement can be found in Part 8. An initial indication of responsibility for the safety manager is found in Note 1 to Clause 5.2: “The Development Interface Agreement (DIA) aims to describe the roles and responsibilities between the customer and supplier. Consequently, the safety planning by the customer and supplier is in line with the DIA.” End of quote. Since the safety manager is responsible for planning all safety activities, they are generally also in charge of the contents of the DIA. Here again, ownership applies, and both roles—the FSM and the Safety Manager—are consistent with regard to the DIA.
The requirements for the Safety Case contain no indication as to which role should assume responsibility or ownership for this work product. However, it is clear that the safety manager is at least responsible, since the development of the Safety Case must always be planned, coordinated, and monitored. But should the safety manager also assume ownership? The ISO does not provide any guidance on this. In practice, however, it has become common to consider the Safety Case as a document belonging to the FSM. In other words: the FSM assumes ownership.
ISO 26262 does not specify which role should assume responsibility or ownership for the Release for Production Report. Both questions remain completely open. However, it is clear once again that the safety manager must at least assume responsibility—that is, planning, coordination, and monitoring of the development of this report. From conversations with many colleagues, I have learned that the FSM is also expected to assume ownership, and I find this absolutely sensible for the following reason: The Release for Production Report is essentially the production release from the perspective of functional safety. Who better than the FSM—supported by the results of the confirmation measures—could evaluate this? Therefore, this assignment makes a lot of sense. However, to avoid placing full responsibility solely on the FSM’s shoulders, it has proven advantageous that the Release for Production Report is approved not only by the FSM but also by other responsible parties (for instance, the Project Lead or Business Director).
The Tool Evaluation and Qualification Report actually consists of two work products according to ISO 26262: the Software Tool Criteria Evaluation Report and the Software Tool Qualification Report. However, it has proven pragmatic to combine both reports into a single Tool Evaluation and Qualification Report. Regarding the question of responsibility and ownership, it must be noted that ISO 26262 once again does not specify clear requirements on this point. There is only a single reference related to tool qualification: the Tool Qualification Report must document the names of the persons who performed the qualification (see Part 8, Chapter 11, Clause 11.4.6.2e). This implies that the qualification of software tools is a cross-competence activity. Ownership (meaning the actual execution) must therefore be distributed across all relevant competence areas. The FSM also assumes ownership regarding the tools specifically used by them. Beyond that, there are no further requirements. However, it has proven practical—and is widely practiced—that the FSM is responsible for creating the final report. This means the FSM performs the evaluation and qualification only for the tools they use personally, but is responsible for all other tools. The actual doing is carried out by the respective users of those tools themselves.
A Competence Management Report is intended to provide the “evidence for competence management” required in Part 2, Chapter 5, Clause 5.5. Who is responsible for creating this report is not defined. However, since this is once again a cross-competence activity, it makes sense for the FSM to be responsible for its creation. In other words, the FSM assumes ownership. This is exactly how it is handled in many companies.
Last but not least: the Confirmation Measures Plan. Here, ISO 26262 makes an exception, because very clear requirements are defined regarding the independence of the person who is to carry out each individual confirmation measure. Confirmation measures are, as is well known, either confirmation reviews of specific work products or functional safety (FS) audits or assessments. Strictly speaking, no specific role is defined for ownership of the confirmation measures. However, there are clear requirements regarding the required level of independence of the person performing the confirmation measure. As in all other similar cases, a clear recommendation is made here to explicitly and unambiguously define responsibilities within the company’s internal processes. Only in this way can it be ensured—especially for the confirmation measures—that the achievement of functional safety for a product is verified with sufficient reliability.
That covers the question of which responsibilities ISO 26262 defines for the safety manager regarding the work products for which the FSM is generally expected to assume ownership. Now, let’s move on to a final evaluation. Regarding responsibility for planning, coordination, and monitoring, the two roles align closely. The FSM is generally responsible for all safety-relevant activities within a project. However, there is one key difference between the roles: While ownership for the Safety Plan can be directly derived from the requirements of ISO 26262 for the Safety Manager, for the Safety Case and the DIA there are only indirect hints. For the other work products, the Safety Manager is not assigned any ownership at all by the standard. Yet, in practice, ownership is usually expected from the FSM. So, how should this be evaluated? Ultimately, it is absolutely essential to define ownership precisely for every work product. It should be ensured that no more than one role is assigned ownership, as otherwise there is a high risk of unnecessary disputes over areas of responsibility. Responsibility and ownership should always be clearly and unambiguously defined. For the work products assigned to the FSM, it has simply proven pragmatic to expect ownership from the FSM. This is because these are safety-relevant documents that cannot be assigned to any other competence area. Cross-competence, safety-related work products are therefore often assigned to the FSM. This arrangement creates clear conditions regarding responsibility and, furthermore, generates a high level of acceptance within the project team. Therefore, it should be regarded as positive and highly recommended. From my own experience, I can report that many FSMs go well beyond this scope of responsibility by also taking on technical responsibility—for example, by supporting the development of technical safety concepts or safety-relevant test cases. That can definitely make sense and add real value to projects. Most FSMs have previously worked in engineering—for instance, as Systems Architects—and bring a wealth of technical expertise. So it can be beneficial to leverage that experience within projects, even when serving in the FSM role.
Applied FuSa – a podcast for Functional Safety pragmatists. Get your new piece of FuSa every other week.
Expert
00:01:06
Moderator
00:15:32