29 人が閲覧(直近 30 日) セキュリティ

ISMSの不適合とは?重大・軽微(マイナー指摘)の判定基準と是正処置報告書の書き方・記入例

ISMSの不適合とは?重大・軽微(マイナー指摘)の判定基準と是正処置報告書の書き方・記入例

ISMSの不適合とは、ISO/IEC 27001の要求事項や自社で決めたISMSのルールを満たしていない状態のことです。内部監査でも認証審査でも指摘されうるもので、指摘を受けた組織は、目の前の問題を直す「修正」と影響への対処を行い、原因を取り除く「是正処置」の必要性を評価して必要な処置を実施し、その記録を残します。この記事では、不適合の定義、重大・軽微・改善の機会(OFI)の分け方、審査前に確認したい条項別の不適合例と2022年版の変更点、認証審査で不適合が出たあとの期限、是正処置報告書の書き方と記入例を、規格と認証機関のルールの条文に沿って整理します。

まとめ:ISMSの不適合対応と是正処置報告書の要点

  • 定義:不適合は「要求事項を満たしていないこと」(JIS Q 27000 3.47)。規格本文だけでなく、適用宣言書で採用した管理策や社内規程に反している状態も含みます。
  • 対応の型:修正で不適合そのものを除去し、原因を除去する是正処置が必要かを評価したうえで、必要な処置で再発を防ぎます。ISO/IEC 27001:2022では箇条10.2「不適合及び是正処置」が根拠です。
  • 重大と軽微(メジャーとマイナー)の境目:ISMSが意図した結果を達成する能力に影響を与えるかどうか(JIS Q 17021-1 3.12/3.13)。同じ要求事項で軽微な不適合が重なると、重大に格上げされることがあります。
  • 審査後の扱い:重大な不適合は、認証機関が修正と是正処置の実施を検証するまで認証が決まりません。初回審査では第二段階の最終日から6か月以内に検証できなければ第二段階のやり直しです。軽微な不適合は、是正処置の計画が容認されれば認証の判定に進めます。
  • 審査前に確かめる箇所:記録などの証拠で運用を確かめる条項(リスクアセスメントの再実施、内部監査、マネジメントレビュー、アクセス権の見直しなど)と、2022年版で新設された4.2 c)・6.3や新しい管理策11個、2024年の追補で4.1に加わった気候変動の判断です。
  • 報告書に書くこと:不適合の内容と根拠の要求事項、修正、原因、類似の不適合の有無、是正処置と期限・責任者、有効性の確認結果。「類似の不適合の有無」は箇条10.2 b) 3)が明確にするよう求めている事項です。

以下、定義、判定基準、審査前の確認事項、審査後の流れ、報告書の書き方の順に説明します。

ISMSの不適合の定義と修正・是正処置の違い

不適合の定義:要求事項を満たしていないこと

用語を定める規格JIS Q 27000:2019(ISO/IEC 27000:2018)は、不適合を「要求事項を満たしていないこと」と定義しています(3.47)。ISMSで要求事項にあたるのは、ISO/IEC 27001の本文(箇条4〜10)だけではありません。リスク対応で選んだ管理策(附属書A以外から選んだ独自の管理策を含む)、組織が自ら定めた規程や手順、ISMSで扱うと決めた利害関係者の要求事項(4.2)も含まれます。内部監査の条文(箇条9.2)も、「組織自体が規定した要求事項」と「この規格の要求事項」の両方への適合を確かめるよう求めています。

たとえば、アクセス権管理規程に「退職日当日にアカウントを無効化する」と書いてあるのに、退職者のアカウントが2週間残っていれば、規格の文言に直接反していなくても社内規程に対する不適合です。反対に、決めるべきルールが決まっていない状態(リスクアセスメントの基準が文書化されていない等)は、規格本文に対する不適合になります。

修正と是正処置の違い:除去の対象となる不適合と原因

JIS Q 27000は、修正を「検出された不適合を除去するための処置」(3.16)、是正処置を「不適合の原因を除去し,再発を防止するための処置」(3.17)と定義しています。違いは除去する対象です。先の例なら、残っていたアカウントを無効化するのが修正、退職情報が情報システム部門に届かない仕組みを直すのが是正処置です。

