深情報セキュリティ美学

ISO/IEC 27701「プライバシー情報マネジメントのためのISO/IEC 27001及びISO/IEC 27002への拡張」の解説

はじめに

　国際規格ISO/IEC 27701「Extension to ISO/IEC 27001 and ISO/IEC 27002 for privacy information management（プライバシー情報マネジメントのためのISO/IEC 27001及びISO/IEC 27002への拡張）」が、ISO/IEC 27001と27002に対する拡張規格として発行された。27001は情報セキュリティ・マネジメントシステム（ISMS）要求事項の規格であり、ISMS認証の基準となる規格である。27701は、27001への追記事項を記述したものであり、単独で認証基準として使えるものではなく、現状ではISMS認証を受ける中で拡張審査を受けることになる。

　27701の発行前も、個人情報保護に関する国際規格としては、27002の拡張規格として、ISO/IEC 29151（Code of practice for personally identifiable information protection）があるため、これまででも27001+27002+29151で個人情報保護のためのマネジメントシステムを構築することが可能である。ただ、27002の拡張としての29151では、管理策対応だけなので、リスクマネジメントを扱う27001についても、拡張規格が必要ではないか、という議論が行われて開発されたのが27701である。

　27701は27001と27002の両方の拡張となっている。当初は、27002への拡張として既に29151があったので、27001への拡張を別に開発することで、2つに分けて開発することも検討されたが、それぞれの拡張は一体のものであるため、1つの規格として開発された。

　27701の使われ方であるが、27001に基づくISMS認証を取得している組織が、その拡張として27701を追加するというのが自然な使い方だと思われる。なぜなら、ISMS認証を取得していない組織が、27701に対応するためには、27001及び27002に対応することになるため、個人情報とは関係ない情報セキュリティ対策もしなければならなくなるからである。

　ISO/IEC 27701（以下、「27701」）について、以下のとおり解説する。

目次

１. 規格開発の背景と発行までの議論の経緯について

２. 規格のタイトル、全体構造、27001/27002との関係、適用範囲について

３. 27001/27002に関する固有要求事項とガイダンスについて

４. 27002に付加されたPII管理者・PII処理者向けのガイダンスについて

５. 附属書の活用方法について

 

この投稿は、PDFファイルをダウンロードしてご覧いただくことができます。

また、文章の概略を講演した内容を YouTube で閲覧（約15分間）していただくこともできます。

 

 

１. 規格開発の背景と発行までの議論の経緯について

