委託先の管理は、3省2ガイドラインが医療機関に求めている項目のひとつです。そして多くの医療機関で、その実務はチェックシートの送付という形をとっています。ところが実際に運用してみると、返ってきたシートが「はい／対応しています」で埋まっているだけで、読んでも何も分からないという状態になりがちです。
原因は設問の作り方にあります。「アクセス制御を実施していますか」と聞けば、どの事業者も「はい」と答えます。嘘ではありません。何らかのアクセス制御は必ずあるからです。しかし御院が知りたいのは、誰が御院のデータに触れられるのか、その人数は何人か、退職時にどう止まるのかのはずです。設問がそこを問うていなければ、回答が形式的になるのは当然です。
本記事は、医療機関がベンダーに出すセキュリティチェックシートを設計するための実務をまとめたものです。何を聞くべきか（6領域）、どう聞けば実態が出るか、そして返ってきた回答をどう読むかを扱います。作った設問は、調達の仕様書にもそのまま使えます。仕様書への落とし込みは 医療情報システムの調達要件にセキュリティを入れる を参照してください。
免責：本記事は一般的な情報提供です。ガイドラインの要求事項は「医療情報システムの安全管理に関するガイドライン」および経済産業省・総務省のガイドライン本文が正本です。契約条項化にあたっては顧問弁護士にご確認ください。
チェックシートが形骸化する3つの理由
まず、なぜ多くのチェックシートが機能しないのかを整理します。原因が分かれば、設計の方針が決まります。
| 原因 | 起きていること | 対処 |
|---|---|---|
| 設問がYes/Noで答えられる | 「実施していますか」→「はい」。実態が見えない | 数・頻度・対象範囲・手段を書かせる設問にする |
| 根拠を求めていない | 回答の裏付けがなく、回答者の認識に依存する | 「根拠となる規程名・文書名を記載」欄を必須にする |
| 回答後に何も起きない | 事業者側が「出せば終わり」と学習する | 回答内容の一部を契約条項に転記する、次回更新時に差分を確認する |
3つ目が実は最も効きます。チェックシートの回答が契約に反映されると分かれば、事業者は書けないことを書かなくなります。逆に、提出させるだけで何も起きない運用を数年続けると、シートは事務作業に退化します。
もうひとつ実務上の注意があります。設問数を増やしすぎると、事業者側が定型回答を貼り付けるようになります。30〜50問を目安に、御院にとって重要な領域を厚くする設計が現実的です。全項目を網羅した長大なシートより、6領域それぞれで踏み込んだ設問が数問ずつあるほうが、実態は見えます。
聞くべき6領域と設問
以下は、医療情報を扱う事業者に対して押さえておきたい領域と設問です。「良い設問」の列は、そのまま使える文言にしています。
1. 体制・責任者
| 項目 | 弱い設問 | 良い設問 |
|---|---|---|
| 責任者 | セキュリティ責任者はいますか | 情報セキュリティの責任者の役職名と、専任／兼任の別を記載してください |
| 規程 | 社内規程はありますか | 情報セキュリティに関する社内規程の名称・最終改定年月を記載してください |
| 教育 | 従業員教育を行っていますか | 直近1年間の従業員向けセキュリティ教育の実施回数・対象者数・受講率を記載してください |
| 認証 | 認証を取得していますか | 保有する第三者認証の名称・認証番号・適用範囲（事業所・サービス）・有効期限を記載してください |
| 退職者対応 | 退職時の手続はありますか | 従業員の退職時に、当院データへのアクセス権を削除するまでの標準日数と、その実施を確認する方法を記載してください |
認証については、適用範囲を必ず書かせてください。認証書に記載された適用範囲が本社の管理部門のみで、御院の案件を担当する開発拠点や運用拠点が範囲外というケースは実在します。認証があることと、御院の案件がその管理下にあることは別の話です。適用範囲の考え方は ISMS適用範囲の決め方、認証そのものの位置づけは ISMS（ISO/IEC 27001）とは をご覧ください。
2. アクセス管理
| 項目 | 良い設問 |
|---|---|
| 接触者数 | 当院のデータにアクセスできる貴社の従業員は何名ですか。役割別に記載してください |
| 権限付与 | アクセス権の付与・変更・削除の申請と承認は誰が行いますか。承認記録は残りますか |
| 特権ID | 本番環境の管理者権限を持つのは何名ですか。共有アカウントの有無を記載してください |
| 認証方式 | 本番環境へのアクセスに多要素認証を適用していますか。適用していない経路があれば記載してください |
| 棚卸 | アクセス権の棚卸をどの頻度で実施していますか。直近の実施年月を記載してください |
「何名か」を数で書かせるのが要点です。5名と答える事業者と、40名と答える事業者では、リスクの性質が違います。共有アカウントの有無も同様で、「あります」と答えた時点で、誰が操作したかを事後に特定できない範囲が存在すると分かります。
3. 委託・再委託
| 項目 | 良い設問 |
|---|---|
| 再委託の有無 | 本件業務で再委託を行いますか。行う場合、再委託先の名称・所在国・委託する業務内容を記載してください |
| 再委託先の管理 | 再委託先に対して、貴社はどのような方法で安全管理措置を確認していますか |
| 事前承諾 | 再委託先を変更する場合、当院への事前通知は可能ですか |
| 開発・保守の体制 | ソフトウェアの開発・保守を行う拠点の所在国を記載してください |
| クラウド | 利用するクラウドサービスの事業者名・リージョンを記載してください |
再委託は、チェックシートで最も情報が取りにくい領域です。「再委託はありません」という回答が、実際にはクラウド基盤やSaaS型の監視サービスを含んでいないだけ、ということがあります。「クラウドサービスの利用を含めて記載してください」と明記しておくと精度が上がります。再委託の連鎖が見えない問題は 医療機関のサプライチェーンリスク で詳しく扱います。
4. インシデント時の対応
| 項目 | 良い設問 |
|---|---|
| 連絡先 | 当院からの緊急連絡先（平日夜間・休日を含む）と、一次応答までの目標時間を記載してください |
| 通知義務 | 貴社側でインシデントを検知した場合、当院への通知はいつ、どの経路で行われますか |
| 通知の基準 | 当院に通知するインシデントの範囲（基準）を記載してください |
| 復旧目標 | システム停止時の復旧目標時間（RTO）と、復旧目標時点（RPO）を記載してください |
| 訓練 | インシデント対応の訓練を実施していますか。直近の実施年月と内容を記載してください |
通知の基準を聞くのがポイントです。「インシデントが起きたら連絡します」という回答は、何をインシデントと呼ぶかが事業者の裁量に委ねられている状態を意味します。不正アクセスの試行を検知した段階で通知するのか、実害が確認されてからなのか——ここが曖昧なまま契約すると、御院が事態を知るのが報道と同時、ということが起こり得ます。RTO/RPOの決め方は SLAと責任分界の書き方、院内側の備えは 医療機関のインシデント対応計画 を参照してください。
5. データの所在と削除
| 項目 | 良い設問 |
|---|---|
| 保存場所 | 当院のデータが保存される国・地域を、本番・バックアップ・ログのそれぞれについて記載してください |
| 分離 | 他の顧客のデータとどのように分離されていますか（論理分離／物理分離の別と方式） |
| 暗号化 | 保存時・通信時の暗号化の有無と方式を記載してください |
| 持ち出し | 保守・開発の目的で当院のデータを貴社環境に複製することがありますか。ある場合、手続と保管期間を記載してください |
| 契約終了時 | 契約終了時のデータ返還形式と、返還後の消去完了までの日数、消去の証明方法を記載してください |
| バックアップの消去 | バックアップに含まれる当院データの消去はいつ完了しますか |
バックアップの消去は、ほぼ必ず抜ける項目です。本番環境からデータを消しても、世代管理されたバックアップには残ります。「消去完了」の定義にバックアップを含めるかどうかを、契約前に確認しておいてください。外部保存の要件全般は 医療情報の外部保存の要件 にまとめています。
保守目的の複製も見落とされがちです。障害調査のために本番データを開発環境にコピーする運用は珍しくありませんが、そこには当然リスクがあります。禁止するか、手続（申請・承認・期限付き・作業後削除）を定めるかを、事前に決めておく必要があります。
6. 監査と報告
| 項目 | 良い設問 |
|---|---|
| 定期報告 | セキュリティ対策の実施状況について、当院への定期報告は可能ですか。頻度と形式を記載してください |
| 監査の受入 | 当院または当院が指定する第三者による監査（書面／立入）を受け入れますか。条件があれば記載してください |
| 第三者監査 | 外部の監査・脆弱性診断を受けていますか。実施主体と直近の実施年月を記載してください |
| 是正 | 監査等で指摘を受けた場合の是正プロセスと、当院への共有方法を記載してください |
監査権は、実際に行使しなくても意味があります。受け入れる義務がある状態そのものが、事業者側の管理水準に影響するためです。ただし無条件の立入監査を求めると価格に跳ね返るので、「書面報告を原則とし、重大な事象が生じた場合に協議のうえ立入を認める」といった現実的な設計にしてください。
回答が形式的にならない聞き方
設問の作り方には、いくつか共通の型があります。
1. 数を書かせる
「アクセス管理をしていますか」ではなく「何名がアクセスできますか」。数は誤魔化しにくく、他社との比較もできます。
2. 直近の実施年月を書かせる
「訓練を実施していますか」ではなく「直近の実施年月と内容」。制度として持っていることと、実際に回していることの差がここに出ます。
3. 根拠文書を書かせる
回答欄の隣に「根拠となる規程・手順書の名称」の列を置きます。書けない項目は、実務が文書化されていないか、そもそも運用されていない可能性があります。
4. 「ない」場合の記載欄を用意する
「該当なし」「未実施」を選べるようにし、その場合の理由・代替措置の記載を求めます。選択肢が「はい」しかないシートは、「はい」しか返ってきません。
5. 誰が回答したかを書かせる
回答者の氏名・役職・部署を記入させます。営業担当が推測で書いたのか、技術部門が確認して書いたのかで、回答の重みが変わります。
| 悪い設問 | 良い設問 | 何が変わるか |
|---|---|---|
| バックアップを取得していますか | バックアップの方式・頻度・世代数・保管場所、およびオフライン保管の有無を記載してください | 加算要件との照合が可能になる |
| ログを管理していますか | 取得しているログの種類と保管期間、当院からの開示要請への対応可否と所要日数を記載してください | 事故時に何が分かるかが事前に見える |
| 脆弱性対応を行っていますか | 重大な脆弱性が公表された場合の、影響調査開始から修正適用までの標準日数を記載してください | 対応の速度が比較できる |
| 従業員教育を行っていますか | 直近1年の実施回数・対象者数・受講率 | 「年1回・受講率40%」のような実態が出る |
返ってきた回答をどう読むか
シートが返ってきたら、点数化する前に次の観点で読んでください。
- 空欄・未記入がどこにあるか。書けなかった項目は、そこに実務がないことを示唆します
- 「はい」の根拠欄が空いていないか。根拠のない「はい」は、回答者の認識である可能性があります
- 数字が不自然に大きくないか／小さくないか。アクセス可能者が2名という回答は、実は共有アカウントで運用している場合があります
- 回答者の部署。全項目を営業担当が書いている場合、技術面の回答精度は割り引いて読む必要があります
- 他社との差。同じ設問に対する複数社の回答を並べると、業界の標準的な水準が見えてきます
そして最も重要なのが、回答内容の一部を契約に転記することです。「アクセス可能者は5名」「通知は検知から2時間以内」と回答したなら、それを覚書や仕様書に反映させます。これをやると、翌年以降のシートの精度が明確に上がります。
回答が不十分だった事業者に対しては、失格とする前に、是正の期限を切って再提出を求める選択肢もあります。長く保守を担ってきた地域の事業者が体制整備の途上にある、という状況は珍しくありません。発注側が具体的な水準を示すことが、供給側の水準を引き上げます。事業者側がこれに応えようとするとき、その手段のひとつが ISMS認証取得支援 のような体制構築です。
まとめ
チェックシートを機能させるために押さえるべき点は次のとおりです。
- Yes/Noで答えられる設問は使わない。数・頻度・直近の実施年月・対象範囲を書かせる
- 聞くべきは 6領域（体制／アクセス管理／委託・再委託／インシデント対応／データの所在と削除／監査と報告）
- 設問数は30〜50問を目安に。網羅より、重要領域の深さを優先する
- 認証は保有の有無ではなく、適用範囲と有効期限まで書かせる
- 再委託は「クラウドサービスの利用を含む」と明記しないと出てこない
- 回答の一部を契約に転記する。これが翌年以降の回答精度を決める
チェックシートの設計と、返ってきた回答の読み解きは、院内の情報システム担当だけで抱えるには重い作業です。既存の委託先を対象に一度棚卸をしたい、あるいは次期更改に向けてシートを作り直したいといった場合は、お問い合わせ からご相談ください。
参考・出典
※ガイドラインの要求事項は改定により変わります。チェックシートの項目は、最新版の公表資料に照らして定期的に見直してください。