事業継続への7つのステップ

現在、企業の重要なビジネスプロセスの可用性を向上させ、計画を立てるのに役立つビジネス継続性管理技術が多数あります。 しかし、これらの手法にはビジネス継続性の理論的基礎が含まれており、「そのようなプロジェクトを実装する方法」という質問には答えません。 この記事では、ビジネス継続性管理システムがどのように実装され、各段階でどのような結果が得られるかを理解するための一連のアクションについて説明します。







事業継続管理プロセスのライフサイクル



企業のビジネス継続性の管理は、組織、ビジネス、IT、法律、および組織に影響を与えるその他の分野で起こりうる変化を考慮し、これらの変化への適応を支援する循環プロセスです。 言い換えれば、ビジネス継続性管理は継続的な改善のプロセスであり、その結果、ビジネス継続性計画の信頼性に対する企業の信頼が高まります。



事業継続管理プロセスのライフサイクルには7つの段階があり、それぞれが手順の順序と結果を決定します（段階のリストはBCM Instituteのサイクル[8]に基づいて作成されました）。



プロジェクトの開始



プロジェクトとは、独自の製品、サービス、結果を作成することを目的としたアクティビティです。







プロジェクト管理計画-プロジェクトの実装方法、監視および制御方法を説明する文書。

PMBOKガイド-第5版



この段階で、事業継続プロジェクトの内容が決定され、段階的な計画が策定されます。 プロジェクトの実装方法、監視、制御、およびクローズの方法を定義し、プロジェクトの境界、プロジェクトチームのメンバーの役割、およびプロジェクトの目的も定義します。



上記のアクションに加えて、プロジェクトの必要性を判断する必要があります。 一部の企業では、ビジネスの継続性により、ミッションクリティカルなビジネス機能の有効性を確保し、顧客にビジネスの持続可能性を実証しています。 しかし、事業継続のための規制上の法的行為および規制機関の要件があることを忘れてはなりません。 以下の表は、ロシア連邦の領土で広く使用されている標準/規制法（NLA）、およびこれらの標準/ NLAがビジネス継続性システムに対して持っている多くの要件をリストし、説明しています。

