トピック3.9 — 事業継続と災害復旧

医療・ケアでは、大規模なシステム停止は、ITの問題である前に患者安全上の出来事です。したがって、システムが止まっている間もケアを提供し続け、それを完全かつ迅速に復旧させる能力は、技術的な脚注ではなく、中核的な臨床能力であり、公的信頼に関わる能力です。

医療・ケアにおいてなぜ重要か#

技術が止まっても、ケアは止まりません。電子患者記録、電子処方のプラットフォーム、検査結果システムが、病院全体で故障したとき、臨床家はエンジニアが作業する間、治療を一時停止することはできません。患者を診続け、薬を処方し、判断を下し続けなければならず、しかも、故障したシステムが通常提供するアレルギーのアラート、用量チェック、既往歴なしに行うことが多いのです。そのため、停止は、ダウンタイムの時間とサービスクレジットだけで測られるのではありません。診断の遅れ、見逃された相互作用、中止された手術、そして目隠しで働くすべての臨床家が抱える追加のリスクで測られます。事業継続は、最悪の事態が起きたとき、ケアを可能な限り安全に保つための規律です。

利害は国家規模であり、十分に記録されています。2017年のWannaCryランサムウェア攻撃は、イングランドのNHSトラストの約3分の1に支障をきたし、何千もの予約と手術の中止を強い、救急車を迂回させ、人々を治療するのに必要なまさにその機器、つまり一部の画像や病理の機器を含めて、職員を締め出しました。NHSに約9,200万ポンドの費用をもたらし、より重要なことに、医療インフラへのサイバー攻撃が、単なるデータセキュリティのインシデントではなく、臨床上の危機として降りかかることを示しました。それ以来、レジリエンスは、サーバールームから取締役会の席へと移り、それは正しいことです。

本トピックは、トピック3.8 — サービスマネジメントとライブ運用の運用の規律を拡張しますが、焦点を日常の運用から大規模な中断、つまり重要なサービスを数時間から数日停止させうる、火災、洪水、サイバー攻撃、サプライヤーの破綻、地域的な停止に移します。トピック1.7 — 情報ガバナンス、データ保護、サイバーセキュリティ（ランサムウェアからの復旧が、いまや中心的な継続性のシナリオだから）、トピック4.0 — 技術アーキテクチャ、クラウド、レガシーシステム（レジリエンスは、後付けではなく設計に組み込まれるものだから）、トピック6.4 — ガバナンスとアシュアランス（誰かが計画を所有し、テストし、責任を負わなければならないから）に、緊密に結びついています。これを正しく行えば、中断は悪い一日になり、誤れば、公的な調査になります。

中核概念#

事業継続と災害復旧。 事業継続計画（BCP）は、中断を伴うインシデントの間と後に、あらかじめ定義された許容水準で、製品やサービス、つまりここでは安全なケアを提供し続ける能力です。ITの災害復旧（DR）は、それらのサービスを支えるシステム、データ、インフラの復元に関する、より狭い技術的なサブセットです。事業継続はより広い約束（「患者は治療され続ける」）であり、災害復旧はその手段の一つ（「結果システムは4時間以内に復旧する」）です。両方が必要であり、復旧したサーバーと復旧したサービスを混同してはなりません。

事業継続マネジメントとビジネスインパクト分析。 事業継続マネジメント（BCM）は、脅威を特定し、組織のレジリエンスを築く、一回限りの文書ではなく継続的な管理プロセスです。その土台がビジネスインパクト分析（BIA）で、各サービスについて、その喪失がどれだけ速く許容できない害を引き起こすか、何に依存しているか、データをどれだけ過去まで失うことに耐えられるかを問う、構造化された評価です。BIAは、臨床判断がエンジニアリングに入る場所です。産科システムと職員向けイントラネットで、「許容できない」が何を意味するかは、技術者だけでなく臨床家が定義しなければなりません。

目標復旧時間と目標復旧時点。 二つの数字が、あらゆる復旧計画の錨となります。目標復旧時間（RTO）は、失敗後にサービスを復旧するための、許容できる最大の時間です。目標復旧時点（RPO）は、時間で表される、許容できるデータ損失の最大量です。15分のRPOは、最後の15分の入力を失うことが最大で許容できることを意味します。重要な臨床システムでは、これらは数分かもしれず、報告用のデータウェアハウスでは、数日かもしれません。サービスごとに、これらを誠実に設定することが、あなたが下す最も有用な継続性の判断です。

