2011年12月23日
Operation
1. 運用計画と管理：
何処から何処までが運用(Operation)なのかな。日常管理的な部分と、年間の手順、イベントまでを含むのでしょうね。
1. 運用計画と管理：
何処から何処までが運用(Operation)なのかな。日常管理的な部分と、年間の手順、イベントまでを含むのでしょうね。
Support
1. 資源
2. 能力：能力または資質
3. 感知：気付いてあげることもサポート？。
4. コミュニケーション：語彙が広がって訳せないかも。
5. 文書化情報：所謂形式値
5.1. 一般要求
5.2. 作成・更新
5.3. 文書化情報の管理
改訂版では「文書と記録」の形をやめる。両者に本質的な違いを見つけることは困難だから。
1. 資源
2. 能力：能力または資質
3. 感知：気付いてあげることもサポート？。
4. コミュニケーション：語彙が広がって訳せないかも。
5. 文書化情報：所謂形式値
5.1. 一般要求
5.2. 作成・更新
5.3. 文書化情報の管理
改訂版では「文書と記録」の形をやめる。両者に本質的な違いを見つけることは困難だから。
Planning
1. リスクと機会の明確化：
2. 情報セキュリティの目的と目的達成のための計画：
資産の洗い出しからリスク評価までの一連の手順を踏まえてリスクを明確にすることは従来どおりとして、機会(Opportunities)の方は分かり難い。単純に改善機会と捕らえることにするかな。
1. リスクと機会の明確化：
2. 情報セキュリティの目的と目的達成のための計画：
資産の洗い出しからリスク評価までの一連の手順を踏まえてリスクを明確にすることは従来どおりとして、機会(Opportunities)の方は分かり難い。単純に改善機会と捕らえることにするかな。
Leadership
経営者の責任に相当するかな。
1. 基本要求
2. 経営者の責任
3. 方針：基本方針のこと？
4. 組織の役割、責任、権限
経営者の責任に相当するかな。
1. 基本要求
2. 経営者の責任
3. 方針：基本方針のこと？
4. 組織の役割、責任、権限
Context Of The Organization
従来、4.2.1a)とした部分かな？。適用範囲の理解あるいは記述の重要性を認識して大きな章立てにしたのだろうか。
「組織の枠組みと適用範囲」ぐらいの理解で如何ですか。
1. 組織概要と組織の関係性の理解：
2．関連団体の要求と期待の理解：利害関係者の要求と期待でしょうね。
3. マネジメントシステムの適用範囲の明確化：従来からの適用範囲。
4. 情報セキュリティマネジメントシステム：推進または管理のための組織。ISMS委員会など。
従来、4.2.1a)とした部分かな？。適用範囲の理解あるいは記述の重要性を認識して大きな章立てにしたのだろうか。
「組織の枠組みと適用範囲」ぐらいの理解で如何ですか。
1. 組織概要と組織の関係性の理解：
2．関連団体の要求と期待の理解：利害関係者の要求と期待でしょうね。
3. マネジメントシステムの適用範囲の明確化：従来からの適用範囲。
4. 情報セキュリティマネジメントシステム：推進または管理のための組織。ISMS委員会など。
ISO/IEC 27001の改定まで後2年？
改定の話は少しずつ進んでいるようだ。大きく内容が変わるものではないが、今までの規格にあった分かり難さを幾分解消するものになるような気がする。但し、構造は大幅に変わるから、規格に合わせて文書を組み上げてきた組織では、過渡期は大変な思いをするだろう。
加えて、27000シリーズが広がっていくので付いて行くのも容易でない。
そうは言っても、要求規格は27001だけで、残りは全てガイドラインだからその点はISMSに携わる人には助かるというか、優先順位を付けて作業にかかれるかも。一番誰もが気にする27001の改定はWEBを探してもこれだと言うものにお目にかかれない。
今のところは2013年の最終リリースが見込まれているようだ。「ISO 27001:2013」
断片的に飛び交う情報だけでも分かる範囲で並べれば何か見えるかもしれない。
.*.
章立てが変わる。下は適当に拾っているので間違っていると思うが、継続的に眺めて行きたい。
1. Introduction
2. Normative References
3. Terms and Definitions
4. Context Of The Organization
5. Leadership
6. Planning
7. Support
8. Operation
9. Performance Evaluation
10. Improvement
.*.
ISO27001:2013リリースの目的？
他の9規格とのハーモナイズ。9000, 14000, 20000など。用語の整合化。ここにもっとも時間が割かれたようだ。それは当然でしょう。考え方の違いなど背景にあるもののギャップが埋まらないと言葉は正されない。
章立ての変更
章立ては変わるが内容は80％以上は現行のものと同じらしい。リスクアセスメントは殆ど同じらしい。と言うことは詳細リスクアセスメントとする現行で行くんだろう。誤魔化しのアセスメントで済ますコンサルはそろそろやめては如何かな。
リスク対応はISO31000との調整が図れる。ISO31000はリスク管理に関する規範規格かな。
適用宣言書(Statement Of Applicability)がドロップってどういうことだろう。そういう固定的な文書を要求することは止めるということかな。しかし相互参照と整合化は要求されるらしい。と言うことは適用宣言書と言う名前はつけなくても良いが、組織が用意した（用意する）各施策と付属書の管理策との連関は明確であることが要求されるようだ。まあ、現物を見ないと分かりませんが。
PDCA(Plan-Do-Check-Action)モデルもドロップする。規格の冒頭に入っている図がなくなるということ。PDCAという言い方もやめるのか。継続的改善は依然要求されるが、改善プロセスを一律に決める必要は無いだろうと言うことでしょう。PDCAも大きな回り方と小さい回り方が交錯するので理念としては理解できても何処まで細分化してもキリが無いものだ。ついでに加えるなら、プランとアクションの部分は重なるので継続的に見る場合はPDCAとすることは返って難しくなるものだ。
外部委託に関するセクションが新たに設定されると言う情報もサイト上にあるがはっきりしない。委託してもISMSの責任を回避できるものではないと言う主旨のものか。
.*.
改定の話は少しずつ進んでいるようだ。大きく内容が変わるものではないが、今までの規格にあった分かり難さを幾分解消するものになるような気がする。但し、構造は大幅に変わるから、規格に合わせて文書を組み上げてきた組織では、過渡期は大変な思いをするだろう。
加えて、27000シリーズが広がっていくので付いて行くのも容易でない。
そうは言っても、要求規格は27001だけで、残りは全てガイドラインだからその点はISMSに携わる人には助かるというか、優先順位を付けて作業にかかれるかも。一番誰もが気にする27001の改定はWEBを探してもこれだと言うものにお目にかかれない。
今のところは2013年の最終リリースが見込まれているようだ。「ISO 27001:2013」
断片的に飛び交う情報だけでも分かる範囲で並べれば何か見えるかもしれない。
.*.
章立てが変わる。下は適当に拾っているので間違っていると思うが、継続的に眺めて行きたい。
1. Introduction
2. Normative References
3. Terms and Definitions
4. Context Of The Organization
5. Leadership
6. Planning
7. Support
8. Operation
9. Performance Evaluation
10. Improvement
.*.
ISO27001:2013リリースの目的？
他の9規格とのハーモナイズ。9000, 14000, 20000など。用語の整合化。ここにもっとも時間が割かれたようだ。それは当然でしょう。考え方の違いなど背景にあるもののギャップが埋まらないと言葉は正されない。
章立ての変更
章立ては変わるが内容は80％以上は現行のものと同じらしい。リスクアセスメントは殆ど同じらしい。と言うことは詳細リスクアセスメントとする現行で行くんだろう。誤魔化しのアセスメントで済ますコンサルはそろそろやめては如何かな。
リスク対応はISO31000との調整が図れる。ISO31000はリスク管理に関する規範規格かな。
適用宣言書(Statement Of Applicability)がドロップってどういうことだろう。そういう固定的な文書を要求することは止めるということかな。しかし相互参照と整合化は要求されるらしい。と言うことは適用宣言書と言う名前はつけなくても良いが、組織が用意した（用意する）各施策と付属書の管理策との連関は明確であることが要求されるようだ。まあ、現物を見ないと分かりませんが。
PDCA(Plan-Do-Check-Action)モデルもドロップする。規格の冒頭に入っている図がなくなるということ。PDCAという言い方もやめるのか。継続的改善は依然要求されるが、改善プロセスを一律に決める必要は無いだろうと言うことでしょう。PDCAも大きな回り方と小さい回り方が交錯するので理念としては理解できても何処まで細分化してもキリが無いものだ。ついでに加えるなら、プランとアクションの部分は重なるので継続的に見る場合はPDCAとすることは返って難しくなるものだ。
外部委託に関するセクションが新たに設定されると言う情報もサイト上にあるがはっきりしない。委託してもISMSの責任を回避できるものではないと言う主旨のものか。
.*.
2011年12月19日
業務委託先に情報資産を貸与したら?
委託終了時は如何するのですか？
返却、削除、廃棄など決めてあるのでしょうか？
そもそもどういう情報を渡しているか記録がありますか？
それぞれの始末に対してどのような証跡を求めるのでしょうか？
殆どのケースで、ノーコンです。管理箒状態。
.*.
翻って、委託先でなく社内の情報誌散逸いてはどうですか？
どういう情報資産を保有しているか把握していますか？
保管期限がきたらどのように始末するか決めていますか？
始末に対して証跡は何か残していますか？
社内で出来ないことを委託先に求めても方法論がないから結局は出来ないのだ。
.*.
情報資産台帳にヒストリーが刻めるようになっていますか？管理の履歴がみれるか？
毎年、その瞬間のスナップショット。
何が無くなって何が増えたのかすら分からない。
.*.
委託終了時は如何するのですか？
返却、削除、廃棄など決めてあるのでしょうか？
そもそもどういう情報を渡しているか記録がありますか？
それぞれの始末に対してどのような証跡を求めるのでしょうか？
殆どのケースで、ノーコンです。管理箒状態。
.*.
翻って、委託先でなく社内の情報誌散逸いてはどうですか？
どういう情報資産を保有しているか把握していますか？
保管期限がきたらどのように始末するか決めていますか？
始末に対して証跡は何か残していますか？
社内で出来ないことを委託先に求めても方法論がないから結局は出来ないのだ。
.*.
情報資産台帳にヒストリーが刻めるようになっていますか？管理の履歴がみれるか？
毎年、その瞬間のスナップショット。
何が無くなって何が増えたのかすら分からない。
.*.
事業継続管理におけるグッドポイントって何ですか？
規格どおりにやるとグッドポイントって変じゃないですか。規格どおりにやっている組織が少ないのですか。好きじゃないんだグッドポイントって。お前に言われたくない。何ですか、規格適合性にもレベルがあるんですか。もしあるなら示して欲しいね。そうしたら達成度評価が出来る。気分でグッドポイントなんて言わないで欲しい。
.*.
訓練及び実地を通してPDCAが回って継続的に改善されたらグッドポイントでもいいかな。去年と同じ今年かやらない、毎年やることが変わる、そういう手合いが多い中では当然かもしれない。
.*.
ポイント制にしてみましょう。
事業継続やりますと何処かに書いてあれば1点。
事業継続管理の担当者や体制を決めていれば1点。
リスクケーススタディがあれば1点。
BCP策定対象を決めていれば1点。
BCPが策定されていたら1点。
レビューがされていれば1点。
BCPのサブセットでも訓練していたら1点。
フルセットなら更に1点。
訓練の目標と実績が記録されていたら1点。
課題が抽出されていたら1点。
トップマネジメントに報告されていたら1点。
課題に基づいてBCPの見直しがあれば1点。
見直し結果がリスクアセスメントにも反映されていたら1点。
BCPのケースが昨年より増えていたら1点。
全社のリスク管理体制の中に位置づいていたら1点。
ビジネスパートナーや地域と一緒にやっていたら1点。
書き出すとキリが無い。10点以下でグッドポイントは有り得ないでしょう？
.*.
規格どおりにやるとグッドポイントって変じゃないですか。規格どおりにやっている組織が少ないのですか。好きじゃないんだグッドポイントって。お前に言われたくない。何ですか、規格適合性にもレベルがあるんですか。もしあるなら示して欲しいね。そうしたら達成度評価が出来る。気分でグッドポイントなんて言わないで欲しい。
.*.
訓練及び実地を通してPDCAが回って継続的に改善されたらグッドポイントでもいいかな。去年と同じ今年かやらない、毎年やることが変わる、そういう手合いが多い中では当然かもしれない。
.*.
ポイント制にしてみましょう。
事業継続やりますと何処かに書いてあれば1点。
事業継続管理の担当者や体制を決めていれば1点。
リスクケーススタディがあれば1点。
BCP策定対象を決めていれば1点。
BCPが策定されていたら1点。
レビューがされていれば1点。
BCPのサブセットでも訓練していたら1点。
フルセットなら更に1点。
訓練の目標と実績が記録されていたら1点。
課題が抽出されていたら1点。
トップマネジメントに報告されていたら1点。
課題に基づいてBCPの見直しがあれば1点。
見直し結果がリスクアセスメントにも反映されていたら1点。
BCPのケースが昨年より増えていたら1点。
全社のリスク管理体制の中に位置づいていたら1点。
ビジネスパートナーや地域と一緒にやっていたら1点。
書き出すとキリが無い。10点以下でグッドポイントは有り得ないでしょう？
.*.
バックアップ・リストアはセットの管理策です
リストアの保証が無いバックアップには何の意味もない。経費の無駄でしかない。
リストアは怖くて出来ない？
そんなバックアップは止めなさい。年に1〜2回はリストアを訓練しなさい。もしくは訓練でなく、バックアップ管理手順の中にリストアを入れる工夫。
バックアップシステムも同様。待機系を動かしたのは導入時に1回だけでは馬鹿と言われる。懲戒解雇でしょう。奇数月はA系、偶数月はB系などとする利用もある。毎月訓練しているのだから。
リストアの保証が無いバックアップには何の意味もない。経費の無駄でしかない。
リストアは怖くて出来ない？
そんなバックアップは止めなさい。年に1〜2回はリストアを訓練しなさい。もしくは訓練でなく、バックアップ管理手順の中にリストアを入れる工夫。
バックアップシステムも同様。待機系を動かしたのは導入時に1回だけでは馬鹿と言われる。懲戒解雇でしょう。奇数月はA系、偶数月はB系などとする利用もある。毎月訓練しているのだから。
共有キャビネの鍵管理
施錠管理するキャビネットがあって、その鍵を利用者全員に配布しておくことの是非。
物がキャビネットとすると、数人（２〜３人）のレベルなら違和感が無い。10人を超えたらクレージーな感じだ。5〜6人でも普通ではない。
普通の施錠管理はと言えば、誰かが朝開いて、誰かが夕方閉めれば済むこと。機密が高い場合は、誰かは管理職、そうでなければ事務補助の人かな。
鍵を利用した記録を求める審査員が居るらしい。
どういう意味があるんだろう。中の物（文書類、メディア類）が紛失していたらトレースできるだろうか。どうしても記録にこだわる場合は、利用目的（アクセスした情報と用途）も記録しないと意味が無いかな。鍵を各担当に持たせたら、記録をスキップされたらそれまでです。鍵の管理者を別に定めて、記録をとれば一定のトレーサビリティは確保できる。
施錠管理するキャビネットがあって、その鍵を利用者全員に配布しておくことの是非。
物がキャビネットとすると、数人（２〜３人）のレベルなら違和感が無い。10人を超えたらクレージーな感じだ。5〜6人でも普通ではない。
普通の施錠管理はと言えば、誰かが朝開いて、誰かが夕方閉めれば済むこと。機密が高い場合は、誰かは管理職、そうでなければ事務補助の人かな。
鍵を利用した記録を求める審査員が居るらしい。
どういう意味があるんだろう。中の物（文書類、メディア類）が紛失していたらトレースできるだろうか。どうしても記録にこだわる場合は、利用目的（アクセスした情報と用途）も記録しないと意味が無いかな。鍵を各担当に持たせたら、記録をスキップされたらそれまでです。鍵の管理者を別に定めて、記録をとれば一定のトレーサビリティは確保できる。
外部に提出する文書に会社名を入れていない
よくある話。部門名は入れて会社名は入れない。表紙が煩くなるから。封筒とかにも社名はある。
でも文書が一人歩きをすると著作物に対する責任、あるいは権利の問題が出ないとも限らない。しっかり社名も入れておきましょう。
まあ、部署名が入っていれば内容も分かっているのだから、社名は分かるね。大した話ではない。
よくある話。部門名は入れて会社名は入れない。表紙が煩くなるから。封筒とかにも社名はある。
でも文書が一人歩きをすると著作物に対する責任、あるいは権利の問題が出ないとも限らない。しっかり社名も入れておきましょう。
まあ、部署名が入っていれば内容も分かっているのだから、社名は分かるね。大した話ではない。
2011年12月17日
ソフトウエアライセンス管理台帳の作り方
コンサル先で時々見かける台帳の一つにソフトウエアライセンス管理台帳があります。名称はクライアント様それぞれです。
内容は、買ったライセンス10本として、その10本のライセンスがそれぞれ何処に配布されているかを表にしたものです。配布先としては、部署命であったり、担当者名であったり、パソコン名であったりする訳ですが、これは正しい利用者は誰かをを示したものに過ぎません。
ライセンスを管理しているには違いありませんが、この内容では、コンプライアンス（法令順守）の観点からは不十分です。
「全てのパソコン、サーバー上にどんなソフトがインストールされ利用されているか、もしくは利用可能になっているかを洗い出されること」が先ず最初に必要です。次に、洗い出されたソフトウエアに対してライセンスの裏づけを行います。全て裏づけが取れれば、問題ありませんが、裏づけが取れないものがあれば、不正使用ですから削除します。もしくは事情（削除が出来ない理由がある場合）を説明して即日購入をおこないます。
単純な作業ですが、組織規模が大きい場合は相当苦労することになります。情報システム部門にノウハウが必要です。特に面倒なのがインストールされたソフトウエアとライセンスとの突合せ。一括管理体制を敷く組織では、インストール数とライセンス数のそれぞれの総数を求めて、その比較で済ますことが出来ます。このときは資源管理ツールなどを利用することになります。
部門管理の場合は一括管理と同じよう総数管理のな考え方でもいいですが、ライセンスを個別に識別して個別管理の方法を取ることもできます。
いずれの場合も『網羅性の確保』が課題になります。
.*.
この台帳はパソコンHWの管理にも利用できますし、適切に維持することにより、過剰なライセンス購入を防止できます。またはフリーソフトの管理にも利用できます。
ところが目的別にめいめい勝手に台帳を作りますから、組織全体では極めて無駄な・非効率な管理作業をやることになります。縦割り組織、縦割りの管理の一般的な弊害です。
.*.
コンサル先で時々見かける台帳の一つにソフトウエアライセンス管理台帳があります。名称はクライアント様それぞれです。
内容は、買ったライセンス10本として、その10本のライセンスがそれぞれ何処に配布されているかを表にしたものです。配布先としては、部署命であったり、担当者名であったり、パソコン名であったりする訳ですが、これは正しい利用者は誰かをを示したものに過ぎません。
ライセンスを管理しているには違いありませんが、この内容では、コンプライアンス（法令順守）の観点からは不十分です。
「全てのパソコン、サーバー上にどんなソフトがインストールされ利用されているか、もしくは利用可能になっているかを洗い出されること」が先ず最初に必要です。次に、洗い出されたソフトウエアに対してライセンスの裏づけを行います。全て裏づけが取れれば、問題ありませんが、裏づけが取れないものがあれば、不正使用ですから削除します。もしくは事情（削除が出来ない理由がある場合）を説明して即日購入をおこないます。
単純な作業ですが、組織規模が大きい場合は相当苦労することになります。情報システム部門にノウハウが必要です。特に面倒なのがインストールされたソフトウエアとライセンスとの突合せ。一括管理体制を敷く組織では、インストール数とライセンス数のそれぞれの総数を求めて、その比較で済ますことが出来ます。このときは資源管理ツールなどを利用することになります。
部門管理の場合は一括管理と同じよう総数管理のな考え方でもいいですが、ライセンスを個別に識別して個別管理の方法を取ることもできます。
いずれの場合も『網羅性の確保』が課題になります。
.*.
この台帳はパソコンHWの管理にも利用できますし、適切に維持することにより、過剰なライセンス購入を防止できます。またはフリーソフトの管理にも利用できます。
ところが目的別にめいめい勝手に台帳を作りますから、組織全体では極めて無駄な・非効率な管理作業をやることになります。縦割り組織、縦割りの管理の一般的な弊害です。
.*.
2011年12月16日
Pマーク制度の弊害?
馬鹿な審査員が馬鹿なことを言って帰る。始末が悪い。個人情報を扱うところだけが馬鹿をやらされるなら我慢も出来るが、関係ない部門まで馬鹿をやらされるから堪ったものでない。こんな制度との付き合いはいい加減にして更新はやめられないか。
悪政の片棒を担いでいるような気がする。
せめてISMSレベルの審査が出来ないものか。
馬鹿な審査員が馬鹿なことを言って帰る。始末が悪い。個人情報を扱うところだけが馬鹿をやらされるなら我慢も出来るが、関係ない部門まで馬鹿をやらされるから堪ったものでない。こんな制度との付き合いはいい加減にして更新はやめられないか。
悪政の片棒を担いでいるような気がする。
せめてISMSレベルの審査が出来ないものか。
2011年12月12日
移転審査って何ですか？
検索すると審査機関を変えることらしい。今まで審査機関Aだったけど、これから審査機関Bにする。株式の預け替えみたいに簡単に出来る。でも建前だろうね。簡単でなければいけないけど、本当は簡単でないよ。同じ現象を見てOKですねという医者もいれば入院ですと言う医者もいる。医者の目利きだけが違いでなくて病院経営状態も影響する。
そう言えばどこかに凄い会社がありましな。
癒着の隙を作らないために、不満だからと言う理由でなく、3年経過を理由に、いきなり審査機関を変えてしまうのだ。素晴らしい。
引越し魔というのがいましたが、審査機関の引越し、乗り換え、も引越し魔ですね。初年度キャンペーンなんかがあればトータルでお安くいけるのかな。
話を戻して。移転審査は、だから、隣からこちらに来るんだけど不良クライアントでは困るから、一応簡単に確認しますが、それが移転審査ですね。困るのは、事件と事故が多い。放置された重大な不適合。支払いは当然ですね。踏み倒し？
だから、何故、移転するのかしつこく聞いてくる。多いのは相性というか消えない不信感。担当者が嫌で忌避して、また嫌なタイプが来たりすると、変えるしかない。お粗末な理由ですね。お前が嫌がられていたりして。
最近はもっとドライに金が決めて。安いほうへ安いほうへ移転の流れ。安いに向かって転がる移転の流れ。その理由は？
.*.
＜安きに流れる移転の真因＞
審査機関が墓穴を掘っている。
クライアントには継続的改善。絶えざる変革。本質にアプローチ。なんだかんだ正論？を振りまいておいて、審査機関はと言えば、全く対極の態度を取っている。例えば、前任者を否定するな。負担を掛けないように。簡単に手際よく。審査をセレモニー化して、波風立てないで、年貢だけ確実に稼ごうと言うのだから。付加価値審査とよく聞くが、何が付加価値化すら理解していないみたいだ。
本当の付加価値はおもねるしんさではありえない。戦う審査。変化変革を促す審査。現状否定。新しい価値観を提示すること。何がその業界その業務のフロントラインかが見えていなければ新しい価値観は提示できない。
お作法で済ますなぞるだけの審査では泰樹に流れて当然。統合審査、複合審査、言葉は変えても結局、手際よくやるだけの無価値審査。
検索すると審査機関を変えることらしい。今まで審査機関Aだったけど、これから審査機関Bにする。株式の預け替えみたいに簡単に出来る。でも建前だろうね。簡単でなければいけないけど、本当は簡単でないよ。同じ現象を見てOKですねという医者もいれば入院ですと言う医者もいる。医者の目利きだけが違いでなくて病院経営状態も影響する。
そう言えばどこかに凄い会社がありましな。
癒着の隙を作らないために、不満だからと言う理由でなく、3年経過を理由に、いきなり審査機関を変えてしまうのだ。素晴らしい。
引越し魔というのがいましたが、審査機関の引越し、乗り換え、も引越し魔ですね。初年度キャンペーンなんかがあればトータルでお安くいけるのかな。
話を戻して。移転審査は、だから、隣からこちらに来るんだけど不良クライアントでは困るから、一応簡単に確認しますが、それが移転審査ですね。困るのは、事件と事故が多い。放置された重大な不適合。支払いは当然ですね。踏み倒し？
だから、何故、移転するのかしつこく聞いてくる。多いのは相性というか消えない不信感。担当者が嫌で忌避して、また嫌なタイプが来たりすると、変えるしかない。お粗末な理由ですね。お前が嫌がられていたりして。
最近はもっとドライに金が決めて。安いほうへ安いほうへ移転の流れ。安いに向かって転がる移転の流れ。その理由は？
.*.
＜安きに流れる移転の真因＞
審査機関が墓穴を掘っている。
クライアントには継続的改善。絶えざる変革。本質にアプローチ。なんだかんだ正論？を振りまいておいて、審査機関はと言えば、全く対極の態度を取っている。例えば、前任者を否定するな。負担を掛けないように。簡単に手際よく。審査をセレモニー化して、波風立てないで、年貢だけ確実に稼ごうと言うのだから。付加価値審査とよく聞くが、何が付加価値化すら理解していないみたいだ。
本当の付加価値はおもねるしんさではありえない。戦う審査。変化変革を促す審査。現状否定。新しい価値観を提示すること。何がその業界その業務のフロントラインかが見えていなければ新しい価値観は提示できない。
お作法で済ますなぞるだけの審査では泰樹に流れて当然。統合審査、複合審査、言葉は変えても結局、手際よくやるだけの無価値審査。
2011年12月11日
チェックリストって殆ど無駄じゃないの？
ISOの要求事項がある時に、それを展開してチェックリストを作っているのを見かけるが、視点・論点が細部に入ってしまって大枠が抜けてしまう例をよく見る。早く言えば、自分で考えてチェックしていくことを辞めてしまう。思考停止を招く弊害も考えて良さそうだ。
チェックリストなんて教育・経験の少ない人でも一定の成果を得るための方便に過ぎない。
ですから、やたらチェックリストを要求する人がいるが、その人の頭も思考停止に陥っている可能性を考えてあげた方が良い。ただでさえ、ＩＳＭＳの規格はチェックリストみたいな付属書をつけているのだから、これ以上、細かく砕くのはやりすぎでしょう。
何も考えずに規格書通りに確認したほうが余程間違えない。特に何処の誰が作ったか分からないチェックリストなどは発想する世界観が違うのだから、暇なときに眺めるだけで充分でしょう。
.*.
ISOの要求事項がある時に、それを展開してチェックリストを作っているのを見かけるが、視点・論点が細部に入ってしまって大枠が抜けてしまう例をよく見る。早く言えば、自分で考えてチェックしていくことを辞めてしまう。思考停止を招く弊害も考えて良さそうだ。
チェックリストなんて教育・経験の少ない人でも一定の成果を得るための方便に過ぎない。
ですから、やたらチェックリストを要求する人がいるが、その人の頭も思考停止に陥っている可能性を考えてあげた方が良い。ただでさえ、ＩＳＭＳの規格はチェックリストみたいな付属書をつけているのだから、これ以上、細かく砕くのはやりすぎでしょう。
何も考えずに規格書通りに確認したほうが余程間違えない。特に何処の誰が作ったか分からないチェックリストなどは発想する世界観が違うのだから、暇なときに眺めるだけで充分でしょう。
.*.
適用宣言書の作り方
これはどこかに解説書でも出ているのではないでしょうか。コンサルに出掛けるたびにマトリクス氷河顔を出す。どういう必然性があるんだろう。
脆弱性評価で出てくる。
現在取っている数々の施策(アクティビティActivity)。
リスクアセスメントの結果、新たに導入するいくつかの施策(アクティビティActivity)。
アクティビティの数が数十で収まればいいが、下手すると、数百に及ぶ。手作業の限界かも。数千ってことも組織規模によっては、纏め方によってはあり得る。内容的に重複するアクティビティあるから、これをどのように整理するかもコンサルのノウハウとなる。
一つのアクティビティを取り出して、付属書Aのどの管理策に該当するか確認する。この作業が冒頭のマトリクスを使ってやることになる。横に133個を並べ、たてにアクティビティを並べる。1万個のセルを埋めていく作業になるわけだ。
133個の管理策で、1箇所でもチェックがあれば、それは採用と言う判断。
適用宣言書に記載する内容：
管理策（＃１-１３３）
アクティビティ＝管理策の中身として実際に実施している内容。
管理文書＝アクティビティ詳細手順を記載している管理文書。
.*.
単純な作業実見える。脆弱性評価が出来たらの話だから、このマトリクス表に来るまでが又大変なんですね。
.*.
この基本的な手順を何も踏まないで適用宣言書を作っている組織もあります。コンサルも手抜き？ 時間が無いからではなくて、クライアントの不理解が原因。
これはどこかに解説書でも出ているのではないでしょうか。コンサルに出掛けるたびにマトリクス氷河顔を出す。どういう必然性があるんだろう。
脆弱性評価で出てくる。
現在取っている数々の施策(アクティビティActivity)。
リスクアセスメントの結果、新たに導入するいくつかの施策(アクティビティActivity)。
アクティビティの数が数十で収まればいいが、下手すると、数百に及ぶ。手作業の限界かも。数千ってことも組織規模によっては、纏め方によってはあり得る。内容的に重複するアクティビティあるから、これをどのように整理するかもコンサルのノウハウとなる。
一つのアクティビティを取り出して、付属書Aのどの管理策に該当するか確認する。この作業が冒頭のマトリクスを使ってやることになる。横に133個を並べ、たてにアクティビティを並べる。1万個のセルを埋めていく作業になるわけだ。
133個の管理策で、1箇所でもチェックがあれば、それは採用と言う判断。
適用宣言書に記載する内容：
管理策（＃１-１３３）
アクティビティ＝管理策の中身として実際に実施している内容。
管理文書＝アクティビティ詳細手順を記載している管理文書。
.*.
単純な作業実見える。脆弱性評価が出来たらの話だから、このマトリクス表に来るまでが又大変なんですね。
.*.
この基本的な手順を何も踏まないで適用宣言書を作っている組織もあります。コンサルも手抜き？ 時間が無いからではなくて、クライアントの不理解が原因。
リスクアセスメントの方法論を検討する前提
何の事前情報も無く、一般的な方法としてリスクアセスメントの方法論を検討することが出来るかと言えば、一般論の範囲では充分可能だ。組織の特性、事業と業務の特性、情報の特性、管理の特性が事前情報として入ることで一般論は修正されることはあるか。充分にあり得ることだ。
しかし、リスクアセスメントの手順なんて何処でも同じはず。前提の何が変わるとリスクアセスメントの何が変わるのだろう？
.*.
適用範囲がどうなっていようが手順の妥当性には変更が生じるわけではないから、リス汗面と手順の検討はいつ始めてもいいはず。手順の妥当性は不変的な価値である。
.*.
トップダウン手順を考えてみよう！
事業ミッション。株主との約束。ビジョン。
事業の構造。外部構造と内部構造と。長期計画。
組織と役割責任と方針展開と年度計画。
具体的な業務と業務プロセス。
どの↑↑↑業務↑↑↑を適用範囲としたか？ または適用範囲の↑↑↑業務↑↑↑をどのように表現したか？
.*.
リスクアセスメントが妥当かどうかは対象となる業務に対するアセスメントかどうかだけであって、手順そのものは殆ど影響を受けない。特に詳細リスクアセスメントの手順は方法論（少なくとも見かけ上の方法論）が確立している。規格はその確立した方法論に沿って策定されている。
簡略化するときに、組織、業務、資産などの特性を踏まえて何処まで可能かの議論を続けることは可能。その場合は、適用範囲の特性を踏まえることになる。
従って、リスクアセスメントの妥当性を見る場合は、組織が何らかの工夫をしている（標準的な詳細リスクアセスメントを採用しない）場合は、適用範囲の特性を抑える必要がある。と言うことになるようだ。
.*.
業務プロセス。対外的に示す業務が基幹プロセス。それを支えるプロセスが支援プロセス。
基幹系は：企画、開発、製造、物流、販売など。
支援系は：管理業務、人事・総務・経理など。
情報は機関化支援か？ 支援入れるケースが多い。これが経営上の難しいところです。品質を基幹系に入れるなら、情報も基幹系に入れておかないと間違えます。ISMSは余った人材で間に合わされるだけの、余計な仕事にされてしまう。機能別管理に上手く収める工夫も必要ですね。
.*.
何の事前情報も無く、一般的な方法としてリスクアセスメントの方法論を検討することが出来るかと言えば、一般論の範囲では充分可能だ。組織の特性、事業と業務の特性、情報の特性、管理の特性が事前情報として入ることで一般論は修正されることはあるか。充分にあり得ることだ。
しかし、リスクアセスメントの手順なんて何処でも同じはず。前提の何が変わるとリスクアセスメントの何が変わるのだろう？
.*.
適用範囲がどうなっていようが手順の妥当性には変更が生じるわけではないから、リス汗面と手順の検討はいつ始めてもいいはず。手順の妥当性は不変的な価値である。
.*.
トップダウン手順を考えてみよう！
事業ミッション。株主との約束。ビジョン。
事業の構造。外部構造と内部構造と。長期計画。
組織と役割責任と方針展開と年度計画。
具体的な業務と業務プロセス。
どの↑↑↑業務↑↑↑を適用範囲としたか？ または適用範囲の↑↑↑業務↑↑↑をどのように表現したか？
.*.
リスクアセスメントが妥当かどうかは対象となる業務に対するアセスメントかどうかだけであって、手順そのものは殆ど影響を受けない。特に詳細リスクアセスメントの手順は方法論（少なくとも見かけ上の方法論）が確立している。規格はその確立した方法論に沿って策定されている。
簡略化するときに、組織、業務、資産などの特性を踏まえて何処まで可能かの議論を続けることは可能。その場合は、適用範囲の特性を踏まえることになる。
従って、リスクアセスメントの妥当性を見る場合は、組織が何らかの工夫をしている（標準的な詳細リスクアセスメントを採用しない）場合は、適用範囲の特性を抑える必要がある。と言うことになるようだ。
.*.
業務プロセス。対外的に示す業務が基幹プロセス。それを支えるプロセスが支援プロセス。
基幹系は：企画、開発、製造、物流、販売など。
支援系は：管理業務、人事・総務・経理など。
情報は機関化支援か？ 支援入れるケースが多い。これが経営上の難しいところです。品質を基幹系に入れるなら、情報も基幹系に入れておかないと間違えます。ISMSは余った人材で間に合わされるだけの、余計な仕事にされてしまう。機能別管理に上手く収める工夫も必要ですね。
.*.
2011年12月03日
オフィス入室用のキーカードを忘れたら？
諸先生の話を聞くと忘れた時の会社側の対応も色々あるようで興味深い。冗談もあります。この頃は電子錠が当たり前になってきている。社員証を兼用する企業もあるようだ。一方、ビルの入館はビル管理会社が方法を決めるので、雑居の場合は一貫性のある入館管理・入室管理ができるか課題も残ります。
カードで入室を管理する以上、カードを忘れる・紛失するのは避けられません。
どないする？
電話で同僚を呼び出して入室。出入りは友連れで済ます。不便しながら一日を黙って過ごす。会社側には特に情報は入らない。
嫌、社員通用口はいつもロックされていないので特に不自由はない。黙っていても分からない。
忘れたことを上司に報告するが、やはり同様に不便な一日を過ごす。上司はその場その日の問題として済ます。
カード管理部門が予備カードを用意していて貸し出す。貸し出し管理の記録が残る。
セキュリティの弱点に類する記録の一つとしてＩＳＭＳ事務局部門にも報告される。忘れた理由も書く。
忘れたと紛失したは紙一重と理解して、当該カードの利用記録（不正利用の有無）を確認する。休日をはさんでいる時は重要。
不測の事態に備えて、当該カードの利用を一旦ロック（無効化）する。予備カード返却時にロックを解除する。翌日が休日の時は重要。
カード管理部門の連絡を受けてからロックするまでの時間、及び利用記録確認までの時間を記録する。
対策として、非接触カードだから携帯フェリカに入れてしまう。
嫌、ついでにパソコン利用キーをパソリ化して全部一緒にしてしまう。
こうなるとキーを忘れたら仕事にならないので家まで取りに帰らせる。
やはりバイオ認証しかありませんね。
.*.
諸先生の話を聞くと忘れた時の会社側の対応も色々あるようで興味深い。冗談もあります。この頃は電子錠が当たり前になってきている。社員証を兼用する企業もあるようだ。一方、ビルの入館はビル管理会社が方法を決めるので、雑居の場合は一貫性のある入館管理・入室管理ができるか課題も残ります。
カードで入室を管理する以上、カードを忘れる・紛失するのは避けられません。
どないする？
電話で同僚を呼び出して入室。出入りは友連れで済ます。不便しながら一日を黙って過ごす。会社側には特に情報は入らない。
嫌、社員通用口はいつもロックされていないので特に不自由はない。黙っていても分からない。
忘れたことを上司に報告するが、やはり同様に不便な一日を過ごす。上司はその場その日の問題として済ます。
カード管理部門が予備カードを用意していて貸し出す。貸し出し管理の記録が残る。
セキュリティの弱点に類する記録の一つとしてＩＳＭＳ事務局部門にも報告される。忘れた理由も書く。
忘れたと紛失したは紙一重と理解して、当該カードの利用記録（不正利用の有無）を確認する。休日をはさんでいる時は重要。
不測の事態に備えて、当該カードの利用を一旦ロック（無効化）する。予備カード返却時にロックを解除する。翌日が休日の時は重要。
カード管理部門の連絡を受けてからロックするまでの時間、及び利用記録確認までの時間を記録する。
対策として、非接触カードだから携帯フェリカに入れてしまう。
嫌、ついでにパソコン利用キーをパソリ化して全部一緒にしてしまう。
こうなるとキーを忘れたら仕事にならないので家まで取りに帰らせる。
やはりバイオ認証しかありませんね。
.*.
受託・委託の注意点
まあ、普通は機密保持契約。次に、再委託の禁止事項。
契約が継続的な場合は、情報システム関連サービスでなくても、情報の受け渡しが有る場合は広く捕らえて、定期的な監査、重要な変化点に対する対応が必要になる。
委託先に対するセキュリティ要求事項＝契約要件を整理することが必要。
＜委託契約＞
機密保持条項を入れること。再委託は禁止または事前に審査・承認を要求すること。随時任意の監査権を入れること。情報セキュリティ要求事項を入れること。この場合は、基本事項・共通事項に加えて、委託時の個別案件毎に設定できるよう別紙書きを前提とする。
事件事故時の緊急対応に関連する要求事項に加えて、事業継続管理の観点からの要求へも配慮したもので無ければいけない。
二兆管理レベルについても定期的な報告を求めること。
◆ 契約管理で問題になるのは、
実際の委託業務のオーナー（主管）部門と、契約管理・委託先管理の責任部門が違う場合に発生する連携の不備です。複数の部門が色々な業務をある企業に委託している場合は、どの部門が何に対して責任を負っているのかはっきりしません。業務ごとに異なる要求レベルを無視して適当なアンケートで済ます。結果もフィードバックされない。形だけ規格要求に沿う。
委託先から足元見られるのは必至。もっとも、委託先の方が大企業の場合もありますから、何から何まで言いなりとは行きません。
.*.
まあ、普通は機密保持契約。次に、再委託の禁止事項。
契約が継続的な場合は、情報システム関連サービスでなくても、情報の受け渡しが有る場合は広く捕らえて、定期的な監査、重要な変化点に対する対応が必要になる。
委託先に対するセキュリティ要求事項＝契約要件を整理することが必要。
＜委託契約＞
機密保持条項を入れること。再委託は禁止または事前に審査・承認を要求すること。随時任意の監査権を入れること。情報セキュリティ要求事項を入れること。この場合は、基本事項・共通事項に加えて、委託時の個別案件毎に設定できるよう別紙書きを前提とする。
事件事故時の緊急対応に関連する要求事項に加えて、事業継続管理の観点からの要求へも配慮したもので無ければいけない。
二兆管理レベルについても定期的な報告を求めること。
◆ 契約管理で問題になるのは、
実際の委託業務のオーナー（主管）部門と、契約管理・委託先管理の責任部門が違う場合に発生する連携の不備です。複数の部門が色々な業務をある企業に委託している場合は、どの部門が何に対して責任を負っているのかはっきりしません。業務ごとに異なる要求レベルを無視して適当なアンケートで済ます。結果もフィードバックされない。形だけ規格要求に沿う。
委託先から足元見られるのは必至。もっとも、委託先の方が大企業の場合もありますから、何から何まで言いなりとは行きません。
.*.
可用性価値
どの情報がどれだけ時間を要するとどれくらい被害が発生するのか。この場合、軸が2つあってややこしい。紛失と漏洩は違うが、出てこないと紛失になり、紛失は漏洩のリスクも併せ持つので大問題。
▲議論不足
どの情報がどれだけ時間を要するとどれくらい被害が発生するのか。この場合、軸が2つあってややこしい。紛失と漏洩は違うが、出てこないと紛失になり、紛失は漏洩のリスクも併せ持つので大問題。
▲議論不足
可用性の議論
その情報を必要とする人が必要な時にアクセスできることの実現性を可用性という。
可用性価値とは、必要な時にアクセス出来ないことにより発生する被害相当額の大きさ。
可用性価値の喪失によって生ずる事態は、顧客クレーム（社会信用や市場機会の喪失）、業務停止に繋がり、それによる損害額が考えられる。
どの程度の時間でアクセスできるかという観点からの価値評価も考えられる。必要な時といっても時間幅が有るとする考え方だ。
最強はリアルタイム。常にその情報にアクセスできる状態。手元あるいは居室内に置く情報。24時間運用のサーバー内に有る情報も最強のカテゴリーに入るでしょう。時間差なし。
最悪はロスト（紛失）で二度とアクセスできない。
管理策の程度で区分する。求められたら直ぐに出せる状態。直ぐそば管理。外部倉庫なら、翌日アクセス。メディアに落としてあるものなら、インデックスがないと分かりにくい。インデックスも外にある場合はもう1日必要。
外部参照データは、
可用性の喪失とは、情報にアクセスできないこと。当てが外れること。
.*.
.*.
.*.
情報が必要になったときに直ぐ必要なのか一定の時間後に必要なのか。タイミングの要求。これ難しいですね。大方は気付いたときに直ぐに必要になります。この情報は３日後でいいですということは会議などを想定すればありうることですが、問題がすり替わる懸念が有る。
情報へのアクセス要求が出て、直ぐに対応が必要なものはAランク。翌日でいいものはBランク。永久にアクセスできなくてもいいものはDランク。とか適当に決める組織がありますが、何か変ですね。
アクセスのスピードと被害額の大きさとは別次元の概念です。
ヘルプデスクではレスポンスタイムは秒オーダーで、個別の対応が入っても数分が限界。顧客のクレームに繋がる。
経営者が経営会議などで必要とする計画実績などの情報は同様に数秒、数分のオーダーが期待値です。経営のスピードが落ちる。
例えば、設計作業時に要件情報にアクセスするのはやはり同様に数秒、数分。プロセスのスピードが落ちる。
.*.
可用性の議論が難しいのは情報の質と遅延の程度によりインパクト（損害額）は変わるだろうと思われるからです。
＜この問題を単純化することが出来ます＞
その情報を必要とする人が必要な時にアクセスできることの実現性を可用性という。
可用性価値とは、必要な時にアクセス出来ないことにより発生する被害相当額の大きさ。
可用性価値の喪失によって生ずる事態は、顧客クレーム（社会信用や市場機会の喪失）、業務停止に繋がり、それによる損害額が考えられる。
どの程度の時間でアクセスできるかという観点からの価値評価も考えられる。必要な時といっても時間幅が有るとする考え方だ。
最強はリアルタイム。常にその情報にアクセスできる状態。手元あるいは居室内に置く情報。24時間運用のサーバー内に有る情報も最強のカテゴリーに入るでしょう。時間差なし。
最悪はロスト（紛失）で二度とアクセスできない。
管理策の程度で区分する。求められたら直ぐに出せる状態。直ぐそば管理。外部倉庫なら、翌日アクセス。メディアに落としてあるものなら、インデックスがないと分かりにくい。インデックスも外にある場合はもう1日必要。
外部参照データは、
可用性の喪失とは、情報にアクセスできないこと。当てが外れること。
.*.
.*.
.*.
情報が必要になったときに直ぐ必要なのか一定の時間後に必要なのか。タイミングの要求。これ難しいですね。大方は気付いたときに直ぐに必要になります。この情報は３日後でいいですということは会議などを想定すればありうることですが、問題がすり替わる懸念が有る。
情報へのアクセス要求が出て、直ぐに対応が必要なものはAランク。翌日でいいものはBランク。永久にアクセスできなくてもいいものはDランク。とか適当に決める組織がありますが、何か変ですね。
アクセスのスピードと被害額の大きさとは別次元の概念です。
ヘルプデスクではレスポンスタイムは秒オーダーで、個別の対応が入っても数分が限界。顧客のクレームに繋がる。
経営者が経営会議などで必要とする計画実績などの情報は同様に数秒、数分のオーダーが期待値です。経営のスピードが落ちる。
例えば、設計作業時に要件情報にアクセスするのはやはり同様に数秒、数分。プロセスのスピードが落ちる。
.*.
可用性の議論が難しいのは情報の質と遅延の程度によりインパクト（損害額）は変わるだろうと思われるからです。
＜この問題を単純化することが出来ます＞
2011年12月02日
資産価値が[C+I+A]とか[C*I*A]とかの困り者
資産価値をＣＩＡごとに求めていたので、まあ普通のやり方と思っていたら、最後に、
資産価値＝Ｃ+Ｉ+Ａとか、資産価値＝Ｃ*Ｉ*Ａとか、時には、資産価値＝Ｃの二乗*Ｉ*Ａとかに遭遇することがあるようです。ＣＩＡは野球の選手なら守備率、打率、盗塁成功率のようなもので、全く次元をことにするものですから、これらの数字を直接演算操作しても得られる数字の意味は良く分からないものになります。クライアントとしては総合評価のつもりらしいですが、確かに傾向として、数字が大きいければ管理コストが掛かる情報資産であろうということは推測できるかもしれません。
このＣＩＡ次元を喪失させた総合？資産価値をベースにリスクアセスに挑む組織もあるようですが、そうなると完全に論理的破綻となります。2002年前後からＩＳＭＳは始まっていますが、延々と論理破綻のままリスクアセスメントを続けている企業もあるようです。先行企業ですからそれなりにビッグネームのものもあります。そうなると、関係したコンサルとか審査とかの側にも罪がありますね。
論理矛盾（ＣＩＡ次元の喪失）に気付いた組織では総合？資産価値は求めても参考情報として併記するだけで、ＣＩＡごとのリスク評価には使用しません。当然のことです。
.*.
機密性価値だけ二乗するのは機密性を重視しようとするからですが、全く意味の無いことです。理解していないことを公表しているようなものですね。普通に機密性価値に対するリスク評価をやれば済むことです。ＣＩＡ毎にリスク評価、リスク対応の労を惜しむばかりに総合指標を無理やり作り出して無意味なリスク分析に走ろうとするのは今でも少なくないらしい。
.*.
少し脱線しますが、ＣＩＡ毎にリスク評価をやる場合に、Ｃだけ5段階、ＩＡは3段階とするなどの例があります。資産価値×脅威（3段階）×脆弱性（3段階）とすると、Ｃは最大４５レンジ、ＩＡは最大２７レンジになります。リスク値は基本的には期待損失額がベースになる考え方のものですから、レンジがずれていること自体が歪んだ評価になります。当然、同じレンジ幅で無ければいけません。
機密性価値を重視したい場合は、受容レベルをＣについてだけ厳しく設定すれば済むことです。受容レベルはダイナミックファクター。管理上のパラメータですから適宜見直す発想が必要ですが、どうしても永久不滅の固定的な基準として理解してしまう組織があるようです。
.*.
資産価値をＣＩＡごとに求めていたので、まあ普通のやり方と思っていたら、最後に、
資産価値＝Ｃ+Ｉ+Ａとか、資産価値＝Ｃ*Ｉ*Ａとか、時には、資産価値＝Ｃの二乗*Ｉ*Ａとかに遭遇することがあるようです。ＣＩＡは野球の選手なら守備率、打率、盗塁成功率のようなもので、全く次元をことにするものですから、これらの数字を直接演算操作しても得られる数字の意味は良く分からないものになります。クライアントとしては総合評価のつもりらしいですが、確かに傾向として、数字が大きいければ管理コストが掛かる情報資産であろうということは推測できるかもしれません。
このＣＩＡ次元を喪失させた総合？資産価値をベースにリスクアセスに挑む組織もあるようですが、そうなると完全に論理的破綻となります。2002年前後からＩＳＭＳは始まっていますが、延々と論理破綻のままリスクアセスメントを続けている企業もあるようです。先行企業ですからそれなりにビッグネームのものもあります。そうなると、関係したコンサルとか審査とかの側にも罪がありますね。
論理矛盾（ＣＩＡ次元の喪失）に気付いた組織では総合？資産価値は求めても参考情報として併記するだけで、ＣＩＡごとのリスク評価には使用しません。当然のことです。
.*.
機密性価値だけ二乗するのは機密性を重視しようとするからですが、全く意味の無いことです。理解していないことを公表しているようなものですね。普通に機密性価値に対するリスク評価をやれば済むことです。ＣＩＡ毎にリスク評価、リスク対応の労を惜しむばかりに総合指標を無理やり作り出して無意味なリスク分析に走ろうとするのは今でも少なくないらしい。
.*.
少し脱線しますが、ＣＩＡ毎にリスク評価をやる場合に、Ｃだけ5段階、ＩＡは3段階とするなどの例があります。資産価値×脅威（3段階）×脆弱性（3段階）とすると、Ｃは最大４５レンジ、ＩＡは最大２７レンジになります。リスク値は基本的には期待損失額がベースになる考え方のものですから、レンジがずれていること自体が歪んだ評価になります。当然、同じレンジ幅で無ければいけません。
機密性価値を重視したい場合は、受容レベルをＣについてだけ厳しく設定すれば済むことです。受容レベルはダイナミックファクター。管理上のパラメータですから適宜見直す発想が必要ですが、どうしても永久不滅の固定的な基準として理解してしまう組織があるようです。
.*.
トーマツ方式リスクアセスメントの弱点は本当に弱点か？
先ず、
資産の洗い出しはプロセス毎に行う。通常は小さな業務グループ単位に行う。業務プロセス＝業務グループとみなす。資産調査表はインプット情報、アウトプット情報、イン・アウトの無い情報に大別される。洗い出すのは情報コンテンツで、その保管形式（紙、メディア、サーバー）の区分なども入れる。コンテンツ単位で管理者も記載する。調査表と資産台帳は同じ書式。管理者が管理者として了承したら台帳になるようなもの。
ここでの課題は洗い出しの網羅性がどのように確保されているか。おそらく、網羅性の確保には特に拘っていないのだろう。初期段階では大枠で把握できれば充分と見る考え方もある。ただ、何れ手直しが前提とすれば、ＩＳＭＳのシステム構築が出来たとは言いがたい。
通常、台帳と言うものは目的の項目（キー情報）について、1件1葉または1件１行の形で整理されるものですが、トーマツではコンテンツ名がキー情報になります。資産は媒体によって管理の仕方が変わりますが、ここではお構いなし。物理的な実態に照らせば、資産の分類表に見えます。
資産台帳では資産の価値評価は行いません。規格が示す手順と整合しているか分かりません。
次に、
重要な資産については業務プロセスを更に細かく見てリスク評価を行いますが、どれが重要かは主要な情報として捕らえれば自明と言うことで、結局、部門業務プロセスをサブプロセスに落として、先ほどのインプット、アウトプットを並べなおすことになります。
サブプロセス毎に、①脅威、②脅威発生時の被害（資産価値に相当）、③現状の管理策、④脆弱性、⑤リスクレベル（①*②*③）、⑥追加の管理策などを評価していきます。
ここでの懸念は、サブプロセスの評価であって、資産が特定されていないこと、更に資産価値のＣＡＩの側面が曖昧なことです。ここも、規格の要求にあっているか分かりません。リスクが認識されても、どの資産のどの側面（ＣＩＡ）についてのリスクか判断が難しくなります。
この方式は、
当初、ざっくりと全体を把握するには利用できる方法論かもしれません。サブプロセス単位で見るので簡単に着手できるのがポイントでしょう。ベースライン方式による管理策の範囲では有用かもしれません。しかし、将来に渡って継続的に利用するのは適当とは思えません。詳細リスク分析には適していないように見えます。
従って、独断で言えば、更新審査のときもこの方式でリスク評価を実施していたら、既に失敗かもしれません。適材適所の発想が必要で、小学校に上がっても園児服を着ているわけには行かないのと同じことです。
.*.
先ず、
資産の洗い出しはプロセス毎に行う。通常は小さな業務グループ単位に行う。業務プロセス＝業務グループとみなす。資産調査表はインプット情報、アウトプット情報、イン・アウトの無い情報に大別される。洗い出すのは情報コンテンツで、その保管形式（紙、メディア、サーバー）の区分なども入れる。コンテンツ単位で管理者も記載する。調査表と資産台帳は同じ書式。管理者が管理者として了承したら台帳になるようなもの。
ここでの課題は洗い出しの網羅性がどのように確保されているか。おそらく、網羅性の確保には特に拘っていないのだろう。初期段階では大枠で把握できれば充分と見る考え方もある。ただ、何れ手直しが前提とすれば、ＩＳＭＳのシステム構築が出来たとは言いがたい。
通常、台帳と言うものは目的の項目（キー情報）について、1件1葉または1件１行の形で整理されるものですが、トーマツではコンテンツ名がキー情報になります。資産は媒体によって管理の仕方が変わりますが、ここではお構いなし。物理的な実態に照らせば、資産の分類表に見えます。
資産台帳では資産の価値評価は行いません。規格が示す手順と整合しているか分かりません。
次に、
重要な資産については業務プロセスを更に細かく見てリスク評価を行いますが、どれが重要かは主要な情報として捕らえれば自明と言うことで、結局、部門業務プロセスをサブプロセスに落として、先ほどのインプット、アウトプットを並べなおすことになります。
サブプロセス毎に、①脅威、②脅威発生時の被害（資産価値に相当）、③現状の管理策、④脆弱性、⑤リスクレベル（①*②*③）、⑥追加の管理策などを評価していきます。
ここでの懸念は、サブプロセスの評価であって、資産が特定されていないこと、更に資産価値のＣＡＩの側面が曖昧なことです。ここも、規格の要求にあっているか分かりません。リスクが認識されても、どの資産のどの側面（ＣＩＡ）についてのリスクか判断が難しくなります。
この方式は、
当初、ざっくりと全体を把握するには利用できる方法論かもしれません。サブプロセス単位で見るので簡単に着手できるのがポイントでしょう。ベースライン方式による管理策の範囲では有用かもしれません。しかし、将来に渡って継続的に利用するのは適当とは思えません。詳細リスク分析には適していないように見えます。
従って、独断で言えば、更新審査のときもこの方式でリスク評価を実施していたら、既に失敗かもしれません。適材適所の発想が必要で、小学校に上がっても園児服を着ているわけには行かないのと同じことです。
.*.
ワークフローマネジメントの裏づけの無い電子印の取り扱い
文書の電子化が当たり前になる。企業によっては電子化文書が「正」で、印刷したものは参考文書の扱いにしているところがある。経費節減、環境対策の中ではますます増えてきているでしょう。
赤いデート印が電子化文書にもあると何と無く承認された正式文書の安心感があるが、ワークフロー管理システムを利用して電子印がはめ込まれる場合は朱印と承認の関係が整合付けられるので良いが、中には朱印はただのイメージ図形で勝手にコピペが出来てしまうところもある。
承認の裏づけが無くても朱印イメージが勝手に添付できる運用が好ましい訳は無い。でも、朱印みたいな面倒はしないで単に名前と日付をテキストで記入して済ますケースもある訳だから、要はその文書の性格によって扱いを分けるべきだろう。
改ざんによるリスクが大きいもの。即ち完全性価値が大きいものは確実な承認プロセスを要求すべきだし、そうでなければ厳密性は要求しない。但し、トレーサビリティの確保だけは必要だろう。
.*.
ワークフローマネジメントの裏づけの無い電子印（朱印）を見つけたら、その文書の完全性価値がどのように評価されているか確認することです。もっとも、そのような場合は面倒な電信（朱印イメージ）の使用を止める方が懸命であることに疑いない。
.*.
文書の電子化が当たり前になる。企業によっては電子化文書が「正」で、印刷したものは参考文書の扱いにしているところがある。経費節減、環境対策の中ではますます増えてきているでしょう。
赤いデート印が電子化文書にもあると何と無く承認された正式文書の安心感があるが、ワークフロー管理システムを利用して電子印がはめ込まれる場合は朱印と承認の関係が整合付けられるので良いが、中には朱印はただのイメージ図形で勝手にコピペが出来てしまうところもある。
承認の裏づけが無くても朱印イメージが勝手に添付できる運用が好ましい訳は無い。でも、朱印みたいな面倒はしないで単に名前と日付をテキストで記入して済ますケースもある訳だから、要はその文書の性格によって扱いを分けるべきだろう。
改ざんによるリスクが大きいもの。即ち完全性価値が大きいものは確実な承認プロセスを要求すべきだし、そうでなければ厳密性は要求しない。但し、トレーサビリティの確保だけは必要だろう。
.*.
ワークフローマネジメントの裏づけの無い電子印（朱印）を見つけたら、その文書の完全性価値がどのように評価されているか確認することです。もっとも、そのような場合は面倒な電信（朱印イメージ）の使用を止める方が懸命であることに疑いない。
.*.
2011年12月01日
幼稚なパラドクス：資産細分化によるリスク縮小でリスクアセスを捻じ曲げる詭弁家に要注意！
分かりやすい例え話は「1千万円以上の発注は役員決済、それ以下は部長決済」とした場合、発注を全部1千万円以下に分割して全て部長決済で逃げ切る手法。この手法を盾にとって決済区分を決めても意味が無いと主張する詭弁をコンサルの中にも審査員の中にもいるのだから驚く。本旨を外してこの連中は一体何をやっているのかと疑う。今尚現役でやっているのだから注意あれ。
リスクを探す活動をリスクを隠す活動に摩り替えているので、問題が起きたらクライアントは自分で被害を被るしかないのです。特に某審査機関とそれに連携するコンサルには多いように思います。
.*.
幼稚なパラドクスを展開してリスクアセスメントを否定する輩が後を立たない。ISMS(ISO27000)はリスクアセスメントを基本したＰＤＣＡ型のマネジメント方法論であるにも関わらず、リスクアセスメントの理解が不十分なことを棚に上げて、方法論そのものを否定し始める。
ＩＳＭＳのセミナーなどに出ると最初にぶつかるのがリスクアセスメント。驚くのはＩＳＭＳ審査員の中にもリスクアセスメントを理解できていない人がいること。審査機関の傾向もありそうだ。やたらベースライン方式を薦める審査員は過剰な負荷を軽減するための手助けかと思ったら実は詳細リスクアセスメントを正しく理解していなかっただけと言うのも有るようだ。
.*.
資産価値×脅威の頻度×脆弱性＝リスク値
リスク値は上記の計算式で求めるが受容レベルを設定すること小さなリスクはそのまま受け入れる。
.*.
パラドクスはどのように展開するか。『脅威を細区分（細かく分解）することにより、発生頻度が小さくなり、もたらされるリスク値も小さくなる。結果、全てのリスクは受容される。』
例えば、震度7.00の自身発生頻度、震度7.01の発生頻度、震度7.02の発生頻度と細かく分けてリスク評価をやる分けだ。『どの地震に対しても対策不要が導かれるから、リスクアセスメントの方法論じたいに正当性は無い』と主張する。
火災を例にしても簡単に出来ます。火災の発生頻度を原因別でも現象別でも細かく見ていくとそれぞれの発生頻度は下がるから、いずれ全てのリスクが受容されることになると主張してきます。でも火災はある確率で発生している訳でどの組織もそれなりの対策を実施している。こういう矛盾を持つリスクアセスメントは意味が無いとやる訳です。
こういうパラドクスを弄ぶ詭弁家を時々見かけます。
リスクアセスメントが面倒なものだから、こういう詭弁で以ってリスクアセスメントを手抜きで済まそうとする。馬鹿なコンサルがいて悪乗りしているから始末が悪い。
.*.
さて、如何すればこの詭弁家は退散させられるか？
答えは超簡単。足し算するだけです。リスク値の本質は期待損失（普通は年間期待損失額）です。どのように分解しようとトータルの損失額が減る訳では有りません。トータルが受容できるレベルなら何もしなくて済みますが、実際は受容できないので分解作業を始めるのですが、この分解作業は詭弁のためでなく、施策を有効にするための優先領域を見つけるために行います。
情報資産、脅威、脆弱性をそれぞれどの程度粗くまたは細かく見るかは試行錯誤が必要だろう。キーとなる資産については「粒感」（つぶかん）と表現する人もいる。そのときにポイントとなるのは管理の視点になる。管理者と管理策である。管理者が変わる場合、または管理策が変わる場合は「粒」を変える。
地震なら、建築物の構造の領域は総務部門だろうし、設置された機器類の対策は当該部門となる。機器類の管理者は構造破壊の領域まで見る必要は無い。火災も原因によらず誰が何をするのかで見れば自ずとある塊にならざるを得ない。
.*.
詭弁は手抜きの方便でしかないのが残念。リスク低減のためにどのようにアプローチすべきか紳士に取り組んでもらいたいものだ。
.*.
分かりやすい例え話は「1千万円以上の発注は役員決済、それ以下は部長決済」とした場合、発注を全部1千万円以下に分割して全て部長決済で逃げ切る手法。この手法を盾にとって決済区分を決めても意味が無いと主張する詭弁をコンサルの中にも審査員の中にもいるのだから驚く。本旨を外してこの連中は一体何をやっているのかと疑う。今尚現役でやっているのだから注意あれ。
リスクを探す活動をリスクを隠す活動に摩り替えているので、問題が起きたらクライアントは自分で被害を被るしかないのです。特に某審査機関とそれに連携するコンサルには多いように思います。
.*.
幼稚なパラドクスを展開してリスクアセスメントを否定する輩が後を立たない。ISMS(ISO27000)はリスクアセスメントを基本したＰＤＣＡ型のマネジメント方法論であるにも関わらず、リスクアセスメントの理解が不十分なことを棚に上げて、方法論そのものを否定し始める。
ＩＳＭＳのセミナーなどに出ると最初にぶつかるのがリスクアセスメント。驚くのはＩＳＭＳ審査員の中にもリスクアセスメントを理解できていない人がいること。審査機関の傾向もありそうだ。やたらベースライン方式を薦める審査員は過剰な負荷を軽減するための手助けかと思ったら実は詳細リスクアセスメントを正しく理解していなかっただけと言うのも有るようだ。
.*.
資産価値×脅威の頻度×脆弱性＝リスク値
リスク値は上記の計算式で求めるが受容レベルを設定すること小さなリスクはそのまま受け入れる。
.*.
パラドクスはどのように展開するか。『脅威を細区分（細かく分解）することにより、発生頻度が小さくなり、もたらされるリスク値も小さくなる。結果、全てのリスクは受容される。』
例えば、震度7.00の自身発生頻度、震度7.01の発生頻度、震度7.02の発生頻度と細かく分けてリスク評価をやる分けだ。『どの地震に対しても対策不要が導かれるから、リスクアセスメントの方法論じたいに正当性は無い』と主張する。
火災を例にしても簡単に出来ます。火災の発生頻度を原因別でも現象別でも細かく見ていくとそれぞれの発生頻度は下がるから、いずれ全てのリスクが受容されることになると主張してきます。でも火災はある確率で発生している訳でどの組織もそれなりの対策を実施している。こういう矛盾を持つリスクアセスメントは意味が無いとやる訳です。
こういうパラドクスを弄ぶ詭弁家を時々見かけます。
リスクアセスメントが面倒なものだから、こういう詭弁で以ってリスクアセスメントを手抜きで済まそうとする。馬鹿なコンサルがいて悪乗りしているから始末が悪い。
.*.
さて、如何すればこの詭弁家は退散させられるか？
答えは超簡単。足し算するだけです。リスク値の本質は期待損失（普通は年間期待損失額）です。どのように分解しようとトータルの損失額が減る訳では有りません。トータルが受容できるレベルなら何もしなくて済みますが、実際は受容できないので分解作業を始めるのですが、この分解作業は詭弁のためでなく、施策を有効にするための優先領域を見つけるために行います。
情報資産、脅威、脆弱性をそれぞれどの程度粗くまたは細かく見るかは試行錯誤が必要だろう。キーとなる資産については「粒感」（つぶかん）と表現する人もいる。そのときにポイントとなるのは管理の視点になる。管理者と管理策である。管理者が変わる場合、または管理策が変わる場合は「粒」を変える。
地震なら、建築物の構造の領域は総務部門だろうし、設置された機器類の対策は当該部門となる。機器類の管理者は構造破壊の領域まで見る必要は無い。火災も原因によらず誰が何をするのかで見れば自ずとある塊にならざるを得ない。
.*.
詭弁は手抜きの方便でしかないのが残念。リスク低減のためにどのようにアプローチすべきか紳士に取り組んでもらいたいものだ。
.*.
識別しないという管理策の誤魔化し
情報資産の識別もしないで管理も何もあったものじゃない。電子化された情報（ソフトコピー）と紙のままの情報（ハードコピー）では扱いは変わる。
＜ハードコピー＞
資産名（必須）
管理責任者（必須）
保管期限（推奨）
機密区分（必須）
保管場所
使用開始
管理部門（必須）
いまだに、「機密文書のラベルを貼るとわざわざ悪意の侵入者に機密文書の所在を教えるようなものだから識別しない」と言う真面目馬鹿の存在していることに驚く。一体、どういうリスク分析をやっているのだろう。
部外者の持ち出しを容易としないためだけなら機密と書かないで色か形を変えたシールでも充分だが、そういう知恵もなさそうだ。
それよりも部外者がアクセスできるところに不用意に機密文書を放置させないことが重要。放置するのは社員だから、確実に社員に注意喚起できなければ意味が無い。リスクは社員の取り扱いにこそあることを認識すべきだ。機密文書が一般文書の中に混じって流出することも懸念すべきだろう。
識別しない管理策もクライアントの無理解だけなら希にあることだが、審査員の中にも同様の発想をしているのがいるから驚き以上だ。適用宣言書でA.7.2.2を採用しておいて、そのことを自分で否定するのを勧めているのだからクライアントも不幸なことだ。
コンサルは取り敢えず傍観するだけです。
.*.
「識別しない」管理策を採用する組織の共通点は単に整理整頓が苦手なだけということもあるようだ。５Ｓ活動が不十分な怠け者たちは、自分たちを正当化するために分けの分からない「識別しない」管理策を持ち出す。
馬鹿な審査員が上乗りする。始末が悪い。ＩＳＯの分野を問わずよくある光景。
.*.
情報資産の識別もしないで管理も何もあったものじゃない。電子化された情報（ソフトコピー）と紙のままの情報（ハードコピー）では扱いは変わる。
＜ハードコピー＞
資産名（必須）
管理責任者（必須）
保管期限（推奨）
機密区分（必須）
保管場所
使用開始
管理部門（必須）
いまだに、「機密文書のラベルを貼るとわざわざ悪意の侵入者に機密文書の所在を教えるようなものだから識別しない」と言う真面目馬鹿の存在していることに驚く。一体、どういうリスク分析をやっているのだろう。
部外者の持ち出しを容易としないためだけなら機密と書かないで色か形を変えたシールでも充分だが、そういう知恵もなさそうだ。
それよりも部外者がアクセスできるところに不用意に機密文書を放置させないことが重要。放置するのは社員だから、確実に社員に注意喚起できなければ意味が無い。リスクは社員の取り扱いにこそあることを認識すべきだ。機密文書が一般文書の中に混じって流出することも懸念すべきだろう。
識別しない管理策もクライアントの無理解だけなら希にあることだが、審査員の中にも同様の発想をしているのがいるから驚き以上だ。適用宣言書でA.7.2.2を採用しておいて、そのことを自分で否定するのを勧めているのだからクライアントも不幸なことだ。
コンサルは取り敢えず傍観するだけです。
.*.
「識別しない」管理策を採用する組織の共通点は単に整理整頓が苦手なだけということもあるようだ。５Ｓ活動が不十分な怠け者たちは、自分たちを正当化するために分けの分からない「識別しない」管理策を持ち出す。
馬鹿な審査員が上乗りする。始末が悪い。ＩＳＯの分野を問わずよくある光景。
.*.
2011年11月21日
Bring Your Own Device (BYOD)：私物持込許可
Bring Your Own Device (BYOD)：個人のデバイスを持ってきてください。私物持込許可のこと。
高 価格スマートフォン、スマートタブレットの普及で、会社は貸与に二の足を踏むし、個人は二重管理を避けたがるし、と言うことで、何らかの条件をつけて私物 利用の解禁に動く向きがあるらしい。スマートデバイスが人間の活動と一体感をもって利用される実態が浮かび上がってくる。人間の活動は公私なく連続してい るので、普段的に利用するデバイスを途中で切り替えるのは現実的でない。
セキュリティが保護される環境が実現できるなら、あるいは費用負担が明確に分離できるなら、企業は喜んでBYODを受け入れるだろう。
.*.
ソリトンシステムのDMEダイナミックモバイルエクスチェンジは専用アプレット内にセキュアな環境を実現するもの。データ類は暗号化される。DMEの環境からのみ会社のシステムに連携しメールなどが利用できるようにする。
MDM（Mobile Device Management）は以前からある概念で、リモートロック、リモートワイプ（消去）、アプリやデバイスの利用制限機能などが相当するが、ソリトンシステムは更にセキュアな環境の提供が必要と判断した。
ここでのデバイスは、スマホやタブレット端末が想定されている。ソリトンはiOSやAndroid対応アプリのものを提供しているようだ。
.*.
Bring Your Own Device (BYOD)：個人のデバイスを持ってきてください。私物持込許可のこと。
高 価格スマートフォン、スマートタブレットの普及で、会社は貸与に二の足を踏むし、個人は二重管理を避けたがるし、と言うことで、何らかの条件をつけて私物 利用の解禁に動く向きがあるらしい。スマートデバイスが人間の活動と一体感をもって利用される実態が浮かび上がってくる。人間の活動は公私なく連続してい るので、普段的に利用するデバイスを途中で切り替えるのは現実的でない。
セキュリティが保護される環境が実現できるなら、あるいは費用負担が明確に分離できるなら、企業は喜んでBYODを受け入れるだろう。
.*.
ソリトンシステムのDMEダイナミックモバイルエクスチェンジは専用アプレット内にセキュアな環境を実現するもの。データ類は暗号化される。DMEの環境からのみ会社のシステムに連携しメールなどが利用できるようにする。
MDM（Mobile Device Management）は以前からある概念で、リモートロック、リモートワイプ（消去）、アプリやデバイスの利用制限機能などが相当するが、ソリトンシステムは更にセキュアな環境の提供が必要と判断した。
ここでのデバイスは、スマホやタブレット端末が想定されている。ソリトンはiOSやAndroid対応アプリのものを提供しているようだ。
.*.
2011年11月20日
出張グッズ
コンサルでも審査員に同行して出張するケースがあるらしい。事務局員とかISMS推進員の同行なら普通だけど、コンサルで同行ってどうなんでしょう。拙くないのかなと思いつつもクライアントの希望に沿うのは最優先？ということで、審査員とコンサルとの同行劇が始まる。
一箇所のホテルに落ち着いて何泊もするのは同行と言うより、本社が遠地で審査に立ち会う都合で一緒になるだけ。各サイトを回るのは文字通り同行する形になる。この場合はホテルに1拍以上することはない。落ち着かない出張。トータルの泊数は多いから荷物も多くなるのに毎日移動なので移動自体が結構大変だそうです。
ISMSに付き合うと出張家業になります。事務局の人も内部監査とか教育とかで各サイトへの出張がどうしても多くなります。
結果的に、出張グッズにもそれぞれ工夫があるようです。
.*.
コンサルでも審査員に同行して出張するケースがあるらしい。事務局員とかISMS推進員の同行なら普通だけど、コンサルで同行ってどうなんでしょう。拙くないのかなと思いつつもクライアントの希望に沿うのは最優先？ということで、審査員とコンサルとの同行劇が始まる。
一箇所のホテルに落ち着いて何泊もするのは同行と言うより、本社が遠地で審査に立ち会う都合で一緒になるだけ。各サイトを回るのは文字通り同行する形になる。この場合はホテルに1拍以上することはない。落ち着かない出張。トータルの泊数は多いから荷物も多くなるのに毎日移動なので移動自体が結構大変だそうです。
ISMSに付き合うと出張家業になります。事務局の人も内部監査とか教育とかで各サイトへの出張がどうしても多くなります。
結果的に、出張グッズにもそれぞれ工夫があるようです。
.*.
北海道・沖縄へ行きたい審査員
本社が東京・大阪でも出先サイト（支店・工場・センター）は地方、中には北海道や沖縄に置く例もある。通常、主任審査員は本社で経営者・事務局・内部監査責任者を相手に全体の審査を行い、各審査員は各出先をカバーする。これが基本。
ところが、主任審査員が自ら飛び歩く例がある。自分の価値観、興味本位、自己本位で動く審査員だろう。地方で、クライアントと飲食を共にする審査員まで居る。土産までもらう審査員も居ると聞く。発覚して懲罰を受けた話も聞く。
主任審査員（リーダー）が本社でもないサイトの沖縄・北海道へ出かけたら、きっと何か怪しいと思って間違えない。理由付けがあっても「李下に冠を正さず」です。止めた方が良い。遠方は交通機関の問題でスケジュール変更を余儀なくされるリスクも持っているわけで、そういうリスクを考慮しない主任は鼻から主任の資格なし。と言う意見も聞きます。
.*.
観光地は雰囲気も変わって出かけたい気持ちは理解できますが、公私混同はやはり避けるべきでしょう。
.*.
本社が東京・大阪でも出先サイト（支店・工場・センター）は地方、中には北海道や沖縄に置く例もある。通常、主任審査員は本社で経営者・事務局・内部監査責任者を相手に全体の審査を行い、各審査員は各出先をカバーする。これが基本。
ところが、主任審査員が自ら飛び歩く例がある。自分の価値観、興味本位、自己本位で動く審査員だろう。地方で、クライアントと飲食を共にする審査員まで居る。土産までもらう審査員も居ると聞く。発覚して懲罰を受けた話も聞く。
主任審査員（リーダー）が本社でもないサイトの沖縄・北海道へ出かけたら、きっと何か怪しいと思って間違えない。理由付けがあっても「李下に冠を正さず」です。止めた方が良い。遠方は交通機関の問題でスケジュール変更を余儀なくされるリスクも持っているわけで、そういうリスクを考慮しない主任は鼻から主任の資格なし。と言う意見も聞きます。
.*.
観光地は雰囲気も変わって出かけたい気持ちは理解できますが、公私混同はやはり避けるべきでしょう。
.*.
