QPPV.COM
Archived Revision: You are viewing historical Version 1 of this article. View current active version →

How to Read and Apply EU GVP Guidance in Practice

Audio Lesson 14 min

How to Read and Apply EU GVP Guidance in Practice

Introduction

Reading Good Pharmacovigilance Practices (GVP) effectively is different from reading a textbook or an operating procedure.

The purpose of GVP is to provide guidance within the EU pharmacovigilance framework. A pharmacovigilance professional therefore needs to move through several layers of interpretation before a GVP statement becomes an operational control.

A useful sequence is:

GVP text
   ↓
Scope and context
   ↓
Legal and regulatory basis
   ↓
Interpretation
   ↓
Operational requirement
   ↓
Process / system / responsibility
   ↓
Control
   ↓
Evidence
   ↓
Oversight and continuous improvement

This approach avoids two common extremes. The first is treating GVP as optional reading with no operational consequence. The second is copying every sentence into an SOP and assuming that documentation alone creates compliance.

1. Start With the Regulatory Question

Before opening a GVP module, define the question that needs to be answered.

For example:

A precise question helps identify the relevant GVP module and prevents unnecessary interpretation of unrelated sections.

2. Identify the Applicable GVP Document

GVP contains multiple modules and annexes, and a single regulatory question may involve more than one.

The first task is therefore to identify:

  1. the primary GVP module;
  2. relevant annexes;
  3. linked GVP modules;
  4. applicable EMA or Commission guidance;
  5. and the underlying legislation.

The goal is not merely to find a sentence containing the desired answer. It is to identify the complete regulatory context.

3. Check the Current Version

GVP guidance can be revised.

Before relying on a requirement, establish:

A procedure based on an obsolete GVP revision can remain internally consistent while still being regulatorily outdated.

4. Read the Scope Before the Requirements

The scope section is one of the most important parts of a GVP document.

It tells the reader what the document is intended to address and can identify limitations or relationships with other guidance.

A useful reading order is:

Title
 ↓
Scope
 ↓
Legal / regulatory context
 ↓
Definitions
 ↓
Main requirements
 ↓
Cross-references
 ↓
Annexes / examples

Reading the scope first reduces the risk of applying a requirement outside its intended context.

5. Separate Law From Guidance

A GVP statement should be understood in relation to its legal basis.

The reader should ask:

Is this requirement directly established by legislation, or is GVP providing guidance on how the legal requirement should be achieved?

This distinction matters when interpreting language, assessing deviations and defending a regulatory position.

It also prevents an organisation from creating an unnecessarily rigid internal rule simply because it has converted guidance into absolute wording without considering context.

6. Read the Whole Paragraph, Not a Single Sentence

A common regulatory-reading error is extracting one sentence from a long section and treating it as a standalone requirement.

GVP statements often contain qualifiers such as:

Those qualifiers can materially affect interpretation.

The surrounding paragraphs should therefore be read before an internal requirement is drafted.

7. Identify the Subject of Each Requirement

For every important statement, identify who or what is expected to act.

Possible subjects include:

This matters because a requirement imposed on an MAH cannot automatically be assigned as a personal obligation of the QPPV or an operational analyst.

8. Convert the Statement Into an Outcome

The next step is to identify what the requirement is actually trying to achieve.

For example, a requirement concerning oversight may ultimately seek to ensure that the responsible person has sufficient visibility of the system to identify material weaknesses.

The operational question becomes:

What outcome would demonstrate that this requirement is being met?

This is more useful than asking only what document needs to be created.

9. Distinguish Activity From Control

An activity is something people do.

A control provides confidence that the activity is performed correctly and consistently.

For example:

Activity Control
Process safety reports Timeliness and quality monitoring
Review literature Defined search strategy and review evidence
Perform signal assessment Independent or appropriate review and documented decision
Update an RMP Version control and regulatory approval tracking
Manage a vendor KPI review, issue escalation and audit oversight