退職情報の連携不備を残したまま修正だけで終えると、次の退職者でも無効化漏れが再発するおそれがあります。逆に、影響が小さく原因も明らかな不適合なら、是正処置の必要性を評価した結果「修正で足りる」と判断することも規格上はありえます(10.2 b)は「処置をとる必要性を評価する」と書いています)。その判断と理由は記録に残します。

箇条番号の入れ替え:2013年版10.1から2022年版10.2へ

2013年版(JIS Q 27001:2014)では「10.1 不適合及び是正処置」「10.2 継続的改善」の順でしたが、2022年版(JIS Q 27001:2023)では「10.1 継続的改善」「10.2 不適合及び是正処置」と順序が入れ替わりました。求められる事項は変わっていません。2013年版の様式を使い続けている場合は、報告書や手順書の引用条番号を10.2に直しておきます。2013年版の認証の移行期限は、ISMS-ACの移行に関する文書が定めた2025年10月31日で終わっているため、2026年の審査はすべて2022年版(気候変動に関する追補Amd 1:2024を含む)が前提です。規格全体の構成はISO27001とは?ISMS認証の全体像・2022年版の管理策と取得手順を実務目線で解説で整理しています。

予防処置の条項が無い理由:2013年版でのリスク対応への統合

ISMS規格に「予防処置」の独立した条項があったのは2005年版(JIS Q 27001:2006)の8.3までです。JIPDECの改正解説資料によると、8.3は「起こり得る不適合の原因を除去する処置を決定しなければならない」としていました。2013年版からは、まだ起きていない問題への手当ては箇条6.1「リスク及び機会に対処する活動」で扱う構成になり、2022年版もこれを引き継いでいます。「2022年版で予防処置が無くなった」という説明を見かけますが、無くなったのは2013年版の時点です。

そのため、ISMSの是正処置報告書に「予防処置」欄を設ける必要はありません。ただし2013年版の10.1 b) 3)と2022年版の10.2 b) 3)は、同じ不適合が他の部署やシステムで起きていないか、起きうるかを明確にすることを求めています。予防処置の考え方の一部は、この「類似の不適合」の確認として是正処置の中に残っています。

是正措置・CAR・不適合報告書:呼び名の整理

ISMSのJIS規格が使う用語は「是正処置」(corrective action)です。「是正措置」は表記ゆれです。書類の名前も「是正処置報告書」「不適合報告書」「是正報告書」「CAR(Corrective Action Report)」と組織や認証機関で異なりますが、規格は様式も名称も定めていません。求められているのは、10.2 f)とg)が示す「不適合の性質及びとった処置」と「是正処置の結果」を文書化した情報として残すことです。

箇条10.2が求める7つの事項と報告書の欄の対応

是正処置報告書の欄は、ISO/IEC 27001の箇条10.2の条文から逆算すると過不足なく決められます。条文が組織に求めているのは次の7つです。

条文 求めていること 報告書の欄
a) 1) 不適合を管理し修正する 修正(応急処置)
a) 2) 不適合で起きた結果に対処する 影響範囲と対処
b)・b) 1)〜2) 不適合と原因を調べ、原因除去の必要性を評価する 不適合の内容・原因・処置の必要性
b) 3) 類似の不適合の有無・発生可能性を明確にする 類似の不適合の確認
c) 必要な処置を実施する 是正処置・期限・責任者
d) 是正処置の有効性をレビューする 有効性の確認
e) 必要ならISMSを変更する 規程・手順の改訂

このほか、是正処置は「検出された不適合のもつ影響に応じたもの」でなければならず、f)不適合の性質及びとった処置と、g)是正処置の結果を証拠として残す必要があります。市販の様式やISO 9001向けの雛形を採用するときは、b) 3)の類似の確認と、e)のISMS自体の変更を書く欄があるかを確かめます。退職者アカウントの例でいえば、「同じ手順で管理している他のシステム(クラウドサービスや共有アカウント)でも無効化漏れがないか」を確かめた結果が b) 3)にあたり、アクセス権管理規程の改訂が e)にあたります。

