The operational problem
Database lock is usually managed as a date on a plan. In practice it is the moment the analysis stops being able to absorb change. Whatever is still open at that moment, whether an analysis decision, a late data transfer, an unreconciled source or a dry-run finding nobody dispositioned, turns into one of three things: a lock blocker, a risk accepted without a record, or post-lock rework.
Three patterns show up often enough to plan for.
- Decisions arrive after implementation has started. How to handle a missing baseline value, which visit window applies, who is in a population: each is a small statistical decision, and each changes code, quality control (QC) and review.
- Data arrives in a state the programs have never run on. A final external transfer, a new coding dictionary version or a late protocol-deviation classification lands after the last dry run.
- Findings are seen but not owned. The dry run produced a list. Nobody was named to decide which items block lock, so the list is argued about on the last day.
The cost is more than delay. The team ends up making lock-day trade-offs with no evidence in front of it, and afterwards cannot show why a trade-off was reasonable.
Practical methodology
1. Work backwards from lock with four gates
A lock plan with one date invites one decision, made late. Four gates turn it into four earlier, smaller decisions. The offsets below match the database-lock plan in the Navigator; stretch or compress them for your study.
| Gate | Days before lock | The question it answers | What it leaves behind |
|---|---|---|---|
| A. Baseline | about 15 | Which analysis decisions, data sources and standards are still open? | Decision log with owners and latest acceptable dates; source list with final-transfer dates; specification status |
| B. Targeted checks | about 10 | Do the highest-risk derivations, populations and reconciliations hold on current data? | Reconciliation results; derivation checks; QC status of priority outputs |
| C. Meaningful dry run | about 7 | On a representative cut, do the priority outputs run end to end, and are findings dispositioned? | Dry-run log with triaged findings; timed rerun plan |
| D. Final checkpoint | about 1 | Are the execution sequence, owners and escalation path agreed, and is every remaining item dispositioned? | Sign-off record; final-run plan; open-item disposition |
2. Give every open decision a latest acceptable date
A decision does not have a due date; it has a latest acceptable date: the last day it can land and still be implemented, independently checked and reviewed before lock. Calculate it backwards in working days:
latest acceptable date = lock date
- (implementation + independent QC + review + buffer)The buffer is the time you want to keep for one rerun, which is the idea behind protecting a plan with buffers rather than padding every task.[1] A decision that has passed its latest acceptable date is by definition a risk. There are only three honest responses: decide now, accept the risk in writing with a named owner, or move the date. "We are waiting on clarification" is not one of them.
3. Say what the dry run must prove, then size it
A dry run that shows the code runs proves little. Write a one-paragraph purpose before you plan it:
- Representative cut. The latest data cut that contains every source in its final structure, even if some sources are not final in content.
- Priority outputs. Primary and key secondary endpoints, safety summaries, and anything that feeds the clinical study report in-text tables.
- What counts as a pass. Priority outputs run end to end; independent QC agrees on them; cross-source reconciliations hold; and the rerun path has been timed.
Population and handling decisions that depend on how intercurrent events are treated belong in the decision log at Gate A, not in the dry run.[2]
4. Triage findings into four classes, with a named decider
| Class | Definition | Typical example | Action |
|---|---|---|---|
| Lock blocker | Could change a primary or key result, or cannot be fixed after lock | Population flag derived from a rule that has changed | Fix and re-verify before lock |
| Fix before lock | Does not change conclusions but is cheaper to fix now | Label or ordering errors in a key table | Fix; verify by targeted rerun |
| Accept with rationale | A known limitation with a documented, bounded impact | A listing that truncates a long free-text field | Written rationale, approved by the named decider |
| Post-lock | Cosmetic or documentation items that do not touch locked data or results | Footnote wording | Backlog item with an owner |
The person who decides a finding's class is named in advance (typically the study statistician with the programming lead), and it is not the person who found it.
5. Reconcile external data against a cutoff, not a hope
For each external source (central laboratory, pharmacokinetics, ECG, ePRO, randomization system, imaging) record the final-transfer cutoff, the reconciliation check against the clinical database (subject and visit counts, key identifiers), and an owner. Decide in advance what happens to data that arrives after the cutoff: it is excluded and documented, or lock moves. Both are legitimate. Deciding on the day is not.
6. Close with evidence that was built as you went
Define the closure set early: decision log, dry-run log with dispositions, final-run log, QC evidence and approvals. Assembling it afterwards from memory takes longer than keeping it current, and it is weaker evidence.
7. Escalate on triggers set in advance
Write the triggers into the plan. Examples: a decision reaches its latest acceptable date still open; a priority output has no independent QC started at Gate C; an external source is unreconciled at Gate C; the number of lock blockers has not fallen between two checkpoints. A trigger fires an escalation with options and a recommendation, covered in the chapter on dependency, risk and escalation management.
A realistic example
A fictional study, ZEPHYR-101 (a made-up Phase 3 trial; all names, dates and numbers are synthetic), has a planned lock on Friday 30 October. The team sets Gate A on Thursday 15 October, Gate B on Tuesday 20 October, Gate C on Friday 23 October and Gate D on Thursday 29 October.
Gate A: the decision log. Six decisions are open. Working days are counted back from the lock date.
| ID | Decision | Owner | Impl. + QC + review + buffer (working days) | Total | Latest acceptable date |
|---|---|---|---|---|---|
| D-01 | Handling of a missing baseline weight in the primary endpoint derivation | Study statistician | 3 + 2 + 1 + 1 | 7 | Wed 21 Oct |
| D-02 | Visit window for the Week 12 assessment | Study statistician | 2 + 1 + 1 + 1 | 5 | Fri 23 Oct |
| D-03 | Population flag for participants with a major protocol deviation | Statistician with clinical lead | 4 + 2 + 1 + 1 | 8 | Tue 20 Oct |
| D-04 | Coding dictionary version for adverse events | Data management | 2 + 1 + 1 + 1 | 5 | Fri 23 Oct |
| D-05 | Censoring rule for a key time-to-event secondary endpoint | Study statistician | 3 + 2 + 1 + 1 | 7 | Wed 21 Oct |
| D-06 | Layout of the concomitant medication listing | Programming lead | 1 + 1 + 1 + 0 | 3 | Tue 27 Oct |
The log already tells the team something no timeline did: D-03 has the longest chain and the earliest deadline. It is the one to chase first.
Gate B: the first trigger. On Tuesday 20 October D-03 is still open, and today is its latest acceptable date. The trigger fires. The programming lead sends the study statistician and clinical lead a short brief with three options:
- Decide today and keep the lock date.
- Keep the current population rule for lock, document the alternative as a pre-specified sensitivity analysis to run afterwards, and record the decision.
- Decide on Friday 23 October and move lock to Wednesday 4 November, because the eight-working-day chain would then end three working days late.
The team picks option 2. Because it was decided at the latest acceptable date, nobody had to compress independent QC to make it work.
Gate C: the dry run and a late transfer. The Gate C dry run on Friday 23 October ran on laboratory transfer 2. Final transfer 3 was due on Wednesday 21 October but arrives on Tuesday 27 October. The safety laboratory outputs from the dry run therefore do not reflect final data. The team classifies this as a lock blocker for those outputs, schedules a two-day rerun and reconciliation, and fits it before the planned final run on Thursday 29 October.
The dry run produced 14 findings. Triage gave 2 lock blockers, 5 fix-before-lock, 3 accepted with rationale and 4 post-lock.
| ID | Finding | Class | Decider | Action |
|---|---|---|---|---|
| F-03 | Week 12 responder count differs from the independent QC program | Lock blocker | Study statistician | Resolve; rerun both programs; record |
| F-07 | Subjects in the laboratory transfer missing from the clinical database | Lock blocker | Data management | Query; reconcile on transfer 3 |
| F-09 | Table footnote refers to the wrong population | Fix before lock | Programming lead | Fix; targeted rerun |
| F-12 | Listing column wraps in the PDF output | Post-lock | Programming lead | Backlog item |
Gate D: the final checkpoint. On Thursday 29 October both blockers are closed with rerun evidence, the three accepted findings have signed rationale, and the final-run plan names the order of execution and who runs it. The team can state exactly what it is relying on: the decision log, the dry-run log with dispositions, QC evidence for priority outputs and the sign-off record.
Common failure modes
| Failure mode | How it shows up | Countermeasure |
|---|---|---|
| Lock treated as a date, not a chain | Everyone "has until lock" for their part | Latest acceptable dates per decision (method 2) |
| Dry run on a stale or unrepresentative cut | Run passes; final data breaks it | Purpose statement and representative cut (method 3) |
| "Zero open items" as the goal | Items are closed, hidden or renamed to hit the number | Measure "dispositioned", not "zero" (method 4) |
| Findings with no decider | Last-day argument about what blocks | Name the class decider before the dry run |
| Specification changes after Gate B without regression scope | A "small" change reopens verified outputs | Define regression scope for every late change before accepting it |
| External cutoff not enforced | Final transfer arrives after the dry run | Cutoff per source, with the exclusion-or-move rule decided up front |
| Independent QC squeezed to the end | QC starts after programming finishes; same person programs and checks | Schedule QC by output priority and protect independence |
| Evidence assembled after lock | Gaps found with nobody left who remembers | Keep the closure set current from Gate A |
| One person holds a derivation | Absence stops the milestone | Name a second person for each priority derivation |
| Escalation by hallway | Problems raised informally, late and without options | Triggers written into the plan (method 7) |
Recommended actions
- This week: list every open analysis decision for your next lock and give each an owner and a latest acceptable date. Sort by the earliest date.
- At Gate A: list every data source with its final-transfer cutoff and decide the rule for late arrivals.
- Before the dry run: write its purpose in one paragraph and name the priority outputs and the finding-class deciders.
- At Gate B: check every decision against its latest acceptable date; escalate any that are at or past it, with options.
- At Gate C: triage every finding into a class with a named decider; time the rerun path.
- At Gate D: confirm the closure set exists, the execution sequence is written down, and each accepted item has a signed rationale.
- After lock: review which decisions arrived after their latest acceptable date and why, and adjust the lead times you use next time.
- Make it repeatable: build the Navigator's database-lock plan for your dates and keep the log in Workspace so the plan and the evidence stay together.
Standards and agency expectations for the data you are locking are set elsewhere, for example by the standards guides and technical specifications that govern your submission.[3, 4, 5] Good clinical practice also expects quality to be designed in and proportionate to risk, which is the spirit of gating the effort where it can change a result.[6]
Template
Lock decision and open-item log
A log that gives every open decision a latest acceptable date, a triage class and a closure record. Example rows come from the synthetic study in this chapter; the blank rows calculate the date for you.
| ID | Item | Owner | Latest acceptable date | Status at gate |
|---|---|---|---|---|
| D-01 | Handling of a missing baseline weight in the primary endpoint derivation | Study statistician | 2026-10-21 | Open at Gate B |
| D-02 | Visit window for the Week 12 assessment | Study statistician | 2026-10-23 | Open at Gate B |
| D-03 | Population flag for participants with a major protocol deviation | Statistician with clinical lead | 2026-10-20 | Open at Gate B |
| D-04 | Coding dictionary version for adverse events | Data management | 2026-10-23 | Open at Gate B |
| D-05 | Censoring rule for a key time-to-event secondary endpoint | Study statistician | 2026-10-21 | Open at Gate B |
| D-06 | Layout of the concomitant medication listing | Programming lead | 2026-10-27 | Open at Gate B |
Preview of the first 5 of 16 columns and 6 synthetic example rows. The download has all 16 columns, blank rows with formulas, and no study data.
Apply it
Apply it in the Navigator
The Handbook explains why and how to decide. The Navigator turns the same logic into dated, owned actions for your milestone, in your browser, with no study data.
- Build a database-lock readiness planDated actions, owners and handoffs for your lock
- Test a lock moved forwardCheck whether a shorter window still fits and what staffing cannot fix
Supporting references
References
- Goldratt EM. Critical Chain. North River Press; 1997.
- ICH. E9(R1) Addendum on estimands and sensitivity analysis in clinical trials to the guideline on statistical principles for clinical trials. Step 4, 2019. database.ich.org ↗
- CDISC. Analysis Data Model Implementation Guide (ADaMIG) version 1.3. www.cdisc.org ↗
- CDISC. Study Data Tabulation Model Implementation Guide (SDTMIG) version 3.4. www.cdisc.org ↗
- U.S. Food and Drug Administration. Study Data Technical Conformance Guide: Technical Specifications Document. www.fda.gov ↗
- ICH. E6(R3) Guideline for Good Clinical Practice. International Council for Harmonisation; 2025. www.ich.org ↗
Links go to the publisher's page. Standards and guidance change: confirm the version in force for your study, sponsor and region before relying on any reference. The worked examples are synthetic and illustrative; they are not benchmarks.
Review status
This chapter has not yet been independently reviewed
It is an author draft written from statistical programming leadership practice. No practitioner has reviewed it yet, and nothing here should be read as validated or endorsed by anyone else. If you work in this area, a 45-minute review using a synthetic scenario is the most useful thing you can do for it.
Suggested citation: Shiva Kumar. 2026. “Dry Run and Database Lock Readiness”, in Clinical Statistical Programming Operations: A Practical Leadership Handbook, working edition 0.1. Clinical Data Readiness Navigator. Accessed [date].