ISMS構築から認証取得までの6ステップ｜規格の箇条は、作る順番には並んでいない

連載「ISMS審査員・監査への道」の第28回です。前回で、附属書Aの93の管理策を一巡しました。今回から第4期に入ります。

第2期と第3期では、規格が何を求めているかを読んできました。第4期は、それをどう作るかの話です。入口の今回は、ISMSを作り始めてから認証を取るまでの流れを、全体の地図として眺めます。

教科書の該当する節は、見開き2ページでした。正直、短いと感じました。そこで今回は、これまで27回で読んだ箇条がどのステップに入るのかも並べます。連載の索引を兼ねた回です。

---

ISMS構築の6ステップとは——ひとことで言うと

範囲と体制を決め、方針を立て、文書を作り、リスクを評価し、運用し、審査を受ける。この6つです。

教科書は、ISMSを作ってから認証を取るまでの活動を、次の6つに分けて整理しています。

1. 適用範囲と責任体制の決定2. 情報セキュリティ方針の策定3. ISMS文書の作成4. リスクアセスメント5. ISMSの運用6. 審査

「ISMS文書」は教科書の呼び方で、規格の用語ではありません。規格の言葉では、ISMSに必要な「文書化した情報」と、組織の規程類のことです。

前の5つは、ISMSを作って回すことです。最後の1つだけが、回っていることを外から確かめてもらうことになります。この違いは後半で触れます。

規格の箇条4〜10は、作る順番には並んでいない

6つのステップは、規格の箇条4〜10の並びとは一致しません。規格の並びは、もともと作る順番ではないからです。

ISO/IEC 27001:2022の序文（0.1）には、要求事項を示した順序は重要さを表すものでも、実施する順序を示すものでもない、という趣旨の一文があります。箇条4から順に片付けていけばISMSができる、とは規格自身が言っていません。

分かりやすいのが文書です。「文書化した情報」の管理は7.5にあり、範囲を決める4.3より後ろに置かれています。ところが4.3は、決めた範囲を文書化した情報として使える状態にするよう求めています。範囲を決めて文書にする段階から、7.5の文書の管理も関わってくるわけです。

リスクアセスメントも同じです。6.1.2で定めたやり方に沿って、8.2ではあらかじめ定めた間隔などでアセスメントを実施します。番号は離れていても、同じやり方を繰り返し使う関係です。番号が後ろにあることと、作業が後ろに来ることは別物だと分かります。

だから、教科書の6ステップは規格を並べ替えた「作る順番」の一例だと筆者は読んでいます。組織によって、別の切り方もあり得るはずです。

6つのステップと箇条4〜10の対応表

各ステップが規格のどこに関わるかを、連載の回と突き合わせて表にしました。規格が定めた工程順ではなく、6つに整理した場合の主な関係です。教科書の図を写したものでもありません。

ステップ	決めること・作るもの	主な箇条	連載で読んだ回
(1) 適用範囲と責任体制の決定	課題と利害関係者の要求を踏まえた範囲。役割と責任の割当て	4.1〜4.4、5.1、5.3	第4回、第5回、第6回
(2) 情報セキュリティ方針の策定	トップマネジメントが定める方針	5.2	第6回
(3) ISMS文書の作成	各箇条が「文書化した情報」として求めるものと、組織の規程類	7.5	第11回
(4) リスクアセスメント	物差しの決定、評価、対応の選択、適用宣言書	6.1.1〜6.1.3	第7回、第8回、番外編
(5) ISMSの運用	教育、管理策の実施と監視、定期のリスクアセスメント、内部監査、マネジメントレビュー	7.2、7.3、8.1〜8.3、9.1〜9.3、10、附属書A	第10回、第12回〜第14回、第15回〜第27回
(6) 審査	認証機関による初回の審査（第一段階・第二段階）	規格の外（認証制度の側）	第2回

並べてみると、(5)の行だけが極端に重いことが分かります。附属書Aの管理策は、ほとんどがここで効き始めるからです。連載でも、これまでの28回のうち半分を超える17回がこの1行に入りました。

(3)文書と(4)リスクアセスメント（6.1.2・6.1.3）は行き来する

6つは番号順に並んでいますが、(3)と(4)は一直線ではありません。文書の作成は、リスクアセスメントの前と後の2回に分かれる、と筆者は整理しています。

前に作るのは、リスクを測る物差しです。6.1.2は、リスクを受け入れるかどうかの基準と、アセスメントを行う基準を決めるよう求めています。これを決めてから評価に入り、評価の結果を受けて対応を選ぶ。選んだ対応を受けて、管理策の規程を書く。後に作る文書は、この規程の側です。

規程を先に全部そろえてしまうと、何が困るのか。第8回で読んだ適用宣言書には、管理策を含めた理由と、附属書Aの管理策を除外した理由を書きます。リスク対応より先に規程ができていると、その理由が評価の結果とつながりません。規程はあるのに、なぜその規程なのかを説明できない状態になります。

