Validation Risk Assessment Rationale.

A properly designed and precisely executed Validation Risk Assessment analysis has proved over and over again to be key to the expedient completion of any compliant risk based validation project.
Our latest issue of this document reflects these principles and also incorporates the latest regulatory guidance document comments, into our current Validation Risk Assessment (VRA) document(now issue 10), which is now available for immediate download.  The use of this VRA ensures that the scope of all your validation activities is actually defined for you; by the execution of this risk based validation document.   This is now a mandatory requirement.


Part 11 will be interpreted narrowly; we are now clarifying that fewer records will be considered subject to part 11.


This would appear to mean that the original all embracing approach to all electronic records is to be dropped and the rigors of part 11 applied only to the data that directly affects product quality and safety, and record (of the product) integrity.


For those records that are to remain the subject of part 11, we will apply discretion in the validation of audit trails, record retention, and record copying.


This would appear to mean that if your in-house document control is secure and robust; then it will be acceptable in the matter of audit trail / record retention and record copying. 


We will enforce all predicate rule requirements, including predicate rule record and recordkeeping requirements.


This is a statement to the effect that in all other ways 21 CFR Part 11 will be enforced.


Accordingly, we recommend that, for each record required to be maintained under predicate rules, you determine in advance whether you plan to rely on the electronic record or paper record to perform regulated activities. We recommend that you document this decision (e.g., in a Standard Operating Procedure (SOP), or specification document).


This is a new requirement for a database of predicate (all) data records, giving a documented and approved justification for the method of storage.  Basically separating them into section such as number:

1.         It is not a predicate data.

2.         It is a predicate data, but does not require to be stored in compliance with Part 11.

3.         It is predicate data that must be stored in compliance with current Part 11 requirements.


New Interpretation:

A predicate data record does not required to be Part 11 compliant; unless it is the master copy of the predicate data and is stored in an electronic format. 


I.E. if the record is derived from an electronic source and is downloaded into a hard copy format; which then becomes your master copy of the record.  This paper copy is not subject to Part 11 requirements; but must comply with all the other rules and regulation governing the management of predicate data records.

VRA Introduction.

The question - How much validation? - has been an open subject for many years. Numerous companies brought in validation consultants, and or regulatory compliance experts, to guide them through these problems, but every so often, there would be clashes, or at least variations in opinion, in what the appropriate scope and depth of validation was. It was understood and accepted by the regulators that there was equipment in use, that full validation was inappropriate for, yet the design or misuse of that piece of equipment could affect product quality, so some degree of validation was required.

The more typical production equipment is mainly mechanical (but often intricate and complex), but frequently uses electronics to monitored and or managed it’s functionality and or record retention systems. Then at the very pinnacle of validation we have the mainly electronic systems running extremely complex sophisticated software programs or systems where the software manipulates data and accepts or rejects product quality base on the outcome of the data manipulation. All these systems play a major role in the product manufacturing process, they all require thorough validation using the existing framework of IQOQ - PQ, but they do not all require the same level of validation. How do we define the appropriate level?

Risk Based Validation

When we move away from these simple devices, to the average type of production equipment. Here we find a range of equipment varying from purely mechanical (but often intricate) equipment, to mechanical equipment assisted and or monitored and or managed by some degree of electronics. Then at the very pinnacle of risk based validation we have the mainly electronic systems running extremely complex sophisticated software programs. All these systems play a major role in the product manufacturing process, they all require thorough validation eiak assessment using the existing framework of IQOQ - PQ, but they do not all require the same level of validation. How do we define the appropriate level?

First we have to look at validation and how the level of validation can be varied independently of the scope. If we list all the tasks we consider essential to complex software driven equipment validation, then drop off the tasks we consider inappropriate to the next level of equipment complexity, and so on. We appear to have four levels, with a significant step change between each of them.

  • Mechanical/electronic/electrical/full life cycle software, validation.
  • Mechanical/electronic/electrical/software, validation.
  • Mechanical/electronic/electrical/software, calibration.
  • None

The requirement for 21 CFR Part 11 compliance, can occur at all three of the upper levels of validation and so is addressed in the Validation Risk Assessment protocol as a separate requirement. To find that a piece of laboratory equipment requires the same degree of validation as a Distributive Control System may be disquieting, however any equipment that uses software alone, to automatically derive whether the product passes, or fails to pass, an inspection stage, must be subjected to FLCV. The laboratory equipment may have one such stage, the DCS will have many, however, one or many, the software lineage for each system, must follow similar methodologies.

Our Validation Risk Assessment (VRA) takes you through this assessment process and enables you to make a documented and justified decision as to the level of validation each piece of equipment will receive. This fulfils your obligation to ensure that all software is assessed, as to FLCV applicability.

Validation Risk Assessment Scope.

This VRA will take you through the under listed points and allow you to make accurate justifiable assessments of risk for any system or piece of equipment. This will enable you to adjust your level or scope of validation effort and deliver soundly based risk based validation.

  • Outline.
  • Approvals.
  • Determination of Classification.
  • Prospective Validation.
  • Retrospective Validation.
  • Impact Assessment.
  • Impact Assessment Process.
  • Risk Scenario.
  • Likelihood.
  • Impact Severity.
  • Probability of Detection.
  • Impact Priority.
  • Impact Mitigation.
  • Assessment of Change.