目次


GDPR 準拠のアプリケーションを開発する, 第 2 回

アプリケーションのプライバシー仕様

Comments

コンテンツシリーズ

このコンテンツは全#シリーズのパート#です: GDPR 準拠のアプリケーションを開発する, 第 2 回

このシリーズの続きに乞うご期待。

このコンテンツはシリーズの一部分です:GDPR 準拠のアプリケーションを開発する, 第 2 回

このシリーズの続きに乞うご期待。

アプリケーションのプライバシー・リスクでは、アプリケーション・ユーザーが、アプリケーションによって管理されている自分の個人情報を管理できない場合に、ユーザーに与える恐れのある苦痛と損害が考慮されます。ユーザー向けにアプリケーションを直接プロビジョニングする組織は、データ管理者としての組織に固有のプライバシー・リスクにさらされます。このリスクには、アプリケーションが EU 市民のユーザーに EU 一般データ保護規則 (GDPR) で規定されているプライバシー権を与えていない場合、管理者としての組織が信用を失い、財政的な影響を被ることも含まれます。したがって、アプリケーションのプライバシー・リスクを完全に理解および評価し、必要と思われる場合には許容されるレベルにまでリスクを軽減しなければなりません。それには、アプリケーション開発ライフサイクル内にプライバシー仕様を統合することが必須の手法となります。アプリケーションのプライバシー仕様は、GDPR では、設計によるデータ保護とも呼ばれています。

この記事は、EU 一般データ保護規則 (GDPR) 準拠のアプリケーション開発に関するガイダンスを提供するシリーズの第 2 回です。第 1 回では GDPR の要点を解説し、第 3 回ではアプリケーションのプライバシー・リスクを軽減する実用的なアプリケーション開発手法について説明しています。

GDPR での設計によるデータ保護の要件

GDPR 第 25 条では、管理者の役割を担う組織には、設計によるデータ保護の要件が適用されると規定しています。この規定は、開発者の組織内で使用するために社内で開発されたアプリケーションに直接適用されます。一方、外部組織で使用するためのアプリケーションを開発する場合でも、その外部組織は管理者として、アプリケーション開発者と協力しながらアプリケーションのプライバシー・リスクを理解し、検証しようと務めることになります。したがって開発者は、アプリケーションが社内用であるか、管理者の役割を担う他の組織用であるかに関わらず、設計によるデータ保護という開発手法を採用しなければなりません。

GDPR 第 25 条 (2) では、設計によるデフォルトでのデータ保護を要件としています。この要件はつまり、アプリケーションをユーザー向けにプロビジョニングする時点で、アプリケーションのすべてのプライバシー設定がユーザーのプライバシーを保護するように設定されていなければならないことを意味します。

第 25 条「設計によるデフォルトでのデータ保護」(1) 管理者は、到達水準、実装のコストと性質、適用範囲、処理のコンテキストと目的ならびに処理によって引き起こされる自然人の権利および自由に対するさまざまなリスクの可能性を考慮し、処理の手段を決定する時点、および処理する時点の両方において、本規則の要件に合致させるため、およびデータ主体の権利を保護するために、適切な技術的および組織的対策 (例えば仮名化) を実施しなければならず、データ保護の原則 (例えばデータ最小化) を効果的な方法で履行すること、および必要な保護措置を処理に統合することが意図された対策を取るものとする。(2) 管理者は、具体的な処理の目的に必要な個人データのみが、デフォルトで処理されることを保証するための適切な技術的および組織的対策を実施するものとする。当該義務は収集された個人データの量、処理の範囲、保管期間およびアクセス可能性に適用される。特に当該対策は個人データが個人の介在なしに不特定多数の自然人にアクセスされないことをデフォルトで確実にするものとする。第 42 条による承認済み認証メカニズムは、本条第 1 項および第 2 項で規定されている要件の順守を証明する要素として用いてもよい。備考 78 で補足。

設計によるデータ保護の要件を満たすアプリケーションを開発するために不可欠なツールとなるのは、データ保護影響評価です。

アプリケーションのデータ保護影響評価

アプリケーションのデータ保護影響評価 (DPIA) を利用することで、開発者はアプリケーションがそのユーザーのプライバシー権と自由にどのような影響を与えるかを特定し、分析、説明することができます。個人情報を収集、保持、共有するよう意図されたアプリケーションに対しては、DPIA を実施する必要があります。

