A statistical analysis plan (SAP) is where a clinical trial’s methodology stops being a design intention and becomes an executable, auditable specification. Because ICH E9 requires the full technical detail of the planned analysis to be documented before anyone can see data that might reveal treatment effects, sponsors, CROs, and academic trial units almost universally work from a standing SAP template rather than drafting the document’s structure from scratch each time. This guide sets out that standard structure section by section, then walks through the part most teams find hardest to operationalize: where the ICH E9(R1) estimand framework’s five attributes actually land inside the document.
Standard SAP table of contents
Neither ICH E9 nor its E9(R1) addendum publishes a fixed template format — unlike ICH M11, which does provide an actual protocol template, ICH’s statistical guidance specifies required content and pre-specification timing, not a mandated document layout. In practice, sponsors, CROs, and academic trial units converge on close variants of the same section order, because each section answers a specific regulatory or scientific-review question. The table below is that convergent structure.
| Section | What it specifies |
|---|---|
| 1. Document control / version history | Version number, date, author and approver sign-off, and a change log against the protocol and any prior SAP versions — the record that proves the SAP was finalized before database lock and unblinding. |
| 2. Introduction and study objectives | Restates the protocol’s primary and secondary objectives and links each to the endpoint(s) that will be analyzed to address it. |
| 3. Study design summary | A brief restatement of design, treatment arms, randomization ratio, and blinding — enough context for a statistician reading the SAP alone to understand what is being analyzed. |
| 4. Endpoints and estimands | Formal definitions of primary, secondary, and exploratory endpoints, each paired with its estimand: population, treatment conditions compared, the variable itself, the intercurrent-event strategy, and the population-level summary measure. |
| 5. Analysis populations | Definitions of each analysis set — typically the full analysis set (FAS)/intent-to-treat population and a per-protocol population — and which population is primary for which endpoint. See Intent-to-Treat vs. Per-Protocol Analysis. |
| 6. General statistical considerations | Significance level(s), whether tests are one- or two-sided, confidence-interval conventions, the statistical software and version to be used, and how baseline characteristics will be summarized. |
| 7. Statistical methods by endpoint | The exact model or test for each primary, secondary, and exploratory endpoint, matched to the endpoint’s estimand and data type — e.g. a mixed model for repeated measures for a continuous endpoint, logistic regression for binary, a Cox model or log-rank test for time-to-event. |
| 8. Missing-data handling | The pre-specified primary approach (e.g. multiple imputation under a stated assumption) and any sensitivity analyses run under alternative, less favorable assumptions. |
| 9. Multiplicity control | How the overall Type I error rate is protected across multiple endpoints, comparisons, or interim looks — e.g. a hierarchical testing procedure or alpha-spending function. |
| 10. Subgroup and sensitivity analyses | Which subgroups are pre-specified (confirmatory-adjacent) versus exploratory, and which robustness checks will be run against the primary analysis. |
| 11. Safety analyses | Adverse-event summarization conventions, the safety population (often distinct from the efficacy population), and any laboratory or vital-sign analysis conventions. |
| 12. Interim analyses, if applicable | Timing, statistical stopping boundaries, and who reviews unblinded interim results — typically a Data Safety Monitoring Board (DSMB) — plus the conditions for stopping early. |
| 13. Mock table, listing, and figure (TLF) shells | Blank output templates showing exactly how each analysis will be displayed, demonstrating the analysis was planned in structure, not just described in prose. |
| 14. References and appendices | Cited methodology papers, and supporting detail such as full imputation-model specifications or derivation rules for composite variables. |
SAP vs. protocol: is the SAP part of the clinical trial or a separate document?
The SAP is a separate document from the clinical trial protocol, though it must be fully consistent with it. The protocol establishes the trial’s design, eligibility, interventions, and endpoints, and usually includes only a summary statistical section; the SAP is the granular technical specification that a biostatistician actually programs against. Because it is downstream of the protocol, a SAP that introduces a primary endpoint not named in the protocol, or that changes the primary analysis population, is a protocol-inconsistency finding that regulatory reviewers and journal editors are trained to catch — particularly by comparing both documents against the trial’s prospective registration on ClinicalTrials.gov, which captures the primary and secondary outcome measures before the trial completes. For the upstream design decisions the SAP builds on — endpoint selection, sample-size and power calculation, and randomization scheme — see Designing a Clinical Trial: Endpoints, Sample Size, Randomization, SAP. For the full definitional treatment of the SAP itself, see the Statistical Analysis Plan (SAP) dictionary entry.
Where ICH E9(R1) estimands fit inside the SAP
The estimand framework, introduced through the ICH E9(R1) addendum (final version adopted 20 November 2019) to ICH E9, requires that each endpoint’s estimand be fully defined by five attributes agreed together as a set: the target population, the treatments being compared, the variable (endpoint) itself, the strategy for handling intercurrent events such as treatment discontinuation or rescue medication, and the population-level summary measure used to express the treatment effect. Inside a SAP, these five attributes belong in the endpoints-and-estimands section (Section 4 in the table above), stated separately for the primary endpoint and for each secondary endpoint that will support a confirmatory claim — because changing the intercurrent-event strategy alone changes what the resulting effect estimate means, even when the same raw data and the same statistical model produce it. The statistical-methods section (Section 7) is then written to match: the chosen model or test is selected because it estimates the stated estimand, not chosen first and interpreted afterward.
Illustrative example (not a real trial)
The following is a labeled, illustrative composite showing how a primary-endpoint estimand might be stated inside a SAP for a hypothetical superiority trial of an oral therapy versus placebo. It is not drawn from, or attributed to, any real trial, sponsor, or publication.
| Attribute | Illustrative statement |
|---|---|
| Population | Adults meeting the protocol’s randomization criteria at baseline, regardless of subsequent treatment discontinuation. |
| Treatment | Randomized study drug versus placebo, both with permitted background therapy per protocol. |
| Variable | Change from baseline to Week 24 on the pre-specified primary efficacy scale. |
| Intercurrent-event strategy | Treatment policy for treatment discontinuation and use of rescue medication — the Week 24 value is analyzed as observed regardless of whether either event occurred. |
| Population-level summary | Difference in mean change from baseline between arms, with a two-sided 95% confidence interval. |
See Estimand Framework for the full comparison of all five ICH E9(R1) intercurrent-event strategies (treatment policy, hypothetical, composite variable, while-on-treatment, and principal stratum) and the assumption burden each carries.
Analysis populations, missing data, and multiplicity
Three sections of the SAP do most of the work of keeping the trial’s confirmatory claims defensible. The analysis-population definitions determine which participants’ data feed into which analysis — ICH E9 recommends the full analysis set as the primary population for superiority trials, with a per-protocol population run as a supportive sensitivity analysis; see Intention-to-Treat Analysis Explained for a full walkthrough of that distinction and why it matters for the direction of bias. The missing-data section commits, in advance, to how dropouts and incomplete assessments are handled — typically a primary imputation approach plus sensitivity analyses run under less favorable missingness assumptions — so that the choice cannot be made after seeing which approach is more favorable to the result. The multiplicity section protects the trial’s overall Type I error rate whenever more than one endpoint, comparison, or interim look is being tested, commonly through a pre-specified hierarchical (gatekeeping) testing sequence or an alpha-spending function.
Interim analyses and the DSMB
Where a trial includes planned interim looks, the SAP is the document that pre-specifies their timing, the statistical stopping boundaries, and the decision rules for stopping early on efficacy, futility, or safety grounds. Because reviewing unblinded interim comparative data creates the same pre-specification integrity concern as the final analysis, this review is typically delegated to an independent Data Safety Monitoring Board (DSMB) rather than the trial team itself, and the SAP’s interim-analysis section is what the DSMB’s charter and statistical analysis center work from.
Timing, version control, and sign-off
A SAP’s methodological value depends on when it is finalized relative to two events: database lock (the point after which the trial dataset is frozen) and unblinding (when treatment-arm assignment becomes visible to those analyzing the data). ICH E9 establishes the general expectation that statistical methodology be pre-specified rather than determined after seeing the data, and a SAP finalized and version-locked before both database lock and unblinding is what makes that pre-specification verifiable rather than simply asserted. A SAP amended after unblinding — even with a scientifically reasonable justification — cannot rule out that the change was influenced by seeing which approach produced a more favorable result, which is exactly why the document-control section (Section 1) tracking version history and sign-off dates is not a formality: it is the audit trail that lets a reviewer confirm the timing independently.
Frequently asked questions
What does a statistical analysis plan for a clinical trial contain?
A SAP typically contains, at minimum: endpoint and estimand definitions, analysis-population definitions, the statistical model or test for each endpoint, the missing-data handling approach, the multiplicity-control strategy, subgroup and sensitivity analysis plans, safety-analysis conventions, and — where applicable — the interim-analysis schedule and stopping rules. Most SAPs are also accompanied by mock table, listing, and figure (TLF) shells. See the section-by-section table above for the standard order these appear in.
Is there an official statistical analysis plan template from ICH or FDA?
No single ICH- or FDA-mandated SAP template exists. ICH E9 and its E9(R1) addendum specify the required content and the pre-specification timing (finalized before database lock and unblinding) but not a fixed document layout, unlike ICH M11, which does provide an actual protocol template. Sponsors, CROs, and academic trial units instead use institutional or standard-operating-procedure templates that satisfy those content requirements; the section order in the table above is the structure most of those templates converge on.
Is the SAP the same document as the clinical trial protocol?
No. The protocol establishes the trial’s design, eligibility, interventions, and endpoints, usually with only a summary statistical section. The SAP is a separate, more granular document containing the full technical detail — exact models, missing-data handling, multiplicity strategy — that a biostatistician programs against, and it must remain fully consistent with the protocol’s stated objectives and endpoints.
How do ICH E9(R1) estimands fit into a SAP?
Each endpoint’s estimand — its population, treatment comparison, variable, intercurrent-event strategy, and population-level summary — is stated in the SAP’s endpoints-and-estimands section, ahead of and driving the statistical-methods section: the analysis model is chosen because it estimates the stated estimand, not the reverse. See the worked example above and the full Estimand Framework entry for detail on all five ICH E9(R1) intercurrent-event strategies.
When must a SAP be finalized?
Before database lock and before unblinding. A SAP finalized after either event cannot rule out that its analytic choices were shaped by seeing results that reveal treatment effects, which is the specific integrity concern ICH E9’s pre-specification requirement exists to prevent.
Last verified 16 August 2026 against ICH E9 (“Statistical Principles for Clinical Trials”), the ICH E9(R1) estimands addendum (adopted 20 November 2019), and this site’s existing, independently-sourced dictionary entries for the SAP and the estimand framework. Regulatory citations and dates are stable, low-churn facts; re-check only if ICH or FDA issue superseding guidance.
