The sign-off form usually arrives late on a Thursday. It has a study number, a line saying the data are complete and accurate, and a space for your signature.

Most sponsors sign it. Few ask what, exactly, they’re attesting to.

That signature is the last point where a correction costs you a query instead of a documented unlock, an impact assessment and an awkward paragraph in the clinical study report. Whether your CRO runs a soft lock first, and what actually happens during it, decides how much you know when you sign. This guide explains soft lock vs hard lock, where each fits in the database lock process in clinical trials, and the questions sponsors should ask before signing off.

Soft Lock vs Hard Lock: What Each Term Means

Neither FDA nor ICH defines “soft lock” or “hard lock.” The terms come from industry practice, and each organization sets its own definitions in its SOPs and data management plan. Ask your CRO for its written definitions well before closeout.

In most usage, a soft database lock and a hard database lock look like this:

One related term causes real confusion. “Database freeze” can mean a subject-level or form-level freeze during the study, or it can just be another word for soft lock. If “freeze” shows up in your timeline, confirm which one your CRO means.

The practical difference is simple. At soft lock, changing a value is inconvenient. At hard lock, changing a value is an event you’ll have to explain.

Where Soft Lock Sits in the Clinical Trial Database Lock Process

The clinical trial database lock process is a sequence of steps, and soft lock only makes sense in context.

The blind review step has a regulatory anchor. ICH E9 describes blind review as checking the data between trial completion and breaking the blind. It also says the statistical analysis plan should be finalized before the blind is broken, with formal records of when the SAP was finalized and when the blind was broken.

Soft lock is where that review usually happens. Decisions on per-protocol membership, major deviations and borderline data points are far easier to defend when they’re made on blinded data. Involving your clinical biostatistics team at this stage, not after hard lock, is what keeps those decisions clean.

A soft lock adds days to the timeline. On some studies, those days are well spent. It usually earns its place when:

• The trial is blinded and analysis populations depend on judgment calls made during blind review.
• Statistical programmers need a stable, near-final dataset to dry-run tables, listings and figures before the real run. This is where your statistical programming team finds problems that listings alone miss.
• The study is large, multi-vendor or global, and reconciliation findings are still arriving late.
• A regulatory or board deadline makes a post-lock unlock especially expensive.

It adds less on a small, open-label Phase I study with one data source and a short query list. There, going straight to hard lock after a clean pre-lock review can be entirely reasonable.

The risky version is a soft lock that exists only on the timeline. If there are no dry runs or blind review happening against it, you’ve added a date without adding a check.

Whatever the sequence, database lock readiness comes down to evidence. A good database lock checklist lists each item, who owns it, and which document proves it’s done.

Readiness item	Evidence you should be able to see
All expected data entered	Missing-page and missing-visit report showing zero or documented exceptions
Queries closed	Query status report; any open item with a documented rationale
Source data verification complete per monitoring plan	Monitoring status summary
Investigator signatures on eCRFs	Signature status report by site
SAE reconciliation complete	Signed reconciliation listing
External data reconciled	Reconciliation reports for each vendor transfer
Medical coding final	Coding listings reviewed by the medical monitor, dictionary versions recorded
Protocol deviations classified	Deviation log with major/minor classification agreed
Analysis populations agreed (blinded trials)	Blind review minutes
SAP final	Signed, dated SAP
Access controls ready	Plan to remove edit rights at lock, with date

An item without evidence is an assumption.

Most of these items depend on clean upstream work. If query handling or database setup is where things usually slip, it’s worth reading how EDC data management services handle validation and queries from setup to lock.

A pre-lock meeting in clinical trials often runs as a status call. It works better as direct questions answered with documents. These are the ones sponsors should be asking.

About the data

• What is still open, and why is it acceptable to lock with it open?
• Were any queries closed as “data confirmed as is” in the last two weeks? How many, and who reviewed them?
• Have all external data transfers been reconciled against the final EDC data, including the most recent transfer?
• Which dictionary versions were used for coding, and do they match what the SAP and the safety database use?

About the process

• What exactly changes technically at soft lock and at hard lock in this EDC? Which roles lose edit rights, and when?
• Were dry-run outputs produced from soft lock data? What did they flag?
• Is the SAP signed, and is its date earlier than the planned unblinding?

About what happens after

• What is the written unlock procedure, and who must approve an unlock?
• How will a post-lock finding be assessed for impact before anyone decides to reopen the database?

Two more are worth asking even when everything looks clean: “What are you least confident about?” and “What would you check if this were your submission?”

Database lock sign-off is a shared attestation. Each signatory confirms a different part of the picture.

Signatory	What their signature should mean
Lead data manager	Data are complete, queries resolved, reconciliations done, lock procedure followed
Biostatistician	Data are fit for the planned analysis; SAP final; blind review decisions documented
Medical monitor	Coding, safety data and medical review are complete
Clinical operations lead	Monitoring and site closeout activities support the data
Sponsor representative	Sponsor accepts the data as the basis for analysis

