ISO27001の適用範囲（4.3・4.4）｜線を引いた瞬間から、範囲は実態とずれ始める

連載「ISMS審査員・監査への道」第5回

ISO/IEC 27001の箇条4は、4.3で「線を引く」段階に入ります。ISMSという仕組みを、組織のどこまでに効かせるのか。その線引きの話です。

前回の最後に「今回決めた課題と利害関係者が、そのまま境界線の材料になります」と書きました。読み進めてみると、本当にそのとおりの作りになっていました。4.1と4.2に手応えを感じなかったのは、あれが4.3のための材料集めだったからだと思っています。

そして今回は、規格を読むより現場を思い出すほうが時間がかかりました。線を引く話は、引いたあとに何が起きるかまで考えないと意味がないからです。

第1回：ISO/IEC 27001の全体像｜規格を知らないと、ベンダーとの会議で何も言えなくなる

第2回：ISMS認証制度と審査の仕組み｜審査する側も、別の機関から審査されている

第3回：ISMS用語集（箇条3）｜規格の言葉と現場の言葉は、たいてい一致しない

第4回：ISO27001の組織の状況（4.1・4.2）｜「誰の要求で決まったのか」は現場に降りてこない

---

適用範囲（スコープ）とは——ひとことで言うと

ISMSという仕組みを、組織のどこまでに効かせるかを決めた線のことです。

誤解されやすいのですが、組織全体である必要はありません。特定の事業所だけ、特定のサービスを担う部門だけ、という取り方が認められています。だから認証を取った組織どうしを並べても、実際に守られている範囲はまったく違う、ということが起こります。

4.3 適用範囲の決定——考える材料は3つある

4.3が求めているのは、ISMSの境界および適用可能性を決定し、適用範囲を確立することです。そのとき考慮せよと指定されている材料が3つあります。

1つ目が、4.1で決めた外部および内部の課題。2つ目が、4.2で決めた利害関係者の要求事項。そして3つ目が、自分の組織が行う活動と他の組織が行う活動との間のインタフェース（接点）および依存関係です。

正直、3つ目がいちばん厄介だと感じました。外部に委託しているもの、他組織のシステムと繋がっているもの、自分たちだけでは完結しない業務。ここを洗い出さないと、線をどこに引けるのかが決まりません。

もう1つ、前回との大きな違いがあります。4.3には文書化の要求がある、という点です。

前回書いたとおり、4.1と4.2に文書化の明示的な要求はありませんでした。4.3は違って、適用範囲を文書化した情報として利用可能な状態にすることが求められます。箇条4のなかで、はっきり文書を要求されるのはここだけ、という理解でいます。

4.4 情報セキュリティマネジメントシステム——決めた範囲で回す、という宣言

4.4は驚くほど短い条項です。この規格の要求事項に従って、ISMSを確立し、実施し、維持し、継続的に改善しなければならない。書かれているのはそれだけになります。

短いわりに、置かれている位置には意味があると思っています。4.3で線を引き、4.4でその中を回すと宣言する。2つはセットで読むほうが素直に入ってきます。

現行の条文には「必要なプロセス及びそれらの相互作用を含む」という趣旨の語句が入っている、と理解しています。範囲を決めるだけでなく、その中で何がどう繋がって動くのかまで示せ、という要求に読める部分です。

ただしここは、手元の解説書の新旧対応表には項目として立っていませんでした。表に立てるほどの変更ではない、という著者の判断なのだろうと受け取っています。実務上の重みは、条文の文言ほど大きくないのかもしれません。

	4.3	4.4
求めていること	境界と適用可能性を決め、適用範囲を確立する	決めた範囲でISMSを確立・実施・維持・改善する
問いの形	どこまでを対象にするか	その中で何をどう回すか
考慮する材料	4.1の課題／4.2の要求事項／他組織とのインタフェースと依存関係	—
文書化の明示的な要求	あり（適用範囲を利用可能な状態にする）	なし
前の条項とのつながり	4.1・4.2の成果物を材料として使う	4.3で決めた範囲を前提にする

範囲は狭いほうが有利か、広いほうが有利か

どちらにも言い分があります。

狭く取れば、運用する対象が減ります。回す手間も、審査で見られる範囲も小さくなる。取得を急ぐ組織が一部門から始めるのは、合理的な判断だと思います。

ただし狭くするほど、3つ目の材料が重くなります。範囲の外に置いたものと、中に残したものが、どこで繋がっているのか。その境目をどう守るのか。切り離したつもりのものが実は繋がっていた、という状態がいちばん説明に困ります。

広く取れば、境目の説明は減るでしょう。今度は全部を同じ水準で回すことになるので、手が回らない部分がそのまま弱点として残ります。

第2回では、認証書の適用範囲を読む側の話として書きました。委託先が認証を持っていても、頼もうとしている業務が範囲外なら意味がない、という内容です。今回はそれを決める側から見ていることになります。読む側で感じた「範囲の欄が肝心だ」という感覚は、決める側でもそのまま当てはまりそうです。

適用範囲と適用宣言書は、別のもの

名前が似ていて混同しやすい2つなので、ここで整理しておきます。

適用範囲（スコープ）は4.3で決めるもので、ISMSをどこまでに効かせるかの線です。適用宣言書（SoA）は6.1.3で作るもので、附属書Aの管理策のうちどれを適用するかを示した文書になります。

対象が違います。前者は組織や場所や業務の範囲、後者は管理策の取捨選択。用語の意味を確認したいときはISMS用語集に戻ってください。

