箇条10 改善｜不適合と是正処置

「不適合が出た」と聞くと、ISMS担当者は身構えます。しかし規格の立場から見れば、不適合が見つかること自体は問題ではありません。見つかった不適合が、応急処置だけで閉じられ、同じことが翌年も起きている——これが問題です。

箇条10が扱うのはまさにこの部分です。応急処置と是正処置は別物であり、是正処置には原因の除去と有効性の確認まで含まれます。この区別が曖昧なまま是正処置報告書を書くと、審査で「原因分析が不十分」と指摘されます。実際、更新審査やサーベイランス審査で最も追及されるのが、前回の指摘が本当に再発しなくなったのかという点です。

本記事は、**箇条10（改善）**が求めることを、不適合の検出から是正処置の完了、有効性レビュー、そして継続的改善の記録までの流れとして整理したものです。

免責：本記事は一般的な情報提供です。規格の要求事項の解釈、認定・認証の取扱いは、ISO/IEC 27001（JIS Q 27001）の規格本文および認定機関・審査機関の公表資料が正本です。実際の運用判断はそれらに基づいて行ってください。

箇条10が求めていること

2022年版の箇条10は2つの項目で構成されます。10.1 が継続的改善、10.2 が不適合及び是正処置という順序です（2013年版は逆順でした。差分は ISO/IEC 27001:2022への移行で扱っています）。

項番	要求の趣旨
10.1 継続的改善	ISMSの適切性・妥当性・有効性を継続的に改善する
10.2 不適合及び是正処置	不適合が起きたとき、①それに対処して結果に対処し、②原因を除去する処置の必要性を評価し、③必要な処置を実施し、④有効性をレビューし、⑤必要ならISMSを変更する。不適合の性質・とった処置・是正処置の結果を記録する

ここで最も重要なのは、10.2 が2段構えになっていることです。

修正（応急処置）と是正処置の違い

	修正（correction）	是正処置（corrective action）
目的	起きてしまった事象そのものへの対処	原因を除去し、再発を防ぐ
時間軸	即時〜数日	数週間〜数か月
例：退職者のアカウントが残っていた	当該アカウントを削除する	退職手続と権限削除を紐づけ、月次で棚卸しする仕組みを作る
例：委託先チェックシートが未回収だった	該当社から回収する	回収期限のリマインド運用と、未回収時のエスカレーション先を決める
例：バックアップの復元テストが未実施だった	直ちにテストを実施する	年間計画に組み込み、実施責任者と代行者を指名する
記録	実施日と内容	原因分析、処置内容、有効性の確認結果
これだけで閉じると	審査で指摘される	適切に閉じられる

修正だけで是正処置報告書を閉じているケースは非常に多いです。 「該当アカウントを削除しました。以上」で終わっている報告書は、原因が除去されていないため、翌年また同じ不適合が出ます。

「原因を除去する処置の必要性を評価する」

規格は、すべての不適合に是正処置を打つことまでは求めていません。求めているのは必要性を評価することです。評価にあたっては、不適合をレビューし、原因を特定し、類似の不適合が存在するか／起こり得るかを判断します。

評価の結果「原因は一時的であり、再発の可能性は低い」と判断するのは正当な結論です。ただし、その判断の根拠を記録に残す必要があります。評価を省略したのか、評価した上で不要と判断したのかを、記録から区別できるようにしてください。

前段の箇条は箇条4｜組織の状況、箇条5 リーダーシップ、箇条6 計画、箇条7 支援、箇条8 運用、箇条9 パフォーマンス評価をご覧ください。ISMS全体の位置づけは ISMS（ISO/IEC 27001）とはにあります。

実務で作る成果物

箇条10で作るのは、基本的に不適合管理台帳と是正処置報告書の2つです。台帳で件数と状態を管理し、報告書で1件ごとの中身を記録します。

成果物	含める項目
不適合管理台帳	管理番号、検出日、検出源、不適合の概要、重大度、担当者、修正の完了日、是正処置の要否判断、是正処置の完了予定日と実績、有効性確認日、状態（対応中／完了）
是正処置報告書	不適合の事実（いつ・どこで・何が）、該当する規格要求または社内ルール、修正の内容と実施日、原因分析、類似事象の有無、是正処置の内容と期限、実施結果、有効性のレビュー方法と結果、ISMS文書の改訂有無

報告書の書き方は是正処置報告書の書き方で様式まで踏み込んで扱います。

不適合はどこから来るか

不適合の検出源を最初に列挙しておくと、台帳への登録漏れが減ります。

