Published on 16/11/2025
Making the Statistical Analysis Plan the Single Source of Truth for Regulators and Sponsors
Scope, Stakes, and Structure: What a High-Fidelity SAP Must Deliver
The Statistical Analysis Plan (SAP) is the operational charter that turns protocol intent into reproducible analyses. When aligned, it bridges objectives, endpoints, and estimands with the models, derivations, and outputs that appear in the Clinical Study Report (CSR). When misaligned, it creates ambiguity that erodes credibility. Across regions, authorities expect pre-specification, transparency, and traceability in line with Good Clinical Practice and the ICH framework (E6[R3], E8[R1], E9 and
Define the purpose and boundaries. In the introduction, declare what data are analyzed (e.g., all randomized participants), which datasets are in scope (SDTM/ADaM versions), what outputs are inferential vs. descriptive, and how deviations from the protocol—if any—are handled. State the lock and blind policy, who holds unblinded access, and the role of independent committees. If adaptive features exist, reference a separate Adaptation Specifications Document, with the SAP focused on inference under the planned decision rules.
Map the estimand to the estimator. List each primary and key secondary estimand per ICH E9(R1): population, treatments, variable, intercurrent events (ICEs) and strategies, and summary measure. For each, specify the estimator—the exact statistical model and parameterization that targets the estimand (e.g., “MMRM with unstructured covariance, Kenward–Roger df, treatment, visit, treatment×visit, baseline, and stratification factors; LS mean difference at Week 12”). Make explicit how ICEs are encoded in data and reflected in analysis (treatment-policy, hypothetical, composite, principal strata).
Declare analysis sets unambiguously. Define Intent-to-Treat (ITT), Safety, and any Per-Protocol (PP) or modified ITT sets. PP must be supportive unless you have a pre-agreed rationale for confirmatory use. Provide algorithmic inclusion/exclusion rules (e.g., primary endpoint outside ±X days for PP), and specify how mis-stratification or mis-randomization are handled (analyze as randomized; adjust via covariates).
Hierarchy and alpha control live here. Multiplicity strategy (e.g., serial gatekeeping, fallback, or graphical α-recycling) should mirror the protocol’s confirmatory claims. Include a table tracing α from the primary endpoint through key secondaries and any co-primaries or hierarchical families. State stop rules for testing if a comparison fails and how estimands relate to this hierarchy (e.g., primary estimand inferential; supportive estimand descriptive).
Outline the table/listing/figure (TLF) universe. Provide mock shells for all inferential outputs and key descriptives. Label the primary estimand’s outputs so reviewers can find them first. Link shells to ADaM variables and derivations to ensure one-to-one traceability from method to column/row. For time-to-event, include Kaplan–Meier, Cox/Hazards outputs, and sensitivity graphics (e.g., cumulative incidence for competing risks).
Pre-specify safety and subgroup philosophies. Safety summaries (TEAEs by SOC/PT, AESIs, lab shifts, ECGs) should include denominators, exposure-adjusted incidence, and time-at-risk conventions. Subgroups support interpretation, not fishing: list a priori subgroups (e.g., age bands, sex, region, baseline severity). Avoid inferential claims unless powered and multiplicity-controlled; otherwise, present interaction tests as exploratory.
Concordance with Design: Alpha, Covariates, ICEs, and Missingness Under One Roof
Mirror randomization and stratification. If the trial stratified by baseline factors, the primary test should honor that choice (stratified log-rank/Cox; ANCOVA/MMRM with factors). If site was not a stratum, avoid post-hoc site fixed effects; use random effects or robust variance if site heterogeneity requires attention. State how strata with zero cells are handled (combine or switch to unstratified sensitivity).
Covariate adjustment improves precision when prespecified. Justify covariates by prognostic value and pre-randomization availability (e.g., baseline value of the endpoint, age, disease stage). Specify coding (continuous vs. bands), interactions (if any), and how departures (e.g., protocol amendments that change measurement) are handled. Consistency with the estimand is essential—don’t adjust away the very pathway your estimand intends to reflect.
Intercurrent events: encode, don’t improvise. For each ICE (rescue, treatment discontinuation, switching, death), declare the strategy (treatment-policy/hypothetical/composite/principal strata) and the data fields required (dates, reasons, amounts). For hypothetical strategies, specify imputation targets (what the outcome would be absent the ICE) and the models used to create those counterfactuals. For composite strategies, define how the composite is constructed and how components will be summarized separately to detect offsetting harm.
Missing data are not an afterthought. State mechanisms assumed (MAR vs. MNAR), primary handling (e.g., MMRM without explicit imputation under MAR for continuous outcomes; multiple imputation with chained equations for PROs), and sensitivity analyses (pattern-mixture, δ-adjusted MI, selection models, tipping-point). Define valid day rules for diaries, visit substitution hierarchies, and what constitutes a non-evaluable assessment. Link all rules back to the estimand logic.
Multiplicity across populations and timepoints. If you test overall and a biomarker-positive subgroup, define a closed-testing or graphical α-sharing scheme. For co-primary endpoints, provide success criteria (all must pass vs. at least one) and α allocation. For interim looks, integrate α-spending or combination-test formulas here and cross-reference the DMC charter.
Adaptive, platform, and complex designs. For group-sequential trials, list information fractions, boundaries, and estimators at each look. For sample-size re-estimation, detail promising-zone rules and caps. In platform settings, describe how shared controls are analyzed, how arms entering/exiting are handled, and the global multiplicity framework. Keep the inferential machinery inside the SAP; operational details (who sees what, when) live in charters and adaptation specs.
Sensitivity and supplementary analyses are planned, not patched. For every key assumption, name a sensitivity that interrogates it: alternative covariance structures; alternative censoring rules; per-protocol supportive sets; component-wise analyses for composites; competing-risk methods where appropriate. Explain how results will be interpreted if sensitivities disagree with the primary analysis and what that means for decision confidence.
From Raw Data to Decision Tables: Derivations, Standards, and Reproducibility
Derivation specs connect science to code. Provide a line-by-line specification for how analysis variables are created: baseline definition; windowing rules; visit selection logic; responder definitions; composite construction; imputation flags; censoring times and reasons; adverse event treatment emergent logic; exposure metrics. Each line should reference its SDTM source and yield an ADaM variable with controlled terminology.
Data standards are your ally. Use SDTM for raw organization and ADaM for analysis-ready datasets with one-to-one traceability to outputs. Define dataset structures (ADSL, ADTTE, ADAE, ADLB, ADPRO, etc.), key variables, and join keys. For time-to-event, declare event and censor definitions and create analysis visit or analysis day fields that mirror estimand windows. Include examples of Define-XML annotations and a reviewer’s guide cross-walk.
Mock shells and programmatic reproducibility. For each inferential TLF, include a shell with row/column rules, footnotes, and population flags. Reference the ADaM variables that populate each cell. Require dual programming or independent QC for primary and key secondary endpoints. Maintain a code repository with version control, peer review, unit tests for critical derivations, and execution logs. Blind-preserving conventions (arm labels masked as A/B) should hold until database lock.
Handling protocol deviations and analysis flags. Program flags for PP eligibility, major protocol deviations, ICE occurrence, rescue use, and mis-stratification. Do not remove participants from ITT datasets to create PP; instead, derive PP flags that the analysis can filter. Link deviation categories to flags so that listings and CSR narratives align with the SAP definitions.
Diagnostics and quality signals. Require standard diagnostic plots/tables in the SAP: model residual checks; convergence indicators; proportional-hazards tests; influence statistics; missingness patterns; ePRO compliance over time; timing distributions around target days; arm-level rates of key deviations. Pre-specify thresholds that trigger sensitivity analyses or model alternatives.
Transparency for regulators. Expect reviewers to attempt reproduction. Provide an analysis data reviewer’s guide, annotated CRFs, derivation specs, and a clear “data lineage” diagram (SDTM → ADaM → TLFs). Ensure all artifacts tell one story recognizable to FDA/EMA/PMDA/TGA reviewers within the broader ICH ecosystem and WHO transparency ethos.
Blinded Data Review Meeting (BDRM) and lock discipline. Specify what can change during BDRM (derivation clarifications that are not outcome-dependent) and what cannot (testing hierarchy, estimands, primary models). Document decisions, update derivations if needed, and ensure alignment across SAP, shells, and analysis programs before database lock and unblinding.
Governance, Version Control, and an Audit-Proof Alignment Checklist
Version control with intent. Assign semantic versioning (e.g., SAP v1.0 for initial; v1.1 for clarifications; v2.0 for material changes). Record rationale, approvals, and impact assessments. Synchronize protocol amendments, SAP updates, derivation specs, shells, IRT/EDC changes, and translations. Keep an SAP–Protocol Concordance Table that shows where each objective/endpoint/estimand appears in SAP sections and TLF shells.
Roles and firewalls. Name the Lead Statistician, Programming Lead, Independent (Unblinded) Statistician (if needed), and DMC. Document who can access unblinded data, when, and for what purpose. Separate safety signal processing from inferential teams when possible; keep logs of any unblinding events and their scope. This segregation is a common inspection theme at FDA and EMA inspections and aligns with ICH expectations.
CSR alignment and public transparency. The CSR must present results in the order and definition used in the SAP. Primary estimand outputs appear first; sensitivity and supportive analyses follow. Explain any divergences and justify their impact. Ensure registry postings and lay summaries match the SAP’s endpoint definitions and denominators to maintain trust consistent with WHO transparency principles.
Common findings—and preemptive fixes.
- Mismatch between protocol, SAP, and CSR: maintain a concordance table; run a pre-lock audit to reconcile definitions, windows, and populations.
- Underspecified missing-data/ICE handling: add explicit models and sensitivity plans; ensure data capture supports the chosen strategy.
- Unjustified subgroup inferences: move to exploratory or incorporate into multiplicity control with power justification.
- Stratification ignored in analysis: correct to stratified tests/models or justify why unstratified analysis is valid.
- Derivation ambiguity: publish line-level specs; add unit tests and dual programming for primary endpoints.
- Post-hoc PP rules: restrict to prespecified PP; move unplanned filters to sensitivity with clear labels.
- Adaptive boundary opacity: include α-spending/combination-test formulas and realized information fractions in the SAP/CSR.
Quality Tolerance Limits (QTLs) and monitoring. Track: proportion of primary analyses reproducible on rerun (target 100%); percentage of primary endpoint assessments within window (≥95%); rate of unscheduled SAP edits post-BDRM (target 0); dual-program match rate for key TLFs (≥99%); and timeliness of analysis program QC. Breaches require CAPA with effectiveness checks.
Inspection-ready file map—quick pull list.
- Final protocol and amendments; SAP with version history; Adaptation Specifications (if applicable); DMC charter.
- Derivation specifications, dataset definitions (SDTM/ADaM), Define-XML, Reviewer’s Guides, and data lineage diagram.
- Mock shells for all inferential outputs with links to ADaM variables; programming plans; QC reports and discrepancy resolutions.
- BDRM minutes and decisions; database-lock certificate; unblinding logs; access rights audit trails.
- CSR sections that replicate SAP definitions and testing hierarchy; registry entries and lay summaries aligned to SAP outputs.
- Cross-references to global expectations from the ICH, FDA, EMA, PMDA, TGA, and the WHO.
Actionable checklist (concise).
- Estimands fully mapped to estimators and data capture; ICE strategies explicit.
- Multiplicity plan mirrors confirmatory claims; α flow tabulated; interim spending/combination tests specified.
- Randomization/stratification honored in models; covariates prespecified and justified.
- Missing data strategy + sensitivities aligned to mechanisms; substitution/window rules encoded.
- Derivation specs complete; SDTM→ADaM→TLF traceability proven; dual programming/QC in place.
- BDRM guardrails set; no inferential changes post-lock; version control documented.
- CSR and registries reflect SAP definitions and denominators; transparency maintained.
- TMF index enables retrieval in minutes; artifacts recognizable to FDA, EMA, ICH, WHO, PMDA, and TGA.
Takeaway. A great SAP is more than statistics—it is a governance artifact that converts protocol ambition into defensible, reproducible evidence. When estimands, models, multiplicity, derivations, and outputs all sing from the same sheet—and the files prove it—your results withstand scientific scrutiny and global regulatory review.