6つのステップに名前が出てこない箇条（6.2・6.3・7.1・7.4・10）

対応表を作りながら、置き場所に迷った箇条がありました。ステップの名前には出てこないのに、どこかで必ず要るものです。

箇条	中身	筆者が置いた場所
6.2 情報セキュリティ目的	測れる形の目的と、達成の計画	(2)方針と(5)運用の間。方針の向きを、運用で測れる形に落とす段
6.3 変更の計画策定	ISMSそのものを変えるときの計画	(5)運用の中。作り終えたあとに効く
7.1 資源	ISMSに要る資源の決定と提供	6つ全部の前提。どのステップにも溶け込む
7.4 コミュニケーション	何を、いつ、誰に伝えるか	(2)方針の周知から(5)運用まで
10.1・10.2 改善、不適合及び是正処置	見つかった問題を直し、仕組みを良くする	(5)運用の中。内部監査やマネジメントレビューなどで見つかった問題を、対応と改善につなげる

どれも「どこかで1回やる」作業ではない、と筆者は読みました。工程表に載らないぶん、計画から落ちやすい箇条だと考えています。

審査（6）だけは、規格の要求事項ではない

ISO/IEC 27001は、ISMSの要求事項を定めた規格です。認証を取ることは、その要求事項に入っていません。

ISO自身も、マネジメントシステム規格の認証は必須ではない、と説明しています。認証は、組織が自分で選んで受けるものです。第2回で読んだとおり、審査するのは認定を受けた認証機関になります。

初回の審査は、第一段階と第二段階に分かれます。ここで効いてくるのが、認証機関の側に掛かる規格です。ISO/IEC 17021-1:2015の該当箇所では、第一段階の目的の1つに、内部監査とマネジメントレビューが計画・実施されているかの評価が挙がっています。第二段階の対象にも、この2つが入っています（どちらも認定機関IASの解説資料で確認しました）。

初回の審査では、ISMSを作っただけでなく、内部監査やマネジメントレビューを含めて実際に運用していることが大事になります。どれくらいの期間を回せばよいかは、組織や認証機関によって事情が違うため、ここでは示しません。

［現場］行政の仕組みと、6つのステップを突き合わせる

ここから現場の話です。

筆者の常駐先はISMSを取得しておらず、予定もありません。以下は取得の体験談ではなく、行政が既に持っている仕組みに6つのステップを当ててみた話です。

範囲の線は、自分で引くより先に引かれている

6つのうち、行政の仕組みからいちばん遠いと筆者が感じるのは、(1)の適用範囲です。範囲の線を自分で引く、という発想そのものが遠いのです。

行政の仕事は、法令と事務分掌によって、誰が何を受け持つかが先に決まっています。第6回で、情報セキュリティの役割が職に割り当てられている、と書いたのもその一つです。線は引くものではなく、もう引かれているもの。筆者の感覚はそちらに近いです。

これは弱みではありません。自分で引かないぶん、担当者が変わっても線がぶれにくいからです。

ただ、4.3が範囲を決める材料に挙げる3つのうち、3つ目は他の組織の活動との接点と依存関係を指しています。行政の線は、内側の分担としては精密です。一方で、委託先や外部の機関との接点を、範囲の境目として意識して書く場面は、筆者は見た記憶がありません。

番外編で、業務の流れを歩いたとき一番見えにくいのは委託先の内側だ、と書きました。行政が(1)に取り組むなら、一から線を引くより、既にある線を外との接点まで含めて読み直す作業になるはずだと考えています。

文書は、稼働前にそろって届く

(3)文書から(5)運用への順番は、筆者の現場ではきちんと守られています。委託先が構築したシステムを運用として引き継ぐとき、運用に要る手順書類は稼働前に一式渡されてきました。

第27回で書いたように、受入れは職員と委託先のあいだで完結します。筆者は稼働後の運用から関わります。入口で文書がそろっているのは、調達が成果物として文書を求めているからでしょう。作ってから回す順番は、調達の世界では当たり前です。

ここで1つ区別しておきます。渡される文書はシステムの文書で、ISMSのために作る文書とは別物です。方針やリスクの物差し、適用宣言書は、システムの納品物には入りません。

それでも、受け取った文書がISMSと無関係になるわけではありません。7.5.3は、ISMSの計画と運用に必要だと組織が決めた文書なら、外部から入手したものでも識別して管理するよう求めています。委託先の手順書も、ISMSの計画と運用に必要だと組織が判断すれば、この「外部から入手した文書化した情報」として管理の対象になります。どの外部文書を対象にするかを決めておくのは、受け取る組織の側です。

時間を決めるのは、委託先の工程

新しい仕組みを入れるとき、決まってから実際に動き出すまでの時間を一番左右するもの。筆者の感覚では、それは委託先の工程です。

