Transcript 第8回「バックアップ/リカバリー計画書」

5,000円ぽっきりのCSVセミナー 【第8講】
「バックアップリカバリー計画書」「サービスレベルアグリーメント」
の書き方
2013年2月28日
イーコンプライアンス
http://eCompliance.co.jp
© Copyright eCompliance 2013
サービスレベルアグリーメントと災害対策
Disaster
災害対策計画書
Recovery
Backup & Recovery
Plan
サービスレベルアグリーメント
Backup
Business Continuity
Plan
Disaster
▲
Incident
▲
Backup
▲
Restore
▲
▲ Verification
Recovery
© Copyright eCompliance 2013
2
Table of contents
1. バックアップ/リカバリー手順書
2. サービスレベルアグリーメント
© Copyright eCompliance 2013
3
バックアップとは
アクティブなデータベースの複製（Duplicate）である。
目的は災害時に復旧ができることなどである。（「バックアップ」と「保存」は目的が
異なる。）
電磁的記録は重要であることから、バックアップメディアは、災害対策用に別地で媒
体保管を行なうこと。
一般に、マグネチックテープ（MT）にバックアップをとることが多い。MTは、検索など
の用には適さない。（したがってMTは「保存」の目的には適切ではない。 ）
またバックアップは、適宜更新される。（最新のものだけ）
ER/ES指針では、「バックアップ」は「真正性」の要件であり「保存性」の要件では
ないことに注意すること。
© Copyright eCompliance 2013
4
アーカイブとは
紙によるアーカイブは、資料保管庫の棚からダンボールなどに移して保存すること
をいう。
これは申請および調査が終了したなどによって、あまり参照されなくなった資料に
適用する。
電子の場合も同様で、変更しない（インアクティブ）データを別のストレージ（ハー
ドディスク）に移行することをさす。このことにより、アクティブなデータベースを常に最
適な状態（ボリューム、検索スピード、バックアップ時間）に維持できる。ただし、ア
ーカイブは検索ができる状態である。
アーカイブデータベースは更新頻度が少ないため、アクティブデータベースほどは頻
繁にバックアップを行う必要性はない。
© Copyright eCompliance 2013
5
厚労省ER/ES指針とバックアップ
3.1.電磁的記録の管理方法
電磁的記録利用システムとそのシステムの運用方法により、次に掲げる事項が確立されていること。
この場合、電磁的記録利用システムはコンピュータ・システム・バリデーションによりシステムの信頼性が
確保されている事を前提とする。
3.1.1. 電磁的記録の真正性
電磁的記録が完全、正確であり、かつ信頼できるとともに、作成、変更、削除の責任の所在が明確
であること。
真正性を確保するためには、以下の要件を満たすことが必要である。
（１） システムのセキュリティを保持するための規則、手順が文書化されており、適切に実施されている
こと。
（２） 保存情報の作成者が明確に識別できること。また、一旦保存された情報を変更する場合は、
変更前の情報も保存されるとともに、変更者が明確に識別できること。なお、監査証跡が自動
的に記録され、記録された監査証跡は予め定められた手順で確認できることが望ましい。
（３） 電磁的記録のバックアップ手順が文書化されており、適切に実施されていること。
© Copyright eCompliance 2013
6
３．電磁的記録利用のための要件
3.1.1.電磁的記録の真正性
バックアップ手順
•どういう間隔で、どの媒体で、誰がバックアップするか。
•保管場所（サーバールームとは別の建屋に保管する）、保管環境を考慮する。
•耐用年数を管理する手順
•媒体の使用回数を記録する手順
•リカバリーの手順
© Copyright eCompliance 2013
7
GCP課長通知（記録の保存等 第26条第1項）
２ 本条の「記録」には、磁気媒体等に記録されたデータを含むこと。データを適切に保存
するためには、セキュリティシステムの保持、データのバックアップの実施等が必要である。
３ 治験依頼者は、データの処理に当たって、電子データ処理システム（遠隔操作電子
データシステムを含む。）を用いる場合には、次の事項を実施しなければならない。
１）電子データ処理システムが、完全性、正確性、信頼性及び意図された性能についての治験依
頼者の要件を満たしていることを保証し、文書化すること（すなわちバリデーションされること。）。
２）当該システムを使用するための手順書を整備すること。
３）当該システムが、入力済みのデータを消去することなしに修正が可能で、データ修正の記録を
データ入力者及び修正者が識別されるログとして残せる（すなわち監査証跡、データ入力証跡、
修正証跡が残る）ようにデザインされていることを保証すること。
４）データのセキュリティ・システムを保持すること。
５）データのバックアップを適切に行うこと。
６）データの修正を行う権限を与えられた者の名簿を作成し、管理すること。
７）盲検化が行われている場合には、盲検性が保持されるようにすること。
４ 治験依頼者は、処理中にデータの変換を行う場合には、処理前のデータと処理後の
データを常に対比し得ることを保証しなければならない。
© Copyright eCompliance 2013
8
厚労省ER/ES指針目次
１．目的
２．用語の定義
３．電磁的記録利用のための要件
３．１ 電磁的記録の管理方法
３．１．１ 電磁的記録の真正性
３．１．２ 電磁的記録の見読性
３．１．３ 電磁的記録の保存性
３．２ クローズド･システムの利用
３．３ オープン･システムの利用
４．電子署名利用のための要件
５．その他
© Copyright eCompliance 2013
9
厚労省ER/ES指針が求める真正性の要件
厚労省ER/ES指針が求める真正性の要件
(1) セキュリティ
(2) 監査証跡（作成記録・変更記録）
(3) バックアップ
© Copyright eCompliance 2013
10
バックアップはなぜ真正性の要件か？
 災害（火災、地震等）時に監査証跡が消失してしまうから。
 監査証跡のない電子記録は、改ざんの有無が確認できないため、
