EUにユーザーがいるソフトウェア企業が、2026年9月11日までに整えておくべきインシデント対応体制

EUの「サイバーレジリエンス法(Cyber Resilience Act、Regulation (EU) 2024/2847。以下CRA)」は2024年11月20日に官報掲載され、すでに発効しています。
原文：REGULATION (EU) 2024/2847 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL

of 23 October 2024

ただし義務の適用は段階的で、実務上まず効いてくるのが2026年9月11日から適用される第14条の報告義務です。本体の適用(セキュリティ要件への適合やCEマーキングなど)は2027年12月11日からですが、脆弱性・インシデントの報告義務だけが1年以上前倒しで始まります。

つまり、EU市場にソフトウェアを提供している企業にとって、この記事を書いている時点で残された準備期間は2か月弱です。本稿では、CRAの条文に基づいて「何を」「いつまでに」「どこへ」報告する必要があるのか、そして今から何を準備すべきかを整理します。

そもそも自社は対象なのか

CRAの対象は「デジタル要素を備えた製品(products with digital elements)」で、EU市場で商業活動として提供されるソフトウェア・ハードウェアが広く含まれます(第2条・第3条)。

有償のパッケージソフトやモバイルアプリはもちろん、無償配布でも収益化の意図があれば「商業活動」と見なされ得ます。

注意したいのは、クラウドサービスの扱いです。SaaSそのものは原則としてCRAではなくNIS2指令の領域ですが、製品の機能に不可欠な遠隔データ処理(リモートデータプロセッシング)はCRAの対象に含まれます(第3条(2)、前文(11)(12))。

たとえばモバイルアプリが自社開発のAPIやバックエンドなしには機能しない場合、そのバックエンド部分も製品の一部として扱われます。「うちはクラウドだからCRAは関係ない」と即断するのは危険です。

また、報告義務を負う「製造者(manufacturer)」には、自社ブランドで製品を市場に出す企業が該当します(第3条(13))。EU域内に拠点がない日本企業でも、EU市場に製品を提供していれば対象です。

第14条:2段階+最終報告の3ステップ

第14条が定める報告義務は、大きく2種類の事象を対象にしています。

1つ目は「積極的に悪用されている脆弱性(actively exploited vulnerability)」です。悪意ある第三者が実際にその脆弱性を悪用したという信頼できる証拠がある場合を指します(第3条(42))。善意のセキュリティリサーチャーによる検証・報告目的の発見は、この義務的報告の対象ではありません(前文(68))。

2つ目は「製品のセキュリティに影響する重大インシデント(severe incident)」です。第14条(5)で「重大」の基準が定義されており、(a) 機微または重要なデータ・機能の可用性・真正性・完全性・機密性を害する(またはその能力がある)場合、(b) 製品またはユーザーのシステムへの悪意あるコードの導入・実行につながった(またはその能力がある)場合が該当します。前文(68)では、製造者のリリースチャネルに攻撃者がマルウェアを混入させたようなケース、つまりサプライチェーン攻撃が例示されています。

どちらの事象も、報告のタイムラインは共通の構造です。

起点は「製造者が認知した時点(becoming aware)」です。侵害発生時点ではありませんが、社内で検知してから経営判断を待って時計が止まるわけでもありません。24時間という期限は、休日や時差を考えると実質的に「検知したその日のうちに報告プロセスが回り始める体制」を要求していると考えたほうがよいでしょう。

どこに報告するのか

報告先は、ENISA(欧州連合サイバーセキュリティ機関)が運営する単一報告プラットフォーム経由で、担当のCSIRT(コーディネーターとして指定されたCSIRT)とENISAに同時に届く仕組みです(第14条(1)(3)、第16条)。

どの加盟国のCSIRTに報告するかは、第14条(7)で決まっています。EU域内に主たる拠点(サイバーセキュリティに関する意思決定が主に行われる拠点)があればその加盟国。EU域内に拠点がない場合は、①最も多くの製品を扱う授権代理人の所在国 → ②輸入者の所在国 → ③流通業者の所在国 → ④最も多くのユーザーがいる加盟国、という順序で決まります。

日本企業の場合、この判定を有事になってから始めると確実に24時間を超過するので、平時に「自社の報告先はどこか」を確定させておく必要があります。

当局への報告だけでは終わらない:ユーザーへの通知義務