The exact list lives in your data management plan and varies by sponsor. What shouldn’t vary is this: each signatory has seen the evidence for their row.

A clinical data lock CRO team should be able to hand you that evidence as a package before the meeting, so the meeting confirms things instead of discovering them. At Weltrix, that pre-lock package is part of how we run closeout within our clinical data management services.

Errors do surface after lock. The first step is an impact assessment. Data management, biostatistics and the medical monitor judge whether the error could affect a primary or key secondary endpoint, a safety conclusion or an analysis population. Many sponsors’ SOPs allow minor, non-impactful errors to be documented and disclosed in the clinical study report rather than corrected in the database.

When the error does matter, the database is formally unlocked. That typically means:

• A written request stating the error, its source and its expected impact
• Approval from the named signatories, including the sponsor
• The correction, captured in the system’s audit trail
• A re-lock, with the same sign-off discipline as the first

The audit trail isn’t optional. 21 CFR 11.10(e) requires secure, computer-generated, time-stamped audit trails for electronic records, and record changes must not obscure previously recorded information. An unlock shows up in that trail permanently.

Timing matters most in blinded trials. An unlock after unblinding means data were changed by people who could know treatment assignments, so documenting who knew what, and when, becomes far more important. That’s the strongest argument for a real soft lock.

Define soft lock, hard lock and freeze in writing, in the data management plan, before first patient in.

Treat the database lock checklist as an evidence list, not a to-do list.

Run dry-run outputs on soft lock data. They find what listings miss.

Finalize and date the SAP before unblinding, as ICH E9 expects.

Write the unlock procedure before you need it.

ICH E6(R3), published by FDA as final guidance in September 2025, puts data governance and traceability at the center of good clinical practice. A lock you can reconstruct step by step, from the checklist to the signatures to the audit trail, is what that looks like in practice.

Q. What’s the difference between a soft lock and a hard lock?

A soft lock closes site data entry but still allows controlled, documented corrections while the data get a final review. A hard lock, or final database lock, freezes the dataset of record for analysis. After it, changes need a formal unlock approved by named signatories, including the sponsor. The exact definitions come from each organization’s SOPs, since neither FDA nor ICH defines the terms.

Q. What is a soft database lock?

A soft database lock is a stage where site data entry is closed and the data are reviewed as a near-final set, but changes are still possible through a controlled, documented process. It’s typically used for blind data review and dry-run outputs.

Q. What is a hard database lock?

A hard database lock freezes the dataset of record. No one can edit the data unless a formal unlock is approved. In blinded trials, unblinding follows hard lock.

Q. When would a sponsor use a soft lock instead of going straight to hard lock?

Use a soft lock when the trial is blinded, when analysis populations depend on blind review decisions, or when programmers need to dry-run outputs on near-final data. Large, multi-vendor studies benefit most. A small open-label study with a single data source can often go directly to hard lock after a clean pre-lock review.

Q. What should be completed before any database lock, soft or hard?

All expected data entered, queries resolved or documented, source data verification complete per the monitoring plan, investigator eCRF signatures collected, SAE and external data reconciliation finished, medical coding finalized, and protocol deviations classified. Before hard lock in a blinded trial, the SAP should be final and blind review decisions documented.

Q. Who needs to approve a database lock?

Typically the lead data manager, the biostatistician, the medical monitor and a sponsor representative, with clinical operations often included. The required signatories are set in the data management plan and SOPs.

Q. What are a sponsor’s responsibilities before database lock?

The sponsor stays accountable for the data even when a CRO runs the process. In practice, that means agreeing the lock definitions and unlock procedure in writing, asking for evidence for each readiness item, attending the pre-lock meeting with real questions, and signing only what they’ve seen documented.

Q. What happens if an error is found after hard lock?

The team first assesses its impact on endpoints, safety conclusions and analysis populations. Minor, non-impactful errors are often documented in the clinical study report without reopening the database. Significant errors need a formal, approved unlock, a correction captured in the audit trail as 21 CFR Part 11 requires, and a documented re-lock.

Conclusion

A database lock is only as solid as the questions asked before it. The soft lock vs hard lock choice matters less than whether the time between them gets used: blind review done, outputs dry-run, evidence in hand. Before you sign, ask to see the unlock procedure. If nobody can produce it, you’ve found your first open item.

“Soft lock” and “hard lock” are industry terms without regulatory definitions. Get your CRO’s written definitions early.

Soft lock closes site entry but allows controlled corrections. Hard lock freezes the dataset of record.

ICH E9 expects the SAP to be finalized before the blind is broken, with records of both dates.

Database lock readiness should be proven with evidence for every checklist item.

Each sign-off role attests to something different, and each signatory should see the evidence for it.

Post-lock errors start with an impact assessment. Formal unlocks are recorded permanently in the Part 11 audit trail.

A soft lock is worth its time only if blind review and dry-run outputs actually happen during it.