透明性のガイドライン(WP260 rev.01)を読む(41)

日経新聞が中国のサイバーセキュリティ法(インターネット安全法)について報道を始めました。
例によって危機感をあおる報道となっていますが、先日参加したIAPPのアジア・プライバシー・フォーラムではアカウンタビリティを果たしていて、
かつ越境移転のプロセスを踏んでいれば大きな問題はないという認識でした。

当社もそれをうけて、中国のサイバーセキュリティ法への対応というよりは、プライバシー・マネジメントのフレームワークを導入するほうが先だとアドバイスをしています。
小手先の対応は結局コスト高になるだけでなく、組織内の混乱を招くことでしょう。新聞報道は「ニュースになる」内容を報道するので、注意が必要です。

引き続き「透明性のガイドライン(WP260 rev.01)」を読んでいきます。

<データ主体の権利行使>
【63】
GPDR全文62で言及されている要因(データ主体の下図、データの古さ、適切な安全保護措置)は管理者が「不当に過大な努力」を要すると判断する際の基準となります。

例)
ある姓に基づいて系列を調査する歴史的調査で、2万人のデータ主体に関する系列データセットを間接的に入手したとします。
このデータセットは50年前に収集されたものであり、それ以降更新されておらず、また連絡先情報も含んでいません。
この場合、データサイズが大きいこと、更にデータが古いことに鑑みて、データ主体一人ひとりにコンタクトすることは「不当に過大な努力」を要すると判断できます。

透明性のガイドライン(WP260 rev.01)を読む(40)

イタリアのニュースです。あるメーカーがGPSシステムを社用車に搭載し、120秒ごとに従業員データ(車の位置、運転時間、ブレーキの時間)を取得していました。その会社は、従業員に当該システムについて適切に通知しておらず、1年間取得したデータを保管していました。(それによって従業員を継続的に監視することができていた)

DPAはそれを不当と判断し、取得したデータや保存していたデータについてデータ処理を停止するよう命じられました。

引き続き「透明性のガイドライン(WP260 rev.01)」を読んでいきます。

<過大な努力 (Disproportionate effort)>
【62】
GDPR第14条(5)(b)でいう「不可能」または「過大な努力」が何に該当するかは、GDPR第13条のケースと同じ基準で判断します。
両者の違いは、GDPR第14条のケースでは、データが直接個人から取得されたわけではない点です。

GDPR第14条(5)(b)の「不可能」または「過大な努力」を適用する際は、データ主体から直接取得されていないことがポイントとなります。

例)
ある大都市の病院では、日帰り手術、長期入院、予約の際に患者情報を記入するように求めています。この患者情報には二親等の親族情報を記載することとなっています。
この病院では日々多数の患者が出入りしており、フォームの二等親の親族情報に記入されたデータ主体にGDPR第14条で要求される情報を通知することは、事実上不可能と判断できます。

透明性のガイドライン(WP260 rev.01)を読む(39)

ドイツDPAは、従業員は個人データ保護の取り扱いにのみ組織に対して責任を負うことを明言しました。DPOは助言し、組織のデータ保護法に対する相談を受け、監督するする立場に過ぎないことも再確認しました。また、組織は、業務において苦情にどう対応するのか従業員を訓練し、是正方法として従業員を律する方法を考える義務を負うとしました。

引き続き「透明性のガイドライン(WP260 rev.01)」を読んでいきます。

<不当に過大な努力を要する場合>
【61】
GDPR第14条(5)(b)では、「情報提供が不可能である場合」と並んで、「不当に過大な努力を要する場合(特に、アーカイブ目的、科学的/歴史的調査目的、または統計目的の場合)」が上げら手います。

GDPR前文62に、この部分についての言及があります。
ここでは、データ主体の数、データの古さ、採用されている安全保護策について考慮するように述べられています。

WP29の立場としては、上記に鑑みて「アーカイブ目的、科学的/歴史的調査目的、または統計目的」で個人データを処理していない管理者は「不当に過大な努力を要する」という例外規定を定常的に利用すべきではないと考えています。

「アーカイブ目的、科学的/歴史的調査目的、または統計目的」場合はGDPR第89条(1)で記載されている安全保護策を適用している必要があり、情報提供は管理者の「当然な努力」に合致するものであるべきと考えてください。

透明性のガイドライン(WP260 rev.01)を読む(38)

中国でAIの標準化についての勧告が出されました。
中国工信部は、AIについての標準について、トップレベルでの設計強化を提言しました。
その目的は産業界の鍵となる開発方針を確立すること、鍵となるAI技術についての調査を促進しオープンで互換性がある安定したシステムを形成すること、プラットフォーム・サポート・技術面・製品サービス・アプリケーション・安全・倫理につちえのAI標準の開発を促進すること、倫理とプライバシーに関連した法を改善することにあります。

引き続き「透明性のガイドライン(WP260 rev.01)」を読んでいきます。

<データの出所情報を提供できない場合>
【60】
GDPR前文61では以下の通り述べられています。
「複数のデータ源を用いているため個人データの出所情報をデータ主体に提供できない場合は、一般的な情報を提供しなければならない(where the origin of the personal data cannot be provided to the data subject because various sources have been used, general information should be provided)」

