ISMSの適用範囲と責任体制の決め方（4.3・5.3）｜体制図に載る名前は、規格の名前ではない

ISMSの構築で最初に作る文書は2つあります。どこまでを対象にするかを書いた範囲の文書と、誰が何を受け持つかを書いた表です。

第5回と第6回では、4.3と5.3が何を求めているかを読みました。今回は実務編として、それを実際の文書に落とすときの考え方を整理します。前回の6ステップでいえば、(1)にあたる回です。

---

適用範囲と責任体制を決めるとは——ひとことで言うと

ISMSを効かせる線を引き、その線の中の仕事に持ち主を付ける作業です。

範囲が決まらないと、どの部門に役を割り当てるかが決まりません。逆に、役を引き受ける部門がいない場所を範囲に入れても、回す人がいない。別の条項ですが、実務では一度に決めることになります。

4.3 範囲の文書——規格は項目までは決めていない

4.3が求めるのは、ISMSの境界と適用可能性を決め、その範囲を文書化した情報として利用できる状態にすることです。決めるときには、4.1の課題、4.2の要求事項、自組織と他の組織の活動との接点と依存関係を考慮します。どんな項目で文書にするかまでは、規格は決めていません。

実務では、組織・場所・業務・資産・ネットワークの5つで書く形がよく使われます。教科書もこの立て方でした。下の表は、それぞれの材料をどこから持ってくるか、境目で何を問われるかの列を足して、筆者が組み直したものです。

項目	書くこと	材料の出どころ（例）	境目で問われること
組織	対象の組織名。一部だけなら部門名まで	組織図、事務分掌	範囲の外に置いた部門と、どこでつながっているか
場所	対象の拠点すべて。図面も添える	施設の台帳、図面	共用部分や、他の組織と同じ建物にいる場合の扱い
業務	原則、その場所で行う業務すべて	業務の一覧	外した業務との切れ目を示せるか
資産	対象の業務で扱う資産の概要	資産の台帳（A.5.9）	台帳と範囲の文書が食い違っていないか
ネットワーク	構成図	設計書、構成図	外とつながる点。4.3 c)の接点と依存関係

右端の列がいちばん大事だと考えています。範囲の文書は、中に何が入るかより、外との切れ目をどう書いたかで読まれるからです。

詳しく書いた範囲の文書は、機微な情報を含みやすい

5つの項目を丁寧に埋めると、拠点の一覧、フロアの図、ネットワークの構成図がそろいます。攻撃する側から見れば、ほぼそのまま地図になり得ます。

一方で、範囲は外にも出ていくものです。認証を取れば、認証書には認証範囲が記載されます。ISMS-ACの認証取得組織の検索でも、組織名や部門名と並んで「登録範囲」が検索項目になっていました。外に出るのは短い文で、図面は付きません。

だから、外に出す範囲の記述と、内部で使う範囲の文書は分けて持つのが素直だと考えています。内部の文書に機微な情報が含まれるなら、情報の分類（A.5.12）やアクセス制御（A.5.15）の考え方に沿って扱う。規格が範囲の文書を名指しで求めているわけではありませんが、範囲を決める文書そのものが守る対象になり得るわけです。

正直、ここは書いていて少し可笑しくなりました。このブログでは、常駐先の構成や所在を書かないと決めています。範囲の文書は、まさにその「書かないもの」を集めた文書だからです。

5.3 責任体制——体制図に載る名前は、規格の名前ではない

教科書の体制の例には、ISMS管理責任者、情報セキュリティ委員会、ISMS事務局、部門長、ISMS推進担当者が並びます。よく見る形です。

5.3は、情報セキュリティに関連する役割に責任と権限を割り当て、組織内に伝えることを求めています。そのうえで、明示的に割り当てるよう求めている責任が2つありました。第6回で書いたとおり、規格への適合を確実にする責任と、ISMSのパフォーマンスをトップマネジメントに報告する責任です。管理責任者や事務局という名前は、5.3には出てきません。置くかどうか、何と呼ぶかは組織が決めます。

自治体には、総務省の「地方公共団体における情報セキュリティポリシーに関するガイドライン」が示す体制の例があります。並べてみると、名前は違っても置き場所はかなり近いものでした。

教科書の例でよく置かれる役割	規格の側で関わる箇所（筆者の整理）	総務省ガイドラインの例文で近い役割
トップマネジメント	5.1。5.3で役割を割り当てる側	CISO（最高情報セキュリティ責任者）
ISMS管理責任者	5.3で明示された2つの責任を担わせることが多い	統括情報セキュリティ責任者
情報セキュリティ委員会	5.1の関与や、9.3のレビューの場として使われやすい	情報セキュリティ委員会
部門長	6.1.2 c)のリスク所有者になりやすい	情報セキュリティ責任者（部局）／情報セキュリティ管理者（課室）
ISMS事務局・推進担当者	7.5の文書管理、9.1の取りまとめ、7.3の認識を広げる役	例文に同じ名前の役は無い

