JETRO広島さんでのワークショップは日本全国からご参加いただけるようです。それだけGDPRについての情報が足りていないということなのだと思います。
私もJETROさんのご依頼でいろいろとご説明に伺っていますが、月数件が限度であり、まだまだ専門家が足りていないと感じます。

JETROさんではGDPRの専門家をあと3名追加したと聞いています。ぜひご活用いただいたらと思います。

引き続き「透明性のガイドライン(WP260 rev.01)」を読んでいきます。
—
＜情報提供のタイミング(Timing for provision of information)＞

【26】
データ処理のサイクルの開始時点でデータ主体に提示しなければならない情報の種類を定めているのがGDPR第13条とGDPR第14条です。
GDPR第13条はデータ主体から直接データを取得するとき、GDPR第14条はデータ主体から間接的にデータを取得するときを想定しています。

直接取得するときとは以下の場合です。

間接的に取得するときとは以下の場合です

【27】
情報提供のタイミングはとても大切です。適切なタイミングに情報を提供できているかどうかで透明性の義務やデータを公正に処理する義務を果たせているかが決まります。
GDPR第13条が該当する場合はGDPR第13条(1)で記載されているように、「個人データが取得されるタイミング」で情報を提示しなければなりません。

GDPR第14条が該当する、間接的に個人データが取得される場合はGDPR第14条(3)(a) – (c)に定められるタイミングでデータ主体に情報を提供しなければなりません。

引き続き「透明性のガイドライン(WP260 rev.01)」を読んでいきます。
—
＜適切な方法で(Appropriate measures)＞

【24】
内容と並んで重要なのが、GDPR第13条、GDPR第14条で要求される情報の提供される方法です。
GDPR第13条、GDPR第14条の内容を含んだ通知は、data protection notice、privacy notice、privacy policy、privacy statement、fair processing noticeといった呼び方で呼ばれます。GDPR上にはフォーマットの指定や様式の指定はありませんが、透明性の原理に基づき、「適切な方法」で必要な情報をデータ主体に伝達する義務が管理者にはあるとしています。

管理者はデータが取得される場面、データが処理される場面をよく検討した上で、様式やフォーマットを決定する必要があります。

特に「適切な手段」であるかどうかは、提供するサービス/製品の観点から評価されなければなりません。
使用する装置は何か、管理者とユーザの間のインタフェースはどこにあるか、ユーザとのやり取りはどのようにしているか、といったことを考えてください。
管理者がオンラインでのユーザとの接点を持っている場合は、privacy statement/noticeは階層化された形で提供されるべきです。

【25】
情報提供にもっとも適切な様式を特定する目的でユーザテストを行うこともできます。
ユーザテストでは、提供した方法がユーザにとってどれくらい容易にアクセス可能か、理解できるか、容易に利用できるかを確認できます。
管理者は説明責任を果たす意味でもこのプロセスを文書化しておくとよいでしょう。

情報を伝えるためのもっとも適切な方法を選択する上でのプロセスを明確にすることができます。

アメリカのカリフォルニア州で可決されたプライバシー法は大きなインパクトがあるようですね。
連日大きく報道されています。今後も新しい情報があれば随時アップデートしていきます。

引き続き「透明性のガイドライン(WP260 rev.01)」を読んでいきます。
—
＜無料で(…free of charge)＞

【22】
GDPR第12条(5)によると、管理者はGDPR第13条、GDPR第14条に基づく情報通知を行うことへの課金はできません。
同様に、データ主体の権利行使に関するコミュニケーションや行動（GDPR第15条 – GDPR第22条）および個人データ侵害の伝達（GDPR第34条）についても課金はできません。

これを敷衍していえば、透明性の原理に関する要求は無料で行うべきといえます。これは商品・サービスの購入を条件とすることも含んで課金できないということに注意してください。

【データ主体に提供すべき情報（GDPR第13条、GDPR第14条）】
<内容（Content）>
【23】
GDPRでは個人データをデータ主体から直接取得した場合(GDPR第13条)またはデータ主体以外から取得した場合(GDPR第14条)に通知すべき情報を定めています。
この表にはこれらの要求の本質、スコープ、内容についても記載しています。WP29としてはGDPR第13条、GDPR第14条の(1)、(2)の要件に従って提供する情報に本質的な違いはないと考えています。
これらの条項で記載されている情報はどれも等しく重要なので、データ主体に必ず提供されなければなりません。

