Business Continuity and Disaster Recovery in Pharmacovigilance

A disruption in pharmacovigilance (PV) can affect patient safety and regulatory compliance before it looks like a major technology incident. A safety database may be unavailable while cases continue to arrive. A service provider may lose the staff or systems used for intake. A cyber incident may make an apparently intact backup unsafe to restore. An office closure may interrupt access to controlled procedures, trained personnel or regulatory communications.

A continuity plan must therefore answer an operational question: how will the organisation keep the necessary PV work moving, protect the information received, and recover with evidence that no safety item or obligation was lost? The plan should connect people, processes, systems, information and suppliers. A disaster-recovery document for infrastructure alone cannot answer that question.

This article provides a programme-level framework for EU human-medicines PV continuity. It complements the system-specific recovery discussion in Computerised System Validation in Pharmacovigilance, the supplier controls in Critical Vendor Management in Pharmacovigilance, and the technical reporting discussion in Electronic ICSR Submission and EudraVigilance. It focuses on how those controls fit together across the PV system.

1. Continuity, disaster recovery and PV obligations

Business continuity is the organisation’s ability to continue or resume priority activities at an acceptable level during a disruption. Disaster recovery is the recovery of information technology, data and supporting infrastructure after disruption. Incident management coordinates detection, classification, decisions, communication and escalation. The three capabilities overlap, but they solve different problems.

A safety database can be restored while staff still lack a safe process for cases received during downtime. Conversely, trained staff may continue to triage reports through an approved temporary process while IT restores a system. Continuity covers the end-to-end PV service; disaster recovery supports the systems and information on which that service depends.

For EU marketing authorisation holders (MAHs), Commission Implementing Regulation (EU) No 520/2012 requires appropriate instructions for processes to be used in case of urgency, including business continuity. The applicable consolidated text, amended by Regulation (EU) 2025/1466 from 12 February 2026, should be checked when procedures are reviewed. This is a requirement to provide appropriate instructions. It does not prescribe one universal business-continuity template, recovery time, recovery point, exercise interval or technical architecture. Those design choices must be set by the organisation in a risk-based way.

EMA GVP Module I provides guidance for the quality system, and EMA’s EudraVigilance electronic reporting guidance specifically advises organisations to have adequate business-continuity processes and backup systems for system failures. These sources support planned and tested arrangements; they do not replace the applicable reporting rules or instructions for a particular system incident.

Business continuity does not suspend pharmacovigilance responsibilities. Unless a competent authority or applicable law provides otherwise, the organisation should assume that intake, assessment, reporting, follow-up, safety evaluation and communication obligations continue during a disruption. The plan should explain what is prioritised, what approved workaround is used, who makes decisions, and how deferred work is tracked and completed.

The scope should include more than a central safety database. Relevant dependencies can include safety mailboxes and web forms, contact centres, medical-information and product-quality intake, affiliate networks, literature screening, study systems, EudraVigilance access, document repositories, identity and communications services, cloud hosting, power, facilities, specialist staff and subcontractors. The dependency map should reflect actual data flows and responsibilities, not just the application inventory.

2. Set continuity priorities from PV impact

A plan is useful only if it tells people what to protect first. The organisation should assess how disruption to each activity could affect patient safety, legal timelines, signal evaluation, risk minimisation, data integrity, inspection access or other critical commitments. This assessment is sometimes called a business-impact analysis (BIA). It should connect PV process consequences to the resources and dependencies needed for recovery.

2.1 Identify essential PV activities

The assessment should consider the full safety-information lifecycle. Depending on the organisation and portfolio, priority activities may include:

• receiving and recognising potentially reportable safety information;
• recording source details, receipt dates and other clock-relevant facts;
• medical triage and prioritisation of serious or otherwise urgent information;
• case follow-up and processing needed to meet applicable submission timelines;
• electronic reporting and monitoring of acknowledgements or rejections;
• monitoring safety sources and evaluating new information that may affect benefit-risk;
• urgent safety communications, authority responses and implementation of required actions;
• access to current procedures, reference safety information and controlled records;
• QPPV oversight, escalation and communication with competent authorities where required; and
• restoration of affected datasets and reconciliation of work completed through temporary channels.

