CHAPTER 01. 漏えい等対応

本日の対談のテーマは、個人データの漏えい等となります。外部ゲストとして、一般社団法人JPCERTコーディネーションセンター(JPCERT/CC)の早期警戒グループマネージャーの佐々木勇人さんをお呼びしています。佐々木さん、どうぞよろしくお願い致します。

佐々木さんは、私が内閣官房内閣サイバーセキュリティセンター（NISC）で任期付職員として働いていたときに大変お世話になった方であり、弁護士に戻ってからも大変お世話になっております。さて、セキュリティ業界の人にとっては、JPCERT/CC（ジェイピーサート・シーシー）を知らないなんてモグリだろうと思いますが(笑)、この対談を読まれる方の中にはJPCERT/CCを知らない人もいるかもしれないので、JPCERT/CCという組織が何をしているのか、簡単にご紹介いただけないでしょうか。

ありがとうございます。佐々木さん自身のプロフィールについては、これがアップロードされたときに多分対談者のプロフィールが出ると思うので、そこを見てもらうということで。さて、これは豆知識ですが、NISCとの関係で申し上げると、サイバーセキュリティ基本法31条は、サイバーセキュリティ戦略本部の事務を政令で指定する法人に委託できる旨を定めております。これを受けて、サイバーセキュリティ基本法施行令5条（※1）に、指定法人としてJPCERT/CCが出てきます。一般社団法人であり、かつ、アルファベットが出てくるという結構レアな法令の条文だと思うので、ご関心があれば是非見てください。

余談ですが、電気通信事業法164条にIPアドレスが出てきますが、これも条文上はカタカナで「アイ・ピー・アドレス」ですよね。

仰るとおりです。法令の条文ってそうそうアルファベット使いませんよね。

ではそろそろ本題に入ります。ご承知のとおり、2020年の個人情報保護法改正により、一定の条件を満たす個人データの漏えい等及びその「おそれ」が発生した場合には、原則として個人情報保護委員会へ報告する義務と、本人への通知義務が導入され（個人情報保護法26条）、2022年4月1日から施行されました。報告は、個人情報保護委員会ウェブサイトのフォームを用いて行う必要がありますが、弊所でも早速様々なご相談を受けています。報告の対象となる事態の中で一例を挙げると、サイバー攻撃など、「不正の目的をもって」行われたおそれがある個人データの漏えい等については、即座に報告義務の対象となってしまいます（個人情報保護法施行規則7条3号）。その関係で佐々木さんにお伺いしたいのですが、インシデント対応を行う中で、この法改正が実務に影響していると思うところはありますでしょうか。

おっと待ってください、今、それだけで各々数時間は対談できる単語が2つほど飛び出しましたが、それはちょっと後でお話をさせてください（笑）。さて、私の方でも、個人データ漏えい等に関する相談を受けた際に、速報は3～5日以内が目安ですよ、と申し上げるのですが、企業によって受け止めの温度感が違う印象を持っています。速報を適切に実施しておかないと、確報が間に合わなくなるのでは…ということが懸念されますね。 そういえば、こうした施行直後の過渡期ならではの論点だと思っていますが、例えば、サイバー攻撃が起こったのが2022年3月の改正法施行前であった一方で、サイバー攻撃を実際に認識したのが2022年4月以降の改正法施行後、というケースがあり得ます。この場合、改正法が適用されて報告義務があるのかどうかは明確ではないように思いますが、田中弁護士、どう思われますか。

私もそれはよく聞かれます。条文を見ると、26条は一定の要件を満たす個人データの漏えい等の事態が「生じたときは」、となっているので、客観的な事象の発生を基準にしているように思います。つまり、改正法施行前に発生した事象については改正法の適用対象外ということですね。ただ気になるのは、個人情報保護法施行規則8条1項やガイドライン（通則編）の26条の箇所では、報告対象事態を「知った」後に報告せよとなっていて、事象の発生を認識した時点という主観的な認識を基準にしているようにも見えるんですよね…。

