ISO 27001 & BS 25999

あなたがIT部門にいるからというだけの理由で、経営陣から事業継続を導入する任務を与えられた事はありませんか。なぜ事業継続は情報技術だと一般に思われているのでしょうか。

これはおそらく、事業継続の起源が災害復旧にあり、災害復旧が基本的に情報技術に関する事だからでしょう。 20～30年前は、事業継続（BC）という概念は存在せず、災害復旧（DR）という概念だけが存在していました。その主な関心は、災害が発生したときに、どのようにデータを保存するかでした。その当時は、たとえば地震発生時に、組織のあらゆる重要なデータを保管できるように、高価な設備を購入して遠隔地に配置することが流行していました。データは保管されるだけでなく、元の場所にあったときとほぼ同じように処理できるようになっていました。

けれども、しばらくすると皆気づきました。データを利用する事業が存在しなかったら、そのデータは何の役に立つのかということに。 ここから事業継続のアイデアが誕生しました。その目的は、大きな中断があった場合でも、事業を継続できるようにすることです。

定義

定義を見てみましょう。事業継続が「あらかじめ定めた受容可能なレベルで事業運営を継続するために、インシデント及び事業中断（混乱）に対して計画を立案し対応する、組織の戦略的及び戦術的な能力」（BS 25999-2: 2007）であるのに対し、災害復旧は「天災や人災の後の、組織に不可欠な技術インフラストラクチャの復旧・継続のための準備に関連するプロセス・方針・手順」（Wikipedia.org）です。

定義からわかるように、DRの重点が技術にあるのに対し、BCの重点は事業運営にあります。 したがって、災害復旧は事業継続の一部です。災害復旧は、事業運営を可能にする原動力、あるいは、事業継続の技術的部分だと言えるかもしれません。

けれども、もう一つ気がついた人もいると思います。それは、BCの定義は BS 25999-2（事業継続管理の代表的な規格）から引用されているのに対し、DRの定義はWikipediaから引用されていることです。実際、「事業継続」は規格で認められた正式の用語ですが、「災害復旧」はそうではありません。

導入の意味

では、IT部門が組織全体の事業継続を実施するのは、どうしてよくないのでしょうか。事業継続は、基本的に事業の問題であって、ITの問題ではないからです。IT部門が組織全体の事業継続を実施した場合、事業活動の重要性も情報の重要性も定義できないでしょう。さらに言えば、組織の事業部門が積極的に参加してくれるかどうかも疑問です。

BCの導入を準備する最善の方法は、プロジェクトを事業側に指導させることです。これこそが、組織のあらゆる部門からより多くの認識と承認を得る方法です。 そのようなプロジェクトにおいて、IT部門が演じるべきなのは、中心的な役割の一つである、災害復旧計画の作成です。

—

また、弊社のウェビナーBS 25999-2 Foundations Part 1: Business Impact Analysis（市販トレーニング）もご利用ください。

ISO 27001の附属書Aは、おそらく、あらゆるマネジメント規格の中でもっともよく言及される附属書でしょう。なぜこの附属書がそんなに話題になるのでしょうか。なぜ時に議論の対象になるのでしょうか。

附属書Aを読んだことがあれば、133個のセキュリティ管理策が列挙されているのをご存知でしょう。では、規格本編は何に使われるのでしょうか。

目的

附属書Aには、以下のような箇条（ISO 27001附属書Aドメインと呼ばれることもあります）が含まれています。

• A.5 セキュリティ基本方針
• A.6 情報セキュリティのための組織
• A.7 資産の管理
• A.8 人的資源のセキュリティ
• A.9 物理的及び環境的セキュリティ
• A.10 通信及び運用管理
• A.11 アクセス制御
• A.12 情報システムの取得、開発及び保守
• A.13 情報セキュリティインシデントの管理
• A.14 事業継続管理
• A.15 順守

すでに言及したように、附属書Aには133個の管理策が含まれています。この管理策は、箇条の名前から分かるように、ITだけを対象としているわけではありません。物理的セキュリティ・法的保護・人事管理・組織的問題なども扱っています。

