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が具体的に何を要求しているのかを見ることが役立ちます。
.jpg)
NIS2の要件とは何ですか?
NIS2要件とは、EU全域の重要および中核的な分野で事業を行う組織に対して、NIS2指令(Directive 2022/2555)の下で定められた必須のサイバーセキュリティ義務です。
これには、第21条に基づくリスク管理措置、第23条に基づくインシデント報告義務、第20条に基づくガバナンス上の説明責任が含まれます。これらの要件が一体となって、18分野にまたがる数千の組織に適用される拘束力のあるセキュリティベースラインを形成します。
NIS2要件がサイバーセキュリティにとって重要な理由
ITインシデントは、多くの貸借対照表が吸収できるよりも速く、事業危機へと発展します。NotPetyaは2017年にそれを証明しました。Merckは後に、関連コストが約8億7,000万ドルに上ったことを Merck SEC filingで開示しています。NIS2は、それが自社の事例にならないようにするために存在します。 ガバナンス、対応準備、統制の有効性を証明する必要があり、監査人が求めるのは設定画面のスクリーンショットではなく、文書化された証拠です。
NIS2はチェックボックスを埋めるための取り組みではありません。これは、具体的なサイバーセキュリティリスク管理措置を義務付け、厳しい期限内での構造化されたインシデント報告を要求し、監督不備について取締役会に個人的な説明責任を負わせます。
この指令では、2層の分類も導入されています。Essential Entitiesは、監査や検査を伴う事前的(ex-ante)監督の対象となります。Important Entitiesは、コンプライアンス違反の証拠によって発動される事後的(ex-post)監督の対象となります。どちらの層も、多額の金銭的制裁と経営責任に直面します。
NIS1からNIS2で何が変わったのか?
自社組織が元のNIS指令の対象であった場合、この2つの枠組みの差は大きいものです。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に整合したセキュリティ条項を含める必要があります。少なくとも、契約では次を扱うべきです。
- 自社の報告期限を満たせるようにするための、インシデント通知義務
- サプライヤーのセキュリティ統制を検証できる監査権
- セキュリティパフォーマンスに結び付いたサービスレベル契約
- 継続的なコンプライアンス違反に対する契約解除条項
これらの条項により、コンプライアンス上の期待は、非公式な了解ではなく、強制可能な約束になります。
ソフトウェアの透明性。 重要なソフトウェアコンポーネントについては、サプライヤーが提供するソフトウェア内のコンポーネントと依存関係を文書化したsoftware bills of materials(SBOMs)を維持してください。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を含める
- インシデント通知、監査権、解除条項をサプライヤー契約に含める
- 重要なソフトウェアコンポーネントについてsoftware bills of materials(SBOMs)を維持する
フェーズ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指令に置き換わり、対象事業体の範囲を拡大し、インシデント報告の義務的な期限を導入し、上級管理職に対する個人責任を設けました。組織は第21条に基づいて定義されたリスク管理措置を実施し、重大なインシデントを認識してから24時間以内に報告しなければなりません。
NIS2要件は、すべてのEU加盟国における指令の国内法化期限が到来した2024年10月17日に適用開始となりました。各国の国内法化法令がまだ最終調整中である場合でも、指令の基準線は確立されており、規制当局は対象事業体がそれに応じてセキュリティプログラムを整合させることを期待しています。
対象となる組織は、すでに第21条の リスク管理 措置を実施し、第23条の報告能力を構築し、第20条に基づくガバナンス上の意思決定を文書化している必要があります。
NIS2は、対象事業体に対して3つのカテゴリーの義務を定めています。
- リスク分析、インシデント対応、事業継続、サプライチェーンセキュリティ、アクセス制御、暗号化、および継続的な有効性評価を対象とする、比例的なサイバーセキュリティのリスク管理措置(第21条)。
- 段階的なインシデント報告:24時間以内の早期警告、72時間以内のインシデント通知、および1か月以内の最終報告(第23条)。
- 経営機関は、サイバーセキュリティ対策を承認し、監督し、それに関する訓練を受けることが求められ、監督上の不備について個人的責任を負います(第20条)。
はい。EUでサービスを提供している場合、本社が他地域にあっても対象範囲に含まれる可能性があります。重要なのは、加盟国で事業を運営しているか、または対象となるサービスを提供しており、特定のサプライヤーとしての役割を含むセクターおよび規模の基準を満たしているかどうかです。
不明な場合は、スコープ設定の前提を文書化し、サービスを提供している国の所管当局に期待事項を確認してください。
NIS2は、運用の中断とサービスへの影響に重点を置いた段階的なフレームワークを採用しています。GDPRでは、個人データ侵害について、別個の期限内にデータ保護当局へ通知することが求められます。
インシデントがサービスの中断と個人データの漏えいの両方を伴う場合は、両方の報告プロセスを調整し、事実関係の一貫性を保ち、各制度の下でのインシデント分類を正当化できるよう証拠を保全する必要があります。
待つべきではありません。指令の基準はすでに明らかであり、規制当局は、国内法とガイダンスが確定する間も対象事業体が準備を進めることを期待しています。加盟国の法案を追跡し、管理策を指令本文に整合させ、何を実装したか、その理由は何かの変更ログを維持してください。
その文書化により、国内法化の過程で要件がわずかに変更された場合でも、誠実なガバナンスを実証できます。
一般に、小規模な組織はデフォルトの規模しきい値の対象外です。ただし、国家当局は、それらが不可欠なサービスの唯一の提供者である場合、またはその中断が重大な越境的影響を引き起こす場合には、より小規模な事業体を含めることができます。
しきい値未満の組織であっても、対象範囲内の事業体に供給している場合は、契約上の義務やサプライヤー評価を通じて間接的なコンプライアンス圧力に直面する可能性があります。
DORA は、多くの金融機関に対する分野別法令として適用され、独自のインシデント分類および報告要件を含んでいます。
両方の制度の対象となる場合は、各フレームワークの報告トリガー、期限、データ項目を対応付けた、統合された単一のワークフローを構築してください。実務上は、通常、最も厳しい期限に合わせて対応し、各提出先当局に応じて提出内容を調整します。
NIS2は、適用範囲、執行、ガバナンス、報告の各面で、元のNIS指令を大幅に拡張しています。NIS1は7つのセクターを対象としていましたが、NIS2は18のセクターを対象としています。NIS1では加盟国が独自の報告期限を設定できましたが、NIS2ではEU全体で3段階のプロセスを調和しています。
NIS2ではさらに、第20条に基づく経営陣の個人的責任、サプライチェーンセキュリティ評価の義務化、および最大1,000万ユーロまたは世界全体の売上高の2%までというEU全体の最低制裁上限が導入されています。NIS1にはこれらの規定はいずれもありませんでした。

