「個人情報保護法に準拠します」——開発会社の提案書にこの一文だけが書かれていたら、発注者として何を確認すればよいでしょうか。経営層からは「違反しないようにしてほしい」と漠然と指示され、要件定義 MTG では「個人情報の扱いは弊社の方針通りで大丈夫です」と返される。この状態のまま開発が進むと、漏えい事故が起きた瞬間に責任を問われるのは委託先（開発会社）ではなく、委託元（発注者）であるあなたの会社です。
個人情報保護法が定める委託先監督義務は、開発会社に丸投げすることを許しません。発注者は仕様書のどこに何を書き、契約書のどの条項を握り、漏えい時に誰がいつまでに何をするのかを、自社の責任として言語化しておく必要があります。とはいえ、法律の条文を読み込んで自社のシステムに翻訳する作業は、専任法務がいない中堅企業にとって現実的ではありません。
本記事では、開発会社との次回 MTG で具体的に指示できるレベルまで論点を分解します。仕様書に明記すべき技術要件 7 項目、契約書に盛り込むべき条項 6 項目、漏えい時のタイムライン、GDPR 対応で追記すべき項目を、発注者の意思決定軸で順に整理します。読了後には、経営層への説明資料としてそのまま使える「責任構造の地図」が手元に残るはずです。
なお、本記事は法的助言ではありません。個別の事案については弁護士・個人情報保護委員会への確認を推奨します。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
個人情報を扱うシステム開発で発注者が抱える本当のリスク
個人情報を扱うシステムの開発を外注したとき、発注者と開発会社のどちらが責任を負うのか——この問いに即答できない状態でプロジェクトが進んでいるなら、リスクの所在を見落としている可能性が高いです。
なぜ漏えい時の責任は発注者に来るのか
個人情報保護法第 25 条は、個人データの取扱いを委託する事業者（委託元）に対し、「委託を受けた者に対する必要かつ適切な監督」を義務づけています。つまり開発会社に外注したからといって責任が移るわけではなく、委託元である発注者が一次的な責任主体として残り続けます（個人情報保護委員会ガイドライン（通則編）参照）。
漏えい事故が報道されるとき、ニュースの見出しに載るのはほぼ例外なく委託元企業の名前です。行政指導の対象、損害賠償請求の名宛人、株価下落のインパクトを直接受けるのも委託元です。開発会社が個別に責任を負うのは、契約上の損害賠償と再委託先への監督義務の範囲にとどまります。
「仕様化していなかった」ことが問われる典型パターン
過去の漏えい事案では、発注者が以下を仕様書・契約書で握っていなかったことが行政指導や訴訟で論点化することがあります。
- 委託先・再委託先（孫請け）の従業員が個人情報にアクセスできる範囲を限定していなかった
- 開発・テスト環境で本番の個人情報を使用することを禁止していなかった
- 漏えい発覚時に開発会社から発注者へ第一報を入れる時間（SLA）を契約に書いていなかった
- 契約終了時のデータ消去・証明書発行を求めていなかった
「言わなかった発注者が悪い」と片付けられるわけではないものの、「監督義務を果たしたか」を問われる場面で、仕様書・契約書という客観的な証跡がなければ抗弁が難しくなります。
本記事の射程と関連記事との読み分け
外注プロセス全体のチェックリストや、発注前から契約後までを俯瞰した網羅情報を確認したい場合は、個人情報保護法対応のシステム開発チェックリストを併せてご覧ください。本記事は射程を絞り、「仕様書・契約書のどこに何と書くか」という実装ガイドに特化します。次の章から、改正法の押さえどころ、仕様書の技術要件、契約書条項、プライバシーバイデザイン、GDPR、インシデント対応の順で解説します。
2022年改正個人情報保護法でシステム開発の発注者が押さえる4つのポイント
2022 年 4 月施行の改正個人情報保護法は、発注者にとって「仕様書・契約書を書き直す契機」となる内容を多数含んでいます。網羅的に把握する必要はなく、発注時の意思決定に関わる 4 点だけを押さえれば実務に十分です。
委託先監督義務——「契約・確認・是正」の3ステップ
委託先監督義務（法第 25 条）は条文自体に大きな変更はないものの、ガイドラインの運用が厳格化しています。求められるのは以下の 3 ステップです。
- 契約: 安全管理措置を委託先に守らせる条項を契約書に明記する
- 確認: 委託先が契約通りに運用しているかを定期的に確認する（年 1 回以上の点検が推奨）
- 是正: 不備があれば是正させ、改善されない場合は委託契約の見直しを検討する
発注者として今すぐ仕様書・契約書に反映すべきは、「定期点検を受け入れる旨の条項」と「是正要求への応諾義務」です。
漏えい等報告義務——速報3〜5日／確報30日（不正目的は60日）
2022 年改正で最も実務インパクトが大きいのが、漏えい等報告と本人通知の義務化です。
- 速報: 漏えい等の発生を発覚した日から「速やかに」（概ね 3〜5 日以内）に個人情報保護委員会へ報告
- 確報: 発覚日から 30 日以内に詳細を確報。ただし不正の目的による漏えい（サイバー攻撃等）は 60 日以内
- 本人通知: 本人への通知も原則として速やかに実施
報告対象は「個人の権利利益を害するおそれが大きいもの」で、要配慮個人情報の漏えい・財産的被害が生じるおそれ・不正目的による場合は 1 人の漏えいでも対象、それ以外は 1,000 人を超える漏えいまたはそのおそれで対象となります（漏えい等報告・本人への通知の義務化について｜個人情報保護委員会）。なお 2024 年 4 月施行の改正施行規則により、Web スキミング等への対応として報告対象がさらに拡大されています。
発注者として仕様書・契約書に反映すべきは、開発会社からの第一報経路と時間（後述）、本人通知用テンプレートの平時準備、検知の仕組み（ログ監視・アラート）です。
不適正利用の禁止——AI・データ分析時に発注者が確認すべきこと
2022 年改正で「不適正利用の禁止」（法第 19 条）が新設されました。違法または不当な行為を助長・誘発するおそれがある方法による個人情報の利用を禁じる条項です。AI による属性推定、与信スコアリング、ターゲティング広告などで個人情報を利用する場合、発注者は以下を確認しておくべきです。
- どのデータをどの目的で利用するか、利用目的をプライバシーポリシーで具体化しているか
- 推定・スコアリングの結果が本人に不利益を与える場合、本人が訂正・削除を請求できる導線を設計に含めているか
仮名加工情報——設計選択肢として知っておくべき位置付け
2022 年改正で創設された仮名加工情報は、他の情報と照合しない限り特定の個人を識別できないように加工した情報です。社内分析・機械学習の学習データとして使う場合、本人同意の取得負担を軽減できる選択肢になります。発注者が「仮名加工情報として扱える設計にしてほしい」と仕様化することで、後の利活用フェーズでの自由度が広がります。
個人情報を扱うシステムの仕様書に明記すべき7つの技術的要件
「個人情報保護法に準拠します」と書かれた提案書を、発注者の責任で具体化する作業がこのセクションです。安全管理措置のうち技術的安全管理措置を 7 項目に分解し、それぞれ仕様書への記載例を示します。技術的セキュリティ要件のより詳細なフォーマット例はセキュリティ要件の書き方ガイドも併せて参照してください。
1. アクセス権限管理——最小権限の原則と棚卸サイクル
仕様書記載例 |
|---|
個人情報を含むテーブル・ファイルへのアクセスは、業務上必要な役割に応じた最小権限で付与する。権限の付与・変更・剥奪は申請・承認のワークフローを経る。アクセス権限は半年に 1 回棚卸を実施し、不要となった権限を削除する |
「管理者・一般」のような大雑把な分類ではなく、業務役割ごとに参照可能なデータ範囲を細分化することが重要です。
2. 通信経路の暗号化——「暗号化します」を仕様としてどう書くか
仕様書記載例 |
|---|
個人情報を扱う全ての通信経路（クライアント・サーバ間、サーバ・データベース間、サーバ・外部 API 間）を TLS 1.2 以上で暗号化する。HTTP 通信は HTTPS にリダイレクトし、HSTS を有効化する |
バージョン指定（TLS 1.2 以上）まで仕様書に書くことで、開発会社が古いプロトコルで実装するリスクを排除できます。
3. 保存データの暗号化——本番DB・バックアップ・ログの全てを対象に
仕様書記載例 |
|---|
個人情報を含むデータベース・バックアップ・ログファイルは、保存時に暗号化する（AES-256 相当以上）。暗号鍵はデータベースとは別の場所で管理し、鍵のローテーションを年 1 回以上実施する |
「保存データを暗号化します」だけでは、ログファイルやバックアップが対象から漏れることがあります。対象範囲を網羅的に列挙することが重要です。
4. 操作ログ・監査ログの取得・保管期間
仕様書記載例 |
|---|
個人情報の参照・更新・削除・エクスポート操作について、ユーザー ID・操作日時・対象レコード・操作種別をログとして記録する。ログは改ざん防止策を講じた上で 1 年以上保管する |
「誰が・いつ・何を見たか」を後から追跡できる設計でなければ、漏えい発覚後の調査で原因特定ができません。エクスポート操作（CSV ダウンロード等）の記録は特に重要です。
5. 認証強度——多要素認証の要否を業務リスクから判断する
仕様書記載例 |
|---|
管理者権限を持つユーザーのログイン、本番環境への管理アクセス、個人情報のエクスポート操作には多要素認証（MFA）を必須とする。一般利用者についてはパスワード強度ポリシー（12 文字以上、英数字記号混在）を強制する |
「全員に MFA」を求めるとユーザー体験が損なわれることがあるため、リスクの高い操作に絞って必須化する設計が現実的です。
6. バックアップと完全性確認
仕様書記載例 |
|---|
個人情報を含むデータベースは日次でバックアップを取得し、3 世代以上保管する。バックアップから定期的（四半期に 1 回）にリストアテストを実施し、完全性を確認する |
バックアップが取れていてもリストアできなければ意味がありません。テスト頻度を仕様化することで運用フェーズでの形骸化を防げます。
7. 開発・テスト環境での本番個人情報の取扱い禁止
仕様書記載例 |
|---|
開発・ステージング・テスト環境において、本番環境の個人情報をそのまま使用することを禁止する。テストデータは個人を識別できないようマスキングまたは仮名化したデータを使用する |
実装現場でハマりやすいのが、本番データをそのまま開発環境にコピーして使ってしまうケースです。仕様書で明示的に禁止しておかないと、開発効率を優先して運用上のルールが破られることがあります。
委託契約書に盛り込むべき6つの個人情報保護条項
仕様書で技術要件を握ったら、次は契約書です。個人情報保護法第 25 条の委託先監督義務を満たすために、契約書に明記すべき条項を 6 つに整理します。契約書全般のチェック観点はシステム開発の契約書チェックポイント10選、損害賠償の上限・下限の交渉観点はシステム開発の損害賠償・リスク管理ガイドも参照してください。
1. 利用目的の限定と「目的外利用の禁止」
最低限の文言例 |
|---|
受託者は、本契約に基づき委託された個人情報を、本契約の業務遂行の目的以外に利用してはならない |
発注者として有利に握る追加文言例 |
|---|
受託者は、本契約に基づき取得・受領した個人情報を、自社のサービス改善・統計分析・AI モデル学習等の目的にも利用してはならない。利用目的を変更する場合は、事前に委託者の書面による同意を得る |
開発会社が「サービス改善のため匿名化して利用する」と提案してくるケースがあります。匿名化の定義は曖昧になりやすいため、目的外利用の範囲を契約段階で明確化しておくのが安全です。
2. 安全管理措置の遵守義務
最低限の文言例 |
|---|
受託者は、個人情報保護法および関連ガイドラインに定める安全管理措置を講じる |
発注者として有利に握る追加文言例 |
|---|
受託者は、別紙に定める安全管理措置（組織的・人的・物理的・技術的）を講じ、委託者の求めに応じて遵守状況を文書で報告する。委託者は年 1 回以上、受託者の作業場所に対して監査を実施できる |
「ガイドラインに従う」だけでは抽象的すぎるため、別紙でチェックリスト化し、監査権を契約に書き込むことが推奨されます。
3. 従業者への監督義務
最低限の文言例 |
|---|
受託者は、個人情報を取り扱う従業者に対して、必要かつ適切な監督を行う |
発注者として有利に握る追加文言例 |
|---|
受託者は、個人情報を取り扱う従業者から秘密保持誓約書を取得し、入社時および年 1 回の教育を実施する。委託者は教育の実施記録を確認できる |
4. 再委託の制限——孫請け先の管理をどう握るか
最低限の文言例 |
|---|
受託者は、本契約に基づく業務の全部または一部を第三者に再委託する場合、事前に委託者の書面による承諾を得なければならない |
発注者として有利に握る追加文言例 |
|---|
受託者は、再委託先に対して本契約と同等以上の義務を課す契約を締結し、再委託先の遵守状況について受託者が責任を負う。委託者は再委託先の名称・所在地・業務範囲を事前に把握できる |
開発会社がフリーランスエンジニアを使う、海外オフショア開発を活用するといったケースで、孫請けの個人情報取扱いが問題化することがあります。事前承諾と一覧把握を契約で握っておくことが重要です。
5. 漏えい時の報告体制と報告期限
最低限の文言例 |
|---|
受託者は、個人情報の漏えい・滅失・毀損またはそのおそれを認識した場合、速やかに委託者に報告する |
発注者として有利に握る追加文言例 |
|---|
受託者は、個人情報の漏えい等またはそのおそれを認識した場合、24 時間以内に委託者の指定する連絡先（電話・メール）に第一報を入れる。72 時間以内に発生事象・規模・原因の暫定見立てを文書で報告し、その後の調査結果を 7 日以内に詳細報告する |
「速やかに」では時間軸が曖昧で、発注者側が個人情報保護委員会への速報期限（3〜5 日）に間に合わなくなるリスクがあります。時間単位で SLA を握ることが必須です。
6. 契約終了時のデータ返却・消去・証明書発行
最低限の文言例 |
|---|
受託者は、本契約終了時に委託者から預かった個人情報および複製物を返却または消去する |
発注者として有利に握る追加文言例 |
|---|
受託者は、本契約終了から 30 日以内に、委託者から預かった個人情報および複製物（バックアップ・ログを含む）を消去し、消去完了の証明書を委託者に交付する。証明書には消去対象・消去日時・消去方法を記載する |
「返却または消去」を曖昧に書くと、開発会社の社内に残ったままになるリスクがあります。証明書まで仕様化することで、契約終了後の責任を切り分けられます。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
プライバシーバイデザインを仕様書に反映する実務手順
プライバシーバイデザイン（PbD）はカナダの Ann Cavoukian 博士が 1990 年代に提唱した概念で、JIPDEC が日本での普及を担っています。「事前的・予防的」「初期設定としてのプライバシー」「デザインに組み込まれるプライバシー」など 7 つの基本原則がありますが（プライバシー・バイ・デザイン｜JIPDEC）、原則そのものを開発会社に説明しても実装には繋がりません。
ここでは原則を発注者が要件定義 MTG で確認するチェック項目に翻訳し、6 点に絞って解説します。
1. 取得項目の最小化——「念のため取得」を排除する
要件定義の現場でよくあるのは「将来使うかもしれないから生年月日を取得しておこう」という発想です。利用目的が明確でない情報は取得しないことが PbD の原則です。要件定義 MTG で各取得項目について「何の業務で必要か」を 1 行で書き出させ、書けない項目は仕様から外すことを推奨します。
2. 利用目的の明示と画面UIへの反映
プライバシーポリシーに記載する利用目的と、システムの画面 UI で表示される目的説明文が一致していなければ意味がありません。会員登録画面・問い合わせフォーム・アンケート画面それぞれに「取得した情報の利用目的」を表示する仕様を要件として明記してください。
3. 同意取得UI——プライバシーポリシーとの一致を画面レベルで担保
仕様書記載例 |
|---|
会員登録画面においては、プライバシーポリシーへのリンクとチェックボックスを設置し、チェックなしでは登録ボタンを押下不可とする。マーケティング利用同意は会員登録同意とは別チェックボックスとして分離する |
オプトイン（明示的に同意を取る）とオプトアウト（同意しない選択肢を提供する）の使い分けは、利用目的の性質によって決まります。マーケティング利用は原則オプトインで設計するのが安全です。
4. 保有期間の定義と自動削除
仕様書記載例 |
|---|
個人情報の種別ごとに保有期間を定義し、保有期間を経過したデータを自動削除するバッチを実装する。退会会員の個人情報は退会から 30 日後に削除する。問合せフォームのデータは 1 年経過後に削除する |
保有期間を運用任せにすると、削除が形骸化して何年も残り続けます。削除の自動化を仕様書段階で要件化することが重要です。
5. 開示・訂正・削除請求への対応API/画面
個人情報保護法は本人による開示・訂正・利用停止・削除請求への対応を義務づけています。受付窓口（メールアドレス、専用フォーム等）と、社内の対応フロー（誰が受領し、誰が判断し、誰が回答するか）を仕様書に書き込んでください。請求件数が多くなる見込みのシステムでは、本人がマイページから直接ダウンロード・削除できる API を実装する選択肢もあります。
6. プライバシーポリシーとシステム実装の整合性確認
ローンチ前にプライバシーポリシーの記載内容とシステム実装が一致しているかを照合する作業を、仕様書のテストフェーズに含めてください。「同意取得画面の文言」「取得項目」「利用目的」「第三者提供の有無」「保有期間」が、プライバシーポリシーの記載と一致しているかを 1 項目ずつ確認します。
GDPR・越境データ移転で発注者が仕様書に追記すべき項目
本節は EU ユーザーの個人データを取り扱う場合に参照してください。日本国内のユーザーのみを対象とするシステムでは原則スキップ可能ですが、グローバル展開の可能性がある場合は最低限の判断軸を持っておくと、後の追加開発を回避できます。
自社のシステムがGDPRの適用対象か判定する3つの問い
GDPR は以下のいずれかに該当する場合、日本企業にも適用されます。
- EU 域内に拠点を持つか: 子会社・支店・営業所が EU 内にあれば対象
- EU 域内の個人にモノ・サービスを提供しているか: EU からの注文を受け付ける、EU の言語・通貨で表示する Web サイトを運営する場合は対象になりうる
- EU 域内の個人の行動を監視しているか: EU ユーザーの Web 上の行動を追跡・分析している場合は対象
このいずれにも該当しなければ、本節はスキップして構いません。
日EU間の十分性認定と補完的ルール
日本は 2019 年 1 月 23 日付で欧州委員会から GDPR 第 45 条に基づく十分性認定を受けており、EU 域内から日本への個人データ越境移転は原則として SCC（標準契約条項）等の追加措置なしに可能となっています。ただし、十分性認定によって移転を受けた個人データには「補完的ルール」が適用されます（日EU間・日英間のデータ越境移転について｜個人情報保護委員会）。
発注者として確認すべきは以下の点です。
- EU から移転を受けた個人データに「性生活」「性的指向」「労働組合」に関する情報が含まれる場合、要配慮個人情報と同様に取り扱う仕様にする
- EU から移転を受けたデータを第三国（EU・英国・日本以外）の事業者に提供する場合、原則として本人の同意が必要
GDPR 全般の概要はジェトロのGDPR解説ページも参照してください。
クラウド選定時のリージョン指定を仕様書に書く
クラウドサービス（AWS、GCP、Azure 等）を利用する場合、データセンターのリージョンを発注者として指定することが、越境移転リスクの最も実装しやすいコントロール手段です。
仕様書記載例 |
|---|
個人情報を保存するデータベース・ストレージのリージョンは、東京（ap-northeast-1 等）に固定する。バックアップ先のリージョンも国内に限定する。EU ユーザーのデータを取り扱う場合は、フランクフルト（eu-central-1）等の EU 域内リージョンに保存し、EU 域外への移転を行わない |
開発会社が「グローバルレプリケーション」を提案してきた場合、レプリケーション先の国を確認することが必須です。米国西海岸への自動レプリケーションは GDPR 違反になりうるため、リージョン固定を仕様書段階で握ることが重要です。
漏えい発生時の報告義務とインシデント対応フローを仕様化する
「漏えいが起きたらどうするか」を契約締結後に詰めるのでは遅いです。仕様書・契約書の段階で、検知から報告までのタイムラインを設計しておくことが、有事の対応速度を決めます。
開発会社からの第一報——時間単位でSLAを握る
個人情報保護委員会への速報期限は 3〜5 日です。開発会社が漏えいを検知してから発注者に連絡するまでに 2〜3 日かかると、発注者側の対応時間がほぼ残りません。
仕様書記載例 |
|---|
受託者は、個人情報の漏えい等またはそのおそれを認識した場合、24 時間以内に委託者の指定する連絡先（電話・メール）に第一報を入れる。第一報には、認識日時・事象の概要・影響範囲の暫定見立てを含める |
24 時間以内の第一報を SLA として書き込むことで、発注者側に報告期限内の意思決定時間を確保できます。
個人情報保護委員会への報告——速報3〜5日・確報30日の数字をチームで共有
報告区分 | 期限 | 内容 |
|---|---|---|
速報 | 発覚から 3〜5 日以内 | 概要・対象人数の見立て・原因の暫定見立て |
確報 | 発覚から 30 日以内（不正目的は 60 日以内） | 確定情報・原因・再発防止策・本人通知の状況 |
本人通知 | 速やかに | 漏えいした内容・問合せ窓口・想定される影響 |
出典: 漏えい等報告・本人への通知の義務化について｜個人情報保護委員会
これらの数字は経営層への報告・社内共有資料に必ず含めてください。「速報 3〜5 日／確報 30 日／不正目的 60 日」を即答できる状態が、発注者として最低限の準備です。
本人通知の文面準備——平時にテンプレを用意しておく
漏えいが起きてから本人通知の文面を作り始めると、初動が遅れます。平時に以下の項目を含むテンプレートを準備し、法務・広報レビュー済みの状態にしておくことが推奨されます。
- 漏えい等が発生した旨と発覚日
- 漏えいした個人情報の項目（メールアドレスのみ／氏名・住所・電話番号等）
- 漏えいの原因
- 想定される二次被害と注意事項（パスワード変更の推奨等）
- 問合せ窓口（メール・電話）
- 再発防止策
発注者と開発会社の役割分担表
仕様書または契約書の別紙として、漏えい発生時の役割分担を明示しておくと、有事の混乱を防げます。
フェーズ | 発注者の役割 | 開発会社の役割 |
|---|---|---|
検知 | 監視アラートの一次受信・トリアージ判断 | ログ・アラートの実装と運用 |
第一報 | 経営層・法務への内部報告、判断 | 24 時間以内に発注者へ事象報告 |
原因調査 | 調査の指示・進捗管理 | 技術的原因の特定・証跡保全 |
速報（3〜5 日） | 個人情報保護委員会への速報送信 | 速報用情報の提供 |
本人通知 | 通知文面の最終承認・配信実施 | システムからの通知配信支援 |
確報（30 日） | 確報の作成・送信 | 詳細調査結果・再発防止策の提供 |
再発防止 | 再発防止策の意思決定・予算化 | 技術的対策の設計・実装 |
漏えい時の損害賠償・契約条項の交渉観点についてはシステム開発の損害賠償・リスク管理ガイドも参照してください。
まとめ——発注者が次のMTGで開発会社に伝えるべき7つの確認項目
ここまでの内容を、次回の要件定義 MTG で開発会社に確認・依頼する 7 項目として圧縮します。読了直後にこのリストを片手に MTG に臨めば、「うちは大丈夫です」という曖昧な回答を具体的な仕様化に進めることができます。
# | 確認・依頼項目 | 本記事の参照セクション |
|---|---|---|
1 | 仕様書にアクセス権限管理・暗号化・ログ・MFA・本番データ取扱い禁止の 7 項目を明記してください | 個人情報を扱うシステムの仕様書に明記すべき7つの技術的要件 |
2 | 委託契約書に再委託の事前承諾・漏えい時 24 時間以内の第一報・契約終了時の消去証明書発行を盛り込んでください | 委託契約書に盛り込むべき6つの個人情報保護条項 |
3 | 取得項目の最小化と保有期間の自動削除バッチを実装してください | プライバシーバイデザインを仕様書に反映する実務手順 |
4 | プライバシーポリシーと同意取得 UI・画面表示の整合性確認をテスト工程に含めてください | プライバシーバイデザインを仕様書に反映する実務手順 |
5 | クラウドのデータ保存リージョンを国内（または対象地域）に固定してください | GDPR・越境データ移転で発注者が仕様書に追記すべき項目 |
6 | 漏えい発生時の役割分担表を契約書の別紙として作成してください | 漏えい発生時の報告義務とインシデント対応フローを仕様化する |
7 | 漏えい時の本人通知テンプレートを平時に準備し、法務レビュー済みにしてください | 漏えい発生時の報告義務とインシデント対応フローを仕様化する |
経営層に「個人情報保護法対応はどうなっているか」と問われたら、この 7 項目をベースに「仕様書・契約書のここにこう書いた」と即答できる状態が、発注者としての到達点です。法務任せ・開発会社任せのままでは見えなかった責任構造が、仕様書・契約書という形で目に見える資産として残ることが、本記事の目指す状態です。
なお冒頭でも触れた通り、本記事は法的助言ではありません。個別の事案、特に大規模システム・要配慮個人情報を多く扱うシステム・GDPR 適用が想定されるシステムの設計時には、弁護士・個人情報保護委員会への確認を推奨します。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
