GDPRに関する記事・書籍・実例がある程度出揃ってきている中で、現時点で議論の盛り上がりに欠けるのが32条の安全管理措置かなと思っています。
- 純粋な法律の話ではないから弁護士もそれほど言及しない（ENISA紹介してお茶を濁すとか）
- 社内のセキュリティ対策の話だから企業も公開に積極的ではない
みたいな所が理由なのかな…と想像しています。施行日を過ぎるまではちょっと様子をうかがっていたのですが、32条周りの議論が日本でもっと活性化して欲しいとの思いを込めて少し記事を書いてみます。
法律上の要求事項
GDPRの32条ですが
…以下のものを含め、適切な技術上及び組織上の措置をしかるべく実装する。 (a) 個人データの仮名化又は暗号化 (b) 取扱システム及び取扱サービスの現在の機密性、完全性、可用性及び回復性を確保する能力 (c) 物的又は技術的なインシデントが発生した際、適時な態様で、個人データの可用性及びそれに対するアクセスを復旧する能力 (d) 取扱いの安全性を確保するための技術上及び組織上の措置の有効性の定期的なテスト、評価及び評定のための手順
と記載されています。文言の抽象度が高いですが、どれもセキュリティ施策として一般的なものだと思います。
対応方針
上記の条文を踏まえて、どのように対応するかですが
- GDPR32条を起点として、スクラッチであるべきセキュリティ施策を検討・実施する
- 何らかのセキュリティフレームワークを起点としてセキュリティ施策を実施の上、当該フレームワークがGDPR32条の要件に適合していることを確認する
の2パターンが論理的にはあり得ると思います。もっとも殆どの企業が2を採用すると思うので、以下では2を前提に具体的な対応策を検討します。
対応策
大きく「一般的なセキュリティフレームワークを採用」「GDPR向けフレームワークを採用」の2パターンがあると思います。有名どころを中心に具体的に掘り下げます。
- 一般的なセキュリティフレームワーク
- ISO27001
- NIST SP800-53 等
- GDPR向けフレームワーク
- ICO
- CNIL
- ENISA 等
一般的なセキュリティフレームワーク
すでに何らかのフレームワークに乗っ取ってセキュリティ対策を実施している場合、そちらをベースにして適宜アレンジという形を取ることが多いと思います。
もっとも、一般的なセキュリティフレームワークを採用した場合には、「なぜそのフレームワークでもってGDPRに対応していると言えるのか」についてのロジックが丁寧めに必要かと思います。SP800-53なんかはそのうち別表でGDPRとの対応表を用意してくれそうな気もしているのですが…。
GDPR向けフレームワーク
こちらについては、最終的には「40条の行動規範」「42条の認証」が出揃い、デファクトスタンダードになるようなものが確立されていくのだろうと考えています。現時点では以下の通り、
- ICO
- CNIL
- ENISA
の3つをよく目にする印象です。
ICO,CNIL
施策が簡易的なリスト形式になっているので、取り組みやすいというのが何よりのメリットかと思います。
ICOは本当にただのリストなので、導入には一工夫いるかもしれません。CNILは綺麗な冊子になっていて、最後のページにチェックリストがついているので使いやすそうです。
ENISA
「リスクを考慮に入れた上で」（32条）との文言を踏まえると、セキュリティ管理策の選定を行う前提としてリスク評価を行う（リスクの高・中・低によって要求される管理策が変わる）ENISAが本来は理想的なのだとは思います。
センシティブデータを扱うプロセスが存在する場合には、他のプロセスと区別して対応するためにもENISAを使うのが良いと思います。
以上です。
「同意の取得」や「データ主体の権利行使」の部分は政治的意図が強すぎて、個人的にはあまり魅力や価値を感じないんですよね。法的なテクニカルさでの面白みはあるのですが。
他方で「安全管理措置」の部分は、それこそ個人データを取り扱う企業が本来取り組むべきことであり、果たすべき責任なのではないかと感じています。