　ISO/IEC JTC1/SC27委員会には5つのWG小委員会があるが、そのWG1小委員会（以下、「WG1」）はISO/IEC 27000ファミリー規格に代表される情報セキュリティ・マネジメントシステム(以下、「ISMS」）などを開発しており、2006年に設立されたWG5小委員会（以下、「WG5」）はアイデンティティ管理、バイオメトリクス、プライバシーに関する規格を開発している。筆者は、2000年からWG1に参加してISO/IEC 27002（以下、「27002」）の開発を担当した後に、WG5設立方針の審議を担当し、設立後はWG5国内小委員会の主査を務めた。

　WG5におけるプライバシー関連の規格は、「ISO/IEC 29100 Privacy framework」（以下、「29100」。）を中心にして開発されている。29110の英語版は無償で公開されており、日本語で読む場合は有償となるが「JIS X 9250プライバシーフレームワーク」としてJIS化されている。

　2020年4月時点で、WG5がプライバシー関連で発行している規格と審議中の規格の一覧を図表１に示した。

 

　27701の開発経緯には、「ISO/IEC 29151 Code of practice for personally identifiable information protection」（以下、「29151」。日本語対訳は発行されていない）が関係する。そこで、まず、29151の開発経緯を紹介する。

　WG5では、WG1におけるISMSに相当するプライバシー保護のマネジメントシステムをどのように規定するかの検討が、2011年から始まった。

　その審議の初期において、当時から存在していた日本の「JIS Q 15001個人情報保護マネジメントシステム−要求事項」（以下、「15001」）を参考資料として提供することが国際会議で求められ、英語の仮訳まで準備したが、日本としては、内容が日本固有であり、15001を国際規格化する方向性がないことから提出しないことになった。このため、審議では、15001の規格が参照されることはなかったが、その規格名を英訳したPersonal information protection management systemという言葉だけは残り、その略語であるPIMSが「ピムズ」と呼ばれた。WG5では、個人情報のことを当初は、Personal informationとしていたが、その後、米国で使われていたPII (Personally identifiable information)として定義したため、29151は、もはや、PIMSではなくなっていたが、その後もPIMSが使われ続けた。

　審議はWG1と合同で行われ、新しいマネジメントシステム規格を開発するのか、既存の27001又は27002の拡張とするのかを検討した。情報管理に関するマネジメントシステムは、基本的にISMSに集約し、個別にマネジメントシステム規格を開発しないことが合意され、PIMSは、ISMSの下で構築することになった。次に、27001と27002のどちらか又は両方を拡張するのかが検討されたが、ちょうどその時期にWG1で27002に分野別に追加事項を規定するISMSセクター規格という考え方ができたため、それと同じ位置付けで開発することにして、27002に対する拡張規格として29151を開発することが決まった。そして、2013年に開発が始まり2017年に発行された。

　29151が完成に近づくと、27002の拡張だけではなく、27001への拡張も必要であることがわかり、2017年から新たに審議が行われた。個別のマネジメントシステムを開発しないという方針を維持して、27001に対する拡張規格として27552という規格の開発を始めたが、利用者がより利用しやすくするために、27002に対する拡張も統合して、27001と27002の両方の拡張を27552で規定することになった。27552は、発行の直前で、マネジメントシステムの要求事項規格であることから、規格番号の末尾を01として発行されることになった。それが、27701である。

 

２. 規格のタイトル、全体構造、27001/27002との関係、適用範囲について

　27701のタイトル「Extension to ISO/IEC 27001 and ISO/IEC 27002 for privacy information management」には、privacy information managementとあるが、これは本来正しくない。なぜなら、privacy informationという情報は扱っていないし、規格本文で使ってもいない。保護の対象はPIIであり、本文で使っているPII protection又はprotection of PIIが正しいだろう。しかし、WG5の内部ではPIMSが既に10年間近くも定着してしまっていた。そのため、略語をPIMSになるように合わせるために、Privacy information management systemをPIMSと定義し、そこから切り取られて、タイトルに、privacy information managementという造語ができあがっている。

　もしも、27701のタイトルを見て、「privacy informationって何？」と思われたなら、このような経緯で名付けられただけであり、この規格が何のための拡張であるかを正しく表すならば、PII protection managementであり、ISMSに習うならば、Information privacy managementが正しい。

　27701は、そのタイトルのとおり、27001と27002のそれぞれに対応した拡張規格と関連する附属書から構成されている。（図表２を参照）

　27701を理解するためには、引用規格である、27001と27002、29100について理解している必要がある。27701については、本書執筆時点では、JIS化の予定は決まっていないが、日本語対訳書「セキュリティ技術―プライバシー情報マネジメントのためのISO/IEC 27001及びISO/IEC 27002への拡張―要求事項及び指針」が2020年3月25日に出版された。

　27001と27002については、それぞれに対応しているJIS規格解説本によって理解を深めることができる。29100については、JIS X 9250を参照することができる。

　ISMSにおいては、27001でマネジメントシステムを規定し、その附属書Aで管理策を示し、それらの管理策に対応する実施の手引きが27002で規定されている。27001におけるリスクアセスメントの必須事項を27001の附属書Aで規定し、その判断や管理策を採用した場合の手引きとして27002が管理策を補足するという構成になっている。いわば、27001と27002の橋渡しとして、27001の附属書Aは重要な役割を果たしている。

　27701においては、27001の要求事項に対するPIMSの追加事項を箇条５で規定し、27002の実施の手引きに対するPIMSの追加事項を箇条６で規定している。そのため、箇条５は、shall（しなければならない）で書かれ、箇条６は、should（することが望ましい）で書かれた規定が一つの規格内で混在しているのに違和感があるかもしれない。これについては、それぞれ27001と27002の関係に対応しているものと考えればよい。すなわち、27701の箇条５は27001を引用しており、その中で27001附属書Aが参照されることで、27002が紐付けられ、それを拡張した27701の箇条６は、また27001附属書Aから紐付けられているという構造をなしている。したがって、27701の箇条５は、27001の附属書Aを介して、箇条６を従属させている。

　以上に引き続いて、27701では、いわば本体となるPIMS固有の管理目的と管理策を附属書A,Bで規定し、それらのガイダンスを箇条７と箇条８で規定している。

　附属書C、D、Eは、他の規格・規則への対応表を、附属書Fは、27001と27002への適用方法についての参考情報を提供している。

　次に、27701の本文の内容であるが、27701の適用範囲は、図表3のように書かれている。

　PIMSという表現については、既に説明したとおりである。ここでは、「privacy managementって何？」と思われるだろうが、この箇所にしか出てこない表現で、規格本文では使われていない。これもPIMSと同じで、PII protection managementと考えればよい。

 

３. 27001/27002に関する固有要求事項とガイダンスについて

　「箇条６ ISO/IEC 27002に関連するPIMS固有の手引」は、「ISO/IEC 27009 Sector-specific application of ISO/IEC 27001」（以下、「27009」）に基づくISMSセクター規格として開発されている。すなわち、27002の構成を引用した上で、PIMS固有の事項がある箇所にだけ、追加や改定（refine）の実施の手引きを規定している。

　「箇条５ ISO/IEC 27001に関連するPIMS固有の要求」は、27000シリーズ規格において、27001を拡張した初めてのものとなる。規定の方法は、27009に準じるものとして、27002への拡張と同じ体裁を使い、追加や改定事項がある箇所に、追加や改定の要求事項を規定している。

　27001に対する固有要求事項で、最初に必要なことは、PIMSをISMSに組み込むことである。

　箇条５と箇条６は、27001の附属書Aを介して紐付けられていることを前節で説明したが、それだけでは、認証規格である27001から見ると、情報セキュリティマネジメントの範囲を超えることができないため、27701の5.1 Generalにおいて、図表4のように規定している。

　そして、5.1にあるとおり、附属書Fにおいて、図表5のような読み替え表を示している。

 

　つまり、27001におけるinformation securityをすべて、information security and privacyと読み替えよという規定である。

　このような読み替えを認証基準規格で行うことは稀であり、これを実際の認証でどのように行うかについては、図表1の「プライバシー関連で規格を開発する投票が行われている案件」にある「Requirements for bodies providing audit and certification of PIMS according to 27701 in combination with 27001」という審議案件で、2020年4月から検討が始まる予定である。基本的には、「ISO/IEC 27006 Requirements for bodies providing audit and certification of ISMS」に組み込むか拡張して対応することが予想される。

　次に必要なことは、PIMS固有の管理策をISMSに従属させることである。

　それをするために、27701の「5.4.1.3 情報セキュリティリスク対応」は、27001の「6.1.3 情報セキュリティリスク対応のc)及びd)」による27001附属書Aを使った管理策の確認について、27701の附属書AとBをそれに加えるように改定している。この改定によって、27701の附属書Aが箇条７を、附属書Bが箇条８を活性化している。

　箇条６における27002の拡張は、基本的に29151による27002の拡張内容を継承し、さらに新たに検討された内容を追加している。

　以上の関係を、図表6に示す。

 

 

図６「27701と関連規格の関係」（動画版）

 

 ４. 27002に付加されたPII管理者・PII処理者向けのガイダンスについて

 　27701の適用範囲には、図表３の文に続いて、図表７のように書かれている。

　27701におけるPIMS固有の事項を理解するための基本となるのは、「PII controller（PII管理者）」と「PII processor（PII処理者）」というアクターの区別である。これらは、29100で定義されており、JIS X 9250では図表8のとおりに書かれている。