したがって、附属書Aは、対応プロセスの際に使われるセキュリティ方策のカタログと見なすことができます。附属書Aは、リスクアセスメントによる許容できないリスクの特定が済んだときに、そのリスクを減らすための適切な管理策を選ぶために役に立ちます。 そして、重要な管理策を見落とさないことを保証してくれます。

附属書Aは、 ISO 27001とISO 27002の接点です。ISO 27002の管理策には、ISO 27001の附属書Aの管理策と同じ名前がついています。違うのはその細かさです。ISO 27001に記載されているのは管理策の簡単な定義だけですが、ISO 27002には管理策を導入する方法に関する詳しいガイドラインが記載されています。

欠点

ここまで読んで、附属書Aを情報セキュリティ・プロジェクトの完全な導入ツールだと思った方も、楽観的になりすぎてはいけません。附属書Aには、おかしなところもあります。 たとえば、A.9.2.6（装置の安全な処分又は再利用）とA.10.7.2（媒体の処分）のように、ほとんど同じ問題を定義した管理策もあり、混乱を招くことがあります。 逆に、第三者との関係のような一部の問題は、附属書Aのいろんな箇条に散らばっており、箇条A.6.2（外部組織）、A.8（人的資源のセキュリティ）、A.10.2（第三者が提供するサービスの管理）、および、管理策A.12.5.5（外部委託によるソフトウェア開発）などに記載されています。このことが、附属書Aを導入ツールとして使うことを困難にすることもあります。

しかし、曖昧なのはこれだけではありません。附属書Aで方針や手順に言及しているのに、文書化を要求していない管理策もあります。 おかしいと思うかもしれませんが、規格で文書化を要求しているのは、「文書化」という言葉があるところだけです。 附属書全体を分析してみると、「文書化」という言葉に言及している管理策は6個（A.5.1.1、A.7.1.3、A.8.1.1、A.10.1.1、A.11.1.1、A.15.1.1）だけです。つまり、これ以外の管理策は文書化しなくても導入できるということです。

けれども、附属書Aのこの柔軟性を濫用すべきではありません。組織が大規模になるほど、セキュリティ手順が全員に認知されることを確実にするため、より多くの文書を作成する必要があります。 一方で、文書化しすぎないように注意する必要もあります。文書が多すぎれば、誰も順守しなくなりますから。

ISO 27001本編との関係

規格の本編、より正確に言えば必須箇条の4～8には、この規格のマネジメント部分が含まれています。ここでは、リスクアセスメントおよび対応、文書管理、記録管理、経営資源の提供、内部監査、マネジメントレビュー、是正処置・予防処置などを含む、PDCAサイクル（計画-実行-点検-処置フェーズ）を規定しています。

先に述べたように、リスクアセスメントおよび対応プロセスは、箇条4～8が附属書Aの管理策に最も関係するところです。この部分は、附属書Aの各管理策が、リスクを減らすために必要かどうかを決めるのに役立ちます。

つまり、箇条4～8と附属書Aは、それぞれ単独では成り立たないということです。リスクアセスメントはリスクを減らすための管理策がなければ無意味ですし、管理策の適用可能性を判定する唯一の方法はリスクアセスメントですから。

私の考えでは、このリスクの重視と、自分が適切だと考えるところにセキュリティ管理策を適用する柔軟性が、ISO 27001の最もよいところです。その恩恵を全面的に受けるためには、慎重になるしかありません。

—

また、弊社のウェビナーISO 27001 Foundations Part 3: Annex A overview（市販トレーニング）もご利用ください。

あなたは、BCMは「不可能」「不要」「大災害時には役に立たない」などと言われた事はありませんか。事業継続管理を導入した人なら、おそらくあるはずです。このような態度はもちろんプロジェクトの邪魔になるので、そのような人に対処する方法をいくつか教えましょう。

「大災害が発生した場合には、どうすることもできない」

