「バックアップリカバリー計画書」「サービスレベルアグリーメント」の書き方

5,000円ぽっきりのCSVセミナー　【第8講】 「バックアップリカバリー計画書」「サービスレベルアグリーメント」の書き方 2013年2月28日イーコンプライアンス http://eCompliance.co.jp

サービスレベルアグリーメントと災害対策 災害対策計画書 Disaster Recovery Backup & Recovery Plan サービスレベルアグリーメント Incident Backup Business Continuity Plan Disaster ▲ Verification ▲ ▲ ▲ ▲ Backup Restore Recovery

Table of contents • バックアップ/リカバリー手順書 • サービスレベルアグリーメント

バックアップとは アクティブなデータベースの複製（Duplicate）である。目的は災害時に復旧ができることなどである。（「バックアップ」と「保存」は目的が異なる。）電磁的記録は重要であることから、バックアップメディアは、災害対策用に別地で媒体保管を行なうこと。一般に、マグネチックテープ（MT）にバックアップをとることが多い。MTは、検索などの用には適さない。（したがってMTは「保存」の目的には適切ではない。）またバックアップは、適宜更新される。（最新のものだけ） ER/ES指針では、「バックアップ」は「真正性」の要件であり「保存性」の要件ではないことに注意すること。

アーカイブとは 紙によるアーカイブは、資料保管庫の棚からダンボールなどに移して保存することをいう。これは申請および調査が終了したなどによって、あまり参照されなくなった資料に適用する。電子の場合も同様で、変更しない（インアクティブ）データを別のストレージ（ハードディスク）に移行することをさす。このことにより、アクティブなデータベースを常に最適な状態（ボリューム、検索スピード、バックアップ時間）に維持できる。ただし、アーカイブは検索ができる状態である。アーカイブデータベースは更新頻度が少ないため、アクティブデータベースほどは頻繁にバックアップを行う必要性はない。

厚労省ER/ES指針とバックアップ 3.1.電磁的記録の管理方法　電磁的記録利用システムとそのシステムの運用方法により、次に掲げる事項が確立されていること。この場合、電磁的記録利用システムはコンピュータ・システム・バリデーションによりシステムの信頼性が確保されている事を前提とする。 3.1.1. 電磁的記録の真正性電磁的記録が完全、正確であり、かつ信頼できるとともに、作成、変更、削除の責任の所在が明確であること。真正性を確保するためには、以下の要件を満たすことが必要である。（１）　システムのセキュリティを保持するための規則、手順が文書化されており、適切に実施されていること。（２）　保存情報の作成者が明確に識別できること。また、一旦保存された情報を変更する場合は、変更前の情報も保存されるとともに、変更者が明確に識別できること。なお、監査証跡が自動的に記録され、記録された監査証跡は予め定められた手順で確認できることが望ましい。（３）　電磁的記録のバックアップ手順が文書化されており、適切に実施されていること。

３．電磁的記録利用のための要件3.1.1.電磁的記録の真正性３．電磁的記録利用のための要件3.1.1.電磁的記録の真正性 • バックアップ手順 • どういう間隔で、どの媒体で、誰がバックアップするか。 • 保管場所（サーバールームとは別の建屋に保管する）、保管環境を考慮する。 • 耐用年数を管理する手順 • 媒体の使用回数を記録する手順 • リカバリーの手順

GCP課長通知（記録の保存等　第26条第1項） ２本条の「記録」には、磁気媒体等に記録されたデータを含むこと。データを適切に保存するためには、セキュリティシステムの保持、データのバックアップの実施等が必要である。３治験依頼者は、データの処理に当たって、電子データ処理システム（遠隔操作電子データシステムを含む。）を用いる場合には、次の事項を実施しなければならない。１）電子データ処理システムが、完全性、正確性、信頼性及び意図された性能についての治験依頼者の要件を満たしていることを保証し、文書化すること（すなわちバリデーションされること。）。２）当該システムを使用するための手順書を整備すること。３）当該システムが、入力済みのデータを消去することなしに修正が可能で、データ修正の記録をデータ入力者及び修正者が識別されるログとして残せる（すなわち監査証跡、データ入力証跡、修正証跡が残る）ようにデザインされていることを保証すること。４）データのセキュリティ・システムを保持すること。５）データのバックアップを適切に行うこと。６）データの修正を行う権限を与えられた者の名簿を作成し、管理すること。７）盲検化が行われている場合には、盲検性が保持されるようにすること。４治験依頼者は、処理中にデータの変換を行う場合には、処理前のデータと処理後のデータを常に対比し得ることを保証しなければならない。