　日本の個人情報保護法であれば、PIIは個人情報に、PII管理者は個人情報取扱事業者に、PII処理者は個人情報取扱事業者からの委託先に、それぞれ概ね対応することになる。

　例えば、Ａ社がセミナー開催にあたって受講者を募集する場合に、受講申込者の氏名や連絡先などの個人情報を取得する場合には、Ａ社が個人情報の利用目的を決定するので、PII管理者となる。この時、受講申し込みを受け付けるために、Ｂ社が運営する受講者管理サービスを利用する場合には、Ｂ社はＡ社に代わって個人情報を取得し、Ａ社の指示に従って受講申込者名簿などをＡ社がアクセスできるように処理するので、PII処理者となる。27701の箇条８は、Ｂ社がＡ社のために取得する個人情報の保護について規定するものとなる。仮に、Ｂ社が自社のためのセミナー開催をする場合は、それに関連する個人情報の取扱いについてＢ社は、PII処理者ではなくPII管理者となる。PII管理者として取り扱う個人情報の保護については、箇条８ではなく、箇条７で規定されている。

　日本の個人情報保護法では、委託先の安全管理措置（情報セキュリティ対策と同義）については、委託元が監督することになっているが、委託先が講じる対策を限定的には定めていない。しかし、上記の例のとおり、Ｂ社は、Ａ社との関係においては委託先であるが、Ｂ社はもともと個人情報取扱事業者でもあるはずである。なぜなら、Ｂ社は、Ｂ社自身の利用目的で取り扱う個人情報をＡ社とは無関係に保有しているはずだからである。そのため、Ｂ社において安全管理措置の内容は、もとからあると想定することができる。その上で、Ａ社はＢ社に対して善管義務を求める（Ｂ社自身の個人情報に対する安全管理措置を、Ａ社から委託する個人情報にも準用させる）ことがあり得るが、ISMSの観点からすると、それはＡ社が管理すべき個人情報をＢ社のリスクマネジメントに委ねることになってしまう。これらの関係をPII管理者とPII処理者に分けた上で、PII処理者としてなすべきことを箇条７で規定することにより、Ａ社のリスクマネジメントの下で、Ｂ社におけるＡ社の個人情報の保護を求めやすくなる。

　上記の例では、委託先が実施すべき事項を規定すれば、PII処理者としての規定が示されていることと同等の効果があるように思われるかもしれない。しかし、このことは実施すべき事項を怠ることがないようにする対策として有効であるが、実施してはいけないこと又は実施することを予見できなかったことが実施されてしまうことを防ぐ対策として違いが出てくる。

　例えば、Ｂ社がＡ社のセミナー受講者に、Ｂ社のセミナー案内を配信してしまうということを考えてみる。この場合、Ａ社がその禁止を業務委託契約で明記していればＢ社が契約に違反したことは明白である。それに加えて、PII処理者が、そのような違反をすることは、PIIを処理するための目的及び手段をＢ社が決定したことになり、Ｂ社は、直ちにPII管理者の立場になる。その結果、利用目的について事前の同意を得ることになっていれば、Ｂ社はPII管理者としての義務を怠ったことになる。つまり、事業者はPII管理者の立場かPII処理者の立場かが区別されて順守事項が定められているために、PII処理者がPII管理者の立場のことをした場合には、直ちにPII管理者としての義務が発生する。

　一方で、日本の場合には、委託によるものか否かという違いにしているため、上記のような違反は日本においても委託先は個人情報取扱事業者としての義務を負うことになるが、現状の日本法では、利用目的は通知だけで同意を求めておらず、さらに直接取得の場合の通知には公表を含んでいることから、仮に利用目的が公表されていれば、違法になるとは言い切れない。もちろん、そのようなことを契約で禁止していれば契約違反であるが、個人情報保護法違反になるとは限らないということである。

　つまり、Ａ社とＢ社の義務を日本では、委託の範囲とその条件は何であったかという2社間の関係性で整理するしかないが、29100の下では、事業者が個人情報をどの立場で取り扱うかによって明確に区別しているために、関係性とは独立しても各社の義務が定まる点が異なる。

　以上のように、PII管理者とPII処理者を区別した上で、PII管理者を対象に附属書Aと箇条７で規定し、PII処理者を対象に附属書Bと箇条８で規定している。

 

５. 附属書の活用方法について

　附属書A及びBは、それぞれ、箇条７及び箇条８に対応するものである。

　附属書C「ISO/IEC 29100への対応付け」は、WG5におけるプライバシー関連規格の中心となる29100との対応について示しており、図表９はその一部である。

 

　WG5では、図表1に示したとおり、様々なプライバシー関連規格を議論しているが、27701によってPIMSを構築する際に、どのような関連規格が役に立つかを知ることができる。

　附属書E「ISO/IEC 27018及びISO/IEC 29151への対応付け」は、既に発行している規格の要求事項との対応を示している。29151については、本来、27701の箇条６のうちPII管理者への規定と同様の内容であるべきもので、今後の改訂によって整合がとられる予定である。「ISO/IEC 27018 Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors」（日本語対訳は発行されていない）は、「PII処理者としてパブリッククラウド内のPIIを保護するための実践の規範」であり、タイトルにあるとおり、パブリッククラウドにおいて、PII処理者としての役割に絞って規定している。

　附属書F「ISO/IEC 27701をISO/IEC 27001及びISO/IEC 27002に適用する方法」は、先述したとおり、5.1 GeneralによるISMSをPIMSに拡張するための包括的な読み替えのための表などを示している。

　特筆すべきは、附属書D「一般データ保護規則への対応付け」である。これは、EUのGDPR（一般データ保護規則）への対応を示したものであり、図表１０はその一部である。

 
　国際規格において、特定の国や地域の法令を具体的に引用することは稀であるが、GDPRはEU以外の他国にも適用を求めているため、国際的に順守する必要がある場合があることから、その対応表が作成された。