これが該当するケースも、限定的と理解してください。
例えば同一のデータ主体に関する個人データが複数あってある特定の情報源と結びつけることができないケース等です。

複数のデータ主体を含むデータベースをいくつか併せて一つのデータベースにしただけの場合は、(時間がかかり労力がかかるかもしれませんが)情報源を特定することが可能であるため「一般的な情報」を提供するだけでは不十分です。

Data protection by design and by defaultの要求がGDPRにはあるため、組織が受け取った個人データの出所がデータ処理のライフサイクルのどの時点でも追跡可能なように、最初から処理システムに透明性の原理を担保するメカニズムを織り込んでおく必要があります。(【43】参照)

透明性のガイドライン(WP260 rev.01)を読む(37)

ケニヤがデータ保護法案を提出しました。
法案が通ると、商業目的での個人データ処理が許されるのは、同意がある場合または法律によって要求された場合のみとなります。
例外規定に該当したときにのみ特別な個人情報(宗教、人種、健康データ)の処理が可能となります。
プライバシー権は状況によっては制限されることがあります。不正処理や不正アクセスは国の委員会および影響を受けた個人に通知されなければなりません。

引き続き「透明性のガイドライン(WP260 rev.01)」を読んでいきます。

<不可能である場合>
【59】
GDPR第14条(5)(b)がいうところの「不可能である場合」というときの「不可能」が何を指すのかは示されていません。
管理者は、「不可能」という限り、当該情報をデータ主体に通知することを妨げている実際の要因を例示しながら「不可能であること」を示さなければなりません。
一定期間経過後、「不可能」であった要因が解消された場合、管理者は直ちにデータ主体に情報を通知する必要があります。

現実問題として、「不可能である場合」と示すことができるケースはごく限られたケースのみとなるでしょう。

例)
あるデータ主体が後払いのオンライン購読サービスに登録したとします。登録後、管理者は信用調査会社からそのデータ主体についての信用データを入手し、サービス提供の可否を確認します。管理者は、GDPR第14条(3)(a)に基づき信用データを入手したことを、入手後3日以内データ主体に通知することにしています。

ところが、このデータ主体の住所も電話番号も公開されたレジストリにはありませんでした。(データ主体は外国に住んでいます。)
データ主体はe-mailアドレスを入力していませんでした。(または誤ったe-mailアドレスを入力していました。)

このような場合、管理者はデータ主体に直接連絡するすべがないということになります。

上記のケースの場合、しかし、信用調査データの収集について管理者は登録前にウェブサイトに記載するという方法をとることができます。
このような場合、GDPR第14条でいわれるところの「不可能」というのは当てはまりません。

透明性のガイドライン(WP260 rev.01)を読む(36)

4月から6月の間にオーストラリアのDPAに対して報告されたデータ侵害の下図は242件でした。
内訳は悪意のある攻撃が59%(フィッシング、不正アクセス、brute-force攻撃(パスワードの総当り攻撃)、書類・装置の盗難)、人的ミスが36%(誤送信、個人情報紛失、BCCの使用ミス)、システムの故障が5%となっています。コンタクト情報、金融情報、アイデンティティ情報、健康情報、納税者番号等が漏洩しました。

引き続き「透明性のガイドライン(WP260 rev.01)」を読んでいきます。