厚労省ER/ES指針目次 １．目的２．用語の定義３．電磁的記録利用のための要件　　３．１　電磁的記録の管理方法　　　　３．１．１　電磁的記録の真正性　　　　３．１．２　電磁的記録の見読性　　　　３．１．３　電磁的記録の保存性　　３．２　クローズド･システムの利用　　３．３　オープン･システムの利用４．電子署名利用のための要件５．その他

厚労省ER/ES指針が求める真正性の要件 厚労省ER/ES指針が求める真正性の要件 (1)　セキュリティ (2)　監査証跡（作成記録・変更記録） (3)バックアップ

バックアップはなぜ真正性の要件か？ • 災害（火災、地震等）時に監査証跡が消失してしまうから。 • 監査証跡のない電子記録は、改ざんの有無が確認できないため、査察が行えない。 • バックアップからのリストアは、あらかじめ定められた手順により実施すること。 • データベースに直接手作業でデータを入力する行為は、監査証跡を記録しないため、行ってはならない。

EU GMP Annex 11１５．Back Up; Migration; Archiving; Retrieval 15.1　全ての関連するデータは、定期的バックアップされなければならない。バックアップデータは、離れた安全な場所に保管しなければならない。バックアップデータの完全性と正確性は、バックアッププロセス中または完了時にチェックしなければならない。 15.24章で特定した期間、システムが記録を保持できる容量を持たない場合、データは適切にアーカイヴされなければならない。アーカイヴされたデータは、物理的および電子的な方法で、故意または偶発的なダメージから保護されなければならない。このデータはアクセス可能性、耐久性、見読性、完全性をチェックされなければならない。コンピュータ機器またはプログラムに変更が加えられた場合においても、データがリストアできることをチェックしなければならない。 15.3　バックアップ、アーカイヴ、検索、リストア（リカバリ）の実施は、製薬企業のQMS 、ISMS、リスク管理要件に従って定義され、テストされ、確立されていなければならない。

FDA査察対応　システム毎に作成すべき手順書類FDA査察対応　システム毎に作成すべき手順書類 • システム・セットアップ / インストレーション • データ収集と取扱い • システム・メンテナンス • データ・バックアップ、リカバリー、緊急時対策 • セキュリティ • 変更管理 • 代替記録方法（システム利用不能の場合）

FDAの査察対応 • システムオーナーがするべき事項 • 当該システムのCSVパッケージの内容を知っておく • テスト戦略を理解しておく • 常に最新のログと記録にしておく • 最新のシステム説明書を持っておく • システムのバックアップを維持しておく • 変更管理に従う • システムオーナーへの禁止事項 • 不作成ドキュメントを作り直さない • 査察官、あるいはQA担当者と議論しない • “争い”の種を自分から進んで提供しない • 監査報告書の内容を提供しない　 • QA担当者抜きで対応しない

FDAの査察対応 • QA担当者が行うべき事項 • システムパッケージがバリデーション計画書のタスクと整合しているか徹底的に調査する • テスト計画書とテスト報告書をレビュする • バックアップテープとシステムのログを見る • トレーニング記録を確認する • QA担当者への禁止事項 • トレーニング記録があると思うな • 更新されたユーザ資料を確認することを忘れるな • 査察ツワー中、査察官たちだけにしない • 過去の監査に触れない

