ISMS構築を始めると、最初に取りかかるのが箇条4です。そして、ここでつまずく組織がいちばん多い箇条でもあります。理由は単純で、「組織の状況を理解せよ」という要求が、そのままでは作業指示にならないからです。
しかも箇条4の判断は後戻りが効きません。ここで決める**適用範囲（スコープ）**が、審査工数を決め、審査費用を決め、その後3年間の運用負荷を決めます。範囲を広く取りすぎた組織は運用で息切れし、狭く取りすぎた組織は「その認証では当社の要求を満たさない」と取引先に言われます。
本記事は、箇条4の要求を実務の手順に翻訳したものです。何を洗い出し、何を文書にし、審査で何を聞かれるのかを、ヘルスケア企業の例とあわせて整理します。規格全体の見取り図は ISMS（ISO/IEC 27001）とは｜ヘルスケア企業のための完全ガイド をご覧ください。
免責：本記事は一般的な情報提供です。規格の要求事項の解釈、認定・認証の取扱いは、ISO/IEC 27001（JIS Q 27001）の規格本文および認定機関・審査機関の公表資料が正本です。実際の対応はそれらに基づいて行ってください。
この箇条が求めていること
箇条4は4つの部分からできています。規格の言葉を離れて、実務の問いに置き換えると次のようになります。
1. 組織と、その状況の理解
「自社の事業環境のうち、情報セキュリティの結果に影響しうるものは何か」を把握することです。外部の要因（取引先の要求、法規制、業界ガイドライン、技術動向、クラウド依存）と内部の要因（事業モデル、組織構造、人員、既存システム、企業文化）の両方を見ます。
ここで書くべきなのは一般論ではなく自社の事情です。「サイバー攻撃が増加している」は誰にでも書ける文章で、審査でも運用でも役に立ちません。「医療機関向けSaaSを提供しており、顧客の調達要件として3省2ガイドライン準拠の説明を求められる」なら、自社の状況です。
2. 利害関係者のニーズと期待の理解
自社のISMSに対して要求を持つ相手は誰か、その要求は何か、そのうちISMSで取り扱うものはどれか。顧客、患者・利用者、従業員、株主・投資家、規制当局、委託先、審査機関などが候補になります。
3. 適用範囲の決定
1と2を踏まえて、ISMSをどの組織・どの業務・どの拠点・どの情報システムに適用するかを決め、文書にします。範囲外とするものがある場合は、その境界とインターフェース（範囲内と範囲外の接点）を説明できる必要があります。
4. ISMSそのものの確立
決めた範囲で、マネジメントシステムを確立し、運用し、維持し、改善していくこと。ここは宣言に近い要求ですが、箇条5以降の全体を受ける前提になります。
ポイントは、1〜3が独立した作業ではなく一続きの論理だという点です。状況と利害関係者から範囲が導かれ、その範囲がリスクアセスメント（箇条6）の対象を決めます。この連鎖が切れていると、後の箇条すべてが根拠を失います。
実務で作る成果物
箇条4で実際に作るものは多くありません。ただし、どれも後の箇条から繰り返し参照されます。
| 成果物 | 目的 | 誰が承認するか |
|---|---|---|
| 外部・内部の課題一覧 | 事業環境のうちISMSの成果に影響するものを特定し、リスクアセスメントの入力にする | ISMS責任者（レビューはマネジメントレビューで） |
| 利害関係者とその要求事項の一覧 | 誰の何に応える仕組みなのかを定め、法規制・契約要求の抜けを防ぐ | ISMS責任者（法務・営業の確認を経る） |
| ISMS適用範囲定義書 | 認証の対象を明確にし、境界とインターフェースを説明する | トップマネジメント |
| 適用範囲の根拠メモ | なぜその範囲にしたか、除外した部分をなぜ除外したかを記録する | ISMS責任者 |
| 組織図・拠点一覧・システム構成図 | 範囲の物理的・論理的な輪郭を具体的に示す | ISMS責任者 |
適用範囲定義書は、認証書に印字される文言の元になります。「登記上の会社名＋対象となる事業・業務＋拠点」 の組み合わせで書くのが一般的で、ここに書いた文言がそのまま取引先の目に触れます。営業部門を巻き込んで決めるべき理由がここにあります。
課題一覧と利害関係者一覧は、表形式で15〜30行程度に収まるのが実務的な目安です。数百行の網羅リストを作っても、次のマネジメントレビューで更新されずに死蔵されます。
つまずきやすい点
範囲を「全社」にすれば安全だと考えてしまう
全社適用は選択肢のひとつであって、正解ではありません。全社にすれば、すべての拠点・すべての部門・すべての業務が審査対象になり、審査工数が増え、内部監査の負荷も増えます。特にバックオフィスしかない拠点や、情報資産をほとんど扱わない部門まで含めると、運用の手間だけが積み上がります。
逆に、取引先が見ているのは「自社が委託する業務が範囲に入っているか」だけです。そこが確実に入っていれば、全社である必要はありません。
範囲を狭くしすぎて説明がつかなくなる
「開発部門のみ」のような切り方をすると、境界の説明が難しくなります。人事が管理する入退社手続き、情報システム部門が管理するアカウント、総務が管理する入退室。これらは開発部門の情報セキュリティに直結しているのに範囲外、という構造は審査で必ず問われます。業務プロセスで切るのではなく、情報の流れで切ると整合が取りやすくなります。
課題一覧が一般論の羅列になる
前述のとおりです。自社固有の事情が1行も書かれていない課題一覧は、審査員にとって「箇条4を形式的に埋めただけ」のサインになります。
利害関係者の要求事項に法規制が入っていない
個人情報保護法、医療法、薬機法、電子帳簿保存法、業界ガイドライン。自社に適用される法規制・ガイドラインを利害関係者の要求事項として拾っておかないと、箇条6のリスクアセスメントでも箇条8の運用でも抜けます。法規制の一覧は箇条4で作り、以降はそれをメンテナンスする形が効率的です。
クラウド・委託先を範囲外と勘違いする
自社が使うクラウドサービスや委託先は、ISMSの適用範囲（組織の境界）の外にありますが、そこで取り扱われる情報は自社の責任範囲内です。境界とインターフェースの説明、そして委託先管理（附属書A.5の組織的管理策）でカバーします。この整理は 外部委託先管理｜チェックシートと契約条項 と 責任分界点の決め方｜医療機関と事業者 で扱っています。
審査で見られること
1次審査（文書審査）では、箇条4の成果物がまとまって確認されます。典型的な確認の観点は次のとおりです。
| 観点 | 審査で問われること |
|---|---|
| 範囲の明確さ | 何が範囲内で何が範囲外か、第三者が読んで判別できるか |
| 境界の説明 | 範囲外の組織・システムとのインターフェースをどう管理しているか |
| 根拠の一貫性 | 課題・利害関係者の分析結果と、決定した範囲がつながっているか |
| 除外の妥当性 | 除外した部分について、除外理由が合理的に説明できるか |
| 維持の仕組み | 課題・利害関係者の一覧を、いつ・誰が見直す取り決めになっているか |
| 実態との一致 | 文書上の範囲と、実際の組織・拠点・システムが一致しているか |
もっとも多い指摘は**「実態との一致」**です。適用範囲定義書に書かれていない拠点で業務が行われていた、組織改編後に文書が更新されていなかった、といったケースです。範囲は一度決めたら終わりではなく、組織変更・新規事業・拠点移転のたびに見直す対象だと位置づけておく必要があります。
1次審査の全体像は 1次審査（文書審査）で見られること にまとめています。
ヘルスケア企業での具体例
医療機関向けSaaSを提供する企業の場合
この業態では、範囲を「サービスの企画・開発・運用・保守」とし、そこに関わる全拠点を含める形が自然です。理由は、顧客である医療機関が委託しているのがまさにその業務だからです。
利害関係者の要求事項には、次のような固有項目が並びます。
- 顧客（医療機関）：3省2ガイドラインが求める安全管理措置への対応、責任分界の明示、再委託先の開示
- 患者・利用者：医療情報が目的外に利用されないこと
- 規制当局：個人情報保護法上の要配慮個人情報としての取扱い
- クラウド事業者：責任共有モデルのうち利用者側に残る責任の履行
3省2ガイドラインを利害関係者の要求事項として明示的に拾っておくと、後続の箇条での対応が一貫します。詳しくは ISMS文書と3省2ガイドライン対応文書の統合 と、既存記事の 3省2ガイドラインとは をご覧ください。
PHR事業者の場合
PHRは利用者本人から直接データを預かる構造です。利害関係者の筆頭は利用者本人であり、要求事項は「同意した範囲を超えて使われないこと」「いつでも自分のデータを確認・削除できること」になります。範囲の設計では、アプリ・バックエンド・カスタマーサポートを一体で含めるのが実務的です。サポート部門だけ範囲外にすると、問い合わせ対応で個人データに触れる導線が説明できなくなります。
治験システムを扱う企業の場合
利害関係者に治験依頼者（製薬企業）と規制当局が加わり、要求事項にER/ES指針やデータインテグリティの観点が入ります。範囲には監査証跡を保持するシステムと、その運用を担う部門を必ず含めます。
SaMDを開発する企業の場合
QMS（ISO 13485）の適用範囲が別に存在するため、ISMSの範囲とQMSの範囲の関係を最初に整理しておく必要があります。二つの範囲が食い違うと、設計管理の記録がどちらの文書体系に属するのか曖昧になります。
ヘルスケア固有の範囲設計は ヘルスケア企業のISMS適用範囲設計、範囲決定の一般的な手順は ISMS適用範囲の決め方 で詳しく扱っています。
まとめ
- 箇条4は「状況の理解 → 利害関係者の特定 → 適用範囲の決定」という一続きの論理であり、途中が切れると後続の箇条すべてが根拠を失う
- 成果物は課題一覧・利害関係者一覧・適用範囲定義書の3点が核。適用範囲定義書はトップマネジメントが承認し、認証書の文言の元になる
- 範囲は広ければ安全ではない。取引先が委託する業務が確実に入っているかが判断基準
- 課題一覧に一般論しか書かれていないのは典型的な形式対応。自社固有の事情を書く
- 審査でもっとも指摘されるのは文書上の範囲と実態のずれ。組織変更のたびに見直す運用を決めておく
- ヘルスケアでは、3省2ガイドラインや規制当局の要求を利害関係者の要求事項として明示的に拾うと、以降の箇条が一貫する
箇条4で決めた範囲は、次の 箇条5 リーダーシップ｜トップマネジメントの責任 で方針と役割に落ち、箇条6 計画｜リスクアセスメントと情報セキュリティ目的 でリスクアセスメントの対象になります。そこから 箇条7 支援｜力量・認識・文書化した情報、箇条8 運用、箇条9 パフォーマンス評価、箇条10 改善 へと続きます。
ポテックは、ヘルスケア領域に特化してISMS認証取得を支援しています。適用範囲の設計は取引先の要求と運用負荷の両方を見て決める必要があるため、初期段階からご相談いただくと手戻りを減らせます。支援内容と料金は ISMS認証取得支援サービス、個別のご相談は お問い合わせ から承ります。
参考・出典
- 情報マネジメントシステム認定センター（ISMS-AC）
- ISO/IEC 27001 Information security management systems｜ISO
- 日本産業標準調査会（JISC）
- 医療情報システムの安全管理に関するガイドライン｜厚生労働省
※規格の要求事項の解釈、認定および認証の取扱いは、規格本文および認定機関・審査機関の公表資料をご確認ください。改定や運用の見直しにより取扱いが変わる場合があります。