<不可能である場合、不当に過大な努力を要する場合、目的を大幅に損なう場合>
【58】
GDPR第14条(5)(b)は、GDPA第14条(1)、GDPA第14条(2)、およびGDPA第14条(4)で提示された情報を提供する義務を免除するケースについて記載しています。

  • 不可能である場合(特にアーカイブ目的、科学的/歴史的調査目的、または統計目的の場合)
  • 不当に過大な努力を要する場合(特に、アーカイブ目的、科学的/歴史的調査目的、または統計目的の場合)
  • GDPA第14条(1)で要求される情報を提供することで処理の目的を果たせなくなる場合、または処理の目的を大幅に損ねる場合
  • 投稿遅延のお詫び

    ここ一週間ほど投稿が滞ってしまっている点、大変申し訳ありません。
    少し仕事の負荷が高くなり、こちらに手が回っておりません。

    来週のお盆休みにかけてなんとか遅れを取り戻したいと考えておりますのでよろしくお願いいたします。

    透明性のガイドライン(WP260 rev.01)を読む(35)

    日本の個人情報保護法とGDPRはどこが違うのか、と問われることがあります。
    大筋においては両者は似ています。しかし、細かい部分(例えば要配慮データの種類や情報提供の要否)では異なる部分が多くあります。
    GDPRに相当なれた後でも、両者を同時に扱うと混乱してしまいます。

    一点言えるのは、解釈の指針は、GDPRと日本の個人情報保護法との間で類似しているということです。

    GDPRへの対応がまず第一なので、GDPR対応が終わった後に世界各国の法律を横並びにして要件の比較をするのがよいといえるでしょう。

    引き続き「透明性のガイドライン(WP260 rev.01)」を読んでいきます。

    <データ主体に情報通知をする義務がない場合>
    【GDPR第14条の例外事項】

    【57】
    GDPR第14条が定める例外事項は、管理者が個人データを直接取得する場合に比べて広範です。
    とはいえ、拡大解釈はしないでください。狭く限定的に解釈するのが正解です。

    データ主体が既に情報を入手している場合以外に、以下の例外事項をGDPR第14条(5)では述べています。

  • 情報通知自体が不可能である、または不当に過大な努力を要する場合(公共利益のためのアーカイブ目的、科学的・歴史的調査目的、統計目的、処理の目的を不可能とする、処理の目的の達成を著しく既存する場合)
  • データ管理者が加盟国法またはEU法の要求によって取得・開示することを要求され、データ主体の正当な利益に対して法が適切な保護策を提供している場合
  • 加盟国法またはEU法によって、専門家の守秘義務(法的な守秘義務を含む)に付されているとき、即ち機密情報
  • 透明性のガイドライン(WP260 rev.01)を読む(34)

    イスラエルのDPA(監督機関)は、制裁金を課すことができるほか、違反者を最大5年間の懲役に課す権限を与えられています。
    IT系、ベンチャー系でイスラエルと取引がある場合は要注意です。

    引き続き「透明性のガイドライン(WP260 rev.01)」を読んでいきます。

    <データ主体に情報通知をする義務がない場合>
    【GDPR第13条の例外事項】

    【56】
    管理者がデータ主体から直接データを取得する際にGDPR第13条に準拠した情報通知を行う必要がないのは、「データ主体が該当する情報を既に手にしている場合(where and insofar as, the data subject already has the information)」に限定されています。この場合においても、管理者は、データ主体が該当する情報を既に手にしているといえる合理的な理由を証明できなければなりません。(文書の提示も必要となるでしょう。)

    管理者が示すべき内容は以下の通りです。

  • データ主体が既に手にしている情報の具体的内容
  • いつ、どのように該当する情報を手に入れたのか
  • 該当する情報に変更がなく、情報が依然として最新であることの証拠
  • “insofar as”(~する限り)という表現が原文(GDPR第13条(4))で使用されているため、管理者はデータ主体がGDPR第13条(1)、(2)で定義された情報を完全な状態で確実に手にしていることを補償する義務があります。

    以下に、データ主体に情報通知をする義務がないと考え得る一例を、good practiceとして示します。

    (例)
    オンラインe-mailサービスにサインアップしたユーザがいるとします。
    ユーザはサインアップ時、GDPR第13条(1)(2)で要求されるすべての情報を入手しています。

    6ヵ月後、同じユーザがe-mailサービス提供業者の提供するインスタント・メッセージ機能を有効化しました。
    その際、電話番号を追加で提供しました。

    サービス業者はこの時点で電話番号の処理について、GDPR第13条(1)(2)で要求される情報の一部を追加提供しました。
    (処理の目的、処理の適法根拠、開示先、保持期間)しかし、6ヶ月前に既に提供されていた情報については、変更がなかったため情報通知を行いませんでした。
    (管理者の身元と連絡先、DPOの身元と連絡先、データ主体の権利、監督機関に苦情申し立てをする権利)

    Best Practiceとしては、再度、GDPR第13条(1)(2)で要求される情報をすべて提供しなおすことがよいといえるでしょう。
    とはいえ、データ主体はどの情報が「追加」で提供されたものかを理解できる必要もあります。

    要はバランスの問題ですが、6ヶ月前に提供された情報をデータ主体が覚えていない可能性があり、権利行使が可能であることを忘れている可能性があります。
    すべての情報を通知しなおすのが最もよい方法といえそうです。

    透明性のガイドライン(WP260 rev.01)を読む(33)

    引き続き「透明性のガイドライン(WP260 rev.01)」を読んでいきます。

    <データ主体の権利行使>
    【55】
    データ主体の権利行使についてGDPRで規定される要件や必要な情報の性質をみると浮かび上がってくることがあります。
    GDPRが意図しているのは、データ主体の権利を擁護し、管理者がデータ主体の個人データ処理について説明責任を果たす、ということです。

    GDPR前文59では「データ主体が権利行使を行うためのフォーマットを提供すべき」とされています。また、管理者は「電子的手法で個人データが処理されている場合は特に、電子的な手法で要求可能であるよう整備する必要がある」とされています。

    管理者は、データ主体との関係に鑑みて適切な形でデータ主体の権利行使が可能な様式を提供しなければなりません。
    そのため、管理者は複数の方法を用意することになるかもしれません。

    (例)
    あるヘルス・サービス提供業者は、データ主体が自身の個人データにアクセス権を行使するための方法として、オンライン、オフラインで次の二つの様式を準備しています。
    1.ウェブサイト上の電子的フォーム
    2.ヘルス・クリニックの受付においてある紙面の様式

    これに加え、手紙やemailでの問い合わせに対しても対応を行っています。また、データ主体が自身の権利行使について問い合わせをするための専用連絡先(emailまたは電話でアクセス可能)を準備しています。