Computerised System Validation in Pharmacovigilance

Computerised systems sit inside almost every important pharmacovigilance process. A safety database receives and processes Individual Case Safety Reports (ICSRs); interfaces transmit cases between organisations and regulatory networks; literature tools help identify reportable information; signal platforms aggregate and analyse safety data; document and quality systems preserve controlled records; and reporting applications support aggregate evaluation and regulatory submissions. When these systems fail, the failure is not merely technical. It can change what safety information is available, when it is available, how it is interpreted, and whether regulatory obligations can be met.

Computerised system validation (CSV) is the organised body of evidence used to establish that a computerised system is suitable for the purpose for which the pharmacovigilance organisation relies on it. The important phrase is intended purpose. Validation is not a certificate that software is universally correct, and it is not a one-time testing exercise performed before go-live. It is a lifecycle process in which requirements, risk assessment, supplier evidence, configuration, testing, release, operation, change control, periodic review and retirement collectively support continued confidence in the system.

This distinction matters because pharmacovigilance organisations use very different kinds of technology. A configurable global safety database that determines reportability and generates electronic submissions creates a different risk profile from a repository used to store non-critical working documents. A proportionate validation strategy therefore asks what the system does, which regulated processes depend on it, what could happen if it fails, and what evidence is needed to reduce that uncertainty to an acceptable level.

Purpose and Scope

The purpose of validation in pharmacovigilance is to provide documented assurance that technology supporting regulated safety activities performs reliably enough for its intended use and that the organisation can maintain that assurance as the system changes. Three related objectives follow from this purpose:

1. process reliability — the system supports the pharmacovigilance process as designed;
2. data integrity — regulated data remain complete, accurate, attributable, traceable and available as required; and
3. regulatory compliance — system behaviour does not prevent the organisation from meeting applicable pharmacovigilance obligations.

These objectives overlap but are not identical. A technically available system can still be unsuitable if a configured rule calculates a regulatory due date incorrectly. Conversely, a software defect that affects an unused feature may have no meaningful pharmacovigilance impact. Validation therefore connects technical behaviour to actual business use.

What is being validated?

In practice, the validation object is better understood as the computerised system in its operating context, not merely the vendor's software product. That context can include configured application functions, infrastructure, interfaces, user roles, controlled procedures, data migration, reference data, reports, electronic records, integrations and human actions around the technology.

This explains why a vendor statement that a product is "validated" cannot by itself establish that a marketing authorisation holder's implementation is fit for purpose. The supplier can provide substantial qualification and testing evidence, but the regulated organisation still has to understand its own intended use, configuration, interfaces and process risks. EMA's pharmacovigilance inspection guidance makes this distinction explicit: the marketing authorisation holder may rely on adequate vendor qualification documentation, but additional qualification or validation may be needed on the basis of documented risk assessment.

Validation, qualification and assurance

Terminology differs across organisations and GxP disciplines. Qualification is often used for infrastructure, platforms, suppliers or technical components, whereas validation is commonly used for demonstrating that the implemented system supports its intended regulated use. Computer software assurance describes a broader risk-based philosophy in which confidence may be established through an appropriate combination of testing, supplier evidence, process controls and other assurance activities.

The terminology is less important than the underlying logic. A defensible approach should show a traceable relationship between intended use, risk, controls, evidence and approval. Changing the label from CSV to CSA does not remove the need to understand those relationships.

Regulatory Framework

There is no single global "CSV regulation for pharmacovigilance". The applicable framework is assembled from pharmacovigilance legislation and guidance, electronic-record requirements where relevant, and supporting GxP or industry standards whose legal status and scope differ. A professional validation strategy must therefore distinguish what is directly applicable from what is useful by analogy.

European Union pharmacovigilance requirements

For EU pharmacovigilance, the starting point is the pharmacovigilance quality system. Commission Implementing Regulation (EU) No 520/2012 requires marketing authorisation holders, national competent authorities and the European Medicines Agency to establish and use an adequate and effective quality system for pharmacovigilance. The quality system covers organisational structures, responsibilities, procedures, processes and resources, including compliance and record management.

GVP Module I translates this legal framework into operational guidance. Section I.B.8 states that facilities and equipment critical for pharmacovigilance should be subject to appropriate checks, qualification and/or validation activities to demonstrate suitability for their intended purpose. Computerised systems that materially support critical PV processes therefore sit within the pharmacovigilance quality system rather than outside it as an IT-only concern.