［現場］線は組織図に書いてある。見えるのは何かが起きたとき

ここから現場の話です。

筆者は自治体の情報システム部門に長く常駐しています。担当しているのは内部情報系と、ネットワークやサーバの基盤運用です。範囲という言葉で真っ先に思い浮かぶのは、庁舎そのものの扱いでした。

情報を扱う場所を守るのは、ISMSでいえば物理的な管理策の領域です。ところが庁舎の維持管理は、情報部門ではなく別の部門が所管しています。仮にその建物を適用範囲に含めたとすると、守るべき対象は範囲の中に入るのに、実際に手を動かす部門は範囲の外にいる、という状態になります。

これがまさに4.3の3つ目の材料だと気づきました。インタフェースと依存関係は、他社との契約だけの話ではありません。同じ組織の中にも、所管が分かれている以上は必ずあります。

似た構造は、決裁の流れにもあります。承認するのは職員で、実際にシステムへ手を入れるのは常駐している側です。監査に伴って書類の提出を求められたときも、窓口は職員側にありました。指示と実装、対外的な説明と内部の作業が、それぞれ別の人のところにあります。

そして正直に書くと、こうした線を日常的に意識してはいません。線が見えるのは、何かが起きたときです。障害の切り分けで「これはどこの持ち物か」を確かめる場面、依頼を受けて「それはうちでは決められない」と返す場面。線は組織図に書いてあるのに、実感として現れるのは事故と依頼の経路のほうでした。

［現場］範囲は決めた瞬間から古くなる

もう1つ、線を引いたあとの話を書きます。

筆者は常駐先で、日々の作業内容を11年ぶん記録してきました。それを自分で数え直したことがあります。1つの自治体の、1担当者の記録にすぎませんが、いくつか傾向が見えました。

分かったことの1つが、直近の年度で物理と回線に関する作業が増えていたことです。しかも内訳の多くが、新しく作る仕事ではなく、使わなくなった回線や設備を畳む仕事でした。

撤去は、台帳と現物が食い違いやすい場面です。作るときは手順が整っています。予算があり、検収があり、記録が残る。ところが畳むときは、現物がなくなったあとで台帳の行が残ります。情報資産の目録を求める管理策が問われるのは、たいていこちら側だと感じています。

台帳そのものの管理にも癖があります。筆者の関わってきた現場では、台帳を年度で切らずに通年で使い続けます。過去分は古いファイルとして残す運用です。使い勝手はよいのですが、どれが最新かを外から見て判断しにくい形ではあります。

もう1つ、範囲がずれる典型を数字で見ました。クラウドのIDやSaaSに関する作業が、ある年度まで実質ゼロだったのに、翌年度から急に増えていたのです。前の年度にメールのなりすまし対策が跳ねていたので、送信ドメインの認証を整えてからID基盤を外へ寄せた、という順番だったのだと思います。

自治体のネットワークは、外部と切り離す前提で設計されてきました。その考え方はLGWANと三層分離の記事で書いたとおりです。ところが実際には、ID基盤のあたりから静かに溶け始めています。分離を前提に書かれた規程が、実態に追いつかなくなる。適用範囲も同じ壊れ方をするはずです。

手順が場所によって通らない、という問題もあります。人の異動に伴うアカウントの処理は、11年を通してずっと作業量の首位でした。しかも職員の区分によって処理の系統が分かれます。同じ「異動対応」という言葉でも、中身が一本道ではありません。本庁と出先をまとめて範囲に入れるなら、この差をどう扱うかは決めておく必要があります。

だから範囲は、決めた瞬間から古くなっていくものだと考えています。4.3を一度きりの作業として読むと、たぶん足をすくわれます。

よくある落とし穴／審査で指摘されやすい点

現場の話とつなげて、指摘されやすそうな点を整理します。

• 適用範囲の文書が、組織改編や業務の追加のあとで更新されていない。範囲は組織のほうが動けばずれます
• 範囲の外に置いたものとの境目が書かれておらず、切り離せている根拠を示せない。3つ目の材料が抜けた状態です
• 委託先や外部サービスが、範囲の中とも外とも読めない書き方になっている。認証書を読む相手が判断できません
• 資産の目録に、撤去したはずのものが残っている。作る側の手順に比べて、畳む側の手順は薄くなりがちです
• 同じ手順が通らない拠点や区分があるのに、範囲の中で一律に扱われている。運用の差は、範囲に含めた時点で説明の対象になります
• 適用範囲と適用宣言書が混同されている。前者は4.3、後者は6.1.3で、決めるものが違います

いずれも「必ず指摘される」という話ではありません。ただ、聞かれたときに答えにくい形ではあります。

まとめ

• 4.3は境界と適用可能性を決めることを求めている。組織全体でなくても構わない
• 考慮する材料は3つ。4.1の課題、4.2の要求事項、そして他組織とのインタフェースと依存関係
• 箇条4のなかで、文書化がはっきり要求されるのは4.3
• 4.4は、決めた範囲でISMSを回すという宣言。4.3とセットで読むほうが分かりやすい
• 範囲を狭くすると運用は軽くなるが、境目の説明が重くなる。広くすればその逆になる
• 境目は組織図より、障害対応と依頼の経路に現れる。範囲は決めた瞬間から実態とずれ始める

次回は5.1〜5.3、リーダーシップと情報セキュリティ方針を扱います。線を引いた組織が、それを誰の責任で回すのかという話になります。

用語の意味を確認したいときはISMS用語集に戻ってください。連載の入口は第1回です。