データ保護要件を満たす業務システムの設計

仏暦2562年（2019年）個人情報保護法は、タイ国内の個人の個人データを収集、利用、開示する組織に適用されます。同法は、処理の目的と方法を決定するデータ管理者と、管理者に代わって処理を行うデータ処理者を区別しており、個人情報保護委員会（PDPC）が監督しています。同法は、処理の法的根拠、データ主体の権利、セキュリティ上の義務、記録保持の義務、侵害通知の要件を定めています。

本ガイドは情報提供を目的としたものであり、法的助言ではありません。同法、その下位規則、PDPCのガイダンスは随時変更されます。貴社への適用については、データ保護責任者または法律顧問にご確認ください。以下はエンジニアリングの観点です。組織が何かをできなければならないと法律が定めている場合に、それを実現するためにシステムに何が必要かを説明します。

同意を根拠とする場合、システムは、特定の人が、特定の文言で示された特定の利用に、特定の時点で、どのような方法で同意したかを示せなければなりません。同意記録には、データ主体の識別子、目的、その人が目にした通知文または同意文のバージョン、タイムスタンプ、チャネル（Webフォーム、アプリ、紙をスキャンしたもの、電話）、フォームIDなどの証跡を保存します。同意文はバージョンごとに保管してください。その後書き換えられた文面を指す記録では、何も証明できません。

同意の撤回は同意と同じくらい簡単でなければならず、その同意に基づいて動いたすべてのシステムで効力を持たなければなりません。同意は、一度コピーされて忘れられるフラグとしてではなく、後続のシステム（マーケティングプラットフォーム、ニュースレター配信、分析パイプライン）が利用時点で確認する一元的な状態として設計します。当社Webサイトのニュースレターは、このパターンの小さな例です。メールによるダブルオプトイン、すべてのメッセージに記載した配信停止リンク、送信前に適用する配信停止リストを備えています。

同意がすべてに適した根拠というわけではありません。給与計算のための従業員データの処理や、購入品の配送のための顧客データの処理は、契約または法的義務に基づきます。こうした場合に同意を求めると、組織が応じられない撤回の権利が生じてしまいます。根拠を正確に選べば、同意記録の数は減り、より意味のあるものになります。

同法は適切なセキュリティ措置を求めています。システムの観点では、それは最小権限から始まります。各ロールが業務に必要な項目だけを参照でき、それ以外は見えないロールベースのアクセスです。オーナー／管理者／メンバー／閲覧者のモデルはワークスペースの土台として適していますが、業務アプリケーションには通常、より細かいロールが必要です。たとえば倉庫作業者は配送先住所を参照できても国民ID番号は参照できず、サポート担当者はカード番号の末尾4桁は参照できても完全な番号は決して参照できない、といった具合です。どのクライアントからも回避できないようAPIレイヤーで適用するフィールド単位のマスキングは、個人データやセンシティブな項目に対して取り組む価値があります。

最小化は、収集時にもあらゆるコピーにも適用されます。目的に必要な項目だけを収集し、本番の個人データをテスト環境や開発環境にコピーせず、代わりにテストデータを生成するか匿名化し、エクスポートや一括ダウンロードを必要なロールに限定して、そのすべてを記録します。これらすべてを強固な認証が守ります。組織のIDプロバイダーによるシングルサインオン、2要素認証、対応している場合はパスキー、そしてデータの機密性に見合ったセッションタイムアウトです。

組織が依存するデータ処理者（ホスティング、メール、分析、AIサービス）とは、同じ水準を義務づける契約を結ぶ必要があり、アーキテクチャ上も、どの個人データがそれぞれに流れるのかを明確にしておくべきです。

個人データは、目的に必要な期間、または法律が求める期間だけ保持できます。これを、データ区分ごとに期間と法的・業務上の理由を定めた保持スケジュールに落とし込みます。たとえば、会計記録は税法が求める期間、求職者のデータは採否決定後の一定期間、休眠状態の顧客アカウントは一定の非アクティブ期間の後、サポートチャットの記録は一定期間の後、といった具合です。そのうえで、スケジュールを自動化します。年に一度誰かがスクリプトを実行することに頼る保持方針は、管理策とはいえません。

削除を技術的にどう行うかを決めます。論理削除はデータを見えなくするだけで、データ自体は残ります。物理削除または匿名化までの短い猶予期間としてのみ許容できます。匿名化は、統計情報を残しつつ識別子を削除するか不可逆的に変換するもので、個人を保持することなく業務の履歴を残せます。バックアップにも同じ扱いが必要です。保存期間を定め、暗号化されていることを確認し、復元したデータにも、バックアップ取得後に行われた削除が反映されるようにします。

データ主体は、組織が自分について保持している情報の開示、写しの提供や訂正、削除を求めることができ、処理に異議を申し立てたり制限を求めたり、同意を撤回したりできます。管理者は、同法と規則が定める期間内に対応しなければなりません。システムに求められるのは、研修を受けたスタッフがエンジニアの手を借りずにこれらの請求に対応できる仕組みです。モジュールを横断してある人物のすべてのレコードを見つけ、その人の個人データを読みやすい形でエクスポートし、監査記録を残しながら項目を訂正し、守るべき保持ルールに従って削除または匿名化を実行できることです（顧客が削除を求めたからといって請求書を削除することはできません。法的根拠を記録したうえで保持できます）。

請求ログを作成します。誰が、いつ請求し、本人確認をどう行い、何を実施し、いつ完了したかを記録します。このログは、法令遵守の証明になると同時に、どこでプロセスが滞っているかも示します。

監査ログは、誰が、いつ、どのデータに対して何をしたかを記録します。ログイン、権限の変更、個人データの閲覧とエクスポート、編集と削除、設定の変更などです。監査ログは操作の時点でアプリケーションが書き込み、書き込み権限を制限したうえで業務データとは別に保存し、意図して定めた期間保持する必要があります。同じデータベースに置かれ、同じ管理者が扱うログでは、内部の不正行為から守ることはできません。

ログは存在するだけでなく、役に立つものにします。人物やレコードで検索でき、定期的にレビューされ、一括エクスポートや業務時間外のアクセスといった通常と異なるパターンにはアラートが出るようにします。監査ログ自体にも個人データが含まれるため、保持スケジュールの対象に含めます。

同法は、個人データの侵害を認識した場合、権利と自由へのリスクが生じるおそれが低い場合を除き、管理者に対し、不当な遅滞なく、可能な場合は認識から72時間以内にPDPCへ通知することを求めています。リスクが高い場合は、影響を受けたデータ主体にも通知しなければなりません。72時間はすぐに過ぎます。システム面での備えは検知です。つまり、不正アクセスを明らかにできるログとモニタリング、そして、どのデータが、誰について、どの期間影響を受けたかを素早く特定できる能力です。

組織面での備えは、文書化されたインシデント対応プロセスです。誰に最初に報告するか、誰がリスクを評価するか、誰が通知文を起草するか、誰が顧客と話すかを定め、組織が業務で使う各言語のテンプレートを事前に用意しておきます。現実的なシナリオで机上演習を毎年実施し、ランブックを初めて使うのが実際の侵害の最中にならないようにします。