ソフトウェア開発ライフサイクルの早い段階で DPIA を組み込めば、開発者はアプリケーションの設計が完了する前に、許容されないプライバシー・リスクを軽減し、GDPR のユーザー・プライバシー権に関する準拠の問題を解決することができます。このように DPIA をソフトウェア開発ライフサイクルに組み込むことで、プライバシー・リスクが最小限になるよう効果的にアプリケーションを開発してユーザーの利益を確保するとともに、アプリケーションをプロビジョニングするデータ管理者としての組織のプライバシー・リスクを最小限に抑えられるようになります。

すでにリリースされて本番環境で使用されているアプリケーションにも、遡及的に DPIA を実施して、それらのアプリケーションのプライバシー・リスクが許容範囲内であることを確実にし、GDRP に準拠していることを確認する必要があります。

アプリケーション DPIA に関与する役割とその責務

アプリケーション DPIA には、以下の役割と責務が関与することになります。

  • 開発者チームのリーダーは、アプリケーション DPIA プロセスを管理する責任を負います。開発リーダーがいない場合、DPIA の責任は、アプリケーション開発プロジェクトの管理者が負うことになります。
  • データ保護職員 (DPO) またはデータ・プライバシー分野の専門家がコンサルティングに応じ、DPIA プロセスをサポートする必要があります。この点は、GDPR 第 35 (2) で DPIA の要件として挙げられています。第 35 (2) - 管理者は、データ保護影響評価を実施する際に、データ保護職員が任命されている場合はその職員に助言を求めるものとする。
  • DPO として組織外の人材 (開発組織で DPO の役割を設けていない場合) または十分なデータ・プライバシーの専門知識を有する個人を任命することもできます。DPO は、DPIA の完了を承認する必要もあります。
  • 情報セキュリティーの専門家またはアプリケーション・セキュリティーのスペシャリストは、コンサルティングに応じ、アプリケーションの開発全体を通してアプリケーション・セキュリティーのベスト・プラクティスが採用されていることを確認する必要があります。
  • リスク管理者には、コンサルティングに応じて、プライバシー・リスクの管理手法についてアドバイスすることが推奨されます。
  • 開発プロジェクトの管理者は、DPIA の結果と措置について通知を受ける必要があります。
  • プロジェクトのスポンサーおよび事業担当ディレクターが、プライバシー・リスクについて責任を負います。したがって、これらの役割に DPIA の状況を報告し、完了した DPIA のコピーとアプリケーションのプライバシー・リスク登録簿を提出する必要があります。
  • 外部のデータ処理業者用のアプリケーションを開発する場合は、その処理業者固有の DPIA プロセス、GDPR 義務の検証、プライバシー・リスクの管理の一環として、アプリケーション DPIA とアプリケーション実装のプライバシー・ガイダンスのコピーを求められることを予期して対応に備えてください。

SDLC 内での DPIA の実施

ソフトウェア開発ライフサイクル (SDLC) の要件分析フェーズで、GDPR によってアプリケーションに課せられるプライバシー権の保護の義務を要件として文書化する必要があります。DPIA はまず、SDLC の設計フェーズで実施します。さらに、以降のすべてのフェーズでプライバシー・リスクに関する徹底的な検証を実施して、アプリケーションのプライバシー要件のすべてが満たされていること、そしてアプリケーション設計で目的どおりにプライバシー・リスクが確実に軽減または排除されるようにします。

アプリケーション SDLC (ウォーターフォール・モデル) には以下のフェーズがあります。

  1. 要件分析 (GDPR プライバシー権の保護の義務)
  2. 設計 (DPIA)
  3. 開発 (DPIA の結果に応じた措置の実施と GDPR プライバシー権を保護するための機能の提供)
  4. テスト (DPIA の結果、GDPR プライバシー権を保護するための機能、アプリケーション・セキュリティーのテスト)
  5. 実装 (プライバシー実装ガイダンス)
  6. 保守 (DPIA の再レビューと更新)

GDPR プライバシー権の保護の義務については、このガイダンス・シリーズの第 1 回で説明しています。プライバシー・リスクが識別された場合、そのリスクを評価する際には、データベース暗号化や仮名化などを使用してそのリスクを最小限にするための技術的アプリケーション・ソリューションの設計を視野に入れなければなりません。このような技術的ソリューションについては、このガイダンス・シリーズの第 3 回で説明しています。

アプリケーション DPIA のプロセス