私もそこが気になっています。しかし、私も田中弁護士に同意で、まずは条文から出発すべきだと思うので、客観的な事象の発生時点がベースなんだろうと思います。施行規則やガイドラインの「知った」という記述は、発生した事象に関する報告義務発生の起算点を示すものと考えれば、法令の文言との整合性も取れるのかな、と思います。 ただ気になるのは、サイバー攻撃の場合って、半年前とか1年前に実は攻撃が発生していたというケースもあります。例えば、改正法施行後の2022年6月にサイバー攻撃による個人データ漏えいが発生していて、それを2022年12月に知った場合は、知った時点から3～5日以内に速報、60日以内に確報ということになります。これは違和感ないのですが、改正法施行前の2022年3月にサイバー攻撃が発生していたことを2022年12月に知ったという場合、事象の発生が2022年3月なので改正法が適用されません、というのは何となく違和感が残ります。この点に関連して、2020年改正法の立案も担当していた小川弁護士、いかがでしょうか。

まず26条の「生じたときは」という文言は、電気通信事業法28条の重大な事故の報告などの用例にならったものですが、当初から報告義務が生じるのは、漏えい等の事態を認識した時点と考えられており、この点を明確にするために、個人情報保護法施行規則8条1項では、「前条各号に定める事態を知った後、速やかに、」と規定されました。 改正法施行前に発生し、改正法施行後に漏えい等事案については、確かに条文上明確でなく解釈問題となりますが、客観的な発生時点をベースに、認識の時点で義務が生じる時点を限定していると考えれば、改正法施行前に発生したものは対象外ということになるかと思います。ただ、実際の漏えい等事案では、客観的な発生時点も必ずしも明らかではなく、事実認定の問題も生じるかなと思います。

サイバー攻撃の場合は、不正アクセスが1回あってそれで終わり、というわけじゃなくて、いつでも侵入できる状態が継続しているようにも思うので、そうすると、2022年4月以降も不正の目的を持った個人データの漏えいのおそれが継続していた、つまり、改正法は適用されると考えることもできそうですね。

仰るとおりだと思います。そのあたりは、個人データ漏えいの蓋然性をまさに個別具体のケースに応じて判断するということになるんでしょうね。実務上の対処としては、改正法が適用されるかどうかは断定できないが報告した方が良い、と申し上げることになりそうです。

先ほども少し触れましたが、個人情報保護法26条の報告対象事態は、一定の条件を満たす個人データの漏えい等の「おそれ」がある場合も対象になっています。おそれとは、漏えい等が疑われるものの確証がない場合といわれていますが、サイバー攻撃事案における「おそれ」については、ガイドライン（通則編）にいくつか具体的な事例が挙げられています。この事例の一つがJPCERT/CCさんとの関係でも興味深いと思っておりまして、「不正検知を行う公的機関、セキュリティ・サービス・プロバイダ、専門家等の第三者から、漏えいのおそれについて、一定の根拠に基づく連絡を受けた場合」というものがあります。第三者による連絡をトリガーにするということで特殊な事例だと思います。 佐々木さんにお伺いしますが、ここにいう「第三者」には、ストレートにJPCERT/CCさんが入ると思います。実際にJPCERT/CCから企業に対してこのような連絡をするケースは多いのでしょうか。

JPCERT/CCから連絡をする際には、企業側も適切に情報提供を受けられるようにしておくことが必要だと思うのですが、JPCERT/CCとしては通常どういったルートで連絡をされるのでしょうか。

