◇ ISO20000情報技術サービスマネジメント

 

- サービスプロバイダーに対する要求事項を規定 -

ISO27001ISO20000を満たす場合はブルー、満たさない(あるいは注意を要する)場合はレッドで記載しています。

 

ISO20000情報技術-サービスマネジメント-第1部:仕様

ISO27001

JSOXCOBIT

対象(適用範囲)

1 適用範囲

ITサービスプロバイダ(社内及び社外)

事例

a)入札対象のサービス事業

b)サプライチェン内サービスプロバイダへの一貫したアプローチ要求

c)自らのITサービスマネジメントのベンチマーキング実施

d)独立したアセスメント基準

e)顧客サービス提供能力の実証

f)サービス改善

 

情報資産を有する全ての組織

 

 

 

プロセス

サービスデリバリプロセス

コントロールプロセス

リリースプロセス

解決プロセス

関係プロセス

@

A

B

C

 

4.2.1a)適用範囲のプロセスの全て

*規格としてプロセスを特定していない。

 

 

2 用語及び定義

-

 

 

3 マネジメントシステム要求事項

達成目標:マネジメントシステムを提供する。

 

 

経営陣の責任

3.1 経営陣の責任

5 経営陣の責任

 

 

a)サービスマネジメントの方針、目標及び計画を確立する。

 

5.1 経営陣のコミットメント

a)ISMS基本方針を確立する

b)ISMSの目的が設定され、計画が策定されることを確実にする。

 

 

b)目標達成の重要性、継続的改善の必要性を周知する。

5.1

d)ほぼ同内容。

 

 

c)顧客要求事項が決定されること、及び顧客満足を改善するという狙いが満たされることを確実にする。

4.2.1c)事業場の情報セキュリティ要求事項を・・特定する等に内容的には含まれる。

*顧客要求、顧客満足を特定した要求としていない。

 

 

d)全サービスの調整及びマネジメントに責任を持つ者を、経営陣の中から一人指名する。

N/A

*このような具体的な記載はない。経営者は部門長のケース、また経営陣として複数のケースあり。

 

 

e)サービスデリバリ及びサービスマネジメントを計画、導入、監視、レビュー及び改善するためのリソースを決定し、(例えば、適切なスタッフを採用する、スタッフの移動を管理するなどして)提供する。

5.2 経営資源の運用管理

5.2.1 経営資源の提供

 

 

f)サービスマネジメントの組織及びサービスに対するリスクを管理する。

4.2.1c) リスクアセスメントとして包括的な管理を行う。

*組織及びサービスに対するリスク管理として切り出されている訳ではない。

 

 

g)サービスマネジメントが引き続き適切で、妥当で、かつ有効であることを確実にするため、予め定められた間隔でサービスマネジメントをレビューする。

 

7 ISMSのマネジメントレビュー

7.1 一般

 

文書化要求

3.2 文書化に関する要求事項

サービスプロバイダは、サービスマネジメントの効果的な計画、運用及びコントロールを確実にするために、文書及びレコードを提供すること。これには次を含めること

4.3 文書化に関する要求事項

4.3.1 一般

*文書管理は行うが、「提供する」という観点ではない。

 

 

a)文書化したサービスマネジメントの方針及び計画

 

a)ISMS基本方針及び目的の表明

 

 

b)文書化したサービスレベルアグリーメント

 

c)当該ISMSを支える手順及び管理策

*SLAを特定して規格要求としていない。

 

 

c)この規格が要求する、文書化したプロセス及び手順。

 

c)当該ISMSを支える手順及び管理策

*プロセスの文書化を特定していない。

 

 

 

d) この規格が要求するレコード。

h)この規格が要求する記録。

 

 

3.3 力量、認識及び教育・訓練

@サービスマネジメントの役割及び責任はすべて、その役割及び責任を効果的に果たすために必要な力量と合わせて定義し、維持すること。

 

5.1c)情報セキュリティに対する役割及び責任を定める。

5.2.2 教育・訓練、認識及び力量

 

 

Aスタッフの力量及び訓練の必要性は、スタッフ自らの役割を効果的に果たすことが出来るようにするために、レビューし、管理すること。

 

5.2.2c)有効性評価

 

 

B経営陣は、従業員が自らの活動の持つ意味と重要性を認識し、サービスマネジメントの目標の達成に向けて自らどのように貢献できるかを認識することを、確実にすること。

 

5.2.2 解説文(下)

 

 