第14条(8)は、悪用されている脆弱性や重大インシデントを認知した製造者に対し、影響を受けるユーザー(必要に応じてすべてのユーザー)への通知と、ユーザー側で取れる緩和策・是正措置の案内を求めています。製造者がこれを適時に行わない場合、CSIRTが代わりにユーザーへ情報提供することもできる、と明記されている点は押さえておくべきです。自社が黙っていても、当局経由で公になり得るということです。

違反した場合

第64条により、第13条・第14条の義務および附属書Iの必須要件への違反には、最大1,500万ユーロまたは全世界年間売上高の2.5%のいずれか高い方の制裁金が科され得ます。その他の義務違反は最大1,000万ユーロまたは2%、当局への虚偽・不完全な情報提供は最大500万ユーロまたは1%です。なお、零細・小企業については24時間の早期警報期限の徒過に対して制裁金を科さないこととされています(前文(120))。

制裁金以上に効くのは、市場監視当局による製品の販売停止・回収命令の可能性です。EU市場からの締め出しは、多くの企業にとって金銭的制裁より痛手になります。

既存の報告義務との関係:GDPR上の「立場」をまず確定する

CRAの報告は、既存の義務に「上乗せ」される点に注意が必要です。そして個人データ侵害が絡む場合、自社の動き方はGDPR上の立場、つまりは管理者(controller)なのか処理者(processor)なのかによって大きく変わります。ここが曖昧なまま有事を迎えると、報告の宛先と期限を取り違えます。

• 自社が管理者に当たるケース
   コンシューマー向けにアプリやサービスを直接提供し、エンドユーザーの個人データの取扱いの目的と手段を自社で決定している場合が典型です。

  この場合、個人データ侵害を認知したら、GDPR第33条に基づき監督機関へ原則72時間以内に報告する義務を自社が直接負います。さらに、侵害が個人の権利・自由に高いリスクをもたらすおそれがある場合には、第34条によりデータ主体本人への通知も必要です。

• 自社が処理者に当たるケース

  B2BのSaaSやソフトウェアで、顧客企業(=管理者)の指示に基づいてその従業員や顧客の個人データを処理している場合です。

  このとき監督機関への72時間報告の義務を負うのは管理者である顧客側で、処理者である自社の法定義務は、第33条(2)に基づき侵害を認知したら不当な遅滞なく管理者に通知することです。

  「72時間はうちには関係ない」と読めそうですが、実務はそう甘くありません。顧客との間で締結しているDPA(データ処理契約)には、法定の「不当な遅滞なく」よりも短い具体的な通知期限(24時間、48時間など)が定められていることが多く、顧客が自らの72時間を守るために、処理者への時間的要求は法定基準より厳しくなりがちです。

  自社が結んでいるDPAの通知条項を棚卸しし、最も短い契約期限を自社の実質的なSLAとして手順書に反映しておくことが、処理者としてのインシデント対応の出発点になります。

なお、同じ企業が製品ラインや機能によって管理者と処理者の両方の顔を持つことは珍しくありません(例:B2B SaaSの本体では処理者、自社マーケティングや課金情報の取扱いでは管理者)。侵害されたデータがどちらの立場で扱っていたものかによって手順が分岐するため、データマッピングの段階で立場を紐づけておく必要があります。

そして重要なのは、CRAの義務はこのGDPR上の立場と無関係に発生するという点です。 CRA第14条の報告義務は「製造者」に直接かかるため、「うちは処理者だから当局対応は顧客がやってくれる」という整理はCRAでは通用しません。処理者であっても、自社製品のセキュリティに影響する重大インシデントや悪用されている脆弱性があれば、CSIRT/ENISAへの報告義務を自社が負います。

結果として、1つのインシデントで次の報告トリガーが並走し得ます。

• CRA第14条:製品のセキュリティに影響 → CSIRT/ENISAへ24時間・72時間・最終報告(立場を問わず製造者の義務)

• GDPR第33条:個人データ侵害 → 管理者なら監督機関へ72時間以内/処理者なら管理者へ遅滞なく(+DPAの契約期限)

• GDPR第34条:高リスクの個人データ侵害 → 管理者としてデータ主体へ通知

• NIS2指令:自社がクラウドサービス提供者などNIS2の対象事業者に該当する場合の報告義務

それぞれ報告先も期限も様式も異なるため、インシデント対応手順書の中で「この事象はどの法令・どの契約のどの報告義務に該当するか」を判定するチェックポイントを設けておかないと、現場は確実に混乱します。

今からやるべき準備

条文から逆算すると、9月11日までに最低限そろえておきたいのは次の5点です。

1. 報告先の確定

   前述の第14条(7)のルールに沿って、自社の報告窓口となるCSIRTがどの加盟国のものかを特定し、手順書に明記しておきます。