WHOIS情報はユーザーが普段見るところではないので、メンテナンスが後回しになりがちなのかもしれませんが、適切な情報提供を受けるためには普段から適切にメンテナンスしておく必要がありますね。これに関連してですが、ガイドラインの事例は、「漏えいのおそれについて、一定の根拠に基づく連絡を受けた場合」とされており、パブリックコメントに関する個人情報保護委員会の見解を見るに、脆弱性があることの連絡をするだけでは「漏えいのおそれ」についての連絡ではないと解されています（※2）。ここは誤解がないようにしたいと思っておりまして、脆弱性があるということは、確かにそれだけで直ちに個人データ漏えい等の蓋然性が高いまでは言えないかもしれませんが、脆弱性を放置すれば結局のところ不正アクセスやデータの漏えいに繋がりますので、脆弱性に関する連絡を受けた段階では、個人情報保護委員会への報告が法的な義務とはならずとも、対応することは必要だと思っております。佐々木さんにこのあたりについてコメントいただきたいのですがいかがでしょうか。

①単に脆弱性がある、②その脆弱性を使った攻撃が既に観測されている、③その脆弱性を使って御社が攻撃を受けている、というように、脆弱性がある旨の連絡にも色々あるということですね。今は個人情報保護法との関係だけを見ておりますが、例えば、脆弱性があることの連絡を受けたのにそれを放置して、それが原因で自分が攻撃者の踏み台にされてしまい、第三者への不正アクセスが発生し損害が生じたというケースを想定すると、「脆弱性があることの連絡を受けたのに放置した」という事実が過失となって、第三者から損害賠償請求を受けるリスクもあると思います。個人情報保護法だけではなく、様々な法的関係を検討する必要もあると思っています。

そうですね、個人データの漏えい等のインシデントにおいて、個人情報保護法は、問題になる法律の一つでしかないということですね。個人データの漏えい等が発生した場合には、当局の他にも、取引先、委託先、委託元、ユーザーといった色んな関係者がいますから、その関係者との関係で論点となり得る賠償リスク等を常に意識する必要があります。

私が配信させていただいたセミナー動画でも触れましたが、改正による実質的規制強化の点、これは是非議論させてください。この記事がアップロードされた際に画像が貼り付けられているはず。

改正前は、告示に基づく努力義務として、個人情報保護委員会への報告等が定められていました。その告示では、漏えいしたデータだけを見ても特定の個人を識別できない場合には、「実質的に個人データが外部に漏えいしていない」ということで、個人情報保護委員会への報告は不要とされていました。今回の改正で、パラダイムシフトと言ってもいいぐらい大幅な方向転換をしておりまして、「個人データに該当するかどうかは、当該個人データを漏えい等した個人情報取扱事業者を基準に判断する」となっています。要は、漏えいしたデータだけを見て特定個人を識別できなくても、漏えいした企業が他の情報と紐付けて特定個人を識別できるなら個人データの漏えいとして扱わないといけないということがQ&Aで明記されています。スライドにもあるとおり、強調するために敢えて「漏えい元基準」とラベリングして呼んでいます。小川弁護士、なぜこのような転換が行われたのでしょうか。

個人データの第三者提供を行う際に、提供元と提供先のどちらを基準に個人データ該当性を考えるか、という論点があって、こちらは提供元を基準に考えるというのが、個人情報保護委員会の立場です。いわゆる提供元基準ですね。つまり、提供先にとって個人データでなくても、提供元にとって個人データであれば、それは個人データの提供として扱わないといけないことになります。この考え方自体にも議論がありますが、提供と漏えいの区別が微妙な事例もありますし、提供元基準を一貫させる立場から、今回の改正にあたって提供元基準の考え方を個人データの漏えいについても当てはめた、ということかと思います。

漏えい先がどんな情報をもっているかは正直分からないということが考慮されたのかな、と思います。漏えい先基準で考えると、おそらく漏えい先では特定の個人は識別できないだろうということの予測に基づいた基準になってしまうため、そうならないように、自分を基準に考える漏えい元基準説を採用しているということなのかなと思います。

一貫させたいというところはわからなくはないのですが、実際のところ、これは本当に厳しい改正をいきなりぶち込んだな、という印象を持っております。極端な例を挙げますが、例えば、氏名、メールアドレス、社員ID（社内で整理用としてのみ利用）をデータベースで管理しているときに、社員IDだけが漏えいした場合、社外の人が社員IDだけを見ても誰のことなのかさっぱりわかりませんが、漏えいした企業としては、データベースを見れば社員IDから特定個人を識別できますので、社員IDは個人データの一部ということになります。そして、漏えいした社員IDが1000件を超えてたらその時点で報告義務の対象となります。