4 サービスマネジメントの計画及び導入

a)Plan

b)Do

c)Check

d)Action

0.2 プロセスアプローチ

*ISMS全体のPDCA

JQACセミナーでは大きいサイクルのPDCAと小さいサイクルのPDCAと二通りあることの理解を求めていた)

N/A

*ISO27001では個別の資産(例:サービス資産)に対するリスクアセスメント、リスク対応計画により、詳細管理策133項目等を導入し適正化を図る。

*ISO20000PDCA各詳細項目とISO27001詳細管理策の対応付けは可能と思われる。

*ISO20000管理項目から直接ISO27001133項目を参照しないものは133項目の管理策から更に参照する内容として具体化する。ISO20000は規格要求であり厳しい。

*結論:管理レベルの枠組みが両者では異なるが、サービス資産管理はISO20000要求をクリアする必要有。個別のサービス資産管理標準はISO20000の枠組みの方が分かり易い。

<文書体系としては、(案1)全体の管理フレームはISMSベース、サービス資産管理フレームは20000ベースにする。(案2)枠組みは二通り作成して、それぞれから共通の個別コンテンツを参照する形も有望>

 

 

4.1 サービスマネジメントの計画(Plan

達成目標:サービスマネジメントの導入及び提供を計画する。

a)適用範囲

b)達成目標及び要求事項

c)実行プロセス

d)管理の役割及び責任についての枠組み。

e)プロセス間インターフェースと活動調整方法。

f)課題及びリスクを特定し、アセスメントを実施し、管理するために採用すべきアプローチ。

g)サービスを生み出し又は修正するプロジェクトに対するインターフェースを取るためのアプローチ。(?意味不明)

h)必要なリソース、設備及び予算。

i)プロセスを支援するためのツール。

j)サービス品質を管理、監査及び改善する方法。

 

 

 

 

4.2 サービスマネジメントの導入及びサービスの提供(Do

達成目標:

a) 資金及び予算の割り当て。

b)役割及び責任の割り当て。

c) 方針、計画、手順及び定義の文書化。

d)リスクの特定及び管理。

e) チームの管理。(要員計画など長期的)

f)設備及び予算の管理。

g)サービスデスク及び運用を含む(個々の)チーム管理

h)進捗状況の報告。

i) サービスマネジメントプロセスの調整。

 

同上

 

 

 

 

4.3 監視、測定及びレビュー(Check

達成目標:目標及び計画が実現されていることを監視、測定及びレビューする。

@チェックのためのメソッドが明確で適切であること。

A経営陣による定期的なレビュー。

a) 計画に沿っていて、規格要求に適合していること。

b)有効に実施され維持されていること。

B適切に監査すること。

C監査・レビューの記録・伝達。

 

同上

 

 

 

 

4.4 継続的改善(Act

達成目標:サービスデリバリ及びサービスマネジメントの有効性及び効率性を改善する。

 

 

同上

 

 

4.4.1 方針

サービス改善について公開された方針を持つこと。サービス改善の役割及び責任を定義すること。

 

-4.2.1b)ISMS方針

 

 

4.4.2 改善のマネジメント

@サービス改善計画

A改善活動管理プロセス

a) 個々のプロセスに対する改善。

b)組織全体または複数のプロセスにわたる改善。

 

-4.2.2b)リスク対応計画

 

 

4.4.3 活動

a) データを収集・分析する。

b) 改善点を特定し、計画し、実施する。

c) 関係者全員と協議。

d)品質、コスト及びリソース活用を改善するための目標値の設定。

e) 改善について関連するインプットを検討。

f)サービス改善を測定し、報告し、周知する。

g)方針、プロセス、手順及び計画の改正。

h)意図された目標が達成されることを確実にする。

 

-4.2.3ISMSの監視及び見直し

-4.2.4ISMSの維持及び改善

 

 

5 新規サービス又はサービス変更の計画及び導入

達成目標:新規サービス及びサービスへの変更が、合意されたコスト及びサービス品質で提供可能であり、かつ、管理可能であることを確実にする。

@変更提案は、コスト上、組織上、技術上、及び営業上のインパクトを考慮したもの。

Aサービスのクローズを含む、新規サービスまたはサービス変更の導入について計画し、正式な変更管理を通して、此れを認可すること。

Bこの計画及び導入には適切な資金調達及びリソースを含めること。

計画には以下を含むこと

a)役割及び責任

b)変更内容

c)関係者へのコミュニケーション