2. インシデント分類基準へのCRA定義の組み込み

   既存のインシデント対応プロセスに「actively exploited vulnerabilityに該当するか」「第14条(5)のsevere incidentに該当するか」の判定基準を追加し、該当した瞬間に24時間タイマーが動き出すことを、判断権限を持つ人まで含めて周知しておきます。深夜・休日でも判断が回るエスカレーションルートの設計が肝です。

3. 第三に、報告テンプレートの事前準備

   24時間以内に書ける情報は限られています。早期警報・72時間通知・最終報告のそれぞれで求められる項目(第14条(2)(4))をテンプレート化しておけば、有事に「何を書けばいいのか」から議論を始めずに済みます。

4. ユーザー通知の段取り

   影響を受けるユーザーの特定方法、通知手段(製品内通知・メール・Webサイト掲載)、公表文面の承認フローを決めておきます。GDPRのデータ主体への通知(第34条)と重なるケースも想定し、法務・広報を巻き込んだ体制にしておくのが現実的です。

5. GDPR上の立場の整理とDPAの棚卸し

    製品・機能ごとに自社が管理者・処理者のどちらに当たるかをデータマッピングに紐づけて明確化し、顧客と締結済みのDPAの侵害通知条項(通知期限・通知方法・記載事項)を一覧化します。CRAの24時間、GDPRの72時間、DPAの契約期限を1枚のタイムラインに重ねてみると、有事に最初の数時間で何を並行して動かす必要があるかが具体的に見えてきます。

なお、2027年12月の本格適用に向けては、報告体制に加えて、脆弱性ハンドリングプロセス全般(協調的脆弱性開示ポリシー、SBOMの整備、原則5年以上のサポート期間の設定、無償セキュリティアップデートの提供、ユーザーが連絡できる単一窓口の設置など。第13条・附属書I)への対応も必要になります。報告義務対応は、その全体像の中の最初の一歩と位置づけるのがよいでしょう。

おわりに

CRAの報告義務は「72時間」という数字だけ見るとGDPRと似ていますが、その前に24時間の早期警報があること、報告対象が個人データ侵害ではなく製品のセキュリティ事象であること、報告先がデータ保護当局ではなくCSIRT/ENISAであること、そして管理者・処理者という立場に関係なく製造者に直接義務がかかることなど、中身はかなり異なります。GDPR対応の体制をそのまま流用できるものではありません。

期限が迫っているとはいえ、上記の5点は大がかりなシステム投資を伴うものではなく、既存のインシデント対応プロセスへの追記と関係者への周知が中心です。まずは自社製品がCRAの対象かどうかの確認と、報告先CSIRTの特定から着手することをおすすめします。

そこでIncident Lake

ここまで見てきたとおり、CRA以降のインシデント対応で問われるのは、対応そのものの速さに加えて「記録し、期限内に報告できる状態を保つ」能力です。

24時間以内の早期警報を出すには認知の瞬間からタイムラインが記録されている必要がありますし、最終報告で求められる根本原因や実施済み・進行中の対策の記述を、対応中にSlackや各種チケットに散らばった情報から後追いで掘り起こすやり方では、期限との勝負になりません。GDPRのDPA上の顧客通知が並走すれば、なおさらです。

私たちが開発しているインシデントマネジメント特化のAgentic AI「Incident Lake」は、まさにこの課題に向き合うプロダクトです。Slackでの対話やJiraなど既存ツールに散らばる対応中の情報を一つのインシデントレコードに集約し、タイムライン、重大度の判定とその変更履歴、対応タスク、影響範囲を時系列で残していきます。

本稿で挙げた「事象がCRAのsevere incidentに該当するかの判定」「24時間・72時間・1か月という複数の期限管理」のような手順はSOPチェックリストとして組み込んで対応の抜け漏れを防げますし、蓄積された記録をもとに報告書のドラフトを作成できるため、最終報告に向けた文書化の負荷を大きく下げられます。

使うほどに組織固有の判断基準や過去の教訓が蓄積され、AIによる支援の精度が上がっていく設計です。

CRAの報告義務対応を「その場しのぎの手作業」ではなく「仕組み」にしたいとお考えでしたら、ぜひ Incident Lake をご覧ください。

本稿はRegulation (EU) 2024/2847の条文(2024年11月20日官報掲載版)に基づく一般的な情報提供であり、法的助言ではありません。個別の適用判断については、EU法に詳しい弁護士等の専門家にご相談ください。