重大な不適合・軽微な不適合・改善の機会の判定基準

重大と軽微を分ける基準:意図した結果を達成する能力への影響

重大・軽微の区分は、ISO/IEC 27001ではなく、認証機関が従う規格JIS Q 17021-1:2015(ISO/IEC 17021-1:2015)が定めています。重大な不適合は「意図した結果を達成するマネジメントシステムの能力に影響を与える不適合」(3.12)、軽微な不適合は「能力に影響を与えない不適合」(3.13)です。英語の原文はmajor nonconformity/minor nonconformityで、現場で「メジャー」「マイナー指摘」と呼ばれるのはこの2区分です。JQAのようにカテゴリーA・Bと呼ぶ認証機関もあります。注記では、重大に分類されうる例として「効果的なプロセス管理が行われているか、又は製品若しくはサービスが規定要求事項を満たしているかについて、重大な疑いがある」場合を挙げています。

区分 判断の目安 ISMSでの例
重大な不適合 仕組みが機能していない 内部監査を1回も実施していない
重大な不適合 要求事項が丸ごと欠けている リスクアセスメントが未実施
軽微な不適合 仕組みはあるが一部で守られていない 棚卸し記録が1回分欠けている
軽微な不適合 記録や文書の部分的な不備 適用宣言書の版数が古い

認証機関の規則はもう少し具体的です。JQAの審査登録規則(第20版)は重大な不適合と判断する事例として、手順が完全に欠落している、全く機能していない、類似の不適合がマネジメントシステム全体に存在するといった場合に加え、ISO/IEC 27001に固有の例として「明らかに著しい情報セキュリティ上のリスクが存在し、管理できるにもかかわらず、リスクアセスメントに取上げられていない場合」を挙げています。

表の例は区分の考え方を示すもので、同じ事象でも範囲や頻度によって判定は変わります。最終的に区分を決めるのは審査チームで、最終会議の前に不適合を分類することが17021-1の9.4.6で求められています。

軽微な不適合が重大に格上げされるケース

17021-1の3.12の注記は、もう一つの例として「同一の要求事項又は問題に関連する軽微な不適合が幾つかあり、それらがシステムの欠陥であることが実証され、その結果重大な不適合となるもの」を挙げています。アクセス権の棚卸し漏れ、退職者アカウントの残存、特権IDの承認記録の欠落が同じ審査で見つかれば、個々は軽微でも「アクセス制御の仕組みが機能していない」として重大と判定されうるということです。

前回の維持審査で指摘された軽微な不適合が同じ形で再発している場合も、是正処置が有効でなかった証拠になります。軽微だからと修正だけで閉じる運用は、次の審査で重大な不適合を招く典型的な経路です。

改善の機会(OFI)・観察事項と不適合の境界

改善の機会はOFI(Opportunity for Improvement)と略されます。「観察事項」「改善の機会」「推奨事項」は認証機関によって呼び名が違い、17021-1にも定義はありません。17021-1が定めているのは扱いのルールで、9.4.5.2は改善の機会を特定し記録してもよいとしつつ、「不適合となる審査所見は,改善の機会として記録してはならない」としています。つまり改善の機会として書かれた所見は、審査チームが要求事項違反ではないと判断したものです。

対応するかどうかは組織の判断に委ねられますが、放置した結果、次の審査で要求事項違反の状態になっていれば不適合として指摘されます。対応しないと決めた改善の機会も、理由を添えてマネジメントレビューに報告しておくと、判断の経緯を説明できます。

内部監査の所見区分:組織が監査プログラムで決める基準

ISO/IEC 27001の箇条9.2(内部監査)には、所見を重大・軽微に分けよという要求はありません。区分するかどうか、何段階にするかは組織が監査プログラムの中で決めます。認証審査と同じ「重大・軽微・改善の機会」の3段階にそろえておくと、内部監査の所見と認証審査の所見を同じ台帳で比較できます。内部監査の進め方そのものはISMSの内部監査とは?箇条9.2の要求事項と進め方・管理策別の質問例で扱っています。