　このような対応表は、自分でも作成することができるが、附属書Dの作成においては、EU規制当局の作業部会がWG5のリエゾンとしてレビューしているため、公式に認められるものではないもののEUのお墨付きがあると言えるものであり、紐付け及び網羅性の観点で、組織がGDPRに対応する取組みをする時に有用なものである。

　また、27701の規格本文では、「in some jurisdictions（法域によっては）」という但し書に続けて、法令による要求事項に触れている箇所がある。これらは、GDPRに対する網羅性を高めるためのものであり、いわば、GDPRのマーカーのようになっている。組織が27701に準拠する時に、これらのマーカーをたどることによって、GDPRへの対応に役立てることができる。

 

謝辞

　本稿は「月刊誌アイソス 2020年05月号 特集 プライバシー保護の国際規格 ISO/IEC 27701」に寄稿したものを書き改めたものです。株式会社システム規格社の中尾優作様による丁寧な編集と校正に感謝いたします。

　 執筆担当箇所の抜き刷りはこちらからダウンロードできます。

　ISO/IEC 27001に関する表現については、一般財団法人日本情報経済社会推進協会（JIPDEC）の畔津布岐様によるご指導に感謝いたします。

「個人情報保護法 いわゆる３年ごと見直しに係る検討の中間整理」に関する意見募集について

「個人情報保護法　いわゆる３年ごと見直しに係る検討の中間整理」に関する意見募集について
http://search.e-gov.go.jp/servlet/Public?CLASSNAME=PCMMSTDETAIL&id=240000053&Mode=0
（2019年4月25日から2019年5月27日まで実施）
に対して以下のとおり意見を提出しました。

【意見１】
（該当箇所）
中間整理において出されていない論点を提案します。
（意見）
個人情報の利用目的の特定に際して、利用目的が適切な内容であることを明示的に求めることを提案します。
そのための一案として、個人情報保護法第十五条（利用目的の特定）について、以下のように見直すことを示します。
見直し案：「」部分を追記
第十五条　個人情報取扱事業者は、個人情報を取り扱うに当たっては、その利用の目的（以下「利用目的」という。）を「個人の権利利益を侵害しないものとして、」できる限り特定しなければならない。
現行法：
第十五条　個人情報取扱事業者は、個人情報を取り扱うに当たっては、その利用の目的（以下「利用目的」という。）をできる限り特定しなければならない。
（理由）
現行法においては、利用目的を特定することを求めていますが、その内容については法条文において規定していません。そのため、利用目的の内容が不適切であっても、それを特定さえしていれば、法を遵守したことになり得ます。
たとえば、事業者が電話による広告活動をする場合には、それを利用目的とすることができます。しかし、しつこい勧誘電話は迷惑行為であり、個人の権利利益を侵害していると言えます。そのような利用は規制されるべきだと考えます。
現行法においては、電話をするために必要な電話番号が個人情報に該当するか否かで、保護の対象とするかが決まります。電話番号が個人情報に該当するためには、特定の個人を識別できるかなどが要件になります。しかし、その該当性について、個人情報の有用性に配慮するために、個人情報の該当性の範囲を狭めることを、迷惑行為をしない事業者が求める傾向にあります。本来は、個人情報の該当性を広くした上でも、利用目的の適正性が規制されるならば、適正な利用を目的とする事業者が個人情報の該当性を狭めることを殊更に求めることは軽減されるものと考えます。
また、他の例として、たとえば、現行法では、個人情報を第三者に提供することを利用目的に含めることが容易にできてしまいますが、その提供が個人の権利利益を侵害し得ると考えられるのであれば、当該利用目的そのものについて規制されるべきだと考えます。
したがって、利用目的については、特定する以前にまず、それが個人の権利利益を侵害しないものであることを規定し、仮に、利用目的そのものが不適切である場合には、それについて個人情報保護委員会が指導・助言をできるようにすることを提案します。

【意見２】
（該当箇所）
中間整理において出されていない論点を提案します。
（意見）
利用目的の通知等に際して、事業者の意図していることが本人に明瞭に通知等されることを明示的に求めることを提案します。
そのための一案として、個人情報保護法第十八条（取得に際しての利用目的の通知等）について、以下のように見直すことを示します。
見直し案：「」部分を追記
第十八条　個人情報取扱事業者は、個人情報を取得した場合は、あらかじめその利用目的を公表している場合を除き、速やかに、その利用目的を、本人に通知し、又は公表しなければならない。「利用目的を通知又は公表するに当たっては、その内容及び方法が欺瞞的であってはならない。」
現行法
第十八条　個人情報取扱事業者は、個人情報を取得した場合は、あらかじめその利用目的を公表している場合を除き、速やかに、その利用目的を、本人に通知し、又は公表しなければならない。
（理由）
法第十五条において、利用目的の特定が求められていますが、事業者は特定した利用目的を本人に誤解をあたえない表現や方法で通知又は公表する必要があると考えます。
個人の権利利益を保護するためには、事業者が特定した利用目的の内容を本人があらかじめ誤解なく知る必要があります。
したがって、利用目的については、事業者が特定した利用目的と、本人が認識した利用目的に祖語が生じにくいようにする必要があり、仮に、利用目的の通知等の内容及びその方法が本人が正しく認識する上で不適切である場合には、それについて個人情報保護委員会が指導・助言をできるようにすることを提案します。

【意見３】
（該当箇所）
中間整理において出されていない論点を提案します。
（意見）
個人情報の取得に際して、事業者が通知等した利用目的について、本人から同意を取得すること（いわゆる、オプトイン）を求めることを提案します。
（理由）
法第十八条において、個人情報の取得に際しての利用目的の通知等が求められていますが、事業者は通知等だけではなく、利用目的への同意を取得することを求める必要があると考えます。
オプトインについては、個人情報保護法が施行された2004年当時から、日本工業規格「個人情報保護マネジメントシステム」（JIS Q 15001）の要求事項になっており、近年ではGDPRでも求められていることから、多くの事業者が既に遵守しているため、事業者の事業規模によらず著しく困難な規定ではないものと考えます。
日本における個人情報保護を国際的な水準に合わせるためにも、オプトインを求めることを提案します。