検出源	典型例	登録漏れの起きやすさ
内部監査	監査報告書に記載された不適合	低
外部審査	1次・2次審査、サーベイランス審査での指摘	低
セキュリティインシデント	誤送信、マルウェア感染、紛失、不正アクセス	中
監視・測定の結果	目標未達、しきい値超過	高（不適合として扱わず放置されやすい）
日常業務での気づき	手順書と実態の乖離、ルールが守れない事情	最も高い
利害関係者からの指摘	顧客監査、チェックシート回答時に露見した不備	高
法令・ガイドラインの改定	既存ルールが新要求を満たさなくなる	中

「日常業務での気づき」を拾える導線があるかどうかが、ISMSが生きているかどうかの分かれ目です。 誰でも起票できる簡易フォームを1つ用意し、事務局が振り分ける運用が現実的です。

有効性のレビューをどう行うか

是正処置を実施したら、有効だったかをレビューすることまでが要求です。ここが抜けている報告書が非常に多いので、様式に欄を設けてください。

レビューの方法は不適合の性質で選びます。

是正処置の種類	有効性の確認方法	確認時期の目安
手順やルールの改訂	改訂後の運用記録をサンプリングし、新ルールどおりか確認する	実施から1〜3か月後
仕組み・ツールの導入	導入後の検知件数や自動化率を測定する	実施から1〜3か月後
教育・周知	理解度テスト、または対象業務の記録で誤りが減ったか確認する	次回教育または四半期後
体制・役割の変更	変更後に該当プロセスが完了しているか確認する	1サイクル後

「対策を実施したので有効」は有効性レビューではありません。 実施したことの確認は処置の完了確認であり、有効性は結果が変わったかで見ます。

継続的改善を記録に残す

10.1 の継続的改善は、10.2 のような手順が規定されていないため、「何を記録すればよいか分からない」という相談が多い項目です。実務的には、次の3つで十分に説明できます。

マネジメントレビューのアウトプット — 改善の機会とISMS変更の決定。これが継続的改善の中心的な証跡になります
情報セキュリティ目的の見直し履歴 — 前期の達成状況を踏まえて次期の目的を変えた記録
改善提案の受付と処理の記録 — 不適合に至らない気づきをどう扱ったか

逆に言えば、マネジメントレビューの議事録に決定事項がなければ、継続的改善の証跡が薄くなります。箇条9と箇条10はここで接続します。詳しくはマネジメントレビューの進め方と議事録をご覧ください。

つまずきやすい点

1. 原因分析が「担当者の確認不足」で止まる

最も多いパターンです。原因を人に帰着させると、対策は「周知徹底する」「注意する」になり、再発します。

原因分析を一段深くするには、「なぜその人はそうできなかったのか」を問うのが有効です。

浅い原因	一段深い原因	導かれる是正処置
担当者が権限削除を忘れた	退職手続に権限削除のステップが組み込まれていない	退職チェックリストに権限削除を追加し、人事と情シスの引き渡しを定義する
担当者が手順を知らなかった	手順書が更新後に周知されていない	文書改訂時の周知フローを定め、改訂履歴に周知日を記録する
忙しくて実施できなかった	実施頻度が業務量に対して過大	頻度を見直し、自動化可能な部分をツール化する
ルールを守ると業務が回らない	ルールが実態に合っていない	実態に合わせてルールを改訂する（例外の手順化を含む）

最後の行が重要です。 守れないルールは是正の対象が「人」ではなく「ルール」です。ルールを現実に合わせて改訂することは、水準を下げることではなく、運用可能な統制に変えることです。

2. 類似事象の確認をしていない

10.2 は、類似の不適合が他に存在するか、または起こり得るかの判断を求めています。1件だけ直して閉じると、同じ構造の問題が別部門に残ります。

例：ある部門で委託先チェックシートが未回収だった場合、他部門の委託先も同じ状態でないかを確認し、確認した事実を報告書に書きます。

3. 期限が切られていない／切られたが守られない

是正処置に期限がないと、台帳の「対応中」が積み上がり、審査で「改善が機能していない」と見られます。

現実的な運用は、期限を延長する手続きを先に決めておくことです。延長理由と新しい期限を記録して承認を得る形にすれば、期限超過のまま放置されることがなくなります。

4. 審査の指摘だけが台帳に載る

外部審査の指摘だけが不適合として管理され、内部で見つけたものが台帳にない組織があります。これは審査員から見ると、内部で問題を見つけられていないというシグナルになります。

内部監査の不適合、インシデント、目標未達を同じ台帳で管理すると、件数の内訳そのものがISMSの成熟度を示す材料になります。

5. インシデント対応と是正処置が分断されている

セキュリティインシデントが起きたとき、復旧対応（修正）は必死に行われますが、それが不適合として台帳に登録されず、原因除去まで進まないことがあります。

インシデント対応手順の最後のステップに「不適合としての起票」を入れておくと分断が防げます。インシデント手順の設計はインシデント対応手順の作り方をご覧ください。

審査で見られること

