GDPR、それから(Brexit、越境移転規制のグローバル化、非個人データへの規制)

本日はGDPRの施行日です。これまで5月25日に間に合わせるべくGDPRの準備を行ってきた方には、心からお疲れ様でしたとお伝えしたいと思います。
もちろん5月25日で準備が完了していない企業も多数あります。(こちらのほうが多数派のはずです)そういった方々は心配なさっているかもしれませんが、高い確率で心配される必要はないと思います。GDPRは継続的な活動であり、なすべきことを特定して粛々と進めていればよいものですから。

今日は、一つのマイルストーンとしての施行日であることから、GDPR後の話をしようと思います。

まず、Brexitについてです。

日本企業はイギリスに欧州本拠地をおいていることがしばしばあります。
2019年3月29日にはイギリスが欧州域外となるため、域外移転の適法化措置や主監督機関を変更するといった措置が必要となります。
同時にイギリス国内法であるData Protection Act(個人データ保護法)への準拠が必要となります。

もう10ヶ月ほどしかないので、対応を今から検討し始める必要があるでしょう。
私もまだ精査できていませんが、Data Protection Act(個人データ保護法)はGDPRよりも要件が高いという話です。
追加の対応が必要となる可能性があります。

次に、世界的なデータ保護の潮流を見逃してはなりません。

以下は、個人データの越境移転規制の拡大としてよく目にするものですが、越境移転規制を導入する国が増加しています。
欧州のみならず、こういった規制への対応も今後は迫られてくるでしょう。特にアジア圏は日本の企業が数多く活動している地域です。
こういった地域への対応も注意しておかなければなりません。個人データ保護の対応が欧州に限らないというのは、世界的にデータ保護の概念が急速に導入されていることにあります。

【個人データの越境移転規制の拡大】
■ 第1期:
EU (データ保護指令)(1995)、香港(1996)、オーストラリア(2000)
■ 第2期:
韓国(2011)、インド(2011)、台湾(2012)、マレーシア(2013)、ベトナム(2013)、シンガポール(2014)、
ブラジル(2014)、インドネシア(2016)、日本(2017)、フィリピン(2017)、EU(GDPR)(2018)

このブログでも何度か指摘しているように、いわゆる「データローカライゼーション」の動きにも注意が必要です。
データローカライゼーションでは「個人データ」を超えて「非個人データ」の移転も規制するため、製品開発等への影響も避けられず問題は更に複雑化してきます。
どういうデータが規制され、国外移転についてどのような要件があるかを専門家と確認してください。

中国のインターネット安全法に関連して、マイクロソフトは中国で取得するデータは中国のデータセンターにしか保存しないという対応をとっていると聞きました。
こういった対応が今後ますます重要になる可能性があります。

テクニカ・ゼン株式会社では会員制データ・プライバシー情報サイトを開始しました。こちらの有用情報で記事を更新していますので、ぜひ、ご訪問・ご登録ください。

2000万ユーロまたは全世界売上高の4%の制裁金となるケース

日本の個人情報保護委員会や個人情報保護委員会に関連した団体は「日本」のデータ保護を議論しています。
これは当然のことなのですが、議論が内向きな印象が否めません。

あくまでも「日本」がどう権利を護り、「日本」の存在をどう世界に発信していくか、という議論が主となっている印象です。
なんとなく聞き手の共感を得にくい気がします。お酒の場で自分の立場や自分の考え方にこだわって主張する人の話を聞いても面白くないようなものです。
立場がそうさせているのだと思いますが、データ保護という世界のダイナミックな動きの中でもったいないと思います。

CBPRの構想は世界に自信を持って発信すべき構想だと思いますし、促進させるためにはもっとインセンティブを事業者に与えればよい気もします。

この国にはあるべき姿を発信し、強力に前進させていくという力が必要です。

昨日の続きです。
今日は制裁金が2000万ユーロまたは前会計年度の全世界売上高の4%以下のいずれか高額の方の金額が上限となる場合について解説します。

GDPR第83項(5)が該当箇所です。
制裁金が2000万ユーロまたは前会計年度の全世界売上高の4%以下のいずれか高額の方の金額が上限となる場合は以下の場合です。

