>
>
公開日
「ISMSの内部監査を、次から自分たちで回すことになった」。そうした情シスに向けて、JIS Q 27001（ISO/IEC 27001）と監査の指針（JIS Q 19011）をもとに、年間計画、監査員の選び方、チェックリスト、指摘と是正までを作業の順に解説します。取得の流れや費用はISMS認証とは？、2022年版の改正点はISO/IEC 27001の解説で扱っており、本記事は認証後の内部監査に絞っています。
本記事のポイント
内部監査で確認するのは「ルールどおりに運用されているか（適合性）」と「仕組みが役立っているか（有効性）」の2つです
チェックリストは93管理策を並べず、自社の適用宣言書から抜き出して作ります
SaaS環境では、退職者アカウント、権限見直しの記録、台帳に載っていないSaaSで指摘が出やすくなります
※2026年11月時点の規格情報と関係機関の資料に基づく整理です。自社の手順は、規格の原文と認証機関の案内で確認してください。
ISMS内部監査とは何を確認する活動か
ISMS内部監査は、自社のISMSが規格と社内ルールに沿って運用され、実際に機能しているかを、組織自身が定期的に確かめる活動です。認証機関の審査とは別に、組織が自ら行うことが規格で求められています。
箇条9.2が求めていること
内部監査の要求事項は、JIS Q 27001の箇条9.2にあります。2022年版（日本語版はJIS Q 27001:2023）では、2013年版で1つだった箇条が「9.2.1 一般」と「9.2.2 内部監査プログラム」の2つに分かれました。
9.2.1は、ISMSが次の状態にあるかの情報を得るために、あらかじめ定めた間隔で内部監査を行うよう求めています。
観点 | 規格が求める内容 | 監査で確かめることの例 |
|---|---|---|
適合性 | 組織自身がISMSについて定めた要求事項と、規格の要求事項に適合している | 規程で「退職時は当日中にアカウントを停止する」と定めているなら、実際に当日中に停止されているか |
有効性 | ISMSが有効に実施され、維持されている | 退職時の停止が回っているだけでなく、停止漏れが起きない仕組みになっているか、起きたら気づけるか |
9.2.2は、内部監査を年間を通じた「プログラム」として計画・運用するよう求めています。プログラムには、頻度、方法、責任、計画に関する要求事項、報告が含まれます。あわせて、監査ごとに監査基準と範囲を決めること、監査プロセスの客観性と公平性を確保できる監査員を選ぶこと、結果を関連する管理層に報告すること、監査プログラムと結果の証拠として文書化した情報を利用できる状態にすることが求められています。
認証機関の審査との違い
内部監査と認証機関の審査は、どちらも「監査」ですが、実施者も目的も異なります。JIS Q 19011の区分では、内部監査は組織自身が行う第一者監査、認証審査は第三者監査にあたります。
項目 | 内部監査 | 認証機関の審査（維持審査・更新審査） |
|---|---|---|
実施者 | 組織が選んだ内部監査員（社内または外部に委託） | 認証機関の審査員 |
目的 | 自社のISMSの問題を見つけ、改善につなげる | 規格への適合を第三者として判定し、認証を維持できるかを決める |
頻度 | 組織が「あらかじめ定めた間隔」で決める | 3年の認証サイクルのなかで、少なくとも年1回の維持審査と、3年ごとの更新審査 |
結果の扱い | 是正処置とマネジメントレビューへの入力 | 不適合があれば期限内の是正を求められる |
認証機関の審査では、内部監査が計画どおり行われ、見つかった問題が是正されているかも確認されます。つまり内部監査の記録そのものが審査の確認対象になります。そう考えておくと、準備の優先順位を決めやすくなります。
最新の規格版で確認しておくこと
2024年に、ISO/IEC 27001:2022に気候変動に関する追補（Amendment 1）が発行されました。日本ではこれを反映したJIS Q 27001:2025が出ています。追補で加わったのは、箇条4.1に「組織は気候変動が関連する課題であるか否かを決定しなければならない」という一文と、箇条4.2の注記の2点です。内部監査の箇条9.2の内容は変わっていません。
ただし、追補が反映された版で認証を受けている場合、箇条4.1の検討結果は内部監査の確認対象に入ります。「気候変動は自社のISMSにとって関連する課題か」を検討した記録があるかを、マネジメントシステム本体の確認項目に1行加えておきます。
内部監査の年間計画の立て方
年間計画は、認証機関の維持審査の日程から逆算して決めるのが実務的です。是正処置とマネジメントレビューを審査前に終えられるよう、監査の実施は審査の2〜3か月前までに済ませておきます。
頻度は「あらかじめ定めた間隔」で、多くの組織は年1回
規格は内部監査の頻度を「あらかじめ定めた間隔」としか定めておらず、年1回とは書かれていません。それでも多くの組織が少なくとも年1回としているのは、認証機関の維持審査が毎年あり、その前に内部監査と是正の結果をそろえておく必要があるからです。
9.2.2では、プログラムを決めるときに、関連するプロセスの重要性と前回までの監査結果を考慮するよう求めています。すべての領域を同じ頻度で見る必要はなく、事故が起きた領域や、前回不適合が出た領域、大きな変更があった領域は頻度を上げる、という決め方ができます。
対象範囲の分け方
年1回ですべての部門・プロセスを一度に監査するか、年間で分割して回すかは、組織の規模と監査員の人数で決めます。
方式 | 進め方 | 向いている組織 |
|---|---|---|
一括方式 | 年1回、適用範囲のすべてを数日〜数週間で監査する | 適用範囲が小さい、監査員が少ない |
分割方式 | 四半期ごとなどに部門・プロセスを分けて監査し、1年で全範囲を一巡させる | 部門が多い、監査員の負担を分散したい |
テーマ追加方式 | 一括または分割の監査に加えて、事故や変更があった領域を臨時で監査する | 前回の指摘や事故の再発を確実に確かめたい |
分割方式にする場合も、年度の終わりに「適用範囲のすべてを一度は見たか」を一覧で確認できるようにしておきます。
維持審査から逆算したスケジュール例
維持審査を毎年10月に受ける組織であれば、次のような流れになります。月はあくまで一例で、自社の審査日程に合わせて前後させてください。
時期 | やること |
|---|---|
審査の6か月前（4月） | 前年度の監査結果・是正状況・事故の記録を振り返り、今年度の監査プログラム（範囲・頻度・方法）を決める |
審査の5か月前（5月） | 監査員を選び、対象部門と日程を調整する。チェックリストを更新する |
審査の4か月前（6月） | 内部監査を実施する（分割方式なら、この時期までに全範囲を終える） |
審査の3か月前（7月） | 監査報告書をまとめ、不適合について是正処置の計画を立てる |
審査の2か月前（8月） | 是正処置を実施し、有効性を確認する |
審査の1か月前（9月） | マネジメントレビューを行い、監査結果と是正状況を経営層に報告する |
監査員の選び方と独立性
監査員は、監査の対象となる業務から独立した立場の人を選ぶのが原則です。情シスが少人数で自部門から独立した監査員を立てられない場合は、他部門との相互監査や外部監査員の併用で客観性を確保します。
規格が求めるのは「客観性」と「公平性」
9.2.2が監査員に求めているのは、監査プロセスの客観性と公平性を確保できることです。「自部門を監査してはならない」とは書かれていません。
一方、監査の指針であるJIS Q 19011は、監査の原則の一つとして独立性を挙げています。監査員は実行可能な場合は監査の対象となる活動から独立し、どの場合でも偏りや利害の衝突がない形で行動することが望ましい、という考え方です。実務では、情シスが情シス自身のアカウント管理を監査する、といった自己点検の形は避けるのが一般的です。
少人数の情シスでの現実的な組み方
ひとり情シスや数名の体制では、技術的な管理策を理解している人がほぼ情シスにしかいない、という状況がよくあります。その場合の組み方には、次のような選択肢があります。
他部門との相互監査：情シスが総務・人事のプロセスを監査し、情シスの領域は総務・経理など他部門の担当者が監査する。技術的な確認は、チェックリストに「確認する証跡」と「見方」を具体的に書いておくことで補う
管理職の監査員を加える：情シス以外の部門長などを監査員にし、情シスのメンバーは被監査側として説明に回る
情シスの領域だけ外部に委託する：マネジメントシステム本体や他部門は社内で監査し、技術的な管理策の部分だけ外部の監査員に依頼する
どの組み方を選んでも、監査プログラムに「誰がどの範囲を監査し、独立性をどう確保したか」を書いておきます。審査の場でそのまま説明できる記録になります。
監査員の力量と記録
規格の箇条7.2は、ISMSの実施に関わる人の力量を決め、教育などで力量を備えさせ、その証拠を残すよう求めています。内部監査員も対象です。社内研修、外部の内部監査員研修、前任者との同行監査などで力量を確保し、受講記録や同行の記録を残します。内部監査員に公的な資格は求められていません。
監査チェックリストの作り方と主な確認項目
チェックリストは、附属書Aの93管理策を上から並べるのではなく、自社の適用宣言書に載っている管理策と、マネジメントシステム本体（箇条4〜10）の要求事項から抜き出して作ります。項目ごとに「何を見れば確認できたことになるか」まで書いておくと、監査員が交代しても同じ深さで監査できます。
適用宣言書から抜き出す手順
附属書Aの93管理策は、組織的管理策（37）、人的管理策（8）、物理的管理策（14）、技術的管理策（34）の4つのテーマに分かれています。組織はリスクアセスメントの結果から必要な管理策を選び、採否と理由を適用宣言書にまとめています。チェックリストはこの適用宣言書を出発点にします。
適用宣言書で「採用」とした管理策を一覧にする
今年度の監査で重点的に見る管理策を決める。前回の不適合、事故があった領域、リスクアセスメントで高リスクとされた領域、SaaSの追加や組織変更など大きな変更があった領域を優先する
管理策ごとに、社内規程のどの条文で運用を定めているかをひも付ける
項目ごとに「確認する証跡」と「確認方法（文書確認・聞き取り・サンプル確認）」を書く
マネジメントシステム本体（箇条4〜10）の確認項目を加える
規程とのひも付けを入れておくと、「規程に書いてあるのに運用されていない」と「規程そのものがない」を区別して指摘できます。規程の作り方や構成は、セキュリティポリシーの策定手順で整理しています。
マネジメントシステム本体で確認する項目
管理策の運用だけを見て、ISMSの仕組みそのものを見落とすのは、内部監査でよくある抜けです。箇条4〜10からは、少なくとも次の項目をチェックリストに入れます。
箇条 | 確認項目 | 確認する証跡の例 |
|---|---|---|
4.1／4.2 | 組織の課題と利害関係者の要求を見直しているか（追補版では気候変動の検討も） | 課題・利害関係者の一覧と見直しの記録 |
6.1 | リスクアセスメントを定めた時期・条件で実施し、結果を残しているか | リスクアセスメント結果、リスク対応計画 |
6.1.3 | 適用宣言書が最新の管理策の採否と一致しているか | 適用宣言書の版と改訂履歴 |
6.2 | 情報セキュリティ目標を決め、達成状況を測っているか | 目標と達成状況の記録 |
7.2／7.3 | 力量の確保と、従業員の意識向上を行っているか | 教育計画、受講記録 |
8.1 | 外部から提供されるプロセス（委託・クラウドサービス）を管理しているか | 委託先・利用サービスの一覧と評価記録 |
9.1 | 監視・測定の対象と方法を決め、結果を評価しているか | 監視・測定の記録 |
9.3 | マネジメントレビューを行い、決定事項を記録しているか | マネジメントレビューの議事録 |
10.2 | 前回の不適合に是正処置を行い、有効性を確認したか | 是正処置報告書、有効性確認の記録 |
リスクアセスメントの進め方はリスクアセスメントの手順、情報資産の分類と台帳の作り方は情報資産管理とはで解説しています。
情シスが担当する管理策のチェックリスト
情シスが運用を担うことの多い管理策について、確認項目と証跡を一覧にしました。適用宣言書で採用している管理策だけを残し、自社の規程の言葉に置き換えて使ってください。管理策の番号と名称はJIS Q 27001:2023の附属書Aに沿っています。
管理策 | 確認項目 | 確認する証跡 |
|---|---|---|
5.9 情報及びその他の関連資産の目録 | 利用中のSaaS・端末が台帳に登録され、管理責任者が決まっているか | 情報資産台帳、SaaS台帳と利用実態の突き合わせ結果 |
5.15 アクセス制御 | アクセス制御の規則が定められ、主要なSaaSに適用されているか | アクセス制御規程、SaaSの権限設定画面 |
5.16 識別情報の管理 | 共有IDの有無と、その理由・利用者が管理されているか | アカウント一覧、共有IDの管理表 |
5.17 認証情報 | パスワードの基準と多要素認証の適用範囲が決められ、守られているか | 認証ポリシー、MFAの設定状況一覧、例外の承認記録 |
5.18 アクセス権 | 権限の付与・変更・削除が申請と承認に基づき、定期的に見直されているか | 申請・承認記録、権限見直しの実施記録 |
5.19／5.20 供給者関係 | SaaSベンダーなど供給者を選ぶ前に評価し、契約でセキュリティ要件を定めているか | 供給者の評価記録、契約・利用規約の確認記録 |
5.22 供給者のサービス提供の監視 | 利用中のSaaSについて、認証の更新や規約変更を定期的に確認しているか | 年次評価の記録、第三者認証・監査報告書の入手記録 |
5.23 クラウドサービスの利用における情報セキュリティ | クラウドサービスの導入・利用・管理・終了の手順が定められ、運用されているか | 導入申請の記録、利用終了時のデータ削除・アカウント削除の記録 |
6.5 雇用の終了又は変更後の責任 | 退職・異動時に、アカウント停止と権限変更が漏れなく行われているか | 退職者リストと各SaaSのアカウント一覧の照合結果 |
8.2 特権的アクセス権 | 管理者権限の付与先が必要最小限で、定期的に見直されているか | 管理者ロールの一覧、見直しの記録 |
8.8 技術的ぜい弱性の管理 | ぜい弱性情報を収集し、修正の適用状況を管理しているか | ぜい弱性対応の記録、パッチ適用状況 |
8.13 情報のバックアップ | バックアップの取得と、復元テストが定めたとおりに行われているか | バックアップの取得記録、復元テストの記録 |
8.15 ログ取得／8.16 監視活動 | 主要なSaaSの監査ログを取得・保管し、確認しているか | ログの保管設定、確認の記録 |
8.32 変更管理 | システムや設定の変更が申請・承認を経て行われているか | 変更申請と承認の記録 |
この表は、監査員が「見るべき証跡」を共有するための骨組みです。委託先に送って回答してもらう形式の点検票が必要な場合は、ISMSセキュリティチェックシートを使うと項目をそろえやすくなります。
SaaS・アカウント管理で指摘が出やすい項目
SaaSが増えた環境では、規程は整っているのに、運用の記録が追いついていない項目で指摘が出やすくなります。退職者アカウント、権限見直しの記録、台帳に載っていないSaaSの3つは、内部監査で必ずサンプルを取って確かめておきたい項目です。
退職者のアカウントがSaaSに残っている
IdPで退職者のアカウントを停止していても、IdPと連携していないSaaSや、SaaS独自のIDで使われていたアカウントは残ることがあります。規程では「退職時に停止する」と定めていても、実際の停止がIdPだけで終わっていれば、管理策6.5と5.18の運用が規程どおりではない、という指摘につながります。
監査では、直近の退職者から数名を選び、主要なSaaSの管理画面やアカウント一覧で状態を確かめます。IdPの停止記録だけで確認を終えないのがポイントです。照合の手順は退職者のアカウント削除｜IdP停止後のSaaS確認手順で詳しく解説しています。
権限の見直しを「やった記録」がない
権限の定期的な見直しは、多くの組織が規程に定めている一方で、実施したことを示す記録が残っていないことがあります。担当者が画面で確認しただけでは、監査で確かめられる証跡になりません。見直しの対象、実施日、確認者、変更した内容と理由が残っているかを確認します。
管理者権限は特に重点的に見ます。SaaSごとの管理者ロールの一覧があり、不要な管理者が外されているかを確かめます。見直しの進め方はアクセス権限の棚卸しの進め方、管理者権限に絞った手順は特権ID管理とは？SaaS管理者ロールの棚卸しで整理しています。
台帳に載っていないSaaSが使われている
部門が独自に契約したSaaSや、無料プランで使われているSaaSは、情報資産台帳から漏れがちです。台帳にないSaaSはリスクアセスメントの対象にもならず、供給者の評価（5.19）やクラウドサービスの管理（5.23）の対象からも外れてしまいます。
監査では、台帳の登録内容が正しいかだけでなく、「台帳にないものが使われていないか」を別の情報源で確かめます。経費精算の支払いデータ、IdPのログイン履歴、ブラウザの利用状況などを台帳と突き合わせる方法があります。見つけ方の具体例はシャドーITの発見方法で紹介しています。
SaaSベンダーの評価が導入時のままになっている
SaaSを導入するときには評価をしていても、その後の見直しが行われていないケースもよくあります。第三者認証の有効期限切れ、データの保存場所の変更、利用規約の改定に気づかないまま使い続けている状態は、管理策5.22の運用が不十分だという指摘につながります。
個人データの取扱いを任せているSaaSは、個人情報保護法の委託先管理の対象にもなります。ISMSの供給者評価と委託先の点検を同じ台帳で管理すると、確認作業の重複を減らせます。進め方は委託先管理の進め方とチェックリストで解説しています。
多要素認証の適用に例外が残っている
多要素認証を「全社で必須」と定めていても、一部のSaaSや一部のユーザーに適用されていないことがあります。例外を設けること自体は認められるため、監査では例外を承認した記録と理由、代わりの対策が残っているかを確認します。点検の方法は多要素認証の導入後に残る穴と適用漏れを防ぐ点検方法が参考になります。
確認作業を毎回手作業にしないために
これらの項目は、SaaSごとに管理画面へログインしてアカウント一覧を取り出し、台帳と見比べる作業になりがちです。監査のたびに手作業で集めると、監査員の負担が大きく、確認できる範囲も狭くなります。
『マネーフォワード Admina』のようなSaaS管理ツールを使うと、連携したSaaSのアカウント・権限・多要素認証の設定状況を一覧で確認でき（SaaSの利用状況の可視化）、従業員マスターとの差分から退職者のアカウントを検知できます（従業員IDライフサイクル管理）。SaaSごとに個人情報の有無、外部認証の取得状況、データの保管国、管理担当者を登録しておけるため（コンプライアンス対応）、供給者評価の台帳としても使えます。Adminaは国内トップクラスの数のSaaSと連携しており、直接連携していないSaaSもスプレッドシート連携で同じ画面に集められます。
監査の実施手順
監査は、事前準備、文書の確認、聞き取り、証跡の確認、所見の整理の順に進めます。証跡は被監査部門に「見せてもらう」だけで終わらせず、監査員が取得して監査記録に残すことが、後の是正と審査の説明につながります。
手順1：事前通知と準備
監査の2〜3週間前までに、対象部門に監査の日程、範囲、監査基準（どの規程・どの管理策を見るか）、用意してほしい資料を伝えます。チェックリストは事前に共有しても構いません。何を見られるかがわかれば、被監査部門は資料を探す時間を減らせ、監査当日は確認に時間を使えます。
手順2：文書の確認
規程、手順書、台帳、前回の監査報告書と是正処置の記録を確認します。規程が最新か、規程と手順書の内容が食い違っていないか、前回の不適合に是正処置が取られたかを、聞き取りの前に把握しておきます。
手順3：聞き取り
担当者に、実際の運用を説明してもらいます。「退職者が出たら、誰から連絡が来て、誰がどのSaaSを止め、どこに記録しますか」のように、手順を順番に話してもらう聞き方をすると、規程と運用のずれが見つかりやすくなります。
手順4：証跡の確認
聞き取りで説明された運用が、記録として残っているかを確かめます。すべてを確認するのは難しいため、母集団からサンプルを選んで確認します。
母集団をはっきりさせる：退職者なら人事の退職者リスト、SaaSならSaaS台帳とIdPの連携先一覧など、確認対象の全体を最初に決める
サンプルは監査員が選ぶ：被監査部門に選ばせると、問題のない記録だけが出てくることがある
取得した証跡を残す：画面のスクリーンショット、出力したCSV、確認した記録の識別番号を、取得日時とあわせて監査記録に残す
証跡を残しておけば、審査で「どのように確認したか」を聞かれたときにそのまま示せます。アクセス管理の証跡は、財務報告に係る内部統制（J-SOX）のIT全般統制でも同じものが求められることが多いため、両方に対応している企業は取り方をそろえておくと二重の作業を減らせます。IT全般統制で求められる証跡はITGC（IT全般統制）とはで整理しています。
手順5：所見の整理と報告
監査の最後に、被監査部門と所見を確認する場（クロージング）を設けます。事実の認識に食い違いがないかをその場で確かめておくと、報告書を出した後の差し戻しを防げます。そのうえで監査報告書をまとめ、関連する管理層に報告します。
指摘事項の書き方と是正の進め方
指摘事項は、どの要求事項に対して、どんな事実があり、何を証拠に判断したかの3点で書きます。不適合には期限を決めて是正処置を取り、再発していないことを確認してから完了とし、結果をマネジメントレビューに報告します。
所見の区分を決めておく
規格が定義しているのは「不適合（要求事項を満たしていないこと）」です。それ以外の区分は組織が決めてよく、実務では次の3区分がよく使われます。
区分 | 内容 | 対応 |
|---|---|---|
不適合 | 規格または社内規程の要求事項を満たしていない | 是正処置を取り、有効性を確認する（必須） |
観察事項 | 現時点では要求事項を満たしているが、このままでは不適合になるおそれがある | 対応の要否を被監査部門が判断し、記録する |
改善の機会 | 要求事項は満たしているが、より良くできる点がある | 任意。次年度の計画に反映するかを検討する |
認証機関の審査では、不適合を「重大」と「軽微」に分けて扱うのが一般的です。内部監査でも、影響の大きさで不適合をさらに分けておくと、是正の優先順位を決めやすくなります。区分の名前と定義は、監査プログラムに書いておきます。
不適合の書き方
不適合は、読んだ人が同じ事実を確認できるように書きます。感想や推測は入れず、証拠に基づく事実だけを書きます。
要素 | 書き方の例 |
|---|---|
要求事項 | 情報セキュリティ規程第○条「退職者のアカウントは退職日当日中に停止する」（附属書A 6.5、5.18） |
事実 | 2026年4月〜9月の退職者12名から5名を抽出して確認したところ、1名について、IdPと連携していないSaaS 1件のアカウントが退職日の30日後も有効だった |
証拠 | 人事の退職者リスト、当該SaaSのアカウント一覧（2026年6月○日取得） |
「アカウント管理が不十分」のような書き方では、何を直せばよいかが伝わりません。どの規程の、どの事実が、どの証拠で確認されたかを書くことで、被監査部門は原因の調査から始められます。
是正処置と有効性の確認
箇条10.2は、不適合が起きたときに次の対応を取るよう求めています。
不適合を管理し、修正する（例：残っていたアカウントを停止する）
不適合の原因を明らかにし、似た不適合がほかにもないか、起こりうるかを確かめる
再発を防ぐための処置を取る
取った是正処置の有効性をレビューする
必要に応じてISMSを変更する
内部監査でよく見られるのが、1の修正だけで完了にしてしまうケースです。残っていたアカウントを止めても、IdPと連携していないSaaSの停止手順がなければ、次の退職者でも同じことが起きます。原因を「担当者の確認漏れ」で止めず、手順や仕組みのどこに穴があったかまで掘り下げます。
有効性の確認は、是正処置の後に同じ確認をもう一度行って、再発していないことを確かめる作業です。たとえば、是正後に出た退職者のアカウントを次の監査や月次の点検で確認し、その結果を記録してから完了とします。
マネジメントレビューへの報告
箇条9.3は、マネジメントレビューで考慮する事項に、不適合と是正処置、監視・測定の結果とあわせて監査の結果を含めています。内部監査の結果は、件数だけでなく、傾向と、経営層に判断してほしいこと（人員、予算、ツールの導入など）を添えて報告します。
「SaaSの増加に台帳の更新が追いついていない」「退職者のアカウント停止が手作業に頼っている」といった課題は、現場の努力だけでは解決しにくいものです。マネジメントレビューで資源の判断を得られると、次年度の改善につなげやすくなります。
よくある質問（FAQ）
Q. ISMSの内部監査は、年に何回必要ですか？
A. 規格は「あらかじめ定めた間隔で」と定めているだけで、回数は決めていません。多くの組織は、認証機関の維持審査が毎年あることから、少なくとも年1回としています。前回不適合が出た領域や、事故・大きな変更があった領域は、頻度を上げて監査する決め方もできます。
Q. 内部監査員に資格は必要ですか？
A. 公的な資格は求められていません。規格が求めているのは、監査員が客観性と公平性を確保できることと、必要な力量を備え、その証拠を残すことです。社内研修、外部の内部監査員研修、前任者との同行監査などで力量を確保し、記録を残してください。
Q. 情シスの担当者が、情シスの業務を監査してもよいですか？
A. 規格に明確な禁止はありませんが、監査の指針（JIS Q 19011）は、実行可能な場合は監査の対象となる活動から独立した人が監査することを原則としています。少人数で難しい場合は、他部門との相互監査や、情シスの領域だけ外部の監査員に依頼する方法で客観性を確保します。
Q. 附属書Aの管理策は、毎年すべて監査する必要がありますか？
A. 毎年すべてを同じ深さで見る必要はありません。重要度、前回の結果、変更の有無に応じて重点を決め、認証の3年サイクルのなかで適用範囲全体を確認できるよう監査プログラムを組む方法が一般的です。重点の決め方と、全体をいつ確認するかは、監査プログラムに書いておきます。
Q. 内部監査を外部に委託してもよいですか？
A. 委託できます。外部の監査員に依頼しても、内部監査としての位置づけは変わりません。ただし、監査プログラムを決め、結果を受けて是正処置を取り、マネジメントレビューに報告する責任は組織に残ります。委託先にすべてを任せると、社内に監査の知見が残らないため、社内の担当者が同行する形がおすすめです。
Q. ISMSとISO 42001（AIMS）の両方を運用している場合、内部監査は分ける必要がありますか？
A. 両規格は共通の構造を持つため、内部監査をまとめて行う方法もとれます。統合のしかたはISMS（ISO 27001）とAIMS（ISO 42001）の違い・統合運用ガイドで解説しています。
まとめ｜内部監査の進め方チェックリスト
ISMS内部監査は、規格と社内ルールに沿って運用されているか、その仕組みが実際に機能しているかを、組織自身が確かめる活動です。適用宣言書から作ったチェックリストで証跡を確認し、不適合には原因まで掘り下げた是正処置を取り、結果をマネジメントレビューで経営層に報告する、という一連の流れを毎年回すことで、維持審査に向けた準備にもなります。
SaaSが増えた環境では、退職者アカウント、権限見直しの記録、台帳に載っていないSaaSの3つが特に指摘の出やすい項目です。日頃からアカウントと台帳を同じ場所で管理しておくと、監査のたびに手作業で集める負担が減り、確認できる範囲も広がります。
計画
前年度の監査結果、是正状況、事故の記録を振り返った
維持審査の日程から逆算して、監査・是正・マネジメントレビューの時期を決めた
監査プログラムに、範囲、頻度、方法、責任者、報告先を書いた
重点的に見る領域（前回の不適合、事故、大きな変更）を決めた
監査員
監査員が、自分の担当業務を監査しない組み方になっている
独立性を確保できない部分について、相互監査や外部監査員などの方法を決めた
監査員の力量の根拠（研修・同行監査）を記録した
チェックリスト
適用宣言書で採用した管理策から確認項目を抜き出した
項目ごとに、根拠となる社内規程、確認する証跡、確認方法を書いた
マネジメントシステム本体（箇条4〜10）の確認項目を入れた
退職者アカウント、権限見直し、台帳外のSaaS、供給者評価、多要素認証の例外を確認項目に入れた
実施と是正
母集団をはっきりさせ、監査員がサンプルを選んで証跡を確認した
取得した証跡を、取得日時とあわせて監査記録に残した
不適合を、要求事項・事実・証拠の3点で書いた
是正処置で原因まで掘り下げ、有効性を確認してから完了とした
監査結果と是正状況をマネジメントレビューで報告した
参考にした資料
JIS Q 27001:2023（ISO/IEC 27001:2022）情報セキュリティマネジメントシステム－要求事項
JIS Q 27001:2025（ISO/IEC 27001:2022/Amd 1:2024）追補1 気候変動対応
JIS Q 19011:2019（ISO 19011:2018）マネジメントシステム監査のための指針
ISO/IEC 17021-1:2015 適合性評価－マネジメントシステムの審査及び認証を行う機関に対する要求事項
一般社団法人情報マネジメントシステム認定センター（ISMS-AC）の公表資料
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
Admina Team
情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。
