マネジメントレビューではどのようにISMSのレビューをしていますか？

規格の意図を汲んだマネジメントレビュー（以降、MRと称します）をされていますか？

MRは、どのような目的で実施すればよいのでしょうか。

常日ごろから自社のことは経営陣が一番知っている。年に一度や二度のレビューなど悠長なことを言っているようでは「規格は甘い」、などとおっしゃる気持ちは十分理解できますが、ここは「ぐっと」堪えて、

・内部監査の結果として監査チームや監査責任者がISMSの有効性を評価した報告内容、

・ISMSの有効性をレビューした管理責任者・事務局、IS委員会結果の報告内容、

・監査責任者や管理責任者、IS委員、従業者の活動の結果である改善提案の内容

等々じっくりと見て、自分の評価と比べてください。

 

同じだったでしょうか？

また、昨年、一昨年と比べて、トレンドや特徴的な事象など気になることはありませんでしたでしょうか。

これらを評価するに必要にして十分なMRのインプット内容でしたでしょうか。

規格がMRに期待しているものは，MRの目的とともに実施項目が，規格7.1 一般に明記されています。要約は以下の通りです。

「経営陣自ら，組織のISMSが引き続き適切であり、妥当であり、かつ、有効であることを確実にするために、あらかじめ定めた間隔（少なくとも年１回）で、ISMSをレビューすること。」

・当社のISMSは引続き適切であり，妥当であること（陳腐化、形骸化していないか）

・当社のISMS基本方針，ISMSの目的をも含めてISMSが有効に機能しているか（経営に役立っているか）

上記がMRの主な目的です。

MRでは「ISMSに関する改善の機会，変更の必要性の評価」を意識して行ってくださいと言っています。言い換えるとISMSの改善サイクルである「PDCA」が適切にまわっているか、当社の利害関係者への説明責任としてのエビデンスに問題はないかを大局的にレビュー「C」して、足らずや新たなことがらなどがあれば指示・示唆してくださいといっています。

外部審査で審査員から重大な指摘をもらわなかったとしても、当社のISMSは問題があるかもしれないと思っていても、経営陣が改善に向かうように指示しなければ、組織は改善が進まず、形骸化だけが進み、ますますリスクが増大します。　大きな事件・事故を引き起こせば、最後の責任を取らないといけないのは経営陣です。 

・ISMS基本方針，情報セキュリティ基本方針の変更の必要性の有無

・ISMSの目的・目標の変更の必要性の有無

・ISMSの変更・改善の必要性の有無

を経営陣目線で視て、ISMSの運用、維持に関することを、提出・説明されたMRのインプットと比較し、監査責任者、管理責任者、IS委員等と十分な「対話：dialogue」を行い、その結果を、経営陣が決定し、その内容を明快にMRのアウトプットとして開示するようにされるとマネジメントシステムは経営のツールとしてあり続けます。

従業者は、経営陣の言動を注視し、そして背中を観ています。従業者の言動は経営陣の映し鏡だと思います。何事に付け、最後の砦が経営陣です。

やはり経営陣というのは大変ですよね。

ISMS基本方針及び目的を満たしていれば、ISMSは有効と言える？

ISMSはマネジメントシステムですので、やっと、「規格4.2.3 b」ＩＳＭＳの有効性のレビューで、方針展開、目標管理がここで控えめに、そして分かりにくく登場しました。

規格での分かりやすさ、具体的な表現から言えば、EMS＞QMS＞ISMSでしょうか。ISMSはEMS、QMSと比べると性格が控えめな規格ですね。

「規格4.2.3 b」では，先の「ISMSにおける管理策の有効性評価」のブログで述べました二種類のISMSの有効性のレビューのもう一つが「ＩＳＭＳ基本方針及び目的を満たしていることのレビュー」です。

「情報セキュリティマネジメントシステム」に対する「用語及び定義」の注記では、「マネジメントシステムには、組織の構造、方針、計画作成活動、・・・が含まれる」とあります。

ISMSが有効かどうかを、「ISMS基本方針及び目的を満たしている」程度で評価することになりますので、この要求の意図は、方針展開、目的・目標管理として「なにを：ＫＧＩ、どのレベルで：ＫＰＩ）」を決めて、目的・目標の達成度合いをマネジメントの観点でレビューすることと考えられます。（規格4.2.3 b→7.1）