The list should be tailored. A small MAH with a single critical vendor may have a different continuity profile from a global MAH with multiple databases, local affiliates, outsourced intake and round-the-clock safety operations. A low-volume activity can still be critical if missing it could delay a serious case or an urgent safety action.

2.2 Map dependencies and failure modes

For each priority activity, identify the people, information, premises, technology, suppliers and decisions it depends on. Record the failure modes that could interrupt it, including simultaneous failures. For example, an identity-provider outage can block access to several otherwise available systems; a cyber incident can make both production systems and connected backups untrustworthy; a vendor closure can interrupt both intake and the records needed to process that intake.

Assess likelihood and impact, but also consider how quickly harm or non-compliance could arise, whether an alternative route exists, and how long the process can safely operate in a reduced mode. A risk register that lists “IT outage” without identifying affected PV activities, reporting queues and fallback owners is not enough to guide activation.

2.3 Define recovery objectives as internal targets

Two common planning measures are:

• Recovery time objective (RTO): the target time to restore an activity or service after disruption.
• Recovery point objective (RPO): the maximum acceptable period of data loss, measured against the last recoverable point.

A maximum tolerable period of disruption may also be used to identify when the impact becomes unacceptable. These are planning tools, not PV-specific statutory values. The organisation should set them for individual services based on the impact assessment, applicable PV deadlines, the amount and type of information at risk, and the viability of temporary procedures. A single RTO for “the safety system” can obscure different needs for intake, report assessment, electronic submission, source document retrieval and signal review.

Recovery objectives should be realistic and testable. If the stated RTO is four hours but the provider’s contract, restoration design or trained coverage cannot support that target, the plan creates false assurance. If the RPO allows a period in which new cases may disappear, the organisation needs a separate controlled intake route to capture them during the gap.

3. Prepare the continuity operating model

A continuity plan should be executable under pressure. Staff must know how an incident is declared, which plan applies, how work changes, who has authority to decide, and how the temporary record will later be brought back under normal controls.

3.1 Define activation, severity and decision rights

Define events that trigger assessment, escalation or activation. Examples include a PV application outage, loss of a safety intake channel, inaccessible site, inability of a critical service provider to perform, a cyber event affecting data integrity, or a staffing disruption that removes a critical capability. Not every event requires full activation. The trigger model should distinguish a recoverable local issue from an incident that could affect deadlines, safety review, data integrity or multiple products.

The incident lead coordinates the response and maintains an event timeline. PV operations identify affected activities, cases and obligations. IT or security leads technical containment and restoration. The QPPV or designated PV leadership assesses PV impact and ensures appropriate oversight. Quality supports deviation assessment, controlled procedures and corrective action. Legal, Privacy, Regulatory Affairs, communications, procurement and vendor owners join when their decisions or reporting obligations are relevant.

The plan should identify primary and alternate contacts, decision authority, escalation routes, approval limits and who can invoke or stand down each mode. Where a QPPV is unavailable, a continuity arrangement must not be confused with an automatic transfer of a regulated appointment. Maintain the applicable QPPV and deputy arrangements, authority contact details and escalation procedures, and follow the rules governing any formal change.

3.2 Preserve intake and clock-relevant information

When the routine channel is unavailable, the organisation needs an approved route for receiving safety information and capturing enough facts to process it later. The route might use an alternate monitored mailbox, telephone line, secure form, affiliate contact or pre-approved manual log. The choice depends on the failure and the organisation’s controls. Staff should not improvise by sending patient information to personal accounts, unapproved consumer services or unprotected spreadsheets.

The temporary process should preserve, at minimum, the source and contact details available, product, event information, first receipt date and time, receiving channel, recipient, seriousness cues, attachments or source location, transfer attempts and any action taken. Record the actual event timestamp and time zone where relevant. If a clock-relevant element is missing, follow the approved process for obtaining it and escalating uncertainty. Do not replace the original receipt date with the later date of entry into the restored database.

