共同PSIRT/BPOを使う時の契約ポイント
（責任分界・免責・情報区分）

先に結論：契約は「外に出す仕事」と「社内に残す仕事」を分ける

最初に決めるべきは、共同PSIRT/BPOに「何を任せ」、そして「何を自社の責任として残すか」です。

この切り分けが曖昧だと、共同PSIRT/BPOは“便利な丸投げ先”ではなく、
“責任があいまいな中間層（ボトルネック）”になってしまいます。

---

比較：共同PSIRT/BPOで契約に入れるべき論点

まずは、最低限この表の論点で整理すると「契約で何を握るべきか」が分かりやすくなります。

契約で必ず決めたい7項目

1. 役務範囲

最初に「何を頼むのか」を明文化します。特に次のような粒度で明記した方が安全です。

• 受付のみ
• 一次トリアージまで
• 回答ドラフトの作成まで
• OEMフォーマットへの変換まで
• 定例会議/進捗管理まで

※“PSIRT支援一式”のような曖昧表現は危険です。

2. 責任分界（最重要）

ここが最重要です。特に、次の線引きを書面化（あるいは運用フロー図化）してください。

共同PSIRT/BPOが「影響なし」のドラフトを書くのは問題ありませんが、その「影響なし」の最終責任は自社で持つ方が、OEM対応としても法務的にも安全です。

3. 情報区分

実務で一番揉めやすいのがここです。少なくとも、次の3区分は開始前に決めてください。

• 共有可： 案件ID、期限、表向きの製品名、提出済み文面
• 条件付き共有： SBOM、構成表、ログ、設定値
• 原則非共有： ソースコード、内部チケット詳細、顧客固有情報

この区分が無いまま始めると、外部が分析に必要な時に情報を出せず、逆に不要な自社機密を渡してしまうことになります。

4. 免責

ここで言う免責は、「全部責任逃れする」ことではなく、「責任の所在を明確にすること」です。契約で整理したいのは、たとえば次のような論点です。

• 最終技術判断は委託側（自社）が持つこと
• 受託側は提供された情報に基づき支援を行うこと
• 故意/重過失や守秘義務違反があった時の扱い
• 第三者（OEM等）からのクレーム時の扱い
• 再委託先が関わる場合の責任連鎖

※ここは最終的に法務確認が必要ですが、少なくとも事業部門として論点から漏らさないことが大事です。

5. SLA（期限）

共同PSIRT/BPOで一番価値が出やすいのが「期限（SLA）運用」です。だからこそ、受託側のSLAと委託側のSLAを分けて書きます。

このように、相手の作業期限だけでなく、「社内での往復の期限」も切るのが運用を止めないコツです。

6. 証跡帰属

監査で一番困るのは、共同PSIRT/BPOを使っていた時期の証跡が、解約後に自社に残っていないことです。最低限、次を決めてください。

• 案件台帳の「正本」はどちらのシステムで持つか
• 回答ドラフトの保管先
• 証跡リンク/IDの管理者
• 提出履歴の保管先
• 契約終了時の返却・削除方法

7. 終了時の引継ぎ

見落としやすいですが、かなり重要です。契約が終わった瞬間に案件が止まらないよう、次を決めます。

• 継続中案件一覧の引継ぎフォーマット
• 「次回更新日付き」の案件の引継ぎルール
• 証跡・テンプレ・台帳のデータ返却形式
• アカウント停止、データ削除の証明、バックアップ扱い

---

兼務でも破綻しない導入手順

よくあるNG例（委託が失敗するパターン）

• NG1：業務範囲が「PSIRT支援一式」
  何をどこまで頼んだのか後から不明になり、結局「お互いに相手がやると思っていた」という責任分界の崩壊が起きます。
• NG2：ドラフト作成と最終判断が混ざっている
  「文面を作る支援」と「技術的に影響なしと判断する責任」を分けないと、何かあった時の責任が曖昧になります。
• NG3：SBOMやログを“必要時に考える”
  最初に情報区分のNDAやセキュリティチェックを済ませておかないと、いざ緊急の脆弱性分析が必要な時にデータを渡せず詰まります。
• NG4：終了時引継ぎを決めていない
  ベンダーを切り替える時や内製化する時に、台帳・証跡・継続案件が手元に残らず、運用が完全にストップします。

---

FAQ：契約と責任分界