企業における「データコンプライアンス」のあり方、日頃の備えについて

本番環境のデータを万全に保護したからといって、コンプライアンス要件が自動的に満たされるわけではありません。バックアップが間違ったリージョンに保存されていたり、SaaSベンダーが個人情報をDPA（データ処理契約）なしで処理していたり、データに誰がアクセスしたかをログで確認できなかったりする場合、データは保護されていますが、コンプライアンス体制が整っているとは言えません。

これは、データセキュリティとデータコンプライアンスの違いです。データセキュリティは情報の保護を意味しますが、データコンプライアンスは、情報がどのように処理されているのかを規定するものです。そこでは、データがどこに保存されているのか、誰が処理したのか、ベンダーが関わったのか、どのくらいの期間、保持されるのか、問題が生じたらどうなるのか、といったことが問われます。

データコンプライアンスを確保するには、上記の問いに、データ環境全般で対応できなければなりません。クラウド、SaaS、バックアップ、DR（障害復旧）サイト、AI環境などのすべてがコンプライアンスの対象となります。

データコンプライアンスとは

データコンプライアンスとは、適用法、業界の基準、顧客との契約、社内のポリシーなど、さまざまなルールに準拠したうえで、データの収集、保存、処理、保護、長期保持、共有を実践することです。個人情報、クレジットカードなどの取引データ、医療レコード、社員情報、監査ログ、バックアップコピーなど、各種規則で保護の必要性が定義されているあらゆるビジネス機密情報が対象となります。

データコンプライアンスは一度合クリアしたら終わりではなく、常に要件を満たし続けなければなりません。組織が新しいSaaSツールを追加導入したり、バックアップサービスやアナリティクスプラットフォームを採用したり、クラウドリージョンやAIワークフローを変更したりするたびに、コンプライアンスのスコープがそれに応じて更新され、その都度コンプライアンス体制を整えなおす必要があります。

データコンプライアンスとデータセキュリティとデータガバナンスの違い

データコンプライアンスとデータセキュリティとデータガバナンスは、重複する部分もあるため、しばしば混同されがちです。それがコンプライアンスプログラムに齟齬をもたらす原因ともなっています。

これら3つの用語の違いを分かりやすく表にまとめると、以下のようになります。

用語	要点	違反例
データコンプライアンス	該当する法令、基準、契約、ポリシーへの準拠	基幹CRMにDPAがあるのに、顧客対応のサポート分析ツールにない場合
データセキュリティ	データを保護して、遺失、誤用、不正アクセスを防止	本番環境のデータベースは暗号化済みなのに、エクスポートされたバックアップが顧客管理の暗号鍵未設定で保存されている場合
データガバナンス	データのオーナーシップ、品質、ライフサイクル、ポリシーを管理	リテンションポリシーで12か月のログ保存が指定されているのに、SIEMが30日後にログを削除

端的に言うと、セキュリティはデータを保護し、ガバナンスはオーナーシップとライフサイクルのルールを定義し、コンプライアンスはそれらの管理が実際に正しく執行されていることかを証明します。

データコンプライアンスの対象となる規制や基準

組織は通常、同時に複数の枠組みに対応しなければならないのが一般的です。企業や団体に求められるコンプライアンスには、以下のようなものがあります。

規制 / 基準	対象	コンプライアンス上の注意点	求められるコンプライアンス証跡
GDPR（EU一般データ保護規則）	EU圏内に居住する個人のデータ	法的根拠、データの最小限化、DPA、違反通知、国際的なデータ移転	処理レコード、DPA登録、SCCまたは妥当性の根拠、違反ログ、削除ワークフロー
CCPA／CCRA（カリフォルニア州消費者プライバシー権法）	カリフォルニア州の消費者個人情報	セールス／情報共有から除外される権利、知る権利、削除する権利	DSAR（データ主体アクセス要求）ワークフロー、オプトアウトプロセス、プライバシー通知、ベンダーリスト、リクエスト履歴
HIPAA（医療保険の携行性と責任に関する法律）	米国ヘルスケアデータ／ePHI	管理的／物理的／技術的保護措置、BAA（業務提携契約）、監査制御、リスク分析	リスク評価、BAA登録、アクセスログ、インシデントレスポンスレコード、暗号化に関する決定事項
PCI DSS（支払いカード業界データセキュリティ基準）	カード所有者データ環境	スコープ管理、アカウントデータの保護、データ転送の暗号化、ログ生成、アクセス管理	ネットワーク図、CDEスコープ、脆弱性スキャン、アクセス確認、バックアップ保護レコード
SOC 2（米国AICPA認定のセキュリティ／プライバシー規範）	関連サービス機関	セキュリティ、可用性、機密性、処理の整合性、プライバシー全般にわたる設計と運用	Type IIレポート、コントロールテスト、例外、ベンダー管理、アクセス確認
DORA（デジタルオペレーショナルレジリエンス法）	EUの金融セクターICT（情報通信技術）リスク	ICTリスク管理、インシデントレポーティング、レジリエンステスト、サードパーティICTリスク	ICTアセット登録、サードパーティ契約、テストレコード、インシデント分類、出口プラン
EU AI法	EU圏内に配置された、またはEU圏内で使用されるAIシステム	リスク分類、データガバナンス、レコードキーピング、透明性、高リスクAIの義務	AIシステムインベントリ、トレーニングデータドキュメント、リスク評価、ログ、人間による監視の記録