その場合の考慮事項として，「このレビューでは，セキュリティ監査の結果，インシデント，有効性測定の結果，提案，及びすべての利害関係者からのフィードバックを考慮する。」とあり，マネジメントレビューのインプットのいくつかと同様であることから，マネジメントレビューの前段階で、経営陣に確かな情報提供を行うことを期待しているのではないでしょうか。

「ISMS基本方針」はそれほど毎年変わることは少ないでしょうが、「ISMSの目的」の方は、あまり毎年同じというのも前期の達成度が悪かった、だから管理策を改定した、或いは教育・訓練で意識付けしたというのであれば、納得できますが、そうでなければ、「ＫＧＩ」は同じでも、別の視点として「ＫＰＩ」を変えてみるというのもよいと思います。

ISMSの目的（オブジェクティブ）とはなに、どうであれば役立つ？

ISO/IEC27001の「ISMS objectives」をJISでは「ISMSの目的」と訳しています。

ISO9001の「quality objectives」はJISでは「品質目標：品質に関して、追求し、目指すもの」とし、ISO14001では、「environmental objectives」を「環境目的：組織が達成を目指して自ら設定する。環境方針と整合する全般的な環境の到達点」とし、「environmental target」を「環境目標：環境目的から導かれ、その目的を達成するために目的に合わせて設定される詳細なパフォーマンス要求事項で、・・・」と使い分けをしています。

英語圏の人にとっては何ら不思議ではないものが、日本人は、「目標」と「目的」では、そのニュアンスが異なるようです。「目標」というと、どうも「数値」であったり、達成をしなければならないもののように思えますが、「目的」となるとなにかスローガン（標語）のような感じがして、「頑張ろう的」になりがちです。ISO14001は分かりやすいですね。

ISO/IEC27001では、「control objectives」を「管理目的」と訳し「管理策を実施した結果, 達成されることになる事柄を説明した記述。」とあります。わかりにくいですが、ISO/IEC27001からJISを制定するに際しては、随分と苦労されたようで、「ISMS目標」とすると、QMSの品質目標のように「数値でなければいけない」と解釈されそうだ（本当は、達成度が評価できれば定性的でもよい）、いやまてよ、「管理目的」と言ってきたので、それと同様に「ISMSの目的」としよう、となったようです。（たぶん）

ISMSの目的で多いのは「セキュリティ事件・事故　ZERO」です。悪くはありませんが、当たり前で、「QMSのクレームZERO」と同じですね。「セキュリティ事件・事故　ZERO」は、ＫＧＩ（Key Goal Indicator）といえます。KGIは，「結果」としての評価と言えます。

 

マネジメントシステムとしては、活動に繋がりにくいので、このＫＧＩを達成する為に，マネジメントを行う上での，課程やプロセスの管理指標として，適切なＫＰＩ（Key Performance Indicator）をセットで設定するとよいと思います。ＫＰＩをコントロールしていくことで，最終目標のＫＧＩを得ることができます。ＫＰＩに対しは具体的なアクションプランがたてやすいです。

また各人、それぞれ達成感を持つことができ、ISMSの運営に役立つ有効な目標となるのではないでしょうか。

参考：KGIとKPIの解説

「ＫＧＩ」は、Key Goal Indicator，「ＫＰＩ」は、Key Performance Indicatorの略です。

各組織は、経営戦略、戦術、プロジェクト、日常管理のレベルで設定された「目標」（なにを：ＫＧＩ、どのレベルで：ＫＰＩ）に沿って活動が行われているかを、具体的、客観的にその対象物の状況を把握して、計画と異なることが分かれば、迅速に、重要度に応じて適切にアクションをとる必要があります。

「ＫＧＩ」とは、企業の経営戦略から導かれる成果を数値で示したもので、最終的な成果指標として設定します。　例えばＫＧＩが「機密情報への不許可のアクセスを防ぐ 100％」も「セキュリティ事件・事故 ZERO」など期末にならないと分かりませんし、一度事件・事故が発生するともう今期の目標は未達となり、その後気が抜けてまた事件・事故を起こすかも知れません。

「ＫＰＩ」とは、ＫＧＩに行き着くまでの手前の業務遂行上の指標です。例えば、アクセス権の設定100％とか、日々日常的に決められたルールを守るとか、絶対に安全と確認できるまで外部からのメールの添付ファイルは開かないとかです。