A compliant system needs both the activity and appropriate controls around it.

10. Translate GVP Into an Operational Requirement

A useful internal formulation is:

GVP expectation
      ↓
"Our system must be able to..."
      ↓
Process requirement
      ↓
Responsible role
      ↓
System / data requirement
      ↓
Control
      ↓
Evidence

For example, instead of copying "signals should be reviewed regularly" into an SOP, the organisation should determine what regular means for the relevant system, who performs the review, what data are reviewed, how completion is demonstrated and what happens when a review is missed.

The internal control should be justified by the regulatory context and the characteristics of the system.

11. Avoid the Copy-GVP-to-SOP Trap

One of the weakest ways to implement GVP is to copy regulatory wording directly into an SOP.

The resulting SOP may sound compliant but still fail to answer practical questions such as:

An SOP should describe the organisation's controlled process, not merely reproduce the source guidance.

12. Do Not Over-Engineer Either

The opposite problem is turning every GVP statement into a complex procedural requirement.

Over-engineering can create:

A proportionate implementation should achieve the required regulatory outcome without creating controls that provide little additional assurance.

13. Build a Traceability Chain

For important requirements, maintain traceability from source to evidence.

A useful model is:

GVP section
   ↓
Regulatory interpretation
   ↓
Internal requirement
   ↓
SOP / process
   ↓
System control
   ↓
Quality check
   ↓
Record / evidence
   ↓
Oversight

This chain is particularly valuable during audits and inspections because it allows an organisation to explain not only what it believes the requirement means but how the requirement is implemented.

14. Use a GVP Requirements Matrix Carefully

A requirements matrix can be useful for important or high-risk areas.

A practical matrix might contain:

Field Example purpose
GVP source Identifies exact guidance section
Legal basis Identifies underlying legislation
Requirement Summarises the expectation
Interpretation Explains organisational meaning
Process Identifies implementation
Owner Identifies accountability
System Identifies supporting technology
Control Identifies assurance mechanism
Evidence Identifies retained record
Metric Identifies monitoring where appropriate
Risk Identifies consequences of failure
Status Tracks implementation

The matrix should remain a management tool, not become an enormous duplicate copy of the GVP library.

15. Identify the Risk of Non-Compliance

Not every requirement has the same operational risk.

For each important requirement, consider what could happen if the control fails.

Potential consequences include:

Risk assessment helps determine where stronger controls, monitoring or escalation are justified.

The next chunk will examine practical interpretation techniques, cross-referencing between GVP modules, evidence, metrics, deviations, CAPA and inspection testing.

14. Start With the Regulatory Question

The most efficient way to use GVP is to begin with a defined question rather than reading the framework indiscriminately.

For example:

Once the question is defined, identify the relevant GVP module, section and related guidance.

This prevents a common failure mode in regulatory interpretation: collecting large amounts of regulatory text without determining what the organisation actually needs to achieve.

15. Identify the Scope Before the Requirement

Before extracting a requirement from GVP, establish its scope.

Ask:

  1. Which products does it apply to?
  2. Which organisations or roles are addressed?
  3. Which pharmacovigilance activity is covered?
  4. Does it apply universally or only where a condition is met?
  5. Is the statement describing a legal requirement, guidance, an example or an explanatory principle?

Scope errors can produce both over-compliance and under-compliance.

A requirement that applies only to a particular activity should not automatically be applied to every PV process. Conversely, a requirement with broad scope should not be restricted to the department that happens to perform the activity.

16. Read the Definitions

Definitions are often more important than they first appear.

Terms such as signal, risk, safety concern, quality system, pharmacovigilance system, important identified risk and important potential risk can have specific meanings in the regulatory framework.

Before designing an SOP or control around a GVP requirement, confirm that the organisation is using the relevant regulatory definition.

A seemingly small terminology error can propagate through procedures, training, metrics and inspection responses.

A practical regulatory interpretation should distinguish three layers:

Layer Question
Legislation What is legally required?
GVP How does EU guidance describe good implementation?
Internal procedure How will this organisation achieve and control it?

This prevents a company procedure from claiming that a particular internal method is mandated by EU law when it is actually one acceptable way of implementing a broader requirement.

It also prevents the opposite mistake of treating an important regulatory expectation as optional simply because it appears in guidance rather than in the wording of the primary legislation.

18. Look for the Actionable Verb

When reading a dense regulatory paragraph, identify what action the text actually requires.

Typical actions include:

For example, if a section says that an MAH should maintain oversight of an activity, the actionable question is not merely "Do we have oversight?" but:

What mechanism makes oversight reliable, and what evidence demonstrates that it occurs?

19. Convert the Requirement Into an Outcome

A useful next step is to express the regulatory expectation as an outcome.

For example:

Regulatory statement: The MAH should monitor the performance of an important outsourced activity.

Operational outcome: The MAH can demonstrate that the outsourced activity is monitored, material failures are identified and escalated, and corrective actions are followed to effectiveness.

This translation makes the requirement testable.

20. Identify the Accountable Role

Every material requirement should have a clear owner or governance interface.

The owner may be:

The person performing the activity and the person accountable for oversight are not necessarily the same.

This distinction becomes particularly important for outsourced processes.

21. Identify the Process

Once the expected outcome and accountable role are clear, identify the process that achieves it.

A process description should answer:

Trigger
  ↓
Input
  ↓
Activity
  ↓
Decision
  ↓
Output
  ↓
Quality control
  ↓
Escalation if required

This is much more useful than copying GVP language into an SOP without explaining how work actually flows.

22. Identify the System and Data Dependencies

Modern PV processes are usually supported by multiple systems.

A regulatory requirement may depend on:

The interpretation should therefore identify which systems and data are critical to achieving the required outcome.

23. Identify the Control

A process is not necessarily controlled merely because it has an SOP.

Controls can include:

The control should address a known risk in the process.

24. Identify the Evidence

A strong interpretation asks what evidence would exist if the process were working correctly.

Examples include:

Requirement Evidence
Timely processing System timestamps and performance records
Signal oversight Signal log and documented decisions
Vendor oversight KPI reviews, issue logs and governance records
QPPV oversight Governance documentation and escalation records
Training Training records and effectiveness evidence
CAPA Investigation, actions and effectiveness review
Regulatory submission Submission and authority correspondence

Evidence should be proportionate to the importance and risk of the activity.

25. Test the Interpretation Against Failure Modes

A useful way to validate an interpretation is to ask how the process could fail.

For example, if the requirement concerns timely reporting, possible failure modes include:

If the proposed control would not detect or prevent the important failure modes, the implementation is probably incomplete.

26. Use Inspection Findings as a Reality Check

Inspection findings can reveal how regulators have identified weaknesses in real pharmacovigilance systems.

A useful approach is not to copy the finding but to ask:

Could the same underlying failure occur in our system?

For each relevant finding, identify:

This converts inspection history into preventive learning.

27. Do Not Treat an Inspection Finding as a Universal Rule

An inspection finding is evidence about a particular system under particular circumstances.

It may illustrate a broader regulatory principle, but it should not automatically be converted into a universal requirement.

The correct approach is:

Inspection finding
      ↓
Understand context
      ↓
Identify underlying principle
      ↓
Compare with GVP/legal requirement
      ↓
Assess own system
      ↓
Implement change only if justified

This prevents compliance programmes from becoming collections of reactions to isolated inspection anecdotes.

28. Handle FAQs Carefully

Regulatory FAQs can be useful where they come from an authoritative source and address a genuine interpretive question.

Before relying on an FAQ, establish:

An FAQ can clarify interpretation without replacing the underlying legal or regulatory source.

29. Build a Traceability Matrix

For important GVP requirements, a traceability matrix can provide a useful governance tool.

A practical structure is:

GVP reference Legal basis Internal requirement Process Owner Control Evidence Risk
Module/section Directive/Regulation What must be achieved How Accountable role Verification Record Consequence of failure

The matrix should be maintained as a controlled governance tool rather than treated as a one-time compliance exercise.

30. Avoid Copying GVP Into SOPs

A frequent mistake is to reproduce regulatory text directly in internal procedures.

This creates several problems.

The SOP may become difficult to operate, regulatory wording may be interpreted incorrectly, and changes to GVP can create extensive document-maintenance work without improving the underlying process.

A better SOP explains how the organisation implements the applicable expectation.

For example:

GVP: describes the regulatory expectation.

SOP: defines the company's process, responsibilities, controls and evidence.

Work instruction: explains the detailed operational steps.

System: enforces or supports the relevant controls.

31. Avoid Turning Guidance Into Arbitrary Internal Deadlines

An organisation may legitimately establish internal targets that are more conservative than the regulatory minimum.

However, the distinction should be documented.

For example:

Regulatory requirement: X.

Internal operational target: Y, established to provide sufficient margin for quality review and escalation.

This prevents an internal management target from later being misrepresented as an explicit statutory requirement.

32. Assess Proportionality

Not every requirement requires the same degree of procedural complexity.

The implementation should consider:

Proportionality should reduce unnecessary complexity without weakening an essential control.

33. Review Cross-Module Dependencies

Before finalising an implementation, check related GVP modules.

For example, a change affecting signal management may also affect risk management, periodic reporting, safety communication and the QPPV's oversight.

Cross-module review reduces the risk of solving one compliance problem while creating another.

34. A Repeatable GVP Interpretation Method

The following method can be applied to almost any GVP requirement:

1. Find the source
2. Confirm current version
3. Read scope and definitions
4. Identify legal basis
5. Identify the actionable expectation
6. Define the required outcome
7. Identify accountable roles
8. Map the process
9. Identify systems and data
10. Define controls
11. Define evidence
12. Test failure modes
13. Check related GVP modules
14. Review relevant inspection experience
15. Implement proportionately
16. Verify effectiveness
17. Maintain change control

This is the core method that will be used throughout the GVP article series.

The final chunk will apply this method to practical examples, explain how to prepare for inspection questions based on GVP interpretation, and provide References and the Regulatory Note.

33. A Practical GVP Reading Workflow

A useful workflow for applying GVP to a real compliance question is:

Define the question
       ↓
Identify the applicable legislation
       ↓
Locate the relevant GVP module/section
       ↓
Read the scope and definitions
       ↓
Identify the actual expectation
       ↓
Check linked GVP modules and annexes
       ↓
Assess current EMA/Commission guidance
       ↓
Translate the expectation into controls
       ↓
Identify evidence and oversight
       ↓
Assess gaps and implement changes

This prevents the common mistake of starting with an isolated sentence and immediately writing or changing an SOP.

34. From Regulatory Text to an Inspectable Control

A regulatory expectation becomes useful only when it can be translated into an operational control.

For each significant expectation, ask:

Question Output
What is required? Requirement statement
Why is it required? Regulatory objective
Who owns it? Accountability
How is it performed? Process
What supports it? System/data
How is it checked? Quality control
What proves it? Evidence
What happens if it fails? Deviation/CAPA/escalation
Who oversees it? Management/QPPV oversight

This converts GVP from reference material into a working compliance framework.

35. Avoiding Two Opposite Errors

There are two common extremes when organisations translate GVP into internal requirements.

Under-implementation

The organisation acknowledges the GVP expectation but does not create adequate controls to achieve it.

Over-implementation

The organisation converts contextual guidance into unnecessarily rigid internal rules that create complexity without improving pharmacovigilance control.

The objective is neither minimal compliance nor maximum bureaucracy. It is a proportionate system that reliably achieves the applicable regulatory objective.

36. GVP and SOP Writing

An SOP should describe how the organisation actually performs an activity.

It should not simply reproduce GVP wording.