右の列は、位置づけが近いものを筆者が当てたもので、権限の中身まで同じではありません。たとえばCISOには、副知事や副市長など上位の役職者を充てるのが望ましいとされています。一方、規格のトップマネジメントは、範囲が組織の一部ならその一部を指揮し管理する人を指します。範囲の取り方で、指す人が変わるわけです。

責任権限表は、「活動ごと」に引く

責任権限表は、ISMSに要る活動を縦に並べ、それぞれの持ち主を横に書く表です。リスクアセスメント、文書の管理、内部監査、是正処置、といった行になります。

行政の事務分掌は、職を起点に「この職はこの事務を受け持つ」と書きます。責任権限表はその逆で、活動を起点に「この活動は誰が受け持つ」と書く。向きが違うだけで、材料は事務分掌の中にかなりあるはずです。

実は自治体の側にも、この向きの表の型があります。総務省ガイドラインは、誰がどんな権限と責任を持つかを一覧表で整理しておくことが望ましいとしていて、付録に「権限・責任等一覧表」を載せています。対策基準の例文の項目を縦に、CISOや各責任者を横に並べた表です。

ただし縦の並びが違います。ガイドラインの表は、対策基準の条項から作られています。6.1.2のリスクアセスメントや9.3のマネジメントレビューに当たる行は、筆者が見たかぎりありませんでした。この表を土台に、規格の箇条4〜10の活動の行を足すのが近道だと考えています。

兼任はどこまで許されるか

規格は兼任を禁じていません。教科書の例でも、推進担当者を部門長が兼ねてよいとしています。小さな組織なら、兼任しないと回らないのが普通です。

分けておきたいのは、自分の仕事を自分で確かめる形の兼任です。たとえば事務局が内部監査も持つと、9.2.2 b)の客観性と公平性の説明が苦しくなります。

この点は、自治体のガイドラインのほうが先に書いています。例文には「兼務の禁止」という項があり、申請する者と承認する者、監査を受ける者と監査する者を、やむを得ない場合を除いて同じ人にしない、と定めています。解説では、同一だと承認や監査の客観性が担保されない、という理由も添えられていました。ISMSの責任権限表を作るときも、この2組だけは列を分けておくと説明が楽になるはずです。

［現場］行政の体制と、範囲・責任の文書を突き合わせる

ここから現場の話です。

筆者の常駐先はISMSを取得しておらず、予定もありません。以下は取得の体験談ではなく、規格の要求と、行政が既に持っている体制を突き合わせた話です。

体制図は、筆者の位置からは見えていない

常駐先の情報セキュリティの体制図を、筆者は見た記憶がありません。誰が責任者で、誰がどこにつながるかを描いた図のことです。

前述の通り、ガイドラインには体制の例も一覧表の型もあります。だから「無い」とは書けません。読み方は2通りあります。職員向けの文書としてはあって、常駐の要員までは回ってこない。あるいは規程の条文としてはあっても、一枚の図の形にはなっていない。派遣の立場からは、どちらなのか判別できません。

調べていて気づいたことがあります。ガイドラインの例文で、設定変更や運用の作業を担うのは「情報システム担当者」で、例文はこの役を職員として書いています。筆者の作業はこの役の中身に近いのに、役の名前は職員の側にあるわけです。

これは歪みではないと考えています。第6回で書いたとおり、権限は職員にあり、筆者は作業を受け持つ。体制図が職員の職で描かれるのは、それが権限の図だからです。

ただ、5.3は割り当てた役割を組織内に伝えることまで求めていました。体制図を見ていない人に、自分の作業がどの役の下にあるかは何で伝わるのか。筆者の場合は係からの指示で、図ではなく経路で伝わっています。

新しい仕事は、使う課が持つ

事務分掌に書かれていない新しい仕事が出てきたとき、どこが持つのか。筆者の見るかぎり、その仕事を使う課が持つ形になっています。新しいサービスを業務で使い始めるときも、抱えるのは使う課の側です。

規格の考え方に照らしても、この置き方には筋があります。6.1.2 c)は、リスクを特定するときにリスク所有者を特定することを求めていました。使うかどうかを決める課に、そのリスクを運用管理する責任と権限を組織として持たせているなら、その課をリスク所有者とする考え方は成り立ちます。規格が「使う課が持て」と決めているわけではありません。

ガイドラインも同じ向きです。クラウドサービスの利用では、利用を申請する側と許可する側を分けています。そのうえで、申請した職員が許可する側やクラウドサービスの管理者を兼ねることは、職務の分離の観点から禁止としていました。

問いが残るのは、技術の見立てがどこで入るかです。第3回で、原課のAI利用は利便性で進み、セキュリティの意識に温度差がある、と書きました。使う課が持つのは、責任の置き方として筋が通っています。ただ、持つ課に技術の物差しがあるとは限りません。

責任権限表でいえば、「主管」の欄の隣に「相談を受ける」「確認する」の欄を置けるかどうか。そこに情報部門の居場所ができるかで、新しい仕事の扱いが変わると考えています。

