重要なポイント
DORAは2024年から段階的に施行され、金融機関全体のデジタルセキュリティ体制が対象となります
監査人はDORA準拠状況を被監査会社の内部統制評価に組み込む必要があり、これが監査範囲に影響します
DORAに関連する不適切な開示または監査証拠不足は、検査で最も指摘を受けやすい領域です
どのように機能するか
DORAはEU諸国の金融機関に対し、ICT関連リスク、サイバーセキュリティ対策、および重大なサイバーセキュリティインシデント報告の要件を定めています。監査人の観点からは、ISA 315.34に基づいて、クライアントのICT環境と運用リスクを被監査会社の重要なリスクとして識別しなければなりません。
DORAは単なるコンプライアンス要件ではなく、被監査会社の内部統制プロセス全体に影響します。クラウドサービス、API、サードパーティーシステムを通じたICT依存度の高い企業では、DORA準拠状況が監査範囲と実証的手続の範囲を大きく左右します。特にISA 402（監査事務所の委託機能の監査）が関連する場合、クラウドサービスプロバイダーのDORA準拠状況を確認することが重要です。
監査人は計画段階（ISA 300.A26）において、クライアントのICT環境、サイバーセキュリティインシデント履歴、DORA実装状況を被監査会社のリスク評価プロセスの一部として文書化する必要があります。
実例：Nexus Financial Services N.V.
被監査会社： オランダの中堅決済サービス提供企業。年間売上€28M。IFRS報告企業。
設定： クライアントはクラウドベースの決済プラットフォームを提供し、取引データの90%がアマゾン ウェブ サービス（AWS）上に保存されています。2024年度監査計画の策定時に、DORAの段階的施行が決定されました。
ステップ1：リスク識別
ISA 315.34に基づいて、被監査会社のICT環境をリスク評価の一部として把握します。Nexus社では、決済処理システムの障害が直接的に売上認識と売掛金に影響することを確認します。
監査調書への記載：「ICT依存度が高く、決済システム障害が売上認識に直結する。DORA準拠状況は重要な監査リスク。」
ステップ2：DORAコンプライアンス確認
DORA第18条に基づいて、被監査会社がサイバーセキュリティインシデント報告義務を果たしているか確認します。過去12か月間のインシデント報告ログを検査し、重大インシデント（Critical Incident）に該当するものが適切に当局に報告されたか確認します。また、クラウドサービスプロバイダー（AWS）の契約書にDORA遵守条項が含まれているか検証します。
監査調書への記載：「DORA第18条に基づくインシデント報告体制を確認。直近12か月間、重大インシデントは報告なし。AWS契約書にセキュリティ基準の遵守条項あり。」
ステップ3：内部統制の評価
ISA 315（改訂2019）に基づいて、DORA対応責任部門（コンプライアンス部門、IT部門、リスク管理部門）の間に、ICTリスク管理プロセスが統合されているかを評価します。Nexus社ではICT部門がセキュリティテストを四半期ごとに実施し、その報告がリスク委員会に提出される体制となっていることを確認します。
監査調書への記載：「四半期ごとのセキュリティテスト（ペネトレーションテスト）実施。結果は取締役会リスク委員会に報告。2024年Q1〜Q3、重大な脆弱性なし。」
結論： Nexus社のDORA準拠状況は概ね適切に進められており、内部統制評価に組み込む根拠が文書化されました。ただし、スタッフのセキュリティ意識研修の実施頻度（現状では年1回）がDORA期待レベルに達しているか、次年度の継続監視項目として記載されます。
監査人と規制当局が見落とすポイント
- 第一次情報： 欧州銀行監督機構（EBA）は2023年と2024年に発表した監視レポートで、金融機関の多くがDORA第11条（ICTリスク報告）の要件理解が不十分であること、特にサードパーティーリスク管理の文書化が未熟であることを指摘しました。監査人がこの領域で標準的なチェックリストのみ適用すると、クライアントの実際のリスク管理体制の質を見落とすリスクがあります。
- 第二次情報： DORA施行初期（2024年）において、クライアント側では「コンプライアンス部門がDORA対応窓口」という認識のままで、実際のICT実装責任がIT部門に委ねられているケースが多くみられます。監査人がコンプライアンス部門とのみ打ち合わせをすると、実装の実態を把握できません。ISA 315.35に基づいて、IT部門を含めた複数の部門との協議が必要です。
- 第三次情報： DORA第20条は三次業者（sub-contractors）のICTセキュリティ義務も定めていますが、実務ではクライアントが把握していない場合が大半です。監査人が「ICTサービス提供者の契約確認」で終了すると、三次業者層のリスクを見落とします。
- レジリエンステスト結果の監査証拠としての評価： DORA第26条は脅威ベースのペネトレーションテスト（TLPT）を一定規模以上の金融機関に義務付けていますが、テスト結果が社内報告書のみで外部検証を受けていないケースがあります。ISA 500.A31に基づき、監査人はテスト実施者の独立性と専門能力を評価し、テスト範囲がクライアントの重要なICTシステムを網羅しているか確認する必要があります。
関連用語
- ICTリスク: DORA管理下の情報通信技術に関連する運用リスク
- サイバーセキュリティ重大インシデント: DORA第18条に基づく報告対象のセキュリティ侵害事象
- サードパーティーリスク: DORA第28条で規制対象となるアウトソース機能のリスク管理
- ISA 315（改訂2019）: 被監査会社のリスク識別における重要な基準
- ISA 402: サービス提供者利用時の監査手続
- 内部統制の評価: DORA準拠体制の監査上の評価方法
計算機・ツール
現在のところ、DORA専用の監査計算機は公開されていません。ただしISA 315リスク評価ワークシート（NV COS形式）にはICTリスク領域が統合されており、DORAチェックリストとして活用できます。詳細はリスク評価ワークシートをご覧ください。