これがおそらく最も多い批判でしょう。 この批判は、あなたが実際に起こりうるあらゆるシナリオを想定して、事業継続戦略や 事業継続計画を作成していなければ、正しいかもしれません。しかし、あなたがあらゆるシナリオを想定していれば、どんな災害にでも耐えられるほど距離の離れた代替地を準備していたこと、データのバックアップコピーを作成済みであること、会社のあらゆる従業員に代替要員がいること、重要なあらゆるサービスに代替供給者がいること、などを説明できるでしょう。

「核戦争が起こったら、うまくいかないだろう」

なるほど。でも軍事供給者でもない限りは、問題ではありませんよね。違いますか。 この種の破滅的なシナリオにおいては、あなたの事業はおそらく存在する意味がなくなっているでしょう。

「不必要なのでは」

もう事業継続を利用する必要がないことを祈るだけですね。 9/11やハリケーン・カトリーナのような周知の例を出すまでもなく、こう尋ねれば十分でしょう。「停電を経験したことはありませんか？」あるいは「サーバが故障したことは？」あるいは「重要なデータを保存したPCが故障したことは？」「完全に焼失した建物の話を聞いたことは？」このような事が誰にでも起こりうることを理解するには、新聞の見出しを読めば十分です。

「ウチは審査員を納得されればいいんだ」

優先順位が間違っています。 適切に実施すれば、あなた自身を守り、その結果として審査員も満足するのです。

「あらゆるインシデントを予測することなんかできない」

これは少なくとも最初のうちは真実です。 けれども、適切なリスクアセスメントを実施して、資料やさまざまな経営資源を利用し、評価を定期的にレビューすれば、起こりうるあらゆるリスクを想定することが可能になるでしょう。リスクを想定できれば、それに対する対応を準備することができます。

「人間は非常の際に、仕事よりも家族のことを考えるだろう」

これも真実です。 地震のときにまず家族の無事を確認しない人はいないでしょう。 けれども、インシデント発生後に帰宅してよい人と残って事態の解決を図る人を注意深く割り振って、残らなくてはならない従業員の家族の面倒を（他の従業員に頼んで）見ることにすれば、おそらくこの問題は解決できるでしょう。

「人間は危機的な状況になると不合理な行動をとる」

間違いなく真実です。けれども、従業員（供給者/パートナー）を日常的に訓練し、なおかつ、事業継続計画を実施しておけば、彼らはストレスの多い状況に慣れるので、そのような事態が発生してもおそらく適切に対処してくれるでしょう。

同様なプロジェクトを導入したことがある方なら、意識向上の重要性をご存知でしょう。同僚がプロジェクトの目的を認識していないと、導入時にかなりの困難を経験するはずです。 プロジェクトが完全に失敗するかもしれないことは言うまでもありません。これが意識向上を事前に考慮しなければならない理由です。

—

また、弊社のウェビナーBS 25999-2 Foundations Part 2: Business Continuity Strategy（市販トレーニング）もご利用ください。

ISO 27001とISO 27002の両方を読むと、おそらく、ISO 27002の方がはるかに詳細かつ厳密であることに気づくでしょう。ではISO 27001は何のためにあるのでしょうか。

まず、ISO 27002はマネジメント規格ではないので、認証を受けることはできません。ではマネジメント規格とは何なのでしょうか。 マネジメント規格とはシステムの運営方法を定義する規格です。ISO 27001の場合、情報セキュリティマネジメントシステム（ISMS）を定義しているので、ISO 27001に対する認証が可能なのです。

情報セキュリティマネジメントシステムでは、情報セキュリティを計画・導入・監視・レビュー・改善する必要があります。ISMSでは、経営陣が明瞭な責任を持ち、目標を設定・測定・レビューし、内部監査を実施する必要があります。このような要素はすべて、ISO 27002ではなく、ISO 27001で定義されます。

ISO 27002の管理策は、ISO 27001の[link]附属書Aの管理策と同じ名前になっています。たとえば、ISO 27002の管理策6.1.6は「関係当局との連絡」という名前ですが、ISO 27001のA.6.1.6も「関係当局との連絡」です。 けれども、違うのはその細かさです。平均すると、ISO 27002では一つの管理策を一ページ全体で説明していますが、ISO 27001では各管理策に一行しか割り当てていません。

