ISMS適用範囲の決め方

ISMS構築の最初の決定が、適用範囲（スコープ）の設定です。そしてこれが、後戻りが最も高くつく決定でもあります。範囲を決めると、情報資産台帳の対象が決まり、リスクアセスメントの対象が決まり、規程を適用する部門が決まり、内部監査で回る先が決まり、審査の人日が決まる。適用範囲は、プロジェクトの総工数をほぼ一義的に規定します。

にもかかわらず、この決定は「とりあえず全社で」あるいは「まず開発部門だけで」といった直感で下されがちです。判断材料が整理されていないためです。実際に効く論点は2つしかありません。工数をどこまで許容できるかと、認証書に印字される範囲の文言が、それを求めている取引先の期待に応えられるか。この2つのバランスが適用範囲の設計です。

本記事は、適用範囲の決め方を実務の判断基準として整理します。規格全体の位置づけは ISMS（ISO/IEC 27001）とは、この決定が後続に与える影響は 箇条6 計画｜リスクアセスメントと情報セキュリティ目的 をあわせてご覧ください。

免責：本記事は一般的な情報提供です。規格の要求事項の解釈、認定・認証の取扱いは、ISO/IEC 27001（JIS Q 27001）の規格本文および認定機関・審査機関の公表資料が正本です。実際の対応はそれらに基づいて行ってください。

なぜここでつまずくのか

適用範囲の設計でつまずく原因は、ほぼ3つに集約されます。

1. 「範囲」という言葉が二重の意味を持っている

規格の文脈では、適用範囲はISMSという仕組みが及ぶ組織的・物理的・論理的な境界を指します。一方、社内で「対象範囲」と言うと、多くの人は「守るべき情報の範囲」を思い浮かべます。この2つは重なりますが同じではありません。ISMSの適用範囲外にある部門が、範囲内の情報を触っているという構造は普通に発生し、その扱いが設計の要になります。

2. 決めるべき軸が複数あることに気づいていない

適用範囲は「部門」の一次元で決まるものではありません。組織（どの部門・どの法人）／物理（どの拠点）／論理（どのシステム・ネットワーク）／業務（どのサービス・プロセス） の4軸で、それぞれ境界を引く必要があります。片方の軸だけで決めると、「本社は範囲内だがリモートワークの自宅はどうなるのか」「開発部門は範囲内だが、その部門が使っているSaaSの管理者権限は情報システム部が持っている」といった穴が後から露出します。

3. 取引先が何を見ているかを確認していない

ISMS認証を取得する動機の多くは取引条件です。ところが、取得後に発行される認証書には適用範囲の文言が印字され、認定機関の検索システムで公開されます。狭く取った範囲が、実際に取引先が見たい事業と一致していなければ、目的を達成できません。「認証は持っているが、当該サービスは範囲外だった」という指摘は、営業の現場で実際に起こります。

工数の見積りだけで範囲を決めようとすると、必ず3つ目を落とします。先に「誰に何を示すためか」を確定させてから、工数の議論に入るのが正しい順序です。

何を決めるのか

適用範囲として文書化すべきものを、4軸で整理します。

この4つを1つの文章にまとめたものが、認証書に載る適用範囲の文言になります。逆算すると、文言を先に書いてみるのが実務的に有効です。「この文章を取引先の調達担当に見せたとき、求めているものと一致していると読めるか」を確認してから、内側の詳細を詰める。

あわせて決めるのが、範囲外との接続点（インターフェース）の扱いです。規格は、適用範囲を決める際に、範囲内の活動と他の組織が実施する活動との間のインターフェースおよび依存関係を考慮するよう求めています。つまり、範囲を狭めること自体は認められるが、狭めた結果として生じる境界は説明できなければならないということです。

実務の手順

適用範囲の設計は、次の順序で進めると手戻りが少なくなります。

手順1：目的の確定（誰に何を示すのか）

