はじめに
この記事は後編です。まだ読んでいない方は、是非、前編からお読みください。
前回の記事を読む
攻めのDX推進（＝データ活用）を安心して進める上で、守りのDX推進（＝データ保護）の実施は必要不可欠である」こと、そして「データ保護活動には大きく３つのポイントがある」ことをご説明しました。
３つのポイントとは、
- リスク分類とリスクベースドアプローチ
- データ保護影響評価
- データプロテクション・バイ・デザイン
です。
リスク分類とリスクベースドアプローチ
リスク分類とは「リスクを、その発生可能性や重大性に応じて分類すること」を指します。
そして、リスクベースドアプローチとは「リスク分類に応じた対策を検討し、優先度の高いものから対策を講じること」を指します。
例えば「データの機密性や完全性、可用性といった観点で区分を分け、それぞれの区分に応じたデータの取扱い方法を定義する」などがあげられます。これは各社で情報セキュリティに関する文書などで規定されていることも多いかと思います。
また既に法令として決まっている場合もあります。例えば、EU AI ActではAIシステムをリスクに応じて４つに分類し、リスク分類に応じた規制を定義しています。（参考：The EU Artificial Intelligence Act）
|
リスク分類 |
具体例 | 求められる義務 |
|
容認できないリスク |
|
|
| 高リスク |
|
|
| 限定的なリスク |
|
|
| 最小限のリスク |
|
|
このように各種法令・規定・ルールで定められたリスク分類をもとに自部門内に対象となるデータが存在していないかを確認し、データを取り扱う上でのリスク分析・評価・対策を検討（＝データ保護影響評価） していくことでデータ保護を実現していきます。
データ保護影響評価
先ほどの「リスク分類とリスクベースドアプローチ」のまとめの中でチラッと登場しましたが、続いてはデータ保護影響評価（Data Protection Impact Assessment、以降DPIA）についてご説明します。
DPIAとは「データ処理の前に実施されるデータ保護に関する影響評価」を指します。
例えば、新しいデータ処理プロセス、システム、テクノロジーを導入する場合や、プライバシーデータを処理する場合など「データ主体の権利と自由」に高いリスクが生じる可能性がある場合に実行する必要があります。
DPIAの全体像は以下のようなイメージです。
それぞれのプロセスを具体的に説明します。
- DPIA要否の判断：
該当するデータの処理に対するDPIAの要否を判断し、不要な場合には、その決定と理由を文書化する。 - データ処理：
処理の背景（入手経路やデータ主体、取得・保存方法など）、処理目的、用途、保護方法、共有範囲などを文書化する。 - 相談：
セキュリティ部門との協議、法律などの外部からのアドバイスなど、個人またはその代表者の意見を収集し記録する。また必要に応じてデータ処理者への支援要請も行う。
- 必要性と適切性の評価：
処理の必要性と適切性を法的な根拠に基づいて評価し、データ主体へのプライバシー情報の提供方法、データ主体の権利の遵守方法、データ処理者のコンプライアンスの確認方法などを文書化する。 - リスクの特定と評価：
データ処理がデータ主体どのような影響（金銭的または経済的な不利益/損失、データ主体が得る機会やサービスの制限、社会的影響など）を及ぼすかを検討・特定し、リスクの重大性と可能性に応じて影響を評価する。 - リスク軽減策の検討：
特定されたリスクごとにその原因とリスク軽減策（データの保存期間の短縮、セキュリティの強化、データの匿名化や仮名化など）を検討・評価し、記録する。 - 結果の承認と記録：
各リスクをどのように処理するか、また残存リスクを文書化する。軽減できないリスクがある場合には、個人データを処理する前にデータ保護当局に相談する。
- 結果の計画への反映：
DPIAの結果をプロジェクトに組み込む。 - 継続的な見直し：
継続的なパフォーマンスを監視するためのルールやプロセスを導入する。
（参考：データ保護影響評価（DPIA）の実施に関するガイドライン ）
DPIAのポイントは２つあります。１つ目はリスクベースドアプローチが推奨されている点です。発生する可能性が低い、または影響がほとんどないリスクに関しては、その判断結果と根拠を文書化するにとどめ、より高いリスクに対する分析と軽減策の検討に注力することで、組織は不必要なリソースを費やすことなく最大限の効果を得ることができます。
２つ目は継続的な取り組みであるという点です。DPIAはシステム構築時にのみ実行すればよいものではありません。データはシステムが生まれる前から存在することもあり、またシステムが変更・廃棄になってもデータは継続して利用されるため、システム開発ライフサイクルとは異なるライフサイクルとなります。定期的に実施することで、新たなデータの発生や最新の法規制などに対応していかなければなりません。
DPIAは、データ処理の内容を明確化しデータの処理に係るデータ主体へのリスクを管理するためだけではなく、情報提供者やユーザ、顧客に対して自社のデータ処理に関する取り組みを説明し信頼を獲得するためや、法令を遵守していることをデータ保護監督当局に対して説明するためにも、非常に重要な取り組みとなっています。
データプロテクション・バイ・デザイン
データ保護活動における3つ目のポイントである、データプロテクション・バイ・デザインとは「保護対象データを取り扱うICTシステムの開発において、開発者は開発プロセスの中にデータ保護対策を組み込む。そして、利用者が追加の設定や費用の必要なく、データ保護に関連する機能を標準利用できる状態にする」という考え方を指します。
データプロテクション・バイ・デザインには、7つの原則があります。
（参考：ICT システムのための「データプロテクション・バイ・デザイン」のガイド）
| 事前的かつ予防的 | データ漏えいが起こる前にデータ保護リスクの評価、特定、管理、予防を行う。 |
| デフォルトとしてのデータ保護 | 個人データを保護する手段はデフォルト設定として自動的に提供されている。 |
| エンド・ツー・エンドのセキュリティ | ソフトウェア開発ライフサイクル全体、そしてデータ通信の開始から終了にわたってセキュリティ対策が配慮されている。 |
| データの最小化 | 目的達成に必要なだけの個人データを収集し、保存し、使用する。 |
| ユーザ中心 | 個人データの保護を目的としてシステムを開発・実装する。また個人が設定をカスタマイズできる機能や方法が、ユーザフレンドリーな形で提供されている。 |
| 透明性の確保 | 何のデータが収集され、どのように使われているのか、誰に処理されているのかなどをユーザに積極的に通知する。 |
| リスクの最小化 | データ保護影響評価によってデータが処理される際のリスクを特定・評価し適切な対策を設計・実装する。 |
この考え方によって、組織の中に個人データをより安全に保護し優れたデータ管理を実践する文化を醸成することができます。またデータ保護機能を後から追加する場合と比較して迅速なリスクへの対応・コストの削減なども可能となります。
システム開発の際には、要件定義から保守までのライフサイクル全体に対して、データプロテクション・バイ・デザインの原則を適用し、データ保護に努めることが重要です。既存のシステムに関しても、収集するデータの必要性を再検討し、データ保護影響評価によるリスク評価をしたうえで、より適切なデータの保護とリスクの低減が実現できるよう再構築していくことが求められます。
おわりに
2回にわたりデータ保護活動についてご説明しました。データ活用の発展に伴い、今後規制強化の波は確実に広がっていくものと思われます。現時点では規制のない領域でも、今後規制対象となる可能性は十分にあります。そのため、すべての企業において「自社内にリスクのあるデータやシステムがないかを継続的に確認し、取扱上のリスク分析・評価・対策を検討し、システムが標準的にデータ保護機能を提供できるよう設計・再構築をする」といった対応が求められます。
データは無色透明・純粋無垢なものであり、多くのリスクを抱えています。人が適切に管理してこそ「資産」となりうる存在です。データ活用推進には、その前提として「安全にデータ活用に取り組める環境づくり」が必須となります。企業の持続的成長・DXを実現するためにも「私たちには関係のない規制だ」「データ保護は成果が見えづらいから…」などと対応を後回しにすることなく、今からデータ保護活動に取り組んでいきましょう。
メルマガで最新情報を受け取る
データ総研に関する最新情報をメールでお送りいたします。データマネジメントweb談義の開催情報や、定期ウェビナのスケジュール、最新ブログ記事の情報などを見逃すことなくチェックできます。こちらのフォームからご登録ください。