漏えいしたデータのみでは特定個人を識別できるかどうか微妙なケースもあるので、そういう場合に幅広に報告して欲しい、ということなのかもしれませんね。さすがに、社員IDだけ漏れましたという場合は、プライバシー性も低いので、報告を受けた個人情報保護委員会も特段リアクションはしないように思います。

幅広に報告するのは構わないのですが、社員IDだけ漏えいしたケースみたいに、報告する方もされる方も手間が増えるだけ、というのは何とかならないかな、と思います。

立法論になるかもしれませんが、誰を基準にするかで画一的に決めるのではなく、本人の権利利益侵害のおそれの度合いという観点からケースバイケースで実質的に判断できる余地を残してもよいと思います。旧告示は、漏えい元基準説を採用していなかったものの、当該事業者以外では特定の個人を識別できない場合であっても、例外として、当該情報のみで「本人に被害が生じるおそれのある情報が漏えい等した場合」には、やはり漏えい等に該当するとしていました。このことも、結局は事案ごとの実質的な判断が必要であることを示唆しているように見受けられます。 確かに、今回の改正法で漏えい等報告を義務化したことに伴い、画一的な判断基準を設けるべきという意識が背景にあることは理解できますが、例えばGDPRにおいても、自然人の権利及び自由に対するリスクを発生させるおそれがない場合は（“unlikely to result in a risk to the rights and freedoms of natural persons”）監督機関への報告は不要とされていますよね。高度な暗号化（個人情報保護法施行規則7条1号括弧書に相当）といったケースも、GDPRでは、この抽象的な要件該当性の中で判断されることになります。 今回の改正法では、個人データに該当しても仮名加工情報であれば漏えい等報告が免除されることが明記されています（個人情報保護法41条9項）。これと平仄を合わせる意味でも、本人の権利利益侵害のおそれの度合いという観点から合理的な結論を導き出せるような解釈ないし立法上の手当てはあっても良いのではないかと思います。

強く同意します。今の点に関して、仮名加工情報は確かに報告義務が除外されていますが、この制度って、「私はこれを仮名加工情報にします！」という意思をもって加工しないと使えないのがネックですよね。仮名加工情報の加工基準は比較的緩いので、安全管理のために一部の情報を削っていれば、結果的に仮名加工情報の加工基準を満たしているケースが多いです。それと同じように、漏えいしたデータだけを見ると、オリジナルのデータと比較したときに仮名加工情報の加工基準を結果的に満たしているケースが結構あると思うんですよね。データの内容、つまり、本人の権利利益の侵害の程度としては仮名加工情報と同じなのに、仮名加工情報にする意思をもって加工したかどうかだけで義務の有無が変わるというのは違和感があります。ここからちょっと悪いことも考えることができそうで、北山弁護士に確認しておきたいのですが、漏えいしたデータがたまたま仮名加工情報の基準を満たしていたというケースで、「実はこれ仮名加工情報だったんです！」と後から仮名加工情報だったことにするのはどうでしょうか。「事後的仮名加工情報」といいますか。まぁダメだと思いますけど。

変なスキームを作らないでください（笑）、そりゃダメでしょう。今仰っていただいたのは、仮名加工情報を「作成するとき」に、仮名加工情報として取り扱おうとしていなければならないという解釈の箇所だと思いますが、これはあくまで作成するその時点で意思が必要ということですので、後から実は意思があったというのは通用しないと思います。

すいません、言ってみただけです。頭の体操と思っていただければ。さて、先ほど岡田弁護士から立法論かもしれないが、という示唆がありましたが、私としても、本人の権利利益の侵害がほとんどないと言えるような軽微な事故については、そもそも報告することを不要とするか、そうでなくとも、例えば、電気通信事業法で定められている事故発生時の四半期報告制度（電気通信事業報告規則7条の3参照）のように、軽微な事故に関する特則があれば良いな、と思っております。データ漏えいが起こった現場で、皆がこの漏えい元基準を完全に把握して対応しているとは思えないのですが、佐々木さんの所感としてはいかがですか。

