自社のセキュリティをどれだけ固めても、情報が外に出ていく先の管理が緩ければ、実質的な守りの水準はその最も弱い箇所で決まります。ヘルスケア企業の場合、この「外」は開発委託先、インフラのクラウド事業者、コールセンター、データ入力業者、AIのAPI提供元、保守ベンダーと多岐にわたり、しかも多くが自社より小さい組織か、自社よりはるかに大きい組織のどちらかです。前者には要求が通り、後者には通らない——この非対称性が、委託先管理を難しくしています。
審査でも、委託先管理は指摘が集中する領域です。典型的なのは、委託先一覧はあるが評価の記録がない、チェックシートは返ってきているが中身が確認されていない、契約書に情報セキュリティに関する条項がないの3つです。いずれも「やっていない」のではなく「やっているが証跡と実質が伴っていない」形で現れます。
本記事では、委託先の選定基準、チェックシートの設計、契約に入れる条項、クラウド事業者の扱い、そして医療情報を扱う場合の3省2ガイドラインとの接続を扱います。リスクアセスメントとの関係は リスクアセスメントの進め方｜評価基準の設計、該当する管理策は 組織的管理策37項目の読み方、規格全体は ISMS（ISO/IEC 27001）とは をご覧ください。
免責：本記事は一般的な情報提供です。規格の要求事項の解釈、認定・認証の取扱いは規格本文および認定機関・審査機関の公表資料が、医療情報の取扱いに関する要件は厚生労働省・経済産業省・総務省の公表資料が正本です。契約条項の法的有効性については弁護士にご確認ください。
なぜここでつまずくのか
すべての委託先を同じ深さで管理しようとする
委託先が50社あるとき、全社に同じチェックシートを送り、全社と同じ条項で契約し、全社を毎年評価する——これは実務的に破綻します。実際には、名刺印刷会社と、患者データを保持する開発委託先を同列に扱う理由はありません。重要度で区分し、深さを変えるのが唯一の現実解です。
チェックシートが「返ってきたこと」で満足してしまう
100問のチェックシートを送り、委託先が全項目「はい」で返してくる。これを受け取ってファイルすれば評価完了、という運用が多く見られます。しかしこの記録は、何も評価していないことの記録です。審査員は「この回答をどう評価したのか」を尋ねます。
契約が既存のひな形のままになっている
営業が使っている業務委託契約書のひな形に、秘密保持条項はあるが情報セキュリティに関する条項がない。再委託は「書面による承諾」とだけ書かれ、承諾の実績がない。データの返却・削除が定められていない。契約の更新タイミングでしか直せないため、後回しにされやすい領域です。
大手クラウド事業者に要求が通らない
主要なクラウドサービスは、個別の契約交渉にも、チェックシートの記入にも、監査にも応じないのが通常です。ここで「評価できないから記録なし」とすると、委託先管理全体が穴だらけになります。公開情報と第三者認証をもって評価するという別の方法を設計する必要があります。
再委託先が見えていない
委託先Aが実装を委託先Bに出し、Bがさらにフリーランスに出している。契約上は禁止していないため違反ではないが、自社は把握していない。インシデントが起きて初めて構造が判明する——これが最も危険な形です。
何を決めるのか
委託先の重要度区分
最初に決めるのは区分です。医療情報・個人データへのアクセスの有無と、自社サービスの可用性への影響の2軸で切るのが実務的です。
| 区分 | 判定の目安 | 選定時の確認 | 定期評価 | 契約条項 |
|---|---|---|---|---|
| 重要（Tier 1） | 患者データ・医療情報にアクセスする／本番環境に権限を持つ／停止するとサービスが止まる | チェックシート＋証跡確認＋必要に応じて実地または面談 | 年1回 | フルセット（再委託・監査権・通知・削除・準拠法） |
| 中（Tier 2） | 個人データを扱うが医療情報ではない／間接的にサービスに影響する | チェックシート＋第三者認証の確認 | 年1回（簡易） | 標準セット |
| 低（Tier 3） | 情報資産へのアクセスがない／代替が容易 | 基本情報の確認のみ | 契約更新時 | 秘密保持＋基本条項 |
区分の判定基準を文書化しておくことが重要です。 「なぜこの委託先がTier 2なのか」を説明できないと、区分そのものが恣意的だと見なされます。判定した根拠を委託先台帳に1行書いておけば足ります。
委託先台帳に持つ項目
| 項目 | 目的 |
|---|---|
| 委託先名・契約書番号・契約期間 | 契約との紐づけ |
| 委託業務の内容 | 何をさせているか |
| 取り扱う情報の種類 | 医療情報／個人データ／機密情報／なし |
| アクセス範囲 | 本番／検証／閲覧のみ／持出の有無 |
| 重要度区分と判定根拠 | 管理の深さの決定 |
| 再委託の有無と再委託先名 | サプライチェーンの可視化 |
| 保有する認証 | ISMS／Pマーク／ISO 27017／SOC 2 等 |
| 最終評価日と評価結果 | 定期評価の追跡 |
| 契約終了時のデータ処理予定 | 終了時の抜け漏れ防止 |
| 自社側の管理責任者 | 委託先ごとに人を置く |
「自社側の管理責任者」の欄が抜けている台帳は、評価が回りません。 誰の仕事でもない評価は実施されないため、委託先ごとに部門の担当者を置き、その人の業務として年次評価を組み込みます。
契約に入れる条項
契約は、委託先管理の唯一の強制力です。チェックシートには従う義務がありませんが、契約条項には従う義務があります。Tier 1の委託先には、最低限次の条項を入れます。
| 条項 | 定めるべき内容 | 抜けたときのリスク |
|---|---|---|
| 情報セキュリティ対策義務 | 自社が求める水準（自社規程の遵守、または具体的な措置の列挙） | 「何が義務か」が争いになる |
| 再委託の制限 | 事前の書面承諾。再委託先にも同等の義務を課すこと。再委託先の一覧提出と変更時の通知 | サプライチェーンが不可視になる |
| 監査権 | 書面調査・現地調査の受入れ。頻度と費用負担。第三者監査報告書での代替可否 | 実態確認の手段がなくなる |
| インシデント通知義務 | 通知の期限（例：認知後◯時間以内）、通知先、通知内容、調査協力義務 | 顧客医療機関への通知が間に合わない |
| データの取扱い範囲 | 目的外利用の禁止、保管場所（国・リージョン）の指定、複製の制限 | 想定外の場所にデータが置かれる |
| 契約終了時の返却・削除 | 返却または削除の別、期限、削除の証明方法、バックアップ内のデータの扱い | 終了後もデータが残り続ける |
| 従業者管理 | 秘密保持義務の承継、退職後の義務、教育の実施 | 個人経由の漏えい |
| 損害賠償・責任範囲 | 上限の有無、情報漏えい時の扱い | 事故時の負担が想定と乖離 |
通知期限を具体的な時間で書くことが、実務上もっとも効果があります。 「速やかに」では、委託先が調査を終えてから連絡してくることがあり、自社の顧客医療機関への通知や法令報告の期限に間に合いません。**「認知後24時間以内に第一報。内容が未確定でも一報を入れる」**のように、一報の義務を分けて書きます。インシデント時の社内フローは インシデント対応手順の作り方（事業者） をご覧ください。
削除の証明方法も具体化します。 「削除しました」というメール1通で足りるのか、削除証明書を求めるのか、バックアップからの消去までを含むのか。バックアップは世代管理の都合で即時削除できないことが多いため、「最長◯日以内にバックアップ世代から消失する」ことを確認するという現実的な書き方もあります。
実務の手順
1. 選定（契約前）
Tier 1候補には、チェックシート＋証跡の確認をセットで行います。チェックシート単体では、回答の真偽を確認する手段がありません。
チェックシートは40〜60問が実務的な上限です。100問を超えると、委託先側も自社側も精読しなくなります。ヘルスケア企業が委託先に確認すべき項目は、次の領域に絞り込めます。
| 領域 | 確認する内容の例 | 求める証跡の例 |
|---|---|---|
| 体制 | セキュリティ責任者の設置、規程の整備、教育の実施 | 規程の目次、教育記録の様式 |
| 認証 | ISMS／Pマーク／ISO 27017／SOC 2 の保有と適用範囲 | 認証書の写し（範囲の記載を確認） |
| アクセス管理 | 権限付与・棚卸の手順、特権IDの管理、多要素認証 | 棚卸記録の様式、実施頻度 |
| データ管理 | 保管場所、暗号化、持出制限、開発環境での本番データ利用 | データフロー図、保管場所の記載 |
| 再委託 | 再委託の有無、再委託先名、再委託先への要求 | 再委託先一覧 |
| インシデント | 対応手順の有無、過去の発生状況、通知の実績 | 手順書の目次 |
| 事業継続 | バックアップ、復旧目標、障害時の連絡体制 | 復旧手順の概要、訓練記録 |
| 終了時 | データ返却・削除の手順 | 削除手順の説明 |
認証書を受け取ったら、適用範囲を必ず読みます。 ISMS認証を持っていても、自社が委託する業務を行う拠点・部門が適用範囲外であることは珍しくありません。「本社のみ」「東京事業所の◯◯サービスに関わる業務」といった記載を確認せずに「認証あり＝問題なし」とすると、評価として成立しません。認定機関による違いは ISMS-AC・UKAS・ANAB｜認定機関の違いと選び方 をご覧ください。
回答に対する自社の評価を1行書く。 これがチェックシートを形骸化させない最小のコストです。
| 項目 | 委託先回答 | 自社評価 |
|---|---|---|
| 多要素認証の導入 | はい（一部） | 本番環境は導入済み、検証環境は未。検証環境に本番データを置かない運用のため許容 |
| 再委託 | あり（設計の一部を◯◯社へ） | 再委託先の認証なし。自社データへのアクセスはない旨を契約で明記することを条件に許容 |
| バックアップ | はい | 頻度・保管場所の記載なし。追加確認が必要（担当：◯◯、期限：◯月◯日） |
「追加確認が必要」と書いた項目が放置されていないかは、審査で見られます。
2. 契約（契約時）
前節の条項を、ひな形として整備します。委託先ごとに一から交渉すると回りません。Tier別に3種類のひな形（フル／標準／基本）を用意し、法務のレビューを一度通しておく形が現実的です。
既存契約の遡及も計画に入れます。 すべてを一斉に巻き直すのは不可能なので、Tier 1から順に、契約更新のタイミングで差し替える計画を立て、その計画自体を記録に残します。審査では「未対応の契約が残っていること」よりも、「計画がなく放置されていること」が問題になります。
3. 監視（契約期間中）
定期評価は年1回が基本ですが、評価のトリガーは時期だけではありません。
| トリガー | 実施すること |
|---|---|
| 年次 | チェックシートの再取得、認証の有効期限確認、台帳の更新 |
| 委託先でインシデントが発生 | 影響評価、是正状況の確認、必要なら区分の見直し |
| 委託業務の範囲が変わった | 取り扱う情報の種類・アクセス範囲の再確認、契約条項の見直し |
| 再委託先が変わった | 新規再委託先の確認、承諾手続き |
| 委託先の資本・組織に変更 | 買収・統合に伴うデータ取扱いの変更確認 |
| 委託先の認証が失効・停止 | 代替手段の確認、区分の見直し |
日常的な監視も設計に含めます。 委託先に付与したアカウントの棚卸（不要な権限が残っていないか）、アクセスログの点検、SLAの達成状況の確認。これらは年次評価より高い頻度で回すべき項目です。
4. 終了（契約終了時）
終了時の抜け漏れが、実務でもっとも多い穴です。終了時チェックリストを用意し、完了を記録します。
- 貸与した機器・媒体の回収
- 付与したアカウント・アクセス権の削除（削除の実施記録）
- VPN・専用線等の接続の停止
- 預けたデータの返却または削除、および削除証明の受領
- バックアップ世代からの消失の確認
- 委託先台帳の更新（終了日、データ処理の完了日）
- 秘密保持義務が終了後も存続することの確認
アカウント削除の記録が残っていないケースが非常に多いのですが、退職者アカウントと同様、委託先アカウントの残存は実害のあるリスクです。
クラウド事業者の扱い
大手クラウド事業者は、個別の契約交渉・チェックシート記入・実地監査のいずれにも通常は応じません。これを「管理不能」で済ませず、評価方法を変えることで委託先管理の枠内に収めます。
| 通常の委託先での方法 | クラウド事業者での代替 |
|---|---|
| チェックシートへの回答 | 公開されている第三者監査報告書・認証（ISO 27001、ISO 27017、ISO 27018、SOC 2 Type II 等）の取得と確認 |
| 個別契約での条項合意 | 利用規約・データ処理条項・SLAの内容確認と記録。規約の重要な変更を追う仕組み |
| 実地監査 | 公開監査報告書のレビュー、コンプライアンスポータルの確認 |
| インシデント通知 | ステータスページ・通知メールの受信先を組織のアドレスにする（個人アドレスにしない） |
| 再委託先の把握 | 事業者が公開するサブプロセッサ一覧の確認と、変更通知の購読 |
重要なのは、責任共有モデルにおける自社側の責任範囲を明確にすることです。 クラウド事業者が基盤の安全性を担保しても、設定・権限・データの分類は利用者側の責任です。ここを委託先管理と混同すると、「クラウド事業者が認証を持っているから大丈夫」という誤った結論に至ります。責任分担の考え方は既存記事の AI電子カルテのセキュリティ設計｜責任共有モデル と 医療機関のクラウドセキュリティ が参考になります。
クラウド向けの追加認証の位置づけは ISO 27017・27018とは｜クラウド向けの追加認証 で扱っています。
保管リージョンの確認は、医療情報を扱う場合は必須です。 サービスによっては、データ本体は国内リージョンでも、ログ・メタデータ・バックアップが国外に置かれる構成があります。契約や仕様で明示されていない場合は、事業者への照会結果を記録に残します。
生成AIのAPIを利用する場合も、委託先管理の対象です。入力データが学習に利用されるか、保存期間はどれだけか、どのリージョンで処理されるか。この3点は最低限、台帳と評価記録に残します。医療分野での論点は既存記事の 医療機関の生成AI利用｜法務・セキュリティガイド をご覧ください。
3省2ガイドラインとの接続
医療情報を扱う事業者にとって、委託先管理はISMSの要求であると同時に、医療情報の安全管理に関する枠組みの要求でもあります。
構造としては次のようになっています。
| 層 | 誰が誰を管理するか | 根拠となる枠組み |
|---|---|---|
| 医療機関 → 事業者 | 医療機関が、システム・サービス提供事業者を管理する | 厚生労働省「医療情報システムの安全管理に関するガイドライン」 |
| 事業者 → 再委託先 | 事業者が、自らの委託先・再委託先を管理する | 経済産業省・総務省「医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン」 |
| 全体 | 組織が、自らのISMSの中で委託先を管理する | ISO/IEC 27001（附属書Aの供給者関係の管理策） |
この3層は別々に作らず、1つの仕組みに統合するのが効率的です。 具体的には、ISMSの委託先管理手順を主とし、そこに医療情報を扱う委託先に追加で求める項目を加える形にします。
追加で求める項目の例：
| 追加項目 | 理由 |
|---|---|
| 医療情報を保管する国・リージョンの明示 | 外部保存に関する要件との関係 |
| 医療機関への説明責任を果たすための情報開示 | 顧客医療機関が自らのガイドライン対応を説明できるようにするため |
| 医療機関への通知を要するインシデントの定義 | 自社が顧客医療機関へ負う通知義務を、再委託先まで貫通させる |
| 診療業務への影響を考慮した作業時間帯の制限 | 保守作業が診療を止めない設計 |
| リモートメンテナンス時の接続・記録の要件 | 遠隔保守経路が典型的な侵入経路になるため |
顧客医療機関から受けるチェックシートの内容を、そのまま自社の委託先チェックシートに反映させるのは実務的に有効な方法です。医療機関から問われる項目は、自社が再委託先に問うべき項目とほぼ重なります。医療機関側から見た確認事項は ベンダーへのセキュリティチェックシート と 事業者に確認すべき質問リスト で扱います。
文書の統合方法は ISMS文書と3省2ガイドライン対応文書の統合、ガイドラインの全体像は既存記事の 3省2ガイドラインとは と 3省2ガイドライン対応の実務ステップ をご覧ください。
よくある失敗
委託先の定義が狭すぎる
「業務委託契約を結んでいる先」だけを台帳に載せ、SaaSの利用・クラウドサービス・APIの利用が入っていない。実質的に情報を預けている先は、契約形態にかかわらず対象です。「自社の情報が外部に出る、または外部から自社の情報にアクセスできる関係」を基準にすると漏れが減ります。
チェックシートの回答を確認していない
前述のとおりですが、「全項目はい」の回答は、むしろ確認を要するサインです。実態と乖離していることが多く、少なくとも重要項目については証跡を求めます。
監査権を契約に入れたが一度も行使していない
条項があること自体に意味はありますが、Tier 1の委託先については書面での年次確認は最低限実施します。実地監査が難しい場合でも、オンラインでの面談と資料確認で代替できます。
再委託の承諾が口頭で行われている
契約で「書面による事前承諾」と定めているのに、実務ではメールの1往復で済ませ、承諾の記録が残っていない。承諾の様式を用意し、台帳に紐づけることで解決します。
評価結果が是正につながっていない
評価で「バックアップの記載なし」と指摘したまま、翌年も同じ指摘が繰り返される。不足事項は期限付きの改善要求として伝え、完了を確認するプロセスにします。改善されない場合の判断（契約継続の可否、代替先の検討）も、あらかじめ基準を決めておきます。
委託先の評価をセキュリティ部門だけで行っている
実際の業務を知らない部門が評価すると、リスクの実態が見えません。委託業務の発注部門を評価に参加させることで、「契約上は閲覧のみだが、実際には本番データを見ている」といった乖離が見つかります。
人的リスクが抜けている
委託先の従業者に対する秘密保持義務、退職時の措置、常駐者の入退室管理。技術的な項目に比べて確認が甘くなりがちですが、実際の漏えい事例では人的要因が大きな割合を占めます。人的管理策の読み方は 人的管理策8項目の読み方 をご覧ください。
ヘルスケア企業の例
医療SaaS事業者の場合
もっとも重要な委託先は、多くの場合開発・保守の委託先です。本番環境への接続権限を持ち、障害調査で患者データを参照しうる立場にあるため、Tier 1として扱います。ここで固有に確認すべきなのは、開発・検証環境における本番データの利用です。「テストのために本番データをコピーして使っている」運用は現実に存在し、契約と実態の乖離が最も出やすい箇所です。マスキング・匿名化の実施と、その確認方法を評価項目に入れます。
もう一つはサブプロセッサの連鎖です。自社のサービスが、クラウド基盤・認証基盤・メール配信・AI API・監視サービスの上に成り立っている場合、そのすべてが顧客医療機関から見れば「自社の再委託先」です。顧客に開示できるサブプロセッサ一覧を自社でも作成しておくと、顧客医療機関からの照会に即答でき、商談の速度が上がります。
PHR事業者の場合
利用者本人から預かったデータの取扱いについて、同意の範囲が委託先にも貫通しているかが論点になります。利用者が同意していない目的で、委託先がデータを利用・分析できる契約になっていないか。契約条項の「目的外利用の禁止」を、同意文言と突き合わせて確認します。詳細は PHR事業者のISMS｜個人情報保護法との関係 をご覧ください。
治験・臨床研究システムを扱う企業の場合
委託先に求める水準に、記録の保存期間と監査証跡が加わります。試験終了後も長期の保存が求められるため、契約終了時のデータ削除条項と、保存義務が衝突しないよう設計が必要です。「終了後速やかに削除」と一律に書くと、保存義務に反する結果になりえます。
SaMDを開発する企業の場合
委託先管理が、ISMSの供給者管理とQMS（ISO 13485）の購買管理の二系統にまたがります。同じ委託先に対して2つの評価を別々に行うのは非効率なため、評価項目を統合した1つのチェックシートを作り、どちらの要求を満たす項目かを列で示す方式が実務的です。関係の整理は SaMDとISMS・QMS（ISO 13485）の関係 をご覧ください。
少人数の組織の場合
委託先の数が多く、管理する人数が少ない構造になりがちです。この場合、Tier 3を思い切って軽くし、Tier 1に工数を集中させる判断が必要です。全社を均等に管理しようとすると、結果的にすべてが浅くなります。組織規模に応じた設計は 少人数組織のISMS｜50名以下で取得するときの考え方 で扱います。
まとめ
- 委託先は重要度で区分し、管理の深さを変える。全社を同じ深さで管理する設計は必ず破綻する
- チェックシートは回答を受け取ることではなく、回答を評価することが目的。各項目に自社の評価を1行残す
- 契約に必ず入れるのは再委託の制限・監査権・インシデント通知（時間を明記）・データの返却と削除の4条項
- クラウド事業者には第三者認証と公開監査報告書による評価という別の方法を設計する。認証の適用範囲を必ず読む
- 医療情報を扱う委託先には、医療機関への通知義務を貫通させる条項を追加する。3層の管理を1つの仕組みに統合する
- 契約終了時のアカウント削除とデータ削除の記録が最も抜けやすい。終了時チェックリストで閉じる
委託先で発生したインシデントの扱いは インシデント対応手順の作り方（事業者）、委託先の停止がサービス継続に及ぼす影響は 事業継続計画（BCP）とISMSの接続、評価で見つかった不足の是正は 是正処置報告書の書き方 をご覧ください。委託先管理の状況は マネジメントレビューの進め方と議事録 の定例インプットにもなります。
ポテックは、ヘルスケア領域に特化してISMS認証取得と運用を支援しています。顧客医療機関からの要求を自社の委託先管理に折り返す設計は、医療分野の商流を知っているかどうかで質が変わります。支援内容と料金は ISMS認証取得支援サービス、個別のご相談は お問い合わせ から承ります。
参考・出典
- 情報マネジメントシステム認定センター（ISMS-AC）
- ISO/IEC 27001 Information security management systems｜ISO
- 医療情報システムの安全管理に関するガイドライン｜厚生労働省
- 経済産業省
- 総務省
- 個人情報保護委員会
※規格の要求事項の解釈、認定および認証の取扱いは規格本文および認定機関・審査機関の公表資料を、医療情報の取扱いに関する要件は各省の公表資料をご確認ください。改定により取扱いが変わる場合があります。契約条項の法的有効性については弁護士にご確認ください。