GDPR違反の通知は一般的に72時間以内が義務付けられていますが、実際の要件は、個人データへの不正アクセス検出時に、それが個人へのリスクを生じさせない場合を除き、72時間以内に監督官庁にできる限り速やかに通知するというものです。インシデントレスポンス手順を作成する際は、この細かなニュアンスが重要になります。

HIPAAも過度に単純化されて伝わっているようです。米国保健福祉省（HHS）は、現行のセキュリティルールで適用可能な暗号化の実装を規定しており、組織はそれが合理的かつ適切かどうかを評価し、それに応じて実装または代替策を文書化しなければならないことになっています。つまり、導入が一律に義務付けられているわけではありません。

DORAは、2025年1月17日に発効され、EU全体における金融機関のICT（情報通信技術）レジリエンスとサードパーティ（事業者）の義務および監督責任を定めています。EU AI法は2024年8月1日に制定されましたが、大部分の条項は一部の段階的施行措置の例外を除き、2026年8月2日以降に義務化が徹底されます。

データコンプライアンスが重要なわけ

GDPRは、繰り返し違反すると、罰金額が数百万ユーロ（数億円）にのぼります。PCI DSSへのコンプライアンス違反が判明した場合は、クレジットカードの取り扱いが禁止され、罰金どころか、支払い処理ができなくなる可能性があります。米国で取引をする企業は調達時にSOC 2または同等の認定が必要とされ、監査に不合格となると進行中の取引も中止される可能性があるので、特に中小企業にとっては、罰則そのものよりも、ビジネス遂行上の直接的なリスクが大きくなっています。

クラウドの利用はその分リスクに晒される機会が増えることを意味します。たとえ本番環境のデータがコンプライアンスを確保したリージョンにとどまっていても、レプリケーション、モニタリングのログ、サポートアクセス、ベンダーSaaSとの統合システムなどは、そのリージョンから外にデータを転送して明示的なアーキテクチャ制御を超えたコンプライアンス違反につながるリスクを孕んでいます。たとえば、SOC 2認定を受けた企業でも、DPA（データ処理契約）を省略してクラウドバックアップベンダーを使用していたり、データレジデンシー要件を満たしていないリージョンをDRレプリケーションの保存先に使用していたりするケースが少なくありません。

実際に何が監査対象となるのか

各種規制はその名称や執行のメカニズムは違えど、規制対象としてチェックされる項目には共通点が多く、以下に注力することで多くの規制に対応できる体制が整います。

データインベントリ ― 本番環境、SaaS、バックアップ、ログ、統合システムを含めた環境全体において、重要データがどこに存在するのか、常に最新の状況を透明化できなければ、ダウンストリームのデータ管理体制はすべて信頼性を欠くものとなってしまいます。データインベントリはいつでもすばやく作成できるようにしておかなければなりません。これは、暗号化や多要素認証（MFA）などでカバーできる問題ではなく、コンプライアンス体制の問題です。データインベントリには、システムオーナー、データタイプ、リージョン、ベンダー、リテンション期間、サブプロセッサ（サードパーティによる個人データ処理）、最終確認日などの情報が網羅されている必要があります。

アクセス制御 ― 最小権限の原則を遵守することで、規制対象のデータへのアクセスを制限できます。また、重要システムへの管理者アクセスにはMFAが必須です。たとえば、本番環境のデータベースにデバッグが必要になって開発者のアクセスが追加され、それが削除されずに長期間そのまま放置されることがあります。このようなことが重なって、システムに不特定多数のアクセス権限が存在してしまう状況は絶対に避けなければなりません。定期的にIAM審査を実施して、審査担当者、削除済みユーザー、権限対象アカウント、例外、承認日などをドキュメント化する必要があります。