【意見４】
（該当箇所）
中間整理において出されていない論点を提案します。
（意見）
個人情報保護委員会が、個人情報保護法及び番号法に限らず、個人情報の保護に係る法令等全般についての取り組みをできるように、必要であれば関連法令等の改正をすることを提案します。
（理由）
個人情報の保護に係る法令は、個人情報保護法だけではなく様々な分野の法令があります。しかし、個人情報保護委員会は、個人情報保護法及び番号法以外の法令について直接的な取り組みをすることができません。しかし、民間における事業等は、個人情報保護法に基づいて推進されるわけではなく、情報の取扱いにおけるコンプライアンスの一環として個人情報の保護に努めることになります。そのため、個人情報保護委員会には、個人情報の保護に関係する事業活動を全体的に指導・助言等していただけることを期待します。
たとえば、迷惑メール防止法（特定電子メールの送信の適正化等に関する法律）は、いわゆる広告を目的とした電子メールの送信の適正化を規定しており、これは個人情報保護法においては、電子メールアドレスの利用や利用停止の制約と密接に関連するとともに、オプトインや送信者とその連絡先を明記するなど、個人情報保護法にはないことも規定されています。迷惑メール防止法が施行された直後は、これらが遵守されていた時期もありましたが、個人情報保護法の啓発が進む半面、迷惑メール防止法の認知がむしろ下がっているようにすら感じられます。
同様の法令としては、特商法（特定商取引に関する法律）もあり、両法律の周知が推進された時期には、オプトインしていない電子メールの件名に「広告メール」の表記がされるなど事業者による遵守も進んだように思いますが、昨今は、個人情報保護法による利用目的の通知又は公表で足りるとの誤解から、広告メールについてオプトインが法的義務であるとの認識が低くなっていると思われます。特商法については、電子メールに限らないものであり、広告全般についてオプトインが求められていますが、郵送や電話連絡についても同様な状況が見受けられます。
これらのことは、個人情報保護委員会による個人情報の説明がされるほどに、事業者に誤解を与えてしまう危険性があります。法規制の基本的な知識として、個人情報保護委員会は、個人情報保護法だけに責任を持っており、事業者はその活動においては、個人情報保護法以外のすべての法令を遵守することは当然のことではあります。しかし、委員会から「個人情報の利用目的をあらかじめ通知又は公表しなければならない」とだけ示されたときに、他の法令において「事前の同意を得なければならない」という規制があることを見落としがちです。
この誤解を軽減するためには、個人情報保護委員会がオプトイン規制を求めている法令があることの説明も加えるのがよいと思いますが、設置法上、他の法令に言及する活動がしにくいのであれば、そのために必要な関連法令等の改正をすることを提案します。

【意見５】
（該当箇所）
３．利用停止等に関する状況（１２ページ）
（意見）
利用停止等のうち、削除の義務を現行法より厳格化する場合には、削除の具体的な要件についてガイドラインに定める際に、改めて実務に沿った内容として見直すことを提案します。また、削除が厳格化されたことを消費者に周知する際には、利用停止が本人の希望である場合に削除を依頼することは、利用停止に遅延が生じたり、安全上必要な連絡を受けることができなくなったりすることなども併せて周知するようお願いします。
（理由）
利用停止については、中間報告にあるとおり徹底することが必要であり、事業者は責任を持って行なうべきであると考えています。
一方で、削除については、個人情報の管理にＩＴシステムを使用している場合に、以下のような観点での具体的な要件を実務に沿って定められることが重要であると考えています。
１．バックアップデータの削除における要件について
ＩＴシステムにおいては、システム全体のデータのバックアップを取っている場合などもあり、その中に含まれる個人情報を個別に削除することは、実務上困難です。また、クラウドサービスを利用している場合には、クラウドサービスを利用する事業者がその削除を指示することは不可能な場合もあります。これらが削除の代替措置として認められるようなガイドラインの作成など、実務に沿った要件を定めてもらうようにお願いします。
２．利用停止を徹底するために必要なデータの削除について
利用停止を徹底するために、データが必要な場合もあります。
たとえば、電子メールの利用停止において、メール送信を迅速に停止するためには、事業者内のメールアドレスの利用停止や削除の手続きをするとともに、最終的なメール送信システムに、送信禁止アドレスのリストを登録する場合があります。事業者が個人情報を取得する機会は、一度だけとは限らないため、保有している個人情報を削除しても、その後新たに取得するとまた利用が再開されます。もしも、本人の希望が利用停止であるならば、削除よりも、送信禁止アドレスのリストに登録される方が、利用停止が徹底されることになります。
一部の消費者には、削除の依頼が利用停止の依頼よりも強固な手続きであるとの誤解があるように思われます。それぞれの依頼に違いがあることを消費者に周知することは事業者の責任でもありますが、これらの義務を厳格化する場合には、削除の場合には利用停止が継続しないことや、場合によってはリコールの連絡が行われなくなることなど、その違いについての周知も併せて推進していただくことを提案します。

【意見６】
（該当箇所）
４．オプトアウト規定と名簿屋対策の状況（１４ページ）
（意見）
個人情報を第三者に提供する同意を取得した際の確認記録に関係する義務は、取得の際の利用目的に応じた適当な義務として緩和する見直しを提案します。
（理由）
前回の改正で、オプトアウト規定が厳格化されるなど、いわゆる名簿屋を想定して規定した内容については、名簿屋以外の事業者にとっては、過度に厳しいものになっています。名簿屋を特定することは難しいと思われますが、たとえば、個人情報の利用目的の内容により、名簿屋のような利用をしない事業者については、名簿屋と比較して緩和した記録義務となるように見直すことを提案します。

「個人情報の保護に関する法律についてのガイドライン（通則編、外国にある第三者への提供編、第三者提供時の確認・記録義務編及び匿名加工情報編）（案）」に関する意見募集について

