■RTOはITの復旧目標として生まれた

さて、ここから欧米と日本の目標復旧時間の考え方に違いが出てくる。BCP策定運用指針のRTOは、「中核事業」という一つの概念に対して事業停止の許容時間内に製品やサービス供給を再開するためのタイミングを探るというものだ。一方欧米のRTOは、社内の主要な業務すべてを洗い出し、その一つひとつについて先程述べた時系列（1日、3日、1カ月業務が止まると…）による業務停止時間の影響を推理する。言い換えれば、すべての業務一つひとつについてRTOが決まるわけである（これもビジネス・インパクト分析であることに変わりはない）。

なぜ欧米のRTOは、すべての業務を対象にこのような手間のかかる評価作業を行うのだろうか。中核事業という一つの対象にRTOを付与するだけで十分ではないか。そうすれば「当社の中核事業の目標復旧時間は5日とする」のように簡潔な方針を示せる。そのようにみなさんは思うだろう。

実はRTOを導く目的が違うのである。もともとBCPはITのディザスターリカバリー（IT機器の故障・破損やデータの破壊からの回復技術）から発展してきたという経緯がある。このことは今日でも変わらない。欧米人がRTOを導くのは、複雑に配置されたおびただしい数のシステムやアプリケーションのうち、どの業務で使用されているコンピュータとソフトウェア、そしてデータが最も重要（Mission Critical）なのかを特定するためなのだ。例えば金融機関の主要なシステムが10分、30分、1時間停止すれば、計り知れない有形・無形の損失や損害が出る可能性がある。そこでRTOを設定してその時間内に業務機能を回復させようというものである。