A controlled downtime log needs a unique temporary identifier, access restrictions, version or correction history, owner, backup location and instructions for transfer to the safety system. Design the log to prevent duplicate entries and preserve attachments. Assign a person to monitor the alternate channel and an alternate person to cover absence; an unmonitored emergency mailbox is not a functioning fallback.

3.3 Prioritise without losing lower-priority work

During continuity mode, triage should direct attention to cases and obligations where delay could have the greatest patient or regulatory impact. Serious, medically urgent or deadline-sensitive information may require immediate review, while routine work is queued. The procedure should state who can reprioritise and how the rationale is recorded. Prioritisation is a way to manage constrained capacity; it is not an undocumented decision to discard or indefinitely defer other work.

The backlog should be visible by item, status, assigned owner, received time, due date or applicable deadline, priority, next action and escalation status. Report volume and staffing capacity should inform whether additional resources, alternate providers or management decisions are needed. Where the interruption continues, reassess the workload and deadline risk rather than assuming the initial estimate remains valid.

3.4 Maintain essential external and internal communications

Keep current contact paths for vendors, affiliates, competent authorities, study partners and internal functions that may need to act. Decide who can issue an incident notice, what facts must be confirmed first, which communications need legal or privacy review, and how updates are logged. A system outage does not by itself mean that a regulator must be notified; notification depends on the applicable rule, incident type, impact and established procedures.

Communications should distinguish confirmed facts from estimates. If an incident affects a specific reporting channel, consult the channel owner’s current official status page and instructions. Do not create an alternative reporting route to an authority unless the authority or applicable procedure directs it. The existing EudraVigilance reporting guidance covers technical submission arrangements and acknowledgements.

4. Recover technology and return to controlled operations

Technology recovery is part of PV continuity, but restoring a service is not the same as proving that it is safe and complete. Recovery must address confidentiality, integrity, availability, system validation, record traceability and the fate of work performed during downtime.

4.1 Restore in a controlled order

A restoration sequence should reflect PV dependencies and the incident’s cause. It can include identity and network access, secure communications, intake channels, safety databases, document repositories, interfaces, reporting tools and analytics. The sequence should be agreed by the relevant PV, IT, security and business owners, with dependencies and recovery criteria recorded.

For a suspected cyber incident, restoration decisions must follow the security incident process. Do not reconnect a system or restore from a backup merely because it is available. Confirm that containment, forensic preservation, identity controls, recovery source integrity and the required technical approvals have been addressed. This protects PV information from reinfection, unauthorised change or loss of incident evidence.

After technical restoration, system owners should perform checks appropriate to the service: access and role controls, interface status, data integrity, audit trail operation, time synchronisation, configuration and validation status, and representative processing or transmission tests. If the intended use or validated state may have changed, use the applicable change-control and validation process before relying on the system for regulated PV work. See Computerised System Validation in Pharmacovigilance for system lifecycle controls.

4.2 Reconcile temporary work with recovered systems

Every item handled during downtime needs an explicit disposition. Transfer source material and log entries through the approved process; link the temporary identifier to the permanent case or record identifier; check for duplicates and missing attachments; preserve original receipt and action timestamps; and verify the resulting case status and any submission acknowledgement. The process should also identify reports received through routine channels that may have been queued, delayed, rejected or left unprocessed.

Use a defined reconciliation population, such as all items received or due during the incident period plus items in any affected system queue. Compare source logs, alternate channels, provider records, database entries and submission evidence where relevant. Resolve every mismatch, not merely the total count. If an item cannot be matched, investigate the source and document the impact assessment and disposition.

The response should retain both the temporary and restored evidence needed to reconstruct what occurred. The manual log should not become a parallel permanent case database; once controlled transfer and verification are complete, close or archive it according to the approved procedure and applicable record schedule.

4.3 Decide when normal operations resume

Define the criteria for returning to routine processing. They may include stable system availability, completed technical verification, successful processing of representative items, safe user access, working interfaces, confirmed provider capacity, staffing readiness, and an understood backlog with owners and deadlines. The incident lead and accountable PV or system owners should document the decision and any restrictions.

