情報セキュリティ目的とKPIの立て方

ISMSの構築を終えた組織の文書を見せていただくと、情報セキュリティ目的の欄に「セキュリティインシデント0件」「情報セキュリティ意識の向上」「全社的なセキュリティレベルの強化」といった文言が並んでいることがあります。方針の言い換えとしては読めますが、1年後にこれが達成されたかどうかを誰も判定できません。

情報セキュリティ目的は、ISMSの中で唯一「今年この組織は何を良くするのか」を宣言する場所です。ここが空文になると、箇条9のパフォーマンス評価に測るものがなくなり、マネジメントレビューの議題が「特に問題ありません」で終わり、箇条10の改善が回りません。目的の質が、ISMS全体が動いているかどうかを決めます。

本記事は、目的とKPIの設計を実務の手順に落とします。測定可能であることの意味、「0件」型の目的が機能しない理由、達成時期と評価方法をセットで決める方法、そして部門への展開のしかたを扱います。要求の位置づけは 箇条6 計画｜リスクアセスメントと情報セキュリティ目的、規格全体は ISMS（ISO/IEC 27001）とは をご覧ください。

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

なぜここでつまずくのか

「測定可能」を「数字が入っている」と読んでしまう

規格は、情報セキュリティ目的が実行可能な場合には測定可能であることを求めています。この「測定可能」は、数値が書かれていることではなく、同じ手順で誰が測っても同じ結論に達し、達成・未達を判定できることを指します。

「教育を強化する」に「年2回」と付けても、何をもって1回と数えるのか、対象は誰か、受講しなかった人がいたらどう扱うのかが決まっていなければ、判定はできません。逆に「年次教育の対象者全員が期末までに修了する」は、対象者名簿と修了記録があれば数字を書かなくても判定できます。測定可能性は、指標の文言ではなくデータ源の有無で決まります。

「インシデント0件」が目的として機能しない

この形は非常によく見かけますが、目的としては次の4点で成立しません。

1. 自組織の統制が及ばない要因に結果が左右される。取引先経由の攻撃、未知の脆弱性、委託先の事故。努力と結果が対応しないため、達成しても未達でも、組織の行動の良し悪しを判断できません
2. 報告を抑制する誘因が生まれる。「0件」が評価される環境では、軽微な事象を事象として上げない動機が働きます。インシデント管理は、上がってこないことが最大のリスクである領域です
3. 未達が確定した瞬間に目的が死ぬ。年度の3か月目に1件起きたら、残り9か月は達成不能な目的を掲げ続けることになります
4. 改善行動に分解できない。0件にするために明日何をするのかが導けません

インシデントを扱いたいのであれば、組織が統制できる過程を測る方向に置き換えます。たとえば「検知から初動着手までの時間」「報告された事象のうち再発防止策まで完了した割合」「重大度判定が手順どおり行われた割合」。いずれも自組織の行動で動かせ、かつ低いほど良い／高いほど良いが明確です。

目的がリスクアセスメントとつながっていない

規格は、目的を設定する際に適用される要求事項と、リスクアセスメント・リスク対応の結果を考慮することを求めています。ところが実務では、目的が総務部門の年間計画から作られ、リスク対応計画は別ファイルで動いている、という分断が起きます。この状態だと、審査で「なぜこの目的なのか」を問われたときに根拠を示せません。目的は、リスク対応計画のうち今年度に重点を置くものを抜き出したもの、という位置づけが最も説明しやすい形です。

目的が箇条9の測定計画と別物になっている

目的に指標を書いたのに、監視・測定の計画には別の項目が並んでいる。これも頻出です。目的の指標は、そのまま箇条9で監視・測定する対象になります。箇条9 パフォーマンス評価 の測定項目表と、目的管理表の指標欄は同じものを指していなければなりません。

何を決めるのか

規格が計画として求めるのは、何を実施するか／必要な資源／責任者／達成時期／結果の評価方法です。実務ではこれに、目的そのもの・指標・目標値・データ源・測定頻度を加えた表で管理すると過不足がありません。

目的の数は3〜5個が扱いやすい水準です。 10個以上並べた表は、期中のレビューで全件を見きれず、結局期末にまとめて実績を埋めることになります。少人数組織であればなおさらで、少人数組織のISMS で触れているとおり、運用できる件数まで絞ることが誠実な設計です。