標準/規範	要件	説明	ステータス
ISO / IEC 27001：2013「情報技術-セキュリティ技術-情報セキュリティ管理システム-要件」（情報技術。セキュリティ手法。情報セキュリティ管理システム）	A.17ビジネス継続性管理の情報セキュリティの側面 （事業継続管理における情報セキュリティの側面）	情報セキュリティの継続性は、会社のビジネス継続性システムに統合する必要があります。 これを行うには、以下を行う必要があります。 -情報セキュリティの継続性を計画する。 -情報セキュリティの継続性を導入します。 -情報セキュリティの継続性を確認、評価します。	企業がISO / IEC 27001：2013「情報技術-セキュリティ技術-情報セキュリティ管理システム-要件」への準拠証明書を取得しようとする場合、情報セキュリティの継続性は要件の1つです。
ISO 22301：2012「社会保障-事業継続管理システム-要件」（社会保障。事業継続管理システム）	この標準は、ビジネスの継続性に焦点を当てています。	標準状態： -会社で事業継続管理システムを確立するために必要な要件。 -事業継続管理システムにおける上級管理職の機能の要件。 -ビジネス継続性管理システムの戦略的目標とガイドラインを設定するための要件。 -ビジネスの継続性を確保するための要件、インシデントの管理手順を開発するための手順。	企業がISO 22301：2012「社会保障-事業継続管理システム-要件」への準拠証明書を取得しようとする場合、BCP / DRP計画（これらの計画については「計画の開発と実装」セクションで説明）の存在が前提条件となります。
GOST R 53647「ビジネス継続性管理」	この標準は、ビジネスの継続性に焦点を当てています。	この国際規格は、文書化されたビジネス継続性管理システムの計画、作成、運用、監視、分析、実施、サポート、改善の要件を定めています。	それは本質的に推奨です。
STO BR IBBS-1.0-2014「ロシア連邦の銀行システムの組織の情報セキュリティの確保」	8.11。 ビジネス継続性管理の要件 中断後の回復	銀行システムの組織は、事業の継続性と可能な中断後の回復を確保するための計画を定義する必要があります。 計画には、銀行システムの組織の従業員が事業を回復するための指示と手順を含める必要があります。 特に、計画には以下を含める必要があります。 -計画を有効化するための条件。 -ISインシデント後に行われるアクション。 -回復手順。 -テストおよび検証手順。 -従業員のトレーニングと意識向上の計画。 -従業員の義務。計画の各規定の実施に責任を持つ従業員を示します。 必要な情報、ソフトウェア、ハードウェア、通信チャネルを復元するための手段の要件を含む、事業継続性と中断後の回復の問題を管理するISを確保するための要件も確立する必要があります。	それは本質的に推奨です。
2013年2月11日付ロシアFSTECの命令第17号「国家情報システムに含まれる国家機密を構成しない情報の保護要件の承認について」	X.情報のアクセシビリティの確保（CCT）	2013年2月11日付けロシア連邦FSTEC命令第17号「国家情報システムに含まれる国家機密を構成しない情報の保護要件の承認」に基づき、以下が必要です。 -フェールセーフ技術手段を使用します。 -予約ハードウェア、ソフトウェア、情報伝送チャネル、情報システムの機能を確保する手段。 -技術機器のトラブルのない機能を制御します。 -技術的手段の機能の障害の検出と位置特定を確実にするため。 -失敗した資金を回復するための措置を講じる -テストハードウェア; -定期的にバックアップマシンメディアに情報をバックアップします。 -指定された時間間隔内にバックアップマシンのストレージメディア（バックアップ）から情報を回復する機能を提供します。 -情報転送を含む、コンピューティングリソース（キャパシティ）の許可された人による提供の条件と品質を制御します。	システムがセキュリティクラス1または2に従って分類されている場合、注文に記載されている要件は必須です。
2013年2月18日付ロシアのFSTECの命令第21号 「個人データ情報システムでの処理中に個人データのセキュリティを確保するための組織的および技術的手段の構成と内容の承認について」	X.個人データの可用性の確保（CCT）	2013年2月18日付けロシア連邦FSTEC命令第21号「個人データ情報システムでの処理中に個人データのセキュリティを確保するための組織的および技術的措置の構成および内容の承認」に従って、以下を確保する必要があります。 -技術機器のトラブルのない機能の制御。 -操作上の障害の検出とローカリゼーション。 -失敗した資金を回復するための対策を講じ、それらをテストします。 -個人データのバックアップマシンストレージメディアへの個人データのバックアップ。 -指定された時間間隔内に個人データ（バックアップ）のマシンバックアップメディアから個人データを復元する機能。	個人データ情報システムに1または2のセキュリティレベルが定義されている場合、注文に記載されている要件は必須です。

プロジェクト計画が最終的に作成および開発された後、承認のために会社の経営陣に送信する必要があります。 計画の作業は、経営陣との合意後にのみ開始されるべきです。



注意してください！ 一部の企業では、プロジェクトスポンサーはそれに十分な注意を払っておらず、責任は中間管理者にあります。 これは、利害関係者間のコミュニケーションの問題や、上級管理職へのサポートの減少につながる可能性があります。 この問題は、すべての利害関係者の代表者を含むプロジェクト委員会を作成することで解決できます。 委員会は定期的に会議を開き、問題を解決し、プロジェクトの進捗状況について話し合う必要があります。



ビジネス影響分析



ビジネスインパクト分析-インシデントが会社の主要な活動やプロセスに与える影響を調査できる方法。



この段階では、会社のプロセスの詳細な調査が提供されます。 これを行うために、コンサルタントはプロジェクトエリア内の部門の管理者とのインタビューを実施します。 会話中に、部門の活動に関する情報が要求され、部門が実行するプロセス/機能のリストがコンパイルされます。 さらに、プロセス/機能の詳細な調査のために、プロセスの所有者にインタビューし、ビジネスへの影響の種類（素材、評判）、およびITおよび外部サービスへのプロセスの依存度を決定します。 そして、最大許容停止が決定されます。



最大許容停止-製品の供給および/またはサービスの提供が再開されない場合に、組織の実行可能性が最終的に失われる恐れがある期間。

GOST R ISO / IEC 31010—2011「リスク管理。 リスク評価方法 ''



プロセス/機能の所有者がMAOによって決定された後、IT部門（MAOに基づく）がインジケーターRTO、RPO、SDOを決定します。

- 目標復旧時間（RTO） 。 緊急時にビジネス機能またはリソースの復元が発生する時間。