FDA Warning Letter • 査察日：2007年7月31日～8月2日 • レター発行日：2008年1月14日 • 会社名：Tomita Pharmaceutical Co., Ltd • 貴社は査察中に要求した文書のコピーを提供しなかった。 • クローズアウトミーティングで、XXX氏は30日以内にFDA-483の所見に書面で回答することを示唆していたが、我々はまだ書面による回答を受け取っていない。 • バリデートされ、安全なコンピュータシステムを保持していない。それに加え、システムに対する責任度を割り当てる書かれたプロトコールがない。 • XXXは分析者と管理者に対するパスワードコントロールがない。 • コンピュータに保存されたデータは削除、移動、転送、名前の付け替えもしくは改ざんすることが可能である。 • 文書化された証拠もしくはコミットメントが提供されていない。 • コンピュータシステムはデータに対する権限のないアクセスや変更を防ぐために十分な管理が必要である。データの欠落を防ぎ、バックアップを確実にするため管理されるべきである。実施されたデータの変更、前回の入力、だれが変更を実施したか、いつ変更が実施されたかの記録が必要である。 • 査察中、貴社は製造記録、研究所の記録及びFDAの査察官から要求された手順書のコピーを提供することを拒否した。

FDA Warning Letter • データファイルのバックアップ手順書がない。 • バックアップテープが社員の自宅に保管されており、何回使用したかの記録も無かった。 • セキュリティ手順（サーバ管理室への入退出、パスワード管理、データのバックアップ）が確立されていなかった。 • パスワード利用、アクセスレベル及びデータバックアップの書面による手順書がなかった。 • 上記の違反に加え、我々査察官は、研究所が原子吸光とHPLC機器からのデータの処理及び保管に電子記録システムを使用していることに言及する。これらはパスワードで管理されていないシステムであるから、セキュリティとデータの完全性を管理するよう構成されておらず、系統だったバックアップ対策がとられておらず、システム機能の監査証跡がない。このシステムは21 CFR Part 11, Electronic Recordsの要求事項に従って設計、管理されているようには思えない。

Table of contents • バックアップ/リカバリー手順書 • サービスレベルアグリーメント

サービスレベルアグリーメントとは システムがバリデートされ、運用を開始するにあたって、サービス組織に管理を移管することになる。サービス組織は、自社内のIS部門である場合や、外部のベンダーである場合がある。ユーザはシステムを利用するために必要となるサービスレベルを、事前にサービス組織と文書によって合意しておかなければならない。サービスレベルとはサービスレベルは、サービス組織が提供できるサービスの品質を定量化し、達成できていることが明示的にわかるように設定する必要がある。サービスの品質は、システムの存在や価値を決定するものであり、ユーザに提供するサービスの品質のことを一般にサービスレベルと呼ぶ。サービスレベルを定義する際には、確実に同意が得られるように、ユーザの要望に沿った内容であることが必要になる。具体的なサービスレベルは、可用性、パフォーマンス、キャパシティとデータ保全、ヘルプデスク関連、セキュリティ関連などがある。

サービスレベルアグリーメントとは サービスレベルアグリーメントとはサービスレベルアグリーメントは、サービス（運用サポート、メンテナンス、バックアップ等）する側とサービスを受ける側（ユーザ）が、その利用形態（サポート体制、稼働時間、ヘルプデスク、ユーザの責任等）について合意した文書である。サービスは物理的な実体のある製品に比べて内容が分かりづらく、提供者と委託者の間で何がどの程度行われるのかに関する認識の食い違いが生じる可能性が高い。特に中長期にわたって提供されるサービスの場合、「最初はよかったが、次第に品質が下がった」「いい場合もあれば、悪い場合もある」といったことが少なくない。そこで、サービスレベルを数値によって明示的・定量的に定義することで、役割と責任の所在について“あいまいさ”を排除し、ルールを定めておくのがSLAである。 SLAの基準は、客観的な方法で測定できる数値でなければ効果はない。中長期にわたるサービスであれば、定期的に測定（モニタリング）できる基準でなくてはならず、SLAの中に測定方法や測定を行う主体についても記述する。サービスレベルアグリーメントの目的は、サービス組織の提供するサービスについての保証レベルを定義し、ユーザと同意することで、ユーザに適切な品質のサービスを提供することである。サービスレベルアグリーメントでは、システムの停止可能時間、バックアップの頻度、メンテナンス、障害時対応などを記載する。またサービス施行の評価基準を定義し、サービス管理の方法に関しても記載しなければならない。

