1. 目的
2. 適用範囲
　2.1 適用範囲
　2.2 適用範囲外
3. 用語の定義
4. 背景
5. サイバーセキュリティの原則
6. TPLC
7. 市販前の考慮事項
　7.1 セキュリティ要求事項およびアーキテクチャ設計
　7.2 TPLCに関するリスクマネジメント原則
　7.3 セキュリティ試験
　7.4 TPLCサイバーセキュリティマネジメント計画
　7.5 顧客向け文書
　　7.5.1 注意事項等情報および取扱説明書
　　7.5.2 顧客向けセキュリティ文書
　7.6 規制当局への申請に関する文書
8. 市販後の考慮事項
　 8.1 意図する使用環境における機器の運用
　 8.2 情報共有
　 8.3 協調的な脆弱性の開示（CVD）
　 8.4 脆弱性の修正
　 8.5 インシデントへの対応
　 8.6 レガシー医療機器
　　8.6.1 TPLCとレガシー医療機器
　　8.6.2 TPLCにおける考慮事項
　　8.6.3 補完的リスクコントロールに関する考慮事項
9. 業許可に関する考慮事項
　9.1 業許可を持つステークホルダーの役割
　9.2 リース医療機器の取扱い
　9.3 中古医療機器の取扱い
10. 手順書等
11. 参考
12. 付則
添付資料１　ソフトウェア部品表（SBOM）の扱い

