規制上の開示ルールは、どれも同じ問いを、それぞれ違う名前で呼んでいます

私が昨年、銀行やフィンテック企業を対象としたEUの規制環境について取り上げた際、サイバーレジリエンス法(CRA)はすでに発効しているものの、法的な適用は2027年12月からになると指摘しました。CRAの大部分については今もその通りですが、報告義務に関しては事情が異なります。

2026年9月11日以降、デジタル要素を含む製品をEU市場向けに販売しているメーカーは、悪用が確認された脆弱性や深刻なインシデントを報告する義務を負うことになります。こうした組織は、欧州連合サイバーセキュリティ機関(ENISA)および該当する加盟国のコンピュータセキュリティインシデント対応チーム(CSIRT)に対し、24時間以内に早期警告を送付しなければなりません。その後、72時間以内により詳細な通知を行い、脆弱性の場合は14日以内、深刻なインシデントの場合は1か月以内に最終報告書を提出する必要があります。この新ルールは新製品だけでなく、すでに市場に出ている製品にも適用されます。

多くの規制対象組織にとって、これは新たな義務というより、すでに山積みになっている開示期限にもう一つ時計が加わっただけと言えるでしょう。しかし、規制が厳しい業界向けにソフトウェアを販売しているベンダーであれば、話はさらに厄介です。自社の通知そのものが、顧客側の時計を作動させる起点になってしまうからです。

期限ばかりが注目を集めがちです。取締役会向けのスライドに載せやすい要素だからでしょう。しかし、その期限は実のところ、一つの重要な判断の後に続くものにすぎません。そして、多くの組織が実際につまずくのは、まさにその判断の部分なのです。

とはいえ、その判断を明確かつ自信を持って下せるようになるには、まず期限そのものを乗り越えなければなりません。

増え続ける時計

グローバル企業が同時並行で管理している可能性のあるタイムラインの一部を挙げてみましょう。

  • 一般データ保護規則(GDPR)第33条。規制対象組織は、個人データ侵害を認識してから72時間以内に、遅滞なく監督当局に通知しなければなりません。ただし、その侵害が個人の権利および自由に対するリスクをもたらす可能性が低い場合は例外です。第34条により、個人へのリスクが高い場合は本人への通知も必要になります。
  • ネットワーク・情報システムセキュリティ指令2(NIS2)第23条。規制対象組織は、重大インシデントを認識してから24時間以内の早期警告を行い、72時間の時点でより詳細な通知、1か月の時点で最終報告書を提出しなければなりません。
  • デジタルオペレーショナルレジリエンス法(DORA)。規制対象組織は、インシデントを重大と分類してから4時間以内に初期通知を送付する必要があり、認識してから24時間を超えてはならないとされています。続いて72時間の時点で中間報告、1か月の時点で最終報告書を提出します。
  • 米証券取引委員会(SEC)フォーム8-K、項目1.05。組織は、重大なサイバーセキュリティインシデントを、重大性があると判断してから営業日4日以内に開示しなければなりません。
  • 重要インフラ向けサイバーインシデント報告法(CIRCIA)。米サイバーセキュリティ・インフラセキュリティ庁(CISA)は2026年9月にCIRCIAを最終化する見込みです。施行されれば、規制対象組織は対象となるサイバーインシデントが発生したと合理的に判断してから72時間以内に報告し、身代金を支払った場合は支払いから24時間以内に報告することが義務付けられる見通しです。
  • CRA。前述の通り、規制対象組織は2026年9月11日以降、24時間以内にENISAおよび該当する加盟国CSIRTへ早期警告を送付し、72時間以内により詳細な通知を行い、脆弱性の場合は14日以内、深刻なインシデントの場合は1か月以内に最終報告書を提出しなければなりません。

これだけで、非常によく似ているものの完全に同一ではない期限、通知先、様式を持つ規制体系が6つも存在することになります。ソフトウェアを提供し、米国で株式を上場している多国籍金融機関であれば、一つのインシデントがこのうち4つを同時に発動させることも十分にあり得ます。