d)新たな契約及び合意、または契約及び合意の変更

e)人的資源及び人員採用の要求事項

f)技及びトレーニングに対する要求事項

g)プロセス、指標、手法及びツール

h)予算及び期間

i)サービス受け入れ基準

j)期待される結果

Cサービスプロバイダの承諾

D結果の報告

 

※発想の軸がずれる(困った):

27001の変更管理は情報資産を扱うシステムの開発または運用に関する変更管理についての要求。

 

20000はサービスと言う資産そのものの新たな導入または変更についての要求。

 

-A.10.1.2変更管理

-A.10.3.2システムの受け入れ

-A.12.5.1変更管理手順

 

 

6 サービスデリバリプロセス

 

 

 

6.1 サービスレベル管理

達成目標:サービスレベルに付いて定義、合意、記録及び管理すること。

@サービスの前範囲について合意し記録すること。

AサービスをSLAの中で定義し、合意しし、文書化すること。

SLA:全ての該当関係者と合意し、記録すること。

SLA:変更管理プロセスのコントロール下に置くこと。

SLA:最新状態、有効であるようにレビューによって維持すること。

Bサービスレベルを監視し報告すること。

 

ISMSなら、「サービスと言う情報資産のレベル・品質(>CIA)を管理する」ことになる。

 

各サービス資産の情報セキュリティ要求事項を明確にし、必要な管理策を実施すること=SLAの策定、運用実施すること」と同じことになる。

 

ISO27001で要求は具体的にしていないが、規格要求の方向はISO20000と矛盾はない。

 

 

 

 

6.2 サービスの報告

達成目標:十分な情報に基づいた意思決定と効果的なコミュニケーションを行うため合意された信頼できる正確なレポートを適時に作成する。

 

@

A

a)サービスレベル目標値に対するパフォーマンス

b)不遵守及び課題

c)作業負荷の特性

d)重大なイベント

e)トレンド情報

f)満足殿分析

Bサービスレポート所見の考慮、該当関係者への伝達

 

※直接ISO20000に符合するISO27001の部分は見当たらない。

 

A.13.1情報セキュリティインシデントの管理

-A.13.1.1

-A.13.1.2

 

 

6.3 サービス継続性及び可用性管理

達成目標:合意されたサービス継続性及び可用性についての顧客に対するコミットメントをあらゆる状況のもとで満たすことができれことを確実にする。

 

@可用性及びサービス継続性の要求事項を特定すること。アクセス時間、応答時間、システムコンポーネントの終端間の可用性を含めること。

A可用性及びサービス継続計画を策定し、少なくとも年1回レビューすること

B事業上の環境に対して重大な変更を行った場合、可用性及びサービス継続性計画を再テストすること。

C変更プロセスにインパクト評価を入れること。

D可用性を測定し記録する。計画外の非可用性については調査し適切な処置をとること。

 

参考 可能な場合、予防処置。

 

E通常のオフィス利用が妨げられた場合の処置:

Fニーズに沿ったテスト:

G継続性テストの記録:

 

ISMSは情報資産のCIAを確実にすることが基本命題であり、情報資産の一つであるサービスについて、CIAの一つ可用性を確実にすることも当然含まれる内容である。

 

-A.12.1.1セキュリティ要求事項の分析及び仕様化

-A.12.2業務用ソフトウエアでの正確な処理

 

その他関連ISMS要求事項

 

-G記録管理、E事業継続管理、Aマネジメントレビュー/内部監査、D監視及び見直し、

 

 

6.4 ITサービスの予算管理及び会計

達成目標:サービス提供のコストに関する予算管理と会計を行う。

 

参考 サービスプロバイダの課金はこの規格では扱わない。

 

@方針及びプロセスを定める

a)全てのコンポーネントに関する予算管理及び会計。

b)間接費の配賦、直接費の割り当て

c)効果的な財務コントロール及び許可

A十分な詳細さの予算化

Bコストについて監視し報告。財務予測のレビュー。コスト管理。

C変更管理プロセスを通してコストの見積もりを行う。

 

-5.2.1経営資源の提供

 

 

6.5 キャパシティ管理

達成目標:サービスプロバイダが顧客からの事業上のニーズの現在及び将来の合意された需要を満たすことが出来るよう十分なキャパシティを常に有していることを確実にする。

 

@キャパシティ計画

Aサービス更新:

B事業上のニーズ:

a)キャパシティ要求事項、パフォーマンス要求事項

b)サービス更新