目標値は現状値を測ってから決めます。 ベースラインを知らずに「95%」と書くと、実はすでに98%だった（改善の意味がない）か、現状40%だった（到底届かない）かのどちらかになりがちです。最初の年は、測ること自体を目的にするのも正当な選択です。「重大な脆弱性の修正日数を毎月測定し、ベースラインを確立する」は、2年目に目標値を置くための準備として意味を持ちます。

100%を置いてよい指標と、置いてはいけない指標があります。 教育の受講率や委託先の年次評価実施率のように、対象が確定していて、やれば必ず達成できるものは100%が適切です。一方、脆弱性の修正率や検知率のように外部要因が入るものに100%を置くと、未達が常態化して目的が形骸化します。

実務の手順

ステップ1：リスク対応計画から候補を抜き出す

今年度に実施予定のリスク対応のうち、組織横断で効き、かつ進捗を測れるものを候補にします。単発の設備投資（たとえば「入退室管理装置を設置する」）は、リスク対応計画の中で管理すれば十分で、目的にする必要はありません。目的に適するのは、継続的な運用の水準を上げるものです。

ステップ2：全社目的を3〜5個に絞る

候補から、経営層が「今年はこれを良くする」と言えるものを選びます。選定の観点は、リスクの大きさ、法令・契約上の要求、そして前年度の不適合や観察事項です。審査でよくある不適合と対策 に挙がるような領域は、目的として置くと改善の証跡にもなります。

ステップ3：指標とデータ源を同時に決める

指標を決めたら、その値をどこから取るかを必ず同時に決めます。ここで「取得手段がない」と判明したら、指標を変えるか、取得の仕組みを作ることを目的に含めます。データ源のない指標は、期末に推計値が書かれ、審査で根拠を示せません。

ステップ4：現状値を測り、目標値を置く

1か月ぶんでもよいので実測します。実測が難しければ、初年度は「測定体制を確立し、ベースラインを記録する」を目的にします。

ステップ5：部門に展開する

規格は、目的を関連する部門および階層において設定することを求めています。ここで全社目的をそのまま各部門にコピーすると、部門にとって統制できない項目が並び、機能しません。全社目的に対して、その部門が担う部分を切り出すのが正しい展開です。

「—」を置ける勇気が重要です。関係のない部門に形だけの目的を配ると、達成状況の報告が空文になります。

ステップ6：レビューの周期を決める

四半期ごとに実績を更新し、未達の兆候があれば期中に手当てします。年1回しか見ない設計にすると、期末に「未達でした」と記録するだけで終わり、是正のサイクルが回りません。実績はマネジメントレビューのインプットになるため、マネジメントレビューの進め方と議事録 の議題設計と合わせて決めると手戻りがありません。

ステップ7：未達だったときの扱いを先に決めておく

未達は失敗ではなく、分析の対象です。原因が「目標値が非現実的だった」「資源が確保されなかった」「前提が変わった」のどれなのかを記録し、次年度の目的に反映します。未達を隠す運用になると、目的管理表そのものが信用されなくなります。不適合として処理すべきかどうかの判断は 箇条10 改善｜不適合と是正処置 の基準に従います。

よくある失敗

目的が情報セキュリティ方針の言い換えになっている

「情報資産を適切に保護する」は方針の文言であって、今年度の目的ではありません。方針は複数年にわたって変わらない意思表示、目的は今年度の到達点です。両者の役割分担は 情報セキュリティ方針の書き方 で整理しています。

指標はあるが、値を取る手段がない

「不審メールの報告率」を指標に置いたものの、分母（実際に届いた不審メールの数）が分からない、という例です。分母が測れない指標は使えません。この場合は「訓練メールに対する報告率」に置き換えると、分母が確定します。訓練の設計は 標的型攻撃メール訓練 が参考になります。

目標値がすべて100%

受講率100%、評価実施率100%、点検実施率100%と並ぶ表は、一見すると隙がありませんが、どれも「やった／やらない」しか測っていないため、質の改善が起きません。少なくとも1つは、時間や件数のように連続量で測る指標を入れると、改善の余地が見えます。

目的が年度途中で静かに書き換わる

未達が見えてきた指標を、期末に目標値ごと差し替える。これは審査で発見されると心証が悪く、また改善の機会そのものを失います。変更が必要なら、変更の理由・承認者・日付を記録したうえで改訂します。ISMSの変更の計画は箇条6にも要求があります。

