情報資産台帳の要件

情報資産台帳の要件

（１）当該情報にアクセスするための情報が網羅されていること。台帳から現物が辿れること。更に言うなら、当該資産に辿り着けなくてはいけない。

（２）当該情報の管理レベルが明確なこと。機密性要件、可用性（アクセス時間）要件、完全性要件。

これまで完全性要件の議論はあまりやっていなかった。完全性維持の一環としてのバックアップのレベル。「正」情報と同一であることを維持する施策のレベル。「正」情報を利用していることの確証を示す施策レベル。

.*.

（３）維持要件

これが大事。審査の時に大慌てで作ったものは役に立たない。保守性保全性に優れた台帳であること。

*

誰でも何時でも何処からでも必要な時に権限に応じてアクセスできること。そのためには台帳はクラウドに置くのが今時の常識。

最新状態を維持するには。

組織が大きい場合は資産オーナーが台帳の管理者に通知して行う。追加も削除も変更も。 小規模組織では一人でやるのでこの辺の手順は不要だ。

結局問題は棚卸を定期的に又はイベントドリブン/オンデマンドに実施すること。この地味な仕事は誰も嫌がる。普通は、定期的（月1回？半期に1回？年1回？）は担当を決めるが、日常の業務遂行の中で発生するメンテナンスは各業務の担当者（情報資産オーナー）にやらせるのが適当。

*

＜資産台帳の構造＞

資産台帳は普通の資産台帳と情報管理の観点から束ねる情報資産台帳の二重構造になる。

資産台帳は業務の数だけ存在すると思って良いだろう。体裁も業務ごとに特徴あるものになって構わない。但し、文書記録管理規定に沿って一定の要件を果たすのは当然。

情報資産台帳は全ての資産台帳を網羅していなければいけない。しhン台帳は全ての資産を網羅していなければいけない。

情報資産か只の資産か判然としない時もあるがそれは問題にはならない。確実に紐づけが出来れば十分。例えば何かの記念のハードコピーとかブックなどは情報資産なら同じものを入手できれば十分だから資産価値も低くなるが、特別な記念品として捉えると代替手段がないから大事に管理する必要が出てくる。

先ず、

上位に台帳リスト/資産台帳一覧を置く。 その下にそれぞれの台帳を置く。業務によっては更に階層構造を持たせても構わない。階層を深くすると使い勝手が悪くなる（一覧性を喪失させる）のでいい加減に押することだ。

「資産台帳一覧」

電子ファイル名。電子化されない情報は存在しない。実際の管理は電子ファイルの管理になる。電子ファイルを「正」とする。

**

嗚呼、勘違いの情報資産台帳

嗚呼、勘違いの情報資産台帳

情報資産台帳を単純に考えれば情報資産だけをリストにしたものになります。

ですから、多くの組織では情報資産を前提に洗い出しを始めます。ところが状況によっては単純には行きません。作業はもっと深くなる。情報資産の１つである「資産台帳」自身が作成されていないことが多いからです。

情報資産に特定しないで、組織の管理対象となる資産は何か洗う作業が必要になります。組織の資産の一部が情報資産です。組織の人・物・金を束ねるのが情報と見ておいてもいいでしょう。組織として既にＱＭＳとかＥＭＳとかで体系的な資産の洗い出しが済んでいれば、ＩＳＭＳの作業は単純になります。

ところがマネジメントシステムに始めて取り組む場合は、組織の管理対象全体をしっかり把握してやることが大事です。ＩＳＭＳ以前の問題（やること）が転がっています。日ごろの管理の穴を埋めるところから作業は始まります。日常管理をしっかりやっているところと手抜きのところが同じレベルでＩＳＭＳを始められるわけが有りません。

.*.

もっとも、手間を惜しむコンサルはそういうことを要求しません。今ある奴だけをリストすればいいと言うでしょう。彼らは、体裁だけクリアすれば認証が得られることを知っているからです。体裁だけの、箱ポンの管理では有効性は期待できませんが、経験を積んだコンサルは手を広げた時の泥沼も知っています。ですから、クライアントの取り組みレベルを見て妥当と思われるところで線引きをせざるを得ない事情もありますので、一部であってもコンサルを頭から非難することは適切では有りません。

.*.

（追記）

資産台帳とは関係ない話。安きに流れると馬鹿コンサルを掴み、馬鹿審査機関の餌食になる。本当に必要な改善はスルーされて時代から取り残される。セキュリティ事故が起きるまで放置される。その間散々貪られる。事故が起きても他のパートナーと組み勇気が示されなければ馬鹿の地獄と付き合い続けることになる。

馬鹿コンサルを思い出した。ヤクザ同然のコンサル。自分のコンサル内容の化けの皮を剥がされそうになったら急に審査に割り込んでくる。会場からたたき出すべきだった。当時はドリームとか佐藤とかの名前だったか。