ISMS審査前の確認事項:条項別の不適合例と2022年版の変更点

記録などの証拠で運用を確かめる条項と管理策

ISO/IEC 27001には、「あらかじめ定めた間隔で」実施することや、結果を「証拠として,文書化した情報を利用可能な状態にしなければならない」とする箇所が多くあります。2022年版では、この言い回しが9.1・9.2.2・9.3.3・10.2でそろえられました(ISMS-ACが掲載するIAF MD 26の日本語訳 2.2)。審査では、記録の有無に加えて、その内容が要求事項への適合を裏付けるかを確認します。以下の附属書Aの例は採用した管理策を前提とし、必要な記録は自社の規程や手順も踏まえて判断します。

箇条・管理策 条文が求めていること 不適合になる状態の例
6.1.2・8.2 定めた間隔又は重大な変更の提案・発生時の評価 重大な組織変更時にリスクアセスメントを実施していない
6.1.3 d) 適用宣言書(管理策の要否と理由) 除外の理由が実態と合わない
7.2 力量の証拠の保持 必要な力量を裏付ける文書化した情報が無い
9.1 監視・測定の結果の保持 指標を決めたが測定結果が無い
9.2 計画した間隔での内部監査 監査プログラムどおり実施していない
9.3 マネジメントレビューの結果の保持 レビュー結果を裏付ける文書化した情報が無い
10.2 是正処置の結果の保持 前回の是正処置の有効性が未確認
附属書A 5.18 アクセス権の提供・レビュー・変更・削除 定期レビューの記録が無い
附属書A 5.19〜5.22 供給者関係のセキュリティと監視 委託先の評価の記録が無い

重大・軽微のどちらになるかは、欠けている範囲と程度により前の章の基準で決まります。審査前の点検では、適用される要求事項に対応する記録を1件ずつ確認し、不足があれば代替の証拠の有無と、要求事項を満たしているかを調べます。

2022年版と追補1(気候変動)で増えた要求事項

2013年版の手順書や様式を使い続けている組織で見落としやすいのは、2022年版で新しく加わった要求事項です。IAF MD 26の2.2が挙げる主な変更点のうち、組織の作業が増えるのは次の点です。

  • 4.2 c)の新設:利害関係者の要求事項のうち、ISMSを通して取り組むものを決定する。利害関係者と要求事項の一覧はあっても、どれをISMSで扱うかを決めていなければ、4.2 c)を満たしたと説明できません。
  • 6.3「変更の計画策定」の新設:ISMSの変更が必要と決定したときは、計画的な方法で行う。組織変更やクラウド移行に合わせて規程を改めたものの、いつ・誰が・何を変えるかを計画せずに進めた場合が該当しえます。
  • 8.1の対象の変更:「外部委託したプロセス」が「外部から提供されるプロセス、製品又はサービス」に広がった。業務の委託先だけでなく、ISMSに関連するSaaSなどの外部サービスも管理の対象として説明できる必要があります。
  • 附属書Aの再編:114管理策から93管理策へ再編され、うち11が新規です。JIPDECのISMSユーザーズガイド(2025年3月)が挙げる新規管理策は、5.7 脅威インテリジェンス、5.23 クラウドサービスの利用における情報セキュリティ、5.30 事業継続のためのICTの備え、7.4 物理的セキュリティの監視、8.9 構成管理、8.10 情報の削除、8.11 データマスキング、8.12 データ漏えい防止、8.16 監視活動、8.23 ウェブフィルタリング、8.28 セキュリティに配慮したコーディングです。

適用宣言書は、必要な管理策と採用の理由、実施しているかどうか、附属書Aの管理策を除外した理由を含むものです(6.1.3 d))。2013年版の適用宣言書を引き継いだ場合は、新規の11管理策についても要否を検討し、採用・除外の理由を説明できるようにします。管理策ごとに行を設ける様式までは要求されていません。採用した管理策の運用例は、脅威インテリジェンス(ISMS管理策5.7)とは|要求事項・情報源・審査証跡を実務解説とISMSの構成管理(管理策8.9)とは?構成記録とベースラインの作り方・変更管理との違いで、審査で見られる証跡まで扱っています。