アプリケーション DPIA には 6 つのフェーズがあります。

  1. DPIA の必要性を識別する
  2. 個人データのフローを記述する
  3. プライバシー・リスクを識別する
  4. プライバシー・ソリューションを決定して評価する
  5. DPIA の結果を文書化し、DPO の承認を取る
  6. 開発計画内の DPIA プライバシー・ソリューションを実装する

DPIA の必要性を識別する

データ保護影響評価の実施を要件として規定している GDPR 第 35 条 (1) では、「新たなテクノロジー」は個人に対して「高リスクを生じさせる可能性がある」としています。これを補足する備考 75 では、個人データを処理するアプリケーションに特有のプライバシー・リスクについて、「処理によって、差別、盗難または不正、金銭的損失、評判へのダメージ、職業上の秘密保持によって保護されている個人データの機密性の損失、不正な仮名化解除、またはその他の多大な経済的または社会的不利が生じるリスク」と記述しています。

第 35 条 (1) の規定により、新しいアプリケーションの開発も「新たなテクノロジー」と見なされる可能性があります。GDPR では、アプリケーションがマスメディア上の個人データを処理する場合の「高リスク」を具体的に定義していませんが、ほとんどの監督機関は、アプリケーションがインターネットに接続する場合は尚更のこと、そのようなアプリケーションにはユーザー・プライバシーに対する高リスクが伴うと見なすはずです。したがって、GDPR 第 35 条 (1) に従うためには、アプリケーションが EU 市民の個人情報を処理する可能性がまったくないのでない限り、開発したすべてのアプリケーションに関して DPIA を実施することが推奨されます。

第 35 条 (1) - 特に新たな技術を用いるような処理が、その性質、範囲、コンテキストおよび目的を考慮すると、自然人の権利や自由に高リスクを生じさせる可能性がある場合、管理者は、処理の前に、予定された処理作業の個人データ保護への影響評価を実施するものとする。同様の高リスクを示す同様の処理作業の集合に対して、単独の評価を実施して対処することは許可される。

第 35 条 (7) - データ保護影響評価には、少なくとも以下の事項を含むものとする。
(a) 予想された処理作業および処理の目的に関する体系的な記述。該当する場合は、管理者が追求する正当な利益も記述に含めること
(b) 目的に関する処理作業の必要性および比例性についての評価
(c) 第 1 項で定めるデータ主体の権利および自由に対するリスクの評価
(d) リスクに対処するための対策の策定。これには、データ主体および関連する他者の権利および正当な利益を考慮し、個人データの保護を確実にするとともに、本規則の遵守を証明するための保護措置、安全対策および安全メカニズムを含めること

個人データのフローを記述する

アプリケーション DPIA は文書化する必要があります。文書化する際は、まず、アプリケーションの全般的目的を記述し、アプリケーションの機能の概要を簡潔にまとめるようにしてください。また、アプリケーションを開発する組織が GDPR における管理者 (アプリケーションをプロビジョニングする役割) または処理者 (アプリケーションをホストするだけの役割) であること、あるいはいずれの役割にも該当しないことを記録します。

次のステップは、アプリケーションが個人情報を取得、処理、保管する方法、およびアプリケーション外部に個人情報を移す方法を特定して記述することです。それには、アプリケーション・アーキテクトの支援を受けて、アプリケーションのデータ・フローと処理をレビューし、マッピングします。データ・フロー図を使って文書化すると、アプリケーションのプロセスと個人データのフローを明確に記述して理解しやすくすることができます。図 1 に、その一例を示します。

アプリケーション・データ・フローの例
アプリケーション・データ・フローの例
アプリケーション・データ・フローの例

