NIS2とは何ですか？
NIS2指令は、重要および中核的なセクターの組織に対する欧州連合の基本的なサイバーセキュリティ法です。EU域内で事業を行っている、またはEUにサービスを提供している場合、NIS2は現在のセキュリティ基準です。加盟国での対応がまだ追いついていない場合でも、今すぐこの指令の基準に沿って取り組むべきです。
その緊急性は理論上のものではありません。2021年には、Colonial Pipelineがransomware攻撃を受けて操業停止を余儀なくされ、DOJの発表では同社が約440万ドルの身代金を支払ったことが示されています。NIS2はこの種の混乱に対応するために設計されており、リスク管理への期待を正式化し、迅速な報告を義務付け、ガバナンスの失敗を取締役会レベルの問題にします。
NIS2は2024年10月に発効し、元のNIS指令（2016/1148）に代わるものとなりました。 European Commission's NIS2 pageでは、これを「より広い適用範囲、より明確なルール、より強力な監督手段を通じて、サイバーセキュリティに関するEU共通の意欲水準を引き上げるもの」と説明しています。実務上、NIS2は対象セクターを拡大し、インシデント報告の必須期限を導入し、上級管理職に個人的な説明責任を課します。
これらの変更が自社のセキュリティプログラムにとってなぜ重要なのかを理解するには、NIS2が具体的に何を要求しているのかを見ることが役立ちます。
NIS2の要件とは何ですか？
NIS2要件とは、EU全域の重要および中核的なセクターで事業を行う組織に対して、NIS2指令（Directive 2022/2555）の下で定められた必須のサイバーセキュリティ義務です。
これには、第21条に基づくリスク管理措置、第23条に基づくインシデント報告義務、第20条に基づくガバナンス上の説明責任が含まれます。これらの要件が一体となって、18のセクターにまたがる数千の組織に適用される拘束力のあるセキュリティ基準を形成します。
NIS2要件がサイバーセキュリティにとって重要な理由は何ですか？
ITインシデントは、多くの貸借対照表が吸収できるよりも速く、事業危機へと発展します。NotPetyaは2017年にそれを証明しました。Merckは後に、関連コストが約8億7,000万ドルに上ったことを Merck SEC filingで開示しています。NIS2は、それが自社の事例にならないようにするために存在します。 ガバナンス、対応準備、統制の有効性を証明する必要があり、監査担当者が求めるのは設定画面のスクリーンショットではなく、文書化された証拠です。
NIS2はチェックボックスを埋めるための取り組みではありません。具体的なcybersecurity risk-management措置を義務付け、厳しい期限内での構造化されたインシデント報告を要求し、監督不履行について取締役会に個人的な説明責任を負わせます。
この指令では、2層の分類も導入されています。Essential Entitiesは、監査や検査を伴う事前（ex-ante）監督の対象となります。Important Entitiesは、不遵守の証拠によって発動される事後（ex-post）監督の対象となります。どちらの層も、多額の金銭的制裁と経営責任に直面します。
NIS1からNIS2で何が変わりましたか？
自社組織が元のNIS指令の下で運用していた場合、両フレームワークの差は大きいものです。NIS2は小規模な改訂ではありません。適用範囲、執行、ガバナンス、報告にわたって義務を再構成しています。
- 適用範囲が大幅に拡大しました。 元の指令が対象としていたのは、エネルギー、運輸、銀行、金融市場インフラ、医療、飲料水、デジタルインフラの7セクターでした。NIS2ではこれが18セクターに拡大され、廃水、宇宙、ICTサービス管理、公共行政、郵便サービス、廃棄物管理、化学、食品生産、製造、研究が追加されました。 European Commissionは、NIS2が現在EU全域で数万の組織を対象としていると見積もっており、NIS1下の数百組織と比較して大幅な増加です。
- インシデント報告が標準化されました。 NIS1では、加盟国ごとに報告期限と基準を設定していたため、国境をまたいで不整合が生じていました。NIS2では、24時間以内のEarly Warning、72時間以内のIncident Notification、1か月以内のFinal Reportという3段階のプロセスを標準化し、EU全域で一律に適用します。
- 経営陣の説明責任が新たに導入されました。 NIS1では、セキュリティ義務は組織に課されていました。NIS2では第20条に基づき上級管理職に個人的責任が追加され、重大な違反の後に当局が経営幹部による管理機能の遂行を一時的に禁止できるようになっています。
- サプライチェーン義務が新たに導入されました。 NIS1には、体系化されたサプライチェーンセキュリティ要件はありませんでした。現在、第21条では、サプライヤーのsecurity posture、その依存関係、自社のNIS2要件に契約上拘束することの評価が求められます。
- 制裁が大幅に強化されました。 NIS1では制裁水準を各国の裁量に委ねていたため、大きなばらつきがありました。NIS2ではEU全域の最低上限が設定され、Important Entitiesには最大1,000万ユーロまたは全世界売上高の2%、Essential Entitiesには最大700万ユーロまたは全世界売上高の1.4%のいずれか高い方が適用されます。制裁の詳細な内訳については、 Commission's NIS2 FAQを参照してください。
したがって、最初の問いは、どのように準拠するかではありません。そもそも自社が適用対象なのかどうかです。
NIS2は誰に適用されますか？
NIS2の適用範囲は、セクター、規模、サービス上の役割によって決まります。この指令では、組織を分類するために2つの附属書を使用し、既定で適用対象となるかどうかを判断するために規模のしきい値を用います。
- Essential Entities（附属書I） は、極めて重要なセクターで事業を行います。具体的には、エネルギー（電力、石油、ガス、水素、地域暖房）、運輸（航空、鉄道、水運、道路）、銀行および金融市場インフラ、医療、飲料水、廃水、デジタルインフラ（DNSプロバイダー、TLDレジストリ、クラウドプロバイダー、データセンター、CDNs、トラストサービスプロバイダー、電子通信ネットワーク）、ICTサービス管理（マネージドサービスプロバイダーおよびマネージドセキュリティサービスプロバイダー）、公共行政、宇宙です。
- Important Entities（附属書II）は、その他の重要セクターで事業を行います。具体的には、郵便および宅配サービス、廃棄物管理、化学品の製造および流通、食品の生産および流通、医療機器、コンピューター、電子機器、機械、自動車、その他輸送機器の製造、デジタルプロバイダー（オンラインマーケットプレイス、オンライン検索エンジン、ソーシャルネットワーク）、研究機関です。
- 規模のしきい値 は、ほとんどの場合に適用されます。対象セクターで事業を行う、従業員50人以上または年間売上高1,000万ユーロ以上の組織は、既定で適用対象となります。中規模および大規模企業には、通常、自動的な免除はありません。ただし、小規模組織であっても、加盟国内で重要サービスの唯一の提供者である場合、その停止が重大な越境影響を及ぼす場合、または国家当局がシステミックリスクをもたらすと判断した場合には、EssentialまたはImportantに指定される可能性があります。規模基準の実務的な解説については、 NCSC Ireland NIS2 FAQを参照してください。
- EU域外の組織も自動的に免除されるわけではありません。EUで適用対象サービスを提供している場合、たとえ本社がEU域外にあっても、加盟国の代表者を指定し、その国のNIS2国内法に準拠する必要がある場合があります。自社の立場については、関連する各国の所管当局に確認してください。
適用範囲と分類が確定すると、本当の作業が始まります。以下が、NIS2が実施を求める内容です。
NIS2の主要なセキュリティ要件
NIS2要件は、必須のセキュリティ対策、インシデント報告、執行という3つの中核的な柱に分かれます。それぞれが、セキュリティプログラムの構成方法に直接影響します。
必須のセキュリティ対策（第21条）
対象となるすべての組織は、自社のリスクエクスポージャー、規模、社会的影響に見合ったサイバーセキュリティリスク管理措置を実装しなければなりません。第21条の要件は、いくつかの運用テーマに分類できます。
- ガバナンスと保証: リスク分析、セキュリティポリシー、継続的な有効性評価により、規制当局が確認できる証拠を伴って、統制が機能していることを示せるようにすること。
- 運用レジリエンス: incident responseプロセスに整合した、バックアップおよび災害復旧を含むインシデント対応と事業継続。
- セキュアなエンジニアリングと通信: システムの取得、開発、保守におけるセキュリティに加え、暗号技術およびencryptionポリシー、ならびに安全な通信。
- 人、アクセス、第三者: 基本的なサイバー衛生とトレーニング（経営陣を含む）、アクセス制御と資産管理、サプライヤーセキュリティ（ supply chain attacksへのエクスポージャーを含む）、および multi-factor authenticationなどの強力な認証。
これらの対策は、意図的に広範に設計されています。NIS2は特定の技術を規定せず、求めるのはリスクに見合った結果のみですが、それを達成する責任者が誰かについては解釈に委ねられていません。
経営陣の説明責任（第20条）
経営機関は、サイバーセキュリティ対策を承認し、その実装を監督し、cybersecurity trainingを完了しなければなりません。これらの義務は委任できません。 DLA Piper's NIS2 analysisによれば、上級管理職は「本指令に基づく義務違反について個人的責任を問われる可能性がある」とされています。
これが「何を」です。以降のセクションでは、「どのように」を扱います。すなわち、インシデント報告、ガバナンス、サプライチェーン義務、執行です。
NIS2におけるインシデント報告要件
第23条では、インシデントが発生した時点ではなく、インシデントを認識した時点から時計が動き始める3段階の必須報告プロセスを定めています。
- 第1段階: Early Warning。 1日以内に、初期分類を提出し、そのインシデントが違法または悪意ある行為に起因するように見えるかどうかを示し、潜在的な越境影響を評価し、調整のための連絡先情報を提供します。
- 第2段階: Incident Notification。 3日以内に、更新された重大度および影響分析、利用可能な場合はindicators of compromise (IoCs)、影響を受けたシステムおよびサービス、ならびに識別方法とタイムスタンプを提供します。
- 第3段階: Final Report。1か月以内に、根本原因分析、適用済みおよび継続中の対応措置の説明、越境影響評価を提出します。
第23条(3)における「重大なインシデント」とは、深刻な運用上の混乱、金銭的損失、または他者に対する有形もしくは無形の損失を引き起こした、または引き起こす可能性があるものです。「引き起こす可能性がある」というしきい値は、確認済みの被害だけでなく、潜在的影響も評価しなければならないことを意味します。この報告チェーンのいずれかの段階を逃すと、監督措置の対象となります。
報告義務は、インシデント後に何を伝達しなければならないかを定めます。以下のガバナンス要件は、そもそもそれらのインシデントを防止する責任を誰が負うのかを定義します。
ガバナンスおよび説明責任の要件
第20条は、サイバーセキュリティガバナンスを経営機関に直接課しています。取締役会メンバーおよび上級幹部は、自社組織のサイバーセキュリティリスク管理措置を承認し、その実装を積極的に監督しなければなりません。これらの責任は個人的なものであり、委任できません。
- 必須の経営陣トレーニング。 経営機関のすべてのメンバーは、サイバーセキュリティトレーニングを完了しなければなりません。第20条(2)では、リスクを特定し、サイバーセキュリティリスク管理の実務を評価し、それが自社組織の提供するサービスに与える影響を評価するのに十分なトレーニングであるべきと規定しています。これは一度限りのオンボーディング要件ではありません。トレーニングは進化するリスク環境に歩調を合わせる必要があり、規制当局は監査時に完了記録を確認できます。
- 監督不履行に対する個人的責任。 cybersecurity incidentが不十分なガバナンスに起因する場合、各国当局は個々の経営幹部に責任を問うことができます。制裁には、行政罰金、違反の公表、そしてEssential Entitiesについては管理機能の行使の一時禁止が含まれます。 Hogan Lovellsは、NIS2が「サイバーレジリエンスを、企業ガバナンスおよび取締役会レベルでの個人的説明責任の問題へと引き上げる」と指摘しています。
- 監督の文書化された証拠。 セキュリティプログラムがIT部門内だけで運用され、経営層レベルで目に見えるガバナンスの痕跡がない場合、監査担当者を満足させることはできません。規制当局が期待するのは次のようなものです。
- 署名者名と承認日が明記された、取締役会承認済みのセキュリティポリシー
- 残留リスクがどのように受容または対処されたかを示す、文書化されたリスク対応の意思決定
- ポリシーが静的ではなく更新されていることを証明する、定期的なレビューサイクルの記録
- 予算および人員配置を特定されたリスクに結び付ける、リソース配分の意思決定
これらの成果物のすべてを、氏名と日付に結び付けてください。要求時にこの証拠を提示できない場合、統制は事実上文書化されていないことになります。
ガバナンス上の説明責任は、内部の責任連鎖を確立します。NIS2は、その説明責任をサプライチェーンセキュリティ要件を通じて外部にも拡張します。
NIS2のサプライチェーンセキュリティ要件
第21条(2)(d)では、直接のサプライヤーおよびサービスプロバイダーを含むサプライチェーン内のセキュリティリスクを評価し、管理することが求められます。NIS2は第三者リスクを自社のリスクとして扱います。サプライヤーの弱点が自社環境での侵害を引き起こした場合でも、コンプライアンス義務は依然として自社にあります。
サプライヤー評価基準。 評価は表面的な質問票を超える必要があります。NIS2では、各サプライヤー固有の脆弱性、全体的な製品品質とcybersecurity practices、事業を行う法域、そしてサプライヤー自身のサプライチェーン依存関係を考慮することが期待されています。
契約上のセキュリティ要件。 サプライヤー契約には、NIS2に整合したセキュリティ条項を含める必要があります。少なくとも、契約では次を扱うべきです。
- 自社の報告期限を満たせるようにするための、インシデント通知義務
- サプライヤーのセキュリティ統制を検証できる監査権
- セキュリティパフォーマンスに結び付けられたサービスレベル契約
- 継続的な不遵守に対する契約解除条項
これらの条項により、コンプライアンス上の期待は非公式な了解事項ではなく、強制可能な約束になります。
ソフトウェアの透明性。 重要なソフトウェアコンポーネントについては、サプライヤーが提供するソフトウェア内のコンポーネントと依存関係を文書化するソフトウェア部品表（SBOM）を維持してください。SBOMsは、展開後に表面化する脆弱性の可視性を提供し、インシデント時のより迅速な影響評価を支援します。
多様化と継続性。 NIS2では、集中リスクの評価も期待されています。単一のサプライヤー障害で重要サービスが停止し得る場合は、継続計画を文書化し、可能であれば代替プロバイダーを特定してください。目的は、単なるコンプライアンスではなくレジリエンスです。
サプライチェーン義務は、コンプライアンスプログラムの外部境界を定義します。以下の執行メカニズムは、そのプログラムのいずれかの部分が不十分だった場合に何が起こるかを定めます。
NIS2の執行および制裁要件
NIS2は善意だけでは機能しません。監督権限、金銭的制裁、個人的責任を通じてコンプライアンスを執行します。
監督権限
Essential Entitiesは、第32条に基づく事前監督の対象となります。当局は、現地検査、無作為および臨時の監査、セキュリティスキャン、証拠提出要求を実施できます。また、拘束力のある指示を出し、違反の公表を命じ、CEOまたは法定代理人による管理機能の行使を一時的に禁止することもできます。
Important Entitiesは、第33条に基づく事後監督の対象であり、不遵守の証拠または兆候によって発動されます。これらの組織も同じ制裁構造の対象ですが、事前の無作為監査にはさらされません。いずれの場合も、金銭的な影響は重大です。
制裁構造
NIS2の制裁は、固定上限額または全世界売上高に対する割合のいずれか高い方に基づいて算定され、Essential Entitiesの方がImportant Entitiesよりも高い上限が設定されています。Commissionによる制裁枠組みの全体像については、 Commission's NIS2 FAQを参照してください。
経営責任は罰金にとどまりません。 Hogan Lovellsは、NIS2が「サイバーレジリエンスを、企業ガバナンスおよび取締役会レベルでの個人的説明責任の問題へと引き上げる」と指摘しています。
まだ公表されたNIS2の執行事例を報告した当局はありませんが、指令本文は期待される基準と監督手段を明確にしています。その枠組みを理解するだけでは十分ではありません。多くの組織が不足しがちな点は予測可能であり、そのすべては回避可能です。
NIS2要件を満たす際の一般的な課題
指令の文面自体は十分に明確です。つまずくのは実装段階です。以下は、Essential EntitiesとImportant Entitiesが最も頻繁に陥る誤りであり、どれ一つとして回避が難しいものではありません。
- NIS2を技術面だけの取り組みとして扱うこと。 NIS2は組織的な変革を要求します。第20条では、取締役会の承認、経営陣トレーニング、文書化された説明責任が求められます。規制当局は、これらすべての側面にわたるガバナンスの証拠を確認します。
- 一度限りのリスク評価を実施すること。 単発のリスク評価は、第21条に基づく継続的な有効性評価要件と矛盾します。ガバナンス議題の中に定期的な常設のリスクレビューを設け、リスク対応計画の更新を文書化する必要があります。
- 直接サプライヤーでサプライチェーンのデューデリジェンスを止めてしまうこと。 NIS2では、サプライヤー自身のサプライチェーン依存関係を評価することが求められ、第四者リスクに関する義務が生じます。 ENISA's implementation guidanceによれば、「第三者から供給されるネットワークおよび情報システムに対するリスクは…依然として組織自身の責任である」とされています。
- 不十分な文書化を維持すること。 存在していても監査時に示せない統制は、事実上存在しないのと同じです。リスク登録簿の各項目を、統制、担当、証拠に結び付けてください。規制当局から求められる前に、監査対応可能なコンプライアンスの説明資料を準備しておく必要があります。
- 1日の報告期限を過小評価すること。 Early Warningは、完全な影響評価が終わる前に提出する必要があります。インシデント対応ワークフローが認識後すぐに重大性を分類できない場合、期限を逃すか、不正確な情報を提出することになり、いずれも規制上のリスクを生みます。
これらの誤りの多くは、共通の根本原因を持っています。NIS2をプログラムではなくプロジェクトとして扱っていることです。以下のチェックリストは、後者ではなく前者として構築するための体系的な方法を示します。
NIS2要件実装チェックリスト
この8段階のチェックリストは、 ENISA's implementation guidanceに基づいています。
フェーズ1: 適用範囲とギャップ分析
- 附属書IおよびIIを用いて、自社組織の分類（essentialまたはimportant）を判断する
- 従業員数は単純な人数ではなく、Annual Work Unitsを用いて算定する
- すべての子会社および事業部門をNIS2の対象セクターにマッピングする
- 現在の態勢を第21条の要件に照らして評価する
- 適用範囲判断の根拠を文書化する
フェーズ2: ガバナンスおよびポリシーフレームワーク
- 文書化された説明責任を伴う取締役会レベルのサイバーセキュリティ責任を割り当てる
- 上級管理職への定期的な報告メカニズムを確立する
- 第21条に整合した情報セキュリティポリシーを作成または更新する
- 第23条の期限を満たすインシデント対応手順を策定する
- サイバーセキュリティリスク管理措置に対する正式な取締役会承認を文書化する
フェーズ3: 技術的統制の実装
- 最小権限の原則を用いたアクセス制御を導入する
- 重要システム全体にmulti-factor authentication (MFA)または継続的認証を実装する
- 保存中および転送中の機微データに対して暗号化を導入する
- すべての重要システムにわたって継続的なセキュリティ監視を確立する
- セキュリティ上の意思決定をリスク評価に結び付ける監査証跡を維持する
フェーズ4: サプライチェーンセキュリティ
- すべての直接サプライヤーおよびサービスプロバイダーを棚卸しする
- サプライヤーをNIS2の評価基準（法域、コンプライアンス、所有権、継続性、多様化）に照らして評価する
- サプライヤー自身のサプライチェーン依存関係を評価する
- 契約を更新し、NIS2のセキュリティ要件およびSLAを含める
- サプライヤー契約にインシデント通知、監査権、解除条項を含める
- 重要なソフトウェアコンポーネントについてソフトウェア部品表（SBOM）を維持する
フェーズ5: トレーニングと意識向上
- 第20条の義務と個人的責任を扱うNIS2トレーニングを取締役会メンバーに提供する
- 全従業員向けに役割ベースの意識向上プログラムを展開する
フェーズ6: インシデント対応準備
- 1日以内の初期通知能力を確立する
- 自国のComputer Security Incident Response Team (CSIRT)との関係を事前に構築する
- 3つすべての通知段階に対応するテンプレートを準備する
- テーブルトップ演習で手順を定期的にテストする
フェーズ7: 継続的な監視と改善
- 有資格者による定期的な内部監査を実施する
- リスク登録簿の各行を統制、担当、証拠に結び付ける
- 脅威インテリジェンスフィードを監視し、それに応じてリスク評価を更新する
フェーズ8: OT環境に関する考慮事項（該当する場合）
- OT資産向けに分離されたサイバーガバナンスを定義する
- IT環境とOT環境の間に network segmentationを実装する
- OTベンダー契約にNIS2コンプライアンス条項を含める
各フェーズを体系的に進めることで、準拠した基盤を構築できます。以下の実践は、それを長期的に維持するのに役立ちます。
NIS2要件を満たすためのベストプラクティス
- まず既存のフレームワークに整合させること。 すでにISO 27001またはNIST CSFの統制を維持している場合は、それらをNIS2の第21条要件にマッピングしてください。重複はかなりあります。ギャップ分析は、白紙の状態から始めるよりも、確立済みの基準から始める方が速く進みます。
- 必要になる前にインシデント報告ワークフローを構築すること。 今すぐ自国の所管当局とCSIRTを特定してください。3つすべての報告段階に対応するテンプレートを事前作成し、迅速な分類と提出をテストするテーブルトップ演習を実施してください。
- 経営責任を戦略的なテコとして活用すること。 第20条の個人的説明責任規定は、取締役会レベルで緊急性を生みます。コンプライアンスロードマップはrisk exposureの観点で提示してください。すなわち、不遵守のコストと、セキュリティプログラムに必要なものを定量化することです。取締役会は、第20条に基づくサイバーセキュリティ対策の承認を委任できません。この単一の法定事実が、予算と優先順位を獲得するための最も強力な手段になることがよくあります。
これらの実践は、NIS2の継続的監視要件に追随できるツールがあって初めて拡張可能になります。そこで適切なプラットフォームが価値を発揮します。監査証跡が後付けではなく、最初から組み込まれていることが重要です。
SentinelOneがNIS2要件をどのように支援するか
NIS2は、途切れることなく3つのことを求めます。継続的な監視、迅速なインシデント分類、そして統制が実際に機能していることの証明です。数十の分断されたツールにまたがる手作業では、その速度を維持できません。SentinelOneの SingularityTM Platformは、エンドポイント、アイデンティティ、クラウドセキュリティを1つのコンソールに統合し、NIS2の義務に直接対応するリアルタイムの可視性と自律的な対応機能を提供します。
- 継続的な監視と有効性評価（第21条）。 Singularity Platformは、すべてのエージェント上で常時稼働のBehavioral AIを実行します。シグネチャが存在する前に、挙動によって脅威を検出します。
- インシデント対応と報告（第21条および第23条）。 Storylineテクノロジーは、エンドポイント、クラウドワークロード、アイデンティティからのテレメトリを1つの攻撃タイムラインに統合します。重大なインシデントが発生したときには、Early Warningに必要なフォレンジックコンテキスト、IoCs、影響の証拠をすでに保持しています。多数のダッシュボードを横断して慌てる必要はありません。
- より迅速な調査（第21条）。 Purple AIは、平易な言葉による質問をテレメトリからの回答に変換し、調査の説明文も作成します。初期導入企業は、 脅威調査を最大80%高速化したと報告しており、これは「何かを見た」から、根拠ある規制上の分類へと迅速に移行する必要がある場面で重要です。
- アイデンティティの監督（第21条）。 Singularity Identityは、見出しになるような停止につながる前に、アイデンティティ起因の攻撃を阻止します。アクセス制御、アカウント衛生、インシデント封じ込めをカバーします。
- 事業継続と復旧（第21条）。 SentinelOneの1-Click rollbackは、ransomwareによる暗号化を巻き戻し、エンドポイントを感染前の状態に復元することで、バックアップ復元ワークフローのみに依存せずに復旧目標を支援します。
SentinelOneのデモを予約することで、各機能がNIS2プログラムにどのように対応するかを、統制ごとに確認できます。
重要なポイント
NIS2は、加盟国の国内法化がどの段階にあるかにかかわらず、すでに有効です。第21条に基づく明確なセキュリティ対策を定め、迅速かつ段階的なインシデント報告を義務付け、上級管理職に個人的な説明責任を課します。
Essential entitiesは、監査や検査を含む事前監督という追加の負担を負います。これらはいずれも、一度限りの認証で満たせるものではありません。コンプライアンスは継続的です。監視、サプライチェーン評価、文書化されたガバナンスを最新の状態に保つ必要があります。これをプログラムとして運用すれば、優位性になります。
よくある質問
NIS2（Network and Information Security Directive 2）は、エネルギー、運輸、医療、デジタルインフラなどの重要分野で事業を行う組織に対するサイバーセキュリティ要件を定めるEU規制です。
これは2024年10月に従来のNIS Directiveに置き換わり、対象事業体の範囲を拡大し、インシデント報告の義務的な期限を導入し、上級管理職に対する個人責任を設けました。組織は第21条に基づいて定義されたリスク管理措置を実施し、重大なインシデントを認識してから24時間以内に報告しなければなりません。
NIS2要件は、すべてのEU加盟国における指令の国内法化期限が経過した2024年10月17日に適用開始となりました。各国の国内法化法令がなお最終調整中である場合でも、指令の基準は確立されており、規制当局は対象事業体に対して、それに応じてセキュリティプログラムを整合させることを求めています。
対象範囲に含まれる組織は、すでに第21条の リスク管理 措置を実装し、第23条の報告能力を構築し、第20条に基づくガバナンス上の意思決定を文書化している必要があります。
NIS2は、対象事業体に対して3つのカテゴリーの義務を定めています。
- リスク分析、インシデント対応、事業継続、サプライチェーンセキュリティ、アクセス制御、暗号化、および継続的な有効性評価を対象とする、比例的なサイバーセキュリティのリスク管理措置（第21条）。
- 段階的なインシデント報告：24時間以内のEarly Warning、72時間以内のIncident Notification、および1か月以内のFinal Report（第23条）。
- 経営機関は、サイバーセキュリティ対策を承認し、監督し、それに関するトレーニングを受けることが求められ、監督上の不備について個人的責任を負います（第20条）。
はい。EUでサービスを提供している場合、本社が他地域にあっても適用対象となる可能性があります。重要なのは、加盟国で事業を運営しているか、または対象サービスを提供しているかどうか、そして特定のサプライヤーとしての役割を含むセクターおよび規模の基準を満たしているかどうかです。
不明な場合は、スコープ設定の前提を文書化し、サービスを提供している国の所管当局に期待事項を確認してください。
NIS2は、運用上の中断とサービスへの影響に重点を置いた段階的なフレームワークを採用しています。GDPRでは、個人データ侵害について、別個の期限内にデータ保護当局への通知が求められます。
インシデントがサービス中断と個人データの漏えいの両方を伴う場合は、両方の報告プロセスを調整し、事実関係の一貫性を保ち、各制度の下でのインシデント分類を正当化できるよう証拠を保全する必要があります。
待つべきではありません。指令の基準はすでに明らかであり、規制当局は、国内法とガイダンスの最終化が進む間も、対象組織が準備を進めることを期待しています。加盟国の法案を追跡し、管理策を指令本文に整合させ、何を実装したか、そしてその理由について変更ログを維持してください。
その文書化により、国内法化の過程で要件がわずかに変更された場合でも、誠実なガバナンスを実証できます。
一般に、小規模な組織はデフォルトの規模しきい値の対象外です。ただし、国家当局は、それらが不可欠なサービスの唯一の提供者である場合、またはその中断が重大な越境的影響を引き起こす場合には、より小規模な事業体を含めることができます。
しきい値未満の組織でも、対象組織に供給している場合は、契約上の義務やサプライヤー評価を通じて間接的なコンプライアンス圧力に直面する可能性があります。
DORAは、多くの金融機関に対する分野別法令として適用され、独自のインシデント分類および報告要件が含まれています。
両方の制度の対象となる場合は、各フレームワークの報告トリガー、期限、データ項目を対応付けた、統合された単一のワークフローを構築してください。実務上は、通常、最も厳しい期限に従って対応し、各提出先当局に合わせて提出内容を調整します。
NIS2は、適用範囲、執行、ガバナンス、報告の各面で、元のNIS指令を大幅に拡張しています。NIS1は7つのセクターを対象としていましたが、NIS2は18のセクターを対象としています。NIS1では加盟国が独自の報告期限を設定できましたが、NIS2ではEU全体で3段階のプロセスが調和されています。
NIS2ではさらに、第20条に基づく経営陣の個人責任、サプライチェーンセキュリティ評価の義務化、および最大1,000万ユーロまたは世界全体の売上高の2%までのEU全体における最低制裁上限が導入されています。NIS1にはこれらの規定はいずれもありませんでした。
