施行から数年、いまだに第32条は「任意」ではない：実務で問われる「技術的措置」とは

はじめに

GDPRは長年にわたり施行されており、主要な制裁金で最も頻繁に引用されるのは第32条です。これは同意バナーでも国際的な移転メカニズムでもありません。セキュリティです。「適切な技術的および組織的措置」を導入するために約10年の猶予があったにもかかわらず、多くの組織がこれを正しく実施できておらず、規制当局は侵害が発生した際に不十分なセキュリティをデフォルトの説明とみなしています。

その一因は、第32条がチェックリストのように記載されていないことにあります。4つのカテゴリーを例示的に挙げ、「適切さ」はリスクに照らして判断されるべきものであり、組織が単に一度実装して終わりにできるような固定的な技術基準を指定していません。本記事では、これら4つのカテゴリーが実際に何を求めているのか、そして第32条を過去のものと見なすことがなぜ誤った前提であるのかを解説します。

• ポイント1：第32条は4つの例示的なカテゴリーを挙げており、固定的なチェックリストではありません。仮名化と暗号化、システムの継続的なレジリエンス、インシデント後の迅速な復旧、そして有効性の定期的なテストです。
• ポイント2：「リスクに応じた適切さ」とは、データや脅威の状況が変化するにつれて基準も変動することを意味します。数年前に適切だった措置が、現在も自動的に適切であるとは限りません。
• ポイント3：GDPRの主要な制裁の中心は手続き上の不備ではなく、セキュリティの失敗です。2026年の数百万ユーロ規模の制裁金も、不十分な技術的および組織的措置が主な原因として挙げられています。
• ポイント4：顧客による鍵管理がない暗号化は、仮名化の要件を形式的にしか満たしません。処理者が管理者と同じようにデータを復号できる場合、暗号化の保護効果は限定的です。
• ポイント5：4つ目の要素である「有効性の定期的なテスト」は、多くの組織が完全に見落としています。一度措置を導入してその後検証しないというのは、よくある、そしてよく罰せられるギャップです。

エグゼクティブサマリー

GDPR第32条は、技術的および組織的措置の4つの例示的なカテゴリーを定めています：仮名化と暗号化、処理システムの継続的な機密性・完全性・可用性・レジリエンス、インシデント後の迅速なデータ復旧・アクセス回復能力、そしてそれらの措置が実際に機能しているかを定期的にテスト・評価するプロセスです。いずれも一度の導入で満たされるものではありません。2026年までの執行パターンを見ると、主要な制裁金はこれらのカテゴリー、特にアクセス制御の不備、弱い暗号化運用、検証されていないインシデント対応能力の欠如といったギャップに起因していることが一貫して示されています。データ保護やセキュリティの責任者にとって、規制施行から数年経った今、問うべきは「第32条に一度対応したか」ではなく、「現在のリスクに照らして今も満たしているか」です。

「適切さ」は固定基準ではなく変動するターゲットである理由

第32条は、特定の技術や設定を名指しすることを意図的に避け、代わりに「処理に伴うリスクに適切な措置」を求めています。これにより技術の変化にも耐えうる規定となり、コンプライアンスが一度きりの達成で終わらないことも意味します。

リスクベースの言語はデータや脅威に応じて基準が変化することを意味する

ある個人データカテゴリ、特定の処理方法、特定の脅威状況に対して適切と判断された措置も、これら3要素のいずれかが変化すれば自動的に適切であり続けるわけではありません。より機微なデータを扱うようになったり、より高度な攻撃者に直面したり、単純に処理量が増加するだけでも、「適切さ」に求められる水準は上がります。特定の措置が削除・弱体化されていなくても同様です。

規制当局は「適切さ」を合理的な組織が取るべき措置と比較して判断する

執行判断では、その組織が実施していた措置が、その種のデータ・リスクを扱う合理的な組織が講じていたであろう措置と合致していたかが一貫して評価されます。単に何らかのセキュリティ措置があったかどうかではありません。現状のリスク評価と対応を示せる組織が評価され、誰も見直していない静的なポリシーでは評価されません。

4つのカテゴリーが実際に求めていること

第32条1項は4つのカテゴリーを明示しており、いずれも執行判断で繰り返し問題となっています。

実効性のある仮名化と暗号化

暗号化は、暗号化データを保持する主体が当然のように復号できる場合、このカテゴリーを形式的にしか満たしません。なぜなら、その主体が侵害されたり強制された瞬間に、暗号化による保護の壁が崩れるからです。同様に、仮名化も単にラベルを付け替えるだけで、通常アクセスできる人が簡単に元に戻せるようでは意味がありません。実際に識別情報と基礎データを分離する必要があります。