A phased return can be appropriate. For example, a team may resume new case intake first, then process the backlog, then restart lower-priority analytics after confirming data feeds. The plan should specify how to monitor for repeat failure and who can re-enter continuity mode. Record the stand-down time, residual limitations and any temporary controls that remain in force.

5. Test the plan as an operational capability

A continuity plan that has only been approved on paper may not work when invoked. Testing should evaluate people, decisions, alternate channels, system recovery, suppliers and the return to normal operations. The appropriate method and frequency depend on risk, change and applicable requirements; avoid relying on an untested assumption that one exercise format covers every failure mode.

5.1 Use complementary exercise types

• Tabletop exercise: participants work through a realistic scenario, such as a safety database outage near a reporting deadline, and explain decisions and handoffs.
• Process simulation: staff use the real downtime forms or alternate channels to intake, triage and assign sample records without affecting live case data.
• Technical recovery or failover test: system and provider teams restore a service or switch to an alternate environment under controlled conditions.
• End-to-end exercise: participants test detection through continuity activation, temporary work, recovery, reconciliation and stand-down.

An exercise should have defined objectives. For example: can a report be received and timestamped; can the serious-case queue be identified; do staff know whom to alert; can an alternate process protect due work; can the restored system accept records without loss or duplication; can every temporary item be reconciled? Choose scenarios that reflect the organisation’s actual architecture and dependencies.

Avoid exercises that merely confirm that a backup file exists or that a phone number works. A successful technical failover says little about whether PV staff know what to process or whether the backlog can be reconciled. A tabletop can test decisions and role clarity but does not prove that the recovery environment will function. Match the exercise to the control being tested.

5.2 Measure outcomes and correct weaknesses

Record scenario, scope, participating teams and suppliers, assumptions, success criteria, timing, observations, decisions, failures, corrective actions and owners. Useful measures may include time to detect and activate, time to make the alternate route usable, number of test items captured, completeness of recovery, time to reconcile, unresolved mismatches, and whether escalation reached the appropriate decision-maker.

A result should be assessed against the objective rather than labelled “pass” because an exercise was completed. If a target was missed, determine whether the plan, technology, contract, training, capacity or governance caused the gap. Raise material issues through the quality system, assign corrective actions and retest the affected capability. Update procedures, contact lists and training after organisational, system, vendor or regulatory changes.

Testing must be safe and controlled. Use synthetic or appropriately protected data unless a validated exercise design and approvals permit controlled live transactions. Agree with vendors and regulators in advance where an exercise could affect production processing, create external messages or resemble an actual incident.

6. Manage people, vendors and wider dependencies

PV continuity can fail even when the database is available. The organisation should assess whether it has enough trained people, authority, premises, secure access and external support to operate during a disruption.

6.1 Plan for staff and site disruption

Identify tasks that depend on a single person, site, time zone or specialist skill. Maintain trained alternates for critical activities, procedures accessible outside the primary office, secure remote-work capability, and a method for confirming staff availability. Cross-training should be practical: alternates need access, current training and permission to perform the defined tasks, not just a name on a roster.

Consider loss of office access, power, telecommunications, transport, regional crisis, simultaneous staff illness, or disruption to local language coverage. Define how the organisation will preserve intake, escalation and time-sensitive decisions if normal working arrangements are not possible. Remote operation should retain confidentiality, access control, secure communications and oversight rather than bypassing them.

Where the QPPV’s usual working location or access is disrupted, use the documented continuity and escalation arrangements. Keep the QPPV informed of material incidents and their effect on PV performance. Senior management should make resources available when the incident exceeds routine team capacity. The QPPV’s awareness, advice and escalation should be documented; this is not a substitute for role-specific legal requirements or formal authority notifications.

6.2 Integrate supplier continuity with MAH accountability

Contracts and oversight should support continued performance, access to data, communications, subcontractor visibility, recovery evidence and orderly exit. The MAH should know whether a vendor’s plan covers the service on which PV depends, whether the vendor has tested it, what the MAH must do to activate it, and whether subcontractors or cloud services create additional dependencies.

