PDCAは、Plan・Do・Check・Actの名称だけでなく、計画したことを実行し、結果を評価し、必要な改善へつなげる流れとして理解することが重要です。
特にSGでは、情報セキュリティ目的をどう設定するか、不適合が見つかったときに「修正」で終わっていないか、原因を除去する「是正処置」まで進んでいるかを見分けます。
読み終えるころには、事例の対応が修正で止まっているのか、是正処置まで進んでいるのかを切り分け、有効性の確認まで求められているかを判断できるようになります。
先に結論:PDCAは活動をつなぐ学習上の整理
| 段階 | 主な活動 | 確認すること |
|---|---|---|
| Plan | 目的と達成計画を定める | 何を目指し、誰が、いつまでに、どう評価するか |
| Do | 計画したプロセス・管理策を実施する | 決めた内容が実際に運用されているか |
| Check | 監視・測定・分析・評価を行う | 目的の達成状況やISMSの有効性はどうか |
| Act | 不適合へ対応し、改善する | 原因の除去や継続的改善へつながっているか |
JIS Q 27001:2023は本文で「PDCAモデル」という語を要求事項として明示しているわけではありませんが、JIPDECの利用者向けガイドでは、6章をPlan、8章をDo、9章をCheck、10章をActとしてPDCAの考え方で整理できると説明されています。
ただし、規格の全要求事項を一つずつ機械的にPDCAへ割り当てるのではなく、活動のつながりを理解するための整理軸として使います。
1.Plan:情報セキュリティ目的と達成計画
情報セキュリティ目的は、組織の情報セキュリティ方針と整合し、適用される要求事項やリスクを踏まえて定めます。
目的は、実行可能な場合には測定可能とします。これは、全ての目的を百分率や件数だけで表すという意味ではありません。数値化が難しい場合でも、達成状況を判断できる指標や評価方法を定めます。
例えば、
対象者の情報セキュリティ訓練受講率を、年度末までに98%以上とする
とすれば、達成状況を確認できます。
一方、「情報セキュリティをできるだけ高める」だけでは、どの状態になれば達成したのか判断しにくくなります。
目的を達成するための計画では、主に次を定めます。
- 何を実施するか
- 必要な資源
- 責任者
- 完了時期
- 結果の評価方法
目的そのものと、目的を実現するための達成計画を分けて考えることがポイントです。
2.Do:計画した内容を実際に運用する
Doでは、計画したプロセスや管理策を実際の業務で実施・管理します。
例えば、教育を実施する、アクセス権を管理する、委託先へ必要な要求を適用する、といった活動です。
文書を作成しただけでは運用したことにはなりません。要求事項に応じて必要な記録を残し、後から実施状況を確認できるようにします。
また、組織、業務、システム、委託先などに変化があれば、計画や管理策を変更する必要がないかを確認します。
3.Check:結果を確認する
Checkは、シラバスの用語例ではパフォーマンス評価にあたります。監視・測定・分析・評価を通じて、情報セキュリティパフォーマンスとISMSの有効性を確認します。
「研修を実施した」「管理策を導入した」という実施事実だけでなく、目的の達成状況や期待した効果が得られているかを評価します。
内部監査とマネジメントレビューもこの評価に関係しますが、両者の目的・実施主体・確認内容は「内部監査とマネジメントレビュー」の記事で扱います。本記事では、実行した結果を確認し、改善へつなぐ段階と押さえます。
4.不適合:要求事項を満たしていない状態
不適合とは、要求事項を満たしていないことです。
対象となる要求事項には、JIS Q 27001の要求だけでなく、法令・契約上の要求や、組織が要求事項として定めた規程・手順なども含まれ得ます。
例えば、
- 退職者アカウントを期限内に停止する手順が守られていない
- 必要な承認を受けずに運用を開始している
- 要求されている点検記録が残っていない
といった状態です。
実際の情報漏えいやシステム停止が起きていなくても、不適合は成立し得ます。
逆に、インシデントが発生したという事実だけで、直ちに不適合と決まるわけではありません。どの要求事項を満たしていなかったのかを確認します。
5.Act:修正・是正処置・継続的改善を分ける
| 用語 | 主な意味 | 試験で見る点 |
|---|---|---|
| 修正 | 検出された不適合そのものを除去する | 目の前の状態を直したか |
| 是正処置 | 不適合の原因を除去し、再発を防止する | 原因を調べ、必要な処置と有効性確認まで進んだか |
| 継続的改善 | ISMSの適切性・妥当性・有効性を継続して改善する | 評価結果や変化を改善へ反映しているか |
修正と是正処置は別
退職者のアカウントが停止されていなかった場合を考えます。
- 未停止のアカウントを停止する
→ 修正
- 停止漏れの原因を調べ、連絡・承認・処理の仕組みを見直す
→ 是正処置
目の前の不適合を直しても、原因が残れば再発する可能性があります。
是正処置は「原因」と「有効性」まで見る
試験対策上は、次の流れで整理すると判断しやすくなります。
- 不適合へ対処する
不適合を管理・修正し、必要に応じて生じた影響へ対処します。
- 原因と類似事例を確認する
原因を分析し、同様の不適合が存在するか、発生する可能性があるかを確認します。
- 必要な処置を実施する
原因を除去するため、手順、役割、連絡方法、仕組みなどを必要に応じて変更します。
- 有効性を確認する
実施した是正処置が機能したかをレビューします。
これはJIS Q 27001の要求事項を試験向けにまとめた流れです。実務では、必要に応じてリスク及び機会を見直し、ISMSそのものを変更することも検討します。
「担当者の不注意だった」と決め付けて注意だけで終えるのは適切とは限りません。人の行動が原因となる場合もありますが、業務量、役割分担、連絡、承認、システムなどを含め、根拠をもって原因を分析します。
6.継続的改善は全面入替えではない
継続的改善は、既存の管理策を毎回全て廃止し、新しいものへ置き換えることではありません。
監視・測定、監査、マネジメントレビュー、是正処置、リスクや環境の変化などを踏まえ、ISMSの適切性・妥当性・有効性を継続して改善します。
有効に機能している管理策は維持し、必要な部分を改善します。改善の規模は、小さな手順変更の場合もあれば、目的・責任・管理策を大きく見直す場合もあります。
7.科目Bでの使われ方
科目Bでは、規格の条項番号ではなく、その対応が修正で止まっていないかを判断する材料として使われます。
| 事例文の合図 | 確認すること |
|---|---|
| 該当のアカウントを停止したので対応は完了した | 原因の除去と有効性の確認まで進んだか |
| 担当者が忘れたことが原因だった | 業務量・役割分担・連絡・承認まで見たか |
| 事故は起きていないので問題ない | 要求事項を満たしていない状態ではないか |
| 目的として「意識を高める」と決めた | 達成状況を判断できる指標があるか |
担当者としては、目の前の不適合を直したうえで、同じことが他の部門・業務でも起きないかを確認します。原因の除去に手順や仕組みの変更が必要な場合は、独断で変えず、上位者や関係部署へ報告して指示を仰ぎます。
不適合への対応を問われたら、次を確認します。
- 目の前の不適合へ対処したか
ここだけなら主に修正です。
- 原因を分析したか
「担当者が忘れた」で止めず、なぜ起きたかを確認します。
- 類似の不適合も確認したか
他の部門・業務でも同じ問題が存在又は発生し得ないかを見ます。
- 原因を除去する処置を行ったか
必要な仕組み・手順等を変更します。
- 処置の有効性を確認したか
実施しただけで終わらず、効果をレビューします。
実際のインシデントを起点とする原因分析・再発防止の詳細は「原因分析と再発防止」の記事で扱います。本記事は、不適合への対応としての修正・是正処置・継続的改善を中心に扱います。
よくある取り違え
| 誤った理解 | 正しい整理 |
|---|---|
| 情報セキュリティ目的は必ず数値だけで表す | 実行可能な場合に測定可能とし、達成を判断できる方法を定める |
| 管理策を実施すれば目的達成 | 実施と、達成状況・有効性の評価は別 |
| 不適合は事故が発生した場合だけ | 要求事項を満たしていなければ、事故がなくても不適合になり得る |
| 不適合を直せば是正処置が完了 | 修正に加え、原因除去と有効性確認が必要 |
| 原因は必ず担当者個人か、必ず仕組みのどちらか | 根拠に基づき、人・手順・役割・仕組みなどを分析する |
| 是正処置を実施した時点で完了 | 処置の有効性をレビューする |
| 継続的改善では全管理策を入れ替える | 評価結果に基づき必要な部分を改善する |
まとめ
- PDCAは、計画・運用・評価・改善をつなぐ学習上の整理
- 情報セキュリティ目的は方針と整合させ、実行可能な場合に測定可能とする
- 目的の達成計画では、実施事項、資源、責任者、完了時期、評価方法を定める
- 不適合は要求事項を満たしていない状態であり、事故がなくても成立し得る
- 修正は検出された不適合を直すこと
- 是正処置は原因を除去して再発を防ぎ、その有効性を確認すること
- 類似の不適合が存在又は発生し得ないかも確認する
- 継続的改善ではISMSの適切性・妥当性・有効性を継続して改善する
- 内部監査・マネジメントレビューの詳細と、インシデント起点の原因分析は別の記事で扱う
関連記事
- C3-T01:情報セキュリティガバナンスと組織体制
- C3-T02:情報セキュリティポリシーと諸規程
- C3-T03:ISMSとJIS Q 27001・27002
- C3-T04:管理策の3つの軸を整理する
- C3-T06:内部監査とマネジメントレビュー
- C4-T03:リスクアセスメントの全体像
- C6-T05:原因分析と再発防止
本記事は、2026年8月3日時点のSGシラバスVer.4.1を基準に作成しています。
参考資料
- IPA「情報セキュリティマネジメント試験(レベル2)シラバス Ver.4.1」
- 日本規格協会「JIS Q 27001:2023」
- 日本規格協会「JIS Q 27001:2023/AMENDMENT 1:2025」
- ISO「ISO/IEC 27001:2022」
- ISO「ISO/IEC 27001:2022/Amd 1:2024」
- JIPDEC「ISMSユーザーズガイド JIS Q 27001:2023(ISO/IEC 27001:2022)対応」
関連する問題
- 情報セキュリティマネジメント 情報セキュリティ管理・ISMS 択一式(応用) 第1問〜第5問
- 情報セキュリティマネジメント 情報セキュリティ管理・ISMS 択一式(応用) 第6問〜第10問
- 情報セキュリティマネジメント 情報セキュリティ管理・ISMS 一問一答 第16問〜第20問

コメント