バックアップと検証済みの復元。 バックアップは、損失後に元のものを復元できるよう、別の場所に保存されたデータのコピーです。業界の基準は3-2-1ルールです。3つのコピーを、2種類の媒体に、1つはオフサイトに保持し（そしてランサムウェアの時代には、1つは不変またはオフラインで保持）。決定的に、一度も復元したことのないバックアップは、統制ではなく願いです。ランサムウェアは、ネットワークから到達可能なバックアップを日常的に暗号化し、検証されていない復元は、当日に日常的に失敗します。規律は「バックアップしているか」ではなく、「最後にエンドツーエンドで復元に成功したのはいつで、どれだけかかったか」です。

高可用性、冗長性、フェイルオーバー。 高可用性（HA）は、部品の故障を通じてもシステムを動かし続ける設計上の性質で、通常、稼働率の「9」の数で測られます。それは冗長性、つまり重要な部品の意図的な重複と、主系が故障したときの待機系の部品やサイトへの自動切り替えであるフェイルオーバーによって達成されます。高可用性は停止の頻度を減らし、災害復旧は、すり抜けてきたものを扱います。両者は補完的であり、代替ではなく、混同すると危険な隙間が残ります。

単一障害点と重要な依存関係。 単一障害点（SPOF）は、その故障がサービス全体を止める、あらゆる部品です。一本のネットワーク回線、一つの認証サービス、一つのサプライヤー、一つのデータベース、あるいは何かがどう動くかを一人だけが知っている人。SPOFと重要な依存関係（あなたのサービスが、黙って頼っている上流のサービスとサードパーティ）の地図づくりは、レジリエンスの分析の核心です。現代の医療ITでは、依存関係はめったに局所的ではありません。シングルサインオンのサービス、国のスパインへの接続、クラウドのリージョンが、多くのシステムを一度に止めうるのです。

臨床のダウンタイムと事業継続の手順。 医療・ケアには、一般的なITにはない独特の統制があります。臨床のダウンタイム手順、つまりデジタルシステムが利用できないときに、ケアを提供するためのリハーサルされた安全な代替手段（通常は紙）と、システムが戻ったときに、その紙の記録をシステムに突合して戻す再入力のプロセスです。これは、ベッドサイドで具体化された事業継続であり、継続性の計画が最もよく現実に出会う場所です。

ランサムウェアとサイバー復旧。 ランサムウェアは、データを暗号化して支払いを要求し、医療システムにとって、継続性を決定づける脅威となっています。2017年のWannaCryランサムウェア攻撃が基準となる事例であり、サイバー復旧、つまり隔離し、クリーンなバックアップから再構築し、再接続する前に完全性を検証することが、いまやあらゆる本格的な計画で第一級のシナリオである理由です。

継続性の標準。 ISO 22301は、事業継続マネジメントシステムの国際規格です。継続性の能力を構築し監査するための、認められた構造、つまり文脈、リーダーシップ、計画、支援、運用、評価、改善を提供し、正式な認証を求めるかどうかにかかわらず、有用な骨格です。

ベストプラクティス#

1. ITだけでなく、臨床家が所有するビジネスインパクト分析から始める。 すべてのサービスを、失敗したときに引き起こされる臨床上の害と、その害がどれだけ速く耐え難くなるかで順位づけ、それぞれに具体的なRTOとRPOを割り当てます。結果を負う臨床家と運用管理者とともに行ってください。「これなしに、どれだけ安全に運営できるか」は、ケアの問いであり、インフラの問いではないからです。成果物は、有限なレジリエンスの予算を、最初にどこに使うかを教えてくれる、優先順位づけされた一覧です。

2. 重要度に比例してレジリエンスを設計する。 エンジニアリングを影響に合わせます。ミッションクリティカルなシステム（救急部門、患者管理、電子処方）には、高可用性、地理的な冗長性、自動フェイルオーバーが値し、重要度の低いシステムは、より長い復旧と、より単純なバックアップを受け入れられます。重要なシステムの過少なエンジニアリングと、些末なものの過剰な作り込みの両方に抵抗してください。アーキテクチャと継続性は一緒に設計しなければなりません（トピック4.0 — 技術アーキテクチャ、クラウド、レガシーシステム参照）。脆い設計に、後からレジリエンスを付け足すことはできないからです。