Vendor service-level metrics can inform oversight but do not prove end-to-end PV continuity. A supplier may restore its platform within a technical service target while the MAH cannot access the case queue, lacks the records needed for processing, or has no trained alternate. Align the vendor recovery design with PV activity priorities and the MAH’s own recovery objectives. For detailed supplier classification, controls and inspection evidence, use Critical Vendor Management in Pharmacovigilance.

Include vendor failure, loss of subcontractor capacity, contract dispute, insolvency, cyber incident and failed data transfer in continuity planning where relevant. Identify what the MAH can continue itself, what may be moved to an alternate provider, and what information is needed to make the transition. A contingency that depends on an untested provider or a former employee’s account is not a reliable contingency.

6.3 Keep critical PV information available

Staff need controlled access to current procedures, contact lists, product and reference safety information, escalation criteria, vendor arrangements, and the information needed to process or prioritise work. These materials should be available through an approved route even when the primary repository is unavailable. Avoid unmanaged local copies that may be outdated or expose personal data; define how emergency copies are controlled, updated and withdrawn.

Where safety datasets are replicated or exported for recovery, define the permitted purpose, access, refresh, reconciliation and deletion rules. A second location reduces some availability risks but can introduce data-integrity and privacy risks if updates diverge or access is broader than necessary. Test that recovery copies can be restored and interpreted, and that they are subject to controlled access and change.

7. Learn from incidents and demonstrate oversight

An actual disruption is a test of the system, even if no formal exercise was planned. Record what happened, which PV activities were affected, what continuity mode was used, how cases and obligations were protected, what was communicated, what remained unresolved and how normal operations resumed.

7.1 Illustrative scenario: safety database unavailable

A global MAH’s safety database becomes unavailable after a failed infrastructure change. Reports continue to arrive through affiliates and a monitored alternate mailbox. The incident lead activates the relevant continuity procedure. PV operations assign unique temporary IDs, preserve original receipt times, and triage the incoming items using approved criteria. The QPPV receives an impact summary, including the affected products, known deadlines, backlog volume and vendor recovery estimate.

IT restores the service only after verifying the environment and confirming the incident cause is controlled. PV staff test representative access and processing, then transfer temporary items to the restored system. A reconciliation compares the alternate mailbox and downtime log with restored cases and affected queues. Unmatched items are investigated individually. The team documents remaining deadline risk, notifies other functions through the established route, and stands down only after agreed recovery criteria are met.

This is a hypothetical example. It does not prescribe one database architecture, reporting fallback or activation threshold. It illustrates the connections between intake, prioritisation, technical recovery, QPPV oversight and post-recovery reconciliation.

7.2 Use incident and exercise evidence to improve controls

A useful incident record includes the timeline, detection source, severity and scope decisions, impacted services and products, relevant case or work queues, plan activation, actions and approvals, communications, recovery evidence, data reconciliation, residual risks, root-cause analysis and corrective actions. Keep the evidence connected to affected PV processes and quality records.

Review whether temporary workarounds preserved the data required for normal processing, whether escalation happened soon enough, and whether the backlog was identified completely. Distinguish cause from contributing conditions. A vendor outage may be the trigger, while an untested contact path, unclear activation authority or missing alternate staffing is a system weakness that the MAH can address.

The QPPV and PV governance forum should receive information proportionate to impact. Material incidents, near misses, repeat failures, missed recovery objectives, significant data-integrity concerns, reporting risk and overdue corrective actions warrant defined escalation. Trends across tests and incidents can reveal common dependencies, such as a single identity provider or a single trained case-processing team.

7.3 Prepare to explain continuity during inspection

An inspector may ask how the organisation knows a PV service is critical, how the plan protects time-sensitive obligations, how a disruption is escalated to PV leadership, what happened to records during downtime, how the system was verified after recovery, and how the organisation demonstrated that no safety information was lost. The current GVP Module III describes inspection scope and the examination of PV-system functioning, records, subcontractors and data access; use the revision in force at the time of inspection.

