A System Release Certificate (SRC) is a formal controlled document that officially declares a validated system approved for GxP production use, issued after all validation activities are complete and the Validation Summary Report has been approved. It acts as the definitive authorisation record for operational deployment — stating that the system in its current configuration, version, and environment has been validated and is permitted to process, store, or report GxP-relevant data or support GxP-regulated operations.
No regulation mandates the SRC by that specific name, but the regulatory expectation that a system is formally released for GxP use before production deployment is embedded in EU GMP Annex 11 and FDA's General Principles of Software Validation. The SRC is the industry-standard document that demonstrates this formal release decision was made, by whom, when, and on what basis. Absence of a clear release record means an inspector cannot determine whether the validated state was formally confirmed before the system began processing regulated data.
The VSR release statement is part of the comprehensive validation evidence document — it authorises release within the context of the full validation narrative. A standalone System Release Certificate is a separate short-form document containing only the release decision: system identity, version, validation scope reference, release conditions if any, release date, and authorised signatures. Organisations typically issue a separate SRC when operational teams need a concise, standalone proof-of-release without carrying the full VSR to production floor access reviews or supplier audits.
Quality Assurance must be a mandatory signatory on the System Release Certificate — this signature is the GMP-controlled authorisation that the system is compliant and released for regulated use. The system owner typically co-signs to confirm operational acceptance. Some organisations also require IT or infrastructure sign-off confirming the released configuration matches what was validated. The key principle is that release for GxP use requires a formal QA approval, not an informal operational decision by the project team.
An inspection-ready SRC should contain: the system name and unique identifier, the specific software version and configuration baseline being released, the validation scope the release is based on (referenced by VSR document ID and version), the GxP activities or processes the release authorises, any conditions or limitations applying to the release, the release effective date, and signature blocks with name, role, date, and meaning for all required signatories. Version and configuration specificity is critical — a generic "the LIMS is released" statement without version detail is not adequate.
No. Using a system for GxP-regulated activities before formal release authorisation means operating outside a validated state — any data produced before the SRC is issued may not have the regulatory assurance required for its intended use. This includes using a system in "pilot production" or "soft launch" mode for regulated activities while release documentation is still being prepared. Temporary operational use before formal release is only acceptable for non-GxP purposes, and even this requires a clear documented boundary.
A conditional SRC authorises GxP use of a system while specific minor outstanding items are being resolved post-release — most commonly minor open discrepancies or low-risk documentation gaps that do not affect the system's fitness for its validated purpose. The conditional SRC must explicitly list each condition, specify the committed closure date and responsible party, and state what action will be taken if conditions are not closed by that date. A second, unconditional SRC or VSR update formally lifts the conditions upon verified closure.
The SRC must be reissued or formally updated whenever a change affects the validated configuration on which the original release was based — software version upgrades, configuration changes affecting GxP functions, hardware replacements, or changes to the validated environment such as server migration. The SRC is not a permanent document; it is a snapshot of the validated state at a specific point in time. An SRC referencing a configuration that no longer matches the running system is evidence that change control was not followed.
Every time a validated system undergoes a formal change that requires revalidation, the change control record should reference the new or updated SRC issued upon change validation completion. This creates a traceable chain: change request → change assessment → revalidation activities → updated SRC — giving inspectors a navigable history of every configuration change and its corresponding validated release state. An SRC that does not trace to a change control record for a known software update is a compliance gap.
Every system that has been validated for GxP use should have a System Release Certificate or equivalent release record, regardless of risk classification. The depth and content of the SRC may vary — a simple Category 3 system may have a brief combined release statement, while a complex Category 5 system warrants a detailed standalone SRC — but the principle that formal release documentation exists before production deployment applies across all GxP-relevant validated systems regardless of their specific risk tier.
The periodic review does not automatically invalidate the existing SRC — it is a scheduled assessment of whether the system remains in its validated state. If the periodic review concludes the system is fully compliant and no revalidation is needed, the review record documents this and the existing SRC remains valid. If the review identifies gaps requiring remediation and revalidation, a new or updated SRC should be issued upon completion of those activities, cross-referencing the periodic review record that triggered them.
The SRC is the formal document issuing the release decision for a specific validation project. The GxP Inventory entry is a live register record showing the system's current overall validation status — validated, conditionally released, pending periodic review, or retired — with a reference to the applicable SRC. The inventory is the dashboard; the SRC is the underlying evidence. An inventory entry showing "Validated" should always reference a specific, current SRC that supports that status.
Inspectors verify that the SRC specifies the exact system version and configuration released, that QA's signature is present with a date that post-dates the completion of all validation activities referenced, that the VSR or validation evidence it references is approved and accessible, that conditions on conditional releases have been formally closed, and that the configuration described in the SRC matches the system currently in production. A discrepancy between the SRC version and the operational system version is a direct indicator that a software change bypassed change control.
Either approach is acceptable provided the release decision is clearly documented, dated, and QA-approved. Embedding the release statement within the VSR works well for projects where the VSR is short and the release audience is the validation team. A separate SRC is preferable when the release needs to be presented independently — for supplier audits, IT change management systems, production floor SOPs, or multi-site deployments where the full VSR is not accessible to all parties who need proof of release status.
An SRC should be retained for the operational life of the system plus the applicable regulatory record retention period — commonly a minimum of five years after system retirement under FDA cGMP and EU GMP frameworks, though this extends for products with longer shelf-lives or where the system supported clinical data. Even after a system is replaced, the SRC provides evidence that GxP activities conducted during the system's operational life were supported by a formally validated, released system.
When a system is retired, the SRC should be formally superseded by a System Retirement Record or Decommissioning Report documenting that the system has been removed from GxP service, data has been migrated or archived appropriately, and the system can no longer be accessed for regulated use. The original SRC remains in the validation archive as evidence of the period during which the system was validly authorised for GxP use. The GxP Inventory entry should be updated to "Retired" with the decommissioning date.
The core content is the same — system identity, version, scope, QA approval, and release date — but some structural differences exist. EU GMP-regulated environments commonly reference Annex 11 and the Validation Master Plan in the SRC. FDA-regulated environments may additionally reference 21 CFR Part 11 applicability and electronic records scope. Organisations operating under both frameworks typically use a single SRC template that satisfies both by referencing applicable regulations in a compliance statement section rather than maintaining separate documents per jurisdiction.
Referencing specific version and configuration is what makes the SRC a meaningful compliance document rather than a generic statement. When an inspector asks whether the current production system is validated, the answer must trace to an SRC that describes the exact version and configuration in operation today. A version mismatch between the SRC and the running system is direct evidence that a software update was deployed without change control — one of the most serious and common CSV inspection findings.
Digital validation platforms issue, store, and track SRCs as structured electronic records within the validated system lifecycle — automatically linked to the corresponding VSR, the system's GxP Inventory entry, and any change control records that modify the validated state. When a system's configuration changes and a new SRC is issued, the platform supersedes the previous version and updates the inventory status in real time, ensuring the inventory always reflects the current release state without manual reconciliation between separate documents.