3. 単一障害点と隠れた依存関係を、徹底的に探し出す。 各重要サービスの依存関係、つまりネットワーク、認証、DNS、国への接続、電源、冷却、主要なサプライヤー、主要な人を体系的に描き、一つの故障が連鎖する箇所を特定します。シングルサインオンや共通の連携エンジンのような、故障すると多くのシステムを一度に止める共有サービスに、特に注意を払います。描かれていない依存関係は、停止の最中に発見する依存関係です。

4. ランサムウェアを生き延びるようバックアップし、復元をテストして証明する。 3-2-1ルールに従い、少なくとも一つのバックアップのコピーを不変またはオフラインに保ちます。ネットワークに到達した攻撃者が、最後の防衛線を暗号化できないようにするためです。そして、復元を予定に沿ってテストし、RTOに照らして時間を計り、RPOに照らしてデータの完全性を検証します。4時間の目標に対して2日かかる復元は、あなたがまだ気づいていないだけの、失敗した統制です。「最後に成功した完全な復元」は、ただ想定する作業ではなく、報告する指標として扱います。

5. 臨床のダウンタイム手順を書き、資源を割り当て、リハーサルする。 すべての重要な臨床システムについて、停止の間も職員が安全なケアを提供し続けられる、テスト済みの紙（あるいはオフライン）の代替手段と、その後、損失や重複なしにそのデータを再入力する明確なプロセスを維持します。ダウンタイムの書式は、ネットワークとプリンターも止まっているときに手が届く場所に保管します。最前線の職員とリハーサルしてください。フォルダの中にしかない手順は、危機の午前3時に、見つけられず、理解されず、信頼されないからです。

6. 実際のサイトへのフェイルオーバーを備えた、災害復旧計画を維持する。 各重要システムについて、どう復旧するかを正確に文書化します。何がどこで、どの順で動くか、誰が発動を決めるか、そしてその後どうフェイルバックするか。影響がそれを正当化する場合は、本当に別個の復旧サイトやクラウドのリージョンを運営し、それに切り替えられることを証明します。復旧の順序は重要です。システムには、順序を決める依存関係があるからです。テストされていないDRサイトは、高価な想定です。

7. 計画を演習する。一度もテストされていない計画は、失敗する計画である。 定期的に、幅のある演習を行います。シナリオの机上のウォークスルー、技術的なフェイルオーバーのテスト、そして臨床の代替手段を含む、時折の完全なライブのシミュレーション。演習は、古くなった連絡先の一覧、誰も持っていないパスワードを必要とする復旧の手順、職員が紙のプロセスを知っているという想定といった、ギャップを、見つけても安全なうちに明らかにします。教訓を記録し、直し、再テストしてください。フォローアップのない演習は芝居です。

8. 継続性を、サプライヤーとクラウドにまで広げる。 あなたのレジリエンスは、重要なサービスが依存するサードパーティと同じだけ強いため、継続性を契約とアシュアランスの問題にします。サプライヤーに、自らのRTO/RPO、DRテスト、サイバー復旧のエビデンスを示すよう求め、クラウドプロバイダーの責任共有モデルを理解してください。アベイラビリティゾーンとリージョンは、一部の故障から守りますが、自分たちが所有する設定ミスやアカウントの侵害からは守りません。サプライヤーの失敗そのもの、主要なサプライヤーがランサムウェアに襲われるシナリオを含めて、計画します（トピック6.3 — 調達と商事参照）。

9. 認められた標準を採用し、継続性をガバナンスの下に置く。 ISO 22301を構造化された骨格として、NHSと国のガイダンスをセクター向けの上乗せとして使い、事業継続について、取締役会に報告する、名前のある経営幹部に説明責任を持たせます。誰も所有せず、資金を出さず、レビューしない継続性は、インシデントがそれを明らかにするまで、静かに劣化します。アシュアランスの枠組み（トピック6.4 — ガバナンスとアシュアランス参照）に結びつけ、計画が、危機の中で再発見されるのではなく、日常として維持され、テストされ、改善されるようにします。

チームで話し合うための問い#