認証取得の動機を、具体的な相手と場面に落とします。「医療機関の調達要件」「製薬企業のベンダー審査」「自治体の入札要件」——どれかによって、必要な範囲の広さが変わります。実際に提示を求められた文書やチェックシートがあれば、それを読むのが最短です。取引条件としてのISMSの位置づけは ISMSが取引条件になるケース で扱っています。

手順2：業務軸の起点を置く

「どのサービスを対象にするか」を最初に決めます。ヘルスケア企業であれば、機微な情報を扱う主力サービスが起点になるのが自然です。ここが認証書の文言の中核になります。

手順3：そのサービスを成立させている要素を洗い出す

起点となるサービスの提供に必要な、部門・拠点・システム・人を列挙します。ここで「実は関わっている」ものが多く出てきます。開発部門だけで完結していると思っていたサービスが、実際には営業が顧客データを受け取り、サポートが本番環境を参照し、情報システム部がアカウントを発行していた——という構造はよくあります。

手順4：含める／外すの線を引き、外したものは接続点として記述する

工数と目的のバランスで線を引きます。外す判断そのものは正当ですが、外した先との間で何が行き来するかを書く必要があります。

手順5：文言を書いて関係者に確認する

認証書に載る想定の文言を書き、営業部門と経営層に見せます。「この文言で取引先の要求に応えられるか」を確認する工程です。ここを飛ばすと、取得後に範囲拡大のための追加審査が必要になります。

手順6：適用範囲の文書化と承認

適用範囲は文書化した情報として維持する必要があります。単独の文書でも、ISMSマニュアルの一節でも構いません。

範囲の広さと工数・費用の関係は、おおむね次のように動きます。

実務上、ヘルスケアのBtoB事業者では「主力サービス＋関連する全部門」が落とし所になることが多いと考えられます。開発部門だけに絞ると、サポート時の本番データ参照や、営業が受け取る医療機関の情報が範囲外になり、取引先の関心事をカバーできないためです。少人数組織での進め方は 少人数組織のISMS もあわせてご覧ください。

よくある失敗

開発部門だけに絞ったが、取引先が見たいのはサービス全体だった

最も高くつく失敗です。範囲拡大には原則として追加の審査が必要になり、費用と期間が発生します。手順1と手順5を省いたときに起こります。

在宅勤務が範囲に入っていない

適用範囲の記述が「東京本社◯◯ビル5F」で止まっているのに、実際には従業者の多くが自宅から本番環境にアクセスしている。物理的境界の記述と実態が乖離している典型です。在宅勤務を含める旨を明記し、その環境に対する管理策（端末管理、ネットワーク、家族による覗き見の防止など）を設計するのが現実的な解です。

クラウドを「範囲外」と書いてしまう

IaaSやSaaSは自社が管理する設備ではないため、範囲外と書きたくなります。しかしクラウド上で自社サービスが動いている以上、その上のデータとアプリケーションは範囲内です。正しくは「クラウド事業者は委託先として管理し、責任共有モデルに基づいて自社の責任範囲を明記する」という扱いになります。責任分界の考え方は既存記事の AI電子カルテのセキュリティ設計｜責任共有モデル が参考になります。

接続点の記述がない

「経理部は範囲外」とだけ書かれていて、範囲内から経理部へ何が渡っているかが書かれていない。審査では「範囲を絞ったことによる情報の流出経路をどう管理しているか」が問われます。範囲の外に出ていく情報と、外から入ってくる情報を、それぞれ1行ずつでも書いておくことで多くの指摘を避けられます。

範囲を後から広げられる前提で設計している

範囲の拡大は、認証機関との調整と追加審査を伴います。「まず小さく取って、来年広げればいい」という計画は可能ですが、二重に費用がかかることを織り込んでおく必要があります。初回の構築で範囲を1段広く取るほうが、総額では安くなる場合があります。

組織の軸で雇用形態を落としている

正社員のみを念頭に規程を作り、業務委託の常駐者や派遣社員が対象から抜ける。実務では最も情報に近い位置にいることも多く、教育記録や秘密保持の取り決めが範囲内で確認できないと指摘の対象になります。適用範囲の組織軸には、雇用形態を明示して書くのが安全です。

