ISO27001 VS. ISO20000 VS. J-SOX LAW

 

(複数の規格を受け入れる時の文書の棚卸し方法:此れまでの検討結果を踏まえた考察)

 

4つの表を作る。

 

1.         27001 vs. 20000, COBIT

2.         20000 vs. 27001, COBIT

3.         COBIT vs. 27001, 20000

4.         Document vs. 27001, 20000, COBIT

 

      この4つの表は概念的なもの。文書間で共通化可能な箇所は工夫すること。(エクセル/アクセス利用)

      ISO9001についてはベンチマーキングの観点で付記しても良い。無くても良い。

      @〜Bの規格に対応する文書事例は理解促進のため。網羅的である必要はない。

      Cはボリューム的には全ての文書を洗い出して作成する「Document vs. 27001, 20000, COBIT」がもっとも大きなものになる。此れは日常的な管理運用文書あるいはそれと連携する文書となる。その他は啓蒙的な利用となり年1回見直す程度の運用管理となる。

 

ISMS軸の規格対応(WANT

ISO27001

ISO20000

JSOXCOBIT

ISO9001

事例文書・備考

 

 

 

 

 

 

 

 

 

 

 

IT-SM軸の規格対応(WANT

ISO20000

ISO27001

JSOXCOBIT

ISO9001

事例文書・備考

 

 

 

 

 

 

 

 

 

 

 

JSOX軸の規格対応(WANT

JSOX(COBIT)

ISO27001

ISO20000

ISO9001

事例文書・備考

 

 

 

 

 

 

 

 

 

 

 

■文書類軸の規格対応(MUST

文書名

内容

主管

用途

形式

保管

ISMS

ITSM

JSOX

QMS

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

◆ ISO27001 VS. ISO20000 VS. J-SOX LAW

 

複数のマネジメント規格、あるいは関連する法規制が存在するため、それらへの対応は文書化の観点からすると相当部分で重複する。統合的な対応を図るには、「規格に沿って参照するだけの体系」と「文書実体を収めた体系」のに階層構造が有効である。

 

ITの活用は参照するだけの仮想的な文書体系とコンテンツ実体を収めた文書体系を矛盾無くスムーズに接続し、トータルな文書管理を実現することが期待される。

 

相互に関連の薄い管理体系では従来どおりそれぞれ固有に作成しても問題は無いが、将来を見据え、電子ファイル上の扱いは当初から参照文書体系に基づいて構築することを進める。この有効性は、文書体系を構築していく時の作文分業においても有効である。既存文書のモジュラー化、不足分の新規作成、全体に糸を通す参照文書体系をそれぞれ分担して進めることが出来る。

 

欠点は、レビュー、見直しにおいて全体の要求とのバランスを常に求められること。特定機能の要求に基づいて簡単に修正は出来なくなる。

 

 

参照文書体系においても、何かをテンプレートして設定しておくことは、その後の追加作業においてもマップを示すことになるため、有益である。マネジメントシステムとして最も歴史の長いISO9000をテンプレートにすることが極めて常識的な発想で問題は無い。ただし、大半が情報システムに関わる問題に特定されている場合は、ISO90000を雛形に策定されたISO27001も有効である。ここでは、ISO27001をベースに規格要求の相関性を確認する。

 

1.         ISO27001規格要求事項
なお、ISO17799:2005は詳細管理策でカバーする。

2.         ISO20000規格要求事項

3.         JSOX法要求事項(ある程度解釈を入れる必要は出る)

4.         ISO9000規格要求事項(品質、環境、食品、等に続くマネジメントシステムを比較する場合に9000を抑えることは有効)

5.         事例文書

 

規格項番に沿って全点チェックするのは相当の作業量。でもココをクリアしておかないと絵に描いたもちになってしまう。オフサイト・コラボレーションが必要。

 

 

 

 

◆ 異なるマネジメントシステム間の文書共有について

 

l          マネジメントシステムの構造の類似性:
その程度は規格等から判断可能。しかし、類似性を理解することは、規格要求を正しく把握する上では役に立つ。組織として矛盾の無い複数のマネジメントシステムを回すことが可能になる。
→ 組織として相関表、相関概念図ぐらい用意してあっても良い。(規格に習熟している限り図表は必須ではない)

l          コンテンツの共有:
手順書・規定・標準等現場の生きた文書類は組織の発展過程で次々に作成されてきているので、またそれぞれの目的に特化して作成されているのでそのまま共有化できる可能性は小さい。
→ 実効性を考慮した文書共有化プロセス構築:
文書見直しの手順の中で、文書の更新時には類似文書の存在をチェックさせオーナー間の合意が得られれば共有化を進めることを推奨する。共有化できない理由を明確にし、其れが解消したら共有化を進める。逆もありうる。文書オーナーが複数設定可能にし、途中で共有が無理になったらオーナーから外す。など。

 

<逆引き文書体系を作った方が早いかな?>

 

・適切なサイズに纏められた具体的な手順が記載された文書(モジュラールール)をリストし、それぞれ何から参照されるかを記載し、最終的にどのマネジメントシステムを構成しているか分かるもの。これを先に作った方が実践的かも。なぜなら程度の差はあれ何らかの形でマネジメントは行われ、その為の文書化は行われている。

ISO9000でも既存文書の棚卸しをやったが、トップダウン型で纏め上げてしまったので、他のマネジメントシステムに転用するのは工夫が必要だった。であれば最初からモジュールという前提で管理しても良い。

・最初からモジュール化というのはきれいごと。全ての業務は途中から受け継いで始まるものです。仕組みの中で共有化が促進されるように努めることが必要。

 

◆ 具体的に用意する文書と記録

 

1.         文書名:一般的なもの。内容が異なる場合はIDを変えること。

2.         コンテンツ:記載内容概略

3.         主管:作成部署・オーナー部署(複数の可能性、追加削除の可能性に配慮すること)

4.         用途:プロセス/発行頻度

5.         形式:ワード/エクセル/ボリューム等

6.         保管:場所/電子/

7.         例:サンプル(文書/記録)の有無

8.         参照文書体系(ISO27001[]/ISO20000[]/JSOX[]/etc)←逆引き用に規格項番を明示する。

 

l          文書一覧サンプル

#

文書名

内容

主管

用途

形式

保管

ISMS

ITSM

JSOX

 

ISMS文書管理台帳

ISMS構築に関わる文書一覧

ISMS事務局

 

 

 

 

 

 

 

情報資産台帳

情報資産の全て

各部署

 

 

 

 

 

 

・実際は別ファイルにすること。

ISMS関連文書は別項にて整理済み。ITMS(ITサービスマネジメント)及びJSOXについては未整理。どの項番がどの文書を要求しているか、JSOXは推定で纏めること。