田中弁護士、ID・パスワード等の個人データ該当性についてはいかがでしょうか。基本的に当たるということになりそうですが。

そうですね。まず、ID自体が単体でも個人データにあたる電子メールアドレスだったりすると、IDだけが漏れた場合でも、それ自体で当然に単体で個人データの漏えいですね。そして、仮に、ID自体が英数字の羅列のようなものであって、IDだけが漏れた場合だとしても、漏えい元ではそのIDを個人データとして管理しているはずなので、結局、個人データの漏えいになりますね。さらに、IDとパスワードのセットが漏れてしまえば、なりすましによる不正ログインの危険が高まりますので、不正ログインした場合に閲覧できる情報についても、漏えいの「おそれ」があるケースも多くなりそうです。

関連して触れておきたいのは、いわゆるリスト型攻撃ですね。簡単に解説すると、リスト型攻撃とは、さっき佐々木さんからお話のあったフィッシングなどによって窃取したID・パスワードのリストを使って、他のサービスへの不正ログインを試みるものです。IDやパスワードについては、色んなサービスで同じものを使い回している人が多いので、使い回しが多ければ多いほど、リスト型攻撃による被害を受ける可能性が高くなってしまうという関係にあります。大きなサービスだと、1日あたり数アカウントの情報が、このリスト型攻撃によって漏えいしているとも聞いたことがあります。リスト型攻撃は、第三者による明確な悪意をもった不正ログインですので、「不正の目的」であることは明白です。つまり、1件でも個人データが漏えいすれば、報告対象事態となります。ID・パスワードについては、先ほどの田中弁護士の話にもありましたが、事業者が他の特定個人を識別できる情報とともに管理しているでしょうから、ID・パスワードが漏えいした時点で、漏えい元基準に基づけば個人データの漏えいになります。

リスト型攻撃による不正ログインが成功しただけだと、そのサービスを提供している事業者からIDとパスワードが攻撃者に流出したわけではないと解釈する余地もあるように思います。

私としては、不正ログインが成功した時点で、そのサービスを提供している事業者のユーザーの認証情報を攻撃者が取得してしまっているので、漏えいに該当するのではないかな、と思っています。もちろん異なる見解もあろうかと思いますが。ただし、この時点では漏えいに該当しないと考えたとしても、ID・パスでログインできるサービスは、ログインした後にユーザー情報を閲覧できることも多いので、結局のところ、不正ログインが成功した時点で、閲覧できる可能性がある情報の漏えいの「おそれ」は発生してしまっているように思います。今の議論が問題となりうるのは、不正ログインをシステムで検知する等して即座にブロックしたようなケースですね。この場合は、攻撃者による不正ログイン自体は成功してしまっていますが、ログイン後に閲覧できる情報等の漏えい又は漏えいのおそれはないと評価することも可能と思われます。

そうすると、ログインした後に閲覧できる情報が非常に限られている場合は、個人データの漏えいのおそれがないという場合もありえそうですね。

ただ、結局ここでまた漏えい元基準が絶妙な効果を発揮しちゃうんですよね。大抵のウェブサービスって、ログインした後に、ユーザーネームとかユーザーIDが表示されることがほとんどだと思うんですが、これも漏えい元基準に基づけば個人データになりますので、ログイン後にユーザーネームやユーザーIDを閲覧できてしまうと、結局その時点で法的には個人データの漏えいになりますよね。

形式的にはそうなりますよね。多要素認証を入れるなどして、IDとパスワードだけでログインさせない、という対策をとるしかないのかもしれません。