ボーリングでいうと、最終的にはどのピンに当てるという目標（ＫＧＩ）は定めるが、より正確に狙うために中間目標であるスパッツ（ＫＰＩ）を目がけて投げるようなものです。

ISMSにおけるリスクアセスメントのレビューとは

「規格4.2.3」ISMSの監視及びレビュー d）項にリスクアセスメントに対するレビューの要求があります。　規格4.2.3は、「Check」ですから、規格4.2.1の「Plan」でのリスクアセスメントの実施とは役割が異なりますが、4.2.1でのリスクアセスメント作業の再確認や期中でリスクアセスメント作業そのものの見直し行為と誤解されていることもあります。

これは、「レビュー」を「見直し」、そしてだったら「再確認」もあるなどとだんだん意味が異なっていくようです。　また、「見直し」「見て・直す」と分解でき、日本語は後の言葉に比重がかかることがありますので、「直す」ために「見る」と考えるのでしょう。 

「レビュー」は、ISO9000用語では、「設定された目標を達成するための検討対象の適切性、妥当性、及び有効性(3.2.14)を判定するために行われる活動。」ですので、「Check」です。もし、「直す」ことが必要であれば、規格4.2.4 ISMSの維持及び改善で行うのが自然ですね。 

また、「レビュー」を適切に行うためには、「設定された目標」なりその基となる「リスクマネジメント方針」が明示的或いは暗黙的に存在していなければ、「レビューではなく、主観で眺めるだけの行為」となります。このことはISO31000（リスクマネジメント-原則及び指針）を見なければ現状わからないです。ISO/IEC27000シリーズの次回の改訂では、ISO31000と用語を合わせるようですので、期待したいものです。

「リスクマネジメント方針」なり「リスクマネジメント目的・目標(objective)」を設定しておれば、このリスクアセスメントのレビューは何をしなければならないか分かりやすくなります。現状ではそれぞれ、「ISMS基本方針」、「ISMS目的・目標(objective)」に含まれているのではないでしょうか。

このリスクアセスメントのレビューは、例えば、期初にリスクアセスメントを行い、リスク対応計画を作成し、リスク対応を実施し、四半期、半期を経た時点で、リスクコミュニケーションやリスクの監視状況を活用してリスクアセスメントのレビューを行い、必要であれば4.2.4項を実施することで、リスクマネジメントとしてＰＤＣＡがまわることになります。これらは、4.2.3b)項やマネジメントレビューとも関連があります。　

このレビューにおいては，リスクアセスメントにおいて、基軸となる「残留リスク、特定したリスク受容可能レベル」のレビューも要求されています。　規格が示してくれた，６種類の視点は、なるほどと思える視点だと思います。

ISMSにおける管理策の有効性評価とは

「規格4.2.2 d」管理策の有効性の測定と利用の定義とは：

ここは、管理目的に対して管理策の有効性評価の測定方法を決め、且つ管理策の有効性評価を行うために、測定結果の利用方法を決めるところです。

管理策の有効性の測定は，「管理策が管理目的を達成していることを管理者及び要員が判断することを可能にする」と注記に示されています。　従って、現在に管理策は、その上位の管理目的に対して、どの程度みたしているかを、何らかの評価指標を決めて、また評価基準を決めると考えられます。　管理策の改善を目的とすると考えてよいともいます。

ISO9001で例えると、「8.2.3プロセスの監視及び測定→8.4データ分析→7.5.2製造及び」サービス提供に関する妥当性確認→8.5改善」あたりの取組方法や評価基準を決めると言うことでしょうか。何か問題があれば「是正」、ありそうであれば「予防」、管理目的を達成するためにもっとよい方法があれば「改善」するための活動です。決して管理策を重厚にすることを意図しているのではなく、智恵を発揮してシンプルな管理策とすることも含みます。

規格「4.2.2 b」では関連するものとして「4.2.3 ｃ」参照とありますが，「4.2.3 b」とは書かれていません。プロセスの繋がりから考えると、「4.2.2 b」→「4.3.1 g」→「4.2.3 ｃ」→「4.2.3 b」→「7.2 f」でしょうか。

「規格4.2.3 c」管理策の有効性を測定とは：

