Falco Feedsは、オープンソースに焦点を当てた企業に、新しい脅威が発見されると継続的に更新される専門家が作成したルールにアクセスできるようにすることで、Falcoの力を拡大します。
本文の内容は、2026年9月18日に Crystal Morinが投稿したブログ (URL) を元に日本語に翻訳・再構成した内容となっております。
銀行やフィンテック企業を対象とした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)。規制対象事業者は、インシデントを重大(major)と分類してから4時間以内に初期通知を送付しなければならず、いかなる場合も認知から24時間を超えてはなりません。続いて72時間以内に中間報告、1か月以内に最終報告を提出します。
- 米国証券取引委員会(SEC)Form 8-K、Item 1.05。企業は、サイバーセキュリティインシデントを重要(material)と判断してから4営業日以内にその重要インシデントを開示しなければなりません。
- 重要インフラのためのサイバーインシデント報告法(CIRCIA)。サイバーセキュリティ・インフラセキュリティ庁(CISA)は、2026年9月にCIRCIAを最終化する見通しです。施行されれば、規制対象事業者は、対象となるサイバーインシデントが発生したと合理的に信じた時点から72時間以内に報告し、ランサム(身代金)を支払った場合はその支払いから24時間以内に報告することが義務付けられる見込みです。
- CRA。前述の通り、規制対象事業者は、2026年9月11日以降、ENISAおよび該当する各国のCSIRTに対し24時間以内に早期警告を送付し、72時間以内により詳細な通知を行い、脆弱性の場合は14日以内、重大インシデントの場合は1か月以内に最終報告書を提出しなければなりません。
これで6つの規制体制が並びました。それぞれ期限や通知先、書式は非常に似ていますが、まったく同じではありません。ソフトウェアを提供し、米国に上場している多国籍金融機関で単一のインシデントが発生した場合、これらのうち4つが同時に発動することも十分にあり得ます。
直感的には、期限のマトリクスを作成してインシデント対応チームに渡したくなるものです。それ自体は行う価値がありますが、開示に先手を打つために取るべき最も重要なステップではありません。
時計を読むことは、最も難しい部分ではない
各フレームワーク群の時計が何によって動き出すのかを、よく見てみましょう。すべてが同じ「イベント」を起点として動き出すわけではないからです。
第一のグループ、つまりDORAとSECでは、時計は自社が下す判断によって動き出します。DORAの4時間は、インシデントを重大(major)と分類した時点から始まり、SECの4営業日は、インシデントを重要(material)と判断した時点から始まります。どちらの時計も、インシデントの発見そのものを起点としていない点に注目してください。
第二のグループ、つまりGDPR、CIRCIA、NIS2、CRAでは、時計は「認知」した時点から動き出します。これは実際よりも客観的に聞こえる基準です。GDPRの72時間は、侵害がおそらく発生したと結論づけるのに十分な情報を得た時点から始まります。CIRCIAの72時間は、インシデントが発生したと合理的に信じた瞬間から始まります。NIS2では、重大なインシデントを認知した時点から24時間が与えられます。CRAでは、自社製品の脆弱性が実際に悪用されていると認知した時点から24時間が与えられます。
いずれの場合も、時計は攻撃が始まった時点ではなく、あなたがそれを知った時点で動き出します。ここからが、私が特に興味深いと感じる部分です。
第一のグループでは、時計は短いものの、インシデントが重要(material)か重大(major)かを判断するまでは動き出しません。第二のグループでは、時計はより早く動き出しますが、それでも同様の判断を下すまでは何も提出できません。しきい値に関する問いが、そもそも報告が必要かどうかを決めるのです。
いずれにせよ、本当に重要な作業はどの時計が動き出す前にも発生しており、規制当局は明白な抜け穴をすでに塞いでいます。SECは、発見後不当に遅延することなく重要性の評価を行うことを求めているため、時間を余分に買うことはできません。DORAは、分類のタイミングにかかわらず、認知から24時間という上限を全体に課しています。GDPRは、72時間の期限に間に合わなかった場合、その理由の説明を求めます。
時計を止めてじっくり考える、ということはできません。速く判断するか、できない理由を説明するか、どちらかです。
同じ判断、4つのラベル
法律用語を取り払ってみると、上記の規制体制はすべて同じ問いを投げかけています。「このインシデントは、社外の誰かに知らせる必要があるラインを越えているか?」それぞれの体制が、そのラインに当てはめる言葉を独自に選んでいるだけなのです。
SECはこれを「重要(material)」と呼びます。DORAは「重大(major)」、NIS2は「著しい(significant)」と呼びます。CRAは「深刻(severe)」、脆弱性の場合は「実際に悪用されている(actively exploited)」と呼びます。GDPRはそもそも名前を付けず、自然人の権利および自由に対するリスクという形で説明し、本人への直接通知にはより高い基準である「高いリスク」を設けています。
つまり、最終的には一つの判断に対して、4つの言葉と一つの記述があるということです。
セキュリティチームは、すでにこの判断をつねに下しています。それを「優先順位付け」と呼び、最も重要な事柄にラインを引いてトリアージしています。規制上のバージョンは、時計が動き、法的な結果が伴う中で行われる同じ行為であり、重みの違いはあっても種類の違いではありません。
このように捉え直すことには、実務上の意味があります。開示のしきい値を、法務チームが関与した時点で始まる作業として扱えば、対応は遅すぎることになります。事実は別の場所にあるからです。一方、これを「観客付きの優先順位付け」として扱えば——その観客が罰金や禁固刑を科す可能性を持つとしても——チームが既に持っている力を使って、事前に備えることができます。
DORAは、あなたの計算能力を試す
これがなぜ即興ではこなせないのか、それを知りたければDORAの分類ルールを読むだけで十分です。規制技術基準によれば、インシデントが重大(major)とされるのは重要なサービスに影響が及んだ場合のみであり、さらに残る6つの基準のうち少なくとも2つを満たす必要があります。
基準には、影響を受けた顧客または取引相手の数、レピュテーションへの影響、攻撃の継続時間とサービス停止時間、データ損失の範囲、地理的な広がり、経済的影響が含まれます。影響を受けたサービスを利用する顧客の10%を超えるインシデントは、一般的にこのしきい値をクリアします。さらに再発ルールもあります。個別には重大とはいえない別々のインシデントも、6か月以内に少なくとも2回発生し、明らかな根本原因を共有し、全体として基準を満たす場合は、1件の重大インシデントとして数えられます。
これを、法的要件としてではなく運用要件として、もう一度読んでみてください。4時間以内に、どれだけの顧客が影響を受けたか、どのくらいの期間、どの法域で、を把握する必要があります。さらに、どのデータが持ち出されたのかも把握しなければなりません。これは、構成のスナップショットだけから下せる判断ではありません。スナップショットは環境がどのように設定されていたかを教えてくれますが、その中で何が、どの順序で、誰に対して起きたのかまでは教えてくれません。
ここが、コンプライアンスに関する議論がしばしば的を外す部分です。業界はこれまで、ある特定の時点で管理策(コントロール)が存在することを証明する能力を磨くことに、長年注力してきました。ほぼすべてのフレームワークがそれを評価し、監査に通るためには有用です。しかし、これまで見てきた6つの規制体制のうち、管理策が存在したかどうかを問うものはひとつもありません。すべてが、何が起きたのかを問うているのです。
これらはまったく異なる問いであり、必要となる証拠もまったく異なります。
正確な事実の把握に、実際には何が必要か
6つの規制を共通点にまで絞り込むと、次のようになります。
- 何がアクセスされたか、または影響を受けたか。関係するデータの性質を特定できる程度の詳細さで。
- インシデントがいつ発生したか。開始時点も含め、それは通常、実際に特定した時点よりも早い。
- 誰が影響を受けたか。件数、そして多くの場合、法域ごとに。
- 悪意によるものかどうか。NIS2は違法行為について明示的に問い、CRAは実際に悪用されている脆弱性と理論上の脆弱性を区別しているため。
- それに対して何を行ったか、そして何が残っているか。
証拠を集める際に心に留めておくべき言葉は「正確」です。撤回を余儀なくされる早期の報告は、勝利ではありません。これらの規制当局のいくつかが段階的な報告制度を設けているのは、まさに当局側も理解が徐々に深まっていくことを想定しているからですが、それでも早期警告は説明可能なものでなければならず、最終報告書はそれと整合していなければなりません。
CRAに特有の点として、「実際に悪用されている」は現在に関する事実の主張である、ということに注目してください。静的スキャナーは、自社製品に脆弱性が存在することは教えてくれますが、誰かがそれを現在利用しているかどうかまでは教えてくれません。この違いは、CRAの報告義務にとって重要です。システム内の何かが実際に悪用されているかどうかを判断するには、本番環境における異常な振る舞いを観測する必要があり、それは脆弱性インベントリとは根本的に異なる種類の証拠です。
開示は、規制当局だけで終わらない
期限のマトリクスの中で見落とされがちな点として、規制当局は唯一の相手ではないということがあります。ベンダーであれば、顧客側にも契約上の通知権があり、その多くは規制対象事業者であるため、あなたが何かを伝えた時点で顧客側の時計が動き出します。これは、ソフトウェアのサプライチェーンと組織のセキュリティが持つ、下流への影響なのです。
個人データを取り扱っている場合、GDPR第34条により本人への直接通知が求められ、上場企業であれば投資家への通知も必要です。これらの相手はそれぞれ異なるレベルの技術的な詳細を求め、それぞれが、あなたが他の相手に伝えた内容と自分に伝えられた内容を比較します。そしてそのすべてが、最終的にニュースになる可能性もあります。
これは最終的にはコミュニケーションの問題ですが、その土台は同じです。すなわち、一つの事実のパターンを、異なるタイムラインの中で複数の相手に一貫して伝えるということです。このプロセスを即興でこなす企業は、規制当局への提出書類と顧客向けメールの内容が一致しないという事態に陥りがちで、これは遅れること以上に悪い問題になり得ます。
だからこそ、この議論はセキュリティチームだけで完結させるべきではありません。インシデント発生前に、法務担当者、プロダクトのリーダーシップ、サードパーティリスク機能を同じ場に集めることは、決して華やかではありませんが、最も価値の高い準備です。一緒にテーブルトップ演習を実施することも検討する価値があります。練習は完璧をつくるからです。最終的に、提出書類に署名するのはこれらの人々であり、緊迫した状況になる前に、事実がどのように集められるかの設計に関わってもらうべきです。
では、時計が動き出す前に何をすべきか?
将来の規制開示に先手を打つために(そして、十分に準備をした上でも、その計画がずっと理論上のものであり続けることを願いつつ)、次の四半期が始まる前に実行しておく価値のある、5つのアクション項目を挙げます。
- 自社に適用される規制をマッピングし、最も厳しい基準に合わせて構築する。優先順位付けは今も最も効率的な道であり、これは私が何年も前から伝えていたアドバイスです。それは今も変わっていません。
- 分類の方法論を文書化し、テストする。DORAは社内の分類アプローチを求め、SECは重要性評価のプロセスを期待しています。どちらも、文書としてよりも、実際に予行演習された手順として機能する方がはるかに有用です。誰も一度も実行したことがなければ、必ず壁に当たります。
- 実際に項目を埋めてみる。起こりうる一つのインシデントを想定し、現在収集しているデータだけを使って、何が影響を受けたか、いつ発生したか、誰のデータが関係していたかに答えてみてください。そこで見つかったギャップこそが、最も差し迫ったコンプライアンス上のリスクです。
- 誰が決めるのかを決める。4時間の時計は、スケジュールの衝突には耐えられません。分類を行う担当者と、その代理を指名し、委員会の承認を待たずに行動できる権限を与えてください。
- 対応と開示の両方を予行演習する。多くのテーブルトップ演習は、インシデントが封じ込められた時点で終了します。すべての該当する提出書類が期限内に提出された時点で終了する、テーブルトップ演習を実施してください。
6つの規制体制は、いずれも同じ問いを投げかけています。ただ、それぞれが異なる言葉——重要(material)、重大(major)、著しい(significant)、深刻(severe)——でその問いに答えているだけです。あなたの判断は、同じ証拠、つまり実際に何が起き、誰に対して、いつ起きたのかに依存します。しかし、時計が動き出した瞬間に、自分の名前を懸けてその判断を下せるだけの確信を持てているでしょうか?
その確信は、インシデントが発生するはるか前から築いておく必要があり、それは自社の環境で実際に何が動いているのかをリアルタイムで把握できることから生まれます。構成が正しかったこと、あるいは前回の監査時点で管理策が存在していたことしか証明できないというのは、重大インシデントの発生から4時間が経過し、規制当局と影響を受けた顧客が回答を待っている状況では、致命的なギャップになります。