査察が行えない。
 バックアップからのリストアは、あらかじめ定められた手順により実施
すること。
 データベースに直接手作業でデータを入力する行為は、監査証
跡を記録しないため、行ってはならない。
© Copyright eCompliance 2013
11
EU GMP Annex 11
１５．Back Up; Migration; Archiving; Retrieval
15.1 全ての関連するデータは、定期的バックアップされなければならない。
バックアップデータは、離れた安全な場所に保管しなければならない。
バックアップデータの完全性と正確性は、バックアッププロセス中または完了時
にチェックしなければならない。
15.2 4章で特定した期間、システムが記録を保持できる容量を持たない場合、
データは適切にアーカイヴされなければならない。
アーカイヴされたデータは、物理的および電子的な方法で、故意または偶発
的なダメージから保護されなければならない。
このデータはアクセス可能性、耐久性、見読性、完全性をチェックされなけれ
ばならない。
コンピュータ機器またはプログラムに変更が加えられた場合においても、データ
がリストアできることをチェックしなければならない。
15.3 バックアップ、アーカイヴ、検索、リストア（リカバリ）の実施は、製薬企業の
QMS 、ISMS、リスク管理要件に従って定義され、テストされ、確立されて
いなければならない。
© Copyright eCompliance 2013
12
FDA査察対応 システム毎に作成すべき手順書類
1. システム・セットアップ / インストレーション
2. データ収集と取扱い
3. システム・メンテナンス
4. データ・バックアップ、リカバリー、緊急時対策
5. セキュリティ
6. 変更管理
7. 代替記録方法（システム利用不能の場合）
© Copyright eCompliance 2013
13
FDAの査察対応
システムオーナーがするべき事項
 当該システムのCSVパッケージの内容を知っておく
 テスト戦略を理解しておく
 常に最新のログと記録にしておく
 最新のシステム説明書を持っておく
 システムのバックアップを維持しておく
 変更管理に従う