サービスレベルアグリーメントの目的と効果 サービスレベルアグリーメントの目的には以下の事項がある。 1) 高品質のサービスレベルの維持 2) サービスレベルを明確にすることでユーザの利便性が向上 3) サービス組織、サービス利用者側それぞれの責任範囲の明確化サービスレベルアグリーメントの効果には以下の事項がある。 1) サービスレベルに見合ったコストの明確化 2) 合意と達成、報告と改善を通じ現行システムの問題点、課題点の把握 3) サービス組織とサービス利用者側への信頼関係の構築

サービスレベルアグリーメントの目的と効果 サービスレベルアグリーメントは基本的にサービス組織とユーザ間の契約であり、企業内部の部門間契約である運用レベルアグリーメント（Operational Level Agreement）と、外部企業との契約である基盤アグリーメント（Underpinning Contract）の2つがある。多くのサービスレベルアグリーメントは通常、他部門や外部のサプライヤによって支えられる。 1)　サービスレベルアグリーメントの前提としての、運用レベルアグリーメントや基盤アグリーメント締結が望ましい 2)　運用レベルアグリーメントで承認された以上のサービスレベルをサービスレベルアグリーメントでコミットする事は難しい 3)　サービスレベルアグリーメント締結時に、運用レベルアグリーメントや基盤アグリーメントの確認・見直しが必要なおサービスレベルアグリーメントでは、障害はカバーするが、災害（火災、地震）時の対応は通常記載しない。従って、別途災害対策計画書の作成が必要となる。

サービスレベルアグリーメントの要件 サービスレベルアグリーメントは、ユーザ要求仕様書等に記載したユーザのサービスに対する要求事項をもとに作成すること。また、現行のサービスレベル合意書（存在する場合）を考慮に入れること。 SLAが含む項目は、原則として下記の要領に従って記載すること。 1)　ユーザのために作成しているSLAが具体的で完全な形であること 2)　評価可能であること 3)　達成可能であること 4)　適切であること

サービスモデルアグリーメントの作成 計画フェーズにおいて、ユーザはユーザ要求仕様書の中で、サービス要求を記載しておかなければならない。ユーザによって要求されたサービス要求は、要求フェーズにおいてサービスモデルとして設計される。サービスモデルは、機能仕様書で文書化しておくこと。サービスモデルでは、サービス組織を組織するために必要であり、サービスレベル及びオペレーショナルレベルを定義し、サービスのコストを定義するために使用する。サービスモデルを作成するにあたって、サービスが自社内で供給できるか、または外部のサプライヤを利用しなければならないかを検討すること。サプライヤにサービスを委託する場合は、サプライヤオーディット等において以下を評価しておくことが望ましい。 1)　定義どおりにサービスを満たすことができるか 2)　要求するタイムフレームを満たすことができるか 3)　自社にビジネスや財務上のリスクを負わせないか 4)　該当するサービスに見合う経験をもっているか 5)　費用見積りに合うか 6)　バリデーション要求を満たすかサプライヤが上記の条件を満たす場合、原則としてサプライヤの標準的な条件と制約をレビュしておくこと。

サービスモデルアグリーメントの作成 サービスレベルアグリーメントは、機能仕様書に記載され承認されたサービスモデルに従って、運用フェーズ開始までに作成しなければならない。現行のサービスレベルアグリーメントが存在する場合は、それらを考慮に入れること。サービスのインプリメンテーションは、移行計画書中で計画しておくこと。またサービスレベルは事前にテストし、レビュしておくことが望ましい。この場合サービスレベルアグリーメントのレビュ結果は、サポート品質報告書に記載することになる。サービスレベルアグリーメントを文書化する場合には、次のような方法がある。 1)　サービスレベルアグリーメントの文書を単独で作成する 2)　保守契約書等に含める 3)　覚書に含めるサービスレベルアグリーメントはサービス組織が確実にサービスレベルを守ることの宣言になるが、対象となるユーザとの同意が必要になる。合意方法を定義する場合は次のことを検討する必要がある。 1)　サービスレベルアグリーメントの対象者と追加費用 2)　サービスレベルアグリーメント違反時の罰則、処置、報告方法 3)　サービスレベルアグリーメント合意の署名、捺印手順

