ISMSで文書化が求められる項目とは？-規格本文編-

この記事では、ISMSにおいて文書化が求められている項目について整理します。
ISMSにおいては、規格の項目によっては「文書化した情報」を準備することが求められていますが、各項目でどのようなことが求められているのでしょうか。

今回は特に規格本文部分における文書化要求がある項目について整理してみましょう。

そもそも「文書化した情報」とは

ISMSの規格ISO/IEC27001（JIS Q 27001）において文書化が求められる項目では「文書化した情報として利用可能な状態にしなければならない」という要求が使われます。
ではここで指す「文書化した情報」とはどのような成果物ができていれば充足ができるのでしょうか。

「文書化」という言葉を見るとたとえば規程のようにすごくしっかりとしたものができていなければないように見えますが、規格上での定義では「あらゆる形式・媒体の形」をとることが許容されています。
ですので規格上で「こういう情報を文書化した情報にしてくださいね」という情報さえカバーできていれば、動画や音声、図表などでもOKです。

文書化要求がある項目

4.3 情報セキュリティマネジメントシステムの適用範囲の決定

この項目では、「ISMSの適用範囲」を文書化した情報として利用可能にしておくことが求められています。

一般的には、適用範囲の組織名、所在地、事業内容を規程や記録に記載したり、またフロア図やネットワーク図、組織図など適用範囲をより明確化するための図面を作成することが多いです。

5.2 情報セキュリティ方針

この項目では、「情報セキュリティ方針」を文書化した情報として利用可能にしておくことが求められています。

多くのケースでは、社内ドキュメントとして作成したり、組織のHP上などで公開する形が取られます。

6.1.2 情報セキュリティリスクアセスメント

この項目では、「情報セキュリティリスクアセスメントのプロセス」を文書化した情報として利用可能にしておくことが求められています。

重要なのはリスクアセスメントの結果の記録ではなく、リスクアセスメントを行うためのプロセス・手順の文書化が求められているということです。

一般的には運用規程上に該当する項目を作ったり、リスク管理規程のようなものを別冊として作成することが多いです。

6.1.3 情報セキュリティリスク対策

この項目では、「情報セキュリティリスク対応のプロセス」を文書化した情報として利用可能にしておくことが求められています。

重要なのは、リスクアセスメントと同様、プロセス・手順の文書化が求められているということです。
ですので文書化の成果物も同じような形が取られることが多いです。

また、「文書化した情報として」とは明確に記載されていないものの、この項目の中では「適用宣言書の作成」も求められているため、実質的には2つの文書化した情報が発生することになります。

6.2 情報セキュリティ目的及びそれを達成するための計画策定

この項目では、「情報セキュリティ目的」について文書化した情報として利用可能な状態にしてくことが求められています。

この項目における成果物はたとえば「情報セキュリティ方針の中に含める」ような場合もあれば、「目的管理表のような記録として管理する」ケースもあるといったように組織に応じて様々な管理方法が行われているように感じます。

7.2 力量

この項目では、「力量の証拠」として文書化した情報を保持することが求められています。

これも組織が力量をどのように定めているか、その力量を何を持って有していると判断するかの基準によって、成果物は全く異なることが想定されます。
例えば教育実施記録のようなものを作成している場合もあれば、教育のテスト結果を保持していたり、eラーニングツールなどを使っていればそのツール上に残っている結果をそのまま文書化した情報として提示することももちろん可能です。
また、場合によっては〇〇資格の認証書を文書化した力量の証跡として代替するなんてことも考えられます。

8.1 運用の計画策定及び管理

この項目では、「プロセスが計画通りに実施されたという確信を持つために必要とされる」文書化した情報を利用可能な状態にしておくことが求められています。
もう少し噛み砕くと、「あらかじめ定めた計画通りにタスクを実施しましたよ」という証拠の文書化した情報が求められているイメージです。

これについても例えば「年間計画表」のようなもので予実管理したり、計画通りにタスクを行ったことを「各タスクで発生した成果物」で示せるようにしたり、最近であればタスク管理ツールで年間計画を管理してそれを証跡として対応するといったことも考えられます。

8.2 情報セキュリティリスクアセスメント

この項目では、「情報セキュリティリスクアセスメント結果」を文書化した情報として保持することが求められています。

6.1.2も同じタイトルの項目でしたが、こちらは6.1.2のプロセスに基づいて行った対応の結果の文書化が求められていると考えましょう。

一般的にはリスク管理表のような記録を作成することが多いです。

8.3 情報セキュリティリスク対応

この項目では、「情報セキュリティリスク対応結果」を文書化した情報として保持することが求められています。

こちらも6.1.3に同じタイトルの項目がありましたが、8.2同様、プロセスに基づいて行った対応の結果の文書化が求められていると考えましょう。

こちらも一般的には同じようにリスク管理表のような記録を作成したり、追加で対応計画のようなものを作ったり、タスク管理ツール上で生成したタスクそのものがこの対象になることも考えられます。

9.1 監視、測定、分析及び評価

この項目では、「規格で求められていることの結果の証拠」として文書化した情報を利用可能な状態にすることが求められています。

一般的には指標などを規程に含めたり、結果を有効性評価シートのようなもので記録として残すケースが多いかもしれません。

9.2.2 内部監査プログラム

この項目では、「監査プログラムの実施及び監査結果の証拠」として文書化した情報を利用可能な状態にすることが求められています。

一般的には監査計画や監査報告書、監査チェックリストなどの形で記録として作成されることが多いです。

9.3.3 マネジメントレビューの結果

この項目では、「マネジメントレビューの結果の証拠」として文書化した情報を利用可能な状態にすることが求められています。

一般的にはマネジメントレビュー記録を作ったり、レビュー時の議事録を証拠として残すことなどが想定されます。

10.2 不適合及び是正処置

この項目では、「不適合の性質及び講じた処置/是正処置の結果」の証拠として文書化した情報を利用可能な状態にすることが求められています。

一般的には是正処置管理表といった形で不適合の内容から原因、是正対応までをまとめた記録が作られることが多いです。

おわりに

今回は規格本文部分で文書化要求がある項目について整理しました。
ただ、この項目だけ文書化すれば良いというものでもなく、少なくともこの項目に該当するものは用意した上で、そのほかの項目でも必要に応じて証跡を用意しておくことが望まれます。

改めて自分たちが作っている文書や記録が何をカバーするために存在するのか、本当に必要な項目を満たせているのか、また実は必要以上に重いものになってしまっていないかなど整理してみても良いかもしれません。