無料で情報を見る

ISO/IEC 27001:2022のISMS内部監査|要求事項と進め方の実務

年に一度の内部監査の週、情報システム部の会議室には前年と同じチェックリストが配られていました。質問は「情報セキュリティ方針は周知されているか」「パスワードは定期的に変更しているか」。回答欄には「はい」が並び、結果は「不適合なし」。ところが翌月の認証機関の審査で、審査員は最初に「クラウドサービスの利用に関する管理策は、適用宣言書でどう扱っていますか」と尋ね、続けて「内部監査プログラムはどのリスク評価に基づいて組みましたか」と聞いてきました。

これは、ISMS(情報セキュリティマネジメントシステム)を長く運用している組織で起こりがちな場面を、架空のモデルケースとして描いたものです。規格が2022年に改訂され、管理策の構成も大きく変わったのに、内部監査の道具だけが旧版のまま残っている。その結果、内部監査は「毎年の儀式」になり、外部審査の前に弱点を見つけるという本来の役割を果たせなくなります。

ISMSの内部監査は、規格が要求する仕組みの一部であると同時に、組織が自分の情報セキュリティを点検する貴重な機会です。この記事では、ISO/IEC 27001:2022が内部監査に何を求めているのか、なぜその要求になっているのかを読み解き、実務で使える監査プログラムとチェックリストの形に落とし込みます。

この記事の要点

  • ISMS内部監査は、ISO/IEC 27001:2022の箇条9.2で要求される活動で、2022年版では「9.2.1 一般」と「9.2.2 内部監査プログラム」に分かれました
  • 監査の基準は「規格の要求事項」と「組織自身が決めたISMSの要求事項」の両方です。規格への適合だけでなく、自社ルールが守られ、有効に機能しているかを確かめます
  • 附属書Aの管理策は114から93に再編され、4つのテーマに整理されました。旧版のチェックリストを使い続けると、新設の11管理策が監査から漏れやすくなります
  • 移行期限は2025年10月31日で終了しています。今後の内部監査は、2022年版の運用が定着しているか、2024年の気候変動に関する追補が反映されているかを確認します
  • 監査員の客観性・公平性の確保、不適合の書き方、マネジメントレビューへのつなぎ方が、形骸化を防ぐ鍵になります

ISO/IEC 27001とは何か:規格の成り立ちと2022年改訂

認証のための「要求事項」の規格

ISO/IEC 27001は、国際標準化機構(ISO)と国際電気標準会議(IEC)が共同で発行する、ISMSの要求事項を定めた国際規格です。組織が情報の機密性・完全性・可用性を守るために、リスクを評価し、対応を決め、運用し、見直すという仕組みを持っているかを定めています。日本では同じ内容がJIS Q 27001として日本産業規格になっており、2022年版に対応するJIS Q 27001:2023が2023年9月に発行されました。

この規格は「要求事項(shall)」を書いた規格であり、第三者認証の基準になります。日本では情報マネジメントシステム認定センター(ISMS-AC)が認証機関を認定し、認定を受けた認証機関が組織を審査する、という制度になっています。内部監査は、その審査を受ける前提として組織自身が実施しなければならない活動の一つです。

2022年改訂で何が変わったか

2022年10月に発行されたISO/IEC 27001:2022では、本文(箇条4〜10)の変更は比較的小さく、主な変更は附属書Aの管理策にありました。本文では、ISMSに必要なプロセスとその相互作用を決めること(4.4)、変更を計画的に行うこと(6.3、新設)、外部から提供されるプロセスを管理すること(8.1)などが明確になりました。内部監査の箇条9.2とマネジメントレビューの箇条9.3は、それぞれ小箇条に分割されています。

附属書Aは、管理策の実施の手引であるISO/IEC 27002:2022にあわせて、114の管理策が93に再編されました。旧版の14の分野は、「組織的管理策(37)」「人的管理策(8)」「物理的管理策(14)」「技術的管理策(34)」の4テーマに整理されています。数が減ったのは管理策を削ったからではなく、重複を統合した結果です。一方で、脅威インテリジェンス、クラウドサービス利用における情報セキュリティ、データ漏えい防止など11の管理策が新設されました。