2024年2月23日に発行された追補(ISO/IEC 27001:2022/Amd 1:2024、JISはJIS Q 27001:2023/AMENDMENT 1:2025)は、4.1に「The organization shall determine whether climate change is a relevant issue.」(気候変動が関連する課題かどうかを決定する)を加え、4.2に利害関係者が気候変動に関する要求事項をもつことがあるという注記を加えました。IAFとISOの共同声明は、認証機関が発行時点からこの文言を審査に含めるとしています。求められているのは「関連するかどうかの決定」で、関連しないと決めることも認められます。決めた結果と理由を、4.1の課題の一覧などで示せるようにしておきます。

認証審査で不適合が出たあとの期限と流れ

回答期限の決まり方:認証機関の規則と最終会議での合意

是正処置の回答期限は国際規格で一律に決まっているわけではありません。17021-1の9.4.9は、認証機関が「定めた期間内に」原因の分析と、実施した修正・是正処置またはその計画を回答するよう求めることとしており、日数は各認証機関の規則で決まります。審査の最後に開く最終会議では、不適合を理解できる方法で示し、対応の期限について合意することが求められており(9.4.7.1)、最終会議の要素にも「審査中に特定された全ての不適合の修正及び是正処置に関する計画を提示する期限」が含まれています(9.4.7.2 d))。

具体的な日数の例として、日本品質保証機構(JQA)の「マネジメントシステム審査登録規則」第20版(2026年4月1日発効・2026年10月時点の最新版)は、ISO/IEC 27001について次のように定めています。

審査の種類 区分 提出物と期限 その後
登録・定期・更新審査 軽微(カテゴリーB) 是正処置計画書または報告書を30日 次回審査で実施状況を確認
登録審査 重大(カテゴリーA) 是正処置を実施のうえ報告書 限定再審査または全面再審査
定期審査 重大(カテゴリーA) 是正処置報告書を原則90日以内 特別審査で登録継続を判定
更新審査 重大(カテゴリーA) 是正処置を実施のうえ報告書を原則90日以内 限定再審査または全面再審査

他の認証機関では日数や呼び名が異なるため、自社の認証機関の規則を確認してください。重大な不適合は、期限までに「計画」ではなく「実施した結果」を出す必要がある点が共通しています。

見落とされやすいのが、審査員は原因も解決策も教えてくれないという点です。9.4.5.3は審査員に「不適合の原因又はその解決法を提案することは控えなければならない」と定め、9.4.8.1も審査報告書で「具体的な解決策を提言してはならない」としています。審査員とは不適合の根拠になった要求事項と客観的証拠について協議できますが(9.4.5.3)、原因や解決策の提案は受けられません。原因分析は組織の責任で行い、必要なら認証審査に関与しない外部の専門家の支援を受けます。

重大な不適合と軽微な不適合で違う「認証の判定」までの条件

17021-1の9.5.2は、認証の判定を行う前に、認証機関が次の点を確認するよう求めています。

  • 全ての重大な不適合について、修正と是正処置をレビューし、容認し、検証したか
  • 全ての軽微な不適合について、修正と是正処置の計画をレビューし、容認したか

重大な不適合は「実施して効果が確かめられた」ところまで進まないと認証が決まらず、軽微な不適合は「計画が妥当と認められた」段階で判定に進めるという違いです。軽微な不適合の是正処置の実施状況は、次回以降の審査で確認されます。

初回審査の6か月ルールと、更新審査で認証が延長されない条件

初回認証では、認証機関が第二段階の最終日から6か月以内に重大な不適合の修正と是正処置の実施を検証できない場合、認証の推薦を行う前に第二段階をやり直さなければなりません(9.5.3.2)。更新審査では、重大な不適合の修正と是正処置の実施を検証できなければ、認証の有効期限は延長されません(9.6.3.2.4)。有効期限切れ後の6か月の扱いや維持審査で毎回確認される項目は、ISMS維持審査とは?更新審査との違い・毎回確認される8項目と有効期限のルールにまとめています。