データ・フロー図に加え、アプリケーションで個人データをどのように使用するのかについて、包括的な詳細を記録してください。アプリケーションの設計をレビューし、技術リーダーと以下の側面について調査します。

  • 個人データの収集
    • 個人データの取り込み:
      • ユーザー・アカウントの作成プロセス
      • ユーザー・データの入力およびデータ編集機能
      • データ転送による取り込み (つまり、サード・パーティーのソースからデータを取り込むこと)
    • 個人データ・フィールド:
      • 個人データを保持する具体的なフィールド名とテーブルを文書化します。
      • 直接または間接的に個人を特定すると見なされる個人データ・フィールド (つまり、氏名、e-メール・アドレス、アカウント番号、位置データを保持するフィールド) にフラグを立てます。
      • GDPR で「特別カテゴリー」の個人データとして規定されている個人データ・フィールド (つまり、生体、健康、人種、政治的見解、宗教、遺伝学的データを保持するフィールド) にフラグを立てます。
      • 個人の場所を特定または追跡するために使用できる個人データ・フィールド (つまり、Cookie、IP アドレス、地理的データを保持するフィールド) にフラグを立てます。
      • 個人データ・フィールドとして指定されていないが個人データを保持する可能性がある、あらゆるフィールド (つまり、ユーザーが個人を説明するデータを自由に入力できる、テキスト・ボックスなどのフィールド) にフラグを立てます。
    • 個人データ・フィールドそれぞれの目的を文書化します。個人データ・フィールドとして特定されたフィールドごとに、個人データを収集して処理する理由を文書化します。
    • そのアプリケーションを子供が使用する可能性があるかどうかを文書化します。
  • 個人データの処理
    • アプリケーションでどのように個人データを使用するかを文書化します。
    • アプリケーションによって自動的に行われる個人データの変更または作成について詳説します。例えば、アプリケーションによる個人データの自動処理、プロファイリング・プロセス、ユーザー・アクティビティーの記録などについて詳しく説明します。
    • プライバシーの侵害として認められる可能性のあるテクノロジーまたはプロセス (つまり、生体認証、ユーザーの位置追跡、遺伝子学的データの分析など) をアプリケーションで使用しているかどうかを文書化します。
  • ユーザー・アクセスおよび操作
    • アプリケーション・ユーザーが自分の個人データを以下の点で操作できるかどうかを文書化します。
      • ユーザーが自分の個人データ・フィールドのすべてを表示できるかどうか
      • ユーザーが自分の個人データを編集したり削除したりできるかどうか
    • 個人データに対する特権レベルのアクセス権を与えるすべてのユーザー・アカウント・ロールについて文書化します。これらのロールには、複数のユーザーの個人データ・レコードにアクセスできる管理者、スーパーバイザー、サポート、およびレポート・アカウントが該当します。これらのアカウント・ロールの個人データに対するアクセス、変更、エクスポート機能について詳説します。
  • 個人データの保管
    • アプリケーションが個人情報を取得および保管するために使用するすべてのデータベース/テーブルの詳細を記録します。
    • 各データベース/テーブルがホストされる場所 (つまり、サーバー/システム) および物理的な配置場所を記述します。ローカル・ホスティング、サード・パーティー/クラウドでのホスティング、およびバックアップ・システムを考慮に入れてください。
    • モニタリング・システムやロギング・システム (つまり、ローカル・アプリケーション・サーバーのログ、アプリケーションから syslog サーバーへのエクスポート) 内での個人データの保管または使用について詳しく説明します。
  • 個人データの出力
    • 個人データのすべての出力ポイントを文書化します。レポート、e-メール・メッセージ、SMS、郵便 (印刷)、外部へのバルク・データ転送、データ抽出プロセスを考慮に入れてください。
    • あらゆる個人データの共有とアクセシビリティーについて、以下の点を文書化します。
      • サード・パーティー組織、アプリケーション内の他のユーザー、他のアプリケーションとの接続または公開された (つまりソーシャル・メディア) 接続による共有とアクセス
      • サード・パーティーのサポート (つまり、リモートでの技術サポートとシステム・アップグレード)

アプリケーションでの個人データの使用について技術的に文書化するには、スプレッドシートやテーブルが便利な手法になります。図 2 に一例を示します。

アプリケーションによる個人データ使用の技術的文書化
アプリケーションによる個人データ使用の技術的文書化
アプリケーションによる個人データ使用の技術的文書化

プライバシー・リスクを識別する

DPIA の次のステップは、個人データ・フローのドキュメントをレビューして、プライバシー・リスクを識別することです。このレビューには、データ保護職員またはプライバシー分野の専門家による支援が必要です。また、公式にリスク評価を進めて文書化するために、リスク管理者やリスク専門家を関与させる必要もあります。

アプリケーション DPIA で検討し、文書化するプライバシー・リスクは、一般に以下の3 つに分類されます。

  • アプリケーション・ユーザー (データ主体) のプライバシー・リスク
  • アプリケーションでユーザーに対する DFPR プライバシー権を支援する上でのプライバシー・リスク
  • 管理者または処理者としての組織のプライバシー・リスク

アプリケーション・ユーザーのプライバシー・リスク

アプリケーション・ユーザーのプライバシー・リスクを評価する際は、アプリケーションがユーザーのプライバシー権と自由を侵害する可能性があるあらゆるシナリオについて、プライバシーが侵害される可能性、ユーザーに及ぼす可能性がある影響 (精神的苦痛や金銭的損失など) と併せて考慮してください。