箇条10は、初回審査よりもサーベイランス審査・更新審査で重く見られる領域です。前回の指摘が本当に閉じたのかが焦点になるためです。

見られる観点	典型的な確認のされ方	準備
修正と是正処置の区別	「この報告書の処置は、原因を除去していますか」	報告書の様式で「修正」と「是正処置」を別欄にする
原因分析の深さ	「なぜこの原因に至ったと判断しましたか」	分析の過程（確認した記録、ヒアリング先）を残す
類似事象の確認	「他部門では同じことは起きていませんか。確認しましたか」	確認範囲と結果を報告書に明記する
有効性のレビュー	「この処置が有効だったと、どうやって確認しましたか」	確認方法・時期・結果を欄として持つ
前回指摘の再発	「前回のサーベイランスで指摘した点は、その後どうなりましたか」	前回指摘を台帳で追跡し、有効性確認まで完了させる
台帳の網羅性	「不適合は外部審査由来のものだけですか」	内部監査・インシデント・目標未達も同じ台帳に載せる
継続的改善の証跡	「この1年でISMSをどう改善しましたか」	マネジメントレビューの決定事項と実施状況を示す

前回指摘の是正が完了していない状態で更新審査を迎えるのは、最も避けたいパターンです。準備の進め方はサーベイランス審査（維持審査）の準備、更新審査（3年目）の準備、典型的な指摘は審査でよくある不適合と対策にまとめています。

ヘルスケア企業での具体例

インシデントの重大度定義に医療情報を組み込む

ヘルスケア企業では、同じ「メール誤送信」でも、宛先と内容によって影響が大きく変わります。医療情報や要配慮個人情報が含まれる場合を別区分にしておくと、是正処置の優先度判断がぶれません。個人情報保護委員会への報告義務が生じる類型は個人情報漏えい時の報告義務で扱っています。

顧客医療機関への報告と是正処置報告書を接続する

医療機関との契約では、インシデント時の報告義務が定められていることが一般的です。顧客向け報告書と社内の是正処置報告書を別々に作ると内容がずれます。 社内の是正処置報告書を正とし、顧客向けはその抜粋として作る運用にすると、記載の齟齬が起きません。

委託先で起きた不適合を自社の台帳に載せる

クラウド事業者や保守委託先で発生した事象は、自社の不適合として扱うかどうかの判断が必要です。自社の管理策（委託先管理）の有効性に関わるため、少なくとも評価した記録は残すべき領域です。委託先管理の実務は外部委託先管理｜チェックシートと契約条項をご覧ください。

ガイドライン改定を不適合の検出源として扱う

3省2ガイドラインの改定により、既存の手順が新しい要求を満たさなくなることがあります。これを「改定対応プロジェクト」として別枠で進めると、ISMSの改善記録に残りません。不適合または改善の機会として台帳に載せると、箇条10の証跡になります。ガイドラインの動向は 3省2ガイドラインとはが入口になります。

ランサムウェアのような大規模事象は是正処置が長期化する

復旧が終わっても、原因除去（ネットワーク分離、認証強化、バックアップ設計の見直し）には数か月かかります。長期の是正処置を1件の報告書で抱え込まず、フェーズごとに分割して期限を管理するのが実務的です。医療機関側の初動はランサムウェア被害時の初動で扱っています。

まとめ

箇条10について押さえるべき点は次のとおりです。

修正（応急処置）と是正処置（原因の除去）は別物。 修正だけで報告書を閉じると、審査で指摘され翌年再発する
規格が求めるのは是正処置の実施そのものではなく、原因を除去する処置の必要性を評価すること。不要と判断した場合もその根拠を記録する
有効性のレビューまでが是正処置。 「実施したので有効」ではなく、結果が変わったかを確認する
原因分析は「担当者の確認不足」で止めない。なぜその人がそうできなかったのかまで降りる。守れないルールは、ルール側を直す
類似事象の確認（他に存在するか、起こり得るか）を報告書に明記する
不適合台帳には内部監査・インシデント・目標未達・日常の気づきも載せる。外部審査由来だけだと内部で問題を見つけられていないと見られる
継続的改善の証跡は、マネジメントレビューの決定事項と実施状況が中心になる

ポテックは、ヘルスケア領域に特化してISMS認証取得と運用を支援しています。是正処置報告書の様式設計、原因分析の伴走、インシデント対応と不適合管理の接続まで支援可能です。2年目以降の運用支援では、前回審査の指摘を確実に閉じるところまで一緒に進めます。

支援内容と料金は ISMS認証取得支援サービスをご覧ください。個別のご相談はお問い合わせから承ります。

参考・出典

※規格の要求事項の解釈および認証の取扱いは、規格本文と認定機関・審査機関の公表資料をご確認ください。漏えい等の報告義務の要否は個別の事案により判断が異なります。