7月9日の交流会は定員に達しましたので新規の募集を終了いたします。
参加ご希望の方は直接弊社あてにご連絡いただければ幸いです。

引き続き「透明性のガイドライン(WP260 rev.01)」を読んでいきます。
—
＜口頭での情報通知も可能(…the information may be provided orally)＞

【20】
GDPR第12条(1)では特に、データ主体からの要求があれば口頭での情報提供も可能とされています。
この場合、データ主体の身元確認を行っておく必要があります。この身元確認は名前の確認だけではなく、より高い確からしさをもってデータ主体が当人であることを確認できる方法である必要があります。

この口頭での情報提供が許容されるのは、GDPR第15条からGDPR第22条およびGDPR第34条に記載されているデータ主体の権利行使を行う場合に限ります。

GDPR第13条、GDPR第14条で要求されている情報通知はこれからユーザとなる人やこれから顧客となる相手に伝えられる必要があります。（それらの相手について管理者は相手を特定する術を持っていません。）
GDPR第13条、GDPR第14条で要求されている情報通知を口頭で行いたい場合は、データ主体の身元確認を必要としない場合のみに許容されることとなります。

【21】
GDPR第13条、GDPR第14条で要求されている高騰での情報提供は、必ずしも人-人のコミュニケーションである必要はありません。
文章での情報に追加する形で自動音声での情報を提供するということも考えられます。

目の不自由な人が情報社会サービスを使用する場合や【19】で言及したようなスクリーンのないスマートデバイスでは自動音声を使用するというオプションがあり得ます。

管理者が音声での情報提供を行う場合、又はデータ主体の要求にしたがって音声での情報提供を行う場合、WP29としては事前に録音しておいた音声情報をもう一度聞けるようにすることが好ましいと考えています。目の不自由なデータ主体や文章での情報通知にアクセスすることができないデータ主体にとっては、自動音声をもう一度聞けるという選択肢があることがとても大切なことです。

データ管理者は(i) 口頭での情報提供の要求があったこと、(ii)データ主体の身元を確認した方法(【20】参照)、(iii)データ主体に情報が提供されたという事実
といったことを確実に記録し、説明責任を果たすために実証できる必要があります。

2018年6月29日アメリカのカリフォルニア州で新しいprivacy法が誕生しました。
California Consumer Privacy Act of 2018と呼ばれるこの法律はGDPRに近い内容の法律であり、世界中の法律がGDPRに倣い始めていることのあらわれと言って良いと思います。チリでも同様の動きがあり、新憲法にプライバシー法が追記されました。

特に処理の原則については同等の要求が世界中でなされることとなるでしょう。
GDPRを契機に社内のデータ保護体制を見直し始めたほうが良いかもしれません。

GDPRについて、少し気になるニュースも出ています。
6月25日にスロバキアのデータ保護当局が次のようなコメントを出しています。
「２年の準備期間は与えられたのだから零細、小規模、中規模の企業に対して更なる猶予を与えることはない」

GDPRについて何もしないというのは少し難しい状況になりつつあるのではないかと感じます。

引き続き「透明性のガイドライン(WP260 rev.01)」を読んでいきます。
—
＜書面またはその他の方法で＞

【18】
電子媒体で階層構造となったprivacy statement/noticeを使用する以外の方法でも、文章による電子的な情報通知を行うことは可能です。
例えば「ジャスト・イン・タイム」方式で文脈に合った情報通知が表示される、3Dで表示される、宙に浮くような形態で表示される、プライバシーダッシュボード等で掲載される等さまざまな方法が取れることでしょう。ビデオやスマートフォン・IoTでの音声によるアラート等、文章によらない情報通知方法も選択肢としてとることが可能です。

電子媒体でないという選択肢もあります。
マンガ、インフォグラフィックス、フローチャートといったものを活用するのも良いでしょう。

子供に向けて透明性の原理についての説明を行う場合は、特に、子供にとってどういう方法がもっともアクセス性が高いかを考えてください。
マンガなのか、ピクトグラムなのか、アニメなのか、といったさまざまな選択肢を取れると思います。

