セキュリティ統制・法務・基準重要度:★★★出題: AM2・PM1

BCP (事業継続計画) と BIA / RTO・RPO・RLO (情報セキュリティ継続)

びーしーぴー / びじねすいんぱくとぶんせき / あーるてぃーおー・あーるぴーおー / Business Continuity Plan / Business Impact Analysis / RTO & RPO

大規模サイバー攻撃や災害によるシステム停止時に重要業務を目標時間内に復旧させる計画（BCP）と、許容停止時間（RTO）および許容データ消失時点（RPO）の指標定義。

3行速習ポイント

BIA（ビジネスインパクト分析）：業務停止が経営に与える影響度を評価し、優先復旧すべき重要業務と、その稼働に必要なITリソースを特定するプロセス
RTO（Recovery Time Objective：目標復旧時間）：障害発生から業務・システムをいつまでに復旧させるかの目標時間（冗長構成やホットスタンバイ等で短縮）
RPO（Recovery Point Objective：目標復旧時点）：障害発生時に「過去どの時点のデータまで遡って復元できればよいか（データの最大許容消失期間）」（バックアップ頻度やレプリケーション方式を決定）

図BCP / BIA における RTO（目標復旧時間）と RPO（目標復旧時点）の設計対応

RPO (Recovery Point Objective：目標復旧時点)バックアップ頻度を決定

【障害発生以前】過去どの時点のデータまで消失を許容するか

「データの鮮度（最大許容消失期間）」を表す指標。RPOを24時間から1時間へ短縮するには、バックアップ取得頻度の高頻度化やリアルタイムレプリケーション導入が必要

RTO (Recovery Time Objective：目標復旧時間)冗長化方式を決定

【障害発生以後】停止からいつまでに業務・システムを再開するか

「許容される最大停止時間」を表す指標。RTOを短縮するには、コールドスタンバイからホットスタンバイ（自動フェイルオーバ）やマルチAZ冗長構成への強化が必要

💡 非常時や縮退運転中であっても、平常時と同等のアクセス制御やログ取得を維持する「情報セキュリティ継続（JIS Q 27001 5.29）」が問われる

ランサムウェア感染やDDoS攻撃、クラウド障害が発生した際、すべてのシステムを同時に即時復旧することは不可能です。事前にBIAを実施して業務ごとのRTO（時間）とRPO（データ鮮度）およびRLO（目標復旧レベル：縮退運転時の提供機能水準）を定め、それに見合ったバックアップと冗長化設計を行います。

RPOとバックアップ設計の対応：RPO＝24時間なら1日1回の夜間日次バックアップで足りるが、RPO＝0（データ消失ゼロ）が求められる決済系DB等では同期レプリケーションやトランザクションログのリアルタイム転送が必要
RTOとスタンバイ方式：コールドスタンバイ（予備機停止・手動切替：RTO長）＜ウォームスタンバイ（OS起動済・データ同期後切替：RTO中）＜ホットスタンバイ（リアルタイム同期・自動フェイルオーバ：RTO極小）
情報セキュリティ継続（JIS Q 27001 管理策5.29）：非常時や縮退運転中であっても、平常時と同等水準の情報セキュリティ（アクセス制御やログ取得等）を維持し続けること