5.3コンプライアンスフレームワークの影響

インシデント対応は技術だけでは完結しません。扱っているデータの種類によって、「侵害したら誰に・いつまでに知らせなければならないか」を法律や業界規則が定めているからです。この節では、カード情報のPCI-DSS、医療情報のHIPAA、EU個人データのGDPR、教育記録のFERPA、米連邦システムのFISMAという代表的なコンプライアンスフレームワークがどのデータを対象にするかの対応関係と、侵害時の報告/通知要件がインシデント対応の手順にどう影響するかを、入門レベルで学びます。

5.3.1代表的なフレームワークと対象データ

• PCI-DSS＝クレジットカード会員データを守る業界標準（カードブランドが策定）。HIPAA＝米国の医療情報（保護対象保健情報）の保護規則。データの種類で使い分けを問う定番なので「カード＝PCI-DSS／医療＝HIPAA」を確実に。
• GDPR＝EU（欧州）の個人データを保護する法律で、EU域内の人のデータを扱うなら域外の組織にも及ぶ。FERPA＝米国の学生の教育記録のプライバシーを守る法律。「EU個人データ＝GDPR／教育記録＝FERPA」で覚える。
• FISMA＝米国の連邦政府の情報システムにセキュリティ管理を義務づける法律。対象は連邦機関とその関連システム。「米連邦システム＝FISMA」。これら5つは守るデータ・対象領域が違うので、状況文に出る「何のデータか」で選ぶのがコツ。

5.3.2報告・通知要件のインシデント対応への影響

• 多くの規制は侵害時の報告/通知要件を定める。例えばGDPRは個人データ侵害を認識してから原則72時間以内に監督機関へ通知するよう求める。つまりインシデント対応計画には「誰が・いつまでに・どこへ通知するか」を最初から組み込む必要がある。
• 通知先は規制ごとに異なる：監督当局、影響を受けた本人、カードブランド、連邦機関など。技術的な封じ込めだけ済ませて報告を怠ると、それ自体が規制違反・罰金の対象になり得る。だから「技術対応」と「法的な報告義務」は並行して進める。
• 入門段階の要点は、「このデータならこの規制が関わり、侵害時には報告義務が生じる」と気づけること。細かな条文の暗記より、扱うデータの種類から該当フレームワークと通知の必要性を結びつける判断ができれば十分。

あなたの会社は欧州の顧客にオンライン販売をしており、決済にはクレジットカードを使っています。ある日、Webサーバへの不正アクセスで、EU在住の顧客の氏名・住所と、カード情報が漏えいした疑いが浮上したとします。技術担当者は「侵入経路を塞いで、漏れたサーバを復旧すれば対応完了だ」と考えがちですが、これはコンプライアンスの視点が抜けた危うい判断です。まず、漏れたデータの種類を見ます。カード情報が関わるならPCI-DSSが、EU在住者の個人データが関わるならGDPRが同時に関係します。そしてGDPRでは、個人データ侵害を認識してから原則72時間以内に監督機関へ通知する義務があり、状況によっては影響を受けた本人への連絡も必要です。つまり、技術的に穴を塞ぐ作業と並行して、法務・責任者と連携し「誰が・いつまでに・どこへ通知するか」を動かさなければなりません。もしここで技術的な封じ込めだけを済ませ、報告を後回しにして72時間を過ぎてしまえば、侵害そのものに加えて通知義務違反という二重の問題になり、罰金の対象にもなり得ます。ここでの学びは、インシデント対応では「扱っているデータは何か」を最初に確認し、そのデータに紐づく規制の報告/通知要件を、技術対応と並行して回すという判断です。入門段階では条文を暗記する必要はありませんが、「このデータならこの規制、そして報告義務がある」と気づけることが、正しい初動につながります。

5.3.3この節のまとめ

• カード＝PCI-DSS／医療＝HIPAA／EU個人データ＝GDPR／教育記録＝FERPA／米連邦システム＝FISMA。データの種類で該当規制を選ぶ
• 規制は侵害時の報告/通知要件を定める（例：GDPRは認識から原則72時間以内に監督機関へ通知）
• 技術的な封じ込めだけで完了とせず、法的な報告義務を並行して果たすのがインシデント対応