ISMS文書の作り方（7.5）｜規格が名指しする14か所に、マニュアルの名前はない

第28回の6ステップでいえば、(3)にあたる回です。前回の第31回は(4)のリスクアセスメントでした。教科書の節の順に合わせて、ここで1つ戻ります。

7.5の要求そのものは、第11回で読みました。識別や承認、版の管理といった作り方の作法は、そちらに任せます。今回扱うのは、その手前の問いです。何を何冊に分けて書くのか。どれから作るのか。

---

ISMS文書を作るとは——ひとことで言うと

規格が名指しするものと、自分たちで要ると決めたものを、どの文書に書くか割り振り、使える形で置く作業です。

第11回で見たとおり、7.5.1は文書化した情報の源を2つ挙げています。規格が要求するものと、組織が必要と決めたものです。実務の最初の仕事は、前者を数えて漏れなく並べること。後者は、並べた結果を見ながら足していきます。

いきなり規程の目次から書き始めると、この順番が逆になります。目次は埋まっているのに、規格が名指ししたものが1つ抜けている。正直、そういう抜けは書いた本人ほど気づきにくいものです。

規格が名指しする14か所——前半は決めたこと、後半はやった証拠

規格本文は手元にないので、JIPDECのISMSユーザーズガイドで読みます。このガイドは、規格の本文で「文書化した情報」と明記されている箇所を表にまとめています。数えると14か所。教科書の整理とも一致しました。ただし、これは規格の文で「文書化した情報」と明記された箇所の数です。作るものの総数ではありません（次の節で、その例を見ます）。

その14か所に、性質と作る時期の列を足して並べ直したのが次の表です。性質と時期の列は筆者の整理で、ガイドの表にはありません。

条項	名指しされるもの	性質	主に作る・溜まる時期
4.3	適用範囲	決めたこと	(1) 範囲の決定
5.2	情報セキュリティ方針	決めたこと	(2) 方針
6.1.2	リスクアセスメントのプロセス	決めたこと	(4)の前
6.1.3	リスク対応のプロセス	決めたこと	(4)の前
6.2	情報セキュリティ目的	決めたこと	枠組みは(2)、具体は(4)の後
7.5.3	外部から入手した文書（必要と決めたもの）	受け取ったもの	随時
7.2 d)	力量の証拠	やった証拠	(5) 運用
8.1	計画どおり実施されたと確信するための情報	やった証拠	(5)
8.2	リスクアセスメントの結果	やった証拠	(4)、以後は定期と変更時
8.3	リスク対応の結果	やった証拠	(4)の後、(5)
9.1	監視・測定の結果の証拠	やった証拠	(5)
9.2.2	監査プログラムの実施と、監査結果の証拠	やった証拠	(5)
9.3.3	マネジメントレビューの結果の証拠	やった証拠	(5)
10.2 f) g)	不適合と講じた処置、是正処置の結果	やった証拠	(5)

並べてみて、意外と偏っていることに気づきました。構築の段で書き上げる「決めたこと」は、上の5行しかありません。残りの大半は、運用が始まってから溜まっていく証拠です。

第28回で、(5)の運用の跡は暦の時間でしか積み上がらない、と書きました。その中身が、この表の後半の行です。文書作成の仕事の半分は、書くことよりも、溜まる器を先に用意することだと筆者は考えています。

適用宣言書とリスク対応計画は、一覧に行がない

表を作っていて、引っかかったことがあります。第8回で読んだ適用宣言書とリスク対応計画が、名指しの一覧に単独の行として出てきません。

JIPDECのガイドは、6.1.3 d)を「適用宣言書の作成」、e)を「リスク対応計画の策定」と説明しています。「文書化した情報」の語で名指しされる形ではない、ということのようです。同じガイドの別の図では、文書名の例に適用宣言書とリスク対応計画書が挙がっています。

一覧に行がないから作らなくてよい、とはなりません。どちらも6.1.3で作成・策定が求められる成果物です。適用宣言書には規格が定める記載事項があります。ただ、文書名や様式まで一律に決まっているわけではありません。経済産業省の情報セキュリティ管理基準も、7.5.1にあたる項目の7つの中にリスク対応計画を入れていました。名指しの件数が資料によって違う理由の一つは、このあたりにありそうです。

