DORA、NIS2、PCI DSS、SECの検出義務

規制に基づく検出義務は、セキュリティの成果として DORA, NIS2, PCI DSS v4.0.1、および SEC開示ルールが、組織が検出、監視、ログ記録、開示を通じて達成し、証明しなければならないことを要求しています。

これらの4つの制度のいずれも特定の検出ツールを規定していません。DORAだけが検出を独立した義務として名指ししています。各フレームワークは結果を要求しています：適時の検出、継続的な監視、体系的なログ記録、または適時の開示です。検出能力は証拠が示唆するものであり、規制者が名前で義務付けたコントロールではありません。

MITRE ATT&CK は、その証拠を攻撃者行動カテゴリごとに監査人がクエリできる構造に編成しています。 ATT&CK は、DORA、NIS2、PCI DSS、SECルールでは要求されていません。

DORAは法の特別法、つまり一般法に優先する特定の法律です。 DORA第1条(2) はNIS2第4条の目的のためのセクター特定の欧州連合の法令であることを明らかにしています。DORAの範囲内にある金融機関は、ICTリスク管理およびインシデント報告にDORAを適用します。NIS2は銀行自体ではなく、銀行の非金融サプライチェーンに及びます。

PCI DSS 4.0とDORAの下での義務をサポートする検出証拠は何ですか？

いずれも PCI DSS v4.0.1 とDORAは、検出を証拠を立てる手段として扱っています。規制は、検出が監視義務に必要な記録を生成するかどうかを問うものであって、検出が存在するかどうかを問うものではありません。

五つの証拠クラスがその証明を提供します。どちらの制度もそれらを実質的に要求しています。

証拠クラス	PCI DSS v4.0.1	DORA
収集したログソース	要件10: 監査ログを取得し、履歴を保持する	第9条(1): ICTシステムのセキュリティと機能を継続的に監視し管理する; 第10条(3): ユーザーアクティビティ、ICT異常、およびICT関連のインシデントを監視する
ルールの展開、所有者付き	要件11: 侵入検知/防止、変更検出のインプレース	第10条: 多層のコントロール、定義されたアラート閾値と基準
発動の証拠	要件10: ログをレビューし、制御システムの失敗を検出する	第10条: アラートが発動し、責任のあるスタッフに届く
変更履歴	要件11: 変更及び改ざんの検出	第17条: ルートケース追求を含む、文書化されたインシデント管理プロセス
日付付きのカバレッジレポート	要件10.5.1: 監査ログの履歴を少なくとも12か月保持し、最新の3か月を即時利用可能にする (PCI SSCドキュメントライブラリ)	第10条(1): 第25条に従って検出メカニズムを定期的にテストする

PCI DSS v4.0は2024年12月31日に廃止され、PCI DSS v4.0.1が唯一のアクティブなバージョンです (PCI SSC、2024年6月)。51の将来的に有効となる要件は2025年3月31日に発効しました (PCI SSC、2024年8月)。上記のH2は検索者のクエリに合わせて「PCI DSS 4.0」を使用しています。

展開されても監査記録を生成しない検出ルールは、評価者には見えません。

DORA、NIS2、PCI DSS 4.0、SEC開示ルールが実際に課す検出および監視義務とは何ですか？

各制度は、ツールの義務付けではなく、結果の義務付けを課しています。以下の表はそれぞれの義務を、その義務が示唆する検出証拠にマッピングしています。