最後の違いは、ISO 27002では、特定の組織にのみ当てはまる管理策とそうでない管理策を区別していないことです。一方、ISO 27001では、各管理策がリスクを減らすために必要かどうか、そして、必要な場合にはどの範囲に適用すべきかを特定するために、実施すべきリスクアセスメントを規定しています。

問題は、 なぜ2つの規格が別々に存在するのか、なぜ両者のいい処だけを取って1つの規格にまとめないのか、ということです。 その答えは使い易さです。もし単一の規格だったら、大量すぎ複雑すぎて実用にならないでしょう。

ISO 27000シリーズの規格は、それぞれ特定のテーマで設計されています。組織の情報セキュリティの基礎を構築して、そのフレームワークを考案したい場合には、ISO 27001を利用すべきだし、管理策を導入したい場合には、ISO 27002を利用すべきだし、リスクアセスメントやリスク対応を実施したい場合には、ISO 27005などを利用すべきです。

結論としては、ISO 27002に記載された詳細がなければ、ISO 27001の附属書Aで定義された管理策は導入できないと言えるでしょう。けれども、ISO 27001の管理フレームワークがないと、ISO 27002は、情報セキュリティに熱心な人の孤独な努力に過ぎず、首脳部からの承認も受けられなければ、実際の組織に影響を与えることもないでしょう。

—

また、弊社のウェビナーISO 27001 Foundations Part 3: Annex A overview（市販トレーニング）もご利用ください。

あなたは、経営陣を説得して情報セキュリティの導入に投資しようとしたことがありますか。 もしあるのなら、どうなるかはご存知でしょう。経営陣はコストがいくらかかるかを尋ね、高すぎれば拒否するでしょう。

実際、そのような経営陣は責められません。結局のところ、経営陣の最終的な責任は企業の収益性なのですから。 つまり、経営陣の意思決定は、すべて投資と利益の間のバランス、彼らの言葉で言えば、ROI（投資収益率）に基づいています。

つまり、そのような投資を提案する際には、準備が必要だということです。経営陣が理解・認識できる言葉を使って、利点をプレゼンする方法を慎重に考えねばなりません。

そのお手伝いをしましょう。情報セキュリティ、特にISO 27001の導入には、さまざまな利点があります。 けれども、私の経験では、最も重要なのは以下の4つです。

1. 順守

これを利点の第一に挙げるのは奇妙に映るかもしれませんが、これが最も早く「投資収益率」に反映されることが多いです。組織（特に金融・保健・政府機関）がデータ保護・プライバシー・IT統治に関するさまざまな規制に従う必要がある場合に、ISO 27001はそれを最も効率的な方法で行うことを可能にする方法論を提供します。

2. マーケティング・エッジ

競争が激化する市場において、顧客の視点で組織を差別化することは極めて困難です。 特にクライアントの機密情報を扱う組織の場合、ISO 27001は得がたいセールス・ポイントになる可能性があります。

3. 費用の節約

情報セキュリティは通常、はっきりした金銭的利益のないコストと見なされています。けれども、インシデントから生じる費用を節約できれば、金銭的利益が生まれます。インシデント時には、おそらくサービスの中断やデータ漏洩や従業員の不満が発生するでしょう。 あるいは元従業員すら不満を抱くかもしれません。

本当を言うと、そのようなインシデントを防ぐことによって節約できる金額を計算する方法や技術はまだ存在しません。 けれども、そのような事態に経営陣の意識を向ければ、肯定的な印象を与えることは確実です。

4. 仕事に秩序をもたらす

おそらくこれが最も過小評価されています。過去2、3年で急速に成長した企業では、誰が何を決断するか、誰が特定の情報資産に責任を持つか、誰が情報システムへのアクセスを認可するか、といった問題に直面することがあります。

ISO 27001は、特にこのような事態を解決することに適しています。ISO 27001は責任・義務を厳密に定義することを強制し、内部組織を強化します。