c)新たな技術、技法の影響評価

d)外部の変更によるインパクト評価(法令等)

e)予測分析のためのデータ及びプロセス

C手法、手順及び技法の識別

 

-A.10.3.1容量・能力の管理

・・177992005の理解ではISMSの方が捉え方が狭くなっている? 少なくともJACO-ISの審査ではキャパシティ計画は求めていない。審査側の問題かな?

 

 

6.6 情報セキュリティ管理

達成目標:全てのサービス活動内で、情報セキュリティを効果的に管理する。

 

参考 ISO177992005

 

@情報セキュリティ基本方針:

Aセキュリティコントロール:

a)情報セキュリティ基本方針

b)リスクマネジメント

Bセキュリティコントロールの文書化

C変更によるインパクト評価

Dアクセス権を持つ外部組織が関与する取り決めは正式な合意に基づく。

Eインシデント管理:

F監視、記録、改善のためのインプット

 

 

6.6と直接対応するものだけを記載する。わざわざ6.6だけ情報セキュリティと書かれると、じゃ他は関係ないのかと言われそうだが、そうは行かない。

 

-4.2.1b)

-4.2.1c)

-4.3文書化に関する要求事項

 

 

 

7 関係プロセス

7.1 一般

 

 

 

 

7.2 事業関係管理

達成目標:顧客とその事業推進要因(*顧客と顧客の事業構造)に対する理解に基づき、サービスプロバイダと顧客との間に良好な関係を確立し維持する。(*ビジネスドライバーを事業推進要因と訳しているが不自然

 

@サービスプロバイダはサービス利害関係者と顧客を識別し文書化すること。

A年1回サービスレビュー:

B利害関係者の招集:

C契約、SLAの変更:

Dニーズ、重大な変更の認識:(わざわざ規格要求とする意図は?)

E苦情処理プロセス:

F顧客満足、事業関係プロセス管理の責任者:

 

-4.2.1a)適用範囲

-7.2b)利害関係者からのフィードバック

-A.6.2.2顧客対応におけるセキュリティ

 

 

7.3 サプライヤ管理

達成目標:シームレスな室の高いサービスが確実に提供されるようにサプライヤを管理する。

 

参考1 この規格の適用範囲にはサプライヤの手配は含まない。

参考2 サービスプロバイダはサプライヤを利用してサービスの一部を提供しても良い。サプライヤ管理プロセスへの適合を実証する必要があるのはサービスプロバイダである。

 

@サービスプロバイダはサプライヤ管理プロセスを文書化すること。サプライヤごとに契約マネジャーを1人指名すること。

Aサプライヤが提供する、要求事項、適用範囲、サービスのレベル及びコミュニケーションプロセスについてはSLA又は他の文書のなかで文書化し関係者の合意を得ること。

BサプライヤのSLAは事業のSLAと整合の取れたものであること。

C各関係者の利用するプロセス間のインタフェースについては文書化し合意を得ること。

D統括サプライヤと再契約先サプライヤとの間の全ての役割及び関係を明確に文書化すること。統括サプライヤは再契約先サプライヤが契約上の要求事項を満たしていることを確実にするためのプロセスを実証できること。

E年1回大規模なレビュー:

F契約、SLAの変更:

G契約上の紛争処理プロセス:

Hサービスの終了、再委託のプロセス:

Iパフォーマンス監視、レビュー、改善インプット:

 

-A.10.2.1第3者が提供するサービス

-A.10.2.2第3者が提供するサービスの監視及びレビュー

-A.10.2.3第3者が提供するサービスの変更に対する管理

 

 

 

8 解決プロセス

8.1 背景

 

 

 

 

8.2 インシデント管理

達成目標:事業に対する合意されたサービスを可能な限り人即位回復する。またはサービス要求に対応する。

 

@インシデントの記録をとる。

A

B

C

Dインシデントに関わる全てのスタッフが、既知のエラー、問題解決及び構成管理データベース(CMDB)などの関連情報を閲覧できるようになっていること。

E重大なインシデントを分類し管理すること。

 

-4.2.2ISMSの導入及び運用

-4.2.2h)

-4.2.3ISMSの監視及び見直し

-4.2.3a)

-4.2.3h)

-A.13.1情報セキュリティ事象の報告

-A.13.2セキュリティ弱点の報告

-A.13.2.1席荷の予備手順

-A.13.2.2情報セキュリティインシデントからの学習

-A.13.2.3証拠の収集

 

 