(a) GDPRの原則(GDPR第5条GDPR第6条GDPR第7条GDPR第9条)に違反した場合
(b) データ主体の権利(GDPR第12条 – GDPR第22条)に違反した場合
(c) 第三国又は国際機関に個人データを違法に移転した場合(GDPR第44条 – GDPR第49条)
(d) GDPR9章(GDPR第85条 – GDPR第91条)で採択された各国法による義務に違反した場合
(e) 監督機関の命令に従わなかった場合(GDPR第58条(2))または監督機関の調査に協力できなかった場合(GDPR第58条(1))

(a)、(b)の具体的な事項については以下を参照ください。

第5条】の違反(対象:管理者、処理者)
個人データが、適法に、公正かつ透明性のある方法で処理されなかった場合。
個人データが、明確、かつ適法な目的のために収集されなかった場合。
個人データが、特定された目的と異なる目的で処理された場合。
個人データの処理が、必要最小限に限定されていなかった場合。
個人データが、目的に照らして必要な期間を超えて、データ主体が識別可能な状態で保存されていた場合。
個人データの処理に際し、適切な技術的又は組織的措置が講じられていなかった場合。

第6条】の違反(対象:管理者、処理者)
適法根拠を満たさずに個人データを処理した場合。

第7条】の違反(対象:管理者、処理者)
1項:適法根拠として同意を用いているにもかかわらず、管理者が同意を証明できなかった場合。
2項:明瞭で平易な言葉、わかりやすいアクセス性のよいフォームを用い、範囲が明確であるべきという同意の要件を満たさなかった場合。
3項:同意を撤回する権利があることをデータ主体に情報提供していなかった場合。

第9条】の違反(対象:管理者、処理者)
適用除外事由がないにもかかわらず、特別カテゴリーの個人データ処理を行った場合。

第12条】の違反(対象:管理者)
1項:データ主体に対する情報提供を行っていなかった場合。
2項:データ主体の権利行使を可能としていない場合。正当な理由なくデータ主体の権利行使を拒んだ場合。
3項:データ主体の権利行使に対して、正当な理由なく1ヶ月以内にデータ主体に情報提供できなかった場合。
4項:データ主体の権利行使に対する拒否理由を1ヶ月以内に通知しなかった場合。
5項:情報通知や権利行使対応、データ侵害通知を、正当な理由なく有償で行った場合。

第13条第14条】の違反(対象:管理者)
第13条、第14条で定める、データ主体に対する情報提供を行わなかった場合。

第15条】の違反(対象:管理者)
データ主体のアクセス権を拒否した場合。処理しているデータの写しの提供を拒否した場合。

第16条】の違反(対象:管理者)
データ主体の訂正権に応じなかった場合。

第17条】の違反(対象:管理者)
データ主体の削除権に応じなかった場合。
データの開示先に対して削除権行使があった旨を連絡し、データ削除を行わせなかった場合。

第18条】の違反(対象:管理者)
データ主体の制限権行使に対して適切な制限方策を施さなかった場合。

第19条】の違反(対象:管理者)
個人データの訂正、消去、処理の制限について受領者やデータ主体への通知義務を怠った場合。

第20条】の違反(対象:管理者)
データポータビリティの権利に基づくデータ主体の権利行使を拒否した場合。

第21条】の違反(対象:管理者)
ダイレクトマーケティングのための個人データ処理についてデータ主体から異議を唱えられたにもかかわらず、それを拒否した場合。

第22条】の違反(対象:管理者)
自動化された処理のみに基づいてデータ主体に大きな影響を与える決定を行った場合。
データ主体の権利、自由、正当な利益を護るための適切な保護措置を実施しなかった場合。

【第12条 – 第22条】の違反(対象:管理者、処理者)
データ主体の権利行使を尊重しなかった場合。

1000万ユーロまたは全世界売上高の2%の制裁金となるケース

先日、ある会議で隣り合った人と名刺交換をしました。その方はアメリカのネット・セキュリティー会社にお勤めの方で、「GDPRの対応で忙しいですか?」と聞くと「もうひと段落着いたかな」との回答でした。「日本は遅れているみたいですね」というのがどうも外資系の方の印象のようです。

日本企業は「横並び」という評価をたまに耳にします。国民性なのかもしれませんが、それでずいぶんもったいないことをしているのも事実です。緻密な議論は得意でも、大きく動くという点ではなかなか腰が重いのでしょう。

欧州については大企業で70%くらい完了した状態のようです。中小企業になるとnothingという答えが返ってくることも多いようで、その点については日本と状況がそれほど変わらないようです。

