▼ 目次
1. はじめに
1.1. 記事の目的と想定読者
本記事では、ISO27001を導入する際に必ず考える「適用範囲（スコープ）」について、決め方の手順やよくある失敗例を中心に解説します。
想定読者:
これからISMS（情報セキュリティマネジメントシステム）を導入・認証取得しようとしている企業の担当者
「適用範囲をどう設定すればいいか分からない…」と悩む初心者
ISO27001審査で「範囲設定に不備がある」と指摘された方
1.2. なぜ“適用範囲”がISO27001で重要なのか
ISO27001では、組織が守るべき情報資産や業務範囲を明確にし、その範囲内でセキュリティを管理しなければなりません。
適用範囲（スコープ）を曖昧にすると、リスク管理が抜け落ちたり、無駄なコストがかかったりして、外部審査でも不適合を指摘されやすい。
コンサル視点: 適用範囲の設定は「ISMSの土台」。ここをしっかり固めると、導入後の運用も非常にスムーズになります。
1.3. 本記事で学べること（決め方の手順、注意点、成功事例など）
手順: 具体的な段階を踏んで適用範囲を設定する方法
やりがちなミス: 範囲を狭く/広くしすぎる失敗例と対策
実務アプローチ: リスクベース・サービス単位・段階的導入など、効果的な決め方を例示
成功事例: 他社が適用範囲を上手に設定して審査を効率化した実例
2. ISO27001の“適用範囲”とは？基本概要
2.1. 適用範囲の定義：何を守るためのシステムか
適用範囲（Scope）: 「情報セキュリティマネジメントシステムをどの組織・拠点・業務に適用するか」を明確に示すもの。
例として、**「本社のIT部門のみ」や「会社全体のすべての事業」**など、保護したい情報資産・部門・拠点を含む。
2.2. 情報セキュリティマネジメントシステム（ISMS）との関係
ISMSは、組織が情報資産を守るための仕組み（PDCAサイクル）。
適用範囲があやふやだと、「どの資産が対象？」「どの部門に監査を行うの？」が曖昧→ ISMSがうまく機能しない。
コンサル経験: 適用範囲を明確化するだけで、関係者が「うちが対象なのね」と認識し責任意識が芽生える。
2.3. 適用宣言書（SOA）との違いと関連性
適用宣言書（Statement of Applicability, SOA）: 附属書Aの管理策に対して「適用する」「非適用」を宣言する文書。
違い: SOAは管理策の選択を示す文書。適用範囲はその前提として、どの部門や施設がISMS対象かを示す。
関連: 「どの範囲内で、どの管理策を適用するか」をセットで考え、審査員は両方を確認する。
3. 適用範囲を決めるメリット・デメリット
3.1. メリット：リスク管理の明確化、審査コスト削減、運用効率化
リスク管理が明確化: 「ここまでが対象」という線引きがはっきりするため、不要な資産も無理に管理しなくて済む。
審査コスト削減: 組織全体を一度にやるより、範囲を絞れば監査対象が減り、審査費用や工数を抑えられる。
運用効率化: 小さな範囲でノウハウを積み、成功事例をつくってから徐々に拡大する企業も多い。
3.2. デメリット：狭すぎると漏れ、広すぎると負担増→ “ちょうどよい範囲”の考え方
範囲が狭すぎ: 他部門での情報漏えいリスクが放置され、実際は守れていない領域が多い
範囲が広すぎ: 組織全体を含めると、文書・監査対象が膨大になり費用と工数が爆発
コンサル視点: 「中心となる事業や重要拠点」をまずスコープに入れて、必要に応じて拡大する段階的アプローチがベスト。
3.3. 他社事例：明確な範囲設定で外部審査がスムーズになった企業例
事例: IT企業A社が主要クラウドサービスとそれを運営する部門だけを先に含み、審査対象を絞った→ ステージ2審査が短時間で済んだ＋合格率向上。
効果: 後から別拠点を追加し、2年目に全社的スコープへ拡大。段階的導入で混乱を回避。
4. 適用範囲設定の基本ステップ
4.1. ステップ1：保護すべき情報資産の洗い出し
手法: 部門長ヒアリング、情報資産台帳作成、リスクアセスメント
具体例: サーバー、アプリ、紙資料、クラウドシステムなど、何を守りたいかを一覧化
アドバイス: 繰り返し検討すると新たな資産や外注先が判明する。棚卸しを丁寧にやると範囲決定が楽
4.2. ステップ2：組織構造・拠点・サービス範囲の確認
組織図: どの部署がどの情報を持っているかを把握。
拠点: 国内拠点だけ？ 海外支店も含む？
サービス: 会社内に複数の事業がある場合、どのサービスを先に守るか優先度を整理
4.3. ステップ3：リスクアセスメントとの連動（優先度決定）
リスクアセスメント: 各情報資産のリスク（可能性×影響度）を評価→ 高リスク領域を先に含む
効果: メイン事業や顧客情報を扱う部門が最優先対象になる
コンサル談: ここで「何を捨てるか」も大事。低リスク領域は最初のスコープから外しても良いか検討
4.4. ステップ4：社内ステークホルダーへのヒアリングと合意形成
利害調整: 範囲に含まれる部署は追加業務や監査が発生→ 反発が出ないよう、メリットを説明
事例: ある企業で営業部を先に含もうとしたが、営業が繁忙期で断念→ スケジュールをずらして合意
4.5. ステップ5：最終承認と文書化（範囲宣言）
最終承認: 経営層やISMS委員会で了承を得る。
文書化: 「適用範囲ドキュメント」に拠点・部署・情報資産などを明確に記述→ 内部監査や外部審査で確認される
5. よくあるやりがちなミス
5.1. 広げすぎて運用困難：全社規模で始めたが人手や予算が足りない
原因: 「どうせなら全部含めたほうがいい」と考えすぎる
結果: 文書整備や監査範囲が膨大に→ 現場が追いつかず形骸化
対策: リスクの高い領域を最初に適用範囲にし、段階的に拡大
5.2. 狭めすぎてリスクをカバーできない：一部部署だけ入れたが、連携部門のインシデントを見逃す
原因: 重要情報が実は他部署でも扱われていた
対策: 情報資産のフローを確認、見落としがないかリスク評価時に再チェック
5.3. 適用範囲に外部委託先を含めず、審査時に不適合指摘
例: システム運用を外部委託しているのに自社範囲で完結していると想定→ 実は大きなリスクが外部にあった
解決: 委託先をスコープに加える or 委託先と契約上でセキュリティ責任を明確化
5.4. 文書と現場運用がずれてしまい、実際には守れていない
失敗例: 適用範囲文書では「海外拠点も含む」と書いたが、海外拠点はISMSルールを未周知で全く運用されていなかった
対策: 範囲設定後、必ず周知と教育を実施し、内部監査で実態を確認
6. リスクベースで考える適用範囲の決め方
6.1. 重要度の高い事業やサービスから検討：リスク評価の観点
方法: 会社の売上・ブランドイメージに影響が大きい部分を優先
理由: ここが情報漏えいしたら大ダメージ→ 最小限のコストでリスク減少が見込める
6.2. クリティカルなデータやシステムを先に含めるメリット
例: 生産管理システム、顧客データベースなど
メリット: コア部分だけ守れば、主要なリスクをコントロールできる→ 審査範囲も小さくコスト低
6.3. “段階的拡張”アプローチ：最初はコア領域→ 実績を積んで徐々に範囲拡大
失敗防止: いきなり全社対応をせず、コア領域で成功→ ノウハウを横展開
事例: 製造業B社が本社のIT部門だけ初年度で認証取得→ 2年目に工場や海外拠点を追加認証
7. 実務に役立つアプローチ例
7.1. サービス単位での範囲設定（例：クラウドサービスだけ先に導入）
事例: SI企業が、自社提供クラウドサービスをISO27001範囲に→ 顧客に安全性をアピール→ 取引増
利点: サービス利用顧客のニーズに合わせスピード取得が可能
7.2. 部門・拠点単位での範囲設定（例：本社部門のみ最初に導入）
メリット: 本社集中の機能が多いなら効果的。外拠点を後から追加
コンサル経験: 分散組織でいきなり全拠点をスコープに入れると、調整に1年以上かかることも…
7.3. システム・情報資産を中心にした“システムスコープ”
方法: ERPや基幹システム、顧客DBなど特定のシステム群を対象に→ それを扱う部署だけ含む
注意: システム間の連携や外部委託部分を見落とさないようにリスク評価を丁寧に
7.4. コンサル視点：自社のビジネスモデルやリスク優先度を踏まえ、最適案を選ぶ
提案: まず「どこが一番リスク高いか？」→ スピード重視でそこを先に抑え、徐々に拡大
ポイント: 会社の成長計画や顧客要件に合わせて拡張プランを作ると審査や内部監査が計画的に進む
8. 適用範囲を文書化・宣言する際の注意点
8.1. 適用範囲文書（Scope Document）の作り方
項目: 範囲に含まれる拠点・部門名、対象業務やシステム名、対象外の理由（ある場合）
実務例: 「本社（東京都xx区）における〇〇事業、および△△システムを対象」と明記
8.2. ISO27001審査でよく見られるポイント（組織境界、拠点、サービス範囲）
審査員は「その範囲外の部門が、実は影響していないか？」を注目
例: 総務部が全社PC管理を担うのに、総務部をスコープ外にしていないか？
8.3. 範囲変更時のフロー：組織改編や新サービス開始で範囲拡大・縮小する場合
策定: どの部署が変更を提案し、誰が承認する？と手順を決めておく
リスク評価: 新たなサービス・拠点を範囲に含む際にはリスクアセスメントを再実施
9. 外部審査と適用範囲：よくある質問Q&A
9.1. 「範囲を狭くすれば審査負荷が減る？逆に問題はない？」
回答: 負荷は減るが、重要リスクをカバーしなければ本末転倒。顧客から不十分と見なされる恐れ。
コンサル目線: 最小限かつ主要リスクをカバーするバランスが大事
9.2. 「取引先が全社スコープを求めてくる場合、どう対応する？」
回答: 取引先の要件に応えられるよう、全社導入が必要になるかも。あるいは根拠を説明して説得。
例: 「まず主要事業でISMS導入し、1年後全社拡張」という段階的プランを提示
9.3. 「クラウドや海外拠点を含めると審査費用は大幅に上がる？」
回答: 拠点数、地理的範囲が広がると審査員の工数が増→ 費用も増。
対策: 段階的に拡大するか、リスク評価で「海外拠点のリスクが大きいなら先行適用」など選択
9.4. 「内部監査との関係は？範囲が複雑だと監査も難しくなる？」
回答: そう。内部監査員が全員理解できるよう、範囲をあいまいにしないことが大事。
注意: 部分的に適用していると、監査計画がややこしくなる場合もある
10. 適用範囲設定後の運用と見直し
10.1. 定期的な内部監査・マネジメントレビューで範囲が適切か確認
内部監査: 範囲内の部署で運用が守られているかチェック。範囲外リスクが生じていないかも確認
マネジメントレビュー: 経営層が範囲の拡大・縮小や追加対策を判断
10.2. 新規事業・システム導入での追加リスク対応
事例: 新たにクラウドシステムを採用→ 適用範囲に含めるか？ 担当部署を明記するか？
コンサル談: 範囲変更時には外部審査にも報告し、次回のサーベイランスで確認されるケースが多い
10.3. コンサル経験：範囲見直しを怠ってトラブルが起きた企業例
例: 事業統合で新子会社が加わったのに、範囲に入れず管理が抜けた→ インシデント発生し大きな損害
結論: 組織変化の都度、範囲を再評価し、文書修正して社内共有する仕組みが必須
11. 成功事例：適用範囲を上手に設定してISMS導入を効率化
11.1. IT企業A社：まずは主要サービスだけ含めて1年後に全社拡大 → スムーズな審査合格
背景: 一気に全社でやると混乱しそう→ コアサービス部門だけを最初にスコープ
結果: 半年でステージ1・2審査をクリア、1年後に範囲拡大して2年目のサーベイランスも無事通過
効果: コア部門でノウハウを得てから全社展開、リスク管理レベルを段階的に高めた
11.2. 製造業B社：本社と研究所を対象に絞り、海外工場は段階的に追加 → リスク管理コスト最適化
背景: 海外工場が多数あり、一度に全拠点を含むと審査費用が高額＋調整困難
実施: まず本社（企画・管理部門）と研究所（機密データ）を範囲→ 成果を確認後、工場を2拠点ずつ順次追加
結果: 過剰な負担なく、3年ほどかけて全社的にISMSを定着
11.3. コンサル実感：焦らず範囲を適切に絞ると、担当者の負担が軽減し品質も高まる
まとめ: 適用範囲を絞る→ 運用と監査がしやすい→ ミスが減る→ 自信を持って外部審査に臨める
12. まとめ：ISO27001適用範囲とは？決め方の手順とやりがちなミスをわかりやすく解説
12.1. 記事の総括：適切な範囲はISMS成功のカギ
ポイント: 何を守りたいか？ どこがリスク高いか？ → リスク評価で優先度を決める
大きすぎ: コスト・負荷増、形骸化リスク
小さすぎ: 重要領域を守れず意味が薄い
12.2. 読者への行動提案：リスクベースで段階導入を検討し、最適な範囲を設定
行動例: コア事業だけ含む or 本社だけ含む or サービス単位で取得→ 実績を積んで拡大
内部合意: 経営層や各部門と話し合い、みんなが納得する形でスコープを決める
12.3. 最後のメッセージ：運用後の定期見直しこそ、長期的なリスク低減に不可欠
範囲変更: 新規事業、組織改編があれば見直す
適用範囲の適正化: 外部審査だけでなく、日々の業務の安全性を高める基本戦略
おわりに
ISO27001の適用範囲は、ISMS導入の要と言っても過言ではありません。
範囲が曖昧だとリスク管理が不十分になり、外部審査や運用でトラブルが起こりやすい。
段階的に設定すれば、コア領域を確実に守り、後から拡大も容易に。
本記事で紹介した決め方のステップややりがちなミス、成功事例を参考に、ぜひご自身の企業に合った形で最適な適用範囲を設定し、ISO27001の導入をスムーズに進めてみてください。
この記事の監修者情報
金光壮太 (ISOコンサルタント)
大手商社にて営業を経験した後、ISOコンサルティングに従事。ISO9001、14001、27001を中心に、各業界の課題や特性に応じたシステム構築や運用支援を行い、企業の業務効率化や信頼性向上に貢献。製造業や建設業など、多岐にわたる業界での豊富な経験を活かし、お客様のニーズに応じた柔軟なソリューションの提案を得意としている
Comments