GVP Module II makes the connection visible in the Pharmacovigilance System Master File (PSMF). The PSMF should describe the location, functionality and operational responsibility of computerised systems and databases used to receive, collate, record and report safety information, together with an assessment of fitness for purpose. It also calls for a summary description of the validation status of key functionality and relevant controls such as change control, testing, backup arrangements and electronic data repositories important to PV compliance.

These provisions establish an important governance principle: the organisation must be able to explain not only which systems it uses, but why it considers the functions on which pharmacovigilance depends to be fit for purpose and controlled.

EU GMP Annex 11: relevant but not a general PV legal basis

EU GMP Annex 11, Computerised Systems, contains well-developed lifecycle principles for regulated computerised systems. It addresses matters such as risk management, supplier assessment, validation, data, audit trails, security, change control, periodic evaluation and business continuity. Those principles are often useful when designing a PV validation framework.

However, Annex 11 belongs to the EU Good Manufacturing Practice framework. It should not be presented as though it directly imposes GMP requirements on every pharmacovigilance system. For a system used solely for post-authorisation PV, the direct EU basis comes from the pharmacovigilance legislation and GVP framework. Annex 11 may inform the organisation's control model where its principles are appropriate, and it may become directly relevant where the same system also supports activities within GMP scope.

This distinction between direct requirement and useful control framework prevents an industry standard or another GxP discipline from being converted into an invented PV legal obligation.

United States electronic records and 21 CFR Part 11

In the United States, 21 CFR Part 11 establishes criteria for certain electronic records and electronic signatures. Its applicability depends on the underlying FDA record or submission requirements—the "predicate rules"—and on how the organisation creates, maintains, relies on or submits the electronic records. It is therefore inaccurate to treat Part 11 as a universal rule that automatically applies to every computer used in pharmacovigilance.

FDA's Part 11, Electronic Records; Electronic Signatures — Scope and Application guidance recommends a justified and documented risk-based approach when determining validation and the extent of validation. The guidance also explains FDA's enforcement-discretion policy for specified Part 11 provisions while emphasising continued compliance with applicable predicate-rule requirements. A PV organisation operating in the United States should therefore map the records and signatures its systems manage to the applicable FDA requirements rather than attaching a generic "Part 11 compliant" label to an application.

FDA Computer Software Assurance: a useful philosophy with a defined scope

FDA issued its current final guidance Computer Software Assurance for Production and Quality Management System Software in February 2026. It advocates a risk-based method for establishing confidence in automation and for directing greater assurance effort to higher-risk functions.

Its formal scope is important: the guidance concerns computer software used in medical-device production or the medical-device quality management system. It is not an FDA pharmacovigilance CSV regulation and should not be cited as creating a new validation requirement for drug-safety databases. The risk-based assurance concepts can nevertheless be educationally useful when an organisation designs its own proportionate validation approach, provided that the source and scope are stated correctly.

Industry standards and guidance

ISPE GAMP 5 and its second edition are influential industry guidance rather than legislation. They provide a structured lifecycle and risk-based model for regulated computerised systems and are widely used to organise validation programmes. Other quality-risk, data-integrity and information-security standards may also contribute to the control framework.

Their proper role is to help an organisation implement applicable requirements in a systematic way. They do not displace the pharmacovigilance legislation, and adoption of a particular GAMP document or template is not itself an EU pharmacovigilance legal requirement.

From Intended Use to Validation Strategy

Once the regulatory basis is understood, the practical problem is to decide what level of assurance a particular system needs. That decision begins with intended use. Intended use describes what the organisation relies on the system to do within its regulated process, not every function that the software vendor makes available.

For a safety database, intended use may include receiving reports, creating case records, applying configured workflows, controlling user access, calculating regulatory due dates, generating E2B(R3) messages, transmitting reports, recording acknowledgements and preserving the safety history. For a signal platform, intended use may instead centre on importing defined data sets, calculating statistical outputs, supporting review decisions and preserving the evidence trail. These different purposes lead to different requirements and different validation evidence.

Define the regulated process before the software requirements

A common weakness in validation is to begin with a vendor feature list. That reverses the logic. The organisation should first understand the pharmacovigilance process and the regulatory outcomes the system must support. Only then can it define system requirements that are meaningful.

A useful requirement describes an observable need in a way that can later be verified. For example, "the system shall support regulatory reporting" is too broad to test intelligently. A set of requirements defining reportability logic, due-date calculation, message generation, transmission status, acknowledgement handling and exception escalation provides a much stronger basis for assurance.