1. 重要な臨床システムそれぞれについて、臨床家と実際にどんなRTOとRPOに合意したか。そして、現在それを満たせるか。 この問いは、願望と能力の間のギャップを表に出させます。多くの組織は、明示的な復旧目標を設定したことがないか、臨床の入力なしにITで設定しているため、「許容できる」ダウンタイムは、実際には、現在のアーキテクチャがたまたま提供するものにすぎません。臨床上のニーズ（救急システムは数分）が、バックアップとDRが実際に達成できること（おそらく1日）と衝突する箇所を議論してください。そのギャップは、名指しするかどうかにかかわらず、あなたが抱える、管理されていない臨床リスクだからです。直近の実際の、あるいはテストされた復旧を具体的に見ます。どれだけかかったか、どれだけのデータを失うところだったか、これが安全だと誰が承認したか。良い誠実な答えは、システムごとの具体的な数字を挙げ、まだ満たせない箇所を認め、それぞれのギャップを、心地よい沈黙ではなく、資金の付いた行動に変えます。

2. もし今夜、ランサムウェアが中核システムとバックアップを暗号化したら、明日、患者をどう安全に保つか。そして、完全に復旧するまでどれだけかかるか。 これは実際の医療システムを襲ったシナリオであり、保証ではなく、具体的で怯まない検討に値します。両方の半分を誠実に探ってください。直近の臨床の継続性（病院全体を数日間紙で運営できるほど、ダウンタイム手順がリハーサルされ、資源が割り当てられ、信頼されているか）と、技術的な復旧（バックアップは不変でオフラインか、クリーンなコピーからの再構築をテストしたか、復旧の順序を知っているか）。不都合な依存関係を浮かび上がらせます。シングルサインオン、連携エンジン、主要なサプライヤーが止まったら、ほかにどれだけが一緒に落ちるか。誰が重大インシデントを宣言し、誰が職員、患者、メディアと話し、あるシステムを再接続しても安全だと誰が決めるかを考えます。強い答えは、名前のある役割とテスト済みの復元を伴う、リハーサルされた計画を説明し、弱い答えは、バックアップは大丈夫で、紙のプロセスは単に機能すると想定します。

3. 継続性と災害復旧の計画を、最後にエンドツーエンドでテストしたのはいつか。そして、何を学んだか。 ここでの目的は、生きた能力と、棚の上の文書を区別することです。演習されていない計画は、検証されておらず、検証されていない計画は、現実との接触で日常的に失敗します。連絡先の一覧が古く、復旧の手順が誰も持っていない認証情報を必要とし、ダウンタイムの書式が、止まっているシステムに保管されている。実際に行っている演習の幅を議論してください。机上のシナリオ、技術的なフェイルオーバーのテスト、そしてサーバーの復元だけでなく、最前線の臨床の代替手段を含む完全なシミュレーション。過去のインシデントや演習からの教訓が、実際に直されて再テストされたのか、記録されて忘れられたのかを探ります。良い答えは、定期的な演習のカレンダー、見つかり解消されたギャップのエビデンス、そして計画のどの部分がまだ証明されていないかについての誠実さを示します。

4. 重要な依存関係のうち、私たちが制御していないものはどれか。そして、そのうち一つが故障する日のための計画は何か。 現代の医療ITは、めったに単独では失敗せず、その下のサービスとサプライヤーを通じて失敗します。チームを、自分たちが所有するシステムを越えて、単に頼っているものへと押し進めてください。国のスパインへの接続、シングルサインオンのプロバイダー、クラウドのリージョン、連携エンジン、外部委託されたデータセンター、復旧の鍵を握るマネージドサービスのパートナー。それぞれについて、それが1日消えたらケアに何が起きるか、契約が、サードパーティに、自分たちの臨床上のニーズに見合う復旧目標を義務づけているか、入札書の安心させる一段落ではなく、彼らのDRテストのエビデンスを見たことがあるかを問います。不都合な真実は、失敗が他者の環境にあるために、値付けしたことのない残存リスクを抱えうることです。誠実な答えは、各重要サービスの具体的な外部依存関係を挙げ、契約上保証されているものと、単に信頼されているものを述べ、レジリエントにできない依存関係には、手動であっても代替手段を特定します。

5. 大規模インシデントが襲ったとき、誰が何を決め、誰が誰に伝えるのか。そして、当日より前に、全員が自分の役割を知っているか。 継続性は、バックアップと同じくらい、指揮と連絡に関するものであり、リハーサルされた計画と即興の混沌が分かれるのはここです。人間の振り付けを検討してください。誰が重大インシデントを宣言し、計画を発動する権限を持つか、誰が運用の対応を指揮し、あるシステムを再接続して安全だと誰が決め、誰が職員、患者、報道、規制当局、そしてサイバー攻撃では法執行機関と話すか。インシデントの最中の自分たちのツールの故障も考えてください。停止が、調整に通常使うメール、電話帳、イントラネットを落とすかもしれないからです。素早く動くことと安全に動くことの緊張、そして国民へのメッセージを誤ることの評判上の利害を浮かび上がらせます。強い答えは、名前のある代理の役割を備えたテスト済みのインシデント指揮の構造、帯域外の連絡チャネル、事前に合意されたメッセージのテンプレートを挙げ、弱い答えは、適切な人々が単に集まり、何をすべきか知っていると想定します。

