2026年1月16日

今回のブログでは、開発ベンダーと顧客の間でビジネス上発生するやり取りの中で、セキュリティインシデント（以下インシデント）やそれに伴うトラブルに発展する可能性のあるリスクと、それを低減させるために注意するべきポイントをご紹介します。

目次

はじめに

サイバー攻撃が激化し、インシデント発生のニュースを頻繁に目にするようになった昨今、インシデントを起こさないようにサイバーセキュリティが活発に議論され重要視されるようになってきました。ただ、インシデントの中には、事前の取り決めや契約時の責任範囲の曖昧さなどが原因で発生してしまったものや、その曖昧さが原因でトラブルになってしまったというという事例も存在します。大きく話題となった近年のインシデント調査報告書でも「責任分界点をベンダー間、ユーザーとベンダー間でも確認しきれていないこともインシデントを大きくしてしまった原因である」［1］と述べられており、インシデント対策としてビジネス上のリスクを対策することの重要性が増していると考えられます。そこで本稿では、ビジネス上のやり取りの中でインシデントやそれに伴うトラブルに発展する可能性のあるリスクを「インシデントビジネスリスク」と呼称し、それを低減するためのポイントをご紹介します。

インシデントビジネスリスクとその対策

ここからは、インシデントビジネスリスクと、それを低減させるための対策をご紹介します。今回は「責任範囲が曖昧な契約を締結」「口頭での合意」の2つをご紹介します。

責任範囲が曖昧な契約を締結

運用・保守の契約時に、責任範囲が曖昧なまま契約をしてしまうと、図1のようにベンダーも発注元もどちらも作業を実施せず、インシデントが発生してしまうリスクがあります。経済産業省により発行されたDXレポート～ITシステム「2025年の崖」の克服とDXの本格的な展開～にも「契約に当たっては、ユーザ企業とベンダー企業との間の責任関係や作業分担等が明確になっていない。その結果、損害賠償請求の訴訟などのトラブルに発展するケースもあり、そのような場合、さらに多くの時間とコストを要することとなる」［2］と記載されており、責任分担の重要性が示唆されています。そのため、契約時には実施する作業内容を明確化するようにしましょう。運用・保守作業は曖昧な名称で実施されることもありますが、契約時には「パッチ適用」や「脆弱性情報の収集・提供」など作業を具体化し、ベンダーと発注元の間で可能な限り認識の相違が起こらないようにしましょう。
また、責任分担した作業範囲は運用保守の担当組織へ連携するなど、運用・保守設計書や手順書に確実に反映させるようにしましょう。契約で締結した責任範囲を履行するというのは当然のことのように感じますが、契約で合意した作業が漏れていたというインシデント事例は実際に存在するので注意しましょう。

口頭での合意

契約書文面の認識合わせや、お互いの責任範囲など、ベンダーと発注元で話し合った内容を口約束のみで合意してしまうと、後々図2のように言った言わないのトラブルに発展するリスクがあります。IPAより発行されている実務者のためのサプライチェーンセキュリティ手引書では、契約締結に関する記述の中で「現実的には既存の契約のまま進めたり、抽象的な記載になったりすることも大いに予想されるため、その時には記載内容がどのようなことを意図しているのか取引先とすり合わせ、議事録などに残すことで問題の発生を防ぐようにする」［3］と、すり合わせて合意した内容について記録を残すことがトラブル防止に繋がると記載されています。そのため話し合いで合意した内容は記録に残すようにしましょう。特に、打ち合わせ後の立ち話などで合意した場合は、後日メールやチャットなどで合意内容を改めて確認するようにしましょう。

まとめ

インシデントに関するビジネス上のトラブルが発生するリスク（インシデントビジネスリスク）とそれを低減させる際のポイントをご紹介しました。サイバーセキュリティだけでなく、責任範囲の明確化や合意内容の記録などもインシデントやトラブルを防ぐために重要なことです。これを機に、より重要視していただけると幸いです。

参考資料

執筆者の他の記事を読む