暗号化の徹底 ― 開発チームによっては、本番環境のデータベースを暗号化しながら、バックアップのエクスポートは暗号化していない場合があります。しかし、HIPAAやPCI DSSが、本番データに厳しくてコピーには甘い、などということはありません。コピーも例外なく規制対象です。データベースバックアップレポートには、暗号化ステータス、暗号鍵オーナーシップ、ターゲットリージョン、リテンション期間、イミュータビリティ設定などが含まれている必要があります。

ログの生成と保存 ― ログはセキュリティ管理の証拠となるものです。誰がどのデータにいつどこからアクセスし、何を変更したのかを記録することに意義があります。ほとんどの組織はログを生成していますが、十分な詳細を十分な期間保存している組織は少ないようです。しかし、セキュリティの監査ではまさにそれが求められます。ログの発生元、リテンション期間、アクセスイベント、管理者アクティビティに加え、管理者がログを改ざんできないことを示す証拠が、SIEM（セキュリティインフォメーションエベントマネジメント）リテンションレポートに含まれている必要があります。

データのリテンションと消去 ― データはとかく放置されがちです。アーカイブに蓄積されたり、貯蔵庫扱いのストレージに半永久的に保存されていたり、3年前のバックアップが保持されていたり、SaaSエクスポートが野ざらしになっていたりは日常茶飯事です。しかし、GDPRの定めるところによると、このような習慣は正当な理由がない限り、データ最小限化の原則に反する行為とみなされます。「念のため」は正当な理由には当たりません。ストレージのライフサイクルルール、削除履歴、バックアップ有効期限、例外の承認記録を含め、リテンションポリシーを確立して、データの保持と消去をきちんと実践することが求められます。

ベンダーDPA ― 個人データを処理するSaaSツールはすべてDPA（データ処理契約）が必要とされます。これが問題となるのは通常、CRMやERPではなく、しばらく前に追加されたアナリティクスベンダーのツールであったり、昨年統合したサポートプラットフォームであったり、調達プロセスを省いて誰かが勝手にダウンロードした生産性向上ツールであったりします。ベンダーとの登録事項には、DPAステータス、処理対象データのカテゴリ、ストレージリージョン、サブプロセッサ（サードパーティによる個人データ処理）、インシデント通知条件、更新日などの情報が記録されていなければなりません。DPAは、ベンダーのソフトウェア使用許諾契約に同意したら自動的に付随するものとの誤解もあるようですが、実際には個別に用意しなければならないものなので注意が必要です。

クラウド、SaaS、ハイブリッド環境の注意点

たとえば、リージョン設定で欧州のeu-west-1を選択し、それに伴うGDPRの要件を満たしたら、コンプライアンスがすべて確保されるわけではありません。選択したリージョンはあくまで本番環境のデータが配置される場所であり、ログやバックアップがどこに保存されるかを規定するものではありません。モニタリングエージェントがテレメトリーを想定外の場所で処理する可能性もあります。これらはすべての監査が入る前にドキュメント化しておく必要があります。

ドイツのフランクフルトに本番環境のデータベースを配置している企業がDRレプリカをEU圏外に保存し、さらにサードパーティのバックアップサービスがコピーを米国に保存しているようなケースはよくあります。そのようなデータにEUの個人データが含まれている場合、たとえ本番環境のデータが一切EU圏外に出るようなことがなくても、レプリケーションの設定にはSCC（標準契約状況）などに準じたデータ移行のメカニズムが必要になります。

SaaSの導入時には（特にEUや米国での取引では）最低限必要なデューデリジェンスがあるのですが、多くの組織で省略されがちです。実際には、①適正なDPAが存在するか、②サブプロセッサリストが用意されているか、③データレジデンシーのオプションが文書化されているか、④SOC 2認定を受けているか、⑤インシデント通知条件は定義されているか、などのチェックが必要です。最初の2点は導入時に調達プロセスで確認されることになりますが、残りは見落としていた場合は監査で指摘されることになります。

バックアップ、DR、監査対応

最大の盲点がここにあります。本番環境の基準を二次的コピーにも適用して、それが適合すると考えている組織はかなり多いようです。承認済みのスコープの域外リージョンにレプリケーションを行うバックアップジョブは、たとえ本番環境のコンプライアンスが完璧でも、データレジデンシー違反を起こす可能性が高いです。また、暗号化せずにエクスポートされたバックアップ（あるいは、データの所有者ではなくベンダーが管理する暗号鍵で暗号化されたバックアップ）も、別の意味で大きなリスク要因となります。どちらのケースも、その時点では明確な問題を引き起こさないため、アラートが発せられず、後々に監査で問題が明るみになる点が同じです。