一応解説すると、多要素認証とは、ID・パスワードという、知識による認証以外に、保有しているものや身体的特徴といった他の要素による認証を付加するものですね。2つの要素を用いる場合には二要素認証ということもあります。具体的には、保有しているスマートフォンを用いた端末認証や、指紋や顔の特徴による認証が挙げられます。ID・パスワードの後に、「秘密の質問」といった知識による認証を追加する場合もありますが、これはどちらも知識という同じ要素を用いて二段階の認証を行うものですので、二段階認証ということになります。 話を戻すと、多要素認証を入れるというのはリスト型攻撃を防止するために有効な手段と言えますが、これを導入することで、ユーザーの利便性が落ちる（ログインが面倒になる）というマイナス効果もあるように思うので、現時点では、まだ全ての事業者が導入できているものではないという印象を持っています。佐々木さん、リスト型攻撃への対策は現状どのような感じでしょうか。

なんと！その発想は全くなかったです。まさに、「逆に考えるんだ、『忘れちゃってもいいさ』と考えるんだ」ってやつですね。某奇妙な冒険のファンが喜びそうです（笑）。確かにパスワードの再発行手続は、結果的に多要素認証又は多段階認証になってるものが多いですもんね。ただ、再発行手続が適切であるという前提には注意しないといけないですね。まぁ、再発行手続が適切でないということは、それ自体がシステムの脆弱性であるようにも思いますが。

さて、後で触れましょう、と先ほど申し上げたテーマにそろそろ言及しましょう。この対談の時間も限られていますので、詳細は別の機会があれば、ということにもなりそうですが、まずはランサムウェアから。皆様ご承知のとおり、近年のランサムウェアの脅威は極めて大きく、様々な企業が被害に遭っており、弊所も多数の相談を受けております。情報処理推進機構（IPA）が公開している「情報セキュリティ10大脅威2022」でも組織向けの脅威第1位ですね。近年のランサムウェア攻撃の特徴としては、単にデータを暗号化するだけではなく、情報を窃取してリークサイトに公開してしまうという点が挙げられるかと思います。ランサムウェアに関する論点は、身代金の支払いの関係を含め沢山あり、これだけで対談のテーマにできてしまいますが、時間の制約もあるので今回はあくまで個人情報保護法との関係に絞りたいと思います。嶋村弁護士、おさらいですが、こうした暴露型のランサムウェアに感染した場合、個人データの漏えい等の関係でどうなるか教えていただけますか。

暗号化した時点で個人データの「毀損」になり、情報が窃取されていれば「漏えい」に該当することになりますね。バックアップがあり復元できるような場合は「毀損」には該当しないとされています。ただ、個人情報保護法施行規則7条は、漏えい・滅失・毀損について特段扱いを分けていないので、課せられる義務は変わりません。

ありがとうございます。そのとおりですね。これは佐々木さんにお伺いしたいのですが、ランサムウェア対応と個人データ漏えい対応について、何か特徴的なことはありますでしょうか。

ここは私も悩ましいと思っておりまして、ランサムウェアに感染したということだけがわかっている場合、それが情報窃取を伴うものなのかどうか、情報窃取を伴うものであるとして、実際に窃取されたのかどうか、というところを判断することが難しい点が悩ましいですね。これは、ランサムウェア攻撃を受けた場合に、報告義務が発生する「知ったとき」がいつなのか、という論点とも絡んできますね。

通常は、ランサムウェアの種別までは企業自身は把握できないと思うので、セキュリティベンダに尋ねることになりますでしょうか。

ランサムウェアがどのような挙動をするかは、確かに企業自身では判断できないと思いますので、ベンダに聞いていただくか、まさにJPCERT/CCにインシデント対応依頼をして尋ねるのも選択肢ですね。佐々木さんが触れなかったので私の方で触れておきますが、JPCERT/CCは、近年のランサムウェアの脅威の増加も踏まえて、「侵入型ランサムウェア攻撃を受けたら読むFAQ」という特設ページを公開しています。ランサムウェアを受けた場合の対応について簡潔かつ網羅的にまとまっているので、感染したらまずここを読みましょう。私もクライアントによくこのページを案内しています。

