内部監査で発生した不適合や、社内で発生した情報セキュリティインシデントは、原因分析や対策を行い、再発防止に努めなければいけません。「改善」の機能ではこの作業フローをサポートします。
（Pマークのマニュアルはこちら）
JIS Q 27001 対応箇所
本文 10
改善を登録するタイミング
以下の事象が起こった場合、「改善」の取り組みを行う必要があります。
- 内部監査や外部審査にて「不適合」が発見されたとき
- 情報セキュリティインシデントが発生したとき
必須ではありません。
一方で、改善の機会も登録することで、ISMSをより良くするための気づきを取り入れることができるため、よりレベルアップしたISMSを構築・運用できます。
具体的な登録の流れ
1.カテゴリを選択する
発見された事象が、以下のどのカテゴリに該当するかを決定します。内部監査や外部審査で発生した「不適合」や「改善の機会（観察事項）」を登録する場合は、そのまま「不適合」「改善の機会」を選択し、登録を行ってください。
| カテゴリ | 具体的な事象の例 |
|---|---|
| 不適合 | 規格や社内ルールが守られていない状態 |
| 改善の機会 | インシデントにつながるおそれのある状態や要因の発見や、普段気に留めていなかった作業の中に、思いもよらぬ危険が常態化していたことの発見など ※審査機関によっては「観察事項」と呼ばれることもあります |
| インシデント | 情報セキュリティが喪失する（あるいはその恐れのある）事象 |
「インシデント」の厳密な定義を教えて下さい。
JIS Q 27001 によると、「情報セキュリティインシデント」は、以下のように定義されています。
望まない単独若しくは一連の情報セキュリティ事象、又は予期しない単独若しくは一連の情報セキュリティ事象であって、事業運営を危うくする確率及び情報セキュリティを脅かす確率が高いもの。
非常に解釈が難しい定義のため、情報セキュリティ（自社が管理している情報資産の、機密性・完全性・可用性）が喪失する（あるいはその恐れのある）事象だと考えればよいでしょう。概要としては、目標設定やリスクアセスメントにて懸案となった事象の発生で、具体的には、
- メールの誤送信（メールに書かれた情報の機密性が喪失）
- オフィスのカードキーの紛失（オフィス内の情報の機密性の喪失の恐れ）
- Webページの改ざん（Webページの情報の完全性が喪失）
- 自社が提供するシステムの停止（システムの可用性が喪失）
- PCの紛失（PC内の情報の可用性が喪失、機密性の喪失の恐れ）
などが考えられます。
また、実際の被害に至っていなくても、被害につながる恐れのある事象も含まれます。
インシデントの登録タイミングについては、インシデントはいつから登録すべきかをご覧ください。
2. 基本事項を登録する
事象の基本事項を登録します。
| 項目 | 説明 |
|---|---|
| 識別番号（任意） | 後で参照しやすい番号 |
| 発見元（任意） | 内部監査や外部審査で発見したものであれば、監査との紐付けを行う |
| インシデントレベル | Low / Middle / High から選択します。 この項目は、「インシデントレベルの設定」から変更できます。 |
| 概要 | タイトル |
| 発生日 | 事象が発生した日や、状態を発見した日 |
| 発生部門 | 事象が発生した部門や、危険が存在していた部門 |
| 時系列・修正処置 | 事象の発生に至った周辺事情と、すぐに実施した応急処置（修正処置）を、時間を添えて記載 |
3. 原因を登録する
事象が発生した原因を登録します。原因は、表面上の原因ではなく「根本原因」を登録することが重要です。短絡的に思いつく原因ではなく、その事象が起こった根本の原因を登録するようにしましょう。
根本原因を特定するにはどうすれば良いですか？
根本原因は、「なぜ？」を繰り返すことで特定できることがあります。ここでは、「社内ルールでパスワードの桁数は10桁と定められているにも関わらず、PCのログインパスワードが8桁だった」という不適合を例に考えてみます。
パスワードが8桁だった →なぜ？→ 社内ルールを知らなかった →なぜ？→ 社内ルールを全社会議で周知したときに、当該社員が欠席していた
また、アプローチを変えることで、以下のような考え方も可能です。なぜなぜ分析を行うことで、原因が複数発見されることもあります。
パスワードが8桁だった →なぜ？→ 10桁未満でもパスワードが設定できるようになっていた →なぜ？→ 端末管理システムのパスワード管理ポリシーが未適用だった →なぜ？→ 共有PCを端末管理システムに登録するのを忘れていた
予算や社内リソースの都合で、その原因に対して是正処置（再発防止策）を行うことが難しい場合は、「是正処理は必要ないと判断する」として登録することもできます。
複数の原因が組み合わさっている場合は、分割して記載してください。それにより、個々の原因に対して、それぞれの是正処置（再発防止策）を登録できます。また、担当者を分割することで、スピーディに対応に取り組むこともできます。
4. 是正処置と有効性確認を登録する
原因を特定したら、その原因を除去するための「是正処置（再発防止策）」と、その是正処置が有効に機能しているかどうかを確認する「有効性確認」を登録します。有効性確認は、是正処置が行われていから一定期間後（目安として数ヶ月以上後）に実施することが一般的です。
是正処置はどのように考えるべきでしょうか？
是正処置は、「気をつける」「注意して行う」といった、個人の意識の問題にせず、できるだけ仕組みの問題として考えるようにしましょう。
具体的には、以下のような取り組みを検討してみましょう。
- チェックリストを作る
- 自動化・システム化する
- 外部委託する
有効性確認とは何でしょうか？
有効性確認とは、「是正処置が有効に機能していることの確認」を意味します。是正処置は実施するだけではなく、実施したあとに、その原因が本当に除去できているかどうかを確認する事が必要です。
是正処置の例としては、以下のような取り組みがあります。
- 3ヶ月後に、同じ不適合が発生していないことを、インタビューによって確認する
- 半年後に、同じインシデントが発生していないことを、インシデントの登録状況から確認する