バックアップのコンプライアンス違反は大概リストアテストで発見されます。リストアテストを盛り込んでいないバックアップポリシーは検証の機会を得られずに、インシデント発生時に問題が明るみに出ます。DORA（デジタルオペレーショナルレジリエンス法）は金融機関にリカバリ手順のドキュメント化を明示的に義務付けていますが、リカバリテストはすべての組織が導入すべきプラクティスです。バックアップには暗号化と同時にイミュータビリティ（不変性）も重要で、たとえばAmazon S3のObject Lockや同等の機能をオンプレミスのオブジェクトストアに実装することで、ストレージレイヤーのイミュータビリティが実現できます。

AIとデータコンプライアンス

AIのコンプライアンス違反は従来のコンプライアンス違反とは様相が異なります。データが盗まれたりするわけではなく、トレーニングセット、プロンプトログ、RAG（検索拡張生成）結果にデータが含まれることで、見るべきでない人も見られるようになってしまうことが問題となるます。

AIプロバイダのDPA要件は、他のデータ処理者と基本的に変わりありません。たとえば、GDPR第28条に同意することなく消費者AIツールを利用することは、プロバイダが企業データをトレーニングに使用していようがいまいが、コンプライアンス違反に当たります。いかなる個人データもモデルに使用される前に、エンタープライズティアかAPI統合レイヤーで適正なDPAを適用しておかなければなりません。

プロンプトレベルでのPII（個人識別情報）フィルタはリスクを軽減させますが、コンプライアンス管理の面では十分ではありません。PIIフィルタは通常、入力テキストはカバーしますが、データを自動処理するAI機能（メール要約、スマートサジェスチョン、その他のツールがユーザーデータを自動活用する場合）には対応していません。このため、組織によっては、ユーザーとLLMプロバイダと間にプロキシを実装しているところもあります。たとえば、Azure OpenAIエンドポイントやカスタムAPIゲートウェイにより、テクニカルレイヤーにポリシーを適用し、DPO（トレンド除去プライスオシレーター）ルックバックにログを生成するやり方です。GDPR第25条では、従業員が顧客レコードをAIツールにそのまま貼り付けられる環境はPrivacy by Design（プライバシーバイデザイン）の基準を満たしていないとみなされます。

EU AI法は、高リスクのAIシステム（人材採用ツール、クレジットスコア、医療AI、社会的な重要インフラなど）に特別な追加要件（トレーニングデータプロべナンスや記録保持義務）を求めており、それが2026年8月から完全に施行される予定です。しかし、現実的な懸念はすでに存在しています。たとえば、RAGシステムが生成するサポートチケットは、元々のヘルプデスクのアクセス制御における権限をいちいち照合しておらず、ユーザーリクエスト情報を権限と関係なく露出させる場合があります。つまり、AIモデルにコンプライアンス違反がなくても、権限レベルに違反が潜んでいる可能性があります。

データコンプライアンス上のよくある間違い

コンプライアンスを書類上の問題と捉えると、監査への準備がおろそかになりがちです。ポリシーは一応適用されているにもかかわらず、その施行体制とポリシーとの間にギャップがあり、それを埋めるモニタリングや証跡の仕組みがないことがしばしば問題となります。

重要なデータがどこに保存されているのかを把握できていない場合、それにもとづく管理体制はすべて信頼性を欠くものとなってしまいます。データインベントリの作成を省略したチームは、自ら設定したシステムにのみデータが存在することを前提としており、その前提はSaaSの導入やAPIの統合、あるいは調達管理プロセスを通じずに誰かがダウンロードしたツールなどであっさりと崩れてしまいます。

さらに、管理者アクセスが広範に付与されていたり、リストアプロセスがテストされていなかったりすることが、組織的な問題を増幅させます。長く有効なまま放置されていたアクセス権を突然無効にして何かが機能しなくなったりしたら面倒だし、リストアテストを実行してバックアップの目標値からかけ離れた数値を発見してしまったりするのも、チーム内で自分が率先してやりたいとは誰も思いません。これらのタスクは組織で先延ばしにされがちで、コンプライアンスリスクが年々拡大していくことになります。監査証跡は監査時にのみ収集されますが、監査担当者がもっとも気にするのは、前回の監査時から今回の監査時の間の状態です。そこにコンプライアンスのギャップがあるとの見立ては大概当たっています。つまり、コンプライアンスは緊急時対応ではなく、不断の努力の賜物でなければなりません。