馬鹿コンサルを許すのは馬鹿審査機関。

背に腹は代えられないとうそぶ居直る審査機関には馬鹿コンサルも仕事を持ってくる協力者。癒着構造が極端な審査機関の認証には何の価値もない。それどころか社会に勘違いさせる悪徳審査機関。

その代表的なところは外資（英国）系の審査機関。英国本国の審査機関は健全な発想でやっているので大丈夫だが、問題は日本法人。完全に歪んでいる。

*

東芝の話題は収まったかな。ここは審査機関を変えた。厳しい審査に耐えられないからイージーな対応で済ませられるところに乗り換え。日常管理をいい加減にして事故が起きたら必死に対応する腹だったのだろうか。しかし、そんな精神構造の集合体では今回の事件は対応不可の状態。

経営者をヨイショするだけの英国系日本法人の審査と経営者に真の改善を迫る正しい審査の違いが導いた結果の違いが目の前にニュースになっているようだ。

*

Why Not? 情報資産の洗い出し

Why Not? 情報資産の洗い出し

この基本的なことが出来ていない。抜け漏ればかり。何が資産か把握できていなければISMSの後工程は全く無意味になります。コンサルに行っても疲れるだけです。どうして普通に出来ないのでしょう？　


＜洗い出しの抜け洩れの例？＞

1. 静的に保管しているものだけが洗い出される。キャビネットの中だけをリストにしている。
2. 個人管理の資料は洗い出しの対象から外す。デスクの袖のキャビネットが外れる。会社のあるいは業務の情報資産で溢れかえっているのに、不思議なことだ。
3. サーバー内の情報は情報システム担当が管理しているから部門の情報資産から外す。おいおい情シ部は器の管理しかしていないよ。彼らは中身には関与しません。
4. 発送する予定の情報類。一時的に入り口にあるが郵便やとか宅配やが来て回収するからリストに入れないよ。
5. 今日中にお客さんとか営業とか管理部門に届ける資料も同じだ。
6. メディア類。USBメモリー、CD/DVD、テープ類などは、中身が空っぽもあれば、ゴミ情報もあれば、重要情報もあれば、と不確定的ですから始末が悪い。コンテンツを識別して、メディア自体は対象から外す。
7. 共有資料というけど、管理責任者不明の資料。倉庫の隅に積み上げられている。キャビネットの一角に門外不出のように置かれている。時には通路の脇に何年も置きっぱなし。
8. 持ち主不明の資料。部門が解散・分離したときに誰も持っていかなかったもの。部門ミッションが変わって宙に浮いてしまった資料。
9. 前任者から引き継いだけど、内容を理解できていないもの。業務上の資料としての意味が無く、誰かに何かを聞かれた時に困らないように捨てないでいるだけの資料。
10. 資産リストとか資産台帳とかの名前は付けているが単なる分類表・区分表・カテゴリー一覧に過ぎないもので済ませるケース。分類・区分が思いつかないものは全て「その他」区分で済ませる。

.*.

＜業務フロー/業務プロセスに沿った洗い出し＞

業務フロー/業務プロセスを書き出してみる。手順に沿ったフローチャートが出来上がる。

各処理のところで、参照する情報、出力する情報を書き出す。情報の内容・情報の所在、入力または出力の方法も記載する。

単純な作業に思えてなかなか面倒。

先ず、何の障害もなくスムーズにことが運んだ時の基本形。次に、例外のフローを書き加える。例外が夥しいほっど多い。人によってやり方が変わる。

問題は、基本の流れでは業務標準が出来ているが、細かい部分は実に何も決まっていないことに気づく。そういうものらしいです。資産の洗い出し（たな卸し）が、業務標準細則の策定作業に変わるのです。今までいい加減にやってきたことですからしようがありません。

もっとも、洗い出し自体は、複数のやり方が並存しても出来るので、先行して進めても問題はありません。無駄をなくすために、後で、何を標準とするか決めれば済むことです。

.*.

＜洗い出されなかった情報資産の特定＞

必要な情報が洗い出されると同時に、どの業務でも参照されない資産が存在するかどうか。プロセスの合理化を進めると中間生成物のような情報は最後には不要とされるケースが多い。自分たちの管理スペースに存在する情報資産で業務プロセスからの引用が全く無かったものを識別し、一定の見極め期間を置いて廃棄する手順が必要になります。

この場合は、静的な情報資産の洗い出しはやはり必要となる。

業務プロセスIDと情報資産IDがあると想定して、プロセスIDから資産IDを引き当て、また資産IDからプロセスIDを引き当てることが出来る。しかし、机上論の展開はできるが、現実にどの程度可能かは一概に言えないでしょう。意味がある範囲において、意味のあるサイズ（かたまり）に対して、プロセス・情報資産ともやればいいということらしい。軌道修正しながら進めるのが現実的なアプローチでしょう。

.*.