結論としては、ISO 27001は、単に認証を壁に飾る以外にも、多くの利益をもたらす可能性があるということです。ほとんどの場合、利益を明快に示すことができれば、経営陣は耳を傾けるはずです。

—

また、弊社のウェビナーISO 27001 / BS 25999-2 management responsibilities: What does management need to know?（市販トレーニング）もご利用ください。

ISO 27001導入の第一段階が適用範囲の定義であることは、おそらくご存知でしょう。 ご存知ないのはおそらく、この手順は、一見単純ですが、さまざまな問題を引き起こす可能性があるということです。つまり、多くの会社では導入コストを削減するために適用範囲を狭めようとしますが、そのような適用範囲が頭痛の種になることは珍しくありません。

では問題はどこにあるのでしょうか。

ISO 27001の適用範囲が組織でない場合の問題は、情報セキュリティマネジメントシステム（ISMS）が「外の」世界との接点を持たねばならないということです。この文脈で言う「外の世界」には、クライアント・パートナー・供給者などだけでなく、組織内の適用範囲外の部門も含まれます。おかしいと感じるかもしれませんが、適用範囲外の部門は外部供給者と同じように扱う必要があります。

たとえば、適用範囲に選択したのがIT部門だけで、このIT部門が購買部のサービスを利用している場合、IT部門は購買部のリスクアセスメントを実行して、IT部門に責任のある情報にリスクがあるかどうかを特定する必要があります。さらに、この2部門は提供されるサービスの取引条件に署名する必要があります。

そのようなコストが必要なのはなぜでしょうか。 認証機関の立場で考えてください。認証機関は、あなたが適用範囲内の情報を安全に処理できることを認証する必要がありますが、適用範囲外の部門をチェックすることはできません。そのような状況を処理する唯一の方法は、そのような部門を外部の企業のように扱うことです。 （認証審査員は決して狭い適用範囲を好まないことに注意してください。）

問題はまだ終わりません。単に外の世界との接点がないだけのために、適用範囲を狭くできない場合もあります。 たとえば、適用範囲内と適用範囲外の従業員が同じ部屋の中に座っているような場合、そのような適用範囲はほとんど実現不可能です。適用範囲内外の従業員が同じローカル・ネットワークを（領域分割なしで）を利用していて、さまざまなネットワーク・サービスにアクセスしている場合、そのような適用範囲は確実に不可能です。そのような場合に、適用範囲内だけの情報の流れを管理する方法はありません。

要するに、ISMSの適用範囲を狭めることは、まったく不可能なこともあるし、多くの場合余計なコストが発生するということです。 したがって、当初は優れたソリューションに見えなかったものが、最終的には最適なソリューションであることがあります。適用範囲を組織全体にまで広げてみてください。 原則として、組織の従業員が数百人以下で、支社も数箇所程度である場合には、組織全体を適用範囲とするISMSが最適です。

逆に、実際に組織全体をISMSの適用範囲で覆うことができない場合には、十分に独立した組織単位を適用範囲に設定してみてください。そして「契約」として働く内部文書（方針・手順など）でサービスを決めることにより、適用範囲外の他の組織単位との関係を解決してみてください。そうすれば、そのような組織単位の責任を、日常業務で利用できるような方法で文書化することができるでしょう。

おめでとうございます。これでISO 27001導入の第一段階は解決しました。

—

また、弊社のビデオ・チュートリアルHow to Define and Document the ISMS Scope According to ISO 27001（市販ビデオ）もご利用ください。

あなたはおそらく、リスクアセスメントが済んでいるのに、なぜ事業インパクト分析（BIA）を実施しなければならないかを不思議に思っているでしょう。 リスクの特定は済んでいます。すでに企業の分析に長時間を費やしているのに、なぜさらなる分析が必要なのでしょうか。

BIAは目的が違うのです。 事業継続では、すべてが時間の問題です。適当な時間内に事業活動を復旧できないなら、復旧できるかどうかは問題ではなくなります。 この「適当」こそがBIAで決める事です。その主な目的は、組織の重要な活動のそれぞれについて、目標復旧時間を発見することです。