とっさに思いつくのは、期限を一覧にしたマトリクスを作成し、インシデント対応チームに渡すことでしょう。それ自体は行う価値がありますが、開示に先手を打つ上で最も重要なステップではありません。

時計を読むことは、実は最も難しい部分ではありません

それぞれの規制体系群の時計が何によって起動するのかを、よく見てみましょう。実は、どれも同じ「起点となる出来事」から始まっているわけではないのです。

一つ目のグループ、すなわちDORAとSECでは、時計は自組織が下す判断によって起動します。DORAの4時間はインシデントを重大と分類した時点から、SECの営業日4日間はインシデントが重大であると判断した時点から始まります。どちらの時計も、インシデントの発見そのものを起点としていない点に注目してください。

二つ目のグループ、すなわちGDPR、CIRCIA、NIS2、CRAでは、時計は「認識」とともに動き出しますが、これは見た目ほど客観的な基準ではありません。GDPRの72時間は、侵害が発生した可能性が高いと結論づけるのに十分な情報を得た時点から始まります。CIRCIAの72時間は、インシデントが発生したと合理的に信じるに至った瞬間から始まります。NIS2は、重大インシデントを認識した時点から24時間の猶予を与えます。CRAは、自社製品の脆弱性が積極的に悪用されていると認識した時点から24時間の猶予を与えます。

いずれの場合も、時計が動き出すのは攻撃が始まった時点ではなく、それを知った時点です。ここからが、私にとってより興味深い部分です。

一つ目のグループでは、時計そのものは短いものの、インシデントが重大かどうかを判断するまでは動き出しません。二つ目のグループでは、時計はより早く動き出しますが、それでも同様の判断を下すまでは何も届け出ることができません。つまり、閾値をめぐる問いが、そもそも報告するかどうかを左右するのです。

いずれにせよ、本当に重要な作業はどの時計が動き出す前に行われるものであり、規制当局はその明らかな抜け穴をすでに塞いでいます。SECは重大性の評価を発見後に不当な遅延なく行うよう求めており、時間稼ぎの余地はありません。DORAは分類のタイミングにかかわらず、認識から24時間という上限を課しています。GDPRは72時間の期限を過ぎた場合、その理由を説明するよう求めています。

じっくり考えるために時計を止めることは許されません。迅速に決断するか、なぜそれができないのかを説明するか、いずれかを選ぶしかないのです。

規制枠組み 報告期限 何が時計を起動させるか
GDPR 72時間 侵害が発生したことの発見
NIS2 24時間 「重大」インシデントの認識
DORA 4時間 インシデントが「重大」と判定された時点
CRA 24時間 製品内の脆弱性が積極的に悪用されていることの発見
CIRCIA 72時間 インシデントが発生したという合理的な確信
SEC 営業日4日 インシデントが「重大」と判定された時点

同じ判断、異なる4つのラベル

法律用語をそぎ落としてみると、これまで挙げた規制体系はすべて同じ問いを投げかけていることが分かります。「このインシデントは、組織外の誰かに知らせる必要があるラインを越えているか?」という問いです。それぞれが、そのラインに当てはめる独自の言葉を選んでいるにすぎません。

SECは「重大(material)」と呼びます。DORAは「重大(major)」と呼びます。NIS2は「重要(significant)」と呼びます。CRAは「深刻(severe)」、脆弱性の場合は「積極的に悪用されている」と呼びます。GDPRに至っては名前を付けず、自然人の権利および自由に対するリスクという形で説明し、本人への通知が必要となる「高リスク」についてはさらに高いハードルを設けています。

つまり、結局のところ一つの判断に対して、4つの言葉と一つの説明が用意されているわけです。

セキュリティチームは、実はこれとまったく同じ判断を日常的に行っています。それを「優先順位付け」と呼び、線を引いて最も重要な事柄をトリアージしています。規制上のバージョンは同じ行為を、時計が動き、法的な結果が伴う状況で行うものであり、賭けられているものという点では大きな違いがありますが、行為の性質自体は変わりません。

