GxP & 21 CFR Part 11 Glossary

A framework for data integrity: Attributable, Legible, Contemporaneous, Original, Accurate, plus Complete, Consistent, Enduring, and Available. Every audit trail in a regulated system is checked against these nine criteria.

EU GMP Annex 11 — the European requirements for computerised systems used in regulated manufacturing. Complements 21 CFR Part 11 with additional emphasis on risk management and supplier assessment.

The recorded choice of whether a conditional document is needed for a specific release. Requires a justification and electronic signature; a "Not needed" decision counts as complete.

A formally approved and frozen configuration at a specific point in time. Often referenced as a "configuration baseline" in the VAL gate document set.

Corrective and Preventive Action — a structured process for investigating and resolving a quality issue, and for preventing its recurrence. Regulated releases may require CAPA closure before PROD.

The formal process by which proposed changes to a validated system are documented, assessed, approved, and implemented. In ReleaseGuard, this is often represented by the change request document and a matrix change request.

Chemistry, Manufacturing, and Controls — the section of a regulatory submission describing how a drug or biologic is made, tested, and controlled. Applies to pharma; not typically relevant to software releases.

A document that may or may not be required for a given release, depending on context. Requires an explicit applicability decision before the assigned stage gate.

The discipline of tracking and controlling changes to a system's configuration items — code, infrastructure, and documentation.

The first of three hard gates. Requires all pre-development documentation (change request, requirements, risk assessments, validation plan) to be approved before the release moves to In Progress.

A cryptographically verifiable identifier of the signer, distinct from an electronic signature. Part 11 permits either, provided the signature meets the applicable requirements.

The stable identifier of a controlled document (e.g. SDS-771). Matrix rules define whether a document keeps its ID across releases or receives a new one.

The version of a documentation matrix currently in force. New releases use the effective version; when a new version is approved, the prior version is superseded.

A legally binding substitute for a handwritten signature under 21 CFR Part 11. Must capture the signer, time, and meaning of the signature. In ReleaseGuard, approval-type actions require password re-entry.

Umbrella term for the Good Practice regulations — GMP (manufacturing), GLP (laboratory), GCP (clinical), GDP (distribution). Used to describe any regulated environment where quality systems are required.

The international guideline on the Pharmaceutical Quality System, establishing the framework for lifecycle management, corrective actions, and management review.

A document assessing the impact of a proposed change on the validated state of a system. Typically required by the DEV gate for major and minor upgrades.

A document state after an author has submitted it, before a reviewer has signed off. Rejection returns the document to Draft.

Documented evidence that a system or piece of equipment has been installed in accordance with the design specification and the manufacturer's requirements.

A single line in a documentation matrix: a document, a release type, a requirement level (required/conditional/N/A), a stage gate, and version behaviour.

A reporting point in a project, distinct from a stage gate. Milestones can be missed without blocking progress; gates cannot.

Documented evidence that a system operates as intended throughout its anticipated operating ranges. Follows IQ and precedes PQ.

Documented evidence that a system consistently performs according to its intended use under production conditions. Sometimes called process validation in pharma.

The third and final hard gate. Requires validation completion evidence and all production-stage documents to be approved before production deployment is authorised.

In ReleaseGuard, one of three approvers required for a product matrix change request. Not a Product Owner in the Agile sense.

The role responsible for approving reviewed documents, matrix versions, DEV/VAL/PROD stage gates, and final release authorisation. Must be a different person from the author and reviewer.

A document defining the approach, scope, and acceptance criteria for IQ, OQ, and PQ. Usually due by the VAL gate.

A bundled export containing approved file revisions, the signature manifest, the release audit CSV, and SHA-256 checksums. Marked preliminary until the release reaches Released status.

The role responsible for managing products and releases, assigning people, deciding applicability, recording manual deployments, and signing release-stage readiness.

An action that returns an approved document to Draft, with a recorded reason. A release in a promotion stage returns to In Progress when this occurs.

A document identifying potential hazards, likelihood, and mitigation for a proposed change or system. Typically required by the DEV gate and, in some matrices, by hotfixes as well.

A matrix rule stating that the document retains its existing ID with a new version number on the next release. Contrasts with the new-ID rule.

The requirement that no single person can complete a critical process end-to-end. In document workflows: author, reviewer, and approver must be three different people.

A cryptographic hash algorithm used to fingerprint files. In ReleaseGuard, every uploaded file is hashed at submission and re-checked at review/approval time; approval is refused if the fingerprint has changed.

Standard Operating Procedure — a written instruction describing how a routine task or process is performed in a regulated environment.

A defined point in the release lifecycle where a release cannot proceed until specific conditions are met. Distinct from a milestone: gates block, milestones do not.

The state of a documentation matrix version that has been replaced by a newer approved version. Existing releases created under the superseded version continue to use it unless moved by a change request.

A document describing the architecture and design of a system. Typically required by the VAL gate for major and minor upgrades, and conditional for patches and hotfixes.

A document mapping requirements to design elements and test cases. Used to demonstrate complete coverage of the specification. Required by the VAL gate.

User and Functional Requirements Specification — a document defining what a system must do, from both the user and functional perspective. Typically required by the DEV gate.

User Requirements Specification — a document defining the user-level requirements of a system. Typically required by the DEV gate.

The second of three hard gates. Requires development verification evidence to be signed and all validation-stage documents (SDS, IQ, OQ, traceability matrices) to be approved.

A document defining the overall approach to validating a system or change — scope, responsibilities, deliverables, and acceptance criteria. Typically required by the DEV gate.

The ordered record of changes to a document or matrix over time. Some matrix rules require the history to be updated when a new version is created; others do not.