The requirements do not have to prescribe the technical implementation unless the implementation itself is necessary to control risk. Their main purpose is to establish what correct performance means.

Identify critical functions and records

Not all functions deserve the same assurance effort. The organisation should identify which functions can materially affect patient safety, regulatory compliance or the integrity and availability of regulated data. Typical high-impact PV functions may include:

These are examples for risk assessment, not a universal regulatory classification. The actual criticality depends on how the organisation uses the system and what compensating controls exist.

Assess risk as a chain, not a score alone

A numeric risk score can help prioritisation, but the reasoning matters more than the arithmetic. An experienced validation team asks a sequence of questions:

1. What can fail in the intended use?
2. What PV information, decision or obligation could be affected?
3. Could the failure be detected before harm or non-compliance occurs?
4. What preventive or detective controls already exist?
5. What evidence is needed to demonstrate that the residual risk is controlled?

For example, an automated submission interface may be intrinsically important because it transmits expedited reports. If the interface records technical acknowledgements and a separate reconciliation process identifies unacknowledged cases, those controls change the residual risk. Validation should test the control chain, not merely prove that one screen can send one message.

This is why a risk-based approach is not synonymous with "less testing". It means concentrating evidence where uncertainty has the greatest consequence and avoiding ritual documentation where it adds little assurance.

The Validation Lifecycle

Validation evidence is generated progressively. The exact document names vary between organisations, but the underlying lifecycle should connect business need, requirements, design or configuration, verification, release and continuing control.

Planning and system classification

The validation plan establishes how assurance will be achieved. Depending on system complexity, it may be a stand-alone plan or part of a broader project quality plan. It should explain the system and intended use, applicable regulatory context, roles, risk approach, supplier reliance, required deliverables, testing strategy, acceptance criteria, deviation management and release decision.

The organisation should also define the system boundary. This becomes particularly important for cloud platforms and integrated PV landscapes. A "safety database" may depend on identity management, hosted infrastructure, terminology services, reporting gateways, data warehouses and external integrations. If those dependencies are outside the declared boundary, the validation argument may be incomplete.

System classification schemes—such as categories based on infrastructure, non-configured products, configured products or custom software—can help scale activities. They are planning tools rather than substitutes for intended-use risk assessment.

Supplier assessment and use of supplier evidence

Commercial PV platforms are usually developed and maintained by specialist suppliers. Repeating all supplier development testing is neither necessary nor particularly informative when credible supplier evidence is available. The regulated organisation can use supplier documentation as part of its assurance case after assessing whether that evidence is relevant and adequate.

Supplier assessment may consider the supplier's quality system, development and testing processes, defect management, release practices, security controls, continuity arrangements, documentation, subcontracting and experience supporting regulated customers. The depth should be proportionate to reliance and risk.

The key question is not whether a supplier possesses a generic certificate. It is whether the organisation has enough evidence to justify relying on the supplier for defined parts of the lifecycle. EMA explicitly recognises that an MAH may rely on vendor qualification documentation when the vendor's activities have been assessed as adequate; the MAH retains responsibility for the PV process supported by the electronic system.

User requirements and traceability

User requirements provide the anchor for later verification. Requirements should be uniquely identifiable where practical and written so that their fulfilment can be demonstrated. High-level process requirements may be decomposed into more specific functional, data, interface, security and reporting requirements when needed.

Traceability links these requirements to risk controls and verification evidence. A traceability matrix is a common implementation, but the regulatory objective is the relationship, not the template. A well-controlled requirements-management tool can establish the same evidence if it allows the organisation to show that critical requirements were implemented and appropriately verified.

Traceability is particularly valuable when something changes. If a reporting rule is modified, the organisation should be able to identify the affected requirements, configuration, tests, procedures and training rather than revalidate the whole system blindly.

Configuration, design and controlled implementation

Configured commercial applications occupy an important middle ground between unmodified software and custom development. Configuration can materially change system behaviour even when no source code is written. Workflow states, reporting rules, case forms, code lists, permissions, dictionaries, interfaces and automated schedules may all be configured.

Validation should therefore treat critical configuration as controlled design information. Changes should be authorised, reviewed and reproducible. Where configuration is promoted between environments, the organisation should know how it confirms that the production configuration is the approved one.

Custom code, scripts and bespoke interfaces generally increase the amount of organisation-specific evidence needed because there is less supplier product evidence on which to rely. The appropriate response is not automatically a larger document package; it is a validation strategy that addresses the additional uncertainty introduced by customisation.

