事業継続計画（BCP）とISMSの接続

情報セキュリティの3要素のうち、実務でもっとも軽く扱われるのが可用性です。リスクアセスメントの台帳を開くと、機密性のリスクが大半を占め、可用性は「クラウド障害」「災害」の2行で終わっている——よくある構図です。

しかしヘルスケア企業にとって、可用性は最も事業に近いリスクです。電子カルテが止まれば外来が止まり、患者が待ち、診療報酬の請求が滞る。 情報が漏れていなくても、止まった時点で顧客医療機関の業務は成立しません。そして、止まった時間の長さがそのまま契約上の責任とレピュテーションに直結します。

一方で、BCPを「災害対策」として総務部が別途作っており、ISMSの文書体系とつながっていない企業も多く見られます。この分断があると、サイバー攻撃による停止という、現実に最も起こりやすいシナリオが、どちらの計画にも入らないという事態が生じます。

本記事では、ISMSの可用性要求とBCPの接続、RTO/RPOの決め方、ISMSの範囲で作るBCPと全社BCPの関係、そして訓練の記録を扱います。運用プロセスは 箇条8 運用、該当する管理策は 組織的管理策37項目の読み方、規格全体は ISMS（ISO/IEC 27001）とは をご覧ください。

免責：本記事は一般的な情報提供です。規格の要求事項の解釈、認定・認証の取扱いは規格本文および認定機関・審査機関の公表資料が正本です。実際の対応はそれらに基づいて行ってください。

なぜここでつまずくのか

可用性のリスクが粗い

「クラウド障害でサービスが止まる」という1行では、対応策を導けません。実際の停止要因は、基盤障害・アプリケーションの不具合・データベースの破損・DDoS・ランサムウェア・鍵の失効・証明書の期限切れ・設定変更の失敗・委託先の停止と、性質が大きく異なります。復旧の手段も所要時間も異なるため、要因ごとに分けなければ計画が書けません。

RTO/RPOが「気持ち」で決まっている

「目標復旧時間は4時間」と書いてあるが、その4時間の根拠がない。技術的に4時間で戻せるのか、顧客との契約上4時間なのか、4時間止まったときの損害がどれだけかを検討したのか。根拠のないRTOは、達成できなかったときに説明ができません。

BCPが2つ存在して整合していない

総務部が作った全社BCP（地震・火災・パンデミック中心）と、情報システム部が作ったシステム復旧手順が、別々の文書として存在し、参照関係がない。招集体制も連絡網も別々。実際の事態では、どちらを開くべきか誰も判断できません。

訓練が「バックアップからの復元テスト」で止まっている

技術的な復元テストは重要ですが、それは訓練の一部でしかありません。誰が停止を判断し、誰が顧客医療機関に連絡し、復旧をいつ宣言するのか——この判断の訓練がなければ、実際の停止時に時間を失います。

顧客医療機関側の代替手段を知らない

自社サービスが止まったとき、顧客の病院・クリニックがどう診療を継続するのかを把握していない。紙の運用に切り替えるのか、復旧後のデータ入力をどうするのか。ここを知らないと、復旧の優先順位を誤ります。

何を決めるのか

事業影響度分析（BIA）から始める

BCPの出発点は、どの業務・システムが、どれだけ止まると、何が起きるかの分析です。これを飛ばしてRTOを決めると、根拠のない数字になります。

分析の単位は、サービス・機能が扱いやすい単位です。

表の右端の「判断根拠」の列が最も重要です。 ここが書かれていないと、RTOの設定が説明できません。

RTO/RPOの決め方

RTOとRPOは、技術部門が単独で決める数字ではありません。 RPOを1時間にするか24時間にするかは、失われたデータの再入力コストを負担する業務側・顧客側の判断です。逆に、RPOを短くすればインフラ費用が上がります。この費用と業務影響のトレードオフを、経営層が判断する構造にする必要があります。決定は マネジメントレビューの進め方と議事録 の議題として扱うのが自然です。

現実的でない目標を書かないことも重要です。「RTO 1時間」と書きながら、実際にはバックアップからの復元に6時間かかる構成であれば、その計画は審査でも実務でも意味を持ちません。目標と現状に差があるなら、その差を改善課題として記録し、期限を付けるほうが誠実で、かつ評価されます。

ISMSの範囲で作るBCPと全社BCPの関係

この整理が、実務でもっとも混乱する点です。両者は目的も範囲も異なります。

ISMSが求めているのは、全社BCPを作ることではありません。 求められているのは、事態が発生したときにも情報セキュリティを維持すること、そしてICTが事業継続の要求を満たせるよう備えることです。ここを取り違えて、ISMSのために立派な全社BCPを新規に作ろうとすると、工数が膨らみ、かつ運用されない文書ができあがります。

実務的な解は次のとおりです。