有効性の検証方法と、認証の一時停止につながる状態

認証機関は、提出された修正・原因・是正処置を容認するかを決め、有効性を検証します(9.4.10)。検証の方法は、提出した記録の書面レビューが基本で、必要なら追加の全面的な審査、追加の限定的な審査、次回審査での確認が選ばれます。どの方法になるかは認証機関から通知されます。

不適合の指摘を受けたこと自体で、認証がその場で取り消されるわけではありません。9.6.5.2が一時停止の例に挙げるのは、「常態化した不適合又は深刻な不適合」がある場合、維持審査や再認証審査を要求された頻度で受け入れない場合、組織が自ら一時停止を求めた場合です。一時停止の原因を認証機関の定める期間内に解決できなければ、取消しか認証範囲の縮小になります。取消しの事由は不適合の件数だけで決まるものではなく、認証機関の規則が別に定めています。

是正処置報告書の書き方と記入例

是正処置報告書の欄ごとの書き方:事実・根拠・原因の切り分け

主な欄の書き方は次のとおりです。先の対応表にある修正、影響への対処、規程・手順の改訂の欄も、あわせて記載します。書き方で差が出るのは最初の3欄です。

  • 不適合の内容:「いつ・どこで・何が・どれだけ」を事実だけで書く。評価語(不十分、徹底されていない)は使わない。
  • 根拠の要求事項:規格の箇条番号、附属書Aの管理策番号、社内規程の文書番号と条項を書く。17021-1の9.4.5.3が審査員に求めているのと同じ粒度です。
  • 原因:「確認不足」で止めず、知識・技能、作業負荷、手順・仕組みを調べ、証拠で確認できた原因を書く。
  • 類似の不適合の確認:確認した範囲と結果を書く。該当なしでも「どこを見て、無かった」と書く。
  • 是正処置・期限・責任者:処置ごとに期限と責任者を分ける。
  • 有効性の確認:確認する方法・時期・判定基準を先に決めて書き、結果は後から追記する。

以下の記入例2つは、書き方を示すための架空の事例です。原因欄の掘り下げにはなぜなぜ分析とは?5回のなぜで真因に迫る手順・事例・現場での進め方を解説の手順が使えます。なぜ起きたか(発生原因)と、なぜ気づけなかったか(流出原因)を分けると、両方に処置を打てます。

記入例1:退職者アカウントの無効化漏れ(認証審査の所見)

  • 不適合の内容:2026年7月末退職者5名のうち2名のクラウドストレージのアカウントが、審査日(9月10日)時点で有効のままだった。
  • 根拠の要求事項:ISO/IEC 27001:2022 附属書A 5.18(アクセス権)、アクセス権管理規程(ISMS-07)第6条「退職日当日に無効化する」。
  • 修正:9月10日に2アカウントを無効化。退職後のアクセスログを確認し、ログインが無いことを記録。
  • 原因:発生原因は、人事システムの退職登録が情報システム部門に通知されず、無効化が部門長からのメール依頼に頼っていたこと。流出原因は、月次のアカウント棚卸しの対象が社内ディレクトリのみで、クラウドサービスが含まれていなかったこと。
  • 類似の不適合の確認:同じ手順で管理している他のSaaS 11件と共有アカウントを9月12日に確認し、無効化漏れ1件(勤怠システム)を追加で発見・無効化。
  • 是正処置:退職登録を情報システム部門へ自動通知する設定(10月15日・人事部長)、棚卸し対象にSaaS全件を追加しISMS-07を改訂(10月31日・情報システム部長)。
  • 有効性の確認:11月・12月の退職者の無効化日を棚卸しで確認し、全件が退職日当日であることを判定基準とする(1月15日・ISMS管理責任者)。

この例では、類似の確認で1件の追加漏れが見つかっています。報告書にこの結果が書かれていると、原因分析が指摘された2件にとどまっていないことが読み手に伝わります。