8.3 問題管理

達成目標:インシデントの原因をプロアクティブに識別し分析することにより、また問題をクローズするまで管理することにより、事業に対する中断を最小限に押さえる。

 

@記録

A識別、最小化、回避の手順

B予防処置

C変更は変更管理プロセスへ受け渡す

D有効性の監視、レビュー、報告

E既知のエラー、是正についての最新情報

F改善

 

-4.2.2h)

-4.2.3a)

-4.2.3h)

-8.2是正処置

-8.3予防処置

 

 

9 コントロールプロセス

 

 

 

9.1 構成管理

達成目標:サービス及びインフラストラクチャのコンポーネントを定義しコントロールし正確な構成情報を維持する。

 

@変更管理及び構成管理の計画立案について、統合的なアプローチ:

Aサービスプロバイダは財務資産会計プロセスとのインタフェースを定義:

 

参考 財務資産会計は、この項の適用範囲外

 

Bコンポーネント定義

C記録情報の定義

Dバージョンの識別、追跡の仕組み、紺とrトールの程度の適切性:

E変更のインパクト、変更に関して追跡可能、監査可能のこと。

F完全性の維持を確実にすること。リリース前のベースライン:

Gマスターコピー:

H全ての構成アイテムは一意に識別可能であること。

I構成監査の手順:

 

-A.7資産の管理

(構成管理に該当する概念が見当たらず。リスクアセスメントから出てくればやるスタンスか?)

 

 

9.2 変更管理

達成目標:全ての変更がコントロールされた方法で評価、認可、実装及びレビューされることを確実にする。

 

@変更の適用範囲の明確化、文書化。

A全ての変更は記録し分類し、リスク、インパクト、事業利益について評価すること。

B変更管理プロセスには変更が失敗した時、元に戻すか修正する方法を含めること。

C変更の点検、実装:

Dレビュー:

E非常時の変更の許可・実装に関する方針及び手順を定める。

Fスケジュール管理:

G変更レコードの定期的分析:

H改善のための処置:

 

-A.12.5.1変更管理手順

ISO20000よりラフ)

-

 

 

10 リリースプロセス

10.1 リリース管理プロセス

達成目標:リリースにおける1つまたは複数の変更を稼働環境に配送し配布し追跡する。

 

参考 リリース管理プロセスを構成管理プロセス及び変更管理プロセスと統合することが望ましい。

 

@リリースの頻度とタイプを記述したリリースポリシーを 文書化し、この文書について合意すること。

Aリリースについては事業とともに計画し、合意されること。

Bプロセスにはリリースが失敗した時の対応を決めておくこと。

C計画で言及する内容:

D変更要求の場合はインパクト評価を含める。

Eリリース前のテスト:

Fリリース及び配布時の完全性の確保:

Gリリースの成否を測定すること。サービス改善のインプットを提供すること。

 

-4.2.1ISMSの確立

情報資産を適用範囲外に出す時のリスクアセスメントと管理策。

-4.3.1一般(・・遡っての方針と結果の関連実証)

-A.6.2.1外部組織に関係したリスクの識別

-A.12.5.1変更管理手順

 

注)表中○番号は規格内の説明段落の順序を示す。段落が一つの場合は省略。

プロアクティブ proactive : 先を見通す

 

(インプレッション)

ISO20000の方が規格項番の流れはITプロセスをベースにしているので自然。一方、ISO27001は対策手段の分類に基づく流れのため一つ一つがやや唐突な印象がある。

 

企業情報システム部門がISMSを構築する場合、単にISMS基準だけでは不足する。やはりISO20000レベルをクリアしていないと本物にならない。

(?) 片山は言った。ISO20000のレベルは情報システム運用部門では常識レベルで特に何もしなくても通るはずだ。実際は規格以上のことをやっているので規格として意味があるのか疑問。

→文書化システムとして構築されているかは疑問。SLAの策定なんかは社内の場合あまり簡単でない。ISO20000をやる意味はある。

◇ 実践のための規範(ベストプラクティス)の関連性

 

ISO20000情報技術-サービスマネジメント-第2部:実践のための規範

27002

 

1 適用範囲

 

 

2 用語及び定義

 

 

3 マネジメントシステム

 

 

4 サービス目ね地面との計画及び導入

 

 

5 新規サービス又はサービス変更の計画及び導入

 

 

6 サービスデリバリプロセス

 

 

7 関係プロセス

 

 

8 解決プロセス

 

 