今日は制裁金の金額と根拠条項をひとつずつつき合わせておきましょう。
今日は制裁金が1000万ユーロまたは前会計年度の全世界売上高の2%以下のいずれか高額の方の金額が上限となる場合について解説します。

GDPR第83項(4)が該当箇所です。

第8条】の違反(対象:管理者、処理者)
1項:子供の保護責任者による同意または許可を得ることなく子供に情報社会サービスを直接提供した場合。(子供の年齢は13歳 – 16歳未満)
2項:子供の保護責任者による同意または許可を得たという状況を証明できるよう合理的なを怠った場合。(子供の年齢は13歳 – 16歳未満)

第11条】の違反(対象:管理者)
2項:データ主体を識別する立場にないことを証明でき、その旨をデータ主体に通知できるときにデータ主体に通知しなかった場合。

第26条(1)(2)】の違反(対象:管理者)
1項:共同管理者であるとき、その責任分掌を合意によって取り決めていない場合。
2項(1):共同管理者間の責任分掌が合意の通りとなっていない場合。
2項(2):共同管理者間の合意のエッセンスをデータ主体が入手できない場合。

第27条】の違反(対象:管理者、処理者)
義務があるのに代理人を書面によって選任していない場合。

第28条(1)】の違反(対象:管理者)
GDPRの要件を満たす技術的、組織的措置の実施をを十分保証できない処理者を利用した場合。

第28条(2)(3)(4)(9)】の違反(対象:処理者)
2項:管理者から書面による許可を得ず他の処理者を使用した場合。管理者への通知を怠ったり、管理者が異議を唱える機会を提供しなかった場合。
3項、9項:処理者契約またはその他の法的行為によらず処理者が処理を行った場合。契約等が書面(電子的方法を含む)で行われなかった場合。
4項:処理者の使用する処理者に対して、管理者-処理者間で定められた契約条項と同一のデータ保護義務を課すことを行った場合。

第29条】の違反(対象:処理者)
管理者の指示に基づかずに個人データを処理した場合。

第30条】の違反(対象:管理者、処理者)
1項 – 3項:処理記録を行わなかった場合。(書面(電子方式を含む)がない場合を含む)
4項:監督機関からの要求に対し、処理記録を提供しなかった場合。

第31条】の違反(対象:管理者、処理者)
監督機関の要求に対して協力しなかった場合。

第32条】の違反(対象:管理者、処理者)
1項:リスクに見合った適切な技術的および組織的な措置を講じなかった場合
4項:個人データを処理可能な人物が、管理者からの指示以外で個人データを処理することがないような手立てを講じなかった場合。

第33条(1)-(3)、(5)】の違反(対象:管理者、処理者)
1項 – 3項:監督機関への通知義務を怠った場合。
5項:個人データ侵害について文書による記録義務を怠った場合。

第34条(1)(2)】の違反(対象:管理者、処理者)
個人データ侵害をデータ主体に連絡する義務を怠った場合

第35条(1)(2)(3)(7)(9)】の違反(対象:管理者)
1項、3項、7項:DPIA実施を怠った場合。
2項:DPIAを行うに当たって、DPOのサポートを求めなかった場合
9項:DPIAを行い、データ主体またはその代理人の意見を求める義務があるときに求めなかった場合

第36条(3)】の違反(対象:管理者)
DPIAについて監督機関に相談する際、必要な情報を提供しなかった場合

第37条(1)(4)(7)】の違反(対象:管理者、処理者)
1項、4項:DPOを選任義務違反があった場合。
7項:データ保護責任者の連絡先を公開しなかった場合、または監督機関に通知しなかった場合。

第38条(1)-(3)、(6)】の違反(対象:管理者、処理者)
DPOの関与を確保しなかった場合。
DPOに必要なサポートを提供しなかった場合。
DPOの独立性を確保しなかった場合。
利益相反を招かない状況を確保しなかった場合。

GDPRの是正措置について

GDPRの施行日がが迫ってきていますので、今日から3日間はGDPRの是正措置について書いておきます。
GDPR対応のお祭り騒ぎはGDPRの高額な制裁金に由来しているのですが、いきなり制裁金が課せられることはありません。