移行期限と2024年の追補

認証を受けている組織には、2022年版への移行期間が設けられていました。ISMS-ACの公表によれば、国際認定フォーラム(IAF)の文書に基づき、移行期限は規格発行から3年後の2025年10月31日です。現在(2026年時点)は、移行を終えた組織が2022年版で運用を続けている段階にあります。

さらに2024年2月には、ISO/IEC 27001:2022の追補(Amendment 1)として気候変動に関する変更が発行されました。箇条4.1に「組織は、気候変動が関連する課題かどうかを決定しなければならない」旨が加わり、箇条4.2に利害関係者が気候変動に関する要求事項を持ち得る旨の注記が加わっています。気候変動を「関連しない」と判断することも認められますが、その判断を検討した記録は内部監査で確認する対象になります。適用の詳細は認証機関の案内を確認してください。

箇条9.2が求める内部監査:条文を読み解く

9.2.1 一般:何を確かめる監査か

箇条9.2.1は、組織があらかじめ定めた間隔で内部監査を行い、ISMSが次の状態にあるかの情報を得ることを求めています。一つは、ISMSが「組織自身が規定した要求事項」と「この規格の要求事項」に適合していること。もう一つは、ISMSが有効に実施され、維持されていることです。

ここで見落とされやすいのが「組織自身の要求事項」です。情報セキュリティ方針、リスク対応計画、適用宣言書(附属書Aの管理策のどれを採用し、どれを除外したかと、その理由を記した文書)、各種規程や手順書は、すべて監査の基準になります。規格の条文だけを基準にした監査は、規格への適合は確かめても、自社ルールが現場で守られているかを確かめきれません。

9.2.2 内部監査プログラム:頻度と方法を「計画」する

2022年版で独立した小箇条9.2.2は、監査プログラムの計画・確立・実施・維持を求めています。監査プログラムには、頻度、方法、責任、計画に関する要求事項、報告を含めます。監査プログラムを定めるときには、関係するプロセスの重要性と、前回までの監査の結果を考慮することが求められています。

さらに、個々の監査ごとに監査基準と監査範囲を定めること、監査プロセスの客観性と公平性を確保する監査員を選ぶこと、監査結果を関連する管理層に報告することが求められます。監査プログラムの実施と監査結果の証拠として、文書化した情報を利用可能な状態にしておくことも必要です。

なぜ「プログラム」として求めるのか

冒頭のモデルケースで審査員が「どのリスク評価に基づいてプログラムを組んだか」と尋ねたのは、この9.2.2の考え方によります。全部署に同じ質問を毎年繰り返す監査は、実施の記録は残っても、プロセスの重要性や前回の結果を考慮したとは言えません。規格が監査を「1回ごとのイベント」ではなく「複数年にわたるプログラム」として求めているのは、限られた監査資源を、リスクの高いところへ繰り返し向けるためです。

この発想は、内部監査部門が年間監査計画をリスクベースで作る考え方と同じです。監査対象の洗い出しと優先順位づけの方法は、リスクベース内部監査の始め方でも解説しています。

計画・実行・点検・改善の循環のうち点検部分が強調され、そこから経営層の会議へ報告が流れる図
内部監査はISMSの点検(Check)を担い、その結果はマネジメントレビューへの入力になります。監査で終わらせず経営層の判断につなげることで、はじめて改善の循環が回ります。

監査プログラムの設計:頻度・範囲・監査員

複数年でカバーする設計

内部監査は毎年すべての要求事項と全部署を同じ深さで見る必要はありません。認証の有効期間(一般に3年)を一つの周期とみなし、その期間内で本文の全箇条と、適用宣言書で採用した全管理策を少なくとも一度は監査対象にする、という設計がよく使われます。そのうえで、リスクの高い領域は毎年、低い領域は隔年または周期内1回、と濃淡をつけます。

下の表は、中規模のサービス企業を想定した監査プログラムの記入例です(架空のモデルケース)。