Data migration

Migration is often one of the highest-risk parts of a system replacement. A new application can function correctly while the migrated historical safety record is incomplete, duplicated, transformed incorrectly or no longer reconstructable.

A migration strategy should define the source and target populations, mapping and transformation rules, handling of invalid or legacy values, reconciliation approach, acceptance criteria and exception process. Verification may combine automated reconciliation, counts, field-level checks and risk-based sampling. The method should be capable of detecting the kinds of error that the migration process could realistically introduce.

The organisation should also decide how provenance is preserved. If a historical value is transformed to fit a new data model, it should remain possible to understand what happened and, where required, reconstruct the original regulated record.

Verification and testing

Testing should demonstrate that the system and its controls work in the intended operating context. Traditional labels such as installation qualification, operational qualification and performance qualification can be useful in some environments, but PV validation does not depend on using those labels.

A risk-based test strategy can combine several forms of evidence:

• supplier testing for standard product behaviour;
• scripted testing for critical configured functions where repeatability and objective expected results are important;
• scenario-based or exploratory testing for complex workflows and usability-related risks;
• interface and reconciliation testing for data transfers;
• security and role testing for access controls;
• migration verification for transferred records;
• negative and exception testing where failure handling is itself a critical control.

A passed test is not meaningful merely because a tester followed steps successfully. The test should address a defined requirement or risk, use an appropriate environment and data set, preserve sufficient evidence, and resolve unexpected results through controlled deviation or defect management.

Acceptance and release

Release is a governance decision. Before production use, the responsible functions should be able to conclude that planned validation activities are complete or that any remaining items are understood, risk-assessed and formally accepted. Critical defects should not be obscured by an overall percentage of passed tests.

The release decision normally considers validation status, unresolved deviations, migration results, procedural readiness, access configuration, training, support arrangements, continuity controls and residual risk. The exact approvals depend on organisational roles, but business and PV ownership should not be displaced by IT approval alone when the system supports regulated pharmacovigilance activities.

Maintaining the Validated State

A system does not remain fit for purpose merely because it passed testing before go-live. Once operational, the system becomes part of a changing environment: vendors release updates, regulations change, infrastructure is patched, interfaces are modified, terminology versions are updated, new products and countries are added, and business processes evolve. Validation therefore moves from project assurance into lifecycle control.

Change control and impact assessment

Every change does not require the same amount of revalidation. The organisation should first understand what is changing and whether the change can affect intended use, regulated data, critical configuration, interfaces, security, reporting, or existing controls.

A strong impact assessment is traceable. It identifies affected requirements and risks, determines which evidence remains valid, defines new or regression testing, considers procedural or training changes, and establishes whether the PSMF or other controlled documentation needs updating. The goal is to preserve the validation argument rather than repeatedly rebuild it from the beginning.

Vendor SaaS releases make this especially important. A supplier may deploy changes on a regular cadence, but the MAH still needs a controlled method for understanding release content, assessing relevance, testing affected high-risk functionality when necessary and documenting the conclusion. "The vendor validated it" is insufficient when the change affects organisation-specific configuration or regulated workflows.

Incident, problem and defect management

Operational incidents can reveal that assumptions made during validation no longer hold. A technical event should therefore be assessed not only for restoration of service but also for its possible effect on safety data and regulatory processes.

Consider an illustrative scenario in which an interface stops transmitting ICSRs for several hours. Restoring connectivity answers the IT problem, but PV governance must also establish which cases were affected, whether reporting clocks continued to run, whether cases were submitted late, whether acknowledgements were reconciled and whether the event indicates a control weakness requiring corrective action.

This is the difference between system recovery and regulated impact assessment. Incident records, deviations and CAPAs should connect when the same event has both technical and pharmacovigilance consequences.

Periodic review

Periodic review is a structured confirmation that the accumulated evidence still supports continued use. The appropriate frequency should be determined by organisational procedure and risk; EU GVP does not prescribe a universal annual CSV review interval for every PV system.

A review may consider significant changes, incidents and recurring defects, access reviews, audit-trail controls, supplier performance, backup and restoration evidence, security events, business-continuity testing, outstanding CAPAs, procedural changes, interfaces, regulatory changes and the current state of validation documentation. The review should conclude whether the system remains fit for purpose and identify any actions needed to restore or strengthen control.

The value of periodic review lies in this conclusion. A checklist completed without examining evidence provides little assurance.