オンプレミスとHCIで厳格なコンプライアンスに対応

組織によっては、データがどこにあって誰がアクセスできるのかについて、より厳密な規制の対象となっている場合があります。特に医療機関、金融機関、公共サービス、防衛、規制が厳しいエッジ環境などはこれに相当します。クラウドによってコンプライアンスが確保できる場合もありますが、リージョン、レプリケーション、サポートアクセス、サブプロセッサ（サードパーティによるデータ処理）、データ移行メカニズムが正確にドキュメント化されている場合に限られます。物理的な制御とローカルデータレジデンシーが主要な要件である場合、オンプレミスやコロケーション、あるいはエッジインフラストラクチャがより管理しやすい環境となります。たとえば、エッジおよびブランチデプロイメントを使用することで、コンピューティングとストレージをローカルに配置して規制対象のデータを物理的なスコープ内に維持し、WANリンクへの依存を減らすことができます。HCI（ハイパーコンバージドインフラストラクチャ）プラットフォームでもこのパターンを実践でき、コンピューティング、ストレージ、仮想化、管理を一つにまとめて運用上のフットプリントを縮小することができます。

オンプレミス環境を使用したからと言って、デフォルトでコンプライアンスが確立されるわけではありません。しかし、インフラストラクチャの境界線を最小化し、うまく制御すると、データがどこにあり、どのようにレプリケートされ、誰がアクセスできるのか、そしてバックアップがきちんとリストアできるのかをすべてドキュメント化しやすくなります。

まとめ

コンプライアンスはプロアクティブでなければ、成功しません。リアクティブ、つまり、当局や監査担当者や顧客に問われたときにはじめて規制遵守の証拠集めを開始する体制では、真のコンプライアンスは確立できません。規制遵守はもちろんのこと、その証拠集めは問われる前に日常のオペレーションとして行っておく必要があります。ここでいうコンプライアンスの証拠には、最新のデータインベントリ、安全確認済みのアクセスとテスト済みのリストアプロセス、ログ、リテンションポリシー、ベンダーの詳細、データレジデンシーとリカバリ要件に合致したインフラストラクチャに関する情報を網羅する必要があります。これらが揃わない場合は、まずはリストアのテストから始めましょう。リストアテストで足りない点を明らかにしてから補正し、コンプライアンスの証拠を積み上げていく必要があります。

よくある質問（FAQ）

データコンプライアンスとデータセキュリティの違いは何ですか？

データセキュリティは、不正アクセスや不慮の損失からデータを保護するためのものですが、データコンプライアンスはデータの適正な取り扱いを証明するための取り組みです。したがって、データコンプライアンスでは、どのベンダーがデータを処理したのか、データはどこに送られたのか、データをどのくらいの期間保持するのか、といった情報が重要になります。データセキュリティが万全でもコンプライアンスが不足する場合もあれば、その逆もあります。

広範に適用されているデータコンプライアンスの枠組みにはどのようなものがありますか？

ヨーロッパでは個人データの保護を規定したGDPR（EU一般データ保護規則）が有名です。米国では医療データを対象としたHIPAA（医療保険の携行性と責任に関する法律）、クレジットカードに関するPCI DSS（支払いカード業界データセキュリティ基準）、カリフォルニア州の消費者の個人情報を保護するCCPA／CPRA、米国公認会計士協会がサービス企業のセキュリティを認定するSOC ２などがあります。このほか、EUの金融セクターICT（情報通信技術）リスクに関するDORA（デジタルオペレーショナルレジリエンス法）や、高リスクAIシステムのデータガバナンスを規定するEU AI法もあります。国境や行政区域をまたがって運営する組織は複数の枠組みに同時に準拠する必要があります。

コンプライアンスの監査にはどのように備えるべきですか？

最新のデータインベントリを維持し、アクセスログ、バックアップレコードを継続的に管理して、リストアプロセスを（監査が入ってからではなく）定期的にテストします。クラウドやSaaSシステム全体のデータフローをドキュメント化し、ベンダーの契約内容（欧州におけるDPAなど）を確認するこも重要です。監査担当者は、緊急で集められた書類ではなく、日頃の継続的な取り組みの証拠を確認しようとするので、普段からセキュリティ体制を万全に整えておく必要があります。

関連トピックス:

コメントを残す

この記事のトラックバック用URL

クライム主催セミナー

出展・参加イベント

カテゴリーで絞る

関連リンク

よく読まれている記事

新着記事

Top30タグリスト

メールマガジン登録

最近のコメント