制度	条文または要件	義務	暗示される検出証拠
DORA	第9条(1)、第10条(3)	ICTシステムのセキュリティと機能の継続的な監視と管理 (第9条(1)); ユーザー活動、ICT異常、ICT関連インシデントの監視 (第10条(3))	ログソースの在庫、継続的収集記録
DORA	第10条(1)、(2)	異常な活動を検出する; インシデント対応に責任を持つスタッフへの自動アラートを含むアラート閾値と基準を持つ多層の制御; 第25条に基づく定期的な検出メカニズムのテスト	所有者付きのルール在庫、閾値の根拠、アラートが対応者に到達した証拠、テスト記録
DORA	第17条	ICT関連のインシデントの検出、管理、および通知、原因追求のフォローアップ付き	プロセス文書、インシデントごとの検出と処理記録
DORA	第19条 + 補足規則 (EU) 2025/301	重大なインシデントを担当機関に報告する	重大と分類されたインシデントの初期通知を4時間以内に、かつ意識した後24時間以内に行い、中間報告を初期通知後72時間以内に、最終報告を中間報告の1か月以内に行うタイムスタンプ付き検出および分類記録
NIS2	第21条(2)	リスク管理措置（ポイント(b)）と措置の有効性を評価するためのポリシー（ポイント(f)）; 監視およびログ記録義務は以下の実施規則にあり、第21条自体には含まれていない	文書化された措置、検出記録
NIS2	第23条(4)	重大なインシデントの通知	意識した後24時間以内に早期警告を、72時間以内にインシデント通知を、インシデント通知の1か月後までに最終報告を行う
NIS2	実施規則 (EU) 2024/2690	第1条(1)の11種類のエンティティに対する監視とログ記録 (附属書第3.2項)、管理されたセキュリティサービスプロバイダを含む。	対象エンティティのための明示的なログ記録
PCI DSS v4.0.1	要件10	システムコンポーネントとカードホルダーデータへのすべてのアクセスのログと監視	監査ログは少なくとも毎日レビューされる (10.4.1)、自動ログレビュー (10.4.1.1)、保持されたログ履歴 (10.5.1)、クリティカルなセキュリティ制御システムの障害が検出され、報告され、迅速に対応される (10.7、10.7.2) PCI SSCドキュメントライブラリ
PCI DSS v4.0.1	要件11	システムとネットワークのセキュリティを定期的にテストする	侵入検知と防止記録 (11.5.1)、変更検出アラート (11.5.2)、支払いページの変更および改ざん検出アラート (11.6.1)
SEC	8-K項目1.05	重要なインシデントについて、重大性判断後4営業日以内に開示する必要があり、この判断自体は発見後、不合理な遅延なく行わなければならない (フォーム8-K、項目1.05)	重大性判断プロセス、インシデント検出記録
SEC	S-K項目106	年次10-K (項目1C) で重要なサイバーセキュリティリスクの評価、特定、および管理プロセスを説明する	検出能力を含む文書化されたリスク特定プロセス

