是正処置報告書の書き方

是正処置報告書は、ISMSの記録の中で最も多く書かれ、最も中身が薄くなりやすい文書です。内部監査で不適合が出るたび、インシデントが起きるたび、審査で指摘を受けるたびに1枚書く。年に10枚、20枚と積み上がるうちに、様式を埋めること自体が目的になり、「原因：担当者の認識不足」「是正処置：注意喚起を実施」という定型文が並ぶようになります。

この定型文が問題なのは、審査で指摘されるからではありません。同じ不適合が翌年も再発するからです。認識不足を原因とし、注意喚起を対策とする限り、人が入れ替わり記憶が薄れれば必ず同じことが起きます。

是正処置の本質は、「その人が悪かった」から「その仕組みだと必ずそうなる」へ、問いの立て方を移すことです。これができている組織は、是正処置の件数が年を追って減り、できていない組織は同じ件数を延々と繰り返します。

本記事では、応急処置と是正処置の違い、原因分析の進め方、有効性の確認、審査での指摘を是正に落とす流れ、そして報告書の記載例を扱います。箇条10の要求全体は 箇条10 改善｜不適合と是正処置、不適合が発生する内部監査の進め方は 内部監査の進め方｜計画・チェックリスト・報告、規格全体は ISMS（ISO/IEC 27001）とは をご覧ください。

免責：本記事は一般的な情報提供です。規格の要求事項の解釈、認定・認証の取扱いは、ISO/IEC 27001（JIS Q 27001）の規格本文および認定機関・審査機関の公表資料が正本です。不適合の是正期限や様式は審査機関ごとに異なります。実際の対応は審査機関の指示に従ってください。

なぜここでつまずくのか

応急処置で終わっている

誤送信が起きた → 送信先に削除を依頼した → 完了。これは応急処置（修正）であって、是正処置ではありません。その事象の後始末をしただけで、次に同じことが起きる確率は1ミリも下がっていません。 報告書の「是正処置」欄に後始末が書かれているケースは非常に多く見られます。

原因が人に帰着している

「担当者の確認不足」「手順の理解不足」「意識の低さ」。これらは原因ではなく、事象の言い換えです。確認を怠れる設計になっていたこと、手順が理解されない形で書かれていたことが原因であり、そこまで降りなければ対策が設計できません。

なぜなぜが3回で止まる

「なぜ誤送信したか → 宛先を確認しなかったから → なぜ確認しなかったか → 急いでいたから → なぜ急いでいたか → 業務量が多いから」。ここで止まって「業務量の適正化」という実行不能な対策が出てきます。問いの方向が1本しかないことが原因です。

有効性の確認が「実施しました」で終わっている

対策を実施したことの確認と、対策が効いたことの確認は別です。規格が求めているのは後者ですが、報告書の「有効性の確認」欄に「◯月◯日に研修を実施した」と書かれているケースが大半です。

審査の指摘を写経している

審査報告書に書かれた指摘文をそのまま「不適合の内容」欄に貼り付け、原因も対策も表層的に書いて提出する。審査機関が見ているのは、指摘を自社の問題として捉え直したかどうかであり、写経は逆効果になります。

何を決めるのか

応急処置と是正処置の違い

規格の考え方では、不適合が起きたとき、まずそれに対処し、結果に対応すること（＝応急処置・修正）、次に原因を除去する処置が必要かを評価し、必要なら実施すること（＝是正処置）が求められます。この2つは目的も時間軸も異なります。

「是正処置は必ず実施しなければならない」わけではない点は、実務上重要です。 規格が求めているのは、原因を除去する処置の必要性を評価することです。軽微で一過性の事象について、費用対効果から是正処置を行わないという判断はありえます。ただし、判断した理由を記録に残すことが条件です。「評価した結果、是正処置は不要と判断した。理由は◯◯」と書かれた報告書は、空欄の報告書よりはるかに評価されます。

なお、2022年版の規格では、旧版にあった「予防処置」という独立した要求は置かれていません。予防に相当する機能は、箇条6のリスクおよび機会への取組みが担う構造になっています。したがって、「他の場所でも同じことが起きうるか」という横展開の検討は、是正処置の中で行います。

