Independent and not affiliated with the FDA, MHRA, ISPE, PDA, or any agency. Get the appgoutham@madhadi.com
madhadi.comData Integrity & GxP Quality
Browse all topics → Articles Templates & Procedures Learning paths GlossaryScenariosToolsRegulatory ReferencesLearning PathsTopics About Start here
Form Plug-and-play starting point CSV / CSA

Form: System Release Authorization

A plug-and-play release authorization record that turns an approved validation summary report into a documented go-live decision: release criteria met or carried as conditions, residual risk accepted, the effective date, and the quality-unit authorizing signature dated on or before go-live, with a filled specimen and the regulations it satisfies.

Document type: Form

Read and copy the template below into your own quality system. It is a generic starting point for your own internal use, provided as is, with no warranty; see the Terms and License. Adopting it does not by itself create compliance.

This is a ready-to-use release authorization form. It is the artifact that records the go-live decision for a validated system: what was released, on what basis, subject to which conditions, and the quality-unit signature that authorizes GxP use. It references an approved validation summary report rather than repeating it. Replace every <<FILL: ...>> placeholder with your own specifics, set your document numbers and dates, and route it through your normal document control. A worked filled specimen follows the template. Verify each cited regulation against the current source before you rely on it.

Document control header

FieldEntry
Form titleSystem Release Authorization
Record number<<FILL: REL-ID, e.g. REL-2026-018>>
System name and version<<FILL: SYSTEM NAME / version>>
GxP classification / GAMP category<<FILL: e.g. GxP, GAMP Category 4>>
Validation summary report referenced<<FILL: VSR doc number and version>>
Validation plan referenced<<FILL: VP doc number>>
Change control reference<<FILL: CR number>>
System owner<<FILL: role>>
Requested effective (go-live) date<<FILL: date>>

1. Release statement

This form authorizes <<FILL: SYSTEM NAME>> for GxP use, based on the approved validation summary report referenced above, subject to the conditions recorded in section 3. GxP use may begin no earlier than the effective date recorded in section 5, and not before the quality-unit approval date in section 6.

2. Release criteria confirmation

Confirm each criterion. Any “No” must be justified in section 3 as a condition or must stop the release.

#Release criterionMet?Evidence / reference
2.1All planned deliverables produced, executed, reviewed, and approvedYes / No<<FILL>>
2.2100% of requirements traced and verified, or justified exception recordedYes / No<<FILL: RTM reference>>
2.3All critical and major deviations closed; minor deviations closed or carried as justified conditionsYes / No<<FILL: deviation log reference>>
2.4Required SOPs approved and effective (operation, backup/restore, security admin, periodic review, business continuity)Yes / No<<FILL>>
2.5Training completed for users and administratorsYes / No<<FILL>>
2.6Supporting infrastructure qualifiedYes / No<<FILL>>
2.7Data migration verified, if applicableYes / No<<FILL: or N/A>>
2.8Residual risk assessed and formally acceptedYes / No<<FILL: residual-risk acceptance record number>>

3. Conditions of release (open items carried into operation)

List each open item released as a condition. A critical deviation is never eligible to be a condition.

#Condition / open itemClassCompensating controlOwnerDue dateTracking reference
1<<FILL>><<FILL: Major / Minor>><<FILL>><<FILL>><<FILL>><<FILL: CAPA / action number>>

If there are no conditions, state “None; released without conditions.”

4. Residual risk

FieldEntry
Overall residual risk<<FILL: Low / Medium / High>>
Residual-risk acceptance record<<FILL: record number>>
Accepted by (role)<<FILL: e.g. Head of QA for high residual risk>>

5. Effective date

FieldEntry
Effective (go-live) date for GxP use<<FILL: date, on or after QA approval in section 6>>
Any documented interim-use arrangement<<FILL: reference and justification, or "None">>

6. Authorization signatures

The quality-unit signature is the gating approval for GxP release and must be dated on or before the effective date.

RoleAttestsNameSignatureDate
Validation leadThe VSR conclusion is supported by the evidence<<FILL>>
System / process ownerOperational readiness: SOPs, training, infrastructure in place<<FILL>>
Quality Assurance (release authority)Validation met procedural and regulatory requirements; deviation handling and residual-risk acceptance are sound; system is released for GxP use<<FILL>>

7. References

21 CFR 211.22 (quality unit responsibility to approve procedures and specifications affecting product quality). 21 CFR 211.68 (automatic, mechanical, and electronic equipment); 21 CFR Part 11 (electronic records and signatures). EU GMP Annex 11 (computerised systems: fitness for intended purpose; validation documentation and reports). GAMP 5 (Second Edition, ISPE 2022) for the validation report and release concept. Where a combination product brings a device constituent into scope, the applicable device quality-system process-validation and release requirements.

Confirm the current version and clause numbers before issue.


Filled specimen

The following shows the form completed for an example configured LIMS (GAMP Category 4), released with two conditions carried from its VSR.

FieldEntry
Record numberREL-2026-018
System name and versionQC LIMS, v7.2 (configured)
VSR referencedVSR-LIMS-2026-004 v1.0
Requested effective date22 June 2026

Release criteria: 2.1 Yes; 2.2 Yes (142/142 traced); 2.3 Yes (all critical/major closed; two majors carried as conditions per below); 2.4 Yes; 2.5 Yes; 2.6 Yes; 2.7 Yes (migration verified, 1 deviation); 2.8 Yes (RRA-2026-011).

Conditions of release:

#ConditionClassCompensating controlOwnerDue dateTracking
1Post-go-live check that no further deprecated-unit records exist in the active datasetMajor11 affected records individually verified 1:1; mapping rule addedQC Supervisor22 July 2026CAPA-2026-057
23 archived records permanently lack original analyst IDMajorRecords read-only, flagged, excluded from current decisions; data-limitation note travels with themHead of QAClosed at acceptanceRRA-2026-011

Residual risk: Low overall; acceptance record RRA-2026-011; accepted by Head of QA. Effective date: 22 June 2026. Interim use: none.

Signatures: Validation lead (18 June 2026), QC system owner (18 June 2026), Head of QA as release authority (19 June 2026). The QA date, 19 June, precedes the 22 June go-live, which is exactly the ordering an inspector checks.

Common inspection findings this form prevents

  • GxP data created in the gap between go-live and the signed release decision, because no artifact recorded when release was actually authorized.
  • A QA approval dated after the effective go-live date.
  • Open items live in production with no owner, due date, or tracking reference.
  • A critical deviation quietly carried as a “condition” instead of blocking release.
  • A release with no clear single quality-unit authorizing signature.

How to adapt this form

  1. Set your record number and point the header references to your real VSR, validation plan, and change control.
  2. Align the release criteria in section 2 with the criteria your validation plan actually committed to.
  3. Route the form so the QA signature is applied before the effective date is set, and capture both dates.
  4. Feed every condition in section 3 into your action-tracking system so it closes rather than becoming a permanent gap.
  5. Keep the residual-risk detail in a separate acceptance record and reference it here, so the acceptance is owned by name at the right level.
Use madhadi.com as an app Full screen, works offline, one tap from your home screen.