部門目的が全社目的のコピー

全部門の目的欄に同じ文言が入っている表は、展開が行われていないことの証拠になります。審査では部門長への質問で「ご自身の部門の目的は何ですか」と確認されるため、答えられない構造はすぐに表面化します。

実績が期末にまとめて記入されている

四半期ごとに測定すると決めた指標が、3月31日付でまとめて4四半期分記入されている。これは実質的に測定していないことを意味し、監視・測定の要求に対する不適合として扱われ得ます。測定日と記録日を分けて残すと、実態が示せます。

目的が経営層に共有されていない

目的はトップマネジメントが承認し、進捗を把握すべきものです。ISMS事務局だけが知っている目的は、資源の手当てが受けられず、未達になります。箇条5 リーダーシップ の観点からも、承認記録と報告経路は明確にしておきます。

ヘルスケア企業の例

医療SaaS事業者

この業態で目的に置く価値が高いのは、本番環境の患者データへのアクセス統制です。障害調査で本番データを参照する運用は現実に存在するため、「本番データアクセスのうち、事前申請・承認を経たものの割合」「アクセス後のログレビュー実施率」といった指標は、自社で完全に統制でき、かつ医療機関側の関心にも直接答えられます。

もう一つはテナント分離に関わる変更のレビュー率です。データ分離ロジックに触れる変更について、指定レビュアーの承認を経た割合を測ると、医療SaaSのISMS｜マルチテナントのリスク評価 で扱うリスクに対する直接の指標になります。

PHR事業者

利用者本人から同意を得てデータを預かる構造上、同意記録の完全性が目的になります。「同意の取得・変更・撤回が記録された割合」「撤回から利用停止までの所要時間」は、個人情報保護法上の要請とも重なるため、法令対応とISMSの目的を一本化できます。詳細は PHR事業者のISMS｜個人情報保護法との関係 をご覧ください。

SaMDを開発する企業

セキュリティ目的と製品安全の管理が別系統で動くため、接点を測る指標が有効です。「セキュリティ脆弱性のうち、安全性への影響評価を実施した割合」は、ISMSと製品側のリスクマネジメントをつなぐ位置にあります。関係の整理は SaMDとISMS・QMS（ISO 13485）の関係 を参照してください。

医療機関向けの受託開発・保守を行う企業

顧客が3省2ガイドラインの対応主体であるため、委託先としての応答品質が目的になります。「医療機関からのセキュリティ質問票への回答所要日数」「リモート保守接続のうち、事前承認と作業記録が揃っている割合」は、契約上の責任分界に直結します。考え方は 3省2ガイドラインとは と ISMS文書と3省2ガイドライン対応文書の統合 にまとめています。

いずれの業態でも共通するのは、顧客である医療機関が説明を求める項目を、そのまま自社の目的の指標にすると、ISMSの運用と営業上の説明資料が一本化できるという点です。調達の現場で何を聞かれるかは ISMSが取引条件になるケース が参考になります。

まとめ

1. 「測定可能」とは数字が入っていることではなく、データ源があり達成・未達を判定できること
2. 「インシデント0件」は目的にしない。統制できない要因に左右され、報告を抑制し、未達の瞬間に死ぬ。検知時間や再発防止完了率など、過程を測る指標に置き換える
3. 目的はリスク対応計画から抜き出す。総務部門の年間計画から作ると、審査で根拠を説明できない
4. 目的管理表には、指標・データ源・現状値・目標値・測定頻度・責任者・資源・達成時期・評価方法をそろえる。達成時期と評価方法をセットで決める
5. 全社目的の部門展開はコピーではなく切り出し。関係ない部門には「—」を置く
6. 目的は3〜5個に絞り、四半期ごとに実績を更新する。未達は隠さず、原因を分析して次年度に反映する

ポテックは、ヘルスケア領域に特化してISMSの構築・運用を支援しています。目的とKPIの設計は、自社のリスクと顧客である医療機関の関心を両方知っていないと、測るだけで使われない指標になりがちな領域です。支援内容と料金は ISMS認証取得支援サービス、個別のご相談は お問い合わせ から承ります。

参考・出典

• 情報マネジメントシステム認定センター（ISMS-AC）
• ISO/IEC 27001 Information security management systems｜ISO
• 日本産業標準調査会（JISC）
• 個人情報保護委員会
• 医療情報システムの安全管理に関するガイドライン｜厚生労働省

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