是正処置報告書に持つ項目

この様式の中で、多くの組織が持っていないのが「是正処置の要否判断」と「横展開の検討」の2欄です。 この2つを様式に入れるだけで、報告書の質は目に見えて変わります。

実務の手順

1. 事実を確定する

最初に書くのは、評価を含まない事実です。

• 悪い例：「委託先管理がずさんで、評価が行われていなかった」
• 良い例：「2026年3月時点で、委託先台帳に登録された Tier 1 委託先12社のうち、5社について2025年度の年次評価記録が存在しなかった。規程『委託先管理規程』第7条は Tier 1 委託先の年1回の評価を定めている」

該当する要求事項を特定することで、「何に対して不適合なのか」が明確になります。規格の箇条なのか、自社規程なのか、契約条項なのか。ここが曖昧だと、是正のゴールも曖昧になります。

2. 応急処置を実施する

事象の影響を止め、後始末をします。上の例なら、未評価の5社について速やかに評価を実施することが応急処置にあたります。この時点では、まだ原因は解消されていません。

情報の漏えいや外部への影響を伴う場合は、応急処置の前にインシデント対応手順に乗せます。外部通知の判断を含むためです（インシデント対応手順の作り方（事業者））。

3. 原因を分析する

ここが本記事の中心です。なぜなぜ分析は有効ですが、それだけでは止まります。 次の3つの工夫で、分析の質が変わります。

工夫1：問いを2方向に分ける

「なぜ発生したか」だけでなく、**「なぜ検出できなかったか」**を並行して問います。

この2方向を分けると、対策が2種類出てきます。 発生側の対策（評価の時期を規程で固定し、年間計画に組み込む）と、検出側の対策（台帳で期限超過を可視化し、事務局が四半期で確認する）です。片方だけでは、いずれ同じことが起きます。

工夫2：3つの層に降ろす

原因を、技術・運用・管理の3層で確認します。

3層すべてに原因があることは珍しくありません。 どれか1つだけを書いた報告書は、たいてい分析が浅いか、対策が打ちやすい層だけを選んでいます。

工夫3：「人」で止まったら問いを変える

なぜなぜの結果が「担当者が失念した」に到達したら、そこで止めずに問いを切り替えます。

• 「失念しても問題にならない設計にできないか」
• 「失念したことに、誰かが早く気づける設計にできないか」
• 「そもそも人が覚えている必要のある手順か」

この切り替えをしないと、対策が必ず「注意喚起」「再教育」になります。教育が無意味なわけではありませんが、教育は原因が「知らなかった」場合にのみ有効な対策です。知っていたが実行されなかった事象に教育を当てても効きません。

工夫4：「変化点」を探す

長く問題なく回っていた業務で急に不適合が出た場合、直前に何が変わったかを問うと原因に早く到達します。担当者の交代、システムの更新、業務量の増加、組織改編、委託先の変更。変化点が特定できれば、対策は「変化に伴う確認手順の追加」という具体形になります。

4. 是正処置の要否を判断し、内容を決める

判断の基準を持っておくと、議論が早くなります。

是正処置の内容は、「何を」「誰が」「いつまでに」の3点が揃っていなければ追跡できません。 そして、可能な限り仕組みで止める対策を選びます。

「弱い」対策だけで閉じる是正処置は、原則として再考します。 ただし、費用や技術的制約から強い対策が取れないこともあります。その場合は、弱い対策に検出の仕組みを組み合わせる（教育＋実施状況の定期確認）ことで実効性を補います。

5. 有効性を確認する

ここが是正処置報告書でもっとも手薄になる欄です。 規格は、取った処置の有効性をレビューすることを求めています。「実施した」ことの確認ではありません。

有効性の確認には、確認の時期と**確認の方法（何を見て効いたと判断するか）**を、是正処置を決めた時点で先に書いておきます。

確認の結果、効いていなかった場合は、それを記録して再度の分析に戻します。 「有効性を確認したが不十分だった。原因分析を見直し、追加の処置を実施する」という記録は、ISMSが機能している証拠です。効いたことにして閉じるほうが、はるかに問題です。

