この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
2018年5月25日より、EU一般データ保護規則（General Data Protection Reguration: GDPR）が欧州で適用されます。欧州議会が以前に制定し各国で法制化が進んでいるデータ保護指令（Directive 95/46/EC）を置き換える統合的な規則で、従前と比べて厳しい罰則、対応する国内法を採決する必要がない、EU外へのビジネス上の影響が大きい、など、EUの単一デジタル市場戦略のマイルストーンとなるイベントです。（単一デジタル市場についてはこちら）
一言にデータ保護と言ってもカバー範囲によって目的と手段が分化されます。
- 個人情報の保護に関するもの
- データの保存、保護、監査に関するもの
- 商習慣や各国の政策に基づいて適者生存に結びつくもの
特にリーガル部門をもつ大手コンサルティング会社によって上記を峻別せずにGDPR対応をうたった恐怖マーケティングが盛んに展開されていますが、多くの場合、データプラットフォームの認証とシステムの監査可能性、可搬性の強化・整備が作業として必要となるため、コンサルティングを受けたからといってGDPRへの対応が万全になるということはありません。また、従前のデータ保護指令や各国の法規対応を進めていた会社にとって、GDPR適用にあたってやることはそれほど多くありません。
むしろこれをきっかけとしてプラットフォームの高度化を進め、GDPRに限らずデータ保護に関する経営上のリスクを下げる取り組みが重要です。そしてあえて結論から書くとこうなります。
データ保護への取り組みはAWSなどのクラウドプラットフォームを中核にして行うことで、コスト負担を将来にわたってやわらげ、コンプライアンスを維持した柔軟な拡張ができるようになる。
取引先や関連会社とのデータ取引に関する契約ドキュメントを作成したりデータマッピングを実施したりと施行前にやらなければならないことは多々ありますが、ことの本質は施行以降のデータオペレーションの品質向上にあり、5月25日の期限に追われて「とりあえず顧問弁護士に言われた書類は作りました」では早々に破綻します。経営者とデータの利用者が理解を深め、主体的に仕組みづくりと運用をすることが肝心です。
カバー範囲からプラクティスをなぞる
上記の３つのカバー範囲のうち下の二つはGDPR対応のために新たに施す対象ではなく、欧州で活動する企業が当然実施しておかなければならないものです。
- データの保存、保護、監査に関するもの
データ保存期間は各国でばらつきがありますが、手法や原則は一致しています。ドイツでは会計文書が10年間、その他のビジネス文書が6年間、トランザクションが改変できない様式で保存する必要があります。欧州各国の法規とのバランスを取るため、ビジネス文書についても8〜10年の保存期間を取るのがコモンプラクティスとされています。ビジネス文書はemailも含まれるため、ジャーナリングやアーカイブの実装が必須になります。
「トランザクションが改変できない様式」とは、究極的には全てを紙にプリントアウトしてファイリングし、鍵で管理されている倉庫に保存することになり、実際にそれをやっている企業もあります。古くはSAP R/3の伝票とExchange - Outlookのアーカイブを行う IXOS Software (現 OpenText)がデファクトになりこういった文書ライフサイクル管理を行ってきましたが、現在はもっと多くの選択肢が市場に提供されています。
GDPRの監査可能性要件を達成するには、少なくとも現行法規へのシステム対応を完璧にしておく必要があります。
- 商習慣や各国の政策に基づいて適者生存に結びつくもの
これは「ドイツで商売をする企業のデータはドイツ国内に保存しなければならない」という伝説に通じるところですが、ドイツの自動車業界や政府調達など、強い購買力をもつ組織が作り上げたプラクティスです。
アメリカの愛国法に類似したイギリスのRIPAの存在によって、データの機密性を重視する大陸ヨーロッパの企業は、「データはできればドイツに、少なくとも大陸かアイルランドに」という方針を近年固めています。AWSのロンドンリージョンの開設が遅かったことと未だにダブリン、フランクフルトの規模に遠く及ばないのはここに起因しています。またマイクロソフトはこの商習慣に合わせるため、Office 365をT-Systemsのフランクフルト、ベルリンのデータセンターに限定したOffice 365 Germanyというサービスを展開しています。
クラウド環境の商慣習で決定的になりつつあるのがドイツ連邦電子情報保安局 (BSI)が定めたC5です。ドイツの政府調達ではこれに準拠している前提が必要になります。フランスの国家情報システムセキュリティ庁(ANSSI)も類似制度であるSecNumCloudを作り、ESCloudというレーベルで相互運用を目指して作業中で、今後1、2年で欧州のスタンダードになると見込まれます。AWSはC5の認定第一号で、Microsoft Azure Germanyも最近認定を受けています。
C5準拠が重要なのは、GDPRの要件になる仮名化、暗号化と鍵の保安がデータプラットフォームとして確保されているからです。
以上のように、GDPR対応の前提となるプラクティスは長いものに巻かれる戦略が妥当で、この領域で具体性のない空中戦コンサルティングや議論検討は意味がありません。
個人情報保護を川下から理解する
GDPRはトップダウンの要件で構成されていて、企業が準拠するための作業項目が契約雛形などのドキュメンテーションをのぞいて示されていません。そのため様々な解釈が飛び交い、エンドレスな不安とコスト負担を強いられる事態に陥りかねません。
川下からGDPRの理念を理解し具体的な行動に移すならば、欧州在住者から組織で管理しているその人の個人情報の所在、取得目的、共有先、どうプロセスされたかの開示、そして削除を求められた時、適時的確に対応できるか、また取得時に明瞭な合意を取っているか につきます。なんでもいいから個人情報を集めてそれをセールスやマーケティングに利用できた牧歌的な時代が欧州で終焉し、個人情報を所持すること、利用することが組織のリスクになるということです。
欧州に恒久施設(PE)があるかどうかでその行動は変わりますが、取得した個人情報の最初のデータストアは欧州内に確定し、利用目的に沿ってその後の流通を計画、管理します。そして欧州外へのデータ移転を取得時の合意を前提として、SCC(Standard Contractual Clauses: 標準契約条項)、ないしはBCR(Binding Corporate Rules: 拘束的企業準則)で保全します。
文書化はこの他に個人情報のデータマッピングがあり、取得する個人情報の処理目的、種類、量、共有・移転先を全て洗い出します。
このうえで上記の行動を実践するには、データの適切なトラッキングと監査が業務に組み込まれる必要があります。データストアのクラウドプラットフォームへの集約と監査ツールがそれを助けます。クラスメソッドヨーロッパではAmazon Macieが欧州リージョンやS3以外のデータストレージにも拡張されることを見越して検証を進めています。
このように、川下から考えるとやらなければならないことのイメージが掴みやすくなります。個人情報の扱いについて厳密で即応性のある内部統制が取れるかがポイントで、文書化や契約はあくまで手段です。
クラスメソッドヨーロッパの実践例
クラスメソッドヨーロッパは、ベルリンにPEがあります。私どものGDPR対応の手の内を明かすことで、似た状況の在欧日系企業の参考になればと思います。コンシューマー向けに広く個人情報を取得する業務をしているわけではないのでもともとセンシティブな個人情報の量は多くなく、ドイツのBSI規則への対応を行なっていた経緯から作業量は少なめです。
ベルリンオフィスが取得、保持、処理、かつ域外のクラスメソッドグループと共有する欧州在住者の個人情報は大きく二つ、従業員の個人情報と、クラスメソッド・メンバーズ（AWS利用顧客）の24時間保守のための顧客担当者の情報です。
Microsoft SharePointによる文書管理
従業員の個人情報は雇用契約時に合意書を結んで取得している基本情報と、ペイロールなどの随時情報があります。いずれも従前からSharePointで権限設定したドキュメントエリアに格納し、必要な情報は日本の管理部門に移転しています。
更新が発生する随時情報はアウトソーサーからの受け取りと個人のドキュメントエリアへの転送、査定用途で日本への移転とワークフローがあるため、権限の制御とデータの所在、消去を確実にするため、Microsoft Flowを使って定義、実行しています。
ペイロールプロセッサからの給与情報の受け取りは限定公開したOneDriveフォルダで行い、SharePointのHR限定領域へ属性ごとコピーして原本を削除します。そのイベントをデータ管理者と従業員個人へ通知するまでのワークフローが上記に定義されています。この後、個々のペイロールの配布と駐在員分のデータの移転が続きます。
アプリケーションをまたいだ情報の制御はこのようなワークフローツールによるトラッキングが有用です。
AWSによる取得データの所在の明確化
顧客担当者情報の取得と管理に関しては、GDPRのために改変が必要でした。
プリセールス段階からイベント等のマーケティング活動やパイプライン管理で日本本社とSFDCを共有しており、そのプラットフォームに乗っている情報取得ツールのPardotフォームはデータの所在と、情報を共有した際の確実なトラッキングに問題があります。また、AWSのパートナーとしてベルリンのAWS社とパイプライン情報をやり取りする際の仮名化が不十分です。
プリセールスのSFAは日本と完全に分離し、DPA(Data Processing Agreement)を早くから開示しているHubSpotに移行してオンライン、オフラインで取得する個人情報のデータの所在を一本化しました。
ポストセールス段階で保守情報をグループ会社でやり取りするケースでは、新規取得のためのPardotフォームを廃止し、新たにフランクフルトリージョンのAWS S3に格納する各種Webフォームを構築しました。既存の情報やプリセールスからデータを引き継ぐ場合も一度S3バケットに集約します。その上でクラスメソッドグループ間のSCCを結び、域外移転を可能にしています。
魔法の杖を探すより、当事者意識を持った取り組みを
昨年中頃から、規模が小さい在欧の日系駐在員事務所ではGDPRのビジネスインパクトがいまいち日本の本社に理解されず、対応が遅々として進まないという悩みをよく耳にしました。そして施行が迫った今年になって、いったいどうしたらいいのか、と対応方法を検索してこのブログポストにたどり着いた担当者の方も多いかと思います。
まず今から慌ててどこかにお金を払って「GDPR対策」を頼んでも、5月25日には間に合いません。GDPR対応はオペレーションフェーズで実施される内部統制なので、書類が期限に間に合うかどうかよりも組織としてその品質を上げるための当事者意識が重要です。また、欧州にPEを持たないが欧州在住者を対象にビジネスをするアプリ提供者などの会社、広くいうとWebの問い合わせフォームに名前とメールアドレスが必要な場合などもGDPRの当事者になります。欧州代理人の選出、場合によってはDPO(Data Protection Officer)の任命が必要です。
GDPRの基礎的な情報および最新ニュースの取得は重要で、JETROがかなり前からガイドブックを含む情報を発信しています。また、豊富な具体例が日々アップデートされているIIJビジネスリスクマネージメントポータルがよくまとまっています。同社は自社のBCRの申請を2016年の段階で行なっているため、SCCを超えてBCR認定が必要な大規模で自由度の高いデータプロセスを行う企業にとっては申請の先行事例として参考できます。
GDPRのアセスメントツールはソフトウェアベンダーやコンサルティング会社が提供していますが、無償で使えるMicrosoftのツールは生成されるレポートが詳しく、組織の規模や取り扱うデータを峻別して初期段階の作業の優先度が明確になります。
繰り返しになりますが、個人情報をリスクと認識し無闇な収集をやめ、収集したデータオペレーションの品質向上、および規則に沿った拡張を行うには、プラットフォームの妥当な選択と集約、洗練を主体的に進めることが具体的な行動となります。AWSを選択した場合、AWSがどういう立ち位置にいて何をしてくれるかはこちらにまとまっていて詳細情報もたどれます。またGDPRに限らずC5などのアカウント個別の文書はArtifactから生成、取得可能です。
2