Demonstrate an actual path through the plan and its evidence: the impact assessment, approved procedure, assigned roles, exercise or incident record, provider evidence, downtime log, recovered records, reconciliation and corrective-action closure. A policy statement that “business continuity is in place” is weaker than proof that the process can be executed and that lessons have changed the system.

8. Implementation checklist

Governance and impact assessment

• Are PV processes and dependencies mapped from intake through assessment, reporting, evaluation and communication?
• Are disruption scenarios linked to patient-safety, compliance, data-integrity and inspection consequences?
• Are recovery objectives set for the relevant activity or service, supported by realistic technical and staffing arrangements?
• Are activation authority, escalation routes, alternate contacts and QPPV involvement documented?
• Are applicable quality, privacy, information-security and regulatory processes connected to the plan?

Continuity operations

• Can staff use an approved alternate channel if the routine intake route is unavailable?
• Does the downtime process preserve source, timestamps, clock-relevant information, attachments, prioritisation and ownership?
• Can urgent work be identified without losing visibility of the remaining backlog?
• Are temporary records protected, controlled, unique and suitable for later transfer?
• Are authority and partner communications accurate, authorised and logged?

Recovery and resumption

• Are technical recovery, security clearance, validation and business acceptance responsibilities clear?
• Are recovery criteria based on the service’s intended use and incident cause?
• Is there a defined population and method for reconciling temporary work, queues and submissions?
• Are unmatched or missing items investigated and assessed individually?
• Is stand-down approved, documented and followed by monitoring for residual issues?

Testing and improvement

• Do exercises test both PV process continuity and technology recovery?
• Are actual vendors, alternate staff and critical handoffs included where relevant?
• Are exercise objectives, results, failed controls and corrective actions recorded?
• Are plans updated after incidents, exercises, system or vendor changes, and organisational changes?
• Does PV governance review significant incidents, recovery performance and overdue actions?

9. Key takeaways

• PV continuity is an end-to-end capability involving people, processes, technology, data, suppliers and governance.
• EU rules require MAHs to provide appropriate instructions for urgent processes, including business continuity. They do not set one universal RTO, RPO, plan template or exercise frequency.
• Continuity and disaster recovery are related but distinct: one keeps priority PV activities moving; the other restores supporting technology and information.
• Reporting and safety obligations should be treated as continuing during an outage unless a competent authority or applicable law says otherwise.
• Temporary work needs approved channels, clock-relevant timestamps, controlled logs, clear ownership and a complete reconciliation into normal systems.
• A restored system should not be used for regulated work until appropriate security, integrity, access and system checks are complete.
• Exercise evidence should show whether the capability worked, what failed and how corrective action was verified.
• The QPPV and PV governance need timely visibility of material interruptions and the resulting compliance or patient-safety risk.

References

1. European Commission. Commission Implementing Regulation (EU) No 520/2012, consolidated text applicable from 12 February 2026, especially Article 10 and the quality-system provisions for marketing authorisation holders.
2. European Commission. Commission Implementing Regulation (EU) 2025/1466 amending Regulation 520/2012.
3. European Medicines Agency. Good pharmacovigilance practices (GVP), Module I: Pharmacovigilance systems and their quality systems, especially I.B.11.3 on contingency planning; read with current applicable legislation.
4. European Medicines Agency. EudraVigilance electronic reporting, including “What to do in case of system failure.”
5. European Medicines Agency and Heads of Medicines Agencies. GVP Module III: Pharmacovigilance inspections (Revision 2, 4 September 2026).
6. European Parliament and Council. Regulation (EU) 2016/679 (General Data Protection Regulation), especially Article 32 where PV activities process personal data.

Regulatory Note

This article is an operational guide to business continuity and disaster recovery in the EU human-medicines pharmacovigilance context, reviewed on 3 October 2026. The legal requirement described is that MAHs provide appropriate instructions for processes used in case of urgency, including business continuity. Recovery objectives, incident roles, alternate channels, exercises, reconciliation methods and governance practices are implementation approaches; the legislation does not prescribe universal values or formats. Applicable reporting duties, system instructions, national rules, data-protection and security requirements should be assessed for the specific organisation and incident.