有効性の確認結果は、マネジメントレビューの進め方と議事録 のインプットになります。

6. 文書と記録を更新する

原因が手順の不備であれば、手順書を改定します。 是正処置報告書に「手順書を改定する」と書いただけで、実際の手順書が旧版のまま、というケースは頻繁にあります。改定版数と改定日を報告書に記載し、紐づけます。

記載例の構造

実際の報告書がどう書かれるかを、1件の例で示します。ここでの要点は文言そのものではなく、各欄がどの粒度で書かれているかです。

この例で注目していただきたいのは3点です。

1. 不適合の内容に、事実だけでなく「何が確認されなかったか」（漏えいの痕跡がない）も書かれている。影響がなかったことの記録も、判断の証跡になります
2. 原因が3層に分けて書かれている。対策が3つ出ているのは、原因が3つあるからです
3. 有効性の確認が、是正処置の完了時点ではなく将来の日付で設定され、報告書がまだ閉じていない。是正処置報告書は、実施した時点では完了しません

報告書を「実施完了」で閉じてしまう運用が、有効性の確認が形骸化する最大の原因です。 完了承認を有効性確認の後に置く様式にするだけで、構造的に防げます。

よくある失敗

審査での指摘を自社の言葉に翻訳していない

審査機関の不適合報告書に書かれた指摘は、審査員が見た範囲の事実です。自社は、その事実がどの仕組みから生まれたかを自分で分析し直す必要があります。指摘文をそのまま原因欄に転記した是正処置計画は、審査機関から差し戻されることがあります。

審査で受けた指摘への対応は、一般に次の流れになります。期限や様式は審査機関ごとに異なるため、必ず審査機関の指示を確認してください。

重大な不適合は、認証の発行や維持の判断に直接影響します。 区分の考え方と典型例は 審査でよくある不適合と対策、審査の流れは 2次審査（実地審査）で見られること と サーベイランス審査（維持審査）の準備 をご覧ください。

是正処置が多すぎて回らない

内部監査で30件の不適合を出し、全件に報告書を書こうとして半年かかる。これは監査側の設計の問題でもあります。観察事項と不適合を区別し、不適合は要求事項に照らして明確に満たされていないものに限定します。観察事項は改善提案として別に管理します。

期限が守られず、放置される

起票したが実施されないまま半年経過する案件が溜まる。一覧で管理し、期限超過を月次で可視化する運用を入れます。実施できない場合は、期限を延長する承認を取り、その理由を記録します。黙って放置するのと、承認のうえ延長するのは、記録上まったく違います。

同じ原因の報告書が毎年出ている

これは是正処置が効いていない明確な証拠です。過去の報告書を原因で分類し、繰り返しているものを抽出する分析を年1回行うと、構造的な問題が見えます。この分析結果は、マネジメントレビューで資源配分を求める材料になります。

インシデントと不適合が別々に管理されている

インシデント台帳と是正処置台帳が別々にあり、相互に参照されていない。インシデントの再発防止策は是正処置そのものなので、番号で紐づけて一元管理します。

是正処置の記録が残っていない

規格は、不適合の性質と取った処置、そして是正処置の結果を、文書化した情報として保持することを求めています。口頭で対応して終わった案件は、実施していないのと同じ扱いになります。

ヘルスケア企業の例

医療SaaS事業者の場合

固有の論点は、是正処置が顧客医療機関に影響する場合の扱いです。たとえば、権限設計の不備を是正するために顧客側の設定変更が必要になる、あるいは機能の挙動が変わる場合、是正処置の計画に顧客への説明と移行期間を組み込む必要があります。自社だけで完結しない是正処置には、顧客側の実施状況を確認する工程まで含めて設計します。

もう一つは、本番データアクセスに関する不適合です。障害調査で患者データを参照した際の申請・承認の記録欠落は、是正処置の典型例です。ここでの強い対策は、「申請なしにはアクセスできない仕組み」（一時的な権限付与、アクセス時の理由入力必須化、時限付きの権限）であり、教育では足りません。責任分担の設計は既存記事の AI電子カルテのセキュリティ設計｜責任共有モデル が参考になります。