最近また猛威を振るっているEmotetにも触れましょう。Emotetは、企業が保有する連絡先情報やメール情報などを窃取することがありますから、その時点で個人データの漏えいがあったといえるケースが多いですし、例えば、自社がEmotetに感染したことを原因として、第三者をEmotetに感染させてしまった、という二次被害が発生するケースもあります。その際には賠償問題となるリスクもあると思います。佐々木さん、JPCERT/CCでも、Emotetに関する相談は多いでしょうか。すいません、結論はわかった上で敢えて聞いてますが。

感染の流行期といいますか、攻撃全体の波ごとに感染被害の「ピーク」があるんですが、そういった時期になると、普段対応しているチームだけでは対応がまわらなくなるので、別のチームを投入するぐらいに相談が多いですね。Emotet対応も、従来とは異なるスピード感でのインシデント対応が必要となる類型の一つと思っています。Emotetは、感染から1日以内に不審メールが取引先等にバンバン飛んでいきますので、短時間での対応が必要です。メールサーバーが乗っ取られて不審なメールが送られる可能性もあります。ベンダに依頼して対応して、というような従来の対応では間に合わないので、被害組織自身が、一定程度の初動対応を実施する必要があります。そうした特徴を踏まえ、JPCERT/CCでは、「マルウェアEmotetの感染再拡大に関する注意喚起」という特設ページを作り、担当者が対応に関するノウハウを紹介する動画をYoutubeで公開しています。Emotetに関する動画の再生回数は段違いで、それだけ被害者が非常にたくさんいるということだと思っています。

ありがとうございます。弊所でも多く相談を受けているところですが、やはり感染してしまっている事業者の数はかなり多いという実感があります。さて、こちらも、感染拡大に伴う民事責任等を検討すると、それだけで数時間は対談できそうですので、感染した企業の個人情報保護法上の対応に絞ってお話をさせていただきます。Emotetに感染すると、感染した端末に保存されていたメールデータやアドレス帳に登録されていた情報等が窃取されると言われています。これらは前提として、報告義務が生じる「個人データ」の漏えいにあたるでしょうか。北山弁護士、いかがでしょう。

今の質問の趣旨は、「個人情報」か「個人データ」か、という質問であると理解しました。報告義務の対象は「個人データ」なので、個人データではない「個人情報」の漏えいがあったとしても法的には報告義務はないということですね。今挙げてもらったものは、「個人情報」であることは前提としてよいと思います。特定の個人情報を容易に検索できるように体系的に構成されているかどうかで、個人データに該当するかどうかが変わりますが、その点で申し上げると、まず、アドレス帳は体系的に構成されたデータですので、それを事業に使っているなら個人データに当たることは疑いないと思います。メールデータについてはちょっと微妙ですね。ただ、メールソフトの機能として、特定の送信元や送信先を基準に並べ替えたり、メールデータの検索ができたりしますので、個人データであることを前提に対応した方が良いのではないでしょうか。

ありがとうございます。確かにギリギリ詰めるとメールデータは「個人データ」ではないと解する余地はあると思いますが、基本的には、様々なデータが漏えいしており、その一部には少なくとも個人データが含まれているという前提で対応した方がよいかと思います。他にもEmotetは、感染した被害組織によるメール送信先（Emotet未感染）になりすますこともあるというのが怖いところだな、と思っています。つまり、第三者から、「あなたになりすましたメールがこちらに届いた」という連絡を受けたとしても、実はその連絡を受けた組織はEmotetに感染してないという場合があり得るので、感染しているかしていないかがわかりづらい、ひいては、個人データの漏えい等があるかどうかがわからないのではと思います。

では、そろそろお時間となりますので、今回の対談はこのあたりで終了とさせていただきたいと思います。サイバーセキュリティ対策の重要性が高まる中、個人データ漏えい等対応と密接に関わってくることは明白であると思いますし、私も本日議論させていただいて非常に勉強になりました。佐々木さん、本日は誠にありがとうございました。どうぞ引き続きよろしくお願い致します。