ヘルスケア企業の例

医療機関向けSaaSを提供する企業

適用範囲の中核は、当該SaaSの企画・開発・運用・保守・サポートです。ここでサポートを外さないことが重要で、障害調査時に本番環境の患者データへアクセスする運用は現実に存在するため、サポート部門が範囲外だと最も機微な接点が管理下から外れます。

物理の軸では、開発拠点に加えて在宅勤務環境を明記するのが実態に即しています。論理の軸では、本番環境（クラウド）、ステージング、社内ネットワーク、そして顧客データが一時的に置かれる可能性のある場所（サポート用のファイル共有、チケット管理システム）まで含めて考えます。

PHR事業者

利用者本人から直接データを預かるため、アプリケーション、バックエンド、そして問い合わせ対応の窓口が範囲の中核になります。個人情報保護法上の取扱いと範囲の設計が連動するため、法務の観点を先に固めておくと手戻りがありません。詳細は PHR事業者のISMS｜個人情報保護法との関係 で扱います。

SaMDを開発する企業

ISMSの適用範囲と、QMS（ISO 13485）の適用範囲が並存します。両者は目的が異なるため範囲が一致する必要はありませんが、設計・開発プロセスは両方の対象になるのが通常です。文書体系を分けたまま接点を明示する設計が現実的です。SaMDとISMS・QMSの関係 をご覧ください。

治験・臨床研究システムを扱う企業

データの完全性と監査証跡が事業の核心であるため、本番環境だけでなくバックアップとログの保管先までを論理の軸に含める必要があります。範囲から外すと、完全性に関するリスク対応の大部分が範囲外の話になってしまいます。

医療機関を顧客に持つ場合の共通論点

顧客である医療機関は3省2ガイドラインへの対応義務を負っており、委託先に同等の管理水準を求める構造があります。つまり、医療機関が見たい範囲は「自院に提供されているサービスの全体」です。この目線を適用範囲の文言に反映しておくと、調達時のやり取りが短くなります。ガイドライン側の全体像は既存記事の 3省2ガイドラインとは、医療機関側の実務は 3省2ガイドライン対応の実務ステップ をご覧ください。ヘルスケア固有の設計論は ヘルスケア企業のISMS適用範囲設計 で詳述します。

まとめ

1. 適用範囲はプロジェクトの総工数をほぼ規定する決定であり、後戻りが最も高くつく。先に「誰に何を示すためか」を確定させる
2. 決めるべき軸は組織・物理・論理・業務の4つ。1軸だけで決めると後から穴が出る
3. 範囲を狭めること自体は正当だが、狭めた結果生じる接続点（インターフェース）は記述しなければならない
4. クラウドは「範囲外」ではない。委託先として管理し、責任共有モデルで自社側の責任を明記する
5. 在宅勤務と業務委託・派遣の扱いを明示する。実態と文言の乖離は指摘に直結する
6. 認証書に印字される文言を先に書いて営業・経営層に確認する。取得後の範囲拡大は追加審査を伴う

適用範囲が決まったら、次は範囲内の情報資産を洗い出す作業に移ります。情報資産の洗い出しと台帳の作り方、リスクアセスメントの進め方｜評価基準の設計、情報セキュリティ方針の書き方 へと続きます。

ポテックは、ヘルスケア領域に特化してISMS認証取得を支援しています。適用範囲の設計は、取引先が何を見ているかを知っているかどうかで結論が変わる領域です。支援内容と料金は ISMS認証取得支援サービス、個別のご相談は お問い合わせ から承ります。

参考・出典

• 情報マネジメントシステム認定センター（ISMS-AC）
• ISO/IEC 27001 Information security management systems｜ISO
• 日本産業標準調査会（JISC）
• 医療情報システムの安全管理に関するガイドライン｜厚生労働省
• 個人情報保護委員会

※規格の要求事項の解釈、認定および認証の取扱いは、規格本文および認定機関・審査機関の公表資料をご確認ください。改定や運用の見直しにより取扱いが変わる場合があります。