継続的な機密性・完全性・可用性・レジリエンスの確保

このカテゴリーは明確に「継続的」であることが求められます。つまり「導入時に安全だったか」ではなく、「現在も継続的に機密性・完全性・可用性・レジリエンスが維持されているか」です。執行判断でこの要素が問題となるのは、時間の経過とともに劣化したアクセス制御、放置された脆弱性、長期間存在していた構造的な弱点が侵害によって露呈した場合などです。

物理的または技術的インシデント後の迅速な復旧

このカテゴリーは、システムがダウンしたりデータが利用不能になった場合、どれだけ迅速にアクセスを回復できるかという運用上の具体的な問いを投げかけています。災害復旧能力がテストされていない、あるいはバックアップからの復旧を実際にリハーサルしたことがない組織は、どれだけ文書で主張しても、この要件を実質的に満たしていません。

導入した措置の定期的なテストと評価

この要素は最も見落とされがちです。暗号化やアクセス制御、災害復旧計画を一度導入しただけで、その後それらが意図通り機能しているかテストしなければ、第32条1項(d)には違反します。他の3つのカテゴリーに最初に対応していても同様です。定期的なテストは任意の努力義務ではなく、明示された独立した要件です。

なぜ今も最大の制裁金を生む条文なのか

GDPR施行から数年経った今も、第32条が主要な制裁の根拠であり続けているのは、それが一度きりではなく継続的な義務であり、組織が継続的な義務を一度で終わったものと誤認しがちだからです。

最大の制裁金を生むのは手続き上の不備ではなくセキュリティの失敗

2026年までの主要な制裁金は、文書化や透明性の不足ではなく、侵害後の技術的・組織的措置の不備に集中しています。規制当局が侵害を調査する際、まず問うのは「適切なセキュリティ措置が機能していたか」であり、それがリスクの範囲内か、予見可能なギャップかを判断する基準となります。

かつて十分だった措置は、今も十分である証拠にはならない

導入当初に強力な措置を講じた組織が、その実装を永続的なコンプライアンスの証拠とみなしてしまうことがあります。しかし第32条は継続的な視点を求めており、調査時に問われるのは「インシデント発生時の措置の状態」であり、初期導入時の状態ではありません。

数年後も耐えうる第32条プログラムの構築

実務的な対応としては、4つのカテゴリーすべてを「完了したプロジェクト」ではなく「継続的な運用上のコミットメント」として扱うことです。暗号化や仮名化が本当に露出を制限しているか（単に管理者が容易に元に戻せるだけではないか）を検証し、アクセス制御やシステムの完全性が継続的に監視されているか（一度きりのチェックで済ませていないか）を確認し、災害復旧能力を実際のスケジュールでテストし、テスト自体を証拠の一部として文書化します。4つ目のカテゴリーは他の3つとは独立して存在するためです。

継続的な第32条コンプライアンスを支えるデータコントロールプレーン

第32条を一度きりの実装ではなく継続的な義務として満たすには、暗号化が本当にアクセス可能者を限定し、アクセスやシステム活動がすべてのチャネルで継続的に監視され、復旧やテスト能力が個別に組み立てるのではなく組み込まれているプラットフォームが必要です。

Kiteworksのデータコントロールプレーンは、ハードウェアセキュリティモジュールによる顧客所有の暗号鍵をサポートし、暗号化による露出制限を実質的に実現します（処理者の復号能力に依存しません）。監査ログはデフォルトで匿名化され、アクティビティ記録に本格的な仮名化レイヤーを追加します。シングルテナントアーキテクチャ、強化された仮想アプライアンス、組み込みのファイアウォールや侵入検知レイヤーは、継続的な機密性・完全性・レジリエンスを支えます。また、組み込みの高可用性・災害復旧構成とノード移行機能により、インシデント後の迅速な復旧もサポートします。Kiteworksは定期的なペネトレーションテストや年次監査を実施し、メール、ファイル共有、API、AIエージェントなど全チャネルのすべてのアクションを改ざん防止かつ制限のない監査ログで記録し、SIEMツールに直接連携します。これにより、第32条1項(d)が実際に求める継続的な証拠基盤を組織に提供します。

現在の技術的・組織的措置が新たな第32条評価に耐えうるかをテストしたい組織は、カスタムデモを予約し、継続的かつ証拠に基づくセキュリティコントロールが自社環境にどう適用されるかをご確認いただけます。