まず警告があり、その後指導し、それでも遵守されないときに発動されるのが制裁金であることを頭にとどめておいてほしいと思います。
日本企業の一番まずい点は、「こういう対応をしていたら安全だ」と形だけを整えてあとは何もしない、適当にPDCAを回しておくという態度です。
それも大切なのですが、本当に大切なのは現地で監督機関に気軽に尋ねていっていろいろ相談をしながら一緒に問題解決を図ってくれる存在です。

そうやって監督機関と信頼関係を築きながらともにデータ保護体制を整えるようなことができるようになればそれがベストな対策というべきでしょう。

では、GDPRの是正措置について書いていきます。

GDPR第58項(1)によると、監督機関には次の権限があります。

(a) 管理者、処理者(該当する場合は管理者、処理者の代理人)に対して業務を行うために必要な情報提供をするように命じる
(b) データ保護監査という形で調査を実施する
(c) 発行された認証のレビューを実施する
(d) GDPR違反の申し立てがあった場合、管理者または処理者に通知する
(e) 業務を行ううえで必要となるあらゆる個人データへのアクセスと関連情報を管理者、処理者から入手する
(f) EU又は加盟国の手続法に従って、管理者、処理者の持つ、あらゆるデータ処理装置や手段へのアクセスを含め、敷地内にアクセスする

権限行使の結果、是正措置が必要となる場合については、GDPR第58条(2)でその種類が示されています。
ちなみに、制裁金について記載されているGDPR第83条(2)には、GDPR第58条(2)の(a)から(h)および(j)に追加して、またはそれらの代わりとして制裁金を課す、と記載しています。GDPR第58条(2)(i)は「制裁金を課す」というものなのですこし回りくどい書き方です。

以下、是正措置を見ておきましょう。

(a) 意図された処理業務がGDPR違反となる恐れがある場合、警告を発する
(b) 処理業務がGDPR違反となっている場合、管理者、処理者に戒告を発する
(c) GDPRに基づくデータ主体の権利行使要求への対応を管理者、処理者に命ずる
(d) 管理者、処理者に対して、処理業務をGDPRに準拠したものとさせる。該当する場合は指定の方法、かつ指定期間内に命ずる
(e) データ主体に対してデータ侵害が生じたことを通知するよう管理者に命じる
(f) 処理の禁止を含む、一時的または永続的な制限を行う
(g) 個人データ処理の修正、削除、制限に対応するよう命じる。開示先に対して修正、削除、制限に対応するよう通知することを命じる
(h) 認証を取り下げる。認証団体に発行した認証を取り下げるよう命じる。認証の要件が合致しなくなった場合は認証団体が認証をそれ以上出さないよう命じる
(i) 制裁金を課する。各状況に応じて本項目に記載されていることの代わりまたは本項目に記載されていることに追加して制裁金を課する。
(j) 第三国または国際組織内の受領者へのデータ・フローをいったん停止するよう命じる

次回からはは制裁金の金額と違反内容について説明します。

個人データのセキュリティ・アセスメント(CNIL)

CNILがGDPR対応の一環として個人データのセキュリティについてガイドラインを作成しています。今日は、ここで示されているアセスメントシートの設問をご紹介します。

以下の項目について対応できてきるかをご検討ください。

1.ユーザの認識向上

1-1. データを処理する人たちに対してデータ・セキュリティについての教育を行っていますか?担当者のセキュリティについての認知度を向上させていますか?

1-2. IT利用の原則を書面化し、実際に運用できていますか?

2.承認

2-1. 各ユーザにユニークな(ログイン)IDを与えていますか?

2-2. 監督機関推奨のパスワードポリシーを採用していますか?

2-3. リセット後パスワードを再設定するよう各ユーザに要求していますか?

2-4. アカウントへのアクセスの試み(回数)を制限していますか?

3.アクセス制限

3-1. 権利プロファイル(authorisation profile)を定義していますか?

3-2. 使用しなくなったアクセス権限を削除していますか?

3-3. 権限の年次レビューを行っていますか?

4.アクセスログの記録とインシデント管理

4-1. ログ記録システムを実装していますか?

4-2. ログ記録システムを実装していることをユーザに知らせていますか?

4-3. ログ記録装置およびログ情報を保護していますか?

4-4. 個人データ侵害通知手順を整理していますか?

5.ワークステーションの安全確保

5-1. 自動でセッションをロックする機能を整備していますか?

5-2. ウィルス対策ソフトを定期的に更新していますか?

5-3. ファイアーウォール・ソフトをインストールしていますか?