1. 目的
2. 適用範囲
　2.1 適用範囲
　2.2 非適用範囲
3. 用語の定義
4. 役割と責任
5. 設計開発ステージとソフトウェア開発プロセスの対応（5.1.3 b））
6. 成果物
7. ソフトウェア開発およびサイバーセキュリティ確保手順（市販前）（5.）
　7.1 ソフトウェア開発計画（5.1）
　　7.1.1 プロセスのインプットおよびアウトプット
　　7.1.2 ソフトウェア開発計画書の作成
　　7.1.3 ソフトウェア結合および結合試験計画書（5.1.5）
　　7.1.4 ソフトウェア検証計画書の作成（5.1.6）
　　7.1.5 リスクマネジメント計画書の作成（5.1.7）
　　7.1.6 ソフトウェア文書管理計画書の作成（5.1.8）
　　7.1.7 ソフトウェア構成管理計画書の作成（5.1.9）
　7.2 リスクアセスメント
　7.4 ソフトウェア要求分析（5.2）
　　7.4.1 プロセスのインプットおよびアウトプット
　　7.4.2 ソフトウェア要求仕様書作成準備
　　7.4.3 ソフトウェア要求仕様書の作成（5.2.2）
　　7.4.4 ソフトウェアリスク分析の再評価（5.2.4）
　　7.4.5 要求事項の更新（5.2.5）
　　7.4.6 ソフトウェア要求事項の検証（5.2.6）
　　7.4.7 ソフトウェア開発計画書の更新（5.1.2）
　7.5 リスクコントロール策の検討
　7.6 ソフトウェアアーキテクチャの設計（5.3）
　　7.6.1 プロセスのインプットおよびアウトプット
　　7.6.2 ソフトウェアアーキテクチャ仕様書の作成
　　7.6.3 ソフトウェアアーキテクチャ仕様書の検証（5.3.6）
　7.7 ソフトウェア詳細設計（5.4）
　　7.7.1 プロセスのインプットおよびアウトプット
　　7.7.2 リスクマネジメントワークシートの更新
　　7.7.3 ソフトウェア詳細設計書
　　7.7.4 詳細設計の検証（5.4.4）
　7.8 ソフトウェアユニットの実装（5.5）
　　7.8.1 プロセスのインプットおよびアウトプット
　　7.8.2 ソフトウェアユニットの実装（5.5.1）
　　7.8.3 ソフトウェアユニット検証プロセスの確立（5.5.2）
　　7.8.4 ソフトウェアユニットの合否判定基準
　　7.8.5 ソフトウェアユニットの検証（5.5.5）
　7.9 ソフトウェア結合および結合試験（クラスB、C）
　　7.9.1 プロセスのインプットおよびアウトプット
　　7.9.2 ソフトウェアユニットの結合および結合試験（5.6）
　　7.9.3 ソフトウェア結合試験の実施および記録
　　 7.9.4 回帰試験（5.6.6）
　7.10 ソフトウェアシステム試験（5.7）
　　7.10.1 プロセスのインプットおよびアウトプット
　　7.10.2 ソフトウェアシステム試験計画書（5.7.1）
　　7.10.3 セキュリティ試験計画書
　　7.10.4 セキュリティ試験
　　7.10.5 ソフトウェアシステム試験記録（5.7.5）
　　7.10.6 変更後の再試験（5.7.3）
　　7.10.7 ソフトウェアシステム試験の評価（5.7.4）
　7.11 トレーサビリティマトリックスの作成および更新（7.3.3）
　7.12 ソフトウェアリリース（5.8）
　　7.12.1 プロセスのインプットおよびアウトプット
　　7.12.2 ソフトウェア検証の完了確認（5.8.1）
　　7.12.3 既知の残留異常の文書化（5.8.2）
　　7.12.4 既知の残留異常の評価（5.8.3）
　　7.12.5 リリースするバージョンの文書化（5.8.4）
　　7.12.6 リリースするソフトウェアの作成方法の文書化（5.8.5）
　　7.12.7 アクティビティおよびタスクの完了確認（5.8.6）
　　7.12.8 ソフトウェアのアーカイブ（5.8.7）
　　7.12.9 ソフトウェアリリースの信頼性の確保（5.8.8）
　　7.12.10 サイバーセキュリティマネジメント計画書の作成
　　7.12.11 顧客向け文書の作成
　　7.12.12 規制当局への申請
8. ソフトウェア保守プロセスおよびサイバーセキュリティ確保手順（市販後）（6.）
　8.1 プロセスのインプットおよびアウトプット
　8.2 ソフトウェア保守計画書（6.1）
　8.3 医療機関への顧客向け文書の提供
　8.4 リスク受容可能性の再評価
　8.5 医療機関等への情報提供
　8.6 問題および修正の分析（6.2）
　　8.6.1 フィードバックの文書化および評価（6.2.1）
　　8.6.2 変更要求の分析（6.2.3）
　　8.6.3 ソフトウェア変更のリスクマネジメント（7.4）
　　8.6.4 ユーザーおよび規制当局への通知（6.2.5）
　　8.6.5 修正の実装（6.3）
　8.7 セキュリティインシデントへの対応
　8.8 不具合報告
　8.9 脆弱性の開示（CVD）
　8.10 脆弱性の修正
　8.11 業許可に関する考慮事項
　8.12 業許可を持つステークホルダーの役割分担
　8.13 リース医療機器の取扱い
　8.14 中古医療機器（貸与医療機器も含む）
9. ソフトウェア構成管理プロセス（8.）
　9.1 プロセスのインプットおよびアウトプット
　9.2 構成識別（8.1）
　9.3 変更管理（8.2）
10. ソフトウェア問題管理（9.）
　10.1 プロセスの開始基準、インプット、終了基準およびアウトプット
　10.2 問題報告の作成（9.1）
　10.3 問題の調査（9.2）
　10.4 関係者への通知（9.3）
　10.5 変更管理プロセスの使用（9.4）
　10.6 記録の保持（9.5）
　10.7 問題の傾向分析（9.6）
　10.8 ソフトウェア問題解決の検証（9.7）
11. 参考
12. 付則

1. 目的
2. 適用範囲
　2.1 適用範囲
　 2.2 適用範囲外
3. 用語の定義
4. 開発体制および要員（組織体制）
　　4.1.1 プロジェクト体制図
　　 4.1.2 組織間のインターフェイス
　4.2 要員体制
　　 4.2.1 役割と責任
　　 4.2.2 各役割に求められる資格要件
5. スケジュール
　 5.1 市販前（設計開発）
　 5.2 市販後（製造販売）
6. 成果物
　6.1 市販前（設計開発）
　6.2 市販後（製造販売）
7. 参考
8. 付則