この種の分析は軽く見られがちです。企業は通常、誤った結果が不必要な出費や不適切な事業継続戦略につながることを認識していないばかりか、BIAを実施するために必要な労力が過小評価しています。

そこで、事業インパクト分析より効果的なものにするためのヒントを以下に紹介します。

（小さい）プロジェクトとして扱う。 導入に責任を持つ人、および、その権限を定義します。適用範囲・目標・時間枠を定義します。

準備として、優れたアンケートを作成する。よくできたアンケートは、時間を大幅に節約し、より正確な結果をもたらします。 BS 25999-1、BS 25999-2規格は、アンケートに含むべき質問について、非常によいヒントを与えてくれます。特に、中断による影響を特定して、時間にともなう変化を判定し、復旧に必要な経営資源を特定する必要があります。 影響を特定する際に、定性的な質問と定量的な質問の両方を使うのはよい方法です。

明確な基準を定義する。 回答者が質問に回答する際に、たとえば1～5の値を割り当てなければならない場合、その5個のマークが持つ意味を正確に説明するようにしましょう。同じ事象を、一般の従業員が破滅的と評価するのに対し、首脳部が中程度と評価することは珍しくありません。

人的交流によりデータを収集する。最善の結果は、事業継続に熟練した人が、重要な活動に責任を持つ人と面談することにより実現されます。そうすれば、未解決の疑問の多くがはっきりし、バランスのとれた解答が得られます。面談が不可能な場合には、全員参加のワークショップを最低でも一回は開催して、参加者が困っている事をすべて聞くようにしましょう。 言い換えれば、単にアンケートを送りつけて、送り返さない人を非難するようなことはやめましょう。

目標復旧時間を決定するのは、依存関係のすべてを特定してからにする。 たとえば、アンケートにより、重要な活動「A」の最大許容停止時間は2日間であると結論付けたとします。でも、重要な活動「B」の最大許容停止時間は1日間で、重要な活動「A」の支援がないと復旧できないとします。 つまり、この場合の「A」の目標復旧時間」は、2日間ではなく1日間であるということです。

私の経験では、BIAの結果はしばしば予想外です。目標復旧時間は通常、当初想定したより長いことが多く、BIAは、実際には単一障害点である経営資源間の依存関係を明らかにします。 でも、事業インパクト分析は何よりも、人々に想定外の事について考えさせる最も効果的な方法であり、そのような意識を生み出すことにより、企業の生存率を増やしてくれます。

—

また、弊社のウェビナーBS 25999-2 Foundations Part 1: Business Impact Analysis（市販トレーニング）もご利用ください。

私は、情報セキュリティ基本方針を詳しく書こうとして、戦略目標からパスワードの文字数まであらゆることを網羅しようとするところを、たびたび見てきました。 そのような基本方針の唯一の問題点は、それが50ページ以上にもなるということ、そして、そんなものを真面目に読もうとする人は誰もいないということです。そのような基本方針は通常、審査員を満足させるだけのための作り物の文書としてしか役立ちません。

でも、そのような基本方針を実施するのが極めて難しいのはなぜでしょう。 それは、そのような基本方針は野心的過ぎるからです。網羅しようとする問題が多すぎ、対象とする人々の範囲が広すぎるからです。

代表的な情報セキュリティ規格であるISO 27001で、さまざまなレベルの情報セキュリティ基本方針を定義しているのはそのためです。

• 高レベルの方針（情報セキュリティマネジメントシステムの基本方針など) – このような高レベルの基本方針では、通常、戦略的な意図や目標を定義します。
• 詳細な方針 – このような方針では通常、選ばれた領域の情報セキュリティの厳密な責任などをより詳しく記述します。