6. 2年間何も問題が起きていないとき、継続性にどう資金を出し、所有し、生かし続けるのか。 レジリエンスは、インシデントとインシデントの間の隙間で静かに劣化し、この問いは、それが腐るのを防ぐ、組織の規律に向き合います。継続性は、目に見える切迫した臨床とデジタルの優先事項と、お金と注意を奪い合い、未成熟だが運の良い組織は、そうでなくなる日まで、成熟した組織と区別がつきません。経営レベルで誰が継続性を本当に所有しているか、借り物の善意ではなく資金の付いた費目があるか、システムと職員が変わるなかで、計画、依存関係の地図、連絡先の一覧がどう最新に保たれるかを議論してください。取締役会が実際に見ているのは何か、つまり検証されたアシュアランスと誠実なギャップなのか、緑の評価と保管された文書なのかを問います。良い答えは、名前のある説明責任、継続的な予算と演習のカレンダー、そして維持され、テストされた継続性を、次の危機で再発見されるものではなく日常として扱う、ガバナンスのリズムを説明します。

実践例：医療・ケアの事例#

Meadowvale NHS Foundation Trustは、600床の急性期病院を運営しています。ある火曜日の朝、職員は、電子患者記録（EPR）、病理、放射線のシステムが、身代金要求のメッセージでロックされているのを発見します。攻撃者は10日前に、サプライヤーのリモートアクセスのアカウントから侵入していました。最高情報責任者は1時間以内に重大インシデントを宣言し、トラストの事業継続計画が発動します。

トラストはビジネスインパクト分析を行っていたため、EPRと病理が最も重要度の高いシステムで、合意された復旧目標があることを知っており、ダウンタイム手順は前年の秋にリハーサルされていました。病棟は、紙の薬剤チャートと、あらかじめ印刷された観察の書式に切り替えます。共有ドライブではなく、各病棟の物理的なキャビネットに意図的に保管されていたものです。救急部門は、紙の経路に戻ります。その週の予定手術は延期され、患者に伝えられ、救急車は最も忙しい時間帯を避けて迂回されます。ケアは、劣化しながらも安全に続きます。職員が、こうした働き方を練習していたからです。

復旧は、復元より難しいものです。セキュリティチームは、拡散を止めるためにネットワークを隔離し、そのあと、攻撃者が到達できなかったコピーである、オフラインで保持された不変のバックアップから、重要なシステムを再構築します。それらのバックアップは四半期ごとに復元テストされていたため、チームはプロセスが機能し、おおよそどれだけかかるかを知っていました。EPRは8時間のRTO以内に戻り、より複雑な依存関係を持つ病理は2日かかります。15分のRPOは、短い時間のデータしか失われなかったことを意味し、職員は、管理された再入力のプロセスの下で、紙の記録をシステムに突合して戻し、薬剤と結果を再確認します。

振り返りで、トラストは本物のギャップを見つけます。シングルサインオンが単一障害点で、復旧中の臨床家のアクセスを遅らせたこと、そしてサプライヤーのリモートアクセスが、トラスト自身の継続性のアシュアランスの対象外だったことです。両方が、責任者と期日を付けて、取締役会のリスク登録簿に載り、次の完全な演習が予定されます。悪い一週間でしたが、破局ではありませんでした。計画が存在し、資源が割り当てられ、テストされていたからです。

セクター別の視点#

スタートアップ#

デジタルヘルスのスタートアップが、余分なデータセンターを持つことはまれなため、その継続性戦略は、ほぼ完全にクラウドネイティブのレジリエンスと、規律あるバックアップに頼ります。アベイラビリティゾーンをまたぐ、高可用性を組み込んだマネージドサービスを使い、ランサムウェアと侵害されたクラウドアカウントの両方を生き延びられるよう、不変でアカウント外のコピーでバックアップを自動化し、クリーンな環境への復元を実際にリハーサルします。顧客であるNHSトラストや統合ケアシステムは、DTACのような枠組みとサプライヤーのアシュアランスを通じて、RTO、RPO、DRテストのエビデンスを、ますます求めるため、継続性を、間接費ではなく、販売上の資産として扱ってください。小さなサプライヤーにとっての存続に関わるリスクは、一つのインシデント、あるいはデプロイを一人だけが理解している創業者が、単一障害点になることです。