Data Integrity and Record Controls

Pharmacovigilance decisions depend on the integrity of the underlying record. Data integrity is therefore not a separate topic added after functional validation; it is a property that the validated system and its operating controls must preserve.

The complete data lifecycle

Safety information moves through a chain of capture, transformation, review, transmission, storage and retrieval. Validation should consider where meaning can change across that chain.

For example, an adverse event term may be entered from a source document, coded to MedDRA, exported to an E2B message, transformed by an integration layer, acknowledged by a regulatory gateway, copied to a data warehouse and later used in aggregate or signal analysis. Each transfer can be technically successful while still altering or omitting information. Interfaces therefore require attention to mapping, versioning, exception handling and reconciliation—not simply connectivity.

Audit trails

An audit trail can provide essential evidence about who changed a regulated record, what changed and when. Whether a particular audit trail is required and how it should operate depends on the applicable regulatory context and the nature of the data and process.

For critical PV records, the control design should address questions such as:

• which changes must be recorded;
• whether previous values remain available;
• whether the actor and timestamp are captured reliably;
• how reason-for-change requirements are applied where appropriate;
• who can modify system configuration affecting audit trails;
• how audit-trail information can be retrieved and reviewed;
• what events should trigger routine or targeted review.

Simply enabling an audit-trail feature does not demonstrate effective control. The organisation should establish how the information is used when review is necessary and how inappropriate changes would be detected or investigated.

Access control and segregation of duties

Role design should follow business responsibilities and the principle that users receive only the access needed for their tasks. Validation should confirm critical permissions, but ongoing user administration is equally important. Joiner, mover and leaver processes, privileged-access control and periodic access review help prevent a validated role model from becoming ineffective over time.

Segregation of duties is risk-dependent rather than absolute. A small affiliate may not be able to separate every activity among different individuals. Where organisational size prevents ideal separation, compensating controls—such as independent review, restricted administration or retrospective monitoring—may be appropriate and should be documented.

Backup, restoration and availability

A backup that has never been shown to restore usable regulated records provides limited assurance. Backup strategy should therefore be connected to restoration testing, data retention and business-continuity requirements.

The organisation should understand recovery objectives for critical PV processes, dependencies on external services, how queued transactions are handled during outages, and how missing or delayed records are reconciled after recovery. Business continuity is particularly important where downtime can consume a regulatory reporting interval.

Cloud and Software-as-a-Service Systems

Cloud delivery changes where technical activities are performed, but it does not transfer the MAH's responsibility for the pharmacovigilance process. The assurance model therefore becomes more dependent on clearly defined responsibilities, supplier oversight and evidence obtained from the provider.

Shared responsibility

A cloud provider may manage physical infrastructure, operating systems, platform components, backups and security monitoring while the customer controls application configuration, user roles, business procedures and regulated use. In a SaaS model, the vendor may control even more of the technical stack. Validation should make this allocation explicit.

Contracts and quality agreements can support this clarity by addressing relevant matters such as change notification, incident communication, service availability, security events, data location where material, backup and recovery, subcontractors, audit rights, access to validation evidence and exit arrangements. The exact controls should reflect system criticality and the services actually delegated.

Continuous vendor releases

Frequent SaaS releases challenge document-heavy validation models built around infrequent upgrades. A proportionate model can use supplier release documentation and testing evidence, automated regression testing, configuration comparison and targeted customer testing based on change impact.

What must remain constant is the logic: the organisation needs a repeatable method to decide whether a release affects its intended use and to generate enough evidence for the affected risk. Release frequency does not justify bypassing change assessment.

Artificial Intelligence and Adaptive Functions

Artificial intelligence introduces additional validation questions because some systems are probabilistic, data-dependent or capable of changing behaviour when models or prompts are updated. These properties do not make validation impossible, but they do make simplistic pass/fail functional testing insufficient for many uses.

Start with the intended decision role

The first question is what the AI function is allowed to do. An AI tool that suggests a literature classification for human confirmation presents a different control problem from a tool that autonomously excludes records from review. The closer the technology comes to making or executing a regulated safety decision without human review, the stronger the evidence and monitoring ordinarily need to be.

A validation strategy for an AI-enabled PV function may need to address:

• the defined use case and prohibited uses;
• training or reference data where relevant and available;
• performance measures that reflect the actual PV task;
• representative challenge sets, including uncommon and difficult cases;
• false-negative and false-positive consequences;
• human review and override controls;
• model, prompt or configuration versioning;
• change detection and re-evaluation triggers;
• monitoring for performance drift;
• traceability of the output used in a regulated decision.

