Vault Validation Management is a new application in the Vault Quality Suite currently available to customers participating in the early adopter program. The application helps organizations manage and execute paperless validation across validation disciplines including: Computerized Systems Validation (CSV), Facility, Equipment, and Utility (FUE), process validation, cleaning validation, and method validation. Validation Management includes several key features:

  • Validation Management automation helps facilitate the creation of versions of validation entities as well as requirements.
  • Additional objects support validation activities and deliverables needed to prove an entity has been validated.
  • A paperless test execution experience where pre-approved test scripts consisting of setup steps and execution steps can be executed by one or more assigned executors. Executors can perform procedures defined by test authors, access requirements being challenged, describe their observed results, and upload attachments to provide objective evidence. 
  • Exceptions or discrepancies encountered during execution can be created directly from the test step where the issue was encountered. The discrepancy will then undergo a workflow for investigation, root cause, and corrective action.

Validation Management Data Model

Validation Management uses these core objects:

  • Validation Inventory Item: An asset that needs to be managed by an organization’s validation processes. Validation Management supports the following Inventory Item types: Computer System, Cleaning, Equipment, Facility, Method, Process, and Utility. For example: VernSoft GxP System
  • Validation Entity: A specific version of an asset at a point in time that will be evaluated by an organization’s validation process. In other words, a versioned instance of an Inventory Item which contains the validation information for that specific version. For example: VernSoft GxP System v1.4 or VernSoft GxP System v1.5. A Validation Entity will have its own unique requirements in addition to requirements that are still applicable from a prior version. The Validation Entity will also have its own unique activities and validation deliverables.
  • Validation Activity: A specific activity performed upon a validatable entity. This object describes the purpose and scope of the deliverables needed for an entity to become validated and used in a production environment. Additional information captured includes start and end dates, participants, and all the deliverables needed to complete the activity. Activities have the following types: Initial Qualification / Commissioning, Change / Modification, and Periodic Review. For example: VernSoft GxP System v1.5 Upgrade Validation Project. The validation activity can also be thought of as a validation project that must be performed in order for the entity to become validated and used in production, while collecting all supporting evidence and completing all necessary validation procedures.
  • Validation Deliverable: A document or other artifact which supports or marks a milestone in a Validation Activity. The deliverable contains the work done to demonstrate that an entity is or is not validated. The Validation Deliverable record functions as a placeholder for a deliverable document or test deliverable. For example: Validation Plan 1.0 (VernSoft GxP System v1.5).docx. Deliverables have the following types:
    • Design / Requirements Deliverable: Used for a User Requirement Specification document, Functional Requirement Specification document, or Design Specification document.
    • Planning Deliverable: Used for validation plan documents.
    • Reference Deliverable: Used in cases where you need to leverage validation deliverables or content from a vendor, supplier, or other third party.
    • Report Deliverable: Used for report documents such a validation summary report or a requirements trace matrix report.
    • Risk Assessment: Used for risk assessments or impact assessment documents.
    • Testing Deliverables: Used for test protocols and test scripts. Each test protocol or test script needs one deliverable. 
  • Validation Requirement: Describes the requirements against which entity or asset will be evaluated. When a new version of a Validation Entity is created, Vault copies all the associated requirements from the previous entity. There are three types of requirements: User Requirements, Functional Requirements, and Design Specifications. For example: UR-VernSoftGxP-1.
  • Test Protocol: Contains narrative content stored in a document record that is relevant to the overall protocol and also consists of one or many test scripts. The Test Protocol narrative content includes information such as the purpose, scope, system overview, responsibilities, reference information, execution requirements, appendices, or other information.
  • Test Script: Contains steps to be performed by assigned Executors to fulfill a required Testing Deliverable that is part of the overall validation activity. Executors perform tests in the test execution interface. A Test Script can be standalone or part of a Test Protocol. If multiple attempts to execute a Test Script are needed for a particular Testing Deliverable, copies of the original Test Script can be created for each additional test run.
  • Requirements Traceability Matrix: Vault creates placeholder Requirements Traceability Matrix records when requirements are associated with an entity version. An entity version is created from a prior version such that each approved requirement has a trace matrix record for that version of the entity. These placeholder records are used to identify requirements which should be tested, but have not yet been planned for testing. Existing placeholder records are either updated or new records are added during test script authoring.

Validation Management Roles

Validation processes require the collaboration of several individuals with separate responsibilities. These individuals are represented in Vault Validation Management via the following roles.

Business Process Owner or System Owner

The owner of the system or process being tested. This user is typically involved with authoring requirements, contributes to assigned validation deliverables, and is part of the approval process for validation deliverables.


Any authority involved in the approval process for validation deliverables and fully executed Test Scripts. There can be multiple approvers for a given validation deliverable.

Independent Reviewer

An individual involved in an independent review of individual Test Scripts. Responsible for ensuring that any discrepancies have been properly addressed and that the system is properly challenged to ensure that the validated state is reliable and compliant prior to involving final approvers.

Quality Unit

The member of the quality assurance team with final authority over whether a validation deliverable is approved or rejected. This also applies to Testing Deliverables to determine whether the test script has passed or failed, or is approved or rejected.

Test Author

A user who is responsible for authoring Test Protocols and Test Scripts, typically a member of the Validation team. For Test Scripts, the Test Author will add the content including all test steps that must be performed to ensure that all defined user and functional requirements will be challenged appropriately prior to submitting the Test Script for pre-approval. Once pre-approved, Test Scripts are available for execution by assigned executors.

Lead Executor

In cases where multiple Executors are performing test steps within the same Test Script, the Lead Executor is responsible for overall governance of execution of the test script. The Lead Executor often performs a review of the testing work prior to submitting it for independent review or formal approval.


A user responsible for performing assigned Test Steps defined in Test Scripts. While test scripts often have only one Executor, in some cases the individual steps within a test script are assigned to multiple Executors.