--- title: "ISMSのPDCAサイクルを回す方法｜各段階の作業と形骸化させない運用設計【2022年版】" url: "https://www.issoh.co.jp/column/details/12661/" published: 2026-06-22 updated: 2026-10-10 categories: ["セキュリティ"] publisher: "株式会社一創" --- # ISMSのPDCAサイクルを回す方法｜各段階の作業と形骸化させない運用設計【2022年版】 ISMS（情報セキュリティマネジメントシステム）のPDCAサイクルは、Plan・Do・Check・Actの4段階を年間で繰り返し、情報資産を守る仕組みを維持・改善していく運用の骨格です。この記事では、4段階それぞれで実施する具体作業を、現行のISO/IEC 27001:2022（邦訳はJIS Q 27001:2023、気候変動の追補1を反映した現行版はJIS Q 27001:2025）の箇条と対応づけて整理します。あわせて、規格本文に「PDCA」という語が実は明示されていない理由、IT運用への落とし込み方、そして多くの組織でサイクルが形骸化する構造的な原因と防ぎ方まで扱います。情報処理試験で問われるフェーズ判定のコツも最後にまとめました。 ## まとめ｜PDCAを回し続けるために最初に押さえる4段階と要点 ISMSのPDCAは、Plan（方針・目標・リスク対応計画の策定）、Do（管理策の実施・教育・記録）、Check（監視・測定・内部監査・マネジメントレビュー）、Act（是正処置・改善）の4段階で構成します。各段階はISO/IEC 27001:2022の箇条4〜10に対応し、Planがおおむね箇条4〜7、Doが箇条8、Checkが箇条9、Actが箇条10にあたります。「回す」とは、Actで得た改善を次のPlanへ戻し、年1回の認証サイクルに合わせて毎年繰り返すことを指します。 押さえるべき要点は3つです。第一に、現行規格は2022年版が前提です。2013年版からの移行期限2025年10月31日はすでに経過し、附属書Aは93管理策・4分類へ再編されています。第二に、規格本文に「PDCA」という語はありません。2013年版で附属書SL（共通構造）に整合した際に明示が外れ、いまは「継続的改善」（箇条10）として規定されています。PDCAは依然として運用の概念モデルとして有効ですが、規格を引用する場面では箇条番号で語るのが正確です。第三に、サイクルは記録（エビデンス）が伴って初めて成立します。「やったが記録がない」状態は、審査でも内部監査でも不適合の典型です。 なお、運用体制づくり・年間スケジュール・維持/更新審査の手順・費用や工数の目安は、[ISMS運用の年間手順を扱った記事](https://www.issoh.co.jp/column/details/12606/)で詳しく整理しています。本記事はPDCAサイクルそのものの理解と回し方に絞ります。 ## ISMSのPDCAサイクルの全体像と規格の箇条4〜10との対応関係 PDCAは、もともと品質管理の分野で広まった改善の枠組みです。ISMSではこれを情報セキュリティに当てはめ、リスクを評価して対策を決め、実行し、効果を検証し、足りなければ直す、という一連の流れを毎年回します。 ### PDCAの4段階がISMSで担う役割と「サイクルを回す」の具体的な意味 Planは、守るべき情報資産とそのリスクを特定し、リスク対応の方針と情報セキュリティ目標、管理策を決める段階です。Doは、決めた管理策を日常業務に実装し、従業員教育を行い、活動を記録する段階を指します。Checkは、運用が計画どおりか、目標に貢献しているかを監視・測定し、内部監査とマネジメントレビューで客観的に評価する段階です。Actは、評価で見つかった不適合や課題を是正し、ISMS全体を改善する段階にあたります。 「サイクルを回す」とは、Actで決まった改善を次のPlanに反映し、これを年単位で繰り返すことです。改善が次の計画に現れていなければ、それは一周しただけで回ってはいません。たとえば前年の内部監査で「アクセス権の棚卸しが不定期」と指摘されたなら、翌年のPlanに棚卸しの頻度と担当を明記する、という連続性が回っている状態の証拠になります。 ### Plan・Do・Check・Actと規格の箇条4〜10の対応関係 2022年版の本文は箇条1〜10で構成され、要求事項は箇条4以降にあります。PDCAの各段階は、おおむね次のように箇条へ対応づけられます。規格を根拠に説明したい場面では、PDCAの語よりこの箇条番号で示すほうが審査でも通りやすくなります。 | 段階 | 対応する主な箇条 | 主な活動 | 残す記録の例 | | --------- | ----------------------------- | ------------------------------- | ----------------- | | Plan（計画） | 箇条4 組織の状況／5 リーダーシップ／6 計画／7 支援 | リスクアセスメント、目標設定、管理策の選定 | リスク対応計画、適用宣言書 | | Do（実行） | 箇条8 運用 | 管理策の導入・運用、教育、記録 | 教育受講記録、アクセス権棚卸し記録 | | Check（評価） | 箇条9 パフォーマンス評価 | 監視・測定、内部監査（9.2）、マネジメントレビュー（9.3） | 内部監査報告書、レビュー議事録 | | Act（改善） | 箇条10 改善 | 不適合の是正処置（10.2）、継続的改善（10.1） | 是正処置記録 | この対応表は固定の正解ではなく、実務上広く使われる整理です。たとえば箇条6の「変更の計画」（6.3は2022年版で新設）は、組織やシステムが変わったときにPlanへ戻る入口として機能します。箇条をまたいで考える場面があると理解しておくと、サイクルを杓子定規に4分割しすぎずに済みます。 ## ISO/IEC 27001:2022が「PDCA」を明示しない理由と継続的改善との関係 多くの解説記事は「ISO 27001はPDCAサイクルを要求している」と書きます。これは運用イメージとしては正しいものの、規格の条文上は不正確です。現行の2022年版本文に「PDCA」という語は登場しません。ここを正しく理解しておくと、審査員との会話や社内説明でぶれがなくなります。 ### 2005年版のPDCA明示から2013年版・附属書SLへの構造変更の経緯 初版のISO/IEC 27001:2005は、序文でプロセスアプローチとしてPDCAモデルを明示的に採用していました。状況が変わったのは2013年版です。ISOのマネジメントシステム規格に共通の上位構造（附属書SL）へ整合させる過程で、特定の改善モデル名を本文に書かない方針となり、PDCAという語は条文から外れました。2022年版はこの2013年版の構造をほぼ引き継いでおり、変更の大半は附属書SLの最新版を取り込むための形式的なものです。継続的改善は箇条10.1、不適合と是正処置は箇条10.2に置かれています。 ### 規格本文に語がなくてもPDCAで運用する実務上の理由と審査での扱い 条文から消えても、PDCAがISMS運用の説明に使われ続けるのには理由があります。計画→実行→評価→改善という流れは、箇条6→8→9→10の要求事項の並びとほぼ一致し、担当者にとって直感的に理解しやすいからです。審査機関やコンサルティングの現場でも、運用の全体像を伝える共通言語としてPDCAが定着しています。 したがって、社内教育や運用設計ではPDCAで語って構いません。一方、適用宣言書やリスク対応計画など審査で提示する文書では、根拠を箇条番号で示すのが安全です。「この活動はPDCAのCheckにあたる」ではなく「箇条9.2の内部監査として実施した」と書けば、規格適合性の説明として過不足がありません。 ## Plan・Doの具体作業｜計画策定から管理策の実装とIT運用への落とし込み PlanとDoは、ISMSの土台を作って動かす前半の2段階です。ここでの作りこみが甘いと、後半のCheck・Actで評価する対象そのものが曖昧になります。 ### Planの作業｜情報資産の洗い出し・リスクアセスメント・93管理策の選定 Planの中心はリスクアセスメントです。具体的には次の順で進めます。 1. 情報資産の洗い出し：顧客情報、技術情報、ソースコード、業務データなどを、保管場所（サーバー、端末、クラウド、書類）とともに台帳化する。 2. 脅威と脆弱性の特定：不正アクセス、マルウェア、内部不正、設定不備、教育不足などを資産ごとに洗い出す。 3. リスク評価：影響度と発生可能性を掛け合わせ、対応の優先度を決める。 4. リスク対応の決定：低減・回避・移転・受容のいずれかを選び、低減するものに管理策を割り当てる。 5. 管理策の選定と適用宣言書の作成：附属書Aの93管理策から自社に必要なものを選び、採否と根拠を適用宣言書にまとめる。 2022年版の附属書Aは、組織的・人的・物理的・技術的の4分類に再編されています。旧版の114管理策から運用していた組織は、適用宣言書の項番が全て変わっている点に注意が必要です。あわせて、新設された11の管理策（脅威インテリジェンスや構成管理など）を採用するかどうかも、このPlanで判断します。 ### 2024年追補の気候変動の考慮をPlan（箇条4.1）へ組み込む観点 2024年2月、ISOのマネジメントシステム規格全体に気候変動を考慮する追補が加えられました。ISMSでも、箇条4.1（組織及びその状況の理解）で、気候変動が自社にとって関連する課題かどうかを判断し、その検討の記録を残すことが求められます。注意したいのは、環境活動の実施まで義務づけるものではない点です。2026年時点では、気候変動を課題として検討したか、そのプロセスを記録したか、の2点を満たせば足ります。たとえばデータセンターの停電・空調障害リスクを事業継続の観点で一度検討した、という記録があれば対応の入口としては十分です。 ### Doの作業｜管理策の導入・教育・記録と脆弱性管理など日常IT運用への接続 Doでは、選んだ管理策を実際の業務に組み込みます。アクセス権限の最小化、バックアップと復旧手順の整備、入退室管理、クリアデスクの徹底などが代表例です。IT運用を担う組織では、ここを既存の運用業務に接続できるかが実効性を左右します。具体的には、OSやミドルウェアの脆弱性情報を定期的に収集し、深刻度に応じてパッチ適用の期限を決め、適用結果を記録するまでをDoの一部として回します。たとえば「重大な脆弱性は公表から30日以内に適用、適用台帳に日付を残す」といったルールにしておくと、後のCheckで適用漏れを機械的に検出できます。 教育と記録もDoの要です。標的型メール訓練の実施、情報セキュリティポリシーの周知、テレワーク端末の利用ルールの徹底などを計画どおりに行い、受講記録や同意書を残します。テレワークを前提にする場合は、社内勤務では顕在化しなかったリスクへの追加対策が必要です。リモートアクセスの認証強化やログ保管など、[テレワーク環境で企業が直面するセキュリティリスクと管理策](https://www.issoh.co.jp/column/details/11239/)を踏まえてDoの対象に加えると、抜けが減ります。 ## Check・Actの具体作業｜内部監査・マネジメントレビューから是正・改善へ CheckとActは、回したサイクルを評価して次へつなぐ後半の2段階です。ここが弱いと、ISMSは「作っただけ」で止まります。 ### Checkの作業｜監視・測定と内部監査（箇条9.2）・マネジメントレビュー（9.3） Checkは3つの活動で構成されます。1つ目は日常の監視・測定です。ログ監視、インシデント発生件数、教育受講率、脆弱性診断の結果などを、あらかじめ決めた指標で定点観測します。2つ目は内部監査（箇条9.2）です。規格要求事項と社内ルールに適合しているか、有効に運用されているかを、監査計画に沿って組織内部の視点で検証します。3つ目はマネジメントレビュー（箇条9.3）です。経営層が、内部監査結果・インシデント状況・目標の達成度・リスクの変化などをインプットとして受け取り、ISMSの妥当性と改善の必要性を判断します。 監視・測定で大切なのは、指標を「測れて、意味があるもの」に絞ることです。すべてを数値化しようとすると運用が破綻します。インシデント対応時間や重大脆弱性の未適用件数など、改善の打ち手につながる指標を数個選ぶほうが、Checkは続きます。 ### Actの作業｜不適合の是正処置（箇条10.2）と継続的改善（10.1）の進め方 Actは、Checkで見つかった問題を直す段階です。是正処置は、事象の特定→原因分析→応急処置と再発防止策の実施→効果の確認、という順で進めます。原因分析を飛ばして表面だけ直すと、同じ指摘を翌年も受けます。たとえば「一部部署で教育が未実施」という不適合に対し、未実施部署への教育という応急処置だけで終えず、「受講状況を管理台帳で毎月確認する」という仕組み化まで踏み込むのが再発防止です。 継続的改善（箇条10.1）は、不適合がなくても進めるべき活動です。脅威やビジネス環境の変化を踏まえ、リスクアセスメントや管理策、文書を見直します。ここで決まった改善が次のPlanに反映されて、サイクルが一周します。 ### 各段階で残す記録（エビデンス）と次サイクルのPlanへの反映 4段階のいずれも、記録が伴って初めて運用したと言えます。Planならリスク対応計画と適用宣言書、Doなら教育受講記録とアクセス権の棚卸し記録、Checkなら内部監査報告書、Actなら是正処置記録が、それぞれの段階の成果物です。審査ではこれらのエビデンスが確認されるため、活動と記録をセットで設計しておきます。記録は、次のPlanで「前年に何を決め、どこまでできたか」を振り返る材料にもなります。マネジメントレビューの議事録に書かれた改善指示が、翌年の目標や教育計画、監査の確認項目に具体化されていれば、Actが回っている確かな証拠になります。 ## ISMSのPDCAが形骸化する構造的な原因と回し続けるための運用設計 PDCAが回らない組織は珍しくありません。原因は担当者の怠慢ではなく、運用の設計にあることが多いです。ここでは構造的な原因を分解し、回し続けるための具体策を示します。 ### 形骸化の典型パターン｜審査前だけ動く運用と記録のための記録 形骸化には決まったパターンがあります。最も多いのは、年1回の審査直前にだけ書類をそろえる運用です。普段はサイクルが止まっており、審査前に過去1年分の記録を慌てて整える。これでは情報セキュリティの実態は何も変わりません。次に多いのが「記録のための記録」です。現場の実態と乖離した手順書を作り、守られていないのに守ったことにして記録だけ残す。三つ目は、内部監査と是正処置が指摘のための儀式になり、根本原因に踏み込まないまま毎年同じ指摘を繰り返すパターンです。いずれも、PDCAの形だけが残り中身が抜けた状態です。 ### 回し続ける設計｜短サイクル化と日常IT運用へのCheckの埋め込み 回し続けるための要点を、重要な順に挙げます。まず最優先は、Checkを日常のIT運用に埋め込むことです。年1回の内部監査とは別に、パッチ適用状況やアクセス権の棚卸しを月次の運用タスクとして組み込み、その結果が自動的に記録に残る形にします。次に有効なのが、サイクルの短縮です。年1回のマネジメントレビューだけに頼らず、四半期ごとに指標を確認して軌道修正すると、問題が小さいうちに手を打てます。三つ目は、規程を現場が使える粒度にすることです。読まれない分厚いポリシーより、業務に紐づいた短いルールのほうが守られます。これら3点のうち、人員が限られる組織はまず1点目から着手するのが現実的です。 運用の体制づくりや費用・工数の目安、外部支援を使うかの判断は、[ISMS運用の実務手順をまとめた記事](https://www.issoh.co.jp/column/details/12606/)で具体的に整理しています。 ### PDCAを過剰適用すべきでない場面と「PDCAは古い」への結論 PDCAは万能ではありません。たとえば公表された重大な脆弱性への緊急対応のように、計画を待たず即座に動くべき場面で、丁寧にPlanから始めるのは過剰です。こうした局面では、まず手を打って被害を抑え、対応の記録を後からActの是正処置として整える順序が適切です。サイクルの形式に縛られて初動が遅れるのは本末転倒だと言い切れます。 「PDCAはもう古い」という指摘もあります。変化の速い領域ではOODAループのような短い意思決定の枠組みが向く、という主張です。ただしISMSにおいては、PDCAを捨てる必要はありません。問題はPDCAという枠組み自体ではなく、回す速度が遅いことにあるからです。年1回しか回さないPDCAは確かに時代に合いませんが、Checkを日常運用に埋め込み四半期で見直せば、速度の問題は解消します。ISMSではPDCAを否定するのではなく、回す頻度を上げて使うのが結論です。 ## 試験で問われるISMSのPDCAフェーズ判定の着眼点と頻出パターン ITパスポートや情報セキュリティマネジメント試験では、ある作業がPDCAのどの段階にあたるかを判定する問題が繰り返し出ます。実務でフェーズを意識するうえでも役立つので、判定の着眼点を整理します。 ### 作業内容からPlan・Do・Check・Actを見分ける着眼点と判定例 判定は動詞に注目すると速くなります。「目的や手順を定める」ならPlan、「定めた手順に従って実施する」ならDo、「客観的に評価・点検する」ならCheck、「問題を是正して方法を変える」ならActです。サーバ監視を例にすると、対応関係は次のとおりです。 | 作業内容 | 段階 | 判定の着眼点 | | ------------------ | ----- | ------------- | | サーバ監視の目的と手順を定める | Plan | 「定める」＝計画 | | 定めた手順に従ってサーバを監視する | Do | 「手順に従って実施」＝実行 | | 監視作業を第三者が客観的に評価する | Check | 「客観的に評価」＝評価 | | 問題点の是正として監視方法を変更する | Act | 「是正・変更」＝改善 | 迷いやすいのはDoとActの取り違えです。すでに決まった手順の実施はDo、問題を受けて手順そのものを変えるのはActと区別します。手順を「使う」のか「直す」のかが分かれ目です。 ### 「適切な運用を確認するために実施されるプロセス」が指す段階 「ISMSの適切な運用を確認するために実施されるプロセスは何か」という問いの答えは、Check段階の活動です。運用が計画どおり機能しているかを確認する代表的な手段が内部監査であり、これは箇条9.2に対応します。設問が「確認する」「監視する」「評価する」という語を含むときは、ほぼCheckを指していると判断して差し支えありません。逆に「是正する」「改善する」が主語になっていればActです。 ## よくある質問 ISMSのPDCAについて、検索で多く見られる疑問に簡潔に答えます。 ### ISMSのPDCAは規格で義務付けられているのですか？ 「PDCA」という語そのものは、現行のISO/IEC 27001:2022の本文には義務として書かれていません。2013年版で附属書SLに整合した際に明示が外れたためです。ただし、計画・運用・評価・改善にあたる要求事項は箇条6〜10に明確に定められており、継続的改善は箇条10.1で求められます。つまりPDCAという呼び名は任意でも、その中身に相当する活動は規格上必須だと理解してください。 ### PDCAモデルのCheckで実施する例として適切なものはどれですか？ Checkは、運用の状況を客観的に確認・評価する段階です。具体例としては、ログや指標の監視・測定、内部監査の実施、マネジメントレビューによる経営層の評価が該当します。試験では「定めた手順どおりに作業を実施する」（これはDo）や「発見した問題を是正する」（これはAct）と区別する点が問われます。評価・点検にあたる選択肢がCheckの答えです。 ### ISMSのPDCAは1年に何回くらい回すのが適切ですか？ 認証は3年を1サイクルとし、内部監査とマネジメントレビューは年1回以上の実施が基本です。ただし、年1回だけでは脅威の変化に追いつけません。日常の監視・測定を月次で行い、指標の確認と軌道修正を四半期ごとに挟む二層構成にすると、サイクルが形骸化しにくくなります。大きな改善は年単位、小さな点検は月次・四半期、という頻度の使い分けが現実的です。 ### 「PDCAはもう古い・よくない」と聞きますが、ISMSでも使うべきですか？ ISMSではPDCAを使って問題ありません。批判の多くは「年1回しか回さない遅いPDCA」に向けられたもので、枠組み自体の欠陥ではないからです。緊急のセキュリティ対応のように計画を待てない場面では即応を優先し、記録を後から是正処置として整えれば、PDCAと矛盾しません。回す速度を上げて使うのが、ISMSにおける現実的な結論です。 ### 小規模な組織でPDCAを回す最低限の体制はどう作ればよいですか？ 専任者を置けない場合は、ITに比較的詳しい従業員を推進役として兼任させる体制が現実的です。月初に端末の更新状況とウイルス対策の動作を確認し、月末にバックアップ記録を確認、四半期ごとに自己点検の結果を経営層へ報告する、という最小サイクルから始めます。なお、個人情報の取り扱いが中心の組織では、ISMSの代わりに、あるいは併用してプライバシーマークを選ぶ判断もあります。両制度の違いは[プライバシーマーク取得の流れを解説した記事](https://www.issoh.co.jp/column/details/5225/)もあわせて確認してください。 ## 関連記事 - [ISMS運用とは？2022年改訂後のPDCA・内部監査・更新審査まで実務手順を解説](https://www.issoh.co.jp/column/details/12606/)：運用体制・年間スケジュール・維持/更新審査・費用の目安まで、運用全体の手順を知りたい方向け。 - [プライバシーマーク取得の流れ：申請から認証までのステップ](https://www.issoh.co.jp/column/details/5225/)：個人情報保護に特化したPマークとISMSの違いや、併用を検討する際の判断材料に。 --- 出典: [ISMSのPDCAサイクルを回す方法｜各段階の作業と形骸化させない運用設計【2022年版】]()（株式会社一創）