These are recommended assurance considerations, not a claim that EU GVP prescribes a specific AI validation template.

Deterministic controls around probabilistic tools

A useful design principle is to place deterministic controls around uncertain outputs. For example, an AI-assisted literature screening tool can preserve the original search result, record the model version and classification, route defined categories for human review, maintain an auditable override, and periodically evaluate false-negative performance against a controlled sample.

This creates an evidence chain even when the underlying model is probabilistic. The validation question becomes whether the overall controlled process is sufficiently reliable for its intended PV use, rather than whether the model can be proven infallible.

System Retirement and Data Preservation

Retirement is the last stage of the validation lifecycle, not the point at which control ends. Regulated safety records may need to remain accessible long after the application that created them has been decommissioned.

A retirement plan should address which records must be retained, retention periods under the applicable rules, migration or archive format, preservation of metadata and audit history, retrieval capability, access controls, verification of transferred records and disposition of legacy infrastructure. If data are migrated to a replacement system, the migration itself should be controlled and verified.

Particular attention is needed when the retired application provided context that is not obvious from exported data. Code lists, terminology versions, workflow history, attachments and audit-trail information may be necessary to reconstruct the meaning of a historical record. A technically readable archive is not sufficient if the regulated record can no longer be interpreted.

Roles and Governance

Computerised system validation is multidisciplinary because no single function holds all of the knowledge needed to judge fitness for purpose. Information technology may understand architecture and technical controls; the supplier may understand the product; quality functions may govern validation methods; and pharmacovigilance process owners understand the regulated use and consequences of failure. Effective governance connects these perspectives.

Business and pharmacovigilance process ownership

The PV process owner should be able to define what the system must achieve in the regulated process, identify critical functions, participate in risk assessment and decide whether the available evidence supports operational use. These responsibilities should not be reduced to signing a validation summary prepared entirely by technical teams.

For a global safety database, for example, meaningful PV ownership includes understanding how case intake, medical review, reporting rules, submissions, acknowledgements, reconciliation and downstream safety analyses depend on the application. The process owner does not need to administer servers, but should understand enough of the control model to judge whether the process remains reliable.

Information technology and system ownership

Technical owners commonly manage infrastructure, environments, deployment, interfaces, monitoring, backup, security and technical change. They provide evidence that the technical platform supporting the regulated application is controlled.

The boundary between system ownership and process ownership should be explicit. Otherwise, a validation gap can arise in which IT assumes PV has verified business behaviour while PV assumes IT has validated the entire regulated process.

Quality assurance

The quality function commonly establishes or oversees the validation framework, reviews compliance with procedures, assesses significant deviations and provides independent challenge where appropriate. Its role is not necessarily to execute every test. A mature quality function asks whether the evidence is proportionate, traceable and sufficient for the stated risk.

Suppliers and service providers

Outsourcing technical activities does not outsource accountability for the pharmacovigilance system. Supplier responsibilities should be clearly described, and the MAH should retain sufficient knowledge and evidence to oversee the outsourced activity. Supplier assurance therefore extends beyond procurement and should continue through performance monitoring, change, incident management and eventual exit.

The QPPV perspective

The EU QPPV is not necessarily the validation approver for every computerised system. The QPPV's role should be interpreted within the broader responsibility to have appropriate oversight of the pharmacovigilance system and its performance. For critical systems, the QPPV should have access to information sufficient to understand material system risks, significant incidents or compliance impacts and the controls used to maintain the pharmacovigilance system.

This is particularly relevant where a system problem affects expedited reporting, signal management, aggregate evaluation or another critical PV process. Governance should ensure that material technology issues are escalated through PV channels on the basis of their safety and compliance impact rather than remaining isolated within an IT ticketing system.

Practical Implementation

A proportionate CSV programme can be built around a simple assurance chain:

intended use → applicable requirements → critical risks → controls → verification evidence → release → lifecycle monitoring.

Each link should be understandable from the records. The objective is not to maximise the number of validation documents but to make the conclusion of fitness for purpose reproducible and defensible.

A practical minimum evidence model

The exact documents will differ, but for a significant PV system the evidence set commonly addresses the following subjects:

This is a recommended operating model, not a prescribed EU dossier format. An organisation may combine records where doing so remains clear and controlled.

Example: validating a regulatory reporting rule change