A good SOP should establish, as appropriate:

The GVP source can be cited or referenced separately so that the SOP remains an operational document rather than a regulatory essay.

37. GVP and Work Instructions

Detailed operational steps often belong in work instructions, system procedures or controlled job aids rather than in a high-level SOP.

This separation can make the system easier to maintain when a system configuration or operational detail changes without changing the underlying regulatory requirement.

The regulatory requirement, SOP and work instruction should nevertheless remain traceable to one another.

38. GVP and Training

Training should focus on what personnel must do, not simply on whether they have read GVP.

For example, case-processing staff may need training on the operational requirements derived from relevant GVP guidance rather than a general course covering every GVP module.

Training effectiveness should also be considered where appropriate. Completion of a training assignment demonstrates exposure to the material; it does not necessarily demonstrate competence.

39. GVP and Change Control

When GVP or related regulatory requirements change, the organisation should assess whether the change affects:

The assessment should document the rationale for changes or for determining that no change is necessary.

This is especially important when a revised GVP document changes an established operational expectation.

40. GVP and Regulatory Intelligence

Regulatory intelligence should identify relevant changes early enough for the organisation to assess and implement them before they create a compliance gap.

A practical process can include:

  1. monitoring authoritative sources;
  2. identifying new or revised documents;
  3. determining applicability;
  4. assessing effective dates;
  5. performing an impact assessment;
  6. assigning actions;
  7. implementing approved changes;
  8. verifying implementation;
  9. and retaining evidence.

The process should distinguish genuine regulatory changes from documents that are merely informational or unrelated to the organisation's activities.

41. GVP and Inspection Preparation

Inspection preparation should test the system against actual GVP expectations rather than attempting to predict every question an inspector might ask.

For each important process, the organisation should be able to demonstrate:

Requirement
   ↓
Procedure
   ↓
Actual execution
   ↓
Quality control
   ↓
Exception handling
   ↓
Evidence
   ↓
Oversight

If these links cannot be demonstrated, the problem is likely to be systemic rather than merely documentary.

42. Learning From Inspection Findings

Inspection findings are most useful when analysed for the underlying system weakness.

For example, a finding concerning overdue safety reports may initially appear to be a case-processing problem. A deeper review might identify weaknesses in triage, vendor oversight, escalation, workload management or management information.

The learning process should therefore move from:

finding → root cause → control weakness → systemic corrective action.

This is more valuable than simply adding another checklist item.

43. Using FAQs Correctly

FAQs can resolve practical questions that arise when applying regulatory guidance, but their authority depends on their source and context.

Before relying on an FAQ, establish:

An FAQ should supplement, not replace, review of the underlying legal and regulatory framework.

44. A GVP Evidence Matrix

A useful compliance tool is a GVP evidence matrix.

Requirement Source Process Owner Control Evidence Oversight
Regulatory expectation GVP/legal source SOP/process Function QC/KPI Record Governance/QPPV

The matrix should focus on significant requirements rather than attempting to turn every sentence of GVP into a separate checklist item.

45. A GVP Gap Assessment

When performing a gap assessment, classify findings according to their actual significance.

A practical assessment can distinguish:

This prevents every documentation discrepancy from being treated as equivalent to a failure of the underlying pharmacovigilance process.

46. Questions a QPPV Should Ask

A QPPV reviewing a significant GVP requirement can ask:

  1. Do we understand the applicable requirement and its legal basis?
  2. Is the requirement applicable to our products and system?
  3. Who is accountable?
  4. How is the activity performed in practice?
  5. What data or system supports it?
  6. What controls detect errors or delays?
  7. What metrics or quality indicators demonstrate performance?
  8. What happens when the process fails?
  9. What evidence would we show an inspector?
  10. How do we know the control is effective?

These questions provide a practical bridge between regulatory interpretation and QPPV oversight.

47. Questions an Inspector May Ask

An inspector approaching the same requirement may ask:

A system designed to answer these questions naturally is usually stronger than one designed merely to pass a document review.

48. What Should Not Be Done

Several approaches should be avoided.

Do not copy GVP into SOPs

Regulatory guidance and operational procedures have different purposes.

Do not rely on old versions

Always establish which version applies to the question and date being assessed.

Do not treat FAQs as legislation

Confirm their status and underlying legal basis.

Do not assume a checklist proves compliance

Evidence of completed checks is useful, but the underlying process must work.

Do not ignore linked modules

A requirement may depend on controls described elsewhere in GVP.

Do not confuse training completion with effectiveness

A trained person can still perform a process incorrectly.

49. The Long-Term Value of This Approach

A structured approach to reading GVP creates reusable organisational knowledge.

Instead of repeatedly asking what a particular paragraph means, the organisation can maintain a traceable relationship between:

Law
 ↓
GVP
 ↓
Internal interpretation
 ↓
Process
 ↓
System
 ↓
Control
 ↓
Evidence
 ↓
Oversight

This is particularly valuable when personnel, systems, vendors or regulatory requirements change.

Key Takeaways

  1. Start with the regulatory question rather than reading GVP indiscriminately.
  2. Identify the underlying legislation before interpreting the guidance.
  3. Read the relevant GVP section together with its scope, definitions and cross-references.
  4. Translate significant expectations into accountable processes and controls.
  5. Keep regulatory guidance distinct from operational SOPs and work instructions.
  6. Build evidence into the process rather than attempting to reconstruct it for an inspection.
  7. Use metrics, quality controls, audits, deviations and CAPA together to assess effectiveness.
  8. Assess GVP revisions for operational impact rather than simply recording that they were reviewed.
  9. Use inspection findings and authoritative FAQs as contextual learning tools, while verifying their status and currency.
  10. The QPPV should be able to connect significant GVP expectations to implementation, control, evidence and oversight.

References

  1. European Medicines Agency. Good Pharmacovigilance Practices (GVP). Current GVP modules, annexes and related guidance for human medicines.
  2. European Parliament and Council. Directive 2001/83/EC, as amended. Community code relating to medicinal products for human use and the EU legal framework for pharmacovigilance.
  3. European Parliament and Council. Regulation (EC) No 726/2004, as amended. Union procedures for authorisation and supervision of medicinal products and relevant pharmacovigilance provisions.
  4. European Commission. Commission Implementing Regulation (EU) No 520/2012, as amended. Detailed rules concerning pharmacovigilance activities under the EU pharmaceutical framework.
  5. European Medicines Agency. Pharmacovigilance post-authorisation guidance. Current regulatory information and procedural guidance relevant to EU pharmacovigilance.

Regulatory Note

This article explains an approach to reading and applying EU GVP guidance for educational and operational-learning purposes. It does not constitute legal advice and does not replace current legislation, GVP documents, regulatory decisions or other applicable guidance.

GVP is periodically revised. Before applying an expectation to a live compliance question, verify the current version, publication status, applicability, effective date and any transitional arrangements. The underlying EU legislation and legally operative regulatory decisions remain essential to determining the legal status of an obligation.

Where an FAQ, inspection finding or other explanatory material is discussed, its source and regulatory status should be verified before it is relied upon for a live regulatory decision.

Revision History

Related Articles

What Are EU Good Pharmacovigilance Practices (GVP)?

Introduces EU Good Pharmacovigilance Practices, explaining their legal context, structure, role in the pharmacovigilance system, relationship with legislation and practical importance for MAHs, QPPVs and inspections.

Common EudraVigilance Inspection Findings

Understanding how inspectors evaluate EudraVigilance compliance, reporting activities, access controls, reconciliation processes and signal management oversight.

EU Pharmacovigilance Inspection Findings: Cross-Functional and Interface Controls

A practical framework for understanding how inspectors test whether pharmacovigilance responsibilities and information flows remain effective across organisational boundaries.

Last reviewed: 2026-08-24