原課とのやりとりは、係を通る

原課と情報セキュリティのやりとりをするとき、筆者が直接相手をすることは基本的にありません。情報部門の係を通します。

教科書の体制の例では、各部門に推進担当者を置いて、部門の中の窓口にしていました。ガイドラインの例文でも、課室ごとに情報セキュリティ管理者を置き、課室長を充てることが想定されています。どちらも、各課の側に窓口がある絵です。

筆者の位置から見えるのは、その手前にある係です。第26回で書いたフィルタの例外も、原課が申し出て、職員が判断し、筆者が設定する流れでした。

この形の強みは、依頼が必ず判断を通ってから作業に届くことです。作業する人が、自分の判断で原課の頼みを聞いてしまう道がありません。前の節の兼務の禁止を、経路の形で守っているとも読めます。

その代わり、各課の側の役がどう動いているかは、係が受け止めるぶん筆者からは見えません。表に書かれた各課の役と、実際の動きが合っているか。ここは確かめていません。

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

審査の事例を集めたものではありません。ここまでの話から、確認しておきたい点を挙げます。

外に出す範囲と、内部の範囲の文書が同じ

前述の通り、詳しく書いた範囲の文書は地図になり得ます。1つで持つと、外に出すたびに削る作業が要り、削り漏れが起きやすくなります。

体制図に、委託先や常駐の要員の居場所がない

権限の図としては、それで正しいのです。ただ、作業の多くを外の人が担う組織では、その作業がどの役の下にあるかを、図とは別の形で示しておくと、5.3の割り当てと伝達につながります。責任権限表に「実施（委託先）」の列を足すのが一つの手です。委託先との取り決めは、第18回の供給者関係の管理策の側で扱います。

役割の名前だけがあって、権限が書かれていない

管理責任者を任命しても、何を決めてよいかが書かれていなければ、5.3の割り当てにはなりにくいと考えています。名前を置くことと、責任と権限を割り当てることは別です。

新しい仕事に、行が立っていない

責任権限表には、作った時点の活動しか載りません。第17回で、権限をまとめて見直すきっかけは組織変更が多い、と書きました。組織が変わらない年に新しいサービスが入ってくると、表の見直しのきっかけがないまま、どの行にも当たらない仕事が残ります。

まとめ

• 4.3は範囲の境界を決めて文書にすることを求めますが、項目までは決めていません。組織・場所・業務・資産・ネットワークの5項目は実務の型です
• 詳しく書いた範囲の文書は機微な情報を含みやすくなります。外に出す範囲の記述と、内部の文書は分けて持つのが素直だと考えています
• 5.3は役割への責任と権限の割り当てと伝達を求め、明示的には2つの責任を挙げています。管理責任者・委員会・事務局は、組織が置き方を決める名前です
• 責任権限表は、活動を起点に引く表です。自治体には総務省ガイドラインの「権限・責任等一覧表」という同じ向きの型があり、規格の活動の行を足せば土台になります
• 規格は兼任を禁じていません。ただ申請と承認、監査する側とされる側は分けておくと説明しやすくなります。自治体のガイドラインは、この2組の兼務を例文で禁じています
• 筆者の位置からは体制図が見えず、原課とのやりとりは係を通ります。役は図ではなく、指示の経路で伝わっています

次回は、ステップ(2)の情報セキュリティ方針の策定を、実務の側から読む予定です。方針の要求そのものは第6回で扱いました。次回は書き方の回になります。

連載の入口は第1回です。

引っかかった点

教科書は、範囲の文書に拠点の図面やネットワークの構成図まで添えるとしています。4.3が範囲の文書の項目を指定していない以上、図面まで付けるのは実務の型だと読みました。規格本文で、範囲の文書の中身まで指定していないことは、条文そのものでは確かめていません。

総務省ガイドラインの体制と教科書の体制を1行ずつ当てましたが、当て方は筆者の判断です。とくに部門長には、部局の長に当たる役と課室の長に当たる役の2つが対応して見えます。どちらに寄せるかは、範囲をどの単位で取るかで変わりそうです。

「権限・責任等一覧表」にリスクアセスメントの行が見当たらない、というのは表を目で追い、テキストを検索した結果です。表の作りが細かいので、見落としの可能性は残ります。

参考にした一次資料

• 地方公共団体における情報セキュリティポリシーに関するガイドライン（総務省 地方行政のデジタル化） … ガイドラインの入口。令和8年3月版（令和8年3月27日改定）の本文で、組織体制の例文と解説、兼務の禁止、クラウドサービス利用の職務の分離、付録の権限・責任等一覧表を確認しました。PDFは改定のたびに差し替わるため、この一覧から辿るのが確実です
• ISMS認証取得組織検索（ISMS-AC） … 「登録範囲」が検索項目になっていることを、2026年10月8日に確認しました
• 岡田敏靖『ISO27001:2022の規格と審査がしっかりわかる教科書 改訂2版』（技術評論社） … 連載で使っている教科書です。13章37節（適用範囲と責任体制の決定）を読みました