本節には、本規格内で使用される用語や略語の定義が記載されている。ISO 21448は、一部ISO 26262 – 1を参照してる。一例として、SOTIFでよく使われる用語として『トリガー条件』があるが、以下のように定義されている。

トリガー条件：危険なふるまい又は合理的に予見可能な間接的ミスユースの防止若しくは検出及び緩和不能に寄与する、その後のシステム反応の発端となるシナリオの特定の条件

本節には、SOTIFの原則の概要とSOTIF活動の作業フロー、SOTIF活動の管理・支援プロセスに関するガイダンスが記載されている。SOTIFの原則の概要では３つのSOTIFの原則である、SOTIF関連の危険事象モデル、四つのシナリオ領域、センス-プラン-アクトモデルについて解説されている。SOTIFの目的は、SOTIF関連の識別された全ての危険事象に関連するリスクレベルが十分に低いことを保証するために、使用する活動及び理論的根拠を記述することである。そのリスクを検証するためにSOTIFの原則が用いられている。例えば、危険事象モデルはClause 6のハザードの識別及び評価で用いらている。詳細についてはClause 6の解説で記載する。
SOTIF活動の作業フローでは、Clause 5の仕様および設計から始まり、Clause 13の運用フェーズの活動までの関係を図示している。
SOTIF活動の管理・支援プロセスではISO 26262 – 2、7、8をSOTIF活動に拡張が可能であることが言及されている。分散型SOTIF開発活動はサプライヤとの活動で、これらの活動はISO 26262 – 8に記載されており、SOTIF活動用にテーラリングされたプロセスを使用し実行される。

SOTIF 関連の識別された全ての危険事象に関連するリスクレベルが十分に低いことを確実にするために、使用する活動及び理論的根拠を記述する
・トリガー条件：後のシステム反応の発端となるシナリオの特定の条件
・危険なふるまい：ハザードの原因、仕様の不十分性
・ハザード：車両レベルでの危険なふるまいにより引き起こされる、危害になり得る潜在的な原因
・危険事象：ある時点で発生する危険な出来事、状況
・危害：人の受ける身体的傷害若しくは健康傷害

ユースケースの一部となるシナリオは、四つの領域(エリア1－4)に分類される
・SOTIF 活動の最終目標は、エリア 2 及び 3 に存在する潜在的に危険なふるまいを評価し、これらのシナリオに起因する残存リスクは十分に低い、すなわち受容基準以下であるという論証を提供すること

危険なふるまいの考えられる原因はシステムが有する以下の３つの能力に関連する
・環境を認知する性能
・意思決定アルゴリズムを用いた、制御アクションの計画
・制御アクションの実行

システムエレメント及びそれらの相互作用は、センス-プラン-アクトモデルで表される。

センス – プラン – アクトモデルに基づいて、Clause 5 仕様及び設計を実施することで、効率的な開発が可能とされる。

本節では、機能の仕様設計とシステム設計及びアーキテクチャ設計、性能の不十分性及び対策の要求事項が定義されている。
機能の仕様設計ではISO 26262 – 3と関係しており、車両レベルでのSOTIF活動の要求仕様書を作成する。その車両レベルでの要求仕様を基にシステム要求、システムアーキテクチャ設計をすることで、後に続くドメイン（ソフトウェアとハードウェア）の活動を実施する。
また、ここで作成される設計文書は、機能安全活動で作成される設計文書と統合することが可能である。例えば、システム要求仕様書に技術安全要求とSOTIF関連のシステム要求を記載しても問題はない。

本節では、意図した機能から生じる、車両レベルで定義されたハザードの識別と、危険なふるまいから生じるリスクの評価、残存リスクの受容基準についての要求事項が定義されている。
実施する活動は、ISO 26262と類似している箇所が多く、機能的不十分性の結果として生じるハザードの識別をする際は、ISO 26262 – 3に規定されている方法を適用することが可能である。
しかし、残存リスクの受容基準の評価は機能安全活動と大きな違いがある。機能安全活動では不合理な残存リスクを回避するために、ASILというリスクの分類システムを定義している。ASILはハザード分析とリスクアセスメントの実施によって定められ、重大度（S）と暴露確率（E）、制御可能性（C）の変数で評価する。ただ、SOTIF活動で残存リスクを回避するための評価方法は残存リスクの有無のみで、重大度（S）と制御可能性（C）の２つの変数で評価する。重大度もしくは制御可能性が０の場合、不合理な残存リスクがないと判断される。それ以外の場合は、不合理な残存リスクがあると判断され、Clause 7以降の活動が必要となる。