システムオーナーへの禁止事項
 不作成ドキュメントを作り直さない
 査察官、あるいはQA担当者と議論しない
 “争い”の種を自分から進んで提供しない
 監査報告書の内容を提供しない
 QA担当者抜きで対応しない
© Copyright eCompliance 2013
14
FDAの査察対応
QA担当者が行うべき事項
 システムパッケージがバリデーション計画書のタスクと整合しているか徹底的に調査する
 テスト計画書とテスト報告書をレビュする
 バックアップテープとシステムのログを見る
 トレーニング記録を確認する
QA担当者への禁止事項
 トレーニング記録があると思うな
 更新されたユーザ資料を確認することを忘れるな
 査察ツワー中、査察官たちだけにしない
 過去の監査に触れない
© Copyright eCompliance 2013
15
FDA Warning Letter
 査察日：2007年7月31日～8月2日
 レター発行日：2008年1月14日
 会社名：Tomita Pharmaceutical Co., Ltd
 貴社は査察中に要求した文書のコピーを提供しなかった。
 クローズアウトミーティングで、XXX氏は30日以内にFDA-483の所見に書面で回答することを示唆
していたが、我々はまだ書面による回答を受け取っていない。
 バリデートされ、安全なコンピュータシステムを保持していない。それに加え、システムに対する責任
度を割り当てる書かれたプロトコールがない。
 XXXは分析者と管理者に対するパスワードコントロールがない。
 コンピュータに保存されたデータは削除、移動、転送、名前の付け替えもしくは改ざんすることが可
能である。
 文書化された証拠もしくはコミットメントが提供されていない。
 コンピュータシステムはデータに対する権限のないアクセスや変更を防ぐために十分な管理が必要で
ある。データの欠落を防ぎ、バックアップを確実にするため管理されるべきである。実施されたデータ
の変更、前回の入力、だれが変更を実施したか、いつ変更が実施されたかの記録が必要である。
 査察中、貴社は製造記録、研究所の記録及びFDAの査察官から要求された手順書のコピーを
提供することを拒否した。
© Copyright eCompliance 2013
16
FDA Warning Letter
 データファイルのバックアップ手順書がない。
 バックアップテープが社員の自宅に保管されており、何回使用したかの
記録も無かった。
 セキュリティ手順（サーバ管理室への入退出、パスワード管理、データの
バックアップ）が確立されていなかった。
 パスワード利用、アクセスレベル及びデータバックアップの書面による手
順書がなかった。
 上記の違反に加え、我々査察官は、研究所が原子吸光とHPLC機器からの