5-4. ユーザのワークステーションを(リモートアクセス等で操作する際)ユーザの同意を事前にとっていますか?

6.モバイルデータ処理の安全確保

6-1. モバイル装置に暗号化を施していますか?

6-2. データを定期的にバックアップ、同期させていますか?

6-3. スマートフォンをロック解除するためにパスワードやパターン認識等を用いていますか?

7.内部ネットワークの保護

7-1. ネットワークトラフィックを必要最低限に限定していますか?

7-2. モバイル・コンピューティングへのリモートアクセスをVPN経由とし、安全を確保していますか?

7-3. Wi-FiネットワークにはWPA2プロトコルまたはWPA2-PSKプロトコルを採用していますか?

8.サーバの安全確保

8-1. ツールや管理インターフェースへのアクセスを有資格者のみに限定していますか?

8-2. 重要なアップデートを遅滞なく行っていますか?

8-3. データの可用性を確保していますか?

9.ウェブサイトの安全確保

9-1. TLSプロトコルを用い、その実装を確認していますか?

9-2. URL経由でパスワードやIDが転送されないことを確認していますか?

9-3. ユーザに入力してもらう項目は想定範囲内のものですか?

9-4. サービス提供に不要なクッキーに対しては同意バナーを準備していますか?

10.継続性の確保

10-1. 定期的なバックアップを行っていますか?

10-2. バックアップメディアは安全な場所に保管されていますか?

10-3. バックアップの移送には安全策を施していますか?

10-4. 事業の継続性を検証するプロセスを用意し、定期的に検証していますか?

11.アーカイブの安全確保

11-1. アーカイブデータへのアクセスについてアクセス方法を指定し、実装していますか?

11-2. 不要となったアーカイブは安全に破壊していますか?

12. メンテナンス監視とデータの破壊

12-1. レジスタでメンテナンス記録をつけていますか?

12-2. 組織内の責任者がサードパーティによる作業を監督していますか?

12-3. ハードウェアを廃棄する前にデータを全消去していますか?

13. データ処理者の管理

13-1. 外注処理者との契約に特定の条項(GDPR28条に準じた条項)を追加しましたか?

13-2. データ回復条件およびデータ破壊条件を整理していますか?

13-3. 実施している安全策が実効性を持つことを確認していますか?(セキュリティー・オーディット、現場監査等)

14. 他の組織とのデータ交換時の安全確保

14-1. 送信前にデータを暗号化していますか?

14-2. 送信相手が正しい相手か確認していますか?

14-3. 機密情報を別送で、異なるチャネルを用いて送っていますか?

15. 物理セキュリティ

15-1. 敷地内へのアクセスは鍵付のドアで制限していますか?

15-2. 侵入防止アラームを設置し、その動作を定期的に確認していますか?

16. ソフトウェア開発の監督

16-1. プライバシーとエンドユーザを尊重するようなパラメータを提供していますか?

16-2. コメント入力欄の設置を避け、設置している場合は厳しく監督していますか?

16-3. 架空データまたは匿名データでテストを実施しましたか?

17. 暗号機能の使用

17-1. 利用しているアルゴリズム、ソフト、ライブラリは広く認められているものですか?

17-2. 秘密の情報や暗号キーは安全な方法で保存していますか?

データ保護体制の構築

GDPRの施行が一週間後に迫ってきました。
データ保護のコンサルタントとしては少し落ち着かない気分になります。

GDPR対応はまだ端緒についたところのようで、大企業中小企業問わずこの時期でも問い合わせが多くあります。
とにかくスタートすることが大切なので、議事録をつけるという簡単なことからでも行動に移していただければ幸いです。

日本は大丈夫ではという声も聞こえてきますが、対応しておくことを強く勧めています。
欧州では大企業であれば数千万円から一億円以上かけて各社対応しているといいます。彼らはそれだけコストアップしているわけです。
これは欧州企業にとっては業績に対してネガティブ要素として働きます。グローバルにビジネスが展開する中、欧州が自分たちだけネガティブになるように動くというのは考えられません。欧州は、GDPRを世界標準とし世界中の企業が同じ土俵にのるよう促すことでしょう。

実際GDPRは世界標準となりつつあります。
韓国、シンガポール、南米諸国は法をGDPRに近しい形に変えつつあります。

何がいいたいかというと、最終的にはグローバルでGDPRと同様の体制が求められるということです。

