WordPress 4.9.6の個人data削除は依頼を受ける前に確認と保存先を分ける

WordPress 4.9.6で個人dataのerasureを使うときは、依頼を受けたらすぐ削除しません。誰からの依頼かを確認し、WordPressが扱うdataとpluginが扱うdata、mailや受注systemなどWordPressの外にある保存先を分けます。そのうえで、何をexportまたは削除し、何を残したかを記録します。管理画面のbuttonを押す作業と、依頼へ責任を持って答える作業は別です。

WordPress 4.9.6では、site ownerが利用者の個人dataをZIP fileとしてexportし、erasureできるようになりました。WordPressと参加pluginが集めたdataを対象にでき、exportとerasureの依頼はemailで確認します。この確認はregistered userだけでなくcommenterにも使えます。privacy policy pageを指定し、login pageとregistration pageへ表示する機能も加わりました。 WordPress.orgの案内

依頼を受ける窓口と実行する人を分ける

個人dataについての問い合わせは、contact form、mail、電話など、複数の経路から届くことがあります。依頼を受けた人が、その場で管理画面を開き、見つかったdataを削除する運用にしません。最初に、どの窓口で受けるか、依頼内容を誰が確認するか、WordPressのexportまたはerasureを誰が実行するか、回答を誰が送るかを決めます。

WordPress 4.9.6にはemailを使ってpersonal data requestを確認する仕組みがあります。これは、依頼を受けた人が表示名やmail addressだけを見て、本人だと判断する代わりにはなりません。依頼の受付、WordPressが送る確認mail、確認後の実行、回答は、それぞれ記録します。確認mailを送ったことと、dataを削除したことを同じ状態として扱わないでください。

たとえば、commentを投稿した人から削除の問い合わせが来た場合を考えます。受付担当は、依頼の日時、連絡先、求められている内容を記録します。実行担当は、確認された依頼にもとづいてWordPress内の対象を調べます。回答担当は、実行したこと、対象外だった保存先があるか、追加の確認が必要かを伝えます。一人で兼ねる場合も、順番を分けて残せば、問い合わせmailを読んだだけで削除まで済ませたことにはなりません。

exportとerasureは同じ依頼でも目的が違う

exportは、siteが保持している個人dataを確認できる形で渡すための処理です。erasureは、対象になる個人dataを消すための処理です。利用者が「自分の情報を知りたい」と言っているのか、「消してほしい」と言っているのかで、行う処理は違います。一つの依頼へ両方を行う必要があるかは、依頼内容と決めた対応方針を見て判断します。

exportのZIP fileには、WordPressと参加pluginが集めた利用者のpersonal dataを含められます。fileを作れたことは、site内にあるすべてのdataが入ったことを意味しません。mail software、受注管理、予約system、外部のaccess analytics、広告serviceなど、WordPressの外に保存しているdataは別に確認します。WordPressから出せるfileを、事業全体の記録だと説明しないでください。

erasureも同じです。WordPressで対象を消せることと、外部service、backup、mail box、帳票の保存先まで同時に消えることは別です。WordPress内のdata、pluginが扱うdata、WordPress外のdataを表へ分け、どの保存先を誰が確認するかを書きます。消せるかどうかの判断や、残す必要がある記録は、利用しているserviceと事業の条件により変わるため、管理画面の機能だけから結論を出しません。

pluginが参加しているかを先に確認する

WordPress 4.9.6は、WordPressと参加pluginが集めたpersonal dataをexportまたはerasureの対象にできます。siteへpluginを入れている場合、すべてのpluginのdataが自動で同じように扱われると決めつけません。contact form、membership、reservation、online store、comment spam対策、mail配信など、dataを扱うpluginごとに、何を保存し、WordPressの新しいtoolへ参加しているかを確認します。

pluginの表示画面に利用者名やmail addressが出ることと、exportまたはerasure toolへdataを渡していることは別です。管理画面の一覧で削除したデータが、plugin独自のtableや外部serviceに残っている場合もあります。pluginのnameだけを一覧にするのでなく、保存するdata、保存先、exportの対象か、erasureの対象か、確認する人を並べます。

説明用の仮例として、contact form pluginと予約pluginを使うsiteを考えます。contact formは問い合わせ内容をmailだけで受けるかもしれません。予約pluginはWordPressのdatabaseだけでなく、外部のcalendar serviceへ予定を送るかもしれません。二つを同じ「問い合わせdata」として扱うと、どこを確認すべきか分かりません。利用者からの依頼を受けたときは、form、mail、予約、外部serviceを別の保存先として確認します。

pluginを制作会社が選んだ場合も、siteを持つ側はplugin name、更新する人、dataの保存先、exportとerasureに参加するかを把握します。pluginを外せばdataの確認も不要になるとは限りません。停止前に、保存したdata、設定、連携先、必要な記録をどう扱うかを決めます。

privacy policy pageは案内の入口であり処理の代わりではない

WordPress 4.9.6ではprivacy policy pageを指定でき、login pageとregistration pageへ表示できます。footerなどからsiteの各pageへlinkを置くことも案内されています。pageを指定しただけで、実際に使っているform、comment、plugin、mail、外部serviceの説明までそろうわけではありません。

policy pageには、siteがどのようなdataを集め、何のために使い、どこへ送るかを、実際の運用に合わせて書きます。WordPressはpolicy作成のために、coreと参加pluginから参考になる情報を示します。参考文をそのまま貼る前に、自分のsiteで使っていないpluginやserviceの記述が混ざっていないかを確認します。説明文を追加する仕事と、dataをexportまたはerasureする仕事は別に管理します。

たとえば、contact formを使っていないsiteへ問い合わせdataを保存する説明を残せば、読者へ誤った案内を渡します。反対に、formを使ってmailへ情報を受け取っているのに、policy pageで何も説明しなければ、実際の運用と表示が食い違います。文章を作る人、formを設定する人、pluginを管理する人が別なら、policy pageの更新を誰が承認するかも決めます。

実行前と実行後に確認することを分ける

personal data requestを処理するときは、次の順序で確認します。

表は、個別の法的な結論を決めるものではありません。受付から回答までに、誰が何を確認したかを残すための順序です。exportしたfileを渡す場合は、渡す相手と経路を慎重に確認します。erasureを行う場合は、実行前に対象範囲を確認し、実行後にWordPress側の結果と外部保存先の確認状況を分けて記録します。

作業を頼む場合も、「個人dataを削除してほしい」とだけ渡しません。依頼の確認を済ませたか、対象site、対象accountまたはcommenter、WordPressで行う処理、pluginと外部serviceの確認範囲、回答する人を渡します。制作側が管理画面を操作できても、依頼を受ける判断や、事業上の保存先を決める責任まで自動で引き受けるわけではありません。

toolを入れたことと対応を終えたことは別である

WordPress 4.9.6のprivacy toolsは、site ownerがpersonal dataを扱うための手段を増やします。けれども、どのdataを集めているか、どこへ送っているか、依頼をどのように確認するか、何を残すかを自動で判断しません。updateを適用した日をもって、個人dataに関する対応が終わったとは考えません。

最初の一手は、siteで使っているform、comment、plugin、mail、外部serviceを一つずつ挙げ、保存するdataと担当を表へ書くことです。次に、依頼を受ける窓口と実行する人を決め、test用の依頼でexportとerasureの画面を確認します。管理画面の新しいtoolと、実際にdataを扱う経路を分けて見れば、依頼が来たときに慌てて削除する運用を避けられます。