データの処理及び保管に電子記録システムを使用していることに言及する。こ
れらはパスワードで管理されていないシステムであるから、セキュリティとデータの
完全性を管理するよう構成されておらず、系統だったバックアップ対策がとられて
おらず、システム機能の監査証跡がない。このシステムは21 CFR Part 11,
Electronic Recordsの要求事項に従って設計、管理されているようには思え
ない。
© Copyright eCompliance 2013
17
Table of contents
1. バックアップ/リカバリー手順書
2. サービスレベルアグリーメント
© Copyright eCompliance 2013
18
サービスレベルアグリーメントとは
システムがバリデートされ、運用を開始するにあたって、サービス組織に管理を移管することになる。
サービス組織は、自社内のIS部門である場合や、外部のベンダーである場合がある。
ユーザはシステムを利用するために必要となるサービスレベルを、事前にサービス組織と文書によって合
意しておかなければならない。
サービスレベルとは
サービスレベルは、サービス組織が提供できるサービスの品質を定量化し、達成できていることが明示
的にわかるように設定する必要がある。
サービスの品質は、システムの存在や価値を決定するものであり、ユーザに提供するサービスの品質の
ことを一般にサービスレベルと呼ぶ。
サービスレベルを定義する際には、確実に同意が得られるように、ユーザの要望に沿った内容であるこ
とが必要になる。
具体的なサービスレベルは、可用性、パフォーマンス、キャパシティとデータ保全、ヘルプデスク関連、セ
キュリティ関連などがある。
© Copyright eCompliance 2013
19
サービスレベルアグリーメントとは
サービスレベルアグリーメントとは
サービスレベルアグリーメントは、サービス（運用サポート、メンテナンス、バックアップ等）する側とサービス
を受ける側（ユーザ）が、その利用形態（サポート体制、稼働時間、ヘルプデスク、ユーザの責任等）に
ついて合意した文書である。
サービスは物理的な実体のある製品に比べて内容が分かりづらく、提供者と委託者の間で何がどの
程度行われるのかに関する認識の食い違いが生じる可能性が高い。特に中長期にわたって提供され
るサービスの場合、「最初はよかったが、次第に品質が下がった」「いい場合もあれば、悪い場合もあ
る」といったことが少なくない。そこで、サービスレベルを数値によって明示的・定量的に定義することで、
役割と責任の所在について“あいまいさ”を排除し、ルールを定めておくのがSLAである。
SLAの基準は、客観的な方法で測定できる数値でなければ効果はない。中長期にわたるサービスで
あれば、定期的に測定（モニタリング）できる基準でなくてはならず、SLAの中に測定方法や測定を行
う主体についても記述する。
サービスレベルアグリーメントの目的は、サービス組織の提供するサービスについての保証レベルを定義
し、ユーザと同意することで、ユーザに適切な品質のサービスを提供することである。
サービスレベルアグリーメントでは、システムの停止可能時間、バックアップの頻度、メンテナンス、障害
時対応などを記載する。またサービス施行の評価基準を定義し、サービス管理の方法に関しても記
載しなければならない。
© Copyright eCompliance 2013
20
サービスレベルアグリーメントの目的と効果
サービスレベルアグリーメントの目的には以下の事項がある。
1) 高品質のサービスレベルの維持
2) サービスレベルを明確にすることでユーザの利便性が向上
3) サービス組織、サービス利用者側それぞれの責任範囲の明確化
サービスレベルアグリーメントの効果には以下の事項がある。
1) サービスレベルに見合ったコストの明確化
2) 合意と達成、報告と改善を通じ現行システムの問題点、課題点の把握
3) サービス組織とサービス利用者側への信頼関係の構築
© Copyright eCompliance 2013
21
サービスレベルアグリーメントの目的と効果
サービスレベルアグリーメントは基本的にサービス組織とユーザ間の契約であり、企
業内部の部門間契約である運用レベルアグリーメント（Operational Level
Agreement）と、外部企業との契約である基盤アグリーメント（Underpinning
Contract）の2つがある。
多くのサービスレベルアグリーメントは通常、他部門や外部のサプライヤによって支
えられる。
1) サービスレベルアグリーメントの前提としての、運用レベルアグリーメントや基盤
アグリーメント締結が望ましい
2) 運用レベルアグリーメントで承認された以上のサービスレベルをサービスレベル
アグリーメントでコミットする事は難しい
3) サービスレベルアグリーメント締結時に、運用レベルアグリーメントや基盤アグ
リーメントの確認・見直しが必要
なおサービスレベルアグリーメントでは、障害はカバーするが、災害（火災、地震）
時の対応は通常記載しない。従って、別途災害対策計画書の作成が必要とな
る。
© Copyright eCompliance 2013
22
サービスレベルアグリーメントの要件
サービスレベルアグリーメントは、ユーザ要求仕様書等に記載したユーザのサービ
スに対する要求事項をもとに作成すること。
また、現行のサービスレベル合意書（存在する場合）を考慮に入れること。
SLAが含む項目は、原則として下記の要領に従って記載すること。
1) ユーザのために作成しているSLAが具体的で完全な形であること
2) 評価可能であること
3) 達成可能であること
4) 適切であること
© Copyright eCompliance 2013
23
サービスモデルアグリーメントの作成
計画フェーズにおいて、ユーザはユーザ要求仕様書の中で、サービス要求を記載しておかなければなら
ない。
ユーザによって要求されたサービス要求は、要求フェーズにおいてサービスモデルとして設計される。
サービスモデルは、機能仕様書で文書化しておくこと。
サービスモデルでは、サービス組織を組織するために必要であり、サービスレベル及びオペレーショナルレ
ベルを定義し、サービスのコストを定義するために使用する。
サービスモデルを作成するにあたって、サービスが自社内で供給できるか、または外部のサプライヤを利
用しなければならないかを検討すること。
サプライヤにサービスを委託する場合は、サプライヤオーディット等において以下を評価しておくことが望
ましい。
1) 定義どおりにサービスを満たすことができるか
2) 要求するタイムフレームを満たすことができるか
3) 自社にビジネスや財務上のリスクを負わせないか
4) 該当するサービスに見合う経験をもっているか
5) 費用見積りに合うか
6) バリデーション要求を満たすか
サプライヤが上記の条件を満たす場合、原則としてサプライヤの標準的な条件と制約をレビュしておく
こと。
© Copyright eCompliance 2013
24
サービスモデルアグリーメントの作成
サービスレベルアグリーメントは、機能仕様書に記載され承認されたサービスモデルに従って、運用
フェーズ開始までに作成しなければならない。
現行のサービスレベルアグリーメントが存在する場合は、それらを考慮に入れること。
サービスのインプリメンテーションは、移行計画書中で計画しておくこと。
またサービスレベルは事前にテストし、レビュしておくことが望ましい。この場合サービスレベルアグリーメン
トのレビュ結果は、サポート品質報告書に記載することになる。
サービスレベルアグリーメントを文書化する場合には、次のような方法がある。
1) サービスレベルアグリーメントの文書を単独で作成する
2) 保守契約書等に含める
3) 覚書に含める
サービスレベルアグリーメントはサービス組織が確実にサービスレベルを守ることの宣言になるが、対象と
なるユーザとの同意が必要になる。
合意方法を定義する場合は次のことを検討する必要がある。
1) サービスレベルアグリーメントの対象者と追加費用
2) サービスレベルアグリーメント違反時の罰則、処置、報告方法
3) サービスレベルアグリーメント合意の署名、捺印手順
© Copyright eCompliance 2013
25
サービスモデルアグリーメントの作成
サービスレベルアグリーメントは、機能仕様書に記載され承認されたサービスモデルに従って、運用
フェーズ開始までに作成しなければならない。
現行のサービスレベルアグリーメントが存在する場合は、それらを考慮に入れること。
サービスのインプリメンテーションは、移行計画書中で計画しておくこと。
またサービスレベルは事前にテストし、レビュしておくことが望ましい。この場合サービスレベルアグリーメン
トのレビュ結果は、サポート品質報告書に記載することになる。
サービスレベルアグリーメントを文書化する場合には、次のような方法がある。
1) サービスレベルアグリーメントの文書を単独で作成する
2) 保守契約書等に含める
3) 覚書に含める
サービスレベルアグリーメントはサービス組織が確実にサービスレベルを守ることの宣言になるが、対象と
なるユーザとの同意が必要になる。
合意方法を定義する場合は次のことを検討する必要がある。
1) サービスレベルアグリーメントの対象者と追加費用
2) サービスレベルアグリーメント違反時の罰則、処置、報告方法
3) サービスレベルアグリーメント合意の署名、捺印手順
© Copyright eCompliance 2013
26
サービスレベルアグリーメントの管理
SLAは単に契約時に取り交わすばかりではなく、継続的なモニタリングが大切である。また、SLAを作
成する場合も最初から委託側／提供側にとって最適なSLAを得ることは困難であり、締結したSLA
を継続的・定期的に見直すことが望ましい。こうした活動をSLMという。
サービスレベルアグリーメントは、あくまでサービス組織とサービス利用者側との合意によって形成される。
そのため、両者間でサービスレベルアグリーメントの管理プロセスについても取り決める必要がある。
1) モニタリング
サービスレベルアグリーメント項目に従ってモニタリングの設定と実施を行う。
2) レポーティング
モニタリングの取得結果に基づいてレポートを作成する。
レポートは主に次の2つに分類できる。
(1) サービスレベルアグリーメント違反レポート
(2) 定期運用レポート
3) 結果レビュ
作成されたレポーティングに対し結果レビュを実施する。
ここではサービスレベルアグリーメント達成状況やサービスレベルアグリーメント違反についてレビュ
する。
4) 定期レビュ
5) サービスレベルアグリーメント／運用レベルアグリーメント／基盤アグリーメントの見直し
各項目の目標値の見直し、前提条件確認、契約・合意内容の改訂を行う。
© Copyright eCompliance 2013
27
サービスレベルアグリーメント(SLA)
6. イントロダクション
本SLAが提供するサービスを記述する。本セクションには、本
SLAを作成するもとになるサービスモデルへの参照を記載するこ
と。必要な場合は、提供しているサービス全体を構成するその
他のあらゆるSLAへの参照を含めること。
10. サービス項目の評価
除外する具体的な事項を挙げ、本合意書の範囲を特定するこ
と。
上記のセクション9. で定義している各サービス項目に対し、以
下の事柄を明確にする。
10.1 評価対象
10.2 評価方法
10.3 責任者
評価のまとめと評価報告に対する責任者
10.4 評価見積りまたは参照
実際の評価見積りまたはその見積りへの参照
8. サービスの記述
11. 報告
7. 範囲
システムのライフタイムの各フェーズに対し、提供するサービスの
内容をユーザの理解可能な形で記述する。また、技術構成とシ
ステムの主要機能の概要や参照も含むこと。
システムのDS、つまりサービスに関連して、サービス組織やユー
ザ組織および社員の具体的な責任を含めるか、または参照し
なければならない。
9. サービス項目
サービスモデルから物理的なサポートのプロセス、相互規制サ
ポートプロセス、サービスを反映しているプロセスのインターフェイス
を特定する。また、サービスレベル対象を各項目に対して定義す
る。サービスレベル目標は評価可能でなければならず、サービス
モデルのサービス手順のセクションにもとづいていること。
サービスに関して、サービス管理側がユーザ側へ伝達する、サー
ビスの評価に関する報告書のフォーマットや頻度を特定する。頻
度は、提供するサービスのレベルに準ずること。
12. サービスのレビュ
サービスレビュの頻度と内容、およびレビュを行う役割の者を明
確にする。サービスの予想が要求事項を満たしていることを保証
するために、定期的にレビュを実行する。
レビュのメカニズムおよび適切なフォーラム(例、月定例のサービス
レビュ会議、サポート品質報告書の一環としてのSLAレビュなど)
を特定する。
サービスのレビュを行うグループには、以下の者を含むこと。
© Copyright eCompliance 2013
28
サービスレベルアグリーメント(SLA)
12.1 システムオーナー
プロジェクトフェーズ中の場合はスポンサー
12.2 サービスマネージャ
12.3 システムサポートマネージャ
本SLAに関連するOLAに記載されている適切なサポートグルー
プを代表するシステムサポートマネージャ
13. エスカレーション
どちらか一方の関係者の要求を満たすことができない未解決の
課題に対する段階的拡大プロセスを特定する。合意した場合
は、エスカレーションプロセスに必要な具体的な項目を記述する。
14. 連絡先
サービスに関して連絡する役割を持つ者、連絡可能時間および
連絡方法を明確にする(例、ヘルプデスク、午前9時―午後5時、
8888に電話)。
© Copyright eCompliance 2013
29