監査領域 主な監査基準 重要性・前回結果 1年目 2年目 3年目
ISMSの基盤(4〜7、9、10) 本文、情報セキュリティ方針 全社に影響 ● ● ●
リスクアセスメント・リスク対応(6.1、8.2、8.3) リスク評価手順、リスク対応計画 前回軽微な不適合 ● ● ●
アクセス制御(5.15〜5.18、8.2〜8.5) アクセス管理規程 顧客データを扱う ● ● ●
クラウドサービス(5.23)・供給者関係(5.19〜5.22) 委託先管理規程 新設管理策、利用拡大 ● ●
物理的管理策(7.1〜7.14) 入退室管理規程 拠点は1か所、変更少 ●
事業継続(5.29、5.30) BCP、ICT継続計画 新設管理策を含む ● ●
人的管理策(6.1〜6.8) 就業規則、教育計画 前回指摘なし ●
開発・変更(8.25〜8.33) 開発標準、変更管理手順 前回観察事項あり ● ●

表中の番号は附属書Aの管理策番号です(本文の箇条番号と区別してください)。表の「重要性・前回結果」の列を残しておくことが、9.2.2の「重要性と前回の結果を考慮した」ことの証拠になります。

客観性と公平性をどう確保するか

ISO/IEC 27001は、監査員が監査対象から「独立していること」までは要求していません。求めているのは、監査プロセスの客観性と公平性です。実務では、自分が担当している業務を自分で監査しない、という線引きが最低限の目安になります。少人数の組織では、部門間で相互に監査する「相互監査」や、外部の専門家への委託がよく使われます。

内部監査部門がISMS内部監査を担う場合、客観性の面では有利です。ただし、情報セキュリティの専門知識が不足すると、質問が表面的になりがちです。情報システム部門の担当者を「技術専門家」としてチームに加え、判断は監査員が行う、という役割分担が現実的です。監査を依頼された内部監査部門がISMS事務局の運営まで引き受けると、自分で作った仕組みを自分で監査することになるため、役割の境界を文書で決めておくことが重要です。

監査の手引きとなる規格

内部監査の進め方そのものについては、マネジメントシステム監査の指針であるISO 19011が参考になります。ISO 19011は2026年に第4版(ISO 19011:2026)が発行され、リモート監査やデジタル証拠を前提とした内容に更新されています。ISMSに固有の監査の手引きとしては、ISO/IEC 27007(ISMS監査の指針)もあります。これらは要求事項ではなく指針ですが、監査員の力量や監査手順を社内で定める際の拠り所になります。

附属書Aの93管理策をどう監査するか

適用宣言書から出発する

管理策の監査は、適用宣言書を読むところから始めます。確認すべき点は三つです。第一に、93の管理策すべてについて採否とその理由が書かれているか。第二に、除外した管理策の理由が、リスクアセスメントの結果と矛盾していないか。第三に、採用した管理策が実際に実施されているか、です。

2022年版への移行時に適用宣言書を作り直した組織では、旧版の管理策番号との対応表を使って機械的に置き換えたケースも見られます。その場合、新設の11管理策の採否理由が「該当なし」の一言になっていないかを重点的に確認します。たとえば、クラウドサービスを業務で使っているのに5.23を除外している場合、除外理由とリスクアセスメントの整合を説明できるかが問われます。

4つの棚に管理策のタイルが並び、その中の11枚が琥珀色に光っている図
2022年版の附属書Aは93の管理策を4つのテーマに整理し、そのうち11が新設です。旧版のチェックリストを流用すると、光っているタイル=新設管理策が監査から漏れやすくなります。

新設された11の管理策と監査の着眼点

下の表は、新設11管理策について、内部監査で確認したい証拠の例をまとめたものです。管理策の名称はISO/IEC 27002:2022の内容を要約したもので、JISの正式な訳語は規格票で確認してください。

