あの9.11テロから10年目に突入した。被災時のデータ確保が企業生命を左右した記憶も一昔…、遠のきつつあるのではないか。今、改めて復旧の実務を詰めていくと、システムをバックアップに切り替えた際の「欠落データ問題」に突き当たる。とくにオフサイト（遠隔地）のバックアップ・センターに切り替わる際には、何らかの欠落データの発生が不可避である。欠落データの問題は、古くからITリスク管理と事業継続の交点に伏在していたが、IT障害の復旧対策や事業継続体制が相応に向上した今、キーポイントとして浮上してくる。

　欠落データの量は、最新の遠隔同期技術を用いてほぼリアルタイムでデータ転送していれば少なくて済むが、1時間ないし1日単位でのデータ取得・転搬送の場合には膨大になる。現状は、「欠落データを特定し、システムに反映しない限り完全な復旧ではない」と考えてBCP（事業継続計画）を用意している金融機関と、「データの完全性が担保されるまで待てば復旧が遅れ、利用者に迷惑がかかるから、見切り発車で業務を再開する」方針の金融機関、そのどちらとも決め切れていない金融機関が混在し、この問題の認識や対応は遅れがちだ。

　「欠落データの特定優先」を選択した場合、その間にも手作業により最低限の窓口取引を継続すると、欠落データに加えて手作業取引分を入力したうえで業務サービスを再開する必要があるため、復旧までの時間は長引く。一方、「データ反映前に業務再開」を選択した場合には、本来入金済みの預金が入っておらず残高不足エラーとなったり、支払い済みの預金から残高以上の引き出しを許すなど、顧客とのトラブルに繋がるリスクが増す。

　こうした状況のまま大きな災害に見舞われた場合、利用している金融機関（あるいは当該金融機関が利用している共同センターやITベンダー）によって対応がまちまちとなり、利用する金融機関によって対応方針自体が異なるとは認識していない顧客が戸惑う可能性が高い。さらには、他の金融機関や決済センターを含め、相互接続された「システム全体の整合性確保」も大きな課題である。この際、個別金融機関や関係企業はもとより、決済システム関係者全体として、欠落データの特定・反映や復旧までの手作業取引分の反映等「実戦的な訓練」を実施することにより、緊急時対応のフィージビリティを向上させていくよう期待したい。（本稿は私見です）