ＩＳＭＳの失敗事例：ツール依存

ＩＳＭＳの失敗事例：ツール依存

リスクアセスメントツールを利用すると、殆どの場合失敗します。ツールの利用がもたらすものはリスク痴呆人を生み出すだすことで、適切なリスク評価できる訳ではありません。リスクアセスメントは関数電卓をたたいて解を求める行為とは全く違います。リスクアセスメントは学習プロセスと言う理解が必要です。その辺まで考慮した支援ツールが出てくれば少しは話は変わりますが、現在のところでは先ず見当たりません。

コンサルもツールを勧めるケースは少ない。時間がないとかを理由に、ノーマルなアプローチを投げ出すときはツールで済ますのかもしれません。

事務局一括でのリスク評価のときはツール利用の誘惑が誰しも頭を過ぎります。事務局でやるだけで既に失敗ですから、仮にツールを使っても全体への影響は有りません。既に泥沼の中ですから。

/

ＩＳＭＳの失敗事例：事務局独走

ＩＳＭＳの失敗事例：事務局独走


現象として分かり易い失敗事例は、数人の事務局で殆ど一切の作業をやっているケース。


資産の洗い出しから、資産価値評価、リスク分析評価まで事務局でやっている場合は、単にそのことだけで既に失敗と言える。資産は各部門で出して、その後は事務局とか、リスク分析評価だけ事務局と言う例も多いが、ことごとく失敗。


資産の所有者あるいは管理責任者が資産のリスクを理解しない状況では、リスクを理解する活動がスキップされてしまい、リスクを軽減する活動は適切に行えないことが殆どです。加えて、事務局が適切に価値評価・リスク分析評価を出来ることは先ず有り得ない。


ご都合で御造りのリスクアセスメントだけが出来上がりますが、全く意味がありません。


.*.


手間を掛けず簡単に出来るので、こういうやり方を勧めるコンサルも居ます。ベースライン方式？の一環で規格不適合ではないとのことです。知識習得に時間が掛かるので当初はベースライン方式でやって、徐々により適切なやり方に移行していくと説明します。


これは殆どの場合、大嘘です。一旦定着させたものを引き剥がしながら、徐々にやる方が遥かに大変だし、コンサルは手間ばかりで旨みが無いと思えばすっと消えていきます。付き合ってくれても、若いコンサルに引き継いでしまいます。


事務局も、新たな苦労は避けたいから、意味の無い御造りのままにしていずれ誰かにバトンタッチしていきます。後任の事務局はもう何が問題かすら理解することは有りません。結局、失敗の泥沼から抜け出ることは出来ません。


例外は、トップが裸の王様でない場合は、愚かな実態に気づいてやり直しの号令を掛けることで泥沼からの脱出が出来ます。


.*.

ＩＳＭＳの失敗事例：ＩＳＭＳの独立運用

ＩＳＭＳの失敗事例：ＩＳＭＳの独立運用

関西某企業はＩＳＭＳを始めるに当たってセキュリティは品質と同じ仕事を進めるときの基本要件と言い切った。これは大変重要なことで当企業の見識の高さが伺える。品質の作りこみは全社を上げてプロセスの上流から下流まで一つの例外もなしに徹底する。セキュリティの作りこみも同様に取り組むことが必要。

セキュリティ活動を専門性は異なるものの、広い意味で品質活動の一環とするところは少なくない。そういう位置づけが示される場合は失敗は少ない。品質活動自身がおろそかで、マネジメントシステムを考えるのはＩＳＭＳが始めてという場合は、失敗するチャンスが増える。

全ての部門の本来業務の中にセキュリティ関連の項目が自然と入ることが大切です。

例えば、部門とか担当とかの業務マニュアルを作成するときに、セキュリティを達成する活動も明確にされていることですが、それが無いと危ない。全社共通の規定とかガイドラインはあっても、部門の業務プロセスに展開されていなければ、まだ仕事は半分で終わっていることになる。

.*.


仕事(本来業務）とＩＳＭＳが2本立ての場合はほぼ失敗です。

.*.

ＩＳＭＳの失敗事例についての独善的考察？

ＩＳＭＳの失敗事例についての独善的考察？

そもそも失敗とは何か？


失敗とは目論見を達成できないこと。では、どんな目論見があるのか？

《認証取得の目論見》

1. 既存の取引先の要求だから”兎に角”認証取得すること。取引継続のためには最優先だ。
2. 今後の営業活動に有用だから、取引要件だから、やはり”兎に角”認証取得すること。上記と同じだね。
3. セキュリティ事故を起こして企業ブランドを落としたくない。仮にその場合も社会への説明責任を果たしたい。
4. セキュリティを企業体質に取り込んでさらに強い会社にしたい。体面のためでなく、方法論として有益そうだから認証を取得する。不足を感じたら更に有益な方法論を取り込みたい。

《失敗とは？》

1. 目論見が達成できない。1～3の場合は取り敢えず認証が取得され維持されていれば良い。しかし、４の場合は内容が問題になる。
2. コストが過剰。情報化投資は事業規模の数％から事業特性によっては20%前後まで行くから、セキュリティ投資のその内数に収めたい。情報化投資の枠組みの見直しは必要。
3. 事業をスポイルする場合。事業とセキュリティマネジメントのシナジーが得られないだけでなく事業遂行に問題を起こし本末転倒となるケース。

.*.