ISO 27001では、情報セキュリティマネジメントシステム（ISMS）の基本方針に対し、最高レベルの文書として、目標を設定し、さまざまな要件や義務を考慮に入れ、組織の戦略的なリスクマネジメントの文脈に合わせて、リスク評価基準を確立するためのフレームワークであることを求めています。 そのような基本方針の主な目的は、首脳部がISMSを管理できることなので、極めて短いもの（1、2ページ）である必要があります。

一方、詳細な方針は、運用時の利用を目的とすべきであり、より狭い範囲のセキュリティ活動に焦点を合わせるべきです。 そのような方針の例としては、分類方針、情報資産の許容できる利用方針、バックアップ方針、アクセス制御方針、パスワード方針、クリアデスク・クリアスクリーン方針、ネットワーク・サービスの利用についての方針、モバイル・コンピューティングの方針、暗号による管理策の利用方針などがあります。 その管理策が適用可能か、あるいは、どこまで適用可能かの決定は、リスクアセスメントの結果に依存するので、ISO 27001では、このような方針の導入や文書化を要求していません。ご注意ください。

そのような方針はより詳しく記述する必要があるので、通常はさらに長くなり、最高で10ページ程度になります。これより大幅に長い方針を導入・維持することは極めて難しくなります。

つまり、情報セキュリティは単一の方針の中で定義するには複雑すぎる問題なのです。ISMSの異なる側面や「対象グループ」に対しては、異なる方針を定義すべきです。中規模の組織では通常、ISMSに最高で15個もの方針を定義します。

そんな数の方針は、企業にとって負担にしかならないと言う人もいるでしょう。 認証審査のことしか考えずに書かれた方針は、官僚主義をもたらすだけだということには私も同意します。 けれども、リスクを減らす意図で書かれた方針は、すぐにではなくても、おそらく2、3年のうちにはインシデントの数を減らし、その価値が明らかになることでしょう。

—

また、弊社のビデオ・チュートリアルHow to Write the ISMS Policy According to ISO 27001（市販ビデオ）もご利用ください。

あなたは、ISO 27001にはたくさんの手順が必要だと聞いたかもしれませんが、必ずしも正しくありません。 実際に規格が文書化を要求している手順は、文書の管理策の手順、内部ISMS監査の手順、是正処置の手順、予防処置の手順の4つだけです。 「文書化」という用語は、「その手順を確立し、文書化し、実施し、かつ、維持している」ことを意味します（ISO/IEC 27001、4.3.1注記1）。

注記： このブログポストでは、ISMS適用範囲、ISMS方針、リスクアセスメント方法論、リスクアセスメント報告、適用宣言書、リスク対応計画などの必須文書には言及しません。ここでは手順だけに重点を置きます。

文書管理策の手順（文書管理手順）では、文書の承認やレビューに責任を負う人、変更・改訂の状態を特定する方法、文書を配布する方法などを定義する必要があります。 言い換えれば、この手順は、組織の血液（文書の流れ）の働きを定義する必要があります。

内部監査の手順では、監査を計画・実施する責任、監査結果の報告方法、記録の管理方法を定義する必要があります。つまり、監査を実施する際の主なルールを設定する必要があるということです。

是正処置の手順では、不適合およびその原因を特定する方法、必要な処置を定義・実施する方法、記録すべき事、処置のレビューを行う方法などを定義する必要があります。 この手順の目的は、不適合が再度発生しないように各是正処置でその原因を取り除く方法を定義することです。

予防処置の手順は、是正処置の手順とほとんど同じです。両者の違いは、不適合がまず発生しないように原因から取り除くことを目標としているということです。この2つの手順は似ているので、1つにまとめられるのが普通です。

でも、ISO 27001では情報セキュリティに関係しない手順も文書化する必要があるのに、なぜセキュリティ手順は必須ではないのでしょうか。

その答えはリスクアセスメントです。ISO 27001ではリスクアセスメントを実施する必要があります。そして、このリスクアセスメントによって容認できないリスクが特定されたときには、そのリスクを低減するような附属書Aの管理策を実施することを求めています。 管理策には、技術的なもの（悪意のあるソフトウェア攻撃のリスクを減らすアンチ・ウィルス・ソフトウェアなど）もあれば、方針や手順の導入（バックアップ手順の導入など）のように組織的なものもあります。したがって、このような手順が必須になるのは、リスクアセスメントで許容できないリスクが特定された場合だけです。