サービスレベルアグリーメントの管理 • SLAは単に契約時に取り交わすばかりではなく、継続的なモニタリングが大切である。また、SLAを作成する場合も最初から委託側／提供側にとって最適なSLAを得ることは困難であり、締結したSLAを継続的・定期的に見直すことが望ましい。こうした活動をSLMという。 • サービスレベルアグリーメントは、あくまでサービス組織とサービス利用者側との合意によって形成される。 • そのため、両者間でサービスレベルアグリーメントの管理プロセスについても取り決める必要がある。 • 1)　モニタリング • サービスレベルアグリーメント項目に従ってモニタリングの設定と実施を行う。 • 2)　レポーティング • モニタリングの取得結果に基づいてレポートを作成する。 • レポートは主に次の2つに分類できる。 • (1)　サービスレベルアグリーメント違反レポート • (2)　定期運用レポート • 3)　結果レビュ • 作成されたレポーティングに対し結果レビュを実施する。 • ここではサービスレベルアグリーメント達成状況やサービスレベルアグリーメント違反についてレビュする。 • 4)　定期レビュ • 5)　サービスレベルアグリーメント／運用レベルアグリーメント／基盤アグリーメントの見直し • 各項目の目標値の見直し、前提条件確認、契約・合意内容の改訂を行う。

サービスレベルアグリーメント(SLA) 6. イントロダクション本SLAが提供するサービスを記述する。本セクションには、本SLAを作成するもとになるサービスモデルへの参照を記載すること。必要な場合は、提供しているサービス全体を構成するその他のあらゆるSLAへの参照を含めること。 7. 範囲除外する具体的な事項を挙げ、本合意書の範囲を特定すること。 8. サービスの記述システムのライフタイムの各フェーズに対し、提供するサービスの内容をユーザの理解可能な形で記述する。また、技術構成とシステムの主要機能の概要や参照も含むこと。システムのDS、つまりサービスに関連して、サービス組織やユーザ組織および社員の具体的な責任を含めるか、または参照しなければならない。 9. サービス項目サービスモデルから物理的なサポートのプロセス、相互規制サポートプロセス、サービスを反映しているプロセスのインターフェイスを特定する。また、サービスレベル対象を各項目に対して定義する。サービスレベル目標は評価可能でなければならず、サービスモデルのサービス手順のセクションにもとづいていること。 10. サービス項目の評価上記のセクション9. で定義している各サービス項目に対し、以下の事柄を明確にする。 10.1 評価対象 10.2 評価方法 10.3 責任者評価のまとめと評価報告に対する責任者 10.4 評価見積りまたは参照実際の評価見積りまたはその見積りへの参照 11. 報告サービスに関して、サービス管理側がユーザ側へ伝達する、サービスの評価に関する報告書のフォーマットや頻度を特定する。頻度は、提供するサービスのレベルに準ずること。 12. サービスのレビュサービスレビュの頻度と内容、およびレビュを行う役割の者を明確にする。サービスの予想が要求事項を満たしていることを保証するために、定期的にレビュを実行する。レビュのメカニズムおよび適切なフォーラム(例、月定例のサービスレビュ会議、サポート品質報告書の一環としてのSLAレビュなど)を特定する。サービスのレビュを行うグループには、以下の者を含むこと。

サービスレベルアグリーメント(SLA) 12.1 システムオーナープロジェクトフェーズ中の場合はスポンサー 12.2 サービスマネージャ 12.3 システムサポートマネージャ本SLAに関連するOLAに記載されている適切なサポートグループを代表するシステムサポートマネージャ 13. エスカレーションどちらか一方の関係者の要求を満たすことができない未解決の課題に対する段階的拡大プロセスを特定する。合意した場合は、エスカレーションプロセスに必要な具体的な項目を記述する。 14. 連絡先サービスに関して連絡する役割を持つ者、連絡可能時間および連絡方法を明確にする(例、ヘルプデスク、午前9時―午後5時、8888に電話)。

「バックアップリカバリー計画書」「サービスレベルアグリーメント」の書き方

「バックアップリカバリー計画書」「サービスレベルアグリーメント」の書き方

Presentation Transcript