Pharmacovigilance Record Retention and Archiving
A pharmacovigilance (PV) record may outlive the system, supplier or organisation that first created it. A case file can be needed years after submission to explain what was reported, how it was assessed and whether the right action followed. A safety decision may depend on the version of a document, the data available at the time and the rationale recorded by the decision-makers. Keeping a file is therefore only one part of retention. The record must remain identifiable, complete, readable, protected and retrievable for as long as it is required.
This article focuses on records created or used in the EU human-medicines PV system. It explains the principal EU retention rules and a practical lifecycle for setting schedules, preserving records, migrating systems, retrieving evidence and controlling destruction. It complements the cross-system controls in Pharmacovigilance Reconciliation, but addresses what happens to evidence after creation and handoff.
- Pharmacovigilance Record Retention and Archiving
- 1. What retention and archiving mean in pharmacovigilance
- 2. Regulatory framework and scope
- 3. Build a retention schedule by record class
- 4. Preserve record integrity, context and provenance
- 5. Maintain retrieval through system and supplier changes
- 6. Manage triggers, holds and controlled destruction
- 7. Governance and inspection readiness
- 8. Implementation checklist
- 9. Key takeaways
- References
- Regulatory Note
1. What retention and archiving mean in pharmacovigilance
Retention is the period during which an organisation must or has decided to keep a record. Archiving is the controlled preservation of records that are no longer needed for routine work but must remain available for reference, accountability or legal and regulatory purposes. An archive may be electronic, paper-based or hybrid.
A retention schedule answers at least four questions: which records are covered, what event starts the period, how long the record remains in scope, and what happens when the period ends. An archive then implements those decisions while preserving the record’s identity, integrity, context and retrievability.
This lifecycle is different from a backup. A backup is designed to restore systems after data loss or disruption. It may be overwritten according to a short recovery cycle and may not preserve record context, searchability or an evidentiary trail. An archive is intended to preserve designated records for a defined period and support their later interpretation and retrieval. Backups can support resilience, but they do not by themselves demonstrate compliant record retention.
A PV record may include more than a final database entry. Depending on the activity, it can include original intake material, correspondence, follow-up, medical assessment, coding, narrative versions, transmission and acknowledgement evidence, signal or aggregate assessment documents, decision records, controlled procedures, training evidence, vendor outputs and system audit trails. The record set should be sufficient to reconstruct the relevant process and decision without retaining every transient working copy indefinitely.
2. Regulatory framework and scope
For EU human medicines, Commission Implementing Regulation (EU) No 520/2012, as amended by Commission Implementing Regulation (EU) 2025/1466, sets binding requirements for PV record management and retention. The consolidated text applicable from 12 February 2026 is the starting point for current EU requirements. The legal framework requires an MAH record-management system for documents used in PV activities, with retrievability and traceability of safety investigations, their timelines, and decisions—including decision dates and the decision-making process. It also specifies minimum retention periods for defined PV records. See Article 12 of the consolidated Regulation in the References.
EMA Good Pharmacovigilance Practices (GVP) Module I provides guidance on PV-system quality and records. It should be read alongside current legislation. Where older GVP wording and amended legislation differ, the applicable legal text controls; check for later GVP updates before applying detailed guidance. GVP Module II separately addresses the Pharmacovigilance System Master File (PSMF), including its content and maintenance. The PSMF is part of the record landscape, but its specific rules should not be substituted for the broader Article 12 schedule.
Other rules may apply to a record for reasons beyond PV legislation. Examples include national laws, clinical-trial requirements, product-specific obligations, litigation or regulatory proceedings, data-protection law, and contractual commitments. A clinical-study record, for example, may be governed by a separate trial-file schedule in addition to its PV use. A global company may also need to meet requirements in more than one jurisdiction. The schedule should identify the applicable rule and scope rather than assume that a single EU period governs every copy and every record class.
The article uses four labels:
- Legal requirement identifies an obligation established in legislation.
- Regulatory guidance identifies recommendations or interpretation in GVP or other official guidance.
- Operational practice identifies a control that an organisation can adopt to make compliance demonstrable.
- Illustrative example describes a hypothetical situation rather than a reported inspection finding.
This distinction matters because a prudent operational control—such as an annual retrieval exercise—is not automatically a statutory interval. It should be justified by risk, documented in the quality system and applied consistently.
3. Build a retention schedule by record class
A retention schedule translates legal and business requirements into controlled record rules. A single “PV records” row is rarely sufficient. Different records can have different owners, systems, triggers, formats and governing requirements. The schedule should define categories that staff and system administrators can apply reliably, without requiring them to interpret legislation each time a folder is closed.
3.1 Start with an inventory and authority
Inventory the records created, received or relied on across the PV system. Include records held by affiliates, service providers, license partners and other organisations acting on the MAH’s behalf. For each class, identify:
| Schedule field | What to define |
|---|---|
| Record class and purpose | What the records document and which PV process uses them |
| Authoritative copy | The system or repository that holds the controlled record |
| Record owner and custodian | The business owner and the person or function responsible for storage and retrieval |
| Applicable authority | EU or national law, GVP guidance, other sector rules, agreement or documented business rationale |
| Retention trigger | The dated event from which the period runs |
| Retention period | The minimum period, any longer requirement and the rule used to calculate expiry |
| Access and format | Authorised roles, readability, metadata and any specialised viewing software |
| Hold and disposal rules | How expiry is suspended, reviewed, approved and evidenced |
Record classes may include individual case files; PV-system and PSMF records; signal, aggregate-reporting and risk-management evidence; study-related safety records; safety agreements and vendor oversight; training and qualification records; procedures and change history; audit and inspection evidence; and system validation, access and audit-trail records. Classification should reflect both the record’s regulatory purpose and the systems that hold it.
3.2 Apply the EU human-medicines minimums precisely
Article 12(2) of Regulation 520/2012 provides two distinct minimums for MAHs:
- The elements referred to in Article 2 must be kept for at least five years after the PV system described in the PSMF has been formally terminated by the MAH.
- PV data and documents relating to individual authorised medicinal products must be retained for as long as the product is authorised and for at least ten years after the marketing authorisation has ceased to exist.
These periods have different scopes and different start events. The first concerns the specified Article 2 elements and starts after formal termination of the PV system. The second concerns product-related PV data and documents and runs while the product is authorised, then for at least ten years after that authorisation ceases to exist. Do not treat “five years” as the general PV-record period or start the “ten years” at case receipt, case closure or the date a file is moved to an archive.
The periods are minimums, not permission to destroy a record when another applicable rule requires longer retention. Article 12 also requires the record-management system to support retrieval and traceability. A period in the schedule is not useful if the record becomes unreadable or its relationship to the product, process or decision is lost before expiry.
3.3 Separate overlapping records and systems
One event may generate records in several classes. A safety case may be stored in the global safety database, in an intake mailbox, in a partner’s system and in a document repository. A signal assessment may cite cases, literature, meeting minutes and a final decision. The schedule should identify the controlled record for each purpose and explain whether supporting evidence is retained with it, linked to it or held in a separate repository.
Avoid creating competing “official” copies without a defined relationship. If one repository is authoritative and another is a convenience copy, label that distinction, maintain the link and define what happens to each copy at expiry. Where a vendor retains source material, the agreement should identify the records, retention responsibilities, access, export format, return or transfer at termination, and destruction evidence. Outsourcing changes custody, not the MAH’s need to demonstrate appropriate oversight.
A schedule owner should periodically reconcile categories against actual systems, agreements and process maps. New products, acquisitions, system replacements, process changes or a vendor exit can create records that were not covered by the original schedule. Change control should update the schedule and communicate resulting handling rules to process owners and custodians.
4. Preserve record integrity, context and provenance
Retention is meaningful only if a record remains trustworthy. The archived material should preserve what was known, when it was known, what changed, who acted, and why a safety decision was reached. This does not mean that every PV document needs the same technical controls. It means controls should be proportionate to the record’s significance and consistent with the applicable quality system.
4.1 Keep the evidence needed to reconstruct the process
For a case file, relevant evidence may include the original report or source document, receipt and awareness dates, follow-up requests and replies, case versions, medical review, coding decisions, narrative history, submission records and acknowledgements. For a safety assessment, it may include the data cut-off, input set, analytical documents, meeting records, decisions, actions and approvals. The exact record set depends on the process and applicable rules.
Preserve links between related records. A case identifier, product identifier, document version, activity date and decision reference can allow an inspector or reviewer to follow the chain from source through assessment to action. When a record is stored in several systems, document the relationship and the authoritative version. A detached PDF of a final report may not explain which source data, comments or approvals led to it.
Corrections should not silently erase the history needed to understand prior actions. Use the controlled correction and versioning mechanism of the system, retain relevant audit-trail information, and ensure that the current record is distinguishable from superseded material. Do not preserve unnecessary duplicate working files merely to appear comprehensive; define which versions are evidence and which are transitory drafts under the approved procedure.
4.2 Protect metadata and audit trails
Metadata can be essential to interpretation. Examples include the creator or source, creation and receipt timestamps, product and case identifiers, document status, version, approval status, transfer dates and relationships to other records. Date and time values should retain enough context to interpret them, including time zone where relevant. An exported file that loses its identifier, creation date or version can be materially less useful than the original controlled record.
Where systems maintain audit trails, preserve their association with the affected record and ensure they remain reviewable for the applicable retention period. An audit trail can show a change, the user, time and recorded reason, but it does not automatically prove that the change was appropriate or that the underlying data were correct. Procedures should define review responsibilities and how significant events are escalated.
Use access controls that protect confidentiality and prevent unauthorised change or deletion. Restrict access to staff with a legitimate role, maintain appropriate access logs and review permissions when roles change. Backups, encryption, replicas and storage redundancy are technical measures; the organisation should also be able to show that authorised retrieval still yields the correct, complete record.
4.3 Keep records readable and interpretable
A file that opens but cannot be understood is not effectively retrievable. Preserve required software or viewing capabilities, code lists, controlled terminology, data dictionaries, templates and relevant procedures where needed to interpret the record. If a database export changes the meaning of coded values, status fields or date conventions, preserve mapping documentation and an explanation of the transformation.
Format choices should reflect long-term readability and the need to retain searchable or structured content. Converting a native database record to a PDF can preserve a visual snapshot but lose relationships, filtering capability or audit-trail context. Conversely, retaining only a proprietary database backup may require software, keys or infrastructure that will no longer exist. The archive design should specify the authoritative preservation format and any companion files needed to reproduce the record’s meaning.
Data protection and confidentiality remain relevant during retention. GDPR’s storage-limitation principle requires personal data to be kept no longer than necessary for its purpose, subject to the applicable lawful basis and exceptions. PV retention duties and data-protection obligations should be assessed together: retain the records required for a legitimate legal or regulatory purpose, limit access and unnecessary data, and review requests for erasure or restriction against the applicable law rather than applying an automatic rule in either direction.
5. Maintain retrieval through system and supplier changes
An archive must remain usable as technology and organisational arrangements change. A system that is scheduled for decommissioning should not be treated as a complete plan until the organisation has shown how records will remain accessible, complete and interpretable after the change.
5.1 Design for retrieval
A retrieval request should be answerable using stable attributes, such as product, case or study identifier, record type, time period, decision, owner or vendor. Define who may request and approve access, how confidential data are handled, how the request is logged and how the returned material is checked for completeness. Inspection readiness depends on being able to find the relevant evidence and explain its context, not merely producing a high volume of files.
A risk-based retrieval test can sample records from different years, products, systems and record classes. It can check whether the item is found within a defined internal service target, whether the correct version and supporting metadata are available, whether relationships and audit trails remain readable, and whether access controls function. The target and frequency are operational choices; set and adjust them according to the organisation’s risk, legal duties and inspection commitments.
Test retrieval after significant events as well as on a routine basis: migration, vendor transition, repository redesign, format conversion, access-model change or archive-software replacement. Record the test population, result, missing or unreadable evidence, remediation owner and closure. A retrieval test that checks only file opening may miss incorrect indexing, missing attachments, incomplete exports or broken links.
5.2 Plan migrations and decommissioning
Before migration, assess the source system, record classes, retention triggers, data relationships, audit-trail design, interfaces and known limitations. Map fields and identifiers to the target archive. Decide how to preserve native context, versions, access history and the ability to distinguish a correction from the original entry.
A controlled migration should define:
- the approved scope and source population;
- extraction rules, cut-off and exclusions;
- field, status and identifier mapping;
- how attachments, links, audit trails and metadata will transfer;
- checks for record counts, completeness, readability and representative content;
- how discrepancies will be investigated and documented;
- acceptance criteria, approval and rollback or contingency arrangements; and
- the date and evidence for source-system access restriction or decommissioning.
These are recommended controls, not a universal statutory migration protocol. Their depth should be risk-based, but a migration should leave an evidence trail showing what moved, how it was checked and how exceptions were resolved. Where the old system must remain available because an export cannot preserve necessary context, retain a governed access route and an explicit exit plan rather than relying on informal access to a retired environment.
5.3 Contract for continued access when work is outsourced
Agreements with PV service providers and other partners should address records as part of the operating model. Define which party creates, controls, stores, maintains and retrieves each record; applicable retention rules; the required file format and metadata; the MAH’s access and inspection cooperation; notification of incidents or changes; continuity arrangements; and transfer or destruction at contract end.
Test the exit route before the relationship ends. Confirm the provider can deliver a complete, readable export with the required audit history and supporting documentation. A contract clause is not evidence that the archive will work; the MAH should obtain and review evidence of the actual handover or continued retrieval arrangement. Where a partner remains the custodian, document how access will be maintained for the full retention period and what happens if the partner ceases operations.
The PSMF and associated quality records should reflect where PV records are held and how their location, access and retrieval are controlled. This connects retention governance with PSMF oversight and the organisation’s continuity planning.
6. Manage triggers, holds and controlled destruction
A schedule needs an unambiguous start event. The event may differ by record class: formal termination of the PV system for the Article 2 elements under Article 12(2), cessation of a product’s marketing authorisation for product-related PV data and documents, or another trigger set by a separate applicable rule. For a global record set, one event may not apply to every market or authorisation. Record the evidence for the trigger and calculate expiry using a controlled method.
6.1 Prevent premature expiry
Before a record becomes eligible for destruction, check whether the underlying period has been calculated correctly and whether another requirement extends it. Examples include a continuing authorisation in another territory, a product-specific commitment, a pending inspection or regulatory request, litigation, an investigation, an audit, a safety issue under active assessment, or a contractual or national requirement. These examples do not create one universal retention extension; they identify matters that the responsible functions should assess.
A legal or regulatory hold is an operational control that suspends routine destruction while a defined matter is unresolved. The hold should identify the subject and record scope, issuing authority, owner, start date, review trigger, affected repositories and conditions for release. Where records are held by vendors or partners, notify them through the agreed process and obtain confirmation that deletion has been suspended. Remove a hold only after the responsible legal, regulatory or quality owner documents the basis for release.
A hold should be scoped and reviewed. An indefinite, unexplained hold can conflict with data minimisation and storage-limitation principles. Where only a subset of records is relevant, preserve that subset and its context while allowing unrelated material to follow its schedule, provided the separation is safe and documented.
6.2 Approve and evidence destruction
At the end of the applicable period, destruction should be controlled rather than automatic by default. A practical process can require the record owner to confirm the class and trigger, the custodian to identify all copies and locations, and Legal, Privacy, Quality or Regulatory Affairs to check for relevant holds and competing duties. A designated approver then authorises disposal under the procedure.
Disposal methods should fit the medium and confidentiality risk. Electronic deletion should cover active repositories and the defined lifecycle for residual backup copies; paper records should be securely destroyed. If deletion from a backup is not technically immediate, the organisation should document the backup retention cycle, prevent routine restoration of expired content, and ensure restored data are re-subjected to deletion controls. This is an operational design principle, not an extra EU PV retention period.
Keep a destruction record that identifies the record classes or covered range, governing schedule rule, trigger and expiry calculation, hold checks, approval, date and method of disposal, and any retained proof from the service provider. The destruction record should itself be managed under an appropriate schedule and should not preserve unnecessary personal data from the destroyed source. A documented “no records located” result is useful when a search was performed, but it should not be used to imply records never existed if the search was incomplete.
6.3 Handle privacy rights with a documented assessment
Safety records can contain personal and health data. GDPR requires storage limitation and provides rights that may include erasure, but those rights are subject to specified conditions and exceptions, including processing necessary to comply with a legal obligation or for certain public-interest purposes. The proper outcome depends on the processing purpose, legal basis, applicable PV duties, national law and the facts of the request.
A request should be routed through the organisation’s privacy process and assessed with PV, Legal and, where appropriate, the Data Protection Officer. Consider whether information can be corrected, restricted, pseudonymised or otherwise safeguarded without undermining the accuracy or traceability required for PV. Record the reasoning and response under the applicable privacy procedure. Do not treat “PV record” as an automatic exemption from GDPR, or apply erasure in a way that destroys records the organisation is legally required to retain.
7. Governance and inspection readiness
Record lifecycle controls cross PV, Quality, IT, Records Management, Privacy, Legal, Regulatory Affairs and procurement. Accountability should be assigned in procedures and agreements rather than inferred from system ownership alone.
The PV process owner defines the record set needed to demonstrate that the activity was performed and that safety decisions were supported. The records or information-governance function maintains the schedule and approved archive rules. IT and system owners implement access, integrity, migration, recovery and deletion controls. Privacy and Legal advise on personal data, legal bases, holds and rights requests. Procurement and contract owners ensure external arrangements support continued access. The QPPV and senior PV management should have appropriate visibility of material risks to PV records, particularly when a failure could prevent review, reporting, signal assessment or response to an authority.
A practical governance review may monitor:
- record classes without an approved owner, location or retention trigger;
- retrieval-test success and time to locate evidence;
- migration and vendor-exit exceptions;
- overdue holds or unreviewed holds;
- retention-rule changes and overdue schedule updates;
- destruction approvals, rejected disposals and exceptions;
- access, integrity or availability incidents affecting PV evidence.
Metrics should prompt investigation rather than replace it. For example, a high retrieval success rate does not show whether the sample included legacy systems, former vendors and older records. A low volume of destruction exceptions may indicate effective controls—or a process that is not identifying holds. Define the denominator, scope and limitations for each measure.
7.1 Illustrative example: product authorisation ends during a vendor transition
An MAH ends a product’s EU marketing authorisation while changing safety-database providers. Under the Article 12 product-record minimum, the product-related PV data and documents remain subject to retention for at least ten years after that authorisation ceases to exist. The end of the vendor contract does not restart or shorten that period. The PV and records owners should identify the affected records, verify the legal end date, transfer or preserve the relevant files and metadata, test retrieval in the destination, and retain evidence of the provider’s handover. If another market authorisation remains active or an applicable hold exists, the schedule must account for that additional scope before destruction is considered.
The example illustrates how a legal trigger, system change and custody transfer interact. It does not establish that every vendor transition requires the same migration design or that every market follows the EU period.
7.2 Questions an inspector or auditor may ask
An inspection may test whether the organisation can explain and evidence its record lifecycle. Typical questions include:
- How does the organisation know which systems and providers hold PV records?
- Which legal rule applies to this record class, and what event starts the retention period?
- Can the organisation retrieve the original source, relevant versions, audit trail and decision evidence?
- How were records checked after a system migration or service-provider exit?
- Who can authorise access, change, hold release or destruction?
- How does the organisation identify records subject to an active request, inspection or investigation?
- How does senior PV management learn about missing or inaccessible evidence?
Prepare by demonstrating the actual retrieval path and governance controls, not only by presenting a policy. If records cannot be found, identify the affected population, assess the impact on PV activities and decisions, escalate through the quality system, document corrective action and determine whether regulatory notification or other action is required under the applicable procedures.
8. Implementation checklist
Use this checklist when establishing or reviewing the record lifecycle:
Scope and schedule
- Have PV record classes, authoritative locations, custodians, partners and copies been inventoried?
- Does each class have a documented source of authority, retention trigger, period and owner?
- Are the five-year PV-system and ten-year product-related periods applied to their correct scopes and triggers?
- Have other jurisdictions, study rules, product commitments and national requirements been assessed?
- Are schedule changes controlled and communicated to affected functions?
Integrity and access
- Can records be linked to the relevant product, case, activity, decision and version?
- Are necessary metadata, source material and audit trails retained and interpretable?
- Are access permissions, confidentiality and change controls appropriate?
- Can older formats, code lists and system exports still be understood?
Migration and retrieval
- Are migration scope, mappings, checks, exceptions, approval and contingencies documented?
- Are retrieval tests representative of older records and different systems or providers?
- Can staff retrieve complete evidence within a defined internal target?
- Do agreements support ongoing access, export, continuity and handover at termination?
Holds and disposition
- Are holds scoped, communicated to custodians and periodically reviewed?
- Is expiry checked against other active authorisations, legal matters and applicable obligations?
- Are destruction decisions approved and evidenced across relevant copies and providers?
- Do backup and restoration procedures prevent expired records from reappearing in routine systems?
9. Key takeaways
- Retention is a controlled lifecycle, not a storage setting. Records must remain protected, interpretable and retrievable for the required period.
- EU human-medicines Article 12 sets two distinct MAH minimums: at least five years after formal PV-system termination for the specified Article 2 elements, and retention of product-related PV data and documents while authorised plus at least ten years after the marketing authorisation ceases to exist.
- The two periods have distinct scopes and start events; neither is a universal retention period for every PV-related record in every jurisdiction.
- A backup supports recovery; it does not by itself provide a governed archive with record context, metadata and tested retrieval.
- System migration and vendor termination need evidence of scope, transfer, checks, exceptions and continued access.
- Holds, privacy requests and destruction require documented assessment; disposal should occur only after the applicable schedule and other constraints have been checked.
- Inspection readiness is demonstrated by retrieving a complete record set and explaining its history, location, retention basis and governance.
References
- European Commission. Commission Implementing Regulation (EU) No 520/2012, consolidated text applicable from 12 February 2026, especially Article 12 and Article 2.
- European Commission. Commission Implementing Regulation (EU) 2025/1466 amending Regulation 520/2012.
- European Medicines Agency. Good pharmacovigilance practices (GVP), Module I: Pharmacovigilance systems and their quality systems, especially I.B.10; read with current applicable legislation.
- European Medicines Agency. Good pharmacovigilance practices (GVP), Module II: Pharmacovigilance system master file.
- European Medicines Agency. Good pharmacovigilance practices (GVP): current modules and revisions.
- European Parliament and Council. Regulation (EU) 2016/679 (General Data Protection Regulation), especially Articles 5(1)(e), 17 and 17(3)(b).
Regulatory Note
This article is an operational guide to record retention and archiving in the EU human-medicines pharmacovigilance context, reviewed on 2 October 2026. The Article 12 periods described are binding EU minimums for the record classes and triggers specified in the legislation; they should not be generalised to unrelated records, veterinary medicines or other jurisdictions. Other EU or national requirements may require longer retention. GVP provides regulatory guidance, while retrieval testing, migration controls, hold procedures and destruction approvals are operational approaches to help an organisation demonstrate effective record management. Confirm the current consolidated law, applicable national rules and current guidance before applying the article to a specific product or system.