Feb. 2, 2026

Tailoring of Safety Activities

The player is loading ...

Hello and welcome to a new episode of “Applied FuSa,” a podcast for FuSa pragmatists.

“We have to do this because it’s written in the ISO.” You hear that a lot, but it’s not always true. In line with the motto “Everything goes, nothing’s a must,” ISO 26262 offers enough flexibility in how its requirements are implemented. In fact, deviations are allowed—as long as it’s demonstrated that they don’t result in an unacceptable, safety-relevant risk.
In other words: everything is fine as long as functional safety concepts are implemented completely and correctly, since these are the ultimate goal from a FuSa perspective. This episode explains the ISO 26262 requirements regarding tailoring.
Which raises the question: can those requirements themselves be tailored? Hmm… now it’s getting complicated… but let’s wait and see.

00:00 - Moderator Intro

00:56 - Req 1-6

05:30 - Req 7-9

08:16 - Moderator Outro

WEBVTT

00:00:00.000 --> 00:00:42.000
Hello and welcome to a new episode of “Applied FuSa,” a podcast for FuSa pragmatists. “We have to do this because it’s written in the ISO.” You hear that a lot, but it’s not always true. In line with the motto “Everything goes, nothing’s a must,” ISO 26262 offers enough flexibility in how its requirements are implemented. In fact, deviations are allowed—as long as it’s demonstrated that they don’t result in an unacceptable, safety-relevant risk. In other words: everything is fine as long as functional safety concepts are implemented completely and correctly, since these are the ultimate goal from a FuSa perspective. This episode explains the ISO 26262 requirements regarding tailoring. Which raises the question: can those requirements themselves be tailored? Hmm… now it’s getting complicated… but let’s wait and see.

00:00:56.000 --> 00:05:29.000
In ISO 26262 a total of 9 requirements is defined for the tailoring of safety activities in Part 2, Section 6.4.5. Let’s take a closer look at each of them and explore how they can be implemented most effectively. The first requirement (Section 6.4.5.1) defines tailoring as: “a safety activity may be omitted or performed in a different manner.” So, as already mentioned… anything goes, nothing’s a must. However, ISO also requires that: 1. every tailoring decision must be documented in the safety plan; and 2. a justification must be provided to show that the proposed tailoring does not pose a risk to the implementation of the safety concepts. This is reasonable, and in most cases, no major changes to the development process are expected. The safety plan must already describe how the safety concepts will be implemented in detail, and any deviation from ISO 26262 must of course be documented and justified. Not only because tailoring is subject to confirmation reviews and/or a functional safety assessment, but also so that the project team can ensure for themselves that the product they’re developing will be sufficiently safe. This is a matter of the company’s safety culture: always asking whether one’s own actions could pose a risk to achieving functional safety—and if so, what can be done to reduce that risk. The second requirement mandates compliance with the provisions of Section 6.4.6.7, if tailoring is the result of an impact analysis. Section 6.4.6.7 itself contains four requirements: 1. Tailoring shall be consistent with the impact analysis. This is automatically fulfilled if the tailoring is based on an impact analysis, so it doesn’t introduce an additional requirement. 2. The affected work products that need to be created or updated shall be identified, described, and reworked accordingly. Again, this is already covered by the impact analysis and therefore not an additional burden. 3. If safety-relevant documentation is not compliant with ISO 26262, then all necessary activities must be identified to achieve compliance. Here, it should first be evaluated whether non-compliance of specific documents (for instance, safety manuals or integration manuals) actually results in an unacceptable risk and therefore must be revised or supplemented. If revision is not necessary, this decision must still be documented and justified in the safety plan. In summary, this second requirement mostly refers to good practice already inherent in performing an impact analysis. The only real effort lies in assessing and justifying whether any deviations introduce risk—and, if not, documenting why that is the case. A common reason for tailoring is the reuse of components. In such cases, the requirements from Part 8, Section 14 must be applied if a proven-in-use argument is to be made. This third requirement related to tailoring is trivial, since Section 14 of Part 8 explicitly defines the requirements for proven-in-use components, and therefore naturally applies in such scenarios. In other words: the third tailoring requirement does not trigger any additional activities—it simply points to existing obligations that would apply anyway when reusing components based on proven-in-use arguments. The same applies to the next three requirements. They concern tailoring as a result of: Confidence in the usage of software tools; Qualification of a software component, and Evaluation of hardware elements. In all these cases, ISO 26262 already provides dedicated sections with specific requirements: Tool confidence: Part 8, Chapter 11; Software component qualification: Part 6, Chapter 12; and Hardware element evaluation: Part 8, Chapter 13. The tailoring requirements simply refer to these existing chapters. Therefore, no additional activities are introduced—these requirements merely reinforce that if tailoring is related to one of these areas, the corresponding ISO sections must be followed as they would be anyway.

00:05:30.000 --> 00:08:15.000
The seventh requirement for tailoring addresses the case of a Safety Element out of Context (SEooC). This is a very specific situation where, typically, no project-specific safety concept exists, and as a result, ISO 26262 is already extensively tailored by default. This requirement refers to Part 10 of the standard. In addition, it states that: 1. An SEooC must be developed based on assumptions derived from the intended use and integration context; and 2. These assumptions must be validated during the integration of the element. However, these points are not truly additional tailoring requirements. Instead, they are logical consequences of applying tailoring in the context of SEooC development. They follow naturally from the concept of SEooC itself and are already addressed in Part 10. Therefore, as with the previous requirements, no additional activities are expected to arise specifically from this seventh tailoring requirement. It simply restates what is already necessary in SEooC-based development. The eighth requirement for tailoring addresses products developed for trucks and buses, which are generally out of scope of ISO 26262. However, if such products interface with components that have been developed according to ISO 26262 or other safety standards, then Part 8, Chapter 15 must be taken into account: “Interfacing an application that is out of scope of ISO 26262.” In this sense, the eighth requirement is once again not an independent or additional requirement. It simply points to an existing chapter that must be considered if relevant interfaces exist. Therefore, like several previous tailoring requirements, this is essentially a cross-reference and does not introduce any new activities beyond what would already be necessary in such a system context. The ninth and final requirement for tailoring refers to Part 8, Chapter 16, which defines the requirements for the integration of systems not developed in accordance with ISO 26262. Here too, the same principle applies: ultimately, it always comes down to ensuring that appropriate measures are in place to guarantee that the relevant safety concepts are fully and correctly implemented. Put differently: no deviation—regardless of its nature—from ISO 26262 is permitted to introduce an unacceptable risk to the functional safety of the product. Or, to return to the initial message: everything goes, nothing’s a must.

00:08:16.000 --> 00:08:35.000
Applied FuSa – a podcast for Functional Safety pragmatists. Get your new piece of FuSa every other week.