Consider a hypothetical change to the configuration that determines whether a type of case is transmitted to a regulatory destination. A weak approach would record that "the vendor update was validated" and execute a generic regression script.

A stronger approach would identify the affected reporting requirement, document why the rule matters, examine the configuration change, select representative positive and negative scenarios, verify message generation and routing, confirm exception handling, assess whether existing procedures or training are affected, and retain the evidence supporting release. If the rule also affects historical or in-flight cases, the impact assessment would address those populations explicitly.

The strength of this approach comes from traceability. An inspector or internal reviewer can reconstruct why the change was made, what could have gone wrong, how it was tested and why the organisation concluded that the residual risk was acceptable.

Potential Failure Modes

The following are illustrative failure modes rather than reported inspection findings. They are useful because they show where apparently complete validation programmes can lose practical effectiveness.

Validation is treated as document production

A large package of approved templates can coexist with poor assurance if requirements are vague, testing is disconnected from critical risks, deviations are closed administratively or system changes are not linked back to validation. Document volume should not be used as a proxy for control.

Vendor validation is accepted without evaluating intended use

Supplier evidence may be extensive, but it usually cannot address the customer's complete configuration, interfaces, migrated data, procedures and business use. The MAH should define what supplier evidence covers and where organisation-specific assurance remains necessary.

Risk assessment is performed after testing

When risk assessment is completed retrospectively to justify an already-defined test set, it cannot perform its main purpose: directing assurance effort. Risk should influence planning, not merely explain it afterwards.

Interfaces are tested for connectivity but not meaning

A successful transfer does not prove that fields were mapped correctly, that all records were transferred, that duplicates or rejections are controlled or that acknowledgements are reconciled. Interface assurance should address information integrity across the transfer.

Change control becomes a technical release process

A technically successful deployment can still alter regulated behaviour. Change assessment should consider PV process impact, affected requirements and data, regression needs, procedures, training and documentation—not only whether the application remains available.

Periodic review becomes calendar compliance

A review performed at a fixed interval adds little value if it does not evaluate actual changes, incidents, access, supplier performance, continuity, CAPAs and validation status. The output should be a reasoned conclusion about continued fitness for purpose.

System incidents are not connected to PV impact

If a critical outage or defect is closed when the technical service is restored, the organisation may fail to assess cases, submissions, signals or records affected during the event. Technical recovery and PV impact assessment should be linked where appropriate.

Inspection Considerations

An inspector evaluating a computerised system in pharmacovigilance is likely to be interested in whether the system and its controls are demonstrably effective in supporting the regulated process. The precise scope depends on the inspection, but the evidence should allow a coherent account of the system from intended use through current operation.

Potential inspection questions include:

• Which computerised systems are critical to the pharmacovigilance system, and how was criticality determined?
• How does the PSMF describe those systems and their fitness for purpose?
• Which functions were considered high risk, and how did that assessment influence verification?
• What supplier evidence is relied upon, and how was its adequacy assessed?
• How are configuration and interfaces controlled?
• How was migrated safety data reconciled?
• How are significant vendor releases assessed before or after deployment according to the service model?
• How does the organisation know that electronic submissions reached the intended destination?
• How are access, audit trails, backup and restoration controlled?
• How are system incidents assessed for impact on regulated PV activities?
• What evidence shows that the validated state has been maintained since initial release?
• How would the organisation retrieve and interpret historical records after system retirement?

The quality of the response depends on traceability and operational evidence. A validation summary that states that the system passed is weaker than an evidence chain showing why the system was considered fit for its specific PV purpose and how that conclusion has been maintained.

Implementation Checklist

For a new or materially changed PV computerised system, an experienced team should be able to answer the following before declaring validation complete:

• Is the intended PV use explicitly defined?
• Is the system boundary, including interfaces and important dependencies, understood?
• Have directly applicable regulatory requirements been distinguished from guidance and industry practice?
• Have critical process, data-integrity and compliance risks been assessed before deciding the assurance strategy?
• Is supplier evidence being used on the basis of an assessed and documented rationale?
• Are critical user requirements testable and traceable to evidence?
• Is organisation-specific configuration controlled and reproducible?
• Have interfaces and migration been assessed for data meaning and completeness, not merely technical connectivity?
• Does testing cover important positive, negative and exception scenarios proportionately?
• Are deviations, residual risks and release decisions explicit?
• Are operational procedures, trained users, access controls and support arrangements in place?
• Is there a defined process for vendor releases, internal changes, incidents and periodic review?
• Are backup, restoration and continuity controls demonstrated rather than assumed?
• Can the organisation preserve and retrieve regulated records throughout the required lifecycle?
• Does the PSMF accurately describe relevant computerised systems and key validation controls?