「個人情報の保護に関する法律についてのガイドライン（通則編、外国にある第三者への提供編、第三者提供時の確認・記録義務編及び匿名加工情報編）（案）」に関する意見募集について
　http://search.e-gov.go.jp/servlet/Public?CLASSNAME=PCMMSTDETAIL&id=240000025&Mode=0
（2016年10月04日から2016年11月02日まで実施）
に対して以下のとおり意見を提出しました。

意見１

（該当箇所）
　通則編の９ページから１１ページ

（意見）
　個人識別符号に該当するものとなる例示のイからチまでのすべてについて「本人を認証することができるようにしたもの」という表現をしているが、「本人を認証する」の意味を明瞭にすべきである。そのために、「本人を認証する」を定義するか、「特定の個人を識別する」に書き換えるべきである。

（理由）
　「認証する」とは、何らかの正当性を第三者が証明することを意味し、英語ではcertifyに相当する。コンピュータ等において、英語のauthenticateを認証と訳すことが多いが、それはそのような文脈に限った用法であり、識別し証明することである。英語ではidentify and proofとなる。このどちらの場合においても、「本人を認証する」とは、本人の正当性を第三者が証明する又は本人を識別し証明するとなるが、ガイドラインの文章の意図することが「特定の個人を識別するに足りるもの」との違いが意味不明である。
　「特定の個人を識別する」ことと同じ意味ならば、同じ表現をすべきであるし、異なることを意味したいなら、「特定の個人を識別する」ことと、「本人を認証する」ことの相違を明瞭にすべきである。
　ガイドラインにおいて、これらが明瞭でなければ、日本語の自然な解釈として、「証明する」という行為が含まれることに限定されたものとなり、証明という行為が含まれない場合には、個人識別符号には該当しないということになると考えられる。

意見２

（該当箇所）
　匿名加工情報編の１９ページ「3-4 匿名加工情報の作成時の公表」・下から７行目事例）の「氏名を削除した上で」

（意見）
　該当箇所の「削除」は、日本語における通常の意味の「削除」の場合であって、法第２条第９項における（１）にある「当該一部の記述等を復元することのできる規則性を有しない方法により他の記述等に置き換えることを含む」及び同（２）にある「当該個人識別符号を復元することのできる規則性を有しない方法により他の記述等に置き換えることを含む」を含めないとすべきである。

（理由）
　法が「削除」という日常的に使われる日本語である「削除」の意味に、日常的には異なる意味で使われている「置き換える」を含めていることについて、ガイドライン内での「削除」が日常的な意味なのか法が定義した特殊な意味なのかをわかりやすくするべきである。法のガイドラインであるということからすると、単に「削除」とした場合には、法が定義した意味を用いることになると考えるが、日常的な意味としての「削除」で使う場合には、それを明記すべきである。
　当該箇所の場合には、氏名を何らかの情報に置き換えただけで、自然な日本語の意味としての削除をしていないのであれば、公表項目に「氏名」を含めるべきである。
　ガイドライン案の文章のままで、「氏名を削除した上で」における「削除」を法第２条第９項の括弧書きの定義としての「削除」として解釈して、匿名加工情報の公表項目を省くことは認められるべきではないと考える。

「個人情報の保護に関する法律についての経済産業分野を対象とするガイドライン」の改正案に対する意見

「個人情報の保護に関する法律についての経済産業分野を対象とするガイドライン」の改正案に対する意見公募について
　http://search.e-gov.go.jp/servlet/Public?CLASSNAME=PCMMSTDETAIL&id=595114087&Mode=0
（2014年9月26日から2014年10月28日まで実施）
に対して以下のとおり意見を提出しました。

「Comment-for-PIPA-METI-Guideline.pdf」をダウンロード

2014年12月12日追記：
上記の意見公募の結果が公示されました。
http://search.e-gov.go.jp/servlet/Public?CLASSNAME=PCMMSTDETAIL&id=595114047&Mode=2

「パーソナルデータの利活用に関する制度改正大綱」に対する意見

政府の「パーソナルデータの利活用に関する制度改正大綱」に対する意見募集について
　http://search.e-gov.go.jp/servlet/Public?CLASSNAME=PCMMSTDETAIL&id=060140625&Mode=0
（2014年06月25日から2014年07月24日まで実施）
に対して以下のとおり意見を提出しました。

■意見１■

該当箇所：大綱全体

意見：
　個人情報の保護とプライバシーの保護の関係について、より具体的に整理するべきである。また、個人の権利利益の保護が、個人情報及びプライバシーの保護と同等であるものと推察するが、それについて暗黙とせずに明記すべきである。

理由：
　個人情報の保護とプライバシーの保護の関係についての整理がないままに、「個人情報及びプライバシーの保護」と「プライバシー保護」という表現を共存させることは、読み手によって意図しない解釈の差を生じさせることが懸念される。
　文体としては、前者を国内とし、後者を海外として区別して用いているが、その場合に、それらを同等と整理しているのか、それとも、言葉のとおり前者が２つの観点で、後者はそのうちの１つの観点だけのことという整理なのかが不明確である。
　後者のプライバシー保護については、海外がわが国に期待するプライバシー保護水準との整合を図ることを目的としているものである。しかし、両者の違いが不明確であると、日本が整えたプライバシー保護水準について、海外からすれば水準より以前に保護範囲が異なるという解釈をされてしまうことがあり得ることになる。
　また、前者の表現（個人情報及びプライバシーの保護）においては、個人情報は、法として定義した情報であるのに対して、プライバシーが何を示すのかは不明瞭である。個人情報は情報であるのに対して、プライバシーには情報という接尾辞を付けていない（プライバシー情報やプライバシーに係る情報とはなっていない）ことから、このプライバシーが何を保護することを意図しているかが不明瞭である。

　また、個人の権利利益の保護が、個人情報及びプライバシーの保護と同等であるものと推察するが、そうであれば、本来は、個人情報及びプライバシーの保護という表現は無用又は最小限にとどめ、個人の権利利益の保護とすればよいと考える。

■意見２■

該当箇所：６ページ、２課題／（１）「利活用の壁」を取り払うために