現状、日本企業の対応は「欧州データだけ」というスタンスが多いのが事実です。
しかし、「欧州データだけ」というのは逆に複雑な対応を迫られる場合もあります。

世界の潮流がGDPRに向かっているのであれば、社内全体のデータ保護体制をGDPRにあわせてしまうというのが長期的に見てもっともコストがかからない方法だと思います。

データマッピングのポイント

コンサルティングをしている中で感じるデータマッピングのポイントを書いておきます。
データマッピングはデータの棚卸しをするために行います。データ保護体制の基本となるのですが、なぜかまだ標準的な方法が定まっていないようです。

日本企業の場合、データマッピング作業は初めて行うことが多いものです。
そのため規模の大きな会社では作業が膨大となり、通常2、3ヶ月を要します。欧州の個人データを扱っている業務が少ない会社でも、書き出してみると意外とわかっていないことが出てくるものです。現状把握作業とは、得てしてそういうものかもしれません。

規模が大きくなることが見込まれる場合、はじめからソフトウェアを導入したほうがよいでしょう。
規模が大きいかどうかの目安は、年間に行うデータ保護影響評価(DPIA)を行う件数で判断したらよいといわれています。
年間DPIAを実施する件数が20件以下であるならばエクセルで管理したらよいでしょう。これを超えるのであればソフトを導入したらよいと思います。

有事の説明責任を考慮するとソフトは英語で使用することを薦めます。
また、北米、欧州には安価で完成度の高いソフトを作成しているソフトウェア会社が数多くあります。
デモンストレーションも受けられるため、ベンダーリストを入手してしっかりと調査をしていただければと思います。

データマッピングを行う場合、GDPR第30条の処理記録を意識して作ってください。
データマッピングが終わったとき、GDPR第30条の処理記録が完成していることが理想です。
作業をいかにシンプルにするかを考えてください。

データマッピングを行う際、かならずデータフローも同時に追うことになります。
データフローは直感的に理解できるよう整理できれば一番ですが、これは少し慣れが必要です。

マイクロソフト社のVISIOを用いてプロセスとそこで得られるデータ種、保管形態、セキュリティ体制を整理していく手法がよいかと思います。
フレームワークとしてはSIPOCを活用するのが整理しやすいと思います。

SIPOCとは6シグマという手法で用いるフレームワークで、データの供給者からどういうインプットがあり、データの受領者にどういうアウトプットが出て行くのか、一行ずつ書き出します。一人で書くのは難しいので、チームで一緒に書くのが良いでしょう。チームと話をしながら書くことで抜け漏れが防げます。

WP243 rev.01 – DPOのガイドラインを読む(その18:最終回)

DPOのガイドラインもようやく最終回です。
ほぼ全訳をしてきましたが、読者の方のお役に立てたところがあれば幸いです。

GDPRの隠れたリスクは第27条で規定されているrepresentativeです。DPOについての情報は割と出回っているのですが、こちらの情報は非常に少ないですね。
欧州域内での選任義務があるので忘れず対応なさってください。

WP29のDPOのガイドライン(WP243 rev.01)の続きです。
(このブログではコメント機能はつけていませんが、ご質問等ございましたらメールにてお問い合わせください。)

今日は4 Tasks of the DPO (DPOの職務)のうち、
4.5 Role of the DPO in record-keeping(記録保持におけるDPOの役割)を見ていきます。


GDPR第30条(1)、(2)で規定される記録義務は、管理者、処理者が負うべき義務ですが、実際にはDPOが個人データのインベントリや処理業務の記録をもつことが多くあります。

(法律上は管理者、処理者は「その責任の下処理の記録をメンテナンスする」または「管理者のために行っている処理活動の種類すべての記録をメンテナンスすること」を要求されています。)

このようなDPOの実際上のあり方は、現行法や欧州機関に適用されるデータ保護法の下確立されたものです。

GDPR第39条(1)に示されているDPOの業務は最低限のものでしかありません。
管理者、処理者が処理業務の記録をメンテナンスする業務を、管理者、処理者の責任の下DPOに依頼することはまったく問題ありません。
この記録を用いることでDPOは管理者、処理者が適法に処理を行っているかを監視し、情報を提供したり助言を与えたりすることができます。