9 コントロールプロセス

 

 

10 リリースプロセス

 

 

 


◆ ISO20000ISO27001の関係

 

ISO27001は「情報資産」のセキュリティを確保するためのマネジメントの考え方。

ISO20000は「情報技術サービス」の品質を確保するためのマネジメントの考え方。

情報技術サービスは情報資産の一部。

セキュリティはCIAの観点で広く押さえるが、コンテンツの質までは立ち入らない。商品の設計図が市場要求に適合しているかどうかは問わない。情報として適切な管理レベルにあるかどうかを問うだけである。

無理やり位置づけを単純化すると、以下のようになるかな。

*ISO27001は資産は網羅的に、管理は特定的に。

*ISO20000は資産は特定的に、管理は網羅的に。

 

両者のマネジメントシステムの構造はある程度似ているが、内容まで共有するものではない

例えば、マネジメントの方針もISMSの方針とITサービスの方針の中身はまったく別のものになる。

両者の取り入れる上での工夫が可能なのは、一部の管理策(詳細管理策レベル)が共通にできる可能性があること。枠組みの考え方は個別に策定するしかない。この考え方はJSOX対応のIT統制でも同様。いくつかの管理策(文書)が共有できるだけなら相互に当該部署を参照するかたちでも問題は無い。いずれにしても誰に参照されているものかを明確にしておく仕組みは必要。

規格の対照表を作成する場合に、マネジメントシステムの枠組みとしての対応関係を示すものと、コンテンツ自体が共有できるか否かを示すものとは、意識して分けて表現すべきである。

「マネジメントシステムの共有性」(=構造の共有とコンテンツの共有は別と言うこと)の理解は「参照文書体系」の検討では必須。


◆ ISO20000の壺

 

何が何でも「変更管理」。継続的改善(改善プロセスとの連携)。「ISO20000の要求内容は普通の企業でシステム運用をやっていれば当然クリアしている内容であり、特段障害になるものは無い」との声を聞くことがあるが、果たしてそうだろうか。ISMS審査では、ここまで具体的にされた内容で受審組織の内容を見ていたかと言うと決してそうではない。基準として設定されていない以上見ることは出来ないのがその理由だが、ISMS審査から垣間見える状況で判断してみると、そもそも文書化の不徹底はそこここにあり、一応ISMS規格(27001)要求のミニマムをクリアしているのが実情ではないか。その意味では、「考え方の常識」でも「実践の常識」には至っていないことが少なくないとの認識に立って、やはりISO20000を進めるべきだ。


◇ ISO20000をクリアする意味

 

サービスプロバイダは当然、企業内情報システム部門のサービス管理、あるいは情報子会社としてのサービス管理のレベルを確保するにはISMS(ISO27001)より要求が具体的なため早く確実に目的を達成できることが期待できる。

 

逆に、情報システム部門以外の部門が行う情報マネジメント改善活動の取り組みは単にISMSだけで進めた方が良い。


◇ ISO20000 VS. ISO27001

 

ISO27001は組織特性を意識しない包括的な内容であるが、ISO20000はサービスプロバイダーを想定した内容であり、0の規格要求はより具体的である。

 

ISO27001をクリアしても要求が具体的なISO20000をクリアしたことにならない。

ISO20000を クリアしてもISO27001をクリアしたことにならない。全資産を網羅したリスクアセスメントは包括性が担保されない。

 

概念的には、@組織全体のマネジメントはISO27001をベースにし、Aサービス資産のマネジメントは更にISO20000をかぶせることにすれば両者の要求に対してクリアできる。

 

統一的に管理されたドキュメント体系の実現は容易でない。QMSISMSの間でも葛藤があったが、中途半端に相互参照するやり方は労多くして返って混乱を来たしているサイトが多い。別々に切り離して管理すれば矛盾を来たす懸念も生ずる。

モジュラー型ドキュメント管理。1施策ごとに独立して標準書を策定する。標準書が参照する文書の他に、その文書を参照している文書も明記することで、関係者(変更時のレビュー先)の抜け漏れを防ぐ。

 

文書台帳を作成し、具体的にどの文書は何処から参照されるかを示さないと実感は掴めない。仮に方針書の共通化を図る場合も本当に矛盾無く策定できるか、ISMS方針とSM方針の二本立てとどちらが有効なのか不明。しかしながら現場作業レベルの手順書の一本化は必須と考えられる。一つ一つ検証を踏まえながら共有文書体系を策定する必要がある。