What Is a Statistical Analysis Plan?
A Statistical Analysis Plan (SAP) is a detailed, written document that specifies exactly how a study's data will be analyzed — finalized before the data are unblinded, and ideally before data collection even begins. It is more technical and more specific than the analysis paragraph in a study protocol: where a protocol might say "the primary outcome will be compared between groups," a SAP says which test, which model, which covariates, which significance threshold, and which software will actually perform that comparison.
Think of a SAP as a recipe written before you start cooking, not a description of the meal written after it is served. Its entire value comes from being locked in place before anyone sees the results — a plan written afterward, to match whatever turned out significant, is not a SAP in any meaningful sense, even if it uses the same template.
Why Journals and Regulators Require a SAP
A SAP exists to solve one specific problem: without it, there is no way for a reader, reviewer, or regulator to distinguish an analysis that was planned in advance from one that was selected after seeing which comparisons happened to reach significance. This distinction matters enormously — an analysis chosen after seeing the data (sometimes called "p-hacking" or "data dredging" when done without disclosure) can produce a confident-looking, statistically significant result that is really just the product of trying many comparisons until one worked.
ICH E9, the international guideline governing clinical trial statistics, requires a finalized SAP before database lock for any regulated trial. CONSORT requires trial reports to state whether a SAP existed and to disclose any deviation from it. STROBE expects the same core transparency for observational studies, even without mandating a standalone SAP document. Journals increasingly ask peer reviewers to specifically check whether reported subgroup or sensitivity analyses were pre-specified — and "the SAP specified this analysis in advance" is the single most effective answer to that question.
There is also a purely practical reason to write one, independent of any external requirement: a SAP forces you to think through every analytic decision while you can still change the study design to accommodate it, rather than discovering a problem — an outcome that was never precisely defined, a subgroup no one thought to plan for, a missing data rate no one anticipated — only after data collection is complete and the options for fixing it have narrowed considerably. Many experienced clinical researchers describe the SAP-writing process itself, not just the finished document, as the point where the sharpest design flaws in a study are usually caught.
| Framework | What It Requires Regarding the SAP |
|---|---|
| ICH E9 | Finalized SAP before database lock and unblinding, for any regulated clinical trial |
| CONSORT | Disclosure of whether a SAP existed and any deviation from it, for randomized trials |
| STROBE | Clear a priori specification of variables and methods, even without a standalone SAP document |
| Journal peer review | Increasing scrutiny of whether subgroup/sensitivity analyses were pre-specified or exploratory |
Defining the Primary Outcome
The primary outcome is the single measurement (or, occasionally, a small pre-specified composite) that your study is powered to detect a difference in, and that your entire sample size calculation is built around. A SAP must define it with enough precision that two different analysts, working independently from the same raw data, would compute the identical number.
A complete primary outcome definition states: the exact variable, its unit of measurement, the exact time point it is assessed at, and precisely how it will be calculated if any derivation is involved (a change score, a threshold-based responder definition, a composite of several components). If the outcome is a composite (for example, a combined cardiovascular event including myocardial infarction, stroke, or cardiovascular death), the SAP must also state how the composite is counted — whether the first qualifying event only, or all events — and how competing or overlapping components are resolved.
Get this definition wrong or leave it vague, and the entire study's power calculation, statistical model, and headline conclusion all inherit that ambiguity — which is exactly why the primary outcome deserves the most precise language in the whole document, even at the cost of a sentence that reads more like a legal contract than plain prose.
Vague (insufficient): "The primary outcome is blood pressure control."
SAP-ready: "The primary outcome is the change in systolic blood pressure (mmHg) from baseline to Week 12, measured as the mean of three seated readings taken after 5 minutes of rest using an automated oscillometric device, calculated as (Week 12 value − baseline value) for each participant."
Defining Secondary Outcomes
Secondary outcomes are additional measurements of interest that the study was not specifically powered to detect, and results for them should be interpreted as supportive or hypothesis-generating rather than confirmatory — this distinction should be stated explicitly in the SAP itself, not left implicit. List every secondary outcome with the same precision demanded of the primary outcome, and group them logically (efficacy secondary outcomes, safety secondary outcomes, quality-of-life secondary outcomes) if there are more than a handful.
A practical limit worth applying here: a study with 20 loosely defined secondary outcomes is not more rigorous than one with 5 carefully chosen ones — it is simply more likely to produce at least one spurious "significant" finding by chance, which is the exact problem multiple comparisons corrections exist to address. Prioritizing a short, clinically meaningful secondary outcome list, each tied to a specific reason for being included, produces a more credible manuscript than an exhaustive one.
"Secondary outcomes are: (1) proportion of participants achieving systolic blood pressure < 130 mmHg at Week 12 (responder analysis); (2) change in diastolic blood pressure from baseline to Week 12; (3) change in 10-year cardiovascular risk score (ASCVD) from baseline to Week 12; (4) incidence of treatment-related adverse events through Week 12. As the study was powered only for the primary outcome, secondary outcome analyses will be considered exploratory and interpreted accordingly, without adjustment for multiple comparisons unless otherwise specified in Section 8."
Variable Definitions
Every variable used anywhere in the analysis — outcomes, predictors, covariates, and subgroup-defining variables alike — needs its own entry specifying its exact measurement, its unit, its coding scheme if categorical, and its measurement level (nominal, ordinal, or continuous). This section is what allows someone else to reconstruct your dataset's structure without ever seeing the raw file, and is exactly the kind of specification our SPSS data entry guide covers for the analyst's own working file.
| Variable | Definition | Coding / Unit | Type |
|---|---|---|---|
| age | Age at enrollment, in completed years | Continuous, years | Continuous |
| sex | Biological sex as recorded at enrollment | 1 = Male, 2 = Female | Nominal |
| bmi_cat | Body mass index category derived from height and weight at baseline | 1 = Normal, 2 = Overweight, 3 = Obese | Ordinal |
| diabetes | Physician-diagnosed type 2 diabetes at enrollment, per medical record | 0 = No, 1 = Yes | Nominal |
| sbp_change | Change in systolic BP from baseline to Week 12 (primary outcome) | Continuous, mmHg | Continuous |
Statistical Methods
This is the technical core of the SAP: for every comparison in the study, state the exact test or model, the covariates included (for adjusted analyses), the significance threshold, and whether the test is one- or two-tailed. Group this section by outcome (primary analysis, then each secondary outcome) rather than writing one generic paragraph, since different outcomes frequently require different methods.
State the primary analysis method
Name the exact test or model for the primary outcome, including how the comparison will be adjusted, if at all (e.g., "independent t-test" vs "ANCOVA adjusting for baseline value").
State the analysis population
Specify intention-to-treat, per-protocol, or both, and which is considered primary — critical for any randomized trial.
State the method for each secondary outcome
List each secondary outcome's test or model separately, even if several share the same method.
State the significance threshold and directionality
Almost always α = 0.05, two-tailed, unless there is a specific, justified reason for a one-tailed test.
"The primary outcome (change in systolic blood pressure from baseline to Week 12) will be analyzed using analysis of covariance (ANCOVA), with treatment group as the fixed factor and baseline systolic blood pressure as a covariate, in the intention-to-treat population. All statistical tests will be two-tailed with α = 0.05. Secondary outcome 1 (responder proportion) will be analyzed using a chi-square test or Fisher's exact test if any expected cell count is below 5."
Where a variable's normality is uncertain at the time of writing (common, since the SAP is often finalized before any data exist), state the decision rule rather than the test itself — for example, "continuous outcomes will be analyzed using the independent t-test if Shapiro-Wilk indicates normality (p > 0.05), and the Mann-Whitney U test otherwise" — so that the eventual choice is still fully pre-specified even though the specific test cannot be named until the data arrive. Choosing the right test for each comparison is its own decision, covered fully in our test selection guide and interactively in the Test Finder wizard; once chosen, use our reporting-by-test guide to make sure the eventual Results section matches this SAP's specification exactly.
Missing Data Strategy
The SAP must state, in advance, how missing data will be handled — because the handling method itself can materially change the result, and deciding it after seeing which method gives a more favorable answer defeats the entire purpose of pre-specification. State the assumed missingness mechanism, the primary handling method, and any planned sensitivity analysis using an alternative method.
| Missingness Mechanism | Typical Primary Method | Common Sensitivity Check |
|---|---|---|
| Missing Completely at Random (MCAR) | Complete-case analysis | Multiple imputation, for comparison |
| Missing at Random (MAR) | Multiple imputation | Complete-case analysis, for comparison |
| Missing Not at Random (MNAR) suspected | Pattern-mixture or sensitivity modeling | Best-case / worst-case bounding analysis |
"Missing data for the primary outcome are expected to be minimal (<5%, based on the pilot study) and assumed missing at random. The primary analysis will use multiple imputation (m = 20 imputations, chained equations, including treatment group, baseline value, age, and sex as predictors). A complete-case analysis will be conducted as a pre-specified sensitivity analysis (see Section 10)."
If your SAP is being written before recruitment starts, the assumed missingness mechanism will necessarily be a prediction based on similar prior studies or a pilot dataset rather than a certainty — that is expected and acceptable, provided the prediction is reasoned and the sensitivity analysis using an alternative method is still pre-specified as a safeguard against being wrong. See our full guide to handling missing data in medical research for the mechanisms and imputation methods in more depth, and use the Excel data cleaning tool to quantify missingness in your dataset before finalizing this section.
Outlier Handling Strategy
Like missing data, how outliers are identified and handled must be decided before the data are examined, because a rule chosen after seeing which points are inconvenient is not a rule at all. State the exact statistical definition of an outlier you will use, and the exact action taken once one is identified — and note that "removed" is rarely the correct default action; "verified, then addressed" usually is.
State the detection method
A specific, quantitative rule — e.g., values beyond 3 SD from the mean, or beyond 1.5× the IQR from the nearest quartile — not a subjective visual judgment.
Distinguish data errors from genuine extreme values
A physiologically impossible value (age = 200) is a data entry error to correct or exclude; a genuinely extreme but plausible value (a very high but real CRP) is not.
State the planned action and any sensitivity analysis
Winsorizing, a robust/non-parametric method, or a sensitivity analysis re-run with and without the flagged points — decide and document it in advance.
"Values beyond 1.5 times the interquartile range from the nearest quartile will be flagged as potential outliers for continuous variables. Flagged values will first be checked against source documents for data entry errors; confirmed errors will be corrected. Genuine extreme values will be retained in the primary analysis; a pre-specified sensitivity analysis will re-run the primary outcome model using Winsorization at the 1st and 99th percentiles."
Note that the correct response to a confirmed outlier is very rarely silent deletion — an unexplained drop in sample size between your CONSORT flow diagram and your final analysis table is itself a red flag reviewers are trained to look for, so any exclusion, however well justified, needs to be counted and disclosed. See our full guide to outlier detection in medical research for the specific detection rules and when each applies.
Subgroup Analyses
A subgroup analysis examines whether the treatment effect differs across a pre-specified patient characteristic (age group, sex, disease severity). The SAP must list every planned subgroup analysis by name before the data are seen — any subgroup finding not listed here, discovered only after looking at the results, must be explicitly labeled as post-hoc and exploratory in the manuscript, never presented as if it were pre-specified.
For each planned subgroup analysis, state the exact subgroups being compared and the statistical method used to test for a genuine subgroup effect — an interaction term in a regression model, not simply comparing p-values from separate analyses run within each subgroup (a common and misleading shortcut, since a significant result in one subgroup and a non-significant one in another does not by itself prove the subgroups differ from each other).
Keep the number of pre-specified subgroups small and clinically justified — each additional subgroup comparison adds another opportunity for a chance finding, and a SAP listing fifteen subgroups looks, to any experienced reviewer, exactly like an attempt to guarantee at least one "significant" result rather than a genuinely hypothesis-driven set of comparisons. Three to five well-justified subgroups, each tied to a specific clinical rationale stated in the SAP, is far more persuasive than an exhaustive list.
"Three subgroup analyses are pre-specified for the primary outcome: by baseline age (<65 vs ≥65 years), by sex, and by baseline diabetes status. Each will be tested by adding a treatment-by-subgroup interaction term to the primary ANCOVA model. Given the exploratory nature of subgroup analyses, no adjustment for multiple comparisons will be applied, and results will be interpreted as hypothesis-generating regardless of statistical significance, per Section 8's overall interpretation framework."
Sensitivity Analyses
A sensitivity analysis re-runs the primary analysis under a different, defensible set of assumptions to check whether the main conclusion holds up — it asks "does this result depend heavily on one specific analytic choice, or is it robust to reasonable alternatives?" Common sensitivity analyses re-test the primary outcome using the per-protocol population instead of intention-to-treat, an alternative missing data method, or with outliers excluded rather than retained.
"The following sensitivity analyses are pre-specified for the primary outcome: (1) per-protocol population instead of intention-to-treat; (2) complete-case analysis instead of multiply-imputed data; (3) Winsorized data instead of raw data; (4) unadjusted comparison (t-test) instead of ANCOVA. Consistency of direction and approximate magnitude of effect across these analyses will be interpreted as supporting the robustness of the primary result."
See our related guide on intention-to-treat vs per-protocol analysis for the most common sensitivity analysis pairing in randomized trials.
Software
State the exact software package, version number, and manufacturer that will be used for the analysis — required by APA 7th edition and expected in any reproducible SAP, since different software versions can occasionally produce small numerical differences in complex models (survival analysis and mixed models especially). If more than one package is used for different parts of the analysis (for example, SPSS for descriptive statistics and R for a specific model unavailable in SPSS), state which package handles which analysis.
This section also matters for a more practical reason than reproducibility alone: naming the software up front forces you to confirm, before data collection begins, that every planned analysis is actually available in the package you intend to use — discovering mid-analysis that your chosen software cannot fit the specific model your SAP requires (a particular mixed-effects structure, a specific imputation method) is a solvable problem early, and a serious one late.
"All analyses will be performed using IBM SPSS Statistics, version 28.0 (IBM Corp., Armonk, NY). Multiple imputation will be performed using the same software's Multiple Imputation module (fully conditional specification method, 20 imputed datasets, pooled per Rubin's rules)."
Sample SAP: A Complete Worked Example
Below is a condensed but complete sample SAP for a hypothetical two-arm randomized controlled trial, showing how every section above comes together into one working document.
1. Study Design
Two-arm, parallel-group, double-blind randomized controlled trial. Participants randomized 1:1 to Drug X or placebo, stratified by baseline diabetes status.
2. Primary Outcome
Change in systolic blood pressure (mmHg) from baseline to Week 12, calculated as (Week 12 value − baseline value), using the mean of three seated readings after 5 minutes of rest.
3. Secondary Outcomes
- Proportion achieving SBP < 130 mmHg at Week 12
- Change in diastolic blood pressure, baseline to Week 12
- Change in 10-year ASCVD risk score, baseline to Week 12
- Incidence of treatment-related adverse events through Week 12
4. Sample Size
76 participants per group (152 total) provide 80% power to detect a 5 mmHg between-group difference (SD 12 mmHg), α = 0.05, two-tailed. Adjusted to 84 per group (168 total) to allow for 10% attrition.
5. Analysis Population
Intention-to-treat (all randomized participants, analyzed as randomized) is the primary population. Per-protocol population is defined as completing ≥80% of scheduled doses with no major protocol deviation, used in sensitivity analysis.
6. Primary Analysis
ANCOVA with treatment group as fixed factor and baseline SBP as covariate, intention-to-treat population, two-tailed α = 0.05.
7. Missing Data
Primary outcome missingness assumed MAR; handled via multiple imputation (20 imputations, chained equations). Complete-case analysis as sensitivity check.
8. Multiplicity
No adjustment for the single primary outcome. Secondary and subgroup analyses are exploratory; no formal multiplicity correction applied, per pre-specified interpretation as hypothesis-generating.
9. Subgroup Analyses
Pre-specified: age (<65 vs ≥65), sex, baseline diabetes status — each tested via treatment-by-subgroup interaction term in the primary ANCOVA model.
10. Sensitivity Analyses
Per-protocol population; complete-case analysis; unadjusted t-test in place of ANCOVA; Winsorized data at 1st/99th percentile.
11. Software
IBM SPSS Statistics, version 28.0 (IBM Corp., Armonk, NY).
Downloadable SAP Template
Use this fill-in-the-blank version of the sample SAP above as a starting point for your own study — every section from this guide is included as a labeled placeholder.
Statistical Analysis Plan Template
All 11 SAP sections in one plain-text file, ready to fill in with your own study's details.
⬇ Download the SAP Template (.txt)Common SAP Mistakes
Mistake 1: Writing the SAP After Seeing the Results
A SAP drafted or finalized after unblinding — even if it accurately describes what was actually done — no longer serves its core purpose of proving the analysis was pre-specified, and this is often discoverable from file metadata or version history during audit.
Mistake 2: Vague Variable and Outcome Definitions
"Blood pressure will be assessed" leaves the timing, measurement method, and derivation entirely undefined, allowing multiple different numbers to satisfy the same sentence.
Mistake 3: No Missing Data or Outlier Strategy
Deciding how to handle missing data or outliers only after seeing which method produces a more favorable result is one of the clearest forms of undisclosed analytic flexibility.
Mistake 4: Presenting Post-Hoc Subgroups as Pre-Specified
Running a subgroup analysis after seeing the results, then describing it in the manuscript without noting it was not listed in the original SAP, is a serious and increasingly detectable violation of analytic transparency.
Mistake 5: No Distinction Between Primary and Exploratory Analyses
Treating every secondary or subgroup finding with the same confidence as the primary outcome overstates what an underpowered comparison can actually support.
Mistake 6: Amending the SAP Without Documentation
Silently changing the primary analysis method, outcome, or a key definition after the SAP was finalized — without a dated, justified amendment — undermines the entire document's credibility if discovered.
Mistake 7: Treating the SAP as a One-Time Document Nobody Will Check
Some researchers write a SAP purely to satisfy an ethics committee or journal checklist requirement, then never refer back to it once analysis begins — defeating its entire purpose, since the whole value of the document depends on the final analysis actually matching what it specifies.
Frequently Asked Questions
Build Your Analysis Around a Solid SAP
Use StatClinic's free calculators for sample size, normality testing, and test selection to fill in your SAP's technical details with confidence — then run the exact analysis you specified. Free, no registration required.
Try StatClinic Free →