A statistical analysis plan (SAP) turns the protocol's one-page statistics section into instructions someone else could follow without asking you. This guide walks through what goes in, in what order, how to handle estimands, populations and missing data, and the point at which the plan must be locked.
Free sandbox · No credit card · 21 CFR Part 11 aligned
Objectives, endpoints and estimands
Copied from the protocol, then made precise
Design, randomization and blinding
Analysis populations
Full analysis set, per-protocol, safety
Primary analysis and multiplicity
Model, covariates, alpha
Missing data and sensitivity analyses
Secondary, subgroup and safety analyses
Tables, listings and figures shells
Writing a SAP in one page
The basics
A statistical analysis plan is a document that states, before the data are examined by treatment group, exactly how the trial data will be analysed. The protocol already has a statistics section, but it usually runs a page or two: the primary endpoint, the sample size and the main test. That is enough for an ethics committee. It is not enough to analyse the study, because a dozen decisions are left open, such as which participants are analysed, how a missed visit is treated, which covariates are in the model and how many secondary endpoints are tested formally.
Leaving those decisions open is the real risk. Once analysts see results by arm, every choice can be made, consciously or not, in the direction that looks best. A SAP removes that freedom. Readers of the final report, reviewers and regulators can then compare what was planned with what was done, and any difference is visible as a documented change rather than an unexplained shift.
The statistical principles that most sponsors cite for this are in ICH E9, with an addendum, E9(R1), on estimands and sensitivity analysis. Regulators in several regions use them. Your sponsor, regulator or funder may also expect a particular template, so check the requirements that apply to you before you start. For the sample size piece that feeds the plan, see the sample size calculator for clinical trials and the power analysis calculator.
Step by step
You do not need to write in the order the final document is read. This sequence puts the decisions that constrain the others first.
Copy the primary and key secondary objectives from the protocol, then add the missing detail: the variable, the time point, the unit, who measures it and how a derived value is computed. If you are using a score, say how the total is built from items and what a missing item does to it.
An estimand describes the treatment effect the trial wants to estimate: the population, the variable, how intercurrent events (stopping the drug, rescue medication, death) are handled, and the summary measure. ICH E9(R1) introduced this framework. Writing it down first tells you whether your analysis answers the clinical question or something slightly different.
State the arms, allocation ratio, stratification factors and who is blinded at which stage. The SAP must say who has access to treatment labels and when, because that governs when the plan can still be changed. See how to randomize participants for the design choices that feed this section.
Typical sets are the full analysis set (randomized participants analysed as allocated, with defined exclusions), a per-protocol set and a safety set (participants who received any treatment, analysed as treated). Write the exact rules for membership, and decide which population is primary for which endpoint, before the data exist.
Name the model, the outcome distribution, the covariates (including stratification factors), the test or interval and the alpha level. State how you will check assumptions and what you will do if they fail. If several endpoints or comparisons carry formal claims, set out the multiplicity strategy: hierarchy, gatekeeping or an adjustment method.
Say what counts as missing, how you will describe it, and the primary handling method. Then list sensitivity analyses that stress the main assumption, for example a different imputation approach or an analysis that treats dropouts as failures. Pre-specifying these is more credible than adding them after seeing a surprising result.
State which are confirmatory and which are descriptive. Name subgroups and the variable that defines each, since post-hoc subgroups are easy to find and hard to believe. For safety, say how adverse events will be summarised (by arm, by severity, serious events separately) and which listings are produced.
Draft mock tables, listings and figures. Define dataset conventions such as visit windows, baseline definition and how repeated rows are handled. Agree the export format with the data manager so that the analysis datasets can be built without rework.
Have a second statistician or a named reviewer read it, and have the clinical lead check that it matches the protocol. Give it a version, a date and an approval record. Then lock it before unblinding, and log every later amendment with the reason and the date.
What goes where
A reference outline. Reorder it to follow your sponsor's template, and shorten it for a pilot.
| Section | Decides | Common gap |
|---|---|---|
| Objectives and estimands | The question and how intercurrent events count | Estimand never stated, so the analysis answers a different question |
| Design and randomization | Arms, ratio, strata, blinding, who sees labels | Strata in the protocol but not in the model |
| Analysis populations | Who is in each set and why | Per-protocol rules written after the deviations are known |
| Endpoint definitions | Derivations, windows, baseline | Unit or time window left to the analyst |
| Primary analysis | Model, covariates, test, alpha | No plan if assumptions fail |
| Multiplicity | Order of testing or adjustment | Several key secondaries tested at the full alpha |
| Missing data | Handling, sensitivity analyses | Only one method, with no stress test |
| Interim analyses | Who looks, what rule, who acts | Interim looks that quietly cost alpha |
| Safety analyses | Summaries, listings, severity grouping | Serious events buried in the all-events table |
| Tables, listings, figures | Shells for every output | Written after the data are in |
Build your eCRFs in the free sandbox, enter sample data and open the export before you finalize the SAP shells. No credit card, no time limit.
Timing and change control
The most defensible moment to finalize a SAP is before the database is locked and before treatment labels are available to anyone doing the analysis. For a double-blind trial that usually means before the blind is broken for the primary analysis. Open-label trials are harder to defend, because the team may have seen emerging results, so the plan should be signed earlier and the dates recorded. The database lock step is a natural checkpoint: the lock checklist can include the signed SAP version.
Changes happen. A blinded data review may show that the outcome distribution is skewed, or the protocol may be amended. The usual practice is to separate changes made before unblinding, which need a new SAP version and a recorded reason, from changes made after unblinding, which should be labelled as post-hoc and reported as such. Some protocols state that changes to the primary hypothesis or its statistical methods before unblinding require a protocol amendment. Check what your protocol and regulator say.
A good change log lists the version, the date, the section changed, the reason and who approved it. It also notes whether the change was made while still blinded. That one extra column is what separates a plan with a clear history from a plan that has to be explained.
What the data system should give the statistician
The plan assumes the data arrive in a form the analysis can use. Most late SAP rework comes from the data side: a free-text field where a coded one was needed, a unit that varies by site, a visit date that nobody can tie to a window. In Capture you build the study yourself, so the person writing the SAP can look at the same forms as the data manager.
Stage 1
DraftBuild and edit freely
Stage 2
ApprovedLocked for live use
Stage 3
In the casebookOnly approved forms
SDV requirement changed on Systolic BP
Data manager · Reason: critical safety value
Form approved: Vital Signs (VS) v2
Study owner · Locked for live use
Answer changed: Weight 68.0 to 68.5 kg
Site coordinator · Reason: transcription error
Where plans fail
Copying the protocol. A SAP that repeats the protocol's statistics paragraph adds nothing. The test is whether someone else could program the analysis from it.
Skipping the estimand. Without it, handling of treatment discontinuation and rescue therapy gets decided case by case. Decide it once, in writing, and let the model follow.
Defining populations after the deviations are known. If per-protocol rules are written while looking at protocol deviation reports, the rules can end up fitted to the data. The protocol deviation severity classifier can help you agree categories up front.
Forgetting multiplicity. If several endpoints will support claims, say how alpha is shared. If none will, say so, and label the secondary analyses as descriptive.
No plan for missing data. The most common outcome is complete-case analysis by default, which can bias results in ways the team did not intend. State the primary method and at least one sensitivity analysis.
Never producing the shells. Mock outputs force the questions that the text lets you skip. Draft them early, ideally alongside the CONSORT flow diagram layout, so the participant flow table already has agreed definitions.
Before you sign it
Check variable, time point, unit, who measures it and the derivation.
Population, variable, intercurrent events and summary measure.
Another analyst could assign each participant to each set.
Covariates, strata, distribution, test, alpha and what happens if assumptions fail.
Confirmatory and descriptive endpoints are labelled.
Methods named, with the assumption each one stresses.
Tables, listings and figures map to a dataset variable that exists in the eCRF.
Signed before treatment labels are seen by the analysis team.
A statistical analysis plan (SAP) is a document that sets out, in enough detail for another statistician to reproduce the work, how a trial's data will be analysed: endpoints, estimands, populations, models, missing data, multiplicity and the tables, listings and figures to be produced. It is written before the analysis team sees results by treatment group.
Guidance such as the UK Clinical Trials Toolkit says a SAP should be finalised before unblinding. In practice that means signed and version-controlled before the blind is broken for the primary analysis, and ideally before database lock. Check the requirements of your sponsor and regulator.
The protocol's statistics section is a short summary used for ethical and regulatory review. The SAP is the detailed technical specification. If the two disagree, the protocol governs until it is amended, so keep them aligned.
An estimand is a precise description of the treatment effect a trial aims to estimate. ICH E9(R1) frames it in terms of the population, the variable, how intercurrent events such as stopping treatment are handled, and the summary measure. The analysis method should then be chosen to estimate it.
A short one is still worthwhile. It can be a few pages that name the primary analysis, the populations, how missing data are handled and what will be reported. The aim is the same: decide before seeing the results.
Yes, but every change should be versioned with a date and a reason, and it should record whether the change was made while the team was still blinded. Changes after unblinding should be reported as post-hoc. Some protocols require a protocol amendment for changes to the primary hypothesis or method.
Usually a trial statistician, reviewed by the clinical lead and the data manager. Smaller teams may use a consulting statistician. The author should have no access to treatment labels until the plan is signed.
No. Capture is the platform where the data are collected, queried, audited and exported, including SDTM datasets as SAS XPT with Define-XML. The statistical plan itself is written by your statistician. A cleaner dataset makes the plan easier to follow.
Keep exploring
Sample size calculator
Size the trial before you plan the analysis.
Power analysis calculator
Check the power of the planned comparison.
EDC for biostatisticians
Exports and datasets built for analysis.
CDISC SDTM export software
Analysis-ready standard datasets.
Database lock
The checkpoint that follows the SAP.
Protocol synopsis generator
Get the protocol summary right first.
CONSORT flow diagram generator
Participant flow for the final report.
How to randomize participants
The design choices that feed the SAP.
Free sandbox with every feature. No credit card, and you pay only when you go live with real participants.