アプリケーションによる以下のようなプライバシーの侵害はユーザーに悪影響を及ぼす可能性があるため、調査する必要があります。

  • 機密性: 意図的でないか悪意があるかに関わらず、個人データの侵害が伴うシナリオ
  • 完全性: 正確ではない個人データが保管されるという結果に至るシナリオ
  • 可用性: ユーザーがアプリケーションまたは個人データにアクセスできなくなるシナリオ

識別したプライバシー・リスクの各シナリオを、リスク登録簿に記入します。登録簿には、各リスクの採点も記入します。リスクの採点は、プライバシーが侵害される可能性をユーザーのプライバシーに与える影響と併せて分析することによって評価します。図 3 に、アプリケーションのリスク登録簿の例を示します。

リスク登録簿
リスク登録簿
リスク登録簿

アプリケーションでユーザーに対する DFPR プライバシー権を支援する上でのプライバシー・リスク

アプリケーションに影響する GDPR ユーザー・プライバシー権はいくつもあります。これらのプライバシー権については、このガイダンス・シリーズの第 1 回で説明しています。アプリケーション・アーキテクトの支援を受けて、アプリケーションの設計ドキュメントをレビューし、適用される GDPR ユーザー・プライバシー権ごとに、アプリケーションがそのプライバシー権を支援しているかどうかを評価してください。これらのプライバシー権には、以下があります。

  • 知らされる権利 (第 12 条)
  • アクセスする権利 (第 15 条)
  • 消去する権利 (第 17 条)
  • 処理を制限する権利 (第 18 条)
  • データ・ポータビリティーの権利 (第 20 条)
  • 異議を唱える権利 (第 21 条)
  • プロファイリングを含む自動判断の適用対象外となる権利 (第 22 条)

GDPR プライバシー権のそれぞれを十分に支援するアプリケーション・プロセスについて、DPIA ドキュメント内に文書化してください。適用される GDPR プライバシー権のうち、アプリケーションが十分に支援していないものがある場合は、それをプライバシー・リスクとしてリスク登録簿に文書化します。

組織のプライバシー・リスク

管理者または処理者の役割にある組織が GDPR に準拠していない場合、その組織は非常に厳しい制裁を受けることになります。これらの制裁には、監督機関による多額の罰金徴収、ユーザーからの法的損害賠償請求、個人データの処理の禁止が含まれ、さらに組織の評判にもダメージが及ぶ場合があります。したがって、DPO の支援を受けて組織のプライバシー・リスクを評価してください。また、それらのリスクを登録簿に記録する必要もあります。

ソフトウェアを開発する組織に管理者の役割が適用される場合、つまりアプリケーションを直接ユーザーに提供する場合は、以下のリスクがあるかどうかと、そのリスクが開発組織に及ぼす潜在的影響を考える必要があります。

  • ユーザーから同意を得ていない、またはプライバシー声明が正確でない
  • 必要以上の個人データを収集する
  • 意図的でないのか悪意があるかに関わらず、大量の個人データ漏洩を含む、個人データの侵害
  • 個人データが最新かつ正確な状態に維持されるよう対策を取っていない
  • GDPR によるアプリケーション・ユーザーの権利がアプリケーション内で規定されていない。また、管理者としての組織によって直接規定されてもいない
  • アプリケーションまたは個人データが、システム停止、バックアップ復旧、悪意のあるサービス拒否攻撃によって利用不可になる

プライバシー・ソリューションを決定して評価する

次の段階では、リスク登録簿に記録されたプライバシー・リスクのそれぞれを、そのリスクを許容するか、軽減するか、または排除するかを視野に入れて評価します。プライバシー・リスクを軽減するには、ソリューションを考案してアプリケーションの設計に変更を加えるという方法、SDLC プロセスを強化するという方法、または管理者としての組織でリスク軽減のための手順や管理体制を導入するという方法があります。プライバシー・リスクを軽減するためのソリューションを決定して評価する際は、アプリケーション・アーキテクト、技術リーダー、情報セキュリティー責任者、DPO のすべてが関与する必要があります。

このガイダンス・シリーズの第 3 回で、データベース暗号化や仮名化を含め、よく使われているアプリケーション・プライバシー・リスクの軽減ソリューションのいくつかについて説明しています。

DPIA の結果を文書化し、DPO の承認を取る