意見：
　「①グレーゾーンへの対応」にある２種類のグレーゾーンに「個人の権利利益が侵害されるおそれに何が該当するかの曖昧さ」を加え、そのグレーゾーンの解消も課題として認識すべきである。それによって、「②個人の権利利益の侵害を未然に防止するために」において保護すべき対象を明確にすべきである。

理由：
　「②個人の権利利益の侵害を未然に防止するために」において、「個人の権利利益の侵害に結びつくような事業者の行為を未然に防止していくことが必要である」とあり賛同するが、どのような行為を「個人の権利利益の侵害に結びつく」ものとするのかが具体的ではない。このことから、どのような事業であれば、個人の権利利益の侵害にはあたらないのかが曖昧なことも、利活用の壁となっている。
　そのような壁を取り払うためには、「①グレーゾーンへの対応」において「個人の権利利益が侵害されるおそれに何が該当するかの曖昧さ」についても解消していく必要がある。

■意見３■

該当箇所：６ページ、２課題／（１）「利活用の壁」を取り払うために

意見：
　①及び②の他に、「個人の権利利益を侵害する実質的なリスクの判断の追加」を加えるべきである。それを実現するために、個人情報の外形的な事前定義への該当性判断だけによる運用を改め、利用目的の必然性や妥当性などにも着目することで、事業者と第三者機関の規律に基づく、個人の権利利益を侵害するリスクの低減を推進し、どのようなリスクをどの程度低減するかについての判断において、マルチステークホルダープロセスを導入して、保護と利活用の両立を図るべきである。

理由：
　現行法の運用では、個人情報の外形的な事前定義への該当性判断をしており、個人情報の利用について実質的な侵害のリスク判断を併用していないが、このことが利活用の壁の１つとなっている。
　それと関連して、利用目的は通知だけすればよく、利用目的の内容についての必然性や妥当性、すなわち、利用目的が個人の権利利益を侵害していないかを検証することについての意識が低くなっている。
　個人情報保護法は、法第１条にその目的を「個人情報の有用性に配慮しつつ、個人の権利利益を保護することを目的とする」と定めている。したがって、個人情報の利活用について既に配慮されたものである。しかし、現行の個人情報保護法が、利活用に配慮されていないという印象を与える原因は、法の条文だけではなく運用にあると考える。個人の権利利益を保護することとは、個人の権利利益を侵害しないことである。そのために、現在の個人情報保護法は、侵害するリスクのある個人情報取扱いの行為を想定し、その行為の主体及び客体並びに行為の内容についての義務を規定したものである。その結果、行為の主体として、「個人情報取扱事業者」を定め、客体として、「個人情報」、「個人データ」、「保有個人データ」を定め、定めた客体のそれぞれに対する行為の義務を規定している。

　そして、革新的なビジネスモデルやサービスなどの新しいアイデアによるビジネスが法に違反しないかの判定は、それらのビジネスを実現するための行為で取り扱う情報が、事前に規定された定義に該当するかどうかだけを解釈して判断される。このとき、その情報が定義に該当していると判断されると、その利用目的や利用形態が、個人の権利利益を侵害するかを個別に判断されることはない。そのため、実質的な侵害リスクがないと考えられるビジネスが規制されてしまう。このことが、利活用に配慮されていないという印象を与える原因のひとつである。
　もちろん、該当性の判断基準だけで侵害リスクの有無が決まる場合には、そのような運用は効率的である。しかし、革新的なビジネスモデルやサービスとそれに伴う新しい技術が起こる近年においては、個別のユースケースや技術を分けずに汎用的な該当性基準を合理的に定めることは困難である。
　そのような状況の中で、該当性基準を無理に定めてしまい、その該当性だけで違法性を判断することは、ビジネスや技術の革新的なアイデアの実行を委縮させることになる。

　利活用の委縮を改善するためには、個人情報を利活用する行為が、個人の権利利益を侵害するリスクについて実質的に判断され、その侵害リスクが低ければ、その利活用を必ずしも違法と判断されないという運用が必要である。
　したがって、事前に定めた情報の定義への該当性についての判断だけではなく、行為による侵害リスクの影響についての実質的な判断も併用するという運用を採用するべきである。

　本大綱では個人情報に該当する範囲の解釈を従来より広げることが検討されているが、その範囲に該当すれば規制され、該当しなければ保護されないという運用が前提となってしまえば、事業者は情報の範囲を狭くして利活用を促進したいと考え、消費者など個人からすれば当該情報の範囲を広くして保護が漏れないようにしたいと考える。
　しかし、事業者は個人の権利利益を明らかに侵害するようなビジネスを想定してはおらず、個人もまた利活用がまったくなされない社会を求めているわけではない。
　両者は共に、個人の権利利益の侵害なく利活用がなされることを望んでいるにも関わらず、保護対象の情報の定義だけを議論するのでは、両者は対峙する関係になってしまいかねない。
　実際に、パーソナルデータ検討会の議論でも、保護推進の立場からは保護対象の範囲を拡大することを求め、他方の利活用推進の立場は狭めようとする意見もあった。しかし、そのような保護対象の範囲の定義にだけ着目した議論では、両者の折り合いが付かない。個人の権利利益の侵害を最終的に抑止するという議論であれば、いったん、保護の対象となりえる情報の範囲を拡大することについて、利活用の立場からも受け入れることができるようになる。
　また、「個人が特定される可能性を低減したデータ」（１０ページ、第３／Ⅱ／１）についても同様のことが言える。こちらは逆に、保護推進の立場からは範囲を狭めたく、利活用の立場からは範囲を広げたいわけである。しかし、個人の権利利益侵害リスクが高い取り扱いを規制するのであれば、利活用する範囲を広げても保護の立場から受け入れやすいものと考えられる。
　以上のとおり、保護と利活用は対峙させるべきものではなく、両立させるべきものでる。 

