A drug program produces a specific set of regulated documents, and they arrive in a fairly predictable order. Preclinical work is written up before a molecule can go into humans. A protocol exists before a trial can enroll. A Clinical Study Report is filed after the trial closes. A safety update goes out every year the drug is in development, and another kind of safety update every cycle after it is approved. Learn the sequence once and most of the regulatory-writing job stops looking like a pile of acronyms and starts looking like a timeline.
This is a field guide to that timeline. For each document: what it is in a few sentences, who actually reads it, what makes it hard to write, and an honest range for how long it tends to run. Page counts vary enormously with the size of the program, so treat every range as a rough sense of scale. If you want the fundamentals underneath all of this, the complete guide to regulatory writing is the place to start; this post is about the documents themselves.
Preclinical and the IND: getting into humans
Before a molecule can enter its first human study — healthy volunteers in some programs, patients in others, as is common in oncology — the sponsor has to convince a regulator that it is reasonable to try. In the US that means an Investigational New Drug application (IND); in the EU it is a Clinical Trial Application built on an IMPD, the Investigational Medicinal Product Dossier. The writing task at this stage is to assemble what is known about the molecule from chemistry and animal work into something a reviewer can act on.
The Investigator's Brochure (IB). The IB is the single reference document that pulls together everything known about an investigational product — pharmacology, toxicology, prior clinical experience if any, and the reference safety information used to judge whether an adverse event is expected. It is written under ICH E6(R3) and it travels with the program, getting reissued as new data comes in. Investigators, ethics committees, and regulators all rely on it to run trials safely. What makes it hard is synthesis: you are folding nonclinical data, clinical data, and the previous edition of the IB into one coherent story, and the reference safety information section has to be treated as a controlled artifact because expectedness assessments downstream depend on it. IBs commonly run from tens of pages early on to well over a hundred for a mature program. This is enough of a set piece that we treat IB authoring as its own workflow.
The IND modules and briefing documents. The IND itself is a structured submission — nonclinical study reports, the CMC section, the clinical protocol, and the IB. It is commonly compiled and submitted electronically in the eCTD structure, so it shares organizing conventions with the later marketing application without being a miniature version of it. Before the IND, sponsors often request a pre-IND meeting with the FDA, and that meeting runs on a briefing document: a focused package that frames the questions the sponsor wants answered and gives the agency the background to answer them. Briefing books are read closely by a review division under time pressure, so the hard part is not length but precision — every question has to be answerable from what you put in front of them. They range from a couple of dozen pages to a hundred or more. See briefing documents for how that package comes together.
During the trial: conduct documents
Once a trial is live, a different set of documents governs how it runs and how its safety is reported.
The protocol and its amendments. The protocol is the operating manual for the trial: objectives, endpoints, eligibility, treatment, statistics, and safety monitoring. It is written under ICH E6(R3), and ICH M11 now provides a finalized harmonized protocol structure (reached Step 4 on 19 November 2025), though regional implementation timelines should be checked. It is amended whenever the design changes. Everyone reads it — investigators, ethics committees, regulators, monitors, statisticians — which is why it is hard to write: the estimand and endpoints have to stay consistent across the objectives, the statistical section, and the safety sections, and an amendment that fixes one place but not the others creates the kind of contradiction reviewers catch immediately. Protocols usually land between 60 and 150 pages. Keeping them internally consistent is the central challenge, and it is why protocol authoring exists as a distinct problem.
The Informed Consent Form (ICF). The ICF is the document a participant actually reads and signs. It has to describe the trial, its risks and benefits, and the participant's rights, and it has to do so at a reading level a non-specialist can follow while staying faithful to the protocol. Its readers are trial participants and the ethics committees that approve it. The difficulty is register, not volume: you are translating a 120-page protocol into a few pages of plain language without softening a risk or overstating a benefit, and every material protocol amendment can force an ICF revision. ICFs typically run from a handful of pages to twenty or more depending on jurisdiction and local requirements. Managing that plain-language translation is what ICF authoring is about.
The SAP interface. The Statistical Analysis Plan is usually owned by biostatistics, not the medical writer, but writers live at its interface. The SAP defines how the trial's data will be analyzed, and it is the source of truth for the numbers that later populate the CSR. The writer's job is to make sure the report describes what the SAP actually specified — the same populations, endpoints, and handling of missing data — so it is worth reading as carefully as the protocol even though you rarely author it.
The Development Safety Update Report (DSUR). Every year a product is in clinical development, the sponsor files a DSUR under ICH E2F. It is the annual account of what the clinical program has learned about safety: interval line listings of serious adverse reactions plus cumulative summary tabulations of serious adverse events across the studies, any new safety findings, and an assessment against the reference safety information. Its readers are regulators tracking the evolving safety profile. What makes it hard is reconciliation — pulling SAE data across multiple investigational studies into cumulative tables that add up, and running listedness against the RSI. DSURs commonly run 50 to 100 pages plus appendices, most of the weight in the tables. That reconciliation is the reason DSUR automation is worth doing.
At the end of the trial: reporting results
The Clinical Study Report (CSR). The CSR is the definitive account of a single trial, written under ICH E3, whose structure defines roughly 16 sections plus appendices. It draws from one protocol, one SAP, and dozens of tables, figures, and listings, and turns them into a narrative a reviewer can follow from design through results to conclusions. Its readers are regulators and, through them, the eventual product label. The CSR is hard for a specific reason: the mapping from source data to text is mechanical and voluminous, but the interpretation — which results are pivotal, how to characterize the safety profile — is judgment, and the two are interleaved on every page. Full CSRs for a large trial run into the hundreds of pages before appendices; the CORE Reference guidance is the practical companion to ICH E3 that most writers keep open. The mechanical half of the work is where CSR automation earns its place.
Patient narratives. Within the CSR sit the patient narratives: short prose accounts of deaths, serious adverse events, and other significant events, describing what happened to a patient and when. Under ICH E3 they appear in Section 12.3.2, or in Section 14.3.3 when there are enough to warrant a separate appendix. A narrative is generally expected for each such event, though E3 allows those clearly unrelated to the study treatment to be omitted or described briefly. A large trial can still generate hundreds, each following the same template against different underlying data. The reader is a safety reviewer checking that nothing was glossed over. They are individually simple and collectively punishing — the difficulty is volume and consistency, not any single narrative.
The marketing application: asking for approval
When the program is ready to seek approval, everything converges into the Common Technical Document, the CTD, whose five modules are the shared format across FDA, EMA, and PMDA. Two clinical summary documents in Module 2 are pure medical-writing set pieces. The Clinical Overview (Module 2.5) is a concise, interpretive benefit-risk argument — typically well under 100 pages — that a senior reviewer reads first. The Clinical Summaries (Module 2.7) are the detailed, factual synthesis of efficacy and safety across all studies, and they run much longer. The overview is hard because it is argument, not recitation; the summary is hard because it is comprehensive. Alongside them, Module 3 carries the CMC (quality) content — mostly interlocking tables rather than prose, which is a genuinely different automation problem and the reason CMC authoring gets treated on its own. For how the five modules fit together, see the CTD explained.
After approval: keeping the file current
Approval does not end the writing. It changes which safety document you file.
The PSUR / PBRER. Once a drug is marketed, the periodic safety report becomes the PSUR, prepared as a PBRER under ICH E2C(R2). Where the DSUR covered a product in development, the PBRER covers a product in use: cumulative and interval safety data, benefit-risk evaluation in the light of real-world exposure, and signal assessment. Regulators read it to decide whether the approved benefit-risk balance still holds. It is hard the same way the DSUR is, at larger scale — cumulative tables that have to reconcile cycle over cycle, listedness against the reference product information (the company core data sheet, or another clearly specified reference document as ICH E2C(R2) permits), and a benefit-risk argument reflecting everything since the last report. PBRERs commonly run from 50 to well over 100 pages plus appendices. The reconciliation burden is what PSUR automation addresses.
Labeling and variations. Post-approval, the product label (the US Prescribing Information, the EU SmPC) is a living document, and changes to it — new safety information, a new indication, a manufacturing change — are reported to regulators, often as a variation or supplement with its own supporting documents. The exact reporting category depends on the jurisdiction and on how significant the change is, ranging from a notification to a prior-approval submission. These filings are typically short but unforgiving: label wording is scrutinized word by word, and a variation has to justify precisely what is changing and why.
For a fuller tour of the guidelines named above, the post on ICH guidelines every regulatory writer should know walks E3, E6(R3), E2C(R2), E2F, and M4 in more depth.
Medical devices: a parallel set
Devices run on their own regulatory track with their own documents, and writers who cross over need a second vocabulary. The central document is the Clinical Evaluation Report (CER), written under MEDDEV 2.7/1 Rev 4 and the EU Medical Device Regulation. A CER appraises the clinical evidence for a device — the sponsor's own data plus a structured literature review — and argues that the benefit-risk profile supports its intended use. Some CERs still lean on an equivalence rationale to a comparable device, but the EU MDR now constrains that route tightly (including access to the comparator's technical documentation), so it is no longer a routine feature of every CER. Its readers are notified bodies. It is hard because the literature appraisal has to be systematic and defensible, and any equivalence argument has to hold up to challenge. Devices also file periodic safety updates: under the EU MDR, PSURs apply to Class IIa, IIb, and III devices, with the update frequency varying by class (broadly, at least every two years for Class IIa and at least annually for Class IIb and III). Each summarizes post-market data and updates the benefit-risk conclusion, conceptually close to the drug PBRER but on a device evidence base. The literature-appraisal machinery is the core of CER authoring.
Reading the map
The documents in this guide are not a random collection. They are the paper trail of a molecule moving from animal studies to an approved product and staying on the market, and every one exists to answer a regulator's question at a particular moment: is it safe to start, is the trial well designed, what did the trial find, does the benefit still outweigh the risk. If you are moving into this field, learn the sequence before the acronyms — the guide on how to become a regulatory writer covers the path in, and the piece on medical writing versus regulatory writing draws the boundary around exactly this document set. Once the timeline is in your head, a new acronym is just a document that slots into a place you already understand.