ISMS取得の相談で最初にぶつかるのが、適用範囲（スコープ）をどこで切るかです。全社にするのか、事業部単位にするのか、拠点を含めるのか。ここで悩む理由ははっきりしていて、範囲を広げれば審査費用と運用負荷が増え、狭めれば取引先が求めている証明にならない可能性があるからです。
ヘルスケア企業ではこの判断がさらに難しくなります。医療機関向けSaaSと一般法人向けツールを両方持っている、受託開発と自社プロダクトが混在している、医療情報を保持する環境と保持しない環境が分かれている——こうした構造が普通にあるためです。範囲を業務単位で切ったつもりが、実際には同じ開発チームが両方を触っていた、という食い違いも起きます。
本記事では、ヘルスケア企業が適用範囲を設計するときの具体的な切り方と、取引先が認証書のどこを見ているかを整理します。範囲定義の一般論は ISMS適用範囲の決め方 にまとめていますので、本記事はヘルスケア固有の論点に絞ります。
免責：本記事は一般的な情報提供です。適用範囲の妥当性の判断は、ISO/IEC 27001（JIS Q 27001）の規格本文および認定機関・審査機関の公表資料が正本です。実際の範囲設定は審査機関との事前確認のうえで決定してください。
適用範囲とは「何を審査で見せるか」の宣言
規格は、ISMSの境界と適用可能性を決定し、適用範囲として文書化することを求めています。ここで決めるのは主に次の4つです。
| 決める対象 | 具体例 | ヘルスケアでの落とし穴 |
|---|---|---|
| 組織単位 | 全社／特定事業部／特定子会社 | 医療事業だけ切り出したつもりが、管理部門が共通で範囲外になる |
| 業務・サービス | 「医療機関向けSaaSの企画・開発・運用・保守」 | 「保守」を入れ忘れ、医療機関から問われる運用工程が範囲外になる |
| 拠点 | 本社／開発拠点／リモートワーク環境 | フルリモート組織で「拠点」の実体がなく、自宅作業環境の扱いが曖昧になる |
| 情報システム・設備 | 開発環境、本番環境、社内IT、クラウド | 本番環境がクラウド事業者の責任範囲と混ざり、境界が説明できない |
重要なのは、適用範囲が**「うちはここまでを管理下に置いています」という対外的な宣言**だという点です。範囲外の領域で事故が起きても認証そのものは維持されますが、取引先から見れば「証明されていない領域」になります。逆に、範囲に含めた以上はその領域の運用記録を審査で見せる必要があります。
範囲を決める際、規格は組織が管理していない外部の依存関係（クラウド、委託先など）も考慮することを求めています。「クラウドに置いているから範囲外」は成立しません。 クラウド上の環境は自社の管理下にあるものとして扱い、事業者との責任分界を説明できる状態にするのが基本です。この考え方は 責任分界点の決め方 で発注側の視点から整理しています。
医療情報を扱う事業と扱わない事業が混在する場合
ヘルスケア企業で最も多いのがこのパターンです。取り得る選択肢は3つあります。
① 全社を範囲にする
最もシンプルで、説明コストが低い方法です。取引先に「全社でISMSを取得しています」と言えるため、調達での確認がスムーズになります。一方で、医療情報を扱わない事業部にも同じ規程・教育・監査が適用されるため、運用負荷が全社に広がります。
② 医療情報を扱う事業だけを範囲にする
審査費用と運用負荷を抑えられます。ただし、範囲の境界を技術的・組織的に説明できることが前提になります。同じ開発者が両方のプロダクトを触っている、同じSlackワークスペースとGitHub Organizationを共有している、といった状態では境界が実質的に存在しません。境界を主張するなら、アカウント・ネットワーク・リポジトリ・入退室のいずれかで実際に分離されている必要があります。
③ まず医療事業で取得し、後で全社に拡大する
現実的によく採られる進め方です。初年度は範囲を絞って取得し、運用が安定してから更新審査のタイミングで範囲を広げます。範囲拡大には追加の審査が必要になるため、3年間の総額で比較する視点が要ります。費用の構造は ISMS取得費用の全体像 をご覧ください。
判断の目安を整理すると次のようになります。
| 状況 | 推奨 | 理由 |
|---|---|---|
| 従業員50名以下で事業間の人的分離がない | ① 全社 | 境界を説明するコストのほうが高くつく |
| 医療事業が独立した部門・子会社になっている | ② 事業限定 | 境界が組織図で説明できる |
| 医療事業が立ち上げ期で今後の形が未確定 | ③ 段階拡大 | 範囲を固定しすぎると変更コストが発生する |
| 非医療事業が受託開発中心で顧客要求が多様 | ① 全社 | 結局どの事業でも証明を求められる |
開発・運用・サポートのどこまで含めるか
範囲の「業務」の切り方で、実務上いちばん判断が割れるところです。医療機関向けにシステムやサービスを提供している場合、顧客が関心を持つのは開発だけではありません。
| 工程 | 範囲に含める必要性 | 判断のポイント |
|---|---|---|
| 企画・要件定義 | 中 | 顧客の医療情報が要件定義段階で提供されるなら含める |
| 設計・開発 | 高 | ソースコード、開発環境、外部ライブラリの管理が問われる |
| テスト | 高 | 本番データを流用していないかが必ず確認される |
| リリース・変更管理 | 高 | 誰が本番に変更を入れられるかは監査の中心論点 |
| 本番運用・監視 | 高 | 医療情報が実際に存在する環境。外すと証明の意味が薄い |
| 保守・障害対応 | 高 | 障害時に本番データへアクセスする経路が最大のリスク |
| カスタマーサポート | 中〜高 | 問い合わせ対応で患者情報に触れるなら必須 |
| 営業・マーケティング | 低〜中 | 顧客名簿・商談情報のみなら外せることもある |
テストと保守の扱いが実質的な分かれ目です。 テストで本番データをコピーして使っている、障害調査のために開発者が本番DBに直接接続している——この2つは医療機関側のチェックシートでほぼ必ず聞かれます。ここを範囲外にしたまま認証書を提示すると、その場で追加質問が来ます。
カスタマーサポートは組織によって判断が分かれます。一次受付が外部委託で、患者情報に触れないスクリプト対応に限定されているなら、委託先管理として扱い範囲外にする設計も成り立ちます。ただしその場合、委託先管理の記録を求められます。委託の管理は 外部委託先管理 をご覧ください。
取引先は認証書のどこを見るか
ここが最も実務的な論点です。ISMS認証書には、おおむね次の情報が記載されます。
| 記載項目 | 取引先が見る理由 |
|---|---|
| 組織名 | 契約主体と一致しているか。子会社名義で親会社が契約する食い違いが起きやすい |
| 登録範囲（適用範囲） | 提供を受けるサービスがこの文言に含まれるか。最も精査される |
| 適用規格 | ISO/IEC 27001:2022 か旧版か |
| 認証登録番号 | 認定機関の登録組織検索で実在確認をする |
| 認定機関のシンボル | ISMS-AC か海外の認定機関か |
| 有効期限 | 失効していないか。更新審査の時期 |
調達担当者が実際に行う確認は、認証書の「登録範囲」に自分が買おうとしているサービス名または業務が読み取れるかです。ここに「情報システムの企画・開発」としか書かれていなければ、運用・保守の証明にはなりません。医療機関向けの調達では、この一行の記述で追加質問の量が変わります。
範囲の文言を作るときの実務的な注意は3つです。
- サービス名を入れるか、業務の類型で書くかを決める。サービス名を入れると明快ですが、プロダクト名変更のたびに範囲変更が必要になります
- 工程を漏らさず列挙する。「企画、開発、運用、保守及びサポート」のように、顧客が関心を持つ工程を明示する
- 拠点の書き方を確認する。フルリモート組織では、本社所在地のみを記載し、リモートワーク環境を規程側で管理する形が一般的です
認証を持っていること自体が取引条件になる場面については ISMSが取引条件になるケース で整理しています。逆に、医療機関側がベンダーに何を確認しているかを知りたい場合は ベンダーへのセキュリティチェックシート が参考になります。
範囲を決めたあとに効いてくること
適用範囲は、その後の作業量を直接決めます。範囲を決めた時点で、次のことが連動して決まります。
- 情報資産台帳の対象：範囲内の業務が扱う情報資産をすべて洗い出す
- リスクアセスメントの対象：台帳に載った資産すべてが対象になる
- 適用宣言書（SoA）の判断：物理的管理策を「該当なし」にできるかは、範囲に拠点が含まれるかで決まる
- 教育の対象者：範囲内の部門の従業者全員が受講対象になる
- 内部監査の対象：範囲内の全部門・全工程を一巡させる必要がある
とくに適用宣言書の判断が範囲に強く依存します。フルリモートで自社オフィスを持たない組織が物理的管理策をどう扱うか、クラウド上の本番環境しか持たない組織がサーバ室の管理策をどう説明するか。ここは範囲定義の書き方で結論が変わります。書き方は 適用宣言書（SoA）の書き方 をご覧ください。
また、医療機関向けサービスを提供している場合、範囲の設計は3省2ガイドラインへの対応とも連動します。ガイドラインが事業者に求める説明責任の対象と、ISMSの適用範囲がずれていると、医療機関への説明資料を別途作り直すことになります。 この統合の考え方は ISMS文書と3省2ガイドライン対応文書の統合 で扱っています。
マルチテナントの医療SaaSでは、テナント境界の設計が適用範囲の説明と直結します。あわせて 医療SaaSのISMS｜マルチテナントのリスク評価 もご覧ください。
まとめ
ヘルスケア企業の適用範囲設計で押さえるべき点は次のとおりです。
- 適用範囲は「何を管理下に置いているか」の対外的な宣言であり、範囲外は取引先から見て「証明されていない領域」になる
- 医療事業だけを切り出すなら、アカウント・ネットワーク・リポジトリ・入退室のいずれかで実際に分離されていることが前提
- 工程ではテストと保守が分かれ目。本番データの流用と本番への直接アクセスは必ず問われる
- 取引先が見るのは認証書の登録範囲の文言。買おうとしているサービスと工程が読み取れるかで追加質問の量が変わる
- 範囲は情報資産台帳・リスクアセスメント・SoA・教育・内部監査の対象を同時に決める。広げるほど毎年の運用負荷が増える
- 3省2ガイドライン対応を見据えるなら、説明責任の対象と適用範囲を最初から揃える
ポテックはヘルスケア領域に特化してISMS認証取得を支援しています。適用範囲の設計は、御社の事業構成と取引先の要求を踏まえて初期段階でご一緒に決めるところから始めます。規程・台帳・教材のひな形を提供し、審査機関とのやり取りも当社が主導します。
支援内容と料金は ISMS認証取得支援サービス を、個別のご相談は お問い合わせ をご覧ください。ISMS全体の見取り図は ISMS（ISO/IEC 27001）とは｜ヘルスケア企業のための完全ガイド にまとめています。
参考・出典
- 情報マネジメントシステム認定センター（ISMS-AC）
- ISO/IEC 27001 Information security management systems｜ISO
- 医療情報システムの安全管理に関するガイドライン｜厚生労働省
※適用範囲の妥当性は審査機関の判断によります。認証書の記載様式は認証機関により異なります。規格の要求事項の解釈は規格本文および認定機関・審査機関の公表資料をご確認ください。