雷が鳴るまで、またはContinuity and GOST R 53647.4-2011 / ISO / PAS 22399：2007

数年前、ある会社のモスクワ事務所で、ガス消火システムの減圧がありました。 人間の生命と健康に対する脅威は現実以上のものでした。 緊急事態の結果、1人が死亡し、中毒度の異なる13人が入院し、60人が避難した。 このような脅威は非常に重要です。結局のところ、モスクワ、サンクトペテルブルク、およびその他の都市の数十の管理およびオフィスビルには、まったく同じ消火システムが装備されています。



別の状況が発生する可能性があります。爆発の脅威により銀行が中断します。 アラーム信号は、攻撃者やいじめっ子、または銀行員が部屋で不審なアイテムや荷物を見つけた場合に発信される可能性があります。 それが危険であるかどうかは後で明らかにされますが、この状況での指示の下でのアクションは厳密に必要です。



別の極端なオプション：煙爆弾が組織のオフィスに投げ込まれました。 死傷者なしで行うことができますが、パニックは確実です。 煙の流れが廊下を突き破り、隣の部屋の騒音が気になる人はほとんどいません。 そしてさらに、彼らは職場の雰囲気に貢献しません。 興奮するだけで病気になる人もいるし、どこで薬を手に入れるのかわからない。



死傷者やその他の深刻な結果を避けるために、いくつかの手順を明確に守らなければなりません。 たとえば、組織の領土にいるすべての人に通知し、従業員と訪問者を避難させ、緊急サービスと法執行機関に（場合によってはメディアに）通知し、従業員の親theに連絡して、事件に関する情報を経営陣に伝えます。 同時に、マネージャーや特別に任命された人だけでなく、すべての従業員が危機に対処するスキルを身につけなければなりません。 このような情報は、事業継続の分野で有効な規制法に含まれるべきです。



特定のインシデントが発生した場合の従業員の行動のアルゴリズムは、ビジネスの継続性を確保するはるかに広い領域の一部です。 以下では、国内の既存の標準ISO / PAS 22399：2007（インシデントの準備と運用継続性管理のガイドライン）を分析します：そこで提示されたガイドラインは、起こりうる緊急事態への準備と企業内の対応プロセスの改善に本当に役立ちますか？



残念なことに、この標準にはインシデントの準備に関する情報がほとんどありません。ビジネスの継続性についてより詳しく説明しています。 野心的なタイトルにもかかわらず、多くの質問は未回答のままです。 私たちは私たちの経験に基づいて、自分でそれらに答えようとします。

インシデントの規模を判断する方法は？

ここでは、事前にコンパイルされた質問のリストが役立ちます。

• 死傷者はいますか？ 事件は人間の生命と健康に脅威をもたらしますか？
• 状況はどのくらい速く変化していますか？ 悪化する可能性はありますか？
• ビジネスプロセスの違反または違反の脅威はありますか？
• ビジネスプロセスの違反は長くなる可能性がありますか？
• 損傷が発生する可能性があります/
  
  
  • 会社のイメージと評判。
  • パートナー、顧客または取引先。
  • 組織の重要な条件は？

崩壊がすでに始まっており、確実性がない場合、誰も座ってこれらの質問に答えないことは明らかです。 したがって、損失の種類と範囲ごとの損害の表を事前に作成する価値があります（表1を参照）。



タブ。 1.損傷表の例

損失範囲	経済的損失	制御不能	法令違反による損害	評判被害	人的損失
壊滅的な損失	上から...	生産プロセスの違反、製品の回収、説明文など	規制機関および/または検査機関の予定外の検査、ライセンスの取り消し、法的要件の違反など	否定的なコメント、レビュー、記事、顧客の流出、苦情の数の増加、パートナーの疑いなど。	インシデントの影響、何らかの方法でインシデントの影響、処理、インシデントによる辞任など。
大きな損失	〜から…
デリケートな損失	〜から…
低損失	〜から…

測定可能なパラメーターの範囲を含む表は、イベントの規模について情報に基づいた決定を下すのに役立ちます。

誰がアクションを開始しますか？

緊急事態はそれぞれどこでも発生する可能性があり、どの従業員もその発生について信号を発することができます。 インシデントを管理するには、下から上へ-イニシエーターから意思決定者へのエスカレーションツリー、および上から下へ-経営者が下した決定について従業員に通知するツリーの2つの方向の情報フローを開発する必要があります。 エスカレーションにはいくつかのタイプがあります。