記入例2:情報セキュリティ教育の未受講者(内部監査の所見)

  • 不適合の内容:2026年度上期の必須教育で、営業部の受講率が78%(45名中10名未受講)。期限の8月31日を過ぎても督促の記録がない。
  • 根拠の要求事項:ISO/IEC 27001:2022 箇条7.2(力量)・7.3(認識)、教育訓練規程(ISMS-04)第5条。
  • 修正:未受講者10名に9月末期限で受講を指示し、全員の受講完了を確認。
  • 原因:受講状況の確認が期限後の集計だけで、期限前に未受講者へ届く督促の手順が無かった。外勤者が多い部署ほど未受講が集中していた。
  • 類似の不適合の確認:全部署について期限時点の受講率と督促記録を確認し、受講率100%未達の部署の有無と、督促漏れの有無を記録する。
  • 是正処置:期限の2週間前と1週間前に未受講者と所属長へ自動で督促する設定を追加し、ISMS-04に督促の手順を追記(11月30日・人事部教育担当)。
  • 有効性の確認:2026年度下期の教育で全部署の受講率が期限内に100%となることを判定基準とする(2027年3月・内部監査責任者)。

容認されにくい是正処置報告書のパターン

17021-1の9.4.10で、認証機関は提出された修正・原因・是正処置を「容認するかどうか」を決めます。次の書き方は、それ自体が規格違反というわけではありませんが、10.2が求める原因の除去や有効性の確認を果たしたことが報告書から読み取りにくく、追加の説明や証拠を求められる原因になります。

  • 是正処置が「再教育」「注意喚起」だけ:原因が本当に知識不足なら教育は有効な処置です。しかし原因欄に「担当者の確認不足」と書いて教育だけで閉じると、手順や仕組みの欠けた箇所が残っていないかが説明されず、担当者が替われば再発するおそれがあります。
  • 類似の不適合の確認欄が空、または「なし」の一語:10.2 b) 3)の要求を満たしたかどうかが読み取れません。どの範囲を見たのかを書きます。
  • 有効性の確認日が是正処置の完了日と同じで、根拠が書かれていない:処置を実施したことと、原因が除去されたことは別です。自動化した設定の動作試験のように当日確認できる処置もありますが、運用で効果が出る処置は次の運用サイクル(翌月の棚卸し、次回の教育)の結果で確かめます。確認時期は処置の性質に合わせて決めます。
  • 規程を直さずに運用だけ変えている:10.2 e)のISMSの変更が必要なケースで手順書が古いままだと、担当者が替わった時点で元に戻ります。
  • 部門をまたぐ処置で期限と責任者が1つだけ:部門ごとに期限と責任者を分けておかないと、どこまで進んだかを証拠で示しにくくなります。

一方で、影響が小さく一度きりの誤記のような不適合に、大がかりなシステム改修を計画するのも過剰です。10.2は是正処置を「不適合のもつ影響に応じたもの」と定めています。処置の重さは影響の大きさに合わせます。

是正処置の台帳管理とマネジメントレビューへのつなぎ方

是正処置台帳の最小限の列

台帳そのものは規格の要求ではなく実務上の推奨ですが、10.2 f)・g)の記録を一覧にしておくと、報告書を1件ずつ作るだけでは見えない期限切れや未完了が把握できます。台帳には、管理番号、発見日、発見の経路(内部監査・認証審査・日常の点検・インシデント)、区分(重大・軽微・改善の機会)、根拠の要求事項、是正処置の期限、状態(対応中・有効性確認待ち・完了)の列を持たせます。件数が少ないうちは表計算ソフトで足ります。製造業で不適合管理をシステム化する場合の考え方は製造業の品質管理とは|受入・工程内・出荷検査と不適合管理をシステムで回す進め方が参考になります。

マネジメントレビューへの報告と、傾向の読み方

