IT企業のBCPは、クラウドにバックアップがあるだけでは完成しません。認証できない、連絡手段が使えない、主要担当者が不在、委託先が停止、顧客へ説明できないといった運用上の停止を含めます。技術復旧計画と事業判断を分けて作ります。

サービス単位で優先順位を決める

顧客向けサービス、社内業務、開発環境、請求、サポートを並べ、停止影響と復旧優先順位を決めます。全システムを同時に復旧しようとせず、顧客データの保護、安全な認証、障害情報の発信など、先に守る条件を明確にします。

技術的な復旧時間の目標だけでなく、誰がサービス停止や切替を決めるか、顧客へ何を案内するか、契約上の連絡を誰が確認するかを記載します。

クラウドと認証の依存関係

クラウド事業者が異なっても、同じ認証基盤、DNS、監視、通知ツール、決済、コード管理に依存していることがあります。構成図へ外部サービスと管理者を記載し、一つの障害がどこへ波及するかを確認します。

管理者権限を一人へ集中させず、緊急時アクセスの承認と記録を定めます。通常のセキュリティを無効にする手順ではなく、安全に代替認証や復旧作業を行う方法を事前に検証します。

在宅勤務時の初動

従業員が分散している場合、安否確認、指揮系統、技術対応、顧客対応をオンライン会議だけに依存しないようにします。通信障害を想定し、代替連絡、定時報告、情報の正本を決めます。

自宅から本番環境へ接続できない場合、誰が安全な場所で作業するか、端末や多要素認証をどう確保するかを確認します。会社貸与端末の紛失や停電も想定します。

サイバー事案と自然災害を混同しない

ランサムウェア等の事案では、可用性だけでなく封じ込めと証拠保全が必要です。自然災害の「早く接続を戻す」手順をそのまま使うと被害を広げる可能性があります。インシデント対応計画、個人情報対応、BCPの接点と分岐を明示します。

訓練で確認する判断

  • 主なクラウドと認証が同時に利用できない
  • 技術責任者と連絡が取れない
  • 顧客問い合わせが急増する
  • 監視通知の信頼性が確認できない
  • 委託先から復旧見込みが出ない

訓練ではコマンド操作より、情報の確からしさ、意思決定、顧客通知、代行権限、復旧後の確認を記録します。計画の最新版を、障害対象と同じサービスだけに保存しないことも重要です。

事業継続力診断で技術と事業の依存関係を整理できます。この記事の執筆・監修は丸岡 峻です。元京都市消防局13年・現役防災士（日本防災士機構認定）・消防設備士・危険物取扱者。

サービス台帳に事業情報を加える

技術台帳へ、サービス責任者、顧客、契約上の通知、売上・業務影響、個人情報、主要委託先を追加します。CPUやデータベースの状態だけでなく、停止がどの顧客業務へ影響するかを経営側が理解できる表現にします。

依存関係図には、クラウド、認証、DNS、決済、メール、監視、コード管理、顧客サポートを含めます。外部サービスが利用できない場合の連絡先とステータス確認方法も記載します。

障害情報の正本を決める

チャット、課題管理、電話、メールで別々の情報が流れると、復旧判断や顧客案内がずれます。インシデントごとに、現象、影響、確認済み事実、仮説、対応、次の更新を一つの記録へ集約します。

技術担当は原因調査、事業責任者は顧客影響、広報・サポートは案内を担当します。未確認の原因を外部へ断定せず、更新時刻と確認中の範囲を伝えます。

顧客通知のテンプレート

通知には、発生を確認した時点、対象サービス、確認されている影響、利用者が取るべき行動、次回更新を含めます。復旧見込みが確定していない場合は、希望時間を約束しません。

顧客ごとに契約上の連絡先や通知条件が異なる場合、CRMや契約台帳から確認できるようにします。担当営業の個人アドレスだけに情報を持たせず、代行者を決めます。

データ復旧を検証する

バックアップが存在することと、復元できることは別です。隔離された環境で復元手順、権限、暗号鍵、データ整合、復旧後の差分を確認します。本番へ戻す判断は、セキュリティ、データ、サービス責任者で分けます。

復元訓練では実顧客データを不用意に複製せず、アクセスと削除を管理します。結果をバックアップ設定、手順、担当者教育へ反映します。

キーパーソン不在の訓練

最高権限者、主要開発者、顧客責任者のうち一人と連絡が取れない想定で、代行権限が機能するかを確認します。緊急権限を共有パスワードで回避せず、安全なアクセス管理と承認記録を用います。

属人化した運用は、コードだけでなくDNS、請求、ストア、証明書、委託先契約にあります。管理者一覧を定期的に棚卸しし、退職・異動時に権限を更新します。

オフィス被災とリモート継続

オフィスへ入れない場合、従業員の安全、端末、ネットワーク、電源、作業場所を確認します。全員が同時に在宅作業できるとは限らないため、重要業務担当から復旧する優先順位を決めます。

自宅の通信や停電が長引く場合、代替拠点、勤務交代、外部支援を検討します。従業員へ無理な移動を求めず、作業可能状況を定時報告する方法を作ります。

委託先障害

開発、運用、サポートを委託している場合、相手のBCP、連絡、再委託、データ返却、緊急アクセスを契約時に確認します。障害時に初めて担当者の個人連絡先を探さないよう、組織窓口を記録します。

委託先が停止した場合の内製代替や別会社への切替は、技術・契約・セキュリティの確認が必要です。短時間で切替できると推測せず、平時にテストします。

IT企業BCPの更新条件

新サービス、クラウド移行、認証変更、買収、組織変更、主要担当退職、委託先変更をBCP更新のトリガーにします。変更審査へBCP影響欄を追加し、リリース完了後に依存関係図も更新します。

事業継続力強化計画の認定を目指す場合、技術的バックアップだけでなく、重要業務、初動、人・物・情報・資金、平時の推進体制を整理します。