アプリケーションの設計にリスク軽減のための変更を加えたら、その変更が反映されるよう、リスク登録簿に記録されているプライバシー・リスクを更新し、残っているリスクの採点 (変更後に評価したリスク採点) を記入する必要があります。プライバシー・リスクを軽減するための変更とソリューションのすべてが、アプリケーションの設計とプロジェクト計画に統合されるようにしてください。リスクの軽減措置が公式に開発計画に統合されるよう、DPIA の結果を開発プロジェクトの管理者に報告する必要があります。

完成した DPIA ドキュメントには、以下の事項が含まれていなければなりません。

  • アプリケーションの概要 (アプリケーションの目的と機能を含む)
  • アプリケーションを開発する組織が GDPR に関してどのような責任を持つか (つまり、管理者、処理者、またはそのいずれにも該当しない)
  • 個人データのデータ・フロー図
  • 個人データの技術的詳細 (スプレッドシートなど)
  • GDPR ユーザー・プライバシー権を支援するためのアプリケーション・プロセスについての説明
  • アプリケーションのプライバシー声明のコピー
  • アプリケーション・ユーザーと組織のプライバシー・リスクを記録して完成させたリスク登録簿
  • DPO 承認の声明ページ

DPO は完成した DPIA ドキュメントをレビューして承認する必要があります。DPO が DPIA を承認するには、DPIA が正確に表現されていると見なされること、プライバシー・リスクが許容されると見なされること、アプリケーションおよび組織 (管理者または処理者の役割にある場合) が GDPR に完全に準拠していることが条件となります。これらの条件を満たしていなければ、DPO は問題を引き合いに出し、さらに綿密に評価するよう要求します。

開発プロジェクトのスポンサーには、完了した DPIA のコピーを提出する必要があります。一般に、プロジェクトのスポンサーは開発されたアプリケーションのプライバシー・リスク全体に責任を負うため、スポンサーにも DPIA を承認してもらうことが推奨されます。

開発計画内の DPIA プライバシー・ソリューションを実装する

開発プロジェクトのスポンサーは、完了した DPIA のコピーの提出を受ける必要があります。一般に、プロジェクトのスポンサーは開発されたアプリケーションのプライバシー・リスク全体に責任を負うため、スポンサーにも DPIA を承認してもらうことが推奨されます。

アプリケーションの実装に関するガイダンス

管理者としての外部組織によって再販、ホスト、または使用される予定のアプリケーションの場合、その外部組織が、設計によるデフォルトでのデータ保護に応じてアプリケーションをプロビジョニングできるよう、開発者はアプリケーションの実装に関するガイダンスを作成して提供する必要があります。実装に関するガイダンスには、アプリケーションをインストールしてプライバシー設定を構成する際のステップバイステップの手順を簡潔に記載します。また、アプリケーションのサポート・コンポーネント (Web サーバー、データベース、ネットワーク環境) に推奨されるセキュリティー構成についても記載してください。

管理者としての組織に対し、透明性を高めて GDPR のサポートを強化するために、実装に関するガイダンスでは、プライバシー関連のアプリケーションの機能とプロセスのすべてについて完全に説明する必要があります。さらに、アプリケーションで支援していない GDPR プライバシー権を、管理者としての組織がユーザーに提供する責任を持つことになる場合は、アプリケーションのプライバシー・リスクを軽減する上でその組織が負う責務について詳しく説明してください。この情報は、あらかじめ入手されて DPIA ドキュメントに記載されているはずです。

まとめ

データ保護影響評価の実施を要件として規定している GDPR 第 35 条では、「新たなテクノロジー」は個人のプライバシー権と自由に対する「高リスクを生じさせる可能性がある」としています。データ保護影響評価の実施要件は、EU 市民の個人データを処理することが意図されているあらゆるアプリケーションの開発に適用されると解釈することができます。

最初からユーザーのプライバシー権を保護するアプリケーションを開発するには、ソフトウェア開発サイクルの早期段階で公式の DPIA を完了することが必須となります。開発者は DPIA プロセス全体を通して、データ・プライバシー分野の専門家、情報セキュリティーの専門家、リスク管理の専門家のサポートを求めるようにしてください。このような専門家たちの専門知識を利用することで、開発者はアプリケーション・ユーザーと組織の両方にとってのプライバシー・リスクを公式に識別して評価し、アプリケーションの設計の中でそれらのリスクを軽減するための技術的ソリューションを考案できるようになります。


ダウンロード可能なリソース


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=セキュリティ
ArticleID=1062194
ArticleTitle=GDPR 準拠のアプリケーションを開発する, 第 2 回: アプリケーションのプライバシー仕様
publish-date=08092018