1. 全社BCPが既にあるなら、それを上位文書として参照する。 ISMS側では、全社BCPの中の情報システムに関する部分を担う位置づけを明記する
2. 全社BCPがないなら、無理に作らない。 ISMSの範囲で、重要な情報システムの継続計画（システムごとの復旧手順とRTO/RPO）を作る
3. どちらの場合も、招集体制と連絡網を一本化する。 事態の原因が地震かサイバー攻撃かで別の名簿を開くのは非現実的
4. サイバー攻撃を明示的なシナリオとして両方に入れる。 ここが分断の起きやすい箇所

「事態発生時にも情報セキュリティを維持する」という要求は、見落とされがちですが重要です。 復旧を急ぐあまり、平時なら許されない運用（管理者権限の一時的な広範な付与、私物端末の使用、暗号化されていない経路でのデータ移送）が行われることは現実にあります。緊急時に何を許容し、事後に何を確認するかを、あらかじめ決めておく必要があります。

実務の手順

1. 停止要因を列挙する

抽象的な「災害」ではなく、具体的な要因で分けます。

ランサムウェアを他と同列に置かないことが重要です。 通常の障害と違い、バックアップ自体が暗号化されている可能性があり、また復旧前に侵害範囲の特定が必要です。「バックアップがあるから復旧できる」という前提が崩れる唯一のシナリオであり、**バックアップの隔離（オフライン保管、書き換え不可の保管）**が対策の核になります。医療機関側の対策は 医療機関のランサムウェア対策、バックアップ設計は 医療機関のバックアップ設計｜3-2-1ルール で扱います。

2. 対策を設計する

縮退運転の設計は、費用対効果が高い割に見落とされがちです。 書き込みができなくても参照だけ提供できれば、顧客医療機関は過去の診療記録を見ながら診療を継続できます。全機能の復旧を待つより、はるかに影響が小さくなります。

3. 復旧手順を書く

復旧手順は、平時に読める文書ではなく、緊急時に使える文書として書きます。

• 手順の先頭に判定表を置く（どの状況ならどの手順へ進むか）
• 各ステップに想定所要時間を書く（実際との差が改善の材料になる）
• 判断が必要な箇所を明示し、判断者の役職を書く
• 実行に必要な認証情報の在り処（値そのものは書かない）を示す
• 前提の依存関係（この手順はDNSが動いていることを前提とする、等）を書く

4. 顧客医療機関への連絡を手順に含める

これがヘルスケア企業に固有の工程です。停止の連絡は、復旧の見通しが立つ前に行う必要があります。医療機関は、復旧を待つか紙運用に切り替えるかを、早い段階で判断しなければならないためです。

第一報に含めるべき内容：

「推奨する暫定運用」を示せる企業は多くありません。 しかし顧客医療機関にとっては、これが最も必要な情報です。平時のうちに、主要な停止シナリオごとの暫定運用案を作っておくと、初動の質が大きく変わります。

インシデントとしての社内フローは インシデント対応手順の作り方（事業者） と接続させ、可用性インシデントも同じ報告経路に乗せます。

5. 訓練を実施し、記録を残す

訓練には段階があります。すべてを毎年やる必要はなく、組み合わせて年間計画に落とします。

訓練の記録に残すべき項目は次のとおりです。この記録は審査で確認されます。

「うまくいかなかったこと」が書かれていない訓練記録は、価値が低いだけでなく、審査で疑われます。 完璧に成功した訓練記録が毎年並んでいる状態は、訓練が形式的であることの徴候と受け取られます。見つかった問題は 是正処置報告書の書き方 の様式で追跡します。

よくある失敗

バックアップを取っているが復元したことがない

もっとも多く、もっとも危険な失敗です。バックアップジョブが成功していても、復元して使える状態に戻せるかは別問題です。世代が壊れている、復元手順が分からない、復元先の環境がない、復元に想定の5倍の時間がかかる——実際に試して初めて判明します。復元テストを定期タスクとして固定してください。

バックアップが本番と同じ権限空間にある

ランサムウェアの被害が拡大するのは、ほぼこの構造が原因です。本番環境の管理者権限が奪われれば、同じ権限で参照できるバックアップも消されます。別の認証空間、書き換え不可の保管、オフラインコピーのいずれかを必ず持ちます。

RTO/RPOがシステム全体で1つしかない

機能によって許容できる停止時間は違います。全機能に一律のRTOを設定すると、過剰投資か過少投資のどちらかになります。機能単位で段階を付ける設計にします。

委託先・外部サービスの停止が計画に入っていない

自社のシステムは無事でも、認証基盤や決済サービスが止まればサービスは使えません。依存する外部サービスを一覧化し、それぞれの停止時の影響と代替手段を検討します。 委託先の可用性要求は契約にも書き込みます（外部委託先管理｜チェックシートと契約条項）。

連絡網が自社のメール・チャットに依存している

自社のIT基盤が停止する事態では、その基盤を使った連絡ができません。**代替連絡手段（個人携帯の連絡網、外部のメッセージング、電話ツリー）**を用意し、年1回は疎通を確認します。個人情報の取扱いに配慮した形で整備してください。

復旧宣言の基準がない