番号 管理策(要約) 監査で確認したい証拠の例
5.7 脅威インテリジェンス 情報源の一覧、収集した情報の分析記録、対策への反映例
5.23 クラウドサービス利用の情報セキュリティ 利用中サービスの台帳、選定・利用・終了の手順、責任分界の確認記録
5.30 事業継続のためのICTの備え 復旧目標の設定、復旧手順、訓練・テストの結果
7.4 物理的セキュリティの監視 監視カメラ・入退室ログの確認記録、異常時の対応記録
8.9 構成管理 標準構成の定義、構成変更の承認記録、構成のずれの検知
8.10 情報の削除 保存期間の規程、削除・消去の実施記録、委託先の消去証明
8.11 データマスキング マスキング対象の定義、テスト環境のデータ確認
8.12 データ漏えい防止 対象データと経路の特定、検知ルール、アラート対応記録
8.16 監視活動 監視対象とルール、アラートのレビュー記録、エスカレーション
8.23 ウェブフィルタリング 制限ルール、例外申請と承認、ルールの見直し記録
8.28 セキュアコーディング コーディング規約、コードレビュー・静的解析の記録

「文書がある」と「機能している」を分けて見る

管理策の監査で最も多い失敗は、規程や手順書が存在することを確認して終わってしまうことです。9.2.1が求めているのは「有効に実施され、維持されている」ことの確認です。規程を確認したら、その規程どおりに実施された記録をサンプルで確かめ、さらにその記録が期待した結果(例:不要なアクセス権が実際に削除された)につながっているかまで見ます。

アクセス権の棚卸や特権IDの管理は、ISMSでも財務報告に係るIT全般統制でも重要な領域です。具体的な監査手順はアクセス管理の監査手順が参考になります。NIST CSF 2.0など他のフレームワークと対応づけてサイバーセキュリティ全体を評価する方法は、サイバーセキュリティ監査の進め方で解説しています。

内部監査の実施手順と記録

手順の全体像

ISMS内部監査の一般的な流れは、監査計画の作成、事前の文書レビュー、現場での監査(インタビュー・記録の確認・観察)、所見のまとめと講評、報告書の作成、是正処置のフォローアップ、という順です。規格は手順の細部を定めていないため、社内の内部監査手順書で自社のやり方を決めておきます。

所見は、一般に「不適合」「観察事項(改善の機会)」「良好事項」に分けて整理します。不適合とは、要求事項を満たしていないことです。要求事項には規格だけでなく自社の規程も含まれるので、「規程では四半期ごとと定めた棚卸が半年実施されていない」も不適合になります。

不適合の書き方:記入例

不適合報告は、事実、基準、証拠を分けて書くと、是正処置の議論がぶれません。以下は記入例です(架空のモデルケース)。

項目 記入例
監査対象 情報システム部 クラウド基盤チーム
監査基準 ISO/IEC 27001:2022 附属書A 5.23、自社「クラウドサービス利用規程」第6条(利用開始前の承認)
事実 2026年4月以降に利用開始したクラウドサービス3件のうち1件について、利用開始前の承認記録が確認できなかった
証拠 クラウドサービス台帳(2026年8月末時点)、承認申請システムの記録、担当者へのインタビュー
区分 不適合(軽微):規程の手続は存在し、他の2件では運用されているため
是正の期待 未承認サービスの事後評価と、台帳登録時に承認記録を必須とする仕組みの検討

「担当者の認識不足」のような原因を監査員が断定して書かないことも大切です。原因の分析と是正処置の決定は、箇条10.2に従って被監査部門が行います。監査員は事実と基準のずれを明確に示し、是正処置が根本原因に届いているかを後で検証します。発見事項の重要度の付け方は指摘事項の重要度評価も参考にしてください。

マネジメントレビューへのつなぎ方

内部監査の結果は、箇条9.3のマネジメントレビューへのインプットになります。2022年版では9.3が「一般」「インプット」「結果」に分かれ、インプットに「利害関係者のニーズと期待の変化」が加わりました。内部監査の報告では、個々の不適合を並べるだけでなく、「新設管理策の定着度」「委託先・クラウドの管理」など、経営層が資源配分を判断できる単位でまとめ直すと、レビューが実質的になります。

内部監査チェックリストの例

以下は、本文の要求事項について毎年確認したい項目を絞ったチェックリストの例です。自社の規程に合わせて調整してください。