小規模事業者#

確立した小規模の提供者、つまり一般診療所、地域薬局、介護施設、訪問介護事業所、単独拠点のクリニックは、停止を通じて患者を安全に保つ、大きなトラストと同じ義務を負いますが、実際の患者、乏しい資金、そして専任のIT職員がまったくいないことも多くあります。ここでの継続性は、意図的に実利的です。どの一つか二つのシステム（臨床記録、調剤やeMARのシステム）が、故障したら安全なケアを止めるかを知り、システムのサプライヤーに、自らのバックアップ、RTO、RPOのエビデンスを示すよう求め、画面が暗くなったときに職員が手にできる場所に、紙の薬剤チャート、主要な電話番号、最近の患者リストといった、簡単な印刷したダウンタイムのパックを保ちます。診療所マネージャーや一人のIT契約者が、しばしば設定を理解する唯一の人であるため、復旧の手順を書き留め、二人目がそれに従えるようにします。ランサムウェアと壊れたブロードバンド回線が日常的な脅威であるため、オフラインまたは不変のバックアップのコピーと、代替の働き方は、負担も運営もできない凝ったDRサイトより重要です。

大企業#

大規模なNHSトラスト、統合ケアシステム、大手ヘルステックのベンダーは、広がった相互依存する環境を抱え、最も難しい問題は、単一のシステムではなく、依存関係と共有サービスの地図づくりです。ISO 22301に沿った正式なBCMプログラム、維持された依存関係の地図、重要システムのためのDRサイトやリージョン、そして臨床の代替手段を含む、ローリングの演習のカレンダーに投資してください。規模は、SPOFが、ID、連携エンジン、ネットワークのコアといった、故障すると数十のシステムに連鎖する共有サービスであることが多いことを意味します。ガバナンスが束縛する制約です。多くのチームとサプライヤーがいるなかで、名前のある経営幹部が所有し、取締役会が書類上の計画ではなく、検証されたアシュアランスをレビューして初めて、継続性は保たれます。

政府#

NHS England、地方分権された保健省、UKHSAといった国の機関は、国民と、システム全体の規模でのレジリエンスを考えなければなりません。国のサービスや広く使われるサプライヤーの失敗は、それ自体がセクター全体の継続性の出来事だからです。標準と期待（復旧目標、サイバー復旧、演習の義務化）を定め、共有の保護的な能力に資金を出し、国規模のランサムウェアの攻撃といった大規模インシデントに対する、セクター全体の対応を調整します。WannaCryへの対応が国の政策を作り変えたのは、まさに、影響が何百もの組織に一度にまたがり、共通の弱点を露呈したからです。ここでの説明責任は、公的で議会に対するものであり、既知のリスクについての透明性と、準備状況の誠実な報告は、技術的な統制そのものと同じくらい重要です。

よくある失敗パターン#

• 一度も復元されたことのないバックアップ。 「毎晩バックアップしている」と「復旧できる」を混同する。検証されていない復元は、日常的に失敗するか、RTOを超過する。バックアップの完了ではなく、エンドツーエンドの復元の成功を測定・報告する。
• ランサムウェアが到達できるバックアップ。 すべてのバックアップをオンラインでネットワークに接続したままにし、攻撃者が本番と一緒に暗号化してしまう。少なくとも一つの不変またはオフラインのコピーを保持する。
• サービスではなくサーバーを守るDR。 データベースは復元するが、それを使える臨床サービスにする依存関係、連携、アクセスは復元しない。サービス全体を、依存関係の順序で復旧し、テストする。
• 紙についての紙の中にしかないダウンタイム手順。 リハーサルされず、故障するシステムに保管され、最前線の職員に知られていない代替計画。ケアが実際に行われる場所でリハーサルする。
• 描かれていない依存関係と共有のSPOF。 シングルサインオン、DNS、あるいは一つのサプライヤーが、すべてを支えていたと、停止の最中に発見する。インシデントの最中ではなく、その前に依存関係を描く。
• 監査人のために書かれ、一度も演習されなかった計画。 テストされないまま、必要とされる日まで劣化していく、コンプライアンス文書としての継続性。一度もテストされていない計画は、失敗する計画である。
• サプライヤーとクラウドの継続性の無視。 エビデンスなしにサードパーティがレジリエントだと想定し、責任共有モデルを忘れる。継続性を契約上のものとし、保証する。

