Skip to main content

Validation and CSV

This page explains the validation posture of Better Comply, who owns the validated state, and what you need to put in place to validate the system for your own regulated use.

Who this is for

Quality and compliance owners preparing a Computer System Validation (CSV) package, and auditors assessing it.

What Better Comply provides, and what you own​

Read this first

Better Comply provides the controls, the design documentation, and the test evidence that support validation. It does not ship as a "validated system" in the abstract. Validation is performed by you, the customer, in your environment, against your intended use, and it is you who owns the resulting validated state and keeps its records. No vendor can validate a system on your behalf for your regulated process.

What this means in practice:

  • Better Comply gives you a documented design, enforced controls (audit trail, signatures, immutability, segregation of duties), and a test suite that exercises the regulated invariants.
  • You decide your intended use, write your user requirements, run your qualification, and sign off.
  • The validated state is yours to maintain through change control on your side.

GAMP 5 categorisation​

Better Comply is positioned as a GAMP 5 Category 4 (Configured Product), not Category 5 (Custom Application). The reasoning:

  • The underlying stack (the database engine, the auth provider, the hosting platforms, the AI model providers) is commercial off-the-shelf infrastructure with documented release histories. You treat these as vendor-validated and out of your validation scope.
  • Better Comply configures those components: the database policies and triggers, the backend routes, and the user-interface flows. That configuration layer is what receives validation.
  • The regulated invariants (recording a signature server-side, the immutability triggers, the fail-loud audit) are validated as configured behaviour, with unit tests and database-level tests.

The V-model and qualification stages​

A GAMP 5 validation follows a V-model: user requirements map to a Performance Qualification, functional specifications to an Operational Qualification, and design to an Installation Qualification.

StageQuestion it answersWhat you produce
IQ (Installation Qualification)Is the production environment the validated one?Confirm the deployed image, the database migrations, the environment, and the secrets match the validated specification.
OQ (Operational Qualification)Does each function work under controlled conditions?Run the test paths for the regulated journeys: signature capture, approval gating, immutability, fail-loud auditing, tenant isolation.
PQ (Performance Qualification)Does it perform correctly under production conditions?Exercise the real journeys at realistic load and confirm no half-written records under failure.

The qualification evidence (a passing test run, an IQ certificate, a PQ report, and a traceability matrix from requirement to test) is what you preserve as your validation package.

The CSV plan is a draft template

The internal CSV plan is a published template that lists the requirements, the qualification matrix, and the re-validation triggers. Some of its qualification suites are roadmap items rather than shipped artefacts. Use the plan as the structure for your own validation; confirm with BetterKnow which suites are available for the release you are validating before you rely on them.

Re-validation triggers​

Plan to re-run the affected qualification when any of these change:

  • A database migration that touches a regulated entity (evidence, versions, audit log, approvals).
  • The signature flow or the function that records evidence.
  • The set of fail-loud audit actions.
  • The pinned base image of the backend.
  • The AI model used for content or quiz generation, or the assistant.
  • A supported language is added or removed.

A re-validation does not require re-running tests unaffected by the change, but you must document the scope of what you skipped.

Where the supporting documents live​

Two internal quality documents support your validation and are maintained by BetterKnow:

  • The CSV plan - the GAMP 5 validation plan with the V-model, the requirements, the qualification matrix, and the artefact list. Ask your BetterKnow contact for the current version aligned to your release.
  • The DPIA (Data Protection Impact Assessment) - the privacy assessment covering the personal data Better Comply processes, the lawful bases, sub-processors, international transfers, and data-subject rights. The DPIA is a draft baseline pending Data Protection Officer review; for a regulated deployment you (as the controller) inherit it and may need to extend it.
Controller and processor

For most deployments the customer is the controller of the employee data and BetterKnow is the processor, acting on documented instructions under a Data Processing Agreement. The platform, hosting, and AI providers are sub-processors. Confirm the current sub-processor list with BetterKnow.

What you need for your own validation​

A practical starting checklist for your CSV package:

  • Your intended-use statement and user requirements for Better Comply in your process.
  • The IQ record confirming the deployed release matches the validated specification.
  • The OQ evidence for the regulated journeys you depend on.
  • The PQ evidence at your expected scale.
  • A traceability matrix from each requirement to its test.
  • The DPIA inherited and extended for your controllership.
  • Your own change-control procedure that triggers re-validation per the list above.
  • Your retention procedure (see the note on retention in Data integrity).