UN-R155/ISO21434で
PSIRT相当として見られるポイント
（監査で止まらない最小設計）
UN-R155やISO/SAE 21434の公開説明を見ると、法規・規格の文面の中に「PSIRT」という名称そのものが必ずしも前面に出てくるわけではありません。
ただし、UN-R155のCSMS要求は、開発・生産・生産後を通じて、組織レベルの管理、リスクの特定/評価/対処、検証・試験、リスク評価の継続更新、車両上のサイバー攻撃・脅威・脆弱性の監視/検知/対応、有効性評価、分析用データの提供、継続的なフィールド監視、サプライヤ依存管理、合理的期間内の緩和までを求めています。
ISO/SAE 21434 も、車両のE/Eシステムに対するサイバーセキュリティ工学をコンセプトから廃棄までのライフサイクル全体に適用し、サプライチェーン整合を促す標準だと公式に説明しています。
つまり公開要件から逆算すると、
「サプライヤー側にもPSIRT相当の運用機能が求められやすい」
というのが実務的な読み方になります。
先に結論：監査で見られやすい“PSIRT相当”は6点
UN-R155やISO 21434 の公開要件を、サプライヤーが担うべき日々の実務へ落とすと、まず次の6点が見られやすくなります。
1. 受付窓口
脆弱性情報やOEMからの照会を受ける入口があるか。
2. 影響評価
対象版数や構成を切り、影響あり/なし/調査中を判断できるか。
3. 期限管理（SLA）
合理的な期間内（SLA内）に評価・緩和・回答できるか。
4. 継続監視
新しい脅威や脆弱性、フィールド上の兆候を継続的に見ているか。
5. サプライヤ連携
自社より上流のベンダや外部依存を管理できているか。
6. 証跡管理
一連の対応結果や根拠を、後から監査で再現できるか。
これらはUN-R155の公開要件で列挙される機能群と、ISO/SAE 21434 のライフサイクル/サプライチェーン前提から、実務上もっとも自然に導かれる観点です。
なぜ“PSIRT相当”として見られるのか
UN-R155の観点
UN-R155の公開実装文書では、CSMS（サイバーセキュリティ管理システム）に求められるプロセスとして、監視・検知・対応、継続的なリスク評価更新、フィールドデータやログの分析、サプライヤ依存管理、合理的な期間内の緩和 が明示されています。
これは、「部署の名前をどう付けるか」は別として、実態として「受付 → 評価 → 対応 → 更新 → 記録」の一連の運用プロセス（つまりPSIRT機能）が必要だということです。
UNECE自身の説明でも、規則は必要なプロセスとして「サイバー攻撃の監視と効果的な対応」「成功・未遂攻撃の分析支援」「新しい脅威や脆弱性を踏まえた有効性評価」を挙げています。
ISO/SAE 21434の観点
ISO/SAE 21434 の公式ページも、この標準が車両のE/Eシステム全体に適用され、ライフサイクル全体を通じてサイバーセキュリティ工学を扱い、規制対応やサプライチェーン整合を支えると説明しています。
さらに、ISO/PAS 5112 は 21434 に基づく CSMS 監査のガイドとして、監査プログラム管理、組織監査、監査証拠の提示 を扱っています。
ここから見ると、サプライヤー側に「PSIRTという名の専任部署」があるかよりも、「PSIRT相当の運用能力（プロセス）と、それが機能している証拠（エビデンス）」があるか が問われやすいと言えます。
兼務でも破綻しない：最小の準備ステップ
これらの要求に対し、現場が兼務体制であっても監査で止まらないようにする「最小の準備」を5ステップで整理します。
1役割を4つだけ決める
最初に必要なのは大きな組織図を作ることではなく、役割の切り分けです。
最低限 「受付窓口」「技術評価」「対外回答」「承認」 の4つが決まっていれば、UN-R155の「組織レベル管理」や、21434/監査側の「責任の明確化」にかなり対応しやすくなります。
2SLAを3つだけ置く
最小で必要な期限管理（SLA）は、「受領確認」「一次回答」「最終回答」の3つです。
UN-R155の公開文書では、対応が必要な脅威や脆弱性は合理的な期間内に緩和されるべきとされており、これを現場に落とすと、SLAの基準が無いと運用を証明できません。
3対象版数と証跡をつなぐ
監査で止まりやすいのは「どの版に対する判断か」が弱い時です。
「対象製品」「対象版数」「SBOM/構成表」「判断理由」「提出履歴」を『案件ID』で束ねるだけでも、監査の再現性が大きく上がります。ISO/PAS 5112 が “providing evidence during CSMS audits” を明示している点から見ても、証跡と版管理の連携は後回しにしない方が安全です。
4継続監視の“入力源”を決める
UN-R155は、車両フィールドからの継続的監視と、車両データ・ログからの分析能力を求めています。
サプライヤーが高度なVSOC（Vehicle SOC）を持たないとしても、少なくとも「OEM/上流からの通知」「JVN/NVD/ベンダ公告」「フィールド不具合やログ」のどこを監視の入力源とするかを明確に決める必要があります。
5サプライヤ依存の連絡線を決める
UN-R155の公開要件には、契約サプライヤやサービスプロバイダとの依存管理が含まれます。
つまり、自社に脆弱性が見つかった時に「上流の問い合わせ先」が不明だと、PSIRT相当の能力としてかなり弱く見えます。問い合わせ窓口、回答期限の取り決め、エスカレーション先を最低限決めておくのが現実的です。
自社でのPSIRT立ち上げや、法規監査に耐えうる運用設計を整理したい方はご相談ください。
【無料】オンライン相談を予約する差し戻されやすいポイント
実務やプレ監査などで差し戻されやすいのは、次のようなケースです。
-
窓口はあるが、SLAが無い
いつまでに回答するかの基準がないため「合理的な期間内の緩和」を証明できない。 -
監視していると言うが、入力源や頻度が曖昧
「気づいたら対応する」という属人的な状態になっており、プロセスの再現性がない。 -
影響なしと言うが、対象版数が無い
どのバージョンに対する評価なのかが抜け落ちており、構成管理と紐付いていない。 -
上流依存があるのに、問い合わせ先や責任分界が曖昧
OSやミドルウェアの脆弱性について、ベンダへ確認するフローが定義されていない。 -
証跡がファイルで散らばり、案件IDで辿れない
「あの時のメール」「あの担当者のPC」に依存しており、監査員へエビデンスを提示できない。
これらは高度なセキュリティ技術論ではなく、「運用設計の不足」が原因です。
だからこそ、最初に「最小の型」を作っておく方が監査には圧倒的に強くなります。
FAQ：監査・法規とPSIRT
A. 公開要約レベルでは、必ずしも “PSIRT” という名称を要求しているわけではありません。ただし、UN-R155 が求める監視・検知・対応・サプライヤ依存管理・合理的期間内の緩和と、21434 のライフサイクル/サプライチェーン整合要件を実務へ落とすと、自ずとPSIRT相当の運用能力が必要になります。
A. フル機能をいきなり持つ必要はありません。まずは「窓口、技術評価、対外回答、承認」の最小体制と、「SLA、証跡、上流連絡線」を整えるのが現実的です。これは公開されている監査・実装文書の趣旨とも整合します。
A. 「窓口、SLA、対象版数、判断根拠、提出履歴」が『案件ID』で一気通貫につながっていることです。ISO/PAS 5112 が“evidence during CSMS audits”を強調していることからも、単発の資料より「再現性のある証跡の束」が重要です。
監査に耐える証跡管理を、システムで自動化しませんか？
案件IDを軸とした対象版数の管理、SLAに基づく期限のトラッキング、影響判断の根拠となるSBOMや構成表の紐付け。これら監査で求められる「PSIRTの運用プロセス」を標準実装した Auto PSIRT Cloud の運用イメージをデモでご案内します。