DORA (規則 (EU) 2022/2554は2025年1月17日から直接適用されています。その報告時計が補足規則 (EU) 2025/301: 重大と分類されたインシデントの初期通知を4時間以内に、かつ認識後24時間以内に行い、中間報告を初期通知後72時間以内に、最終報告を中間報告の1ヶ月以内に行います。最初の時計は検出と分類から始まるため、インシデントのタイムライン自体が監査可能な証拠です。

NIS2 (指令 (EU) 2022/2555) は各加盟国の法改正を通じて適用され、直接適用されません。移行期限は2024年10月17日（第41条）でした。2025年5月7日、欧州委員会は 19の加盟国に理由付き意見を送りました完全な法改正を通知しなかった件で、2026年7月8日にアイルランド、スペイン、フランス、オランダを司法裁判所に提訴しました。 2026年1月20日に委員会は改正案を提案しました NIS2 (COM(2026) 13) の第21条(5) を触れ、ランサムウェアの段落を第23条に追加し、第21条(2) 措置と第23条(4) 報告時計は変更がありません。購入者が直面する義務は、自国の法改正に依存します。

実施規則 (EU) 2024/2690、2024年10月18日に発行され、2024年11月7日に施行されるこの規則は、DNSサービスプロバイダ、TLD名レジストリ、クラウドコンピューティング、データセンター、コンテンツデリバリーネットワーク、管理サービスおよび管理されるセキュリティサービスプロバイダ、オンラインマーケットプレース、検索エンジン、ソーシャルネットワーキングプラットフォーム、信頼サービスプロバイダに対する明確な監視とログ要件 (附属書第3.2項) を設定します。これはMSSPを顧客の義務とは別個に規制対象として捉えます。

PCI DSS v4.0.1 が唯一のアクティブなバージョンです。要件10と11は検出と監視義務を伴っています。

SEC (最終ルール公表33-11216、2023年7月26日に採択された) は開示とガバナンスのルールであり、検出コントロールの義務付けではありません。検出は派生的です: 登録者は、インシデントを検出および評価する能力がない限り、重要性を判断できません。項目1.05へのコンプライアンスは、大半の登録者では2023年12月18日から、小規模報告企業では2024年6月15日から要求されています。

監査人は通常どのような証拠を見て、検出システムが効果的であることを確認するのですか？

五つの証拠クラスがこれらの制度全体で繰り返されます。カバレッジの割合だけでは、どれも証拠にはなりません。

#	証拠クラス	それが証明するもの
1	収集したログソース	どのテレメトリーがどのシステムから取り込まれ、収集が継続されているかを証明します。監査人は監視が稼働しているかどうかをチェックします。一度設定されたかどうかではありません。
2	展開されたルール	配置された検出ルール、義務をサポートし、適用可能な場合はその ATT&CK 技術にマップされ、所有者がいます。
3	発動の証拠	実際またはエミュレートされたイベントでの発火したルールとアラートが対応者に到達したこと。展開されたことがないルールは監査人の観点では未テストです。
4	変更履歴	誰がいつ、なぜルールを変更したのか：バージョン管理、レビューの追跡、および変更ごとの文書化された理論。
5	日付付きのカバレッジレポート	日付付きの点検時点報告書で、傾向とカバレッジの現状を証明可能にします。日付のない報告書は、カバレッジが存在していた時点に関する証拠を提供しません。

ATT&CKは、攻撃者行動によるクロスウォークとしてこの証拠をクエリ可能にします。技術IDは既存の証拠（データソース、展開されたルール、発火記録）に付けられたメタデータですので、証拠が行動カテゴリによって取得可能になります。ATT&CKはこれらの4つの制度のいずれにも要求されていません。これらが課す義務に対して証拠を組織化します。

誰が、いつ、なぜルールを変更したのかを監査人に示せますか？

コードとしての検出がこれに答えます。すべての検出ルールは、ソース管理でバージョンされたアーティファクトです。変更履歴には作成者、タイムスタンプ、レビューの承認、変更の理由が記録されています。

このトレイルは特定の義務にマッピングされます：

DORA第17条はルートケースフォローアップ付きの文書化されたインシデント管理プロセスを要求します。

PCI DSS v4.0.1 要件11には変更と改ざんの検出が含まれています。

SECの項目106は、登録者がそのリスク識別プロセスを記述することを期待しています。

各フレームワークは、組織が検出ルールを単なるルールの有無ではなく、管理対象品として統治しているかどうかを問うものです。

運用テスト: 前四半期に発火したルールがある場合、そのチームはその完全な系譜を生成できますか？誰が作成し、誰がレビューし、いつ最後に修正され、なぜ、どの義務にマッピングされ、どの技術に対応しているか。ルールをバージョン化したコードとして管理する検出コンテンツプラットフォームは、通常の運用の副産物としてこのトレイルを生成します。

コンソール内でバージョン管理なしでルールが編集される場合、監査人には現在のルールステートに関する出所がありません。コードとしての検出のガバナンスは、構築においてその曖昧さを除去します。

検出カバレッジはどのようにしてコンプライアンスの項目になるのでしょうか？

検出能力は通常、SOCマネージャーの目に見える形で運用予算に組み込まれており、CFOの目には見えません。カバレッジを取締役会の議論にする3つの事実があります。

報告の時計は検出から始まります。DORAの4時間分類時計とSECの4営業日重大性時計はどちらも、組織が検出または認識したときに始まります。より速い検出がコンプライアンスのタイムラインの始まりです。

検出証拠は監査可能です。上記の五つの証拠クラスが監査人がレビューする内容です。それらを生成するのには時間と人員がかかり、チームが独自のルールを構築するか、検出コンテンツソースを購読するかは関係ありません。

カバレッジまでの時間は測定可能です。公開される技術と組織の自環境での検証済み検出発火の間の窓は追跡可能です。

エンジニアリングチームは、ヘッドカウントとツールの観点から検出容量を要求します。コンプライアンスチームは、証拠生産の観点からそれを要求します。第2のフレーミングは、取締役会がすでに追跡している規制義務に対する検出の支出を結びつけます。

SIEM姿勢監査は、監査人が求めるカバレッジマップを生成します：MITRE ATT&CKにマッピングされたルール、同じマトリックスにマッピングされたログソース、および計画付きのリストされたギャップ。

営業部門へのお問い合わせ

これが当てはまらない場合

いくつかの制限が適用されます。

すべての義務が検出にマッピングされるわけではありません。 SEC項目1.05は、特定のコントロールではなく開示を要求します。NIS2第21条およびDORAは、サプライチェーンセキュリティ、事業継続性、およびアクセス管理を含んでいます。これらのいずれもATT&CKの技術にマッピングされません。ATT&CKは、検出と監視のサブセットを組織化するものであり、フルコンプライアンスの表面をカバーするものではありません。

NIS2の改正は不完全です。 加盟国の法改正が施行されていない場合、NIS2第21条および第23条は地域的には実施されません。2026年1月に提案された改正は、記事21または23を再ナンバリングしていません。

SECルールは論争中です。 The 撤回請願書 SECファイル番号4-856に基づく項目1.05に対して、2025年5月22日に5つの銀行および証券業界の団体によって提出されたものは未解決のままです: 2026年9月21日現在、SECは項目1.05に対して修正を提案しておらず、請願者はSECの規制S-Kレビューの下で2026年4月のコメントレターで要請を更新しました。 2024年5月21日のステートメント当時事業法部長を務めていたエリク・ゲディング氏によって発表されたもので、項目1.05は、登録者が重要であると判断したインシデントに予約され、別の項目（項目8.01など）で他のインシデントの開示を奨励しました; 2024年6月24日にコンプライアンスと開示解釈を続けました。

副要件番号はv4.0.1に従う。 ここに引用されているPCI DSSの副要件（10.4.1、10.4.1.1、10.5.1、10.7、10.7.2、11.5.1、11.5.2、11.6.1）はv4.0.1のナンバリングを使用しています。標準自体は PCI SSCドキュメントライブラリにあり、要件10.7.2はすべてのエンティティに対して2025年3月31日から適用されます。

ATT&CKはクロスウォークであり、規制義務ではありません。 検出をATT&CK技術にマッピングすることにより、証拠を整理します。それは何らかの規制義務を果たすものではなく、ここで検討されているフレームワークのいずれもそれを要求していません。

DORAは金融機関にとって法の特別法です。 DORAの範囲にある銀行は、自己のICTリスク管理とインシデント報告にNIS2第21および23条を追加適用しません。NIS2は銀行の非金融サプライチェーンに及びますが、銀行自体のICT運用には及びません。

監査証拠チェックリスト: 検出義務
 
1. 収集されたログソース

 [ ] インジェストされたテレメトリソースの在庫

   [ ] 継続的収集の証拠（瞬間的ではない）

   [ ] 各ソースがカバーするシステム、資産、および

       義務にマッピングされている 

2. 展開されたルール

 [ ] 名付けられた所有者がいる検出ルール在庫

   [ ] 各ルールがサポートする規制義務にマッピングされている

   [ ] 各ルールが適用可能な場合はATT&CK技術にマッピングされている

       （クロスウォーク、規制で要求されません）

   [ ] 根拠が文書化されたアラート閾値
 
3. 発火された証拠

 [ ] 実際またはエミュレートされたイベントでルールが発火した証拠

   [ ] アラートが指定された対応者に到達した記録

   [ ] 検出メカニズムのための日付付きテスト記録

       （DORA第10条）

4. 変更履歴
   
 [ ] 各検出ルールのバージョン管理

       （コードとしての検出）

   [ ] 作成者、レビュアー、タイムスタンプ、および変更ごとの根拠

   [ ] レビューと承認の追跡

   [ ] 変更と改ざんの検出記録

5. 日付付きのカバレッジレポート

 [ ] 日付付きの点検時点報告書

   [ ] 優先技術セットに対するカバレッジ測定、

       フルATT&CKマトリックスではなく

   [ ] 時間経過に伴うカバレッジの傾向データ

   [ ] 環境ごとの報告（単一の集計数値ではなく）

制度特有の項目

   [ ] DORA: 根拠が文書化されたアラート閾値

       （第10条）

   [ ] DORA: 報告時計でのインシデントタイムスタンプ

       （分類から4時間 / 意識から24時間、

       中間72時間、1か月最終）

   [ ] NIS2: 転記された国内法にマッピングされた証拠、

       指令のテキストだけではない

   [ ] PCI DSS v4.0.1: 該当するログ保持

       副要件

   [ ] SEC: 文書化された重要性判断プロセス

       （項目1.05）

   [ ] SEC: 取締役会の監督と管理役割の記述

       （項目106）

注記

- ATT&CKはこの証拠を整理するために使用されるクロスウォークです。

  DORA、NIS2、PCI DSS、またはSECルールでは要求されません。

- DORAは法の特別法です: DORAの範囲にある銀行はDORAを適用します、

  ICTリスク管理のためにNIS2第21および23条を適用しません。

- PCI DSS v4.0.1が唯一のアクティブなバージョンです

  （v4.0は2024年12月31日に廃止されました）。

この文書におけるすべての規制の詳細は

  公開前にciso-cto-smeによって検証されます。

FAQ

PCI DSS 4.0とDORAの下での義務をサポートする検出証拠は何ですか？

両制度とも、検出ツールが導入されているだけでなく、継続的な検出と監視の証拠を要求します。五つの証拠クラスは: 収集されたログソース、所有者付きで展開された検出ルール、それらのルールが発火する証拠、バージョン管理された変更履歴、そして日付付きのカバレッジレポートです。MITRE ATT&CKは、この証拠を攻撃者行動カテゴリごとに組織化します。ATT&CKはどちらのフレームワークでも要求されていません。

監査人は、検出システムが効果的であることを確認するためにどのような証拠を探しますか？

監査人は、五つの証拠クラスを探します: 収集されたテレメトリーソースとその収集が継続的であること、義務とATT&CK技術にマッピングされた所有者付きの検出ルール、実際またはエミュレートされたイベントでのルール発火の証拠、各ルールのバージョン管理された変更履歴、そして日付付きの点検時点カバレッジレポート。支持記録のないカバレッジ割合だけでは証拠になりません。

検出をMITRE ATT&CKにマッピングすることで、規制当局を満足させることができますか？

ATT&CKは攻撃者行動による検出証拠を組織化するためのクロスウォークです。それは証拠を技術ごとにクエリ可能で報告可能にします。それ自体が何らかの規制義務を果たすものではありません。DORA、NIS2、PCI DSS、およびSECルールは、運用の証拠: 監視、検出、ログ、および開示を求めています。ATT&CKはその証拠を組織化します。ここで検討されたフレームワークのいずれもそれを要求していません。

DORAおよびNIS2の下でのインシデント報告のタイムラインはどのようになっていますか？

DORAの下では、補足規則 (EU) 2025/301 が主要インシデントの時計を設定しています: 重大と分類されたインシデントについて4時間以内に（認識後24時間以内）初期通知を行い、中間報告を初期通知後72時間以内に行い、最終報告を中間報告の1か月以内に行います。NIS2の下では、重大なインシデントは認識後24時間以内に早期警告を行い、72時間以内にインシデント通知を行い、インシデント通知の1か月後までに最終報告を行います。どちらのタイムラインも検出から始まり、検出のタイムスタンプ自体が監査可能な記録です。

SOC Primeのカスタムコンテンツエンジニアリングは、SIEMまたはEDRに検出を実装し、その目的、機能、使用法の詳細なドキュメントを提供します。

営業部門へのお問い合わせ