• サポートサービスがある場合、コールはそのオペレーターに送信されます。
• そうでない場合、控訴は事件を発見した人のすぐ上司に向けられます。
• 会社がインシデント管理の原則を実践している場合、確立されたスキームに従って行動する必要があります。 この場合、エスカレーションと警告のスキームを明確にすることは価値があります。

インシデントの境界は時間とともにどのように変化しますか？

インシデントの検出とローカライズが速くなるほど、犠牲者は少なくなります。 時間が経つにつれて、インシデントの境界は拡大します。 たとえば、迅速な復旧では、サーバー障害に気付かないことさえあります。 ただし、長いダウンタイムは内部プロセスを混乱させる可能性があります（たとえば、レポートや支払い注文の準備ができません）。 場合によっては、会社全体に影響を与える可能性があります（規制当局への報告期限、または商品/サービスの支払い期限を守れないと、重大な金銭的損害または会社の評判が損なわれる可能性があります）。



可能な境界は事前に明確に定義する必要があります-インシデント中にスケールのみが決定されます。 何が起こったかを最も確実に説明する境界のオプションが選択されます。 既に述べたように、選択を容易にするために、損傷表を使用できます。

エスカレーションのレベルを制限する方法（ITに障害が発生したときにゼネラルマネージャーを呼び出さないでください）？



会社がエスカレーションの手順を説明する正式な指示を持っている場合、それらは明確に従う必要があります。 あなたは穏やかな環境で書かれたものの矛盾と議論することができますが、反応の速度が重要な場合はそうではありません。



そのような指示はないが、サポートサービスまたはセキュリティサービスがある場合は、それらに何が起こったかを報告する必要があります。 彼らは彼らの責任の領域を理解し、これらの領域における一連の行動を表しています。



最後に、これらのいずれも存在せず、アドバイスが必要な場合は、直属の上司またはその代理に事件を報告してください。 手が届かない場合は、階層を上に移動します。

誰が危機委員会に関与していますか？

危機委員会は、事件に関して迅速な決定を下せる権限と能力を備えていなければなりません。 会社のすべての分野の代表者を含める必要があります。

• 財務ディレクター（機器の緊急購入、追加施設のレンタル、パートナー、顧客、サプライヤーなどとの関係の決済などに資金を割り当てます）;
• 人事部長（負傷した従業員の問題を解決し、追加の従業員を募集し、大量解雇し、従業員の親relativeと連絡を取ります）;
• オペレーションディレクター（産業事故、顧客からの苦情、製品の回収）;
• 事務局長（輸送、物流、供給に関連する問題）;
• 情報通信技術ディレクター。
• 広報担当ディレクター（メディアとの接触、報道機関での事件の報道、ソーシャルネットワーク、インターネット）;
• セキュリティディレクター（物理的および情報）;
• 国家機関との相互作用のディレクター（危機的状況が国家機関による不適切な決定によって引き起こされる場合、彼の参加が決定的かもしれない）

インシデントが発生した場合、誰がすべてのアクションを調整しますか？

インシデントの管理に責任を持つ人は、他のすべての会社の従業員を拘束する決定を行う権限を持っている必要があります。 これは、通常モードでリーダーシップを発揮するものである必要はありません-危機的な状況で管理するには、ストレスへの抵抗と迅速な意思決定能力が必要です。



さまざまなインシデント、権限の説明、従属構造における従業員の相互作用の標準パターンを事前に開発することが重要です。



インシデント評価のオプション（インシデント評価スケール）とは何ですか？



インシデントを評価するには、定性的および定量的な複数のスケールを使用できます。



タブ。 2.定量化：インシデントの影響の頻度と大きさ

	ほとんどない	まれに	しばしば	定期的に
壊滅的な損失	高リスク	危険レベル	許容できないリスクレベル	許容できないリスクレベル
大きな損失	低リスク	高リスク	危険レベル	許容できないリスクレベル
デリケートな損失	無視できるリスク	低リスク	高リスク	危険レベル
低損失	無視できるリスク	無視できるリスク	低リスク	高リスク

タブ。 3.インシデントの定性的評価（これらの用語の詳細な説明は、記事の付録に記載されています）