Key Takeaways

Computerised system validation in pharmacovigilance is best understood as lifecycle assurance of intended use. It is not proof that software contains no defects, and it is not satisfied by a vendor certificate or a large collection of test scripts.

In EU pharmacovigilance, the direct framework arises from the pharmacovigilance quality-system requirements and GVP. GVP Module I expects critical PV facilities and equipment to undergo appropriate checks, qualification and/or validation for intended purpose, while GVP Module II requires the PSMF to describe relevant computerised systems, fitness for purpose and key validation controls. EU GMP Annex 11 contains useful computerised-system principles but should not be misrepresented as a general legal requirement for systems used solely for post-authorisation pharmacovigilance.

Similarly, 21 CFR Part 11 should be applied according to its actual scope and the relevant FDA predicate rules. FDA's 2026 Computer Software Assurance guidance provides a useful risk-based assurance philosophy, but its formal scope is medical-device production and quality management system software rather than a general drug-pharmacovigilance validation requirement.

A defensible PV validation programme links requirements to risk, controls and evidence, uses supplier material intelligently without surrendering accountability, and maintains the validated state through controlled change, incident assessment, periodic review and retirement. The central governance question remains stable throughout the lifecycle: what evidence shows that this system, in this configuration and operating environment, remains fit for the pharmacovigilance purpose for which the organisation relies on it?

References

1. European Commission. Commission Implementing Regulation (EU) No 520/2012 on the performance of pharmacovigilance activities, consolidated version current at 12 February 2026. EUR-Lex. https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02012R0520-20260212
2. European Medicines Agency. Guideline on good pharmacovigilance practices (GVP) Module I – Pharmacovigilance systems and their quality systems. EMA/541760/2011. https://www.ema.europa.eu/en/documents/scientific-guideline/guideline-good-pharmacovigilance-practices-module-i-pharmacovigilance-systems-and-their-quality-systems_en.pdf
3. European Medicines Agency. Guideline on good pharmacovigilance practices (GVP) Module II – Pharmacovigilance system master file (Rev. 2). EMA/816573/2011 Rev. 2. https://www.ema.europa.eu/en/documents/scientific-guideline/guideline-good-pharmacovigilance-practices-module-ii-pharmacovigilance-system-master-file-rev-2_en.pdf
4. European Medicines Agency. Coordination of pharmacovigilance inspections — section addressing validation of pharmacovigilance processes supported by electronic systems and reliance on vendor qualification evidence. https://www.ema.europa.eu/en/coordination-pharmacovigilance-inspections-0
5. European Commission. EudraLex Volume 4, Annex 11: Computerised Systems. Revision January 2011. https://health.ec.europa.eu/medicinal-products/eudralex/eudralex-volume-4_en
6. U.S. Food and Drug Administration. Part 11, Electronic Records; Electronic Signatures — Scope and Application. Guidance for Industry, September 2003. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/part-11-electronic-records-electronic-signatures-scope-and-application
7. U.S. Food and Drug Administration. Computer Software Assurance for Production and Quality Management System Software. Guidance for Industry and FDA Staff, February 2026. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/computer-software-assurance-production-and-quality-management-system-software
8. International Society for Pharmaceutical Engineering. GAMP 5: A Risk-Based Approach to Compliant GxP Computerized Systems, Second Edition. ISPE, 2022. Industry guidance; not legislation.

Regulatory Note

This article distinguishes binding requirements from regulatory and industry guidance. For EU pharmacovigilance, Commission Implementing Regulation (EU) No 520/2012 is legally binding. EMA GVP Modules I and II provide the principal EU pharmacovigilance guidance discussed here. EU GMP Annex 11 is a GMP document and is cited for relevant computerised-system principles; it should not be interpreted as automatically applying GMP requirements to a system solely because that system supports pharmacovigilance. FDA guidance documents describe the Agency's current thinking and are non-binding unless specific statutory or regulatory requirements are cited. FDA's February 2026 Computer Software Assurance guidance is formally scoped to medical-device production and quality management system software. ISPE GAMP 5 is industry guidance. Organisations should determine the legal and regulatory requirements applicable to each system, jurisdiction, product and regulated use rather than relying on a generic CSV classification.