マニュアルと文書の階層は、規格の要求ではない

解説書でよく見る作り方があります。規格の箇条に沿って、「組織は〜しなければならない」を「当組織は〜する」と書き換えた基本規定を作る。これをISMSマニュアルとして最上位に置き、その下に規程・手順書・様式を並べる形です。

ただ、14か所の中にマニュアルという名前は出てきません。管理基準は、必要な内容は「どの文書に記載されていてもかまわない」としています（第11回で引いた箇所です）。階層も、規格が決めているものではありません。

観点	マニュアルと階層を作る	作らない
審査員から見た辿りやすさ	条項番号から該当箇所へ辿りやすい	条項と文書の対応表が別に要る
抜けの確認	箇条の順に並ぶので確認が速い	一覧の根拠の列で確認する
書く量	規格の言い換えの分だけ増える	既にある規程を使えば少なくて済む
起きやすい問題	何をするかはあるが、どうやるか・誰がやるかが書かれない	どの文書に何があるかが本人にしか分からない

どちらが正しい、という話ではありません。既に規程の体系を持っている組織なら、マニュアルを新しく書くより、既存の規程と14か所の対応表を作るほうが早いと思います。何もないところから作るなら、マニュアルの型は抜けを防ぐ枠として役に立ちます。

何冊に分けるか——変わる速さ・承認する人・読む人

第31回では、リスクの1行の単位を「扱いが同じかどうか」で決めました。文書の1冊の単位も、同じ発想で決められます。

文書の例	変わる速さ	承認する人（例）	主に読む人
方針	数年に一度	トップマネジメント	全員、外部の利害関係者
範囲、リスクの基準とプロセス	年に一度程度	ISMSの責任者	推進の担当者
適用宣言書	アセスメントのたび	ISMSの責任者	推進の担当者、審査員
管理策の規程	管理策を変えたとき	ISMSの責任者	対象となる職員・従業員
手順書	機器やシステムを変えたとき	部門の責任者	作業する人
台帳・一覧	日々	更新する担当	担当者

承認する人の列は例です。一般的な文書の承認者を、規格が一律に指定しているわけではありません（第11回）。ただし例外が1つあります。6.1.3 f)は、リスク対応計画の承認と残留リスクの受容を、リスク所有者から得るよう求めています。

速さの違うものを1冊にまとめると、困ったことが起きます。速いほうに引っ張られて全体の改訂が増えるか、遅いほうに合わせて中身が古くなるかです。方針の本文の中に台帳を入れると、台帳を直すたびに方針の承認を取り直すことになります。

読む人が違うものを1冊にまとめるのも危うい形です。全員に配る文書に、作業者向けの細部が混ざります。管理基準は、内容を知る必要がある人には伝わり、知る必要のない人は見られないように構成する、と書いていました。分ける単位は、この線とも重なります。

先に作るのは、文書・記録の一覧

規格の要求ではありませんが、筆者が最初に作るなら一覧表です。第11回で読んだ識別・版・承認・保存期間を、1枚で回すための道具になります。

列の例は次のとおりです。

• 番号と名前
• 版と改訂日
• 承認者
• 置き場所と、見られる人
• 保存期間
• 根拠（14か所のどれか、または組織が必要と決めたもの）

効くのは最後の列です。根拠の列があれば、14か所の抜けがその場で見えます。「組織が必要と決めたもの」の行が増えすぎていないかも分かる。

版と改訂日の列は、第11回の現場パートで書いた「規程の改訂を見かけない」に効きます。安定しているのか、放置されているのか。外から区別する手がかりが、この列です。

記録は、様式から逆算する

表の後半の行は、ほとんどが記録です。運用が始まってから「何を残すか」を考えると、それまでの期間の跡が残りません。

だから手順書を書くときに、その手順が残す記録の様式も一緒に決めます。欄は「あとで誰が、何を確かめるか」から逆算します。是正処置なら、10.2 f) g)が求める「不適合と講じた処置」「是正処置の結果」の欄が要る、という具合です。