No. 確認項目 関連箇条 確認方法
1 組織の課題(気候変動の関連性の判断を含む)が見直されているか 4.1 課題一覧、検討記録
2 利害関係者の要求事項と、そのうちISMSで扱うものが決まっているか 4.2 利害関係者一覧
3 リスクアセスメントが計画した間隔と重大な変更時に実施されているか 6.1.2、8.2 評価記録、変更の一覧
4 適用宣言書が最新のリスク対応と整合しているか 6.1.3 適用宣言書、リスク対応計画
5 ISMSの変更が計画的に行われているか 6.3 変更計画、承認記録
6 情報セキュリティ目的が測定・監視されているか 6.2、9.1 目的の一覧、測定結果
7 外部から提供されるプロセスが管理されているか 8.1 委託先一覧、評価記録
8 前回の不適合の是正処置が有効だったか 10.2 是正記録、再確認の結果
9 マネジメントレビューのインプットが規格どおりそろっているか 9.3.2 議事録、資料

内部監査部門とISMS内部監査の関係

誰が担当するのが良いか

日本企業では、ISMS内部監査を情報セキュリティ事務局が主導し、各部署から選ばれた内部監査員が相互監査を行う形が多く見られます。一方、内部監査部門は業務監査やJ-SOX評価を担い、ISMSは「別の仕組み」として扱われがちです。この分担自体は問題ではありませんが、監査の重複と空白が生まれやすい点には注意が必要です。

たとえば、アクセス権の棚卸はISMS内部監査、J-SOXのIT全般統制評価、内部監査部門の業務監査の三者が別々に確認していることがあります。被監査部門から見ると同じ資料を3回求められ、しかも評価の基準が微妙に異なります。逆に、クラウドサービスの契約管理のように、どの監査も「他の監査が見ている」と考えて誰も見ていない領域が生じることもあります。

3ラインモデルで整理する

役割を整理するには、3ラインモデルの考え方が役立ちます。情報セキュリティ事務局は、方針や手順を定めて現場を支援・監視する第2ラインに近い立場です。ISMS内部監査は規格上の要求として行う点検であり、事務局が主導する場合は第2ラインの活動としての性格を持ちます。内部監査部門は第3ラインとして、ISMSという仕組み全体が有効に機能しているかを独立した立場から評価できます。

内部監査部門の年間計画では、ISMS内部監査の結果を「利用」し、自らは仕組みの有効性やガバナンス(経営層の関与、資源配分、リスク受容の判断)に焦点を当てる、という分担が考えられます。IIAのグローバル内部監査基準では、他の保証提供者との連携と依拠が求められており、ISMS内部監査の品質を確認したうえでその結果に依拠する設計は、この考え方にも沿います。

三つの監査の分担表(記入例)

観点 ISMS内部監査 J-SOX(IT全般統制) 内部監査部門
目的 規格・自社ルールへの適合と有効性 財務報告の信頼性に関わるIT統制の有効性 ガバナンス・リスク管理・統制の有効性
範囲 ISMSの適用範囲 財務報告に関連するシステム 全社(リスクベース)
主な基準 ISO/IEC 27001、適用宣言書 実施基準、社内のIT統制規程 社内規程、グローバル内部監査基準
依拠の関係 自ら実施 ISMSの結果を参考にできる場合あり ISMS・J-SOXの結果の品質を確認して利用

よくある失敗と対策

旧版のチェックリストを使い続ける

2013年版の管理策番号のまま質問を並べたチェックリストは、新設管理策を確認しないだけでなく、統合された管理策の範囲も正しく捉えられません。対策は、適用宣言書を起点にチェックリストを毎年作り直すことです。適用宣言書の改訂とチェックリストの改訂を同じ手順で連動させると、ずれが起きにくくなります。

「はい・いいえ」で終わるインタビュー

「規程は周知されていますか」という質問には、ほぼ全員が「はい」と答えます。質問は「直近で規程を参照したのはどの場面ですか」「その記録を見せてください」のように、行動と証拠を求める形にします。インタビューの設計については監査インタビューの技術も参考になります。