【19】
情報通知を行う方法を選ぶ際は、管理者とデータ主体が接触する場面やデータ主体のデータが取得される場面にふさわしい形で情報通知が行われることを心がけてください。
IoTデバイスやスマートデバイス等、ウェブサイトにアクセスできない、またはスクリーン上で情報通知を確認することができないようなときに、オンライン上でprivacy statement/noticeを掲示しているだけでは不十分といわざるを得ません。

そのような場合、適切な追加措置を行わなければなりません。取扱説明書にprivacy statement/noticeを（ハードコピー形式で）記載する、ハードコピーの取扱説明書やパッケージそのものにprivacy statement/noticeを確認可能なURLウェブサイトアドレスを記載する、といった方法がその一つとして考えられるでしょう。

スクリーンがない装置で音声を用いることができる場合は、音声による情報通知を追加措置として使用することが可能です。
WP29はIoTについて意見(opinion)を出しています。（Opinion 8/2014）IoT製品にQRコードをつけて透明性に関する情報を提示する等、データ主体への情報提供のあり方を掲載しています。GDPR対応を行ううえでも参考にしてください。

引き続き「透明性のガイドライン(WP260 rev.01)」を読んでいきます。
—
＜子供やその他社会的弱者への情報提供について＞

【16】
身体障碍者や情報へのアクセスが困難な社会的弱者に向けて商品、サービスが提供される場合、またはそのような人々を対象とした商品、サービスである場合、データ主体が社会的弱者であることを考慮した情報通知が必要です。
透明性の原理を実現するために最善の方法とはどのようなものか、検討する必要があります。管理者は、商品、サービスの対象者がどの程度の理解度を持つか【９】で述べた基準に従って評価しなければなりません。

＜書面またはその他の方法で＞

【17】
データ主体への情報通知の方法としてGDPR第12条(1)で前提とされているのは、書面での情報通知です。(GDPR第12条(7)では標準化されたアイコンを用いるようにとされています。【49】、【53】でこれは取り上げます。)ただし、「電子的な手段」等様々な方法も取り得る点はGDPRも認めています。

管理者が維持運営している、ウェブサイトについては、階層化されたprivacy statement/noticeを使用することをWP29は推奨しています。
privacy statement/noticeが階層化されていれば、ウェブサイトの訪問者は迷うことなく知りたい場所に移動できます。(【35】、【37】で解説します。)
これと同時に、データ主体が情報全体に容易にアクセスできるようにもしておかなければなりません。（電子的な形態、紙面を問いません。）

階層構造を用いるのはウェブサイト等電子情報だけに限ったことではないことに注意してください。
処理の透明性を確実にするためにはいくつかの手法を組み合わせてデータ主体に情報を通知する方法も取り得ます。（【35】、【36】、【38】）

以前の名刺交換についてのポストに関連して情報を少し補足しておきます。

名刺情報を用いたダイレクト・マーケティングについてです。

弁護士事務所のfieldfisherが公表している欧州域内でのe-marketingについての各国要件をまとめた資料をみると、B2Bのやり取りであっても、個人に送付する場合はOpt-inを求めている加盟国が数多くあります。（詳細は資料を参照ください）

（カナダのAnti-spam法）展示会で名刺boxをおいておきそこに名刺を投入する等、affirmativeな行動とみなされれば、opt-inが成立していると考えることもできると考えられているため、そのような工夫をする必要があるかもしれません。

ダイレクト・マーケティングをopt-outで行えるのは以下の場合です。
– 相手の情報を「販売活動の一環として」取得している
– マーケティング情報の送り手と相手の情報の収集者は同一法人、同一会社である
– マーケティング情報の内容はマーケティング情報の受け取り手が当初名刺交換をしたときに提示されていたものと類似製品またはサービスについてである
– マーケティング情報の受け取り手は無料でマーケティング情報を拒否することができる。（データ取得時でも、その後でも）

ダイレクト・マーケティング関連でのICOの最近の制裁金事例があります。（２０１８年６月２０日）
イギリスのPECRという法律に基づくものですが参考になると思います。
BT fined £77,000 by the ICO for five million spam emails