このように捉え直すと、実務上の意味合いが見えてきます。開示の閾値判断を、法務チームが関与し始めた時点で始まる作業として扱っていては、確実に対応が遅れます。なぜなら、判断材料となる事実は別の場所にあるからです。一方で、これを「聴衆を伴う優先順位付け」――罰金や場合によっては禁錮刑を科すこともある聴衆ではありますが――として捉えるなら、チームがすでに持っている力を活かして、事前に備えることができます。

DORAは計算力を試してきます

この作業が即興でこなせない理由を知りたければ、DORAの分類ルールを読むのが一番です。規制技術基準のもとでは、インシデントが「重大」と判定されるのは重要なサービスに影響が及んだ場合に限られ、さらに残る6つの基準のうち少なくとも2つを満たす必要があります。

この基準には、影響を受けた顧客や取引先の数、レピュテーションへの影響、攻撃の継続時間とサービス停止の期間、データ損失の範囲、地理的な広がり、経済的影響が含まれます。影響を受けたサービスの利用者のうち10%を超える顧客に影響が及んだ場合、通常はこの特定の閾値をクリアすることになります。再発に関する規定もあります。個々には重大と言えないインシデントであっても、6か月以内に少なくとも2回発生し、明らかに同一の根本原因を共有し、全体として基準を満たす場合には、一つの重大インシデントとしてカウントされます。

これを法的要件としてではなく、実務上の要件として改めて読んでみてください。4時間以内に、何人の顧客が影響を受けたか、どのくらいの期間続いたか、どの法域にまたがるかを把握する必要があります。そして、どのようなデータが流出したかも把握しなければなりません。これは構成情報のスナップショットだけから下せる判断ではありません。スナップショットは環境がどのように構築されていたかを教えてくれますが、その内部で何が、どの順序で、誰に対して起きたのかまでは教えてくれないのです。

ここに、コンプライアンスをめぐる議論がしばしば的を外す原因があります。この業界は長年かけて、ある特定の時点で管理策が存在していたことを証明する力を磨いてきました。ほとんどのフレームワークがそれを評価対象としており、監査を通過する上では確かに役立ちます。しかし、これまで取り上げた6つの規制体系のうち、管理策が存在していたかどうかを問うものは一つもありません。すべてが、実際に何が起きたのかを問うているのです。

これらはまったく異なる問いであり、求められる証拠もまったく異なります。

正確な事実関係の整理に本当に必要なもの

6つの規制を共通項に絞り込むと、次のような要素が浮かび上がります。

  • 何がアクセスされた、あるいは影響を受けたのか。関係するデータの性質を特定できる程度の詳細さで。
  • インシデントがいつ発生したか。実際に特定した時点ではなく、通常それより早い、始まった時点も含めて。
  • 誰が影響を受けたか。人数、そしてしばしば法域別に。
  • 悪意によるものかどうか。NIS2は違法行為について明示的に問うており、CRAは積極的に悪用されている脆弱性と理論上のものとを区別しているためです。
  • それに対して何を行ったか、そして何が未対応として残っているか。

証拠を集める際に心に留めておくべき言葉は「正確」です。後から撤回しなければならない早期の届け出は、成果とは言えません。これらの規制当局の多くが段階的な報告方式を採用しているのは、時間の経過とともに理解が深まっていくことを当局側も想定しているからにほかなりません。とはいえ、早期警告そのものも防御可能な内容でなければならず、最終報告書はそれと整合性が取れていなければなりません。

特にCRAについて言えば、「積極的に悪用されている」という表現は現在進行形の事実主張であることに注意してください。静的スキャナーは製品に脆弱性が存在することを教えてくれますが、誰かが現在それを利用しているかどうかまでは教えてくれません。この違いは、CRAの報告義務にとって重要です。自社システム内で何かが積極的に悪用されているかどうかを判断するには、本番環境における異常な挙動を観測する必要があり、これは脆弱性一覧とはまったく種類の異なる証拠を要求します。

開示は規制当局だけで終わりません