　なお、情報の利用について実質的な権利侵害のリスク判断が事業者において適正に実施されているかを消費者などが評価するためには、事業者は情報の取り扱いについて透明性を高め、それが公平に判定されるための規律を設ける必要がある。
　事業者は透明性を高めるために、情報の取り扱いをプライバシーポリシーなどに定めて公表することが有用である。
　このような運用をするに際して、従来の個人情報保護法の運用では、事業者個別の侵害リスクを主務大臣が判定するという運用は現実的ではない側面があった。しかし、第三者機関の設置を前提とした運用であれば、その判定を第三者機関が担うことは必ずしも非現実的ではない。
　一方、「個人が特定される可能性を低減したデータ」が定義に該当するかを、技術的に判断するためには、高度な技術力が求められる。そのような要員を第三者機関が持つことは容易ではない。仮に、特定性を低減する加工をしても、特定性をまったく否定できないことが技術検討ワーキンググループから報告されている現状から考えれば、どのような加工であっても、結果的に再特定がされ侵害が起これば、その加工方法は不十分であったと判断することができる。そうなれば、第三者機関の要員に求められるのは、ある行為が個人の権利利益を侵害することか否かという、市民感覚に近い判断であり、それを第三者機関が判断するという運用は、合理的である。また、そこにマルチステークホルダーの考え方を入れることもできる。むしろ、情報の定義の該当性の判断に、マルチステークホルダーを入れることよりも有効である。
　以上のことから、事業者は権利侵害リスクについての対処策についての透明性を高め、第三者機関がその適正性を公平に判定できるようにするための法条文への必要な改正に加えて、法の運用方法についても、情報の外形的な事前定義への該当性判断だけでなく、情報の利用が及ぼす影響について実質的な権利侵害のリスク判断を併用するようにするべきである。

■意見４■

該当箇所：１０ページ／Ⅱの１　個人が特定される可能性を低減したデータの取扱い

意見：
　タイトルについて「個人が特定される可能性を低減したデータ」のような表現を少なくとも「特定の個人を識別することを禁止するための適切な取り扱いをするデータ」とするか、むしろ本意見の意見３を踏まえ、「個人の権利利益を侵害するリスクを低減するための適切な取り扱いをするデータ」などのように書き改めるべきである。

理由：
　「個人が特定される可能性を低減したデータ」という表現からは、データそのものが安全になっているという誤解を受けやすい。実際には、それについての適切な取り扱いや、特定されることを禁止する規約などにより安全が確保されることから、あえて、誤解されやすい表現をするべきではない。
　また、個人が特定される可能性の低減だけが、個人の権利利益の侵害を防ぐわけではなく、個人が特定されないままでも、そのような侵害が起きることについても、保護すべきであるという点においても、「個人が特定される可能性を低減したデータ」という表現は不適切である。

■意見５■

該当箇所：１０ページ／Ⅱの１　個人が特定される可能性を低減したデータの取扱い

意見：
　当該データについて「本人の同意を得ずに行うことを可能」とされるが、その利用目的は、個人情報として取得したときの利用目的の範囲内でだけ可能となることを明記するべきである。

理由：
　本文は、第三者提供において本人の同意を要することについて、情報を円滑に利活用するために、その同意を不要とするというものである。
　これは現行法の第２３条第１項の要件の緩和であるが、その提供の結果として利用される目的については、現行法第１５条、第１６条、第１８条の要件を免れるものではないと考えるべきである。
　特に、第１８条で求められている利用目的の通知等が免れるわけではない。このことが明記されていないと、「本人の同意を得ずに行うことを可能」としていることが、あたかも、そのような利用目的を通知等することも必要なく、本人に対してまったく無通知で最終的に利用してもよいかのような誤解を与えることが懸念される。
　このことは、法第２３条第２項の第三者提供を利用目的とするということとは異なり、当該データを第三者提供した上で、それがどのように利用されるかの利用目的の通知等として求められるべきものである。

自分で解を考える前に正解を見るべきではない

経済産業省 個人情報保護法ガイドラインのQ&Aを強化するための検討会が発足しました。
委員としてお声がけをいただいたので、会合に参加しました。

経済産業省 個人情報保護法ガイドラインのQ&A
http://www.meti.go.jp/policy/it_policy/privacy/privacy_qa.pdf
がありますが、このQ&Aを強化するための検討会が発足しました。

委員としてお声がけをいただいたので、会合に参加しました。

個人情報保護法については解釈が異なると、第三者提供の同意の必要性の有無などで、企業間のトラブルが発生しています。
このような Q&A で、解釈の不一致を軽減できるのならとても有益だと思います。

ただ、解釈の不一致は、法の条文やガイドラインが不明確なためだけに起きているかというとそうではなく、企業側の対策工数を減らそうという思惑で、恣意的に自分に都合のよいような解釈をしているようなことも見受けられます。
法の基本理念を理解し、それに基づいて、法の条文やガイドラインの解釈を正確に行なうということは、本来、企業の担当者の責務であって、Q&A などで「正解」を示されずとも、自身で正解を導き出す能力の向上に努めなければならないとも思います。

Q&A などをあまりやりすぎると、自身で理解し考える能力を鈍化させてしまい、「マニュアル人間」ばかりを作ってしまうことを助長してしまいかねません。

最初から Q&A を見て勉強するのではなく、まず、Q について自身で考えて自分なりの解を導いた後に、Q&A を見てそこにある　A と自分の解とをつき合わせて「答え合わせ」をするという使い方をしてもらえるとよいのだろうと思います。
そうしないと、Q&A に書いてないことはしなくてもいい。とか、してもよい。とかということになって、 Q&A のための Q&A を期待され、さらにその Q&A が必要になって・・・。ということにもなりかねません。

すべきでないこと： 　Q を見て→すぐに A を読む すべきこと： 　Q を見たら→自分で解を考えてから→答え合わせのために A を読む 　その結果、自分の解と A が； 　　一致していたら、自分の判断能力・思考能力の自信の糧にする 　　一致していなければ、自分の解のどこに問題があったのかを考え、A の理解を深める そんなことを考えながら、第1回目の検討会会合を終えました。

連休明けには、当社内で用意している FAQ を全面放出する予定です。