- 目標復旧ポイント（RPO ）。 リカバリターゲットポイントは、操作が中断された場合に許容されるデータ損失の量を決定します。 たとえば、RPOが15分である場合、最後の15分間のデータ損失は許可されます。

- サービス提供目標（SDO） 。 特定の時点でのサービスの可用性のレベル。



図は、上記のメトリックがどのように決定されるかを示しています。







ビジネスインパクト分析の結果は次のとおりです。

-優先度および関連する相互依存性によってランク付けされた重要なプロセスのリスト。

-重要なプロセスの違反によって引き起こされる登録済みの経済的および生産的影響。

-特定された重要なプロセスに必要なサポートリソース。

-ダウンタイムの可能性のある期間および重要なプロセスと相互接続された情報技術の回復。



注意してください！ 多くの場合、ビジネスプロセスの所有者は、意図的または無意識に回復基準の目標値を過大評価します。これは、分析のゆがみに寄与し、不合理なコストを伴います。 この問題を回避するには、プロジェクトチームおよび利害関係者とともに、会社全体に影響を与えたインシデントのコンテキストでビジネス機能の価値を検討する必要があります。 このアプローチは、回復基準を客観的に決定します。



リスク評価



リスクは、目標に対する不確実性の影響です。

偏差：この記事では、リスク評価の詳細については触れていません。



リスク評価-リスクの特定、リスク分析、リスク評価を含むプロセス。

ISO 73：2009「リスク管理。 辞書»



ビジネス継続性管理のフレームワークでのリスク評価の目的は、企業の混乱につながる可能性のあるイベントとその結果（損害）を特定することです。



リスク評価は以下を提供します

-潜在的な危険と、その結果が会社の目標の達成に与える影響の理解。

-脅威とその原因の理解。

-主要なリスク要因の特定; 会社およびそのシステムの脆弱性。

-リスク治療方法の選択;

-標準の要件への準拠。



リスク評価プロセスは以下で構成されます。

-リスク識別-リスク要素を識別し、それぞれを説明し、それらのリストを編集するプロセス。 リスクの特定の目的は、会社の確立された各目標の達成に影響を与える可能性のあるリスクと脅威のソースのリストをまとめることです。

-リスク分析-リスク情報を調査するプロセス。 リスク分析は、全体的なリスク評価プロセスへの入力を提供し、リスク治療の必要性に関する決定を下し、適切な治療戦略と方法を選択するのに役立ちます。

-リスク評価の比較-リスクの種類とその重要性を判断するために、リスク管理の範囲を決定する際に確立された基準とレベルを比較します。



将来のリスク評価により、ビジネス継続性戦略を合理的に開発でき、その実装に最適なシナリオを決定するのにも役立ちます。



事業継続戦略の策定



継続性の要件を分析した後、可能な技術的および組織的ソリューションを選択して正当化する必要があります。 ソリューションを選択するプロセスでは、施設、技術、情報資産、請負業者、およびパートナーに関する考えられるアクションを詳細に検討する必要があります。 これらの決定は通常、次の目的で選択されます。

-会社の優先活動の保護。

-彼らの効果的な回復;

-インシデントの結果の緩和、対応の開発および予防措置。

注：ソリューションの選択は、復旧のコストとダウンタイムのコストに基づいて行う必要があります。



これらの決定には以下が含まれます。

-「ミラー」プラットフォーム。

-「ホット」サイト。

-「ウォーム」プラットフォーム。

-「コールド」サイト。

-動的な負荷分散のためのプラットフォーム。

-アウトソーシング\契約;

-モバイルプラットフォーム。



余談：上記のソリューションについては、別の記事で詳しく説明します。







上記のソリューションの主な違いは、会社のコストと回復時間です。

注意してください！ ソリューションは、効果的なビジネス継続性戦略の実装を支援します。 ただし、最適なオプションを決定するには、ビジネスへの影響の分析結果とリスク評価の結果に基づいて戦略的な決定を選択する必要があります（このアプローチは、経営陣がビジネス継続性管理プロジェクトへの投資の必要性を正当化するのに役立ちます）。



事業継続計画の開発と実施



計画は、作業の実施の順序、順序、および期限を規定する事前に計画された測定システムです。



ベストプラクティス[1、2、4]に従って、継続性管理計画は次の3つのコンポーネントで構成する必要があります。

1.緊急対応-インシデントが検出されたときに実行する必要がある一連のアクションを決定します。

2.インシデント管理-インシデントの規模を軽減または削減するために必要な方法を定義します。

3.アクティビティの回復-特定のレベルでサービスを復元するために実行する必要がある一連のアクションを決定します。



注：明確にするために、フローチャートやその他のグラフィカルな方法を使用して情報を表示します。



事業継続計画のサンプル構造：



1.はじめに

1.1。 ソース情報

1.2。 計画の境界

1.3。 計画を作成するための前提条件

2.コンセプト

2.1連続性システムの説明

2.2。連続性を回復する手順の説明

2.3役割とその責任

3.アクティベーションプラン

3.1。基準とアクティベーション手順

3.2。関係者への通知手順

3.3。インシデントの評価手順

4.制御

5.リカバリー

5.1連続性回復シーケンス



NISTの専門家がガイド[1]を作成しました。これは、必要なビジネス継続性計画を十分詳細に説明しています。 以下は、各計画（NISTマニュアルで指定されている）と、そのような計画の開発を必要とする標準/ NLAへのリンクを説明する表です。

計画の名前	計画の説明	標準/規範
事業継続計画（BCP） 事業継続計画	インシデント発生時の使用を考慮して開発、要約、更新された一連の文書化された手順であり、企業が重要な重要な活動を設定された許容レベルで継続して実行できるようにすることを目的としています。	ISO 22301「社会保障。 事業継続管理システム」： 8.4.4事業継続計画
運用継続計画（COOP） 事業継続計画	代替サイトでの会社の重要な機能の復元と、30日以内の実装に焦点を当てています。	-
危機コミュニケーション計画 危機コミュニケーション計画	この計画には、緊急時の外部および内部通信の手順と規則が文書化されています。	1994年12月21日の連邦法第68号「自然および技術的緊急事態からの人口と地域の保護について」： 第14条緊急事態から人口と地域を保護する分野の組織の義務
重要インフラ保護計画（CIP） 重要なインフラストラクチャ保護計画	この計画は、国家インフラの主要なリソースとコンポーネントを保護することを目的としています。	2013年1月15日N 31sのロシア連邦大統領令「ロシア連邦の情報リソースに対するコンピューター攻撃の結果を検出、防止、排除するための国家システムの作成について」。
サイバーインシデント対応計画 サイバーインシデント対応計画	ハッカー攻撃、情報システムへの侵入、およびその他のセキュリティ問題に関連するインシデントへの対応手順を説明する計画。	GOST R ISO / IEC TO 18044-2007「情報技術。 セキュリティ方法とツール。 情報セキュリティインシデント管理」; NIST 800-61「コンピューターのセキュリティ。 インシデント処理ガイド。」
災害復旧計画（DRP） 災害復旧計画	事故後の会社のインフラストラクチャの復元を計画します。	ISO 22301「社会保障。 事業継続管理システム」： 8.4.5回復。
情報システム緊急時対応計画（ISCP） 情報システムの緊急計画	クラッシュ後のシステム、ネットワーク、およびコアアプリケーションの回復計画。 この計画は、重要なシステムやアプリケーションごとに作成する必要があります。	-
乗員緊急計画（OEP） 緊急時対応計画	この計画は、緊急時に人員の安全を確保するための手順と避難手順を定義しています。	1994年12月21日の連邦法第68号「自然および技術的性質の緊急事態からの人口および領土の保護について」。 1994年12月21日の連邦法第69号「火災安全に関する」。

上記の文書は会社のニーズに基づいて作成されていますが、実際には次のタイプの計画が最も頻繁に適用されます。

-インシデント対応計画-このタイプの計画には、サイバーインシデント対応計画、情報システムの緊急時対応計画が含まれる場合があります。 この計画は、災害の規模を縮小し、その結果を軽減するのに役立ちます。これにより、時間を節約する機会が得られ、他のタイプの計画をアクティブ化する際の追加の利点が得られます。

-人員の緊急行動計画-1994年12月21日の連邦法第68 68号「自然および技術的緊急事態からの人口と領土の保護」および1994年12月21日の連邦法第69号「火災安全”この計画はすべての企業に必須です。

-障害回復計画-重要な情報システムの回復に焦点を当てています。 このタイプの計画は、ビジネス継続性計画をサポートし、個々のシステムおよびアプリケーションのパフォーマンスを復元することを目的としています。

-事業継続計画-緊急時および緊急後の会社のビジネスプロセスのサポートに重点を置いています。 それは、会社が確立された許容レベルで重要なタイプの活動を実行し続ける可能性を確保することを目的としています。

-危機防止コミュニケーション計画-この計画は、危機的状況における会社の評判を維持するのに役立ちます。 メディア、法執行機関、緊急事態省などとのやり取りの手順を文書化しています。



注意してください！ 事業継続計画の段階では、一部の企業は技術的なソリューションに焦点を当てており、組織的な対策を重視していません。 この点で、組織的な対策の必要性を技術的な対策とともに示す必要があります。 これを行うには、トレーニングセミナー、テスト計画、トレーニング資料が発行されます。



計画のテストとレビュー



会社の活動に影響を及ぼす特定の状況が発生した場合に、計画の運用性を検証するためにテストが実施されます。 テスト計画は、会社のタイプとその目標に基づいて選択されます。



テストは、定量的メトリックを使用してITシステムまたはコンポーネントの正常性を検証する評価ツールです。

NIST Special Publication 800-84「IT計画と機能のためのテスト、トレーニング、および演習プログラムのガイド」



テストの目標は次のとおりです。

-計画の証拠の受領。

-方法論的および技術的サポートの十分性の検証。

-必要なスキルと知識の取得。



テストの目的が決定された後、シナリオが開発され、テスト方法が決定され、経営陣と合意されます。 最も一般的に使用される方法は次のとおりです[2]：

-デスクトップ検証（卓上）;

-模倣（模倣）;

-完全なテスト（完全なビジネス継続性テスト）。



余談：上記のテスト方法については、別の記事で説明します。



テスト後、テストのシナリオと結果、および事業継続計画を改善するための提案を示すレポートが作成されます。



注意してください！ 企業は、目標と財務能力に基づいてテスト方法を選択する必要があります。

注意してください！ 完全なテストは多くの欠点を特定できるため最も効果的ですが、リスクが高いため実際にはほとんど使用されません。 このタイプのテストを使用することを会社が決定した場合、リスクを最小限に抑え、大幅なダウンタイムを防ぐために、パートナーのサポートを依頼するか、請負業者のサービスを使用する必要があります。



メンテナンスおよび更新計画



上記のように、企業の事業継続性の管理は循環的なプロセスです。 これは、計画の形成だけに限定できないことを意味します。計画を毎年、そして時にはより頻繁に、例えば次の場合に維持、更新、改善する必要があります。

1. ITインフラストラクチャの変更。

2.会社の組織構造の変更。

3.法律の変更。

4.テスト中の計画の不備の検出。

計画を最新の状態に保つには、次を実行する必要があります。

-災害復旧レビュー、継続性文書、および関連手順を含む内部監査を実施します。

-計画の実施に関する定期的な実践的トレーニングを実施する。

-ビジネス継続性の問題を会社の変更管理プロセスに統合します。



おわりに



事業継続管理は、企業で適用されるすべての対策を、実際の脅威に適切な全体的で適切な複合体に統合することにより、企業が継続的にサービスを提供し、緊急事態が活動に与える影響を回避し、起こりうる損害を最小限に抑えることができます

この複合施設は、サービスの継続性と製品の生産を確保するために社内で実装する必要がある7つのステージで構成されています。

この記事では、ロシアの現実を参考にして各段階について説明し、このプロジェクトを実装する際に注意すべき点について説明します。



文学

1. ISO 22301社会セキュリティ-ビジネス継続性管理システム-要件

2. GOST R 53647「ビジネス継続性管理」

3. GOST R ISO / IEC 31010-2011。「リスク管理。 リスク評価方法 ''

4. NIST Special Publication 800-34 Rev. 1「連邦情報システムの緊急時対応計画ガイド」

5. NIST Special Publication 800-84「IT計画および機能のためのテスト、トレーニング、および運動プログラムのガイド」

6.ビジネス継続性管理の最終ハンドブック第2版Copyright 2007 John Wiley＆Sons Ltd、

7.事業継続管理危険から会社を守る方法マイケル・ギャラガーピアソンエデュケーションリミテッド2003

8. www.bcmpedia.org/wiki/BCM_Body_of_Knowledge_（BCMBoK ）



Softline Webサイトのプロジェクトに関する情報： services.softline.ru/security/upravleniya-ib



Evgeny Kachurov、コンサルタント、分析部、ソフトライン