Velkommen IFF 2016.09.06 GMP Disaster Recovery
Agenda Terminologi Regler, Guidelines og Whitepapers Egne interesser (Business Continuity) Disaster strikes Test af Disaster recovery Inspektion af Disaster Recovery Summary og spørgsmål
Hvem underholder? Christian Stage IT siden 1987 Automation siden 1992 Pharma siden 1992 Stage One Computing: QA målrettet imod IT og Automation
Terminiologi Backup Kopi af data, parametre og opsætning, samt lager af relevante identiske hardwarekomponenter
Terminiologi Restore point Seneste kendte kontrollerede gode kopi af data, parametre og opsætning, samt lager af kontrollerede relevante identiske hardwarekomponenter. Markerer disaster begyndelsespunkt.
Terminiologi Disaster Situation hvor anlæg, system eller data ødelægges eller bliver utroværdige (korrumperes), og derved gør det pågældende system, anlæg eller data ubrugelige i relation til produktion i et valideret stade.
Terminiologi Recovery At bringe et system, anlæg eller data tilbage til et operativt brugbart stade.
Terminiologi Disaster Recovery En veldefineret process til at modvirke afbrydelser af forretningsaktiviteter, og beskytte kritiske forretningsprocesser fra effekten af et større nedbrud i mekaniske komponenter eller IT systemer, samt at sikre betidelig genoptagelse af normal operativ situation.
Terminiologi Restore validated state At bringe et system, anlæg eller data tilbage til et operativt brugbart stade. Markerer afslutningspunkt for Disaster
Terminiologi Påvirket periode Work around? Disaster Retur til normal Disaster Recovery Disaster Recovery Plan Business Continuity Plan
Disaster recovery Regler Eudralex 1. Risk management Risk management should be applied throughout the lifecycle of the computerised system taking into account patient safety, data integrity and product quality. As part of a risk management system, decisions on the extent of validation and data integrity controls should be based on a justified and documented risk assessment of the computerised system.
Disaster recovery Regler Eudralex 7.1 Data should be secured by both physical and electronic means against damage. Stored data should be checked for accessibility, readability and accuracy. Access to data should be ensured throughout the retention period.
Disaster recovery Regler Eudralex 7.2 Regular back-ups of all relevant data should be done. Integrity and accuracy of backup data and the ability to restore the data should be checked during validation and monitored periodically.
Disaster recovery Regler Eudralex 13. Incident Management All incidents, not only system failures and data errors, should be reported and assessed. The root cause of a critical incident should be identified and should form the basis of corrective and preventive actions.
Disaster recovery Regler Eudralex 16. Business Continuity For the availability of computerised systems supporting critical processes, provisions should be made to ensure continuity of support for those processes in the event of a system breakdown (e.g. a manual or alternative system). The time required to bring the alternative arrangements into use should be based on risk and appropriate for a particular system and the business process it supports. These arrangements should be adequately documented and tested.
Disaster recovery Regler Eudralex 17. Archiving Data may be archived. This data should be checked for accessibility, readability and integrity. If relevant changes are to be made to the system (e.g. computer equipment or programs), then the ability to retrieve the data should be ensured and tested.
Disaster recovery Regler FDA N/A!
Guidelines PIC/S 19.3 The examination of the procedures and records should assure that the following basic requirements are satisfied: Measures are needed to ensure the validated recovery of original information and data following back up, media transfer, transcription, archiving, or system failure.
Guidelines PIC/S 19.6 There should be written procedures for recovery of the system following a breakdown; these procedures should include documentation and record requirements to assure retrieval and maintenance of GxP information. The examination of the procedures and records should assure that the following basic back up and disaster recovery requirements are satisfied: Procedure for regular testing, including a test plan, for back up and disaster recovery procedures should be in place. A log of back up testing including date of testing and results should be kept. A record of rectification of any errors should be kept.
Guidelines PIC/S INSPECTORS - PREPARING FOR AN INSPECTION 10. Details of disaster-recovery, back up, change-controls, information security, and configuration management.
Guidelines NIST
Guidelines WHO
Regler og Guidelines Summary
Årsag til disaster Naturkatastrofer o.l. Virus Software fejl Menskelige fejl Hardware fejl 3% 7% Kan minimeres med vaidering! 13% 44% 33%
IT Disaster recovery Sværhedsgrad af problemstillinger Lettere Automatik Sværere
Typer af problemstillinger 3 typer disaster recovery HW SW Data Baseline Backup System
Specielle udfordringer
Specielle udfordringer
Specielle udfordringer
Specielle udfordringer
Lagdeling af problemstillinger Procedurer for Backup og Recovery Disaster Recovery Plan Business Continuity Plan
Backup/restore/recovery Praktisk udførte processer jf. godkendte procedurer Kontrol af readiness Findes data Er det de korrekte Er de up-to-date Er der udstyr til at gøre det med (kabler, software, hardware) Er udstyret parat (eller ligger det på en CD og skal installeres først)
Disaster Recovery (+ Plan) Periodisk review Test af beredskab Beskriver backup/restore/disaster recovery procedurer Tab af hele systemer Tab af data/hardware etc. Definerer sikkerhed mod tab af data, produktion, tid eller penge Incident management
Business Continuity Plan Definerer minimumsbetingelser for et operativt miljø under nedbrud Minimerer antal af forstyrrelser i produktionen Benyttes til at vurdere hvor lang nedetid at system kan tåle Minimerer potentielt tab Definerer overordnede strategier og procedurer for nedbrud Opretholder kritisk produktion under nedbrud Planlægning af incident management Hvorledes håndteres datatabet
Eksempel på business continuity plan Level 1 Workflow Start Understand business BC/ DR scope Develop BC strategy Initiate BC & Dr Review architecture Implement changes Embed DR (Disaster Recovery) End Level 1 Level 3 Business continuity & disaster recovery objectives BCP&DRP test / actual incident reports Level 2 Start Define security governance structure Define contractual requirements & scope management Analyze business impacts Evaluate alternative approach to enable disaster recovery Process change management as per key outputs Plan assurance & maintenance activities Updated BC plan & DR plan Level 2 Workflow New/ changed services Agreed security standards, policies and procedures Analyzed business/ technology impacts Asses risks & identify likely threats Identify architecture changes Develop & test specific recovery procedures Business Continuity Plan Testing Accident or natural disaster Develop response procedures (crisis management) Schedule audit & assurance plans Improved BC & DR End Key Interactions Input Process external to ITOM Key Triggering Events Input Outcomes Level 1 Activity Level 2 Activity Decision Points Process Outcome
Risikovurderingen Baseres på faktiske data hvis disse er tilgængelige Kendte nedbrud af tilsvarende systemer Hvad er prisen på et nedbrud Hvor sandsynligt er det at det sker
Life cycle management og baseline Life cycle management Vugge til grav (dvs. hele livscyklus) Pas på med restore at der ikke smutter udgåede data med Baseline er værktøjet Demonstrerer kontrol Bortskaffelse Skabelse Arkivering
Eksempler og løsninger Redundans Like-for-Like Kompatibel Identisk Rationaler Styr på leverandøren
Revurdér planen
Restoretest - hvornår? Store risici ifm. valideringsaktiviteter Kan påvirke tidsplan Kan ødelægge udført validering 2 gode tidspunkter under initialvalidering Kvalificeres i forbindelse med FAT Som en del af IQ
Inspektion af disaster recovery Hvad skal man kigge efter ved inspektion? Findes der en riskiovurdering der bla. omfatter Disaster recovery? Er retentionsperioden defineret? Findes der en kontrol af datas læsbarhed? Er der en tilbagevendende vurdering af teknologiens egnethed? Vurderes evnen til at udføre en recovery/restore periodisk? Hvorledes håndteres incidents (incident management)? Hvorledes håndteres business continuity under nedbrud? Er der en risikovurdering forbundet med business continuity?
Tak for i dag