作る順番も、ここから見えてきます。前述の通り、第28回で(3)と(4)は行き来すると書きました。今回の表で言い直すと、次のようになります。

• (4)の前に整えるもの：適用範囲、方針、リスクの基準とプロセス、情報セキュリティ目的を設定する枠組み、一覧表
• (4)の後に具体化するもの：リスクアセスメントとリスク対応の結果を踏まえた情報セキュリティ目的、適用宣言書、リスク対応計画、管理策の規程、手順書、記録の様式

［現場］行政の仕事と、ISMS文書の層を突き合わせる

ここから現場の話です。

筆者の常駐先はISMSを取得しておらず、予定もありません。以下は取得の体験談ではありません。ISMS文書の層（規程・手順書・記録・一覧）に当たるものが、筆者の位置からどう見えているかの話です。

迷ったときに開くのは、委託先の手順書と自分のメモ

日々や月次の作業で手順に迷ったとき、筆者が最初に開くのは2つです。委託先から受け取った運用手順書と、自分の手順メモや前回の作業記録です。

自治体の情報セキュリティポリシーは、基本方針・対策基準・実施手順の三層で語られます（第3回）。ただ、機器やシステムをどう操作するかまで書いた文書は、筆者の位置から見ると、システムの側の文書が持っています。規程の層は何をしてよいか、誰が決めるかを定める層。操作の手順は、手順書の層です。

これをISMS文書の層に置き直すと、手順書の行には2本の文書が入ります。委託先の手順書は、7.5.3の外部から入手した文書の候補です（前述の通り、第28回で書きました）。自分のメモは、第19回で書いた「どのメモをいつ正式な手順書に格上げするか」の線引きの対象です。

筆者が見ている現場では、手順書の層に当たる文書は既にあります。ただ、あることと、ISMSの文書として管理されていることは別です。ISMSに乗せるなら、まず一覧に載せて根拠を整理する。そのうえで、承認・改訂・アクセスの管理が7.5.2と7.5.3に沿っているかを確かめる順になる、と考えています。

記録の様式は、書く人の側で育っている

筆者が日々書いている記録の様式は、前任から引き継いだものと、自分たちで作ったものです。欄を足したり削ったりするときも、常駐側の判断で変えています。中身は、職員が報告を受け取る段で見る形です。

前の節で「記録は様式から逆算する」と書きました。この現場では、その逆算を書く人自身がやっている、とも言えます。何を残せば後で困らないかを一番知っているのは、書く人です。様式の形を書く側に任せる分担は、筋が通っていると筆者は見ています。全部の様式の変更を決裁に回せば、業務が止まります。

ISMSの目で見ると、問いが1つ残ります。様式の欄が変わると、後で確かめる人が見られる項目も変わることです。9.1の監視の結果や、10.2の是正処置の結果を確かめる人がいるなら、欄の変更はその人にも関わります。様式に版と改訂日を入れておく。変えたことを受け取る側に一言伝える。ISMSに乗せるなら、そのくらいの手当てで足りるのではないかと思います。

一覧は、納品物の目録にはある

規程や手順書を、何があってどれが最新かまで分かる形で一覧にしたものを、筆者は見た記憶がありません。職員向けの管理の中にあって回ってこないのか、一覧という形を取っていないのか。派遣の立場では、どちらなのか判別できません。

一方で、委託先の納品物に付く目録は見ています。ドキュメントの名前、版、日付が並んだ一覧です。調達の世界では、一覧は成果物に当たり前に付いてくるものでした。

ISMSの一覧を作るとき、新しい形を発明する必要はないのだと思います。納品物の目録の形に、承認者・保存期間・根拠の列を足せば、先に書いた一覧表にかなり近づきます。目録にも規程にも載らない自分のメモのような文書を、どの行に入れるか。そこを決めるのが、一覧を作る側の仕事になります。

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

審査の事例を集めたものではありません。ここまでの内容から、つまずきやすいと考える点を挙げます。

規格の主語を替えただけの規定