その他、ICOの公表している違反事例はこちらで調べられます。

いずれにせよ、ダイレクトメール送付の際は注意が必要です。

引き続き「透明性のガイドライン(WP260 rev.01)」を読んでいきます。
—
＜子供やその他社会的弱者への情報提供について＞

【14】
データ管理者が子供を対象としている場合、または自社のサービスや商品を子供が利用していると認識している場合（子供の同意を適法根拠としている場合を含む）、使用する語彙、文章の調子、書き方は子供にとって適切なものとしなければなりません。これは子供が、その情報通知が自分に向けて書かれたものであると認識できるようにするためです。

子供に向けて書かれたものとして参考になるのは次のサイトです。参照にしてください。
UN Convention on the Rights of the Child in Child Friendly Language

【15】
WP29は「透明性」というのは大人にも子供にも等しく与えられた独立した権利と考えています。
子供だからといって「透明性」について説明を求める権利を失わない、というのがWP29の立場です。たとえばGDPR第８条にしたがって、子供の同意が親権者によって確認されていたとしてもこの点は変わりません。

子供の同意についての親権者の確認は一度きりであることが多いでしょうが、子供も他のデータ主体と同様、管理者に自身の個人データを提供している限り、いつでも透明性について説明を求める権利を持っています。
これはUN Convension on the Rights of the Child（国連子供の人権憲章）第13条とも呼応しています。

したがって管理者はGDPR第12条(1)（およびGDPR前文38、GDPR前文58）に従って、子供向けに透明性を担保する方法を提供する義務を負います。
管理者は自社の商品、サービスの対象が子供である、または子供が利用するものであることを認識している場合、子どもが容易に理解できるような明確で平易な言葉または伝達方法でなされなければならないということを肝に銘じてください。

ただし、とても幼い子供や文字を読めない子供の場合は、子どもが透明性の原理自体を理解しえないため、親権者向けに情報通知を行うケースもあることはWP29も認めています。

引き続き「透明性のガイドライン(WP260 rev.01)」を読んでいきます。
—
＜明確で平易な言葉＞

【13】
ガイドラインで使用を避けるべきとされている表現は以下のものです。
“may”、”might”、”some”、”often”、”possible”

業界的、職種的に使用せざるを得ない場合は、説明責任の原則に基づき、なぜこれらの「ぼかした」表現を使わざるを得ないのか、それによって処理の公平性を既存することがなぜないといえるのかについて、管理者は説明できなければなりません。

パラグラフ構成、文章構成も練られたものであるべきです。
列挙方式を用いたり、インデントを用いて階層構想を明確化してください。

文章は受動態ではなく能動態を使います。
名詞中心の表現ではなく動詞を使った文章とします。

法律用語や技術用語、特殊用語、述語を使いすぎてはなりません。

二つ以上の言語に翻訳される場合は、翻訳の正確性を確認してください。言葉使いや構文が難解でないよう注意が必要です。
（情報通知は、管理者が販売を意図している地域の言語で行う必要があるため、複数言語に翻訳が必要です。）

引き続き「透明性のガイドライン(WP260 rev.01)」を読んでいきます。
—
＜明確で平易な言葉＞

【12】
書面で情報が提供される場合、（目の不自由な人に説明するために）書面で提供された情報が口頭で説明される場合、音声で説明される場合、音声と画像で説明される場合には、「明確な」書き言葉となるように工夫が必要です。
同様の要件はこれまでもEU法の中で用いられてきています。（例：消費者契約の公平性を欠いた条項についての指令 93/13/EEC(1993/04/05)の第５条）GDPR前文42にも「同意」の文脈で「平易」で「理解可能な言葉」という表現が用いられています。

「明確で」「平易な」言葉とは、情報の提供が可能な限りシンプルな形で行われること、文や言語の構造が複雑なることを避けることを意味しています。
具体的な情報を提供し、内容も明快なものである必要があります。抽象的な言い回しやどちらとも取れる言葉使い、他の意味に取れる余地があってはなりません。
特に、目的の部分、適法根拠の部分については注意が必要です。

===============
（ガイドラインで提示されている例）
『悪い例』

『良い例』

===============