Writing a systematic review protocol means setting out, in advance and in writing, exactly how you will find, select, appraise, and combine the evidence for one defined question. The protocol fixes the eligibility criteria, the databases, the planned analysis, and the outcomes before any study is seen, so the finished review reflects the evidence rather than choices made after the results appeared.
Why a protocol is the part you cannot skip
A protocol is the contract you make with your future self and your readers. Once you have run the search and started reading abstracts, it is human nature to drift toward the studies that fit your expectation. The protocol removes that temptation by committing you to pre-specified methods. It is also what separates a true systematic review from a narrative one, a distinction we draw out in systematic review versus literature review. A registered, timestamped protocol is increasingly expected by journals and by guideline panels, and it is the single best protection against accusations of outcome switching or selective reporting.
The sections every protocol needs
1. Background and rationale
Open with a short justification: what is already known, what gap remains, and why a systematic review is the right tool now. A scoping exercise often comes first to confirm no recent review already answers your question, which is why many teams start with a scoping review of the field.
2. The review question and framework
State one answerable question and the framework you used to build it, most often PICO for effectiveness questions. The framework also seeds your search terms, so it is worth getting right. Our walkthrough of framing the research question covers how a vague aim becomes a testable question.
3. Eligibility criteria
Spell out your inclusion and exclusion criteria in full: populations, study designs, comparators, outcomes, language, and date limits. These criteria must be specific enough that two reviewers applying them reach the same decisions. We treat this in depth in setting eligibility criteria.
4. Search strategy
Name the databases, the date of the search, and the structure of the query. The full strategy for at least one database is usually appended. Building this well is a craft of its own, covered in building a search strategy and supported by our literature search service.
5. Screening, extraction, and risk of bias
Describe how many reviewers will screen, how conflicts are resolved, what data you will extract, and which risk of bias tool fits your included designs, such as RoB 2 for randomised trials. Naming the tool now stops you reaching for a convenient one later.
6. Planned synthesis
Say whether you expect to pool results in a meta-analysis or to use a structured narrative approach, and how you will judge heterogeneity and overall certainty with GRADE. Pre-specifying any subgroup analyses here is what keeps them credible rather than fishing expeditions.
Following the PRISMA-P reporting items
A protocol is not free-form prose; it has its own reporting standard. PRISMA-P (Preferred Reporting Items for Systematic Review and Meta-Analysis Protocols) sets out the items a protocol should contain, and writing to it is the surest way to avoid a registration bouncing back for incompleteness. It maps closely to the sections above but adds administrative items that authors often forget: an amendments statement, the planned registration venue and number, the funding source, and any support from a sponsor. Drafting against the checklist rather than from memory is what stops a protocol reading complete while quietly missing the items a methods editor will look for first.
The protocol is also where the labour-intensive stages are resourced in advance. State how many reviewers will screen, who breaks ties, and what level of agreement, measured with Cohen’s kappa, will trigger a re-screen. Naming the people and the thresholds now is what keeps the later stages of the review from improvising under deadline pressure.
A worked example: turning a vague aim into a protocol question
Suppose the starting aim is “does mindfulness help anxiety”. That is unanswerable as written, because two reviewers would disagree on almost every term. Sharpened with PICO, it becomes: in adults with a diagnosed anxiety disorder (Population), do mindfulness-based interventions (Intervention) compared with usual care or a waiting list (Comparator) reduce self-reported anxiety symptoms at eight weeks (Outcome). Each element now does work elsewhere in the protocol. The population fixes an eligibility rule and seeds search terms; the intervention defines a concept block in the query; the comparator decides which study arms are eligible; and the outcome pins down both the effect measure and the timepoint the synthesis will pool. A protocol question that cannot be decomposed this way is a sign the question still needs work before any method is written.
Common mistakes that weaken a protocol
Three errors recur in protocols submitted for registration. The first is vague eligibility criteria that two reviewers could read differently, which guarantees screening conflicts and a low agreement score later. The second is naming no risk of bias tool, or naming a generic quality checklist, when a design-matched instrument such as a structured risk of bias assessment is what the synthesis actually needs. The third is describing the synthesis as “narrative or meta-analysis as appropriate” without committing to a rule, which leaves the choice to be made after the results are visible, the very thing a protocol exists to prevent. Each is avoidable by writing the protocol as a set of decisions rather than intentions.
Registering and amending the protocol
For health questions the finished protocol is registered on PROSPERO, which timestamps it publicly; for broader topics teams use OSF instead, a choice we compare in PROSPERO versus OSF registration. The mechanics of submitting are covered step by step in registering on PROSPERO. Plans do change, and that is allowed: the rule is that you record every change transparently, which is exactly what we cover in amending a protocol. A protocol is a living document, but every edit must be visible.