成熟度モデル#

チェックリスト#

• 臨床家とともに所有するビジネスインパクト分析が、すべてのサービスを順位づけ、各重要システムに明示的なRTOとRPOを設定している。
• 重要システムに、その臨床上の重要度に比例した、高可用性と冗長性がある。
• 単一障害点と重要な依存関係（共有サービスとサプライヤーを含む）が描かれ、軽減されている。
• バックアップが3-2-1ルールに従い、ランサムウェアが到達できない、少なくとも一つの不変またはオフラインのコピーがある。
• 復元が予定に沿ってテストされ、RTO/RPOに照らして時間が測られ、「最後に成功した復元」が指標として報告されている。
• すべての重要な臨床システムに、リハーサルされたダウンタイム手順と、管理されたデータの再入力のプロセスがある。
• 災害復旧計画が、復旧の手順、順序、決定の権限、フェイルバックを定義し、DRサイト/リージョンがテストされている。
• サイバー復旧のシナリオ（隔離し、クリーンなバックアップから再構築し、検証し、再接続する）が文書化され、演習されている。
• サプライヤーとクラウドの継続性が、責任共有モデルを含め、契約上求められ、エビデンスが示され、保証されている。
• 継続性がISO 22301に沿い、名前のある経営幹部に所有され、カレンダーに沿って演習され、取締役会に報告されている。

主要な情報源#

• NHS England — Business Continuity Management Toolkitと、Emergency Preparedness, Resilience and Response (EPRR) FrameworkおよびCore Standards。
• National Cyber Security Centre (NCSC) — オフライン/不変のバックアップ、ランサムウェアの軽減、インシデント対応のガイダンス。
• ISO 22301:2019 — Security and resilience — Business continuity management systems — Requirements（International Organization for Standardization）。
• ISO/IEC 27031 — Guidelines for information and communication technology readiness for business continuity。
• Business Continuity Institute (BCI) — Good Practice Guidelines。
• National Audit Office — Investigation: WannaCry cyber attack and the NHS（2017年）と、保健省の教訓のレビュー。
• NHS England / Data Security and Protection Toolkit (DSPT) — 事業継続とインシデント対応を含むデータセキュリティ標準。
• GOV.UK Service Manual — 稼働中のサービスのレジリエンス、監視、復旧のガイダンス。

参考文献#

1. Business continuity planning — Wikipedia — https://en.wikipedia.org/wiki/Business_continuity_planning
2. IT disaster recovery — Wikipedia — https://en.wikipedia.org/wiki/IT_disaster_recovery
3. ISO 22301 — Wikipedia — https://en.wikipedia.org/wiki/ISO_22301
4. Backup — Wikipedia — https://en.wikipedia.org/wiki/Backup
5. High availability — Wikipedia — https://en.wikipedia.org/wiki/High_availability
6. Redundancy (engineering) — Wikipedia — https://en.wikipedia.org/wiki/Redundancy_(engineering)
7. Failover — Wikipedia — https://en.wikipedia.org/wiki/Failover
8. Single point of failure — Wikipedia — https://en.wikipedia.org/wiki/Single_point_of_failure
9. Ransomware — Wikipedia — https://en.wikipedia.org/wiki/Ransomware
10. WannaCry ransomware attack — Wikipedia — https://en.wikipedia.org/wiki/WannaCry_ransomware_attack
11. ISO 22301:2019 Security and resilience — Business continuity management systems — Requirements — International Organization for Standardization — https://www.iso.org/standard/75106.html
12. Investigation: WannaCry cyber attack and the NHS — National Audit Office — https://www.nao.org.uk/reports/investigation-wannacry-cyber-attack-and-the-nhs/
13. Emergency Preparedness, Resilience and Response (EPRR) — NHS England — https://www.england.nhs.uk/ourwork/eprr/
14. Offline backups in an online world — National Cyber Security Centre — https://www.ncsc.gov.uk/blog-post/offline-backups-in-an-online-world
15. Data Security and Protection Toolkit — NHS England — https://www.dsptoolkit.nhs.uk/