「復旧した」と顧客に伝えた後で再発するのは、信頼を大きく損ないます。復旧判定の基準（主要機能の動作確認項目、一定時間の安定稼働、再感染がないことの確認）を事前に定め、判定者を決めておきます。

訓練が技術部門だけで完結している

停止時の判断・連絡・顧客対応は、経営層と営業・サポート部門が関わります。技術部門以外を含めた演習を年1回は行わないと、実際の停止時に連携が崩れます。

ヘルスケア企業の例

医療SaaS事業者の場合

固有の論点は、診療時間帯という制約です。一般的なBtoB SaaSなら「深夜にメンテナンス」で済みますが、医療機関の診療時間は施設ごとに異なり、休日診療・救急対応を行う施設もあります。顧客ごとの診療時間を把握し、影響の小さい時間帯を判断できる情報を平時に持っておくことが、復旧作業の設計に直結します。

もう一つは、復旧後のデータ整合です。停止中に紙で記録された診療内容を、復旧後にシステムへ入力する作業が発生します。この入力をどう支援するか（一括取り込み、入力期限の扱い、監査証跡上の記録方法）を設計しておくと、顧客の負担が大きく変わります。可用性を含む設計の考え方は既存記事の 医療システムのセキュリティ・バイ・デザイン も参考になります。

PHR事業者の場合

利用者が自分のデータにアクセスできない状態が続くことの影響を評価します。診療とは異なり緊急性は低い場合が多いですが、服薬記録や検査値を医療機関受診時に見せる用途がある場合、影響は診療に直結します。用途ごとに影響を分けて評価することが必要です。

治験・臨床研究システムを扱う企業の場合

データの完全性と監査証跡の連続性が、RTOより重視される場面があります。停止中の操作をどう記録するか、復旧後にどう追跡可能性を担保するか。急いで復旧して記録が欠落するより、時間をかけても証跡を保つほうが適切な場合があります。復旧の優先順位に、完全性の観点を明示的に入れる設計が必要です。

SaMDを扱う企業の場合

停止が患者への危害につながりうるかの評価が加わります。診断や治療の判断に直接関わる機能であれば、停止は安全性の問題として扱われ、ISMS側のBCPだけでは足りません。製品のリスクマネジメント（ISO 14971）側の評価と接続させ、必要なら製品仕様としての代替手段（オフライン動作、フェイルセーフ）を設計します。関係は SaMDとISMS・QMS（ISO 13485）の関係 をご覧ください。

顧客医療機関のBCPとの関係

自社の復旧計画は、顧客医療機関のBCPの一部として機能します。顧客が自らのサイバーBCPを作る際、事業者側の復旧目標・代替手段・連絡体制の情報が必要になります。この情報をまとめた資料を平時に用意しておくと、顧客の計画策定を支援でき、同時に商談上の差別化にもなります。医療機関側の視点は サイバー攻撃を想定したBCP と SLAと責任分界の書き方、責任の切り分けは 責任分界点の決め方｜医療機関と事業者 で扱います。

まとめ

1. 可用性はヘルスケア企業にとって最も事業に近いリスク。台帳で2行に圧縮せず、停止要因ごとに分けて評価する
2. RTO/RPOはBIAから導く。根拠のない数字は、達成できなかったときに説明ができない。決定は経営層の判断として記録する
3. ISMSが求めるのは全社BCPの作成ではなく、事態発生時の情報セキュリティの維持とICTの備え。既存の全社BCPがあるなら上位文書として参照する
4. ランサムウェアは他の停止要因と別に扱う。バックアップ自体が失われる唯一のシナリオであり、隔離された保管が対策の核になる
5. 顧客医療機関への第一報には、次の連絡予定時刻と推奨する暫定運用を必ず含める
6. 訓練記録には実測値とうまくいかなかったことを残す。成功記録だけが並ぶ訓練は形式的と見なされる

可用性インシデントの社内フローは インシデント対応手順の作り方（事業者）、外部依存の管理は 外部委託先管理｜チェックシートと契約条項、訓練で見つかった不備の是正は 是正処置報告書の書き方 で扱います。RTO/RPOの投資判断は マネジメントレビューの進め方と議事録 の議題として記録してください。

ポテックは、ヘルスケア領域に特化してISMS認証取得と運用を支援しています。医療システムの停止が顧客の診療に何をもたらすかを前提にした事業継続の設計は、汎用のBCPひな形では組み立てられません。支援内容と料金は ISMS認証取得支援サービス、個別のご相談は お問い合わせ から承ります。

参考・出典

• 情報マネジメントシステム認定センター（ISMS-AC）
• ISO/IEC 27001 Information security management systems｜ISO
• ISO 22301 Security and resilience — Business continuity management systems｜ISO
• 医療情報システムの安全管理に関するガイドライン｜厚生労働省
• 独立行政法人情報処理推進機構（IPA）
• 内閣府 防災情報のページ

※規格の要求事項の解釈、認定および認証の取扱いは、規格本文および認定機関・審査機関の公表資料をご確認ください。改定や運用の見直しにより取扱いが変わる場合があります。