ここは、上記の規格「4.2.2 b」で定めた方法で、管理目的に対して管理策がどの程度有効かを測定するところです。それ以外のなにものでもありません。

「規格4.2.3 b」管理策の有効性のレビューとは：

ここでは、ISMSの有効性をレビューするために，「セキュリティ管理策」のレビューを行えと言っています。　このレビューでは，有効性測定の結果以外にもISMS基本方針及び目的を満たしていることのレビューと同様に，多くの要素（前スライド参照）を考慮せよと言っています。

 

あくまでも「ＩＳＭＳの有効性のレビュー」の一要素として「セキュリティ管理策のレビュー」を求めていることから，4.2.2　d項だけが評価とするのではなく，4.2.3 c項（管理策の有効性測定）の「結果も」考慮せよといっています。　管理策の有効性のレビューは，管理策の測定結果だけではないよと規格は言いたかったのでしょう。

また，4.2.3 b と4.2.3 cはプロセスの繋がりとして後先となっているように見えますが，アングロサクソン人のトップダウンの思考回路を考えると、重要であるのはレビューであって、そのネタとしての測定は、その一要素であると言いたかったのかもしれません。

ISMSにおけるリスク対応計画とは

ISO/IEC27001規格4.2.2 ISMSの導入及び運用の下記の項番において、

a）リスク対応計画を策定する。この計画では，情報セキュリティリスクを運営管理するための，経営陣の適切な活動，経営資源，責任体制及び優先順位を特定する。

b）特定した管理目的を達成するためにリスク対応計画を実施する。この計画には，必要資金の手当て並びに役割及び責任の割当てへの考慮を含む。

とあります。上記以外では、「リスク対応計画」という表現はなく、規格4.2.1のe)、f)、g) は「リスクの対応」をせよと言っています。些細な表現上の問題かも知れませんが、「リスク対応計画」は、運用上の計画ですから「Do」だと伝えたいのかも知れません。

また、「管理策」は「管理目的」を達成する為にあるのですから、4.2.2 b）項は当然の言い方ですね。しかし現実は、個々の管理策に基づくルールのことばかり気になるようですから、管理策そのものが管理目的とかけ離れてしまい、リスク対応が不備になることが心配です。このルールはどのような事を防ぐ（管理目的）ためにあるのかを意識することが重要です。

リスク対応計画は，一過性のものではなく年間を通して、リスク受容基準を満たし続ける（言い換えると残留リスク値に留め置く）ための計画であり，例えば、意識向上策や教育・訓練教育・トレーニング計画や内部監査計画(含む監査プログラム)等に関する計画でもよいし，リスクマネジメントを包含するＩＳＭＳの運用計画でもよいと思います。

ISMSユーザーズガイド JISQ27001：2006(ISO/IEC27001：2005)対応リスクマネジメント編（JIP-ISMS113-21）の記述（2.3.1 STEP1 リスク対応計画の策定）も、その気で読めば読めないわけではありませんが、具体性に欠けます。要するに、リスクマネジメントは、予防の塊ですので、心配なところ、その程度に応じて各企業で考え、活動するための計画ということでしょうか。

このガイドでの「実装（implementation）」の解釈もいろいろ考えられます。　日本語的には「ルールを作る、ルールを見える化する」こととも取れますが、実際の日々の活動を考えたとき、「決めたルールを実行する、実行していることをチェックする」までとした方が、よいように思います。

「計画」とあるから「リスク対応計画」の策定・実施は、4.2.2「Do」ではなく、4.2.1「Plan」のg)項とh)項の間に入れた場合の特徴は、リスク対応計画は、管理策を作り込むためのものですので、必然的に「管理策」単位となります。従って、ISMS登録の時点では、賑やかに全ての管理策対応が作り込みの計画・結果としてありますが、登録後は、「すべて対応済み」として「リスク対応計画」そのものがなくなるということにならないでしょうか。

4.2.1「Plan」でのリスクアセスメントも眺めただけで、4.2.2「Do」の「リスク対応計画もない」状態で、どのようにリスクに対応して行くのか心配になります。定めた情報セキュリティに関するルールをひたすら日々守れば、災いは降りかからないのでしょうか。ルールの未実行やルールそのものの不備・陳腐化というリスクが一番怖いですね。