「当組織は〜する」と書いた規定には、何をするかが書いてあります。ところが、誰が、いつ、何を残すかが抜けていることがある。審査で「実際にはどうやっていますか」と聞かれると、答えが規定の外の説明になってしまいます。言い換えた文の後ろに、担当・時期・残す記録の3つを足せるかを確かめます。

「適切に」「速やかに」で終わる手順

「適切に管理する」「速やかに報告する」は、守れたかどうかを判定できない言葉です。第31回で、物差しは判定できる言葉で書く、と書いたのと同じことが手順書にも言えます。誰が、何日以内に、何を使って、を書けるところから書きます。

様式の欄が多すぎて、埋まらない

念のためにと欄を増やすと、空欄が並ぶ様式ができます。空欄は、やっていないのか、該当しないのかを外から区別できません。「該当なし」と書く決まりを置くか、欄そのものを減らします。欄は、後で誰かが確かめる項目だけで足ります。

一覧そのものが古くなる

一覧表も文書の一つです。規程を改訂したのに一覧の版を直し忘れると、一覧と現物がずれます。第11回の「最新版がどれか分からない」は、この形でも起きる。改訂の手順の中に「一覧を直す」の1行を入れておきます。

まとめ

• 規格の文で「文書化した情報」と明記された箇所は14か所です。作るものの総数ではありません。構築の段で書く「決めたこと」は5つで、残りの大半は運用で溜まる証拠です
• 適用宣言書とリスク対応計画は、名指しの一覧に単独の行がありません。それでも、6.1.3で作成・策定が求められる成果物です。リスク対応計画の承認と残留リスクの受容は、リスク所有者から得ます
• ISMSマニュアルと文書の階層は、作り方の一つです。既に規程の体系がある組織は、14か所との対応表から始める道もあります
• 何冊に分けるかは、変わる速さ・承認する人・読む人で決めます
• 文書・記録の一覧を先に作り、根拠の列で抜けを見ます。記録は、後で誰が何を確かめるかから様式を逆算します
• 筆者の現場では、手順書の層は委託先の手順書と自分のメモが担い、記録の様式は書く側で育っていました。ISMSに乗せるなら、まず一覧に載せて根拠を整理し、そのうえで7.5.2・7.5.3の管理に沿っているかを確かめる順になると考えています

次回は、教科書14章のISMS導入教育と運用管理を読みます。作った文書を、人に届けて回し始める段です。

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

引っかかった点

14か所は、JIPDECのユーザーズガイドの表（JIS Q 27001:2023からの引用）で数えました。規格本文は手元にありません。6.1.3 d)・e)が「文書化した情報」の語を使っていないことは、ガイドの説明と表の構成から読んだもので、本文の語を直接は照合していません。

「文書」と「記録」の線は、規格の言葉ではありません（第11回）。表の「性質」の列は筆者の整理です。7.5.3の外部から入手した文書のように、どちらにも入れにくい行があったので「受け取ったもの」と別に書きました。

教科書の文書の例では、ISMSマニュアルを方針と並ぶ最上位に置いていました。規格が階層を決めていない以上、これは一つの作り方として読んでいます。

ISO/IEC 27001:2022には、2024年に気候変動への考慮を加える追補1が出ています。日本語版はJIS Q 27001:2023の追補1（2025年）です（第4回）。手が入ったのは4.1と4.2なので、14か所の整理には響かないと読んでいます。14か所は、ユーザーズガイドの表（JIS Q 27001:2023からの引用）にもとづいて数えました。

参考にした一次資料

• ISMSユーザーズガイド（JIPDEC／2025年3月31日） … JIS Q 27001:2023（ISO/IEC 27001:2022）対応版です。7.5の解説にある「要求事項に示された文書化した情報」の表と、6章の文書名の例を読みました
• 経済産業省「情報セキュリティ管理基準（令和7年改正版）」 … 4.8.1.1（文書化する情報の7項目と、記載する文書・伝える範囲の考え方）を確認しました。4.8.2.1（作成と更新）も読んでいます。本文は意見公募時に公開されていた版から読んでいます
• 岡田敏靖『ISO27001:2022の規格と審査がしっかりわかる教科書 改訂2版』（技術評論社） … 連載で使っている教科書です。13章40節（ISMS文書の作成）を読みました