どのような形態をとるにせよ、GDPR第30条が求める処理記録のメンテナンスは、管理者、監督機関にとって、
必要なときにその組織が行っている全個人データ処理活動を概観することができるツールとなると考えるべきです。したがって第30条処理記録は、適法性の前提条件であり、効果的なアカウンタビリティの手法として欠かせないものといえます。

WP243 rev.01 – DPOのガイドラインを読む(その17)

WP29のDPOのガイドライン(WP243 rev.01)の続きです。
(このブログではコメント機能はつけていませんが、ご質問等ございましたらメールにてお問い合わせください。)

今日は4 Tasks of the DPO (DPOの職務)のうち、
4.3 Cooperating with the supervisory authority and acting as a contact point(監督機関との協同およびコンタクト先としての役割)4.4 Risk-based approach(リスク・ベースド・アプローチ)を見ていきます。


【監督機関との協同およびコンタクト先としての役割】
GDPR第39条(1)(d)、(e)には「監督機関に協力」し、「第36条で触れられている事前相談を含め、処理に関する問題および、それが適切であれば、その他のことがらについての監督機関のコンタクト先と」なる存在がDPOであると規定されています。

DPOはいわば「ファシリテータ」のような役柄です。
監督機関が第57条で規定された職務を行うに当たって、組織内文書や組織内情報にアクセスする際のファシリテータを行います。また、監督機関が第58条で規定された職務を行うに当たって、調査、修正、許可、助言を執行するファシリテータの役割も行います。

DPOはその職務について秘密保持義務を負いますが、DPOが監督機関に連絡をしたり助言を求めることは可能です。
GDPR第39条(1)(e)は、適切であれば、DPOが監督機関に相談することを可能としています。

【リスクベースドアプローチ】
GDPR第39条(2)には「その性質、範囲、文脈、および目的に鑑みて処理のリスクに十分注意を払っている」ことがDPOの職務の一つとして挙げられています。

DPOは「常識」に基づいて日常業務を行います。データ保護リスクの高い、「優先度の高い活動」に注力するのは自然な振る舞いです。
これはリスクがそれほど高くない処理業務についてGDPR適合性を無視してもよいという意味ではなく、まず優先度の高い活動から取り組む、という意味です。

どのような手法でDPIAを行うべきか、データ保護について内部監査、外部監査をどの分野について行わなければならないか、データ処理活動に責任を持つスタッフやマネジメント層に対してどのような内部トレーニングを提供すべきか、時間とリソースをどの処理業務に使うべきか、ということをアドバイスする際にも、このような選択的かつ現実的なアプローチをとること効果的な方法といえるでしょう。

WP243 rev.01 – DPOのガイドラインを読む(その16)

WP29のDPOのガイドライン(WP243 rev.01)の続きです。
(このブログではコメント機能はつけていませんが、ご質問等ございましたらメールにてお問い合わせください。)

今日は4 Tasks of the DPO (DPOの職務)のうち、
4.2 Role of the DPO in a data protection impact assessment(データ保護影響評価におけるDPOの役割)を見ていきます。


GDPR第35条(1)は管理者が必要な場合にデータ保護影響評価(DPIA)を行うことと定めています。
しかし、DPOはDPIAを補助する存在となりえます。「設計段階からデータ保護を織り込む」原則に従い、GDPR第35条(2)は管理者がDPIAを行う際、DPOに「助言を求めること」と特記しています。GDPR第39条(1)(c)ではDPOの職務として「DPIAについて、要求された場合助言を与え、第35条にしたがって執り行われていることを監視する」ことをあげています。

WP29は管理者はDPOに対して特に以下の場合助言を求めるよう推奨しています。

  • DPIAを実施すべきかどうか
  • DPIAを行う際にとるべき手法
  • DPIAを社内で行うか社外で外注すべきか
  • データ主体の権利と利益に対するリスクを低減するためにどのような保護策を採用すべきか(技術的、組織的手法を含めて)
  • データ保護影響評価が正しく執り行われているかどうか、およびその結論(処理を続けるべきかやどのような保護策を適用すべきか)がGDPRに適合しているか
  • 管理者がDPOの助言に同意できない場合、DPIA結果は書面でまとめ、DPOの助言がなぜ採用されなかったかを特に説明しなければなりません。

    WP29はさらに、特にDPIAを行ううえでのDPOの職務を管理者が明確に規定し、従業員やマネジメント層(およびその他のステークスホルダに対しても)に周知しておくことを推奨しています。