本節では、潜在的な仕様の不十分性、潜在的な性能の不十分性及び潜在的なトリガー条件の分析方法と、識別したトリガー条件を含むシナリオを、SOTIFが達成可能とみなせるかどうかを判断するための評価方法についての要求事項が定義されている。トリガー条件の分析方法は原因ツリー分析、事象ツリー分析(ETA)、帰納的SOTIF 分析又はハザード及び運用性分析（HAZOP）が挙げられる。そして、分析の考慮点としては、類似のプロジェクトのメンバーや専門家を交えて分析実施することである。このようなメンバーから得た知識や経験を基に、分析を実施することで精度の高い結果を得ることを可能にする。こうして識別されたトリガー条件を含むシナリオは、Clause 10の検証活動の対象となる。

本節では、Clause 5～7の作業成果物を基にSOTIF関連リスクに対処するための方策についての要求事項が定義されている。活動の流れとしては本節でSOTIF 方策を検討し、これらのSOTIF 方策を用いて仕様および設計(Clause5)を更新し、更新された仕様および設計を使用して意図した機能(Clause6、7)のリスク評価を実施する。この一連のプロセスを繰り返し、システムを更新する。また、SOTIF方策のポイントは不合理な残存リスクの「回避」または、「低減」を適切に組み合わせることである。「回避」はリスクを伴う活動自体を中止し、予想されるリスクを遮断する対策、「低減」はリスクを未然に防止する対策や、予防措置を講じて発生頻度を減らす対策である。

本節では、Clause 10～12で実施する活動の妥当性確認目標を含む、検証および妥当性確認戦略の策定方法についての要求事項が定義されている。一般的にテスト計画について述べており、各ドメインごとで作成するテスト計画に合わせてSOTIF関係のテスト計画を作成する。ここで定義される妥当性確認の目標は、リスクの受容基準が満たされていることの証拠として提供する。目標は、本節で定義された妥当性確認方法に応じて決定される。

本節では、Clause 7で識別したトリガー条件を含むシナリオが、Clause 9で定義した検証及び妥当性確認戦略に則り受容基準を満たしていることを評価するための要求事項が定義されている。評価する際に気を付けるポイントは、SOTIFの原則であるセンス-プラン-アクトモデルに従って、各ドメインをセンシング、計画アルゴリズム、アクチュエーションに分けて検証することである。そして、それぞれで定義された検証方法に則り、評価を実施する。

本節では、未知のシナリオに対して残存リスクを評価し、安全を保障できる領域を広げる（四つのシナリオ領域）活動についての要求事項が定義されている。ここでは、車両に統合された際にシステムの危険なふるまいを誘発する可能性のある状況に起因する残存リスクを評価する。評価方法の例としては、経験の少ないユーザーによるミスユースのテストや、リアルワールドでのシナリオ探索が挙げられる。ここでできる限りの未知のシナリオを評価することで、SOTIFの原則の１つである四つのシナリオ領域の未知で危険な領域を狭めていく。

本節では、Clause 5～11 の目的及びClause 13で定義されているフィールド監視方策(例えば、プロセス及び必要なハードウェアリソース)の達成に基づいて、SOTIF の達成を示す論証についての要求事項が定義されている。論証の構成としては、GSNを使用した考え方が推奨されており、GSNはISO 26262の安全論証の構成としても使用されている。またSOTIFの達成を示す論証の審査は、ISO 26262 – 2の機能安全アセスメントと合わせて実施することができ、審査によって承認されたシステムに対して、リリースの勧告がされる。

本節では、リリース後のSOTIFを確実にするためのフィールド監視プロセスと、そのプロセスを実行するための要求事項が定義されている。製品の開発中にSOTIF活動で未知のシナリオの領域を減らし、不合理な残存リスクがないことを評価した上でリリースを行っても、リリース後にそれまで識別されていなかったハザードがフィールドで発見される可能性がある。そのため、その推定の正しさを監視する必要がある。監視結果から、当初想定していたとりも残存リスクが高いと判断されたり、新たなリスクが市場で発見された場合、Clause 5の活動から再度実施する。活動の結果次第で、機能をアップデートするなど対応する必要がある。また、監視する際は、インシデントの報告だけではなく、知識体系（同様の機能から学んだ教訓）、コンテキストの変更（インフラの進化）も対象となる点を考慮する必要がある。