期限マトリクスの陰でしばしば見落とされるもう一つの側面は、規制当局だけが聴衆ではないという点です。ベンダーである場合、顧客にも契約上の通知権があり、その顧客の多くは規制対象組織であるため、自社が何かを伝えた瞬間に顧客側の時計が動き出します。これはソフトウェアサプライチェーンと組織セキュリティがもたらす下流への波及効果です。

個人データを扱っている場合、GDPR第34条により本人への直接通知が義務付けられます。また、上場企業であれば、投資家への通知も必要です。これらの聴衆はそれぞれ異なるレベルの技術的詳細を求めており、それぞれが自分たちに伝えられた内容を他の相手への説明内容と照らし合わせます。そしてその一部始終が報道されることもあり得ます。

これは最終的にはコミュニケーションの問題ですが、その土台となるのは同じものです。すなわち、一つの事実関係を、異なるタイムラインに沿って複数の聴衆に一貫して伝えることです。このプロセスを即興でこなそうとする組織は、規制当局への届け出内容と顧客宛のメールの内容が食い違うという事態に陥りがちで、これは遅延そのものよりも深刻な問題になりかねません。

だからこそ、この議論をセキュリティチームだけで完結させてはいけません。インシデント発生前に、法務、プロダクト部門のリーダー、サードパーティリスク管理部門を同じ場に集めることは、地味に見えて最も価値のある備えです。実践に勝るものはありませんから、合同でテーブルトップ演習を行うことも検討する価値があります。結局のところ、届け出書類に署名するのはこうした人々であり、緊迫した局面が訪れる前に、事実をどう整理するかの設計に関わってもらうべきなのです。

時計が動き出す前に、何をすべきか

将来の規制上の開示に先手を打つために(そして、十分に備えたとしても、そうした計画があくまで理論上のものにとどまることを願っていますが)、次の四半期が始まる前に実行しておくべき5つの行動項目があります。

  1. 自社に適用される規制をマッピングし、最も厳しいものから対応する:優先順位付けは今も最も効率的なアプローチであり、これは何年も前から私が伝えてきたアドバイスと変わりません。
  2. 分類方法を文書化し、テストする:DORAは社内での分類プロセスを、SECは重大性評価プロセスを求めています。どちらも、文書として存在するだけでなく、実際にリハーサルされた手順としてこそ価値を発揮します。誰も一度も実行したことがなければ、必ず壁にぶつかるはずです。
  3. 実際に項目を埋めてみる:あり得そうなインシデントを一つ想定し、今日自社が収集しているデータだけを使って、何が影響を受けたか、いつ、誰のデータが関わったかに答えてみてください。そこで見つかったギャップこそが、最も差し迫ったコンプライアンス上のリスクです。
  4. 誰が決めるのかを決めておく:4時間の時計は、スケジュール調整の行き違い一つで簡単に破綻します。分類を行う担当者と、その代理を指名し、委員会の承認を待たずに行動できる権限を与えておきましょう。
  5. 対応と開示の両方をリハーサルする:多くのテーブルトップ演習は、インシデントが封じ込められた時点で終了します。すべての届け出が期限内に提出された時点で終わるテーブルトップ演習を実施してください。

6つの規制体系はいずれも同じ問いを投げかけています。ただ、それぞれが異なる言葉でそれに答えているだけです――重大(material)、重大(major)、重要、深刻。判断の拠り所は同じ証拠、すなわち実際に何が、誰に対して、いつ起きたかです。しかし、いざ時計が動き出したその瞬間、自分の名前を添えられるだけの確信を持って、その判断を下せるでしょうか。

その確信は、インシデントが起きるずっと前から築いておく必要があります。そしてそれは、自社の環境で実際に何が動いているのかをリアルタイムで把握できていることから生まれます。構成が正しかったこと、あるいは直近の監査時点で管理策が存在していたことしか証明できないというのは、重大インシデント発生から4時間が経過し、規制当局と影響を受けた顧客が回答を待っている状況においては、致命的な弱点になります。

翻訳元: https://webflow.sysdig.com/blog/every-regulatory-disclosure-rule-asks-the-same-question-each-calls-it-something-else

本記事は webflow.sysdig.com の記事を翻訳・要約したものです。