でも、重要な注意事項が一つだけあります。文書化が義務付けられた4つの手順とは逆に、附属書Aの管理策の手順は、文書化する必要がありません。そのような手順を文書化すべきかどうかを考えるのは、組織側の責任です。

義務付けられた4手順は、（セキュリティの基本方針と共に）マネジメントシステムの柱と考えることができます。この柱を地面にしっかりと建てておけば、家の壁を建てることができます。 このことは、他のマネジメントシステムを見れば明らかです。同じ4手順が、ISO 9001（品質マネジメントシステム）や、ISO 14001（環境マネジメントシステム）や、BS 25999-2（事業継続管理システム）でも必須になっています。 したがって、これらの手順は、いわゆる「統合マネジメントシステム」を開発する際にも、異なるマネジメントシステム間の主な接点として利用できます。

—

また、弊社のビデオ・チュートリアルHow to Write ISO 27001/ISO 22301 Document Control Procedure（市販ビデオ）もご利用ください。

事業継続管理を導入する際に直面する最大の課題は、おそらく、事業継続計画を書くことです。

事業継続計画を書くことはなぜそんなに難しいのでしょうか。それは、災害（その他の事業活動の中断）が発生し得るさまざまなシナリオを検討して、そのような極めて稀であるが潜在的に破滅的なインシデントを処理する方法を考える必要があるからです。

そのような計画を書く人が一般に直面する問題には、計画に何を加えるべきか（何が主な要素か）、計画をどのぐらい長く（どのくらい詳しく）すべきか、計画にどんな手順を含むべきか、などがあります。

このようなジレンマに対する最善のソリューションは、BS 25999-2規格を使うことです。この規格はBS 25999-1とともに、計画を書くためのフレームワークを定義します。

これらの規格によると、事業継続計画は、(1)インシデント対応計画および(2)復旧計画から構成されている必要があります。 インシデント対応計画は通常、組織全体のために書かれた統一計画で、 インシデントの影響を減らす、救急隊に通報する、建物から避難する、集合場所に集合する、別の場所への移動手段を調達する、などの災害発生の直後に行わなくてはならない事を記述します。

復旧計画は通常、重要な活動ごとに書かれます。復旧計画に記載される手順には通常、次の通りです。さまざまなステークホルダー（従業員・その家族・株主・顧客・パートナー・政府機関・公共メディアなど）に伝える時期と方法、チームを招集する方法、インフラストラクチャを復旧する方法、アプリケーションが機能しているかどうか、および、アクセス権が適切かどうかをチェックする方法、損失したデータや災害によって破損したデータをチェックする方法、データを復旧する方法、復旧が完了して通常営業を開始できる時期を決める方法。

災害復旧計画（ICTインフラストラクチャの復旧計画）には、特定の重要活動の目標復旧時間以内に各システムを実行する方法を記述する必要があるので、注意深く書くべきです。これは通常、復旧する各システムの詳しい復旧計画を書くことにより実現されます。

原則として、このような計画には、その重要活動に従事している人が実行できない場合にも、他の従業員（または外部のスタッフ）が実行できる程度の詳しさが必要です。 したがって、計画を書く際には常識を働かせて、自分だけでなく誰もが理解できるようにしてください。

私の経験では、このような計画を書くときの最大の課題は、従業員がそれまで考えもしなかったような、まったく異なる事態に直面しなくてはならないということです。 そのような問題を乗り越えるには、起こる事やその対処方法に関する見解を共有できるようなワークショップ（モデレータはいてもいなくてもよい）を組織するのが最善です。

実際には、従業員が事業継続について考え始めるという事は、仕事全体の半分に過ぎません。そのようなアプローチをとることにより、事業継続計画の結果は数段向上します。

—

また、弊社のウェビナーBS 25999-2 Foundations Part 3: Business Continuity Planning（市販トレーニング）もご利用ください。