不適合ゼロを目標にする

不適合が出ないことを評価の指標にすると、監査員も被監査部門も指摘を避ける方向に動きます。内部監査は外部審査の前に弱点を見つける機会です。不適合や観察事項の件数ではなく、是正処置が根本原因に届いたか、同種の問題が再発していないかを指標にします。

監査員の力量が育たない

相互監査では、監査員が年に1回しか監査を経験しないことも珍しくありません。監査前の短い勉強会で、今回の重点領域の管理策と、確認すべき証拠の例を共有するだけでも質は上がります。監査員の力量を定義し、教育の記録を残すことは、箇条7.2(力量)の要求にも関わります。

よくある質問

ISMS内部監査は年1回実施しなければなりませんか?

規格は「あらかじめ定めた間隔」での実施を求めており、年1回とは明記していません。ただし、認証審査は通常毎年行われるため、少なくとも年1回は何らかの内部監査を実施し、認証の周期内で全範囲をカバーする設計が一般的です。頻度の妥当性は、自社のリスクと認証機関の考え方を踏まえて判断してください。

内部監査を外部の専門家に委託してもよいですか?

委託は可能です。規格は監査員が社内の人である必要を定めていません。ただし、監査プログラムの管理、監査結果の受け止め、是正処置の責任は組織側に残ります。委託先の監査員の力量と客観性を確認し、監査プログラムとの整合を事前にすり合わせておくことが重要です。

内部監査部門の監査で、ISMS内部監査を兼ねられますか?

内部監査部門の監査が、9.2の要求(監査基準・範囲の設定、客観性、報告、記録)を満たしていれば、ISMS内部監査として位置づけることは考えられます。その場合は、ISO/IEC 27001の要求事項と適用宣言書を監査基準に明記し、監査プログラム上でISMS内部監査として扱うことを文書化します。認証機関に事前に確認しておくと安心です。

気候変動の追補にはどう対応すればよいですか?

箇条4.1で、気候変動が組織の課題として関連するかを判断し、その結果を記録します。データセンターの所在地や自然災害リスク、顧客からの要求などを踏まえて判断するのが一般的です。関連しないと判断することも認められていますが、判断の根拠を説明できるようにしておきます。

まとめ

ISMS内部監査は、規格の要求事項であると同時に、組織が自分のセキュリティを点検する仕組みです。2022年版では、監査を複数年のプログラムとして計画すること、93に再編された管理策を適用宣言書から出発して監査すること、結果をマネジメントレビューにつなぐことが、あらためて問われています。

次の一歩として、手元の内部監査チェックリストが2022年版の管理策番号と新設11管理策に対応しているかを確認してみてください。関連する論点は、ITGC(IT全般統制)とSOC報告書の見方、委託先管理の監査、サイバーセキュリティ経営ガイドラインと内部監査でも扱っています。認証の判断や審査対応の詳細は、認証機関の見解もあわせて確認してください。

ISMS内部監査の体制づくりや監査プログラムの見直しについてのご相談は、お問い合わせからお寄せください。

参考資料

  • ISO/IEC 27001:2022 Information security, cybersecurity and privacy protection — Information security management systems — Requirements https://www.iso.org/standard/27001
  • ISO/IEC 27001:2022/Amd 1:2024 Climate action changes https://www.iso.org/standard/88435.html
  • ISO/IEC 27002:2022 Information security controls
  • ISO 19011:2026 Guidelines for auditing management systems https://www.iso.org/standard/19011
  • ISO/IEC 27007 Guidelines for information security management systems auditing
  • JIS Q 27001:2023 情報セキュリティ,サイバーセキュリティ及びプライバシー保護-情報セキュリティマネジメントシステム-要求事項
  • 情報マネジメントシステム認定センター(ISMS-AC)「ISMS適合性評価制度 ISO/IEC 27001:2022 への対応について」 https://isms.jp/topics/news/20230227.html
  • The Institute of Internal Auditors「グローバル内部監査基準」

内部監査の情報サイトから、実務の基盤へ。

信頼できるナレッジと実務ツールで、内部監査の価値をさらに高めます。