ISO/IEC 27001の箇条9.3は、マネジメントレビューで考慮する事項として、情報セキュリティパフォーマンスの傾向の一つに「不適合及び是正処置」を挙げています。台帳を根拠の要求事項ごとに集計すると、同じ管理策で繰り返し不適合が出ている箇所が見えます。そこが次に手を入れるべき仕組みで、17021-1が重大な不適合の例に挙げる「同一の要求事項に関連する軽微な不適合の重なり」を、審査の前に自分たちで見つけることにもなります。マネジメントレビューを含むISMS全体の回し方はISMSのPDCAサイクルを回す方法|各段階の作業と形骸化させない運用設計【2022年版】で解説しています。

ISMSの不適合に関するよくある質問

ISMSの不適合を指摘されると認証は取り消されますか?

不適合を指摘されたこと自体で直ちに取り消されるわけではなく、判断は不適合の内容と認証機関の規則によります。一時停止の対象になるのは、常態化した不適合や深刻な不適合がある場合、維持審査や更新審査を受け入れない場合などで(ISO/IEC 17021-1 9.6.5.2)、その原因を期限内に解決できなかったときに取消しか範囲の縮小になります。重大な不適合でも、期限内に修正と是正処置を実施し、認証機関がその有効性を検証して容認すれば、認証を維持できる道があります。

マイナー指摘(軽微な不適合)の是正期限はどれくらいですか?

国際規格に一律の日数はなく、認証機関が定めた期限に従います(ISO/IEC 17021-1 9.4.9)。たとえばJQAはISO/IEC 27001の軽微な不適合について、是正処置計画書または報告書の提出期限を30日としています。期限は審査の最終会議で示され、組織と審査チームが合意します。軽微な不適合は是正処置の計画が容認されれば認証の判定に進めますが、計画した処置の実施状況は次回の維持審査で確認されます。

観察事項は対応しなくてもよいのですか?

観察事項や改善の機会は要求事項違反ではないため(ISO/IEC 17021-1 9.4.5.2は不適合にあたる所見を改善の機会として記録することを禁じています)、是正処置の提出は求められません。ただし放置して要求事項を満たさない状態になれば、次の審査で不適合として指摘されます。対応しない場合も理由を記録しておきます。

修正と是正処置は両方必要ですか?

修正は目の前の不適合の除去、是正処置は原因の除去と再発防止で、目的が違います。ISO/IEC 27001 10.2 b)は原因を除去する処置の「必要性を評価する」と定めているため、影響が小さく原因が明らかな一過性の誤りなら修正だけで閉じる判断もありえますが、その判断と理由は記録に残します。認証審査で指摘された不適合では、認証機関が定めた期間内に原因の分析と、修正・是正処置またはその計画を回答することが求められます(ISO/IEC 17021-1 9.4.9)。

是正処置報告書のフォーマットは決まっていますか?

ISO/IEC 27001は様式を定めていません。求められているのは、不適合の性質、とった処置、是正処置の結果を文書化した情報として残すことです(10.2 f)・g))。認証機関が独自の様式を指定している場合はそれに従います。自社で作るなら、10.2 a)〜e)に対応する欄を持たせると、審査で求められる内容を漏れなく書けます。

関連記事

お気に入りに入れた記事の一覧

この記事は以下の記事からリンクされています

資料請求

今日のトレンド記事 直近 24 時間で、いつもより多く読まれている記事

  1. 2026.10.23 テックブログ Renta!不正アクセスでサービス停止:再開未定の現状と運営側の停止判断・証拠保全・段階的再開
  2. 2026.07.09 テックブログ Muse Imageとは?Metaの画像生成AIの使い方・API料金(1枚0.01ドル)と日本での提供状況【2026年10月】
  3. 2026.10.22 テックブログ Tomcatのバージョン一覧とサポート期限【2026年10月】最新版11.0.27、9.0系は2027年3月末終了・9.1系は2030年末まで
  4. 2026.10.23 テックブログ Splunk 脆弱性CVE-2026-76299:影響版の確認と10.2.8などへの更新手順
  5. 2026.10.24 テックブログ ブラストメール不正アクセス:配信先288件の漏えいと利用企業の報告・通知の手順

RELATED POSTS 関連記事

目次