PHR事業者の場合

同意範囲に関する不適合は、原因分析が製品開発プロセスに及びます。新機能の企画時点で同意範囲の確認工程がないことが原因であれば、是正処置は「開発プロセスへのレビュー工程の追加」になります。運用部門だけで閉じる是正では再発します。詳細は PHR事業者のISMS｜個人情報保護法との関係 をご覧ください。

治験・臨床研究システムを扱う企業の場合

記録の完全性に関する不適合では、応急処置そのものに制約がかかります。欠落した記録を後から追記する際、追記であることが監査証跡上明確でなければなりません。「後から辻褄を合わせる」形の応急処置は、それ自体がより重い問題になります。応急処置の方法を、完全性の要求と整合させて設計する必要があります。

SaMDを開発する企業の場合

ISMSの是正処置と、QMS（ISO 13485）のCAPA（是正処置・予防処置）が並走します。同じ事象が両方の対象になる場合、二重に報告書を書くのではなく、どちらの記録を正とし、もう一方からどう参照するかを決めておくことが必要です。運用を決めずに始めると、記録の不整合という新たな不適合を生みます。関係の整理は SaMDとISMS・QMS（ISO 13485）の関係 をご覧ください。

3省2ガイドライン対応との関係

顧客医療機関の監査や、ガイドラインに基づくチェックリスト対応で不足が判明した場合も、ISMSの是正処置として扱うと管理が一本化できます。医療機関側でのチェックリストの使い方は 3省2ガイドライン対応チェックリスト、文書の統合は ISMS文書と3省2ガイドライン対応文書の統合 をご覧ください。インシデントの構造的な共通点については、医療機関向けの インシデントの構造から学ぶ｜共通する失敗パターン も参考になります。

まとめ

1. 応急処置と是正処置は別物。後始末は是正処置ではない。是正処置の要否は評価したうえで判断し、不要とした場合も理由を記録する
2. 原因分析は**「なぜ発生したか」と「なぜ検出できなかったか」の2方向**に分け、技術・運用・管理の3層に降ろす。人で止まったら問いを変える
3. 対策は仕組みで止める方向を優先する。教育は、原因が「知らなかった」場合にのみ有効な対策である
4. 有効性の確認は、確認時期と確認方法を是正処置の決定時点で先に書く。完了承認は有効性確認の後に置く
5. 審査の指摘は自社の言葉に翻訳して原因分析をやり直す。指摘文の転記は差し戻しの原因になる
6. 同じ原因の報告書が繰り返されていないか、年1回は過去の報告書を原因で分類して点検する

是正処置の状況と有効性の確認結果は マネジメントレビューの進め方と議事録 のインプットになり、そこで資源配分が判断されます。不適合の発生源となる内部監査は 内部監査の進め方｜計画・チェックリスト・報告、インシデント由来の是正は インシデント対応手順の作り方（事業者）、訓練で見つかった不備の是正は 事業継続計画（BCP）とISMSの接続 と接続します。委託先評価で見つかった不足の扱いは 外部委託先管理｜チェックシートと契約条項 をご覧ください。

ポテックは、ヘルスケア領域に特化してISMS認証取得と運用を支援しています。審査で受けた指摘を、再発しない形の是正に落とし込む作業は、様式の埋め方ではなく原因分析の設計そのものです。支援内容と料金は ISMS認証取得支援サービス、個別のご相談は お問い合わせ から承ります。

参考・出典

• 情報マネジメントシステム認定センター（ISMS-AC）
• ISO/IEC 27001 Information security management systems｜ISO
• 日本産業標準調査会（JISC）
• 医療情報システムの安全管理に関するガイドライン｜厚生労働省
• 独立行政法人情報処理推進機構（IPA）

※規格の要求事項の解釈、認定および認証の取扱い、ならびに不適合の是正期限・様式は、規格本文および認定機関・審査機関の公表資料と指示をご確認ください。改定や運用の見直しにより取扱いが変わる場合があります。