PDPAとは? 企業がすべき8つのこと(セキュリティツールが実際に役立つのはどれか)
タイのPDPCはJ.I.B.社に700万バーツの制裁金を科しました。企業が確認すべき8項目と、セキュリティツールが実際に役立つ範囲を整理します。
PDPAとは? 企業がすべき8つのこと(セキュリティツールが実際に役立つのはどれか)
2024年8月21日、タイの個人情報保護委員会(PDPC)は大手IT製品販売会社J.I.B. Computer Groupに対し、700万バーツの制裁金を科しました。これはPDPA本格施行以降、PDPCが下した最初の行政処分です。
興味深いのは、この700万バーツが一つの違反によるものではなく、3つの内訳に分かれている点です。10万人以上の個人データを処理していたにもかかわらずDPO(データ保護責任者)を任命していなかったこと(100万バーツ)、セキュリティ対策が不十分で情報漏えいに至ったこと(300万バーツ)、そして顧客から23件もの苦情が寄せられていたにもかかわらずPDPCへの72時間以内の通知に間に合わなかったこと(300万バーツ)――つまりこの会社は、一度に複数の義務でつまずいたということです。
タイに拠点を持つ企業、あるいはタイで事業を行う日系企業の担当者が最初に挙げる疑問は、たいてい同じです。「PDPAって結局何項目あって、何をすればいいのか」。この記事ではその8項目すべてに答えます。そして私たちはセキュリティ製品を売る会社であって法律事務所ではないので、正直に言います――security toolが本当に役立つのはどの項目で、どれだけ良いツールを買っても解決しない項目(書類作成、法務判断、人の任命)がどれかを、はっきり分けて説明します。
PDPAとは何か――最短で理解する
PDPAはPersonal Data Protection Actの略で、タイ語の正式名称は「個人情報保護法 仏暦2562年(西暦2019年)」です。2019年に官報で公布されましたが、コロナ禍の影響で施行が何度か延期され、実際に全面施行されたのは2022年6月1日でした。
所管官庁は個人情報保護委員会(PDPC)で、事務局として個人情報保護委員会事務局が実務(ガイドラインの発行、調査、制裁金の決定など)を担っています。
罰則は行政制裁金だけではなく、3つのルートに分かれています。行政制裁金は違反行為ごとに最大500万バーツ(法的根拠のない機微情報の処理など)、刑事罰は禁錮最大1年および/または罰金最大100万バーツ(不正な利益目的や悪意がある場合)、民事責任は実損害の賠償に加えて実損害の最大2倍までの懲罰的賠償が認められています――この3つは独立しており、一つの企業が同時にすべてを科されることもあり得ます。
この法律が保護するのは、識別可能な「個人データ」全般です。顧客、従業員、取引先を問わず、誰かの氏名・メールアドレス・電話番号・IPアドレスなどを扱っている組織であれば、業種を問わずほぼすべて対象になります。IT企業や大企業だけの話ではありません。
PDPAが企業に求める8つの義務
法律の条文の順に沿って、各項目の最後で「zcrが役立つかどうか」を率直に示します。
1. 適法な処理根拠の確保とconsent管理
個人データを収集・利用する前には、必ず何らかの「適法根拠」が必要です。第24条に基づく本人の同意(consent)のほか、契約履行や正当な利益、他の法令遵守といった根拠もあり得ます。宗教、人種、健康情報などの機微情報については、第26条によりさらに厳格な明示的同意が求められます。
これはconsentバナーの設計、consent management platformの構築、データフローごとに適切な法的根拠を選ぶ作業であり、法務顧問やprivacy専門チームの領域です――この工程にzcrの製品が関わることは一切ありません。
2. RoPA(処理活動記録)の作成
第39条は、データ管理者に対しRecord of Processing Activities(RoPA)の作成を義務づけています。どんなデータを、何のために、どれくらいの期間保持し、誰と共有しているかを記録した文書で、PDPCが調査に入った際に真っ先に確認する資料です。
誤解されがちな例外があります。PDPCはSME向けにRoPA義務の免除を告示しており(データ管理者側の適用開始は2025年4月8日)、これはPDPA全体の適用免除ではなく、RoPAという1項目だけの免除です。対象となるSMEの基準は、年間売上高1億バーツ以下かつ従業員50人以下、または売上高5,000万バーツ以下かつ従業員30人以下(業種によって基準は多少異なります)。しかもSME基準を満たしていても、その処理がデータ主体の権利に対するリスクを伴う場合、一時的な処理ではない場合、あるいは第26条の機微情報を含む場合は、結局RoPAの作成が必要です。残り7項目については、SMEであっても大企業と同様にすべて求められます。
この項目はzcrと無関係です――RoPAは組織全体のデータフローを記録する文書であり、log managementやsecurity toolが代わりに作成できるものではありません。
3. Privacy PolicyまたはPrivacy Noticeによる本人への通知
第23条は、データ収集の前または収集時に、何を、何の目的で、どれくらいの期間収集するか、そしてデータ主体にどんな権利があるかを本人に通知することを義務づけています。多くのWebサイトで見かけるPrivacy Policyは、この義務を満たすための一形態です。
これを担当すべきなのは法務チームやprivacyコンサルタントであり、zcrではありません。法律の要件を満たしつつ組織の実際のデータフローと整合したPrivacy Policyを書くのは文書作成の仕事であり、security monitoringの領域ではないからです。
4. データ主体の権利を実現する仕組み
第30条から第36条は、データ主体にさまざまな権利を与えています。データへのアクセス請求権、訂正請求権、削除請求権、データポータビリティ(移転)請求権、そしていつでも同意を撤回する権利などです。組織はこれらの請求を実際に受け付け、処理できる窓口とプロセスを持たなければなりません。単に権利が理論上存在するだけでは足りません。
これはzcrの製品範囲の完全に外側にある話です。請求受付フォームの構築、請求者の本人確認プロセス、社内承認workflowの整備は、CRMやdata governanceのシステムが担う仕事であり、security monitoringではありません。
5. 適切なセキュリティ対策――zcrが本当に役立つ項目
第37条(1)は、データ管理者に対しアクセス制御(access control)、データの暗号化、アクセス記録(audit logging)を含む適切なセキュリティ対策の整備を義務づけています。冒頭で紹介したJIBの事案でこの項目により300万バーツの制裁金が科されたのは、セキュリティ対策の不備によって実際に情報漏えいが起きたためです。
ここがsecurity toolが本当に力を発揮できる場所です。
- zcrLog はシステムとデータへのアクセスログを一元的に収集し、誰がログを閲覧できるかをRBACで制限し、誰が何にいつアクセスしたかのaudit trailを残します。「昨夜、誰が顧客データベースにアクセスしたのか」と聞かれたとき、組織は推測ではなく答えを提示できなければなりません。ログ収集がPDPAと(タイの)コンピュータ犯罪法の両方に抵触しないための具体的な方法は、PDPAとログ管理で詳しく解説しています。
- zcrSIEM はAI-assisted threat huntingにより、アナリストが異常なデータアクセスの兆候をより速く見つけられるよう支援します。「深夜の顧客データベースへの不審なアクセス」のような自然言語をそのまま入力すると、AIがクエリに変換してくれる仕組みですが、生成されたクエリは実行前に必ずアナリストが確認・修正できます――AIに判断を丸投げすることはありません。この機能の詳細はAI-Assisted Threat Huntingとは?をご覧ください。
- zcrWAF は個人データを扱うWebアプリケーションやAPIを、SQLインジェクションをはじめとするOWASP Top 10クラスの攻撃から保護します。こうした攻撃は、攻撃者が顧客データベースからデータを抜き出す際の主要な経路の一つです。
- zcrCTEM は、意図せずインターネットに露出しているassetをスキャンして検出します。設定ミスで外部からアクセス可能になっているデータベースなどを、攻撃者より先に見つけ出します。
これらはすべて、第37条(1)が意味する「適切なセキュリティ対策」を文字通り満たす取り組みであり、単なるマーケティング文句ではありません。
6. 該当する場合のDPO(データ保護責任者)任命
第41条は、組織の主たる活動が個人データ・システムを大規模に継続監視することである場合、あるいは主たる活動が第26条の機微情報の処理である場合、またはPDPCが指定する行政機関である場合に、DPOの任命を義務づけています。この解釈を示す告示は2023年12月13日から施行されています。
注意点があります。多くの記事が「大規模」の目安として引用する「10万人」という数字は、実はPDPC告示が定めた固定基準ではなく、JIBの事案固有の事実(制裁を受けた当時、実際に10万人以上のデータを処理していた)に由来するものです。確実に言えるのは、「大規模」かどうかは実際の活動内容に基づく個別判断であり、法律に明記された固定の数値基準ではないということです。自社が該当するか判断に迷う場合は、自己判断で数字を当てはめるのではなく、法務専門家に直接相談することをお勧めします。
人の任命は組織とHRの問題であり、どんなソフトウェアも代わりに解決できるものではありません。この項目についても、zcrが手伝える部分は一切ありません。
7. インシデント対応計画とPDPCへの72時間以内の通知――もう一つzcrが役立つ項目
第37条(4)は、個人データの漏えいが発生した場合、遅滞なく、そして可能な限り認知してから72時間以内にPDPCへ通知することを義務づけています(リスク評価の結果、データ主体の権利・自由への影響がないと判断された場合は例外があり、72時間を過ぎてしまった場合でも遅くとも15日以内に、遅延の理由を添えて通知する義務があります)。JIBの事案で300万バーツの制裁金が科されたのはこの項目で、理由は自社の検知システムではなく23件もの顧客からの苦情によって漏えいを把握し、しかもPDPCへの通知が期限に間に合わなかったためです。
ほとんどの組織が自問していない問いがあります。「今この瞬間に情報が漏えいしたとして、何時間で気づけるだろうか」。72時間のカウントダウンは事件発生の瞬間ではなく、組織がそれを「認知した」瞬間から始まります。検知が遅い組織は、カウントダウンが始まる前から自分の持ち時間をただ浪費していることになります――これはまさにJIBの事案で実際に起きたことです。
ここでautomationが効いてきます。zcrSIEMのSecurity Operationsダッシュボードでは、インシデントが重大度別に整理され、確認までの平均時間(MTTA)、解決までの平均時間(MTTR)、SLA遵守率、検知までのレイテンシを数字で確認できます。初動のスクリーニングが速いほど、アナリストの時間は手作業でログを1行ずつ追う作業ではなく、「どのインシデントが本当に報告すべき事案か」を判断する仕事に振り向けられます。
検知が速いだけでは十分ではありません。対応も速くなければなりません。zcrSOARはここを補完します。playbookはTrigger型のnodeで起動し、IOC情報のenrichやログの追加取得など本番環境への影響が小さいステップはAction型のnodeが自動で実行します。一方、端末の隔離やアカウントの停止といった本番環境に直接影響するステップの前には必ずApproval型のnodeが挟まり、担当者の判断そのものが必要な場面ではHuman Task型のnodeが処理を引き渡します。この人間参加型(human-on-the-loop)のアーキテクチャの詳細は、SOARにおけるAgentic Automationの仕組みで解説しています。
はっきり言って、手作業の目視確認だけに頼っている組織が、PDPCへの72時間通知に間に合うほど速く漏えいに気づくのは、ほぼ不可能です。
8. 外部委託先とのデータ処理契約
第40条は、クラウドサービス、給与計算のアウトソーシング、マーケティング代理店など、外部にデータ処理を委託する場合、委託先が守るべき範囲とセキュリティ対策を明記した契約を締結することを義務づけています。何の法的拘束力もないままデータを外部に渡すことはできません。
最後のこの項目は契約の話であり、法務・調達チームの仕事です。zcrが関わる領域ではありません。
結論として: zcrが役立つのは8項目中2項目だけ
上記8項目のうち、zcrが本当に役立つのは項目5(セキュリティ対策)と項目7(インシデント対応とPDPCへの適時通知)の2つだけです。残る6項目――consent、RoPA、Privacy Policy、データ主体の権利、DPO、ベンダーとの契約――は、書類作成、法務判断、組織としての意思決定であり、どれだけ優れたsecurity toolを導入しても代わりにはなりません。
私たちがこれをあえて明言するのは、PDPA対応を進めようとしている組織には、最初からその前提を知ってもらうべきだと考えているからです。security投資と並行して法務顧問を確保する必要があるのであって、ツールを一つ買えば全項目が片付くわけではありません。偶然にも、私たちが手伝える2項目は、JIBの事案で科された制裁金のうち最も金額の大きい2つの項目(合計600万バーツ、全体700万バーツの大半)と重なっています。つまり8項目中2項目に過ぎなくても、失敗した場合の金銭的リスクが最も大きい2項目だということです。
まだ何も着手していない場合、どこから始めるべきか
もしPDPA対応にまだ一つも着手していないなら、次の順序をお勧めします。
- まずRoPAとPrivacy Policyの作成について法務顧問に相談する――この2つは他の項目が参照する土台になるため、何を収集しているかを把握して初めて、何を守るべきかが分かります。
- DPO任命の要件に該当するかを評価する。判断に迷う場合は自己判断せず、法務専門家に直接確認してください。
- これと並行して、access control・暗号化・audit loggingなど、第37条(1)が求める具体的なセキュリティ対策の整備を始める。
- インシデント対応計画と、十分な速さで検知できる仕組みを準備する。72時間のカウントダウンは待ってくれません。
3と4は、私たちが十分にお力になれる領域です。組織の規模に合わせてどのプランが適しているか、zcrSIEM、zcrLog、zcrSOARのプランをぜひご覧ください。
お問い合わせ
PDPAの項目5と項目7について、自社がどこまで準備できているか気になりませんか。お気軽にご相談ください。無料でご相談いただけます。
参考資料