第16回で、ログの取り方や権限の割り方といった細部は構築の途中で決まっていく、と書きました。全体の日程も、委託先がどの順で作り、いつ試験し、いつ納めるかに沿って動きます。

これを6ステップに当てはめると、1つ見えてきます。(1)〜(4)は、外部の支援で縮められる余地がある。ところが(5)の運用の跡は、暦の上で時間が経たないと積み上がりません。内部監査もマネジメントレビューも、回した記録があって初めて見せられます。審査の日程も、認証機関という別の相手との調整で決まる。

外の工程に乗って進むほど、組織の手で縮められない区間を先に知っておく必要があります。それが(5)だと筆者は読んでいます。

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

6つを一直線の工程表として読む

前述の通り、(3)と(4)は行き来します。一直線の工程表にすると、リスク対応の結果が規程に戻る道が計画から消え、適用宣言書の理由の説明に詰まりやすくなります。

審査日から逆算して、運用の期間が足りなくなる

審査の日を先に決め、そこから逆算して構築を詰め込むと、(5)にしわ寄せが来ます。内部監査とマネジメントレビューを、形だけ急いで1回回すことになりがちです。第一段階でもその2つの計画・実施状況が確かめられるため、跡の薄さは隠しにくいと考えています。

ひな形の文書を、理由ごと借りてくる

ひな形を素材にするのは構いません。リスク対応の結果に合わせて削ったり足したりすれば、時間を縮める道具になります。問題は、理由まで借りてしまうことです。

外から来た文書を、管理の外に置く

委託先から受け取った手順書や設計書は、作ったのが外の人だという理由で、ISMSの文書管理から漏れやすくなります。対象が決まっていないと、改訂されたときに古い版が残ることもあります。

まとめ

• 教科書はISMS構築から認証取得までを、範囲と体制・方針・文書・リスクアセスメント・運用・審査の6つに分けています
• 規格の序文は、要求事項の並び順が実施の順序を示すものではない、という趣旨を書いています。6ステップは、規格を並べ替えた作る順番の一例です
• 文書の作成は、リスクの物差しを決める前段と、リスク対応を受けて規程を書く後段に分かれる、と筆者は整理しています。規程を先に全部そろえると、適用宣言書の理由がつながりません
• 審査だけは規格の要求事項ではありません。ただ認証機関の側の規格は、第一段階で内部監査とマネジメントレビューが計画・実施されているかを見るとしています
• 行政の仕組みから一番遠いのは、範囲の線を自分で引く発想だと筆者は感じています。線は既に引かれていて、読み直すべきは外との接点です
• 筆者の現場では、運用の手順書類は稼働前に一式届きます。それをISMSの計画と運用に必要な文書として管理するかは、受け取る組織の側が決めることです

次回は、ステップ(1)の適用範囲と責任体制の決定を、実務の側から読む予定です。第5回と第6回が「何が求められているか」だったのに対して、次回は「どう決めるか」の回になります。

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

参考にした一次資料

• ISO/IEC 27001:2022（序文 0.1） … 要求事項の順序についての一文を、規格の公式プレビューで確認しました。JIS Q 27001:2023の訳文は照らしていないため、趣旨だけを書いています
• ISO「Management system standards」 … マネジメントシステム規格の認証は必須ではない、という説明を確認しました
• ISO/IEC 17021-1:2015（9.3.1.2.2、9.3.1.3） … 第一段階の目的と第二段階の対象を、米国の認定機関IASの解説資料で確認しました。規格の本文は読んでいません
• 経済産業省「情報セキュリティ管理基準（令和7年改正版）」 … マネジメント基準の4.8.2.2（27001の7.5.3に対応）で、外部から入手した文書の項目を確認しました。意見公募時の版で読んでいます
• 岡田敏靖『ISO27001:2022の規格と審査がしっかりわかる教科書 改訂2版』（技術評論社） … 連載で使っている教科書です。13章36節（ISMS構築から認証取得までのステップ）を読みました

引っかかった点

教科書の6ステップでは、文書の作成が(3)、リスクアセスメントが(4)です。番号だけ見ると、文書を作り終えてから評価するように読めます。ところが同じ節の流れの図では、評価と対応の結果が規程の作成へ戻る形でした。番号は大まかな順序で、実際は入れ子だと読みました。

6.2の情報セキュリティ目的は、6つのステップのどこにも名前がありません。方針を測れる形に落とす作業なので、(2)の延長と見るか、(5)の運用の入口と見るかで迷いました。記事では「その間」と書いています。次回以降の実務編で、教科書がどこで扱うかを確かめます。

ISMSの認証機関には、ISO/IEC 17021-1に加えてISO/IEC 27006の系列も掛かるはずですが、今回は読めていません。審査の中身にISMS固有の追加があるかは、確かめていません。