HULFT SquareはSaaSとしてお客様にご利用いただくよう開発を進めています。
お客様がSaaSに求めるものはマネージドです。そして、安心、安全の上で動いていることは必要条件でしょう。
安心、安全は言葉で表すことは難しいですね。しかし、すでに世の中にはいくつもそれを担保するための標準や、法律、規則があります。
本投稿ではGDPR（General Data Protection Regulation｜一般データ保護規則)をターゲットとして、これに対応するサービスはどのような検討が必要になるかを簡潔に記載します。
このあたりをビジネスと開発・運用組織が押さえておけば、サービス開発で大きく外すことはないと思います。やるか、やらないか検討しているソフトウェアチームの一助になれば幸いです。
大きなポイント
- 日本は十分性認定の対象国である（アメリカは違う)
- 個人情報の定義と配置する場所こそが一番大事
- サービスとユーザーの接点は同意、請求、開示
- 管理者（コントローラ）と処理者はあなた次第
それぞれの簡単なポイント
日本は十分性認定の対象国である
ズバリ、日本にあるサーバにGDPRにおける個人情報として指定されるデータを保持してOKです。 USは認定対象外です 。もし、現在のサービスをマルチリージョンで考えるのであれば、ここは十分検討してください。
BCPなどを実現するアーキテクチャを米国リージョン含めて構成している場合は、検討が必要です。（絶対ダメというわけではないです）
個人情報の定義と配置する場所こそが一番大事
GDPR対応の一丁目一番地です、まずサービスにおけるGDPRとしての個人情報の特定、そしてその配置場所の特定が初めに必要です。
最近のサービスはAWSやAzure、もしくはその他のサービスの上や横連携を前提にアーキテクチャが検討されるでしょう。いわゆる巨人の肩に乗って、遠くへ早く進む戦略です。これはコア、ノンコアのフォーカス戦略からも非常に重要です。
ただ、GDPRはこれでハマる部分可能性があります。 GDPR対応のSaaSアプリケーションを作る場合は連携対象SaaSがGDPR基準に対応しているものを選んでください 。そうでないと、その１つのサービスのおかげで、次の「開示」で詰みます。 なお、HULFT SquareはGDPR準拠を予定しています
サービスとユーザーの接点は同意、請求、開示
GDPRはユーザーを保護するものです。エンジニアがシステムを作って終わりではありません。
まず、最初に「同意」のイベントを軽やかに超える必要があります。細やかなルールは多少ありますが、まずは、同意を記録する、そして同意を取り消せること。これを実現可能としてください。
「請求」はオンラインであることが必要です。（必須ではないが、とある約束事に触れる可能性があります）
「開示」はシステムと組織両方のシナジーが問われる部分です。また、次で触れるコントローラの決定方法により、要件を重くも軽くもできます。
管理者（コントローラ）と処理者はあなた次第
SaaSの種類によりコントローラは利用ユーザー自身になります。何を言っているんだというと、BtoB SaaSの場合は実際の利用者は企業の社員です。つまり、SaaSの利用企業はそのSaaSを社員に使わせているから管理者なのです。GDPRとして管理者の役割はいくつかあります。
これを契約の中で定義することで、いくつかの非常に繊細なテーマを委譲することができます。
最後に
GDPR対応アプリケーションは費用と時間と有識者と運用する真摯な組織があれば対応できます。そして、GDPRに対応していれば、グローバルなプロダクトを目指せます。対応していなければ無理でしょう。
最後にGDPR対応サービスはそんなに難しくありません。これができればCCPA対応もほぼほぼできたようなものです。
まず、以下のような全体がわかる本をサラッと全部読んでいただければ、やってみようと思えるはずです。
GDPRは恐るに足らずです。
図解入門ビジネス最新GDPRの仕組みと対策がよーくわかる本
概説GDPR
欧州GDPR全解明
がんばりましょう