期間	説明
クラッシュ	ITインフラストラクチャなどのリソースが意図したとおりに機能しない状況。 このような状況の影響は最小限と見なされます。
危機的な状況（重大な事件）	インシデント管理の一環として、割り当てられた時間内に最優先の重大なインシデントを解決できない場合に発生します。
事故	社内のプロセスが期待どおりに実行されないような壊滅的なイベント。 これらのプロセスおよび関連機器の可用性は、割り当てられた期間内に復元できません。
危機	通常の状態とは異なる状況。 予防措置が講じられていますが、この状態はいつでも発生する可能性があり、通常の手続き的または組織的な措置では克服できません。
大災害	企業が時間と空間を制限できず、人々、富、環境に広範な影響を与えるイベント。 会社の存在そのもの、従業員の生命と健康が危険にさらされています。

インシデント管理をサポートする技術ツールは何ですか？

インシデント管理のフレームワーク内で、いくつかの個別のタスクを区別できます。

• 必要なデータの保存：連絡先情報、実行するアクションのリスト、予備サイトおよびオフィスの住所。
• 事件、集合場所、行政命令などに関する大勢の人々への通知。
• インシデント対応ログの維持。
• 会社の通常運用の復旧過程の運用分析（つまり、実行されたアクションの期間が計画されたものとどれだけ異なるか）
• 実行されたアクションの分析、インシデントレポート（開始のタイミング、排除する時間、参加者の数など）。
• 回復プロセスと、このプロセスで発生する問題の解決策/議論に関する情報交換のためのプラットフォームの作成。

IT市場には、これらの課題のほとんどに対処する製品があります。

必要な対応策を開発する方法は？

すべてのインシデントを予測することは不可能ですが、メジャーは主要な領域で解決できます。特定の状況に合わせてそれらを組み合わせて修正することができます。 会社の主な活動は何ですか：

• 材料/サービスの購入;
• 配送;
• 生産と組み立て;
• 顧客への製品とサービスの提供。
• マーケティング
• 技術サポート;
• 生産プロセス;
• 人員、トレーニング;
• ITおよび情報セキュリティ。

通常モードで関連性を維持する方法は？

これまでのところ、定期的なトレーニング/テストほど優れたものは発明されていません。

変更方法 どれくらいの頻度で？ どんな些細なことに注意を払う価値がありますか、計画で考慮に入れるべきものは何ですか？

会社に変更を加えるには、特別な正式な変更管理プロセスが必要です。 可能なバリエーション：組織構造の変化、新しいポジションの出現、技術的解決策の変化、リスクの変化、新製品/サービスの出現。

テストの実施方法

上級管理職が個人的にテストに参加するのに役立ついくつかの議論があります。

• リーダーは問題を解決するために使用されます。 彼らが詳細な正式な計画を実行するために訓練することはありそうにない。 仮想インシデントを排除する際に生じる多くの問題の解決に、彼らはより惹きつけられるでしょう。 計画の代わりに、4つのステップ/質問のあるシートで十分な場合があります。
  
  
  • データ収集-何が起こったのですか？
  • 収集された情報の分析-これはどれですか？
  • アクションプランの開発-今何？
  • 決定に関する部下の通知。
  
  
  
• テストシナリオは、リーダーのタスクのレベルに対応する必要があります。 メディアのページに表示されるVIPクライアントに影響を与えるイベントは、会社の収入レベル、法律の変更、政府の決定に影響します。これは、マネージャーが対処する問題のレベルです。
• リーダーシップを備えたテストでは、適切な準備と適切な予備分析が非常に重要です。 シナリオと動作は現実的でなければなりません。 そのため、実際のインシデントでは、情報が既製で配信されることはありません。 また、シナリオは予期しないものである必要があります。たとえば、火災の場合の対処方法は多かれ少なかれ明確ですが、機密データが漏洩した場合の対処方法はあまり良くありません。 したがって、2番目のオプションを解決する必要があります。
• 他の人だけでなく、危機の間に自分自身をチェックすることが重要です。 「他者が危機に苦しんでいる間、私は待つ」という立場は、リーダーにとって受け入れがたいものです。 そうでなければ、従業員にヒロイズムや単なる誠実な態度を期待するべきではありません。
• トップマネジメントは事実と数字を好む。 彼は2種類のストーリーに興味があります：時間の継続性を確保することに注意を払わなかった企業の難しさ（外部または内部の専門家の助けを借りて）、および十分にテストされた計画がないために廃業した競合企業についてです。

「デスクトップ」監査への参加は、トップマネジメントが自社の会社がインシデントに正しく対応する準備ができていないことを確認するのに十分な場合があります。



現在、テストプロセスで一般従業員の関与を増やすためのいくつかのオプションがあります。

• 参加者が自分の重要性とプロセス自体の重要性を感じることが重要です。 テストは、ビジネス継続性スペシャリストの1つの観点のみに限定しないでください。 非標準的なスタッフの思考を奨励します。
• 各テスト参加者には役割が必要です。 ただのエキストラである以上に退屈なものはありません。 テスト自体に関与していない人のために、他の役割、たとえば、外部のオブザーバー、外部組織の従業員、クライアントなどを選択する必要があります。
• トップマネジメントが事業継続プロジェクトに関与しているとき、人々は奨励されます。 この場合、その重要性が強調されます。
• 上級管理職が継続性ポリシーを明示的にサポートできるように、継続性がスタッフの責任に含まれるようにします。
• テストに対話性を追加します。管理者の予備サイトへの訪問を整理し、マネージャーとその部下がどのような状況で仕事をしなければならないかを示し、生活条件とそこで利用できるコミュニケーション手段を示します。
• テストへの参加の事実は、会社のビジネスを維持および強化する彼の仕事に対して従業員に報酬を与える機会であるとしましょう。

インシデントレポートにはどのような情報を含める必要がありますか？

インシデントレポートには次の情報を含める必要があります。

• 影響を受けるビジネスプロセスのリスト（停止した情報リソース）;
• 事件の理由;
• 対応策の説明（バックアップオフィス/バックアップデータセンターへの移動があったかどうかを含む）;
• 結果を排除するために他にどのような措置を講じるべきか。
• インシデントの発生の責任。
• インシデントの影響の持続時間/情報システムのダウンタイム;
• インシデントの除去の結果に関する結論。これは、将来の再発の回避に役立ちます。
• 欠陥を除去するタスク。
• 修復ログ。

アプリケーション：

障害とは、ITインフラストラクチャなどのリソースが意図したとおりに機能しない状況です。 このような状況の影響は最小限と見なされます。 つまり、損害の量は、会社がその業務を遂行することを妨げるものではありません（または、年間売上高と比較して損害は無視できます）。 ただし、障害が時間内に解決されない場合、事故の規模まで拡大する可能性があります。 障害は、ITの継続性を確保するプロセスではなく、インシデント管理（ディスパッチサービスの作業、2番目と3番目のサポートライン）に関連することに注意してください。



重大な状況（重大なインシデント）は、インシデント管理のフレームワーク内で、割り当てられた時間内に最優先の重大なインシデントを解決できない場合に発生します。



事故は、会社のプロセスが意図したとおりに実行されない破壊的なイベントです。 また、割り当てられた期間内に可用性を復元することはできません。 業務は深刻な影響を受けます。 SLAの実装は不可能になります。 損傷の範囲は、大規模から非常に大規模です。 この事故は、会社の年間収益に容認できないほど大きな悪影響を及ぼします。

事故は危機的な状況、すなわち インシデント管理の通常の手順のままです。 それらを排除するには、ビジネス継続性管理プロセスの一部として特別な反応が必要です。



危機とは、通常の状態とは異なる状況です。 予防措置が講じられていますが、この状態はいつでも発生する可能性があり、通常の手続き的または組織的な措置では克服できません。 危機管理が必要です。 危機を管理するための明確で正式な手順はなく、一般的な推奨事項のみがあります。 危機の典型的な特徴は、その独自性です。



ビジネスプロセスの過程に影響を与える事故は、危機の規模まで拡大する可能性があります。 つまり、危機は、会社の存在または従業員の生命と健康を脅かす生い茂った事故です。 危機は会社に影響を及ぼしますが、環境や公共の安全性に大きな影響は与えません。 危機は、会社自体によって大部分が解消されます。



ビジネスプロセスに直接影響しない危機がいくつかあります。 これらには、経済危機、流動性危機、経営危機、詐欺事件、大規模な製品回収、誘nまたはテロリストの脅威が含まれます。 そのような危機は、原則として、会社自体によって排除することはできず、外部組織（内政機関、規制当局、金融機関）の関与を必要とし、災害の例と考えることができます。



大災害とは、企業が時間と空間を制限できないイベントであり、人々、富、環境に広範な影響を及ぼします。 会社の存在そのもの、従業員の生命と健康が危険にさらされています。 この規模のイベントの結果は、組織自体の努力によって排除することはできません;これには緊急サービスの参加が必要です。



この記事は、Jet Infosystemsのビジネス継続性コンサルタントであるKonstantin Musatovによって作成されました。 建設的なコメントを歓迎します。