The development safety update report (DSUR) is often the first place a regulator forms a view of how seriously a sponsor takes ongoing safety oversight.
A coherent and well-reasoned report signals your safety system is under control, but one with minimal signal discussion or mismatched data invites a request for information that can delay your drug development program.
This blog looks at where DSUR writing typically breaks down, and what your pre-submission check should cover to ensure your document stands up to regulatory scrutiny.
Why the DSUR draws closer scrutiny than sponsors expect
A DSUR is governed by the International Council for Harmonisation’s (ICH) E2F guideline and is due annually from the point your first clinical trial authorization takes effect.
Unlike a one-off submission, it is cumulative: each report has to account for safety data from every active study under the same investigational product, including all serious adverse events recorded during the period, compared against the prior year’s findings and against the reference safety information (RSI) sponsors use to judge whether an event was expected.
That comparison is exactly what creates the scrutiny.
A reviewer assessing this year’s development safety update report typically has last year’s version open alongside it, together with the risk management plan and the safety section of the investigator’s brochure (IB). Any discrepancies between these documents, in numbers or in the conclusions drawn from them, quickly become visible.
First-time sponsors tend to treat each DSUR as a standalone deliverable, disconnected from their day-to-day pharmacovigilance services and with limited reference to what was submitted previously.
That approach misses the point: regulators are assessing whether oversight has been continuous, not just whether this year’s profile looks acceptable.
Where development safety update report writing breaks down
Three failure points account for most of the questions regulators raise on a development safety update report, alongside several smaller issues that compound the problem:
1. Inconsistent safety summaries across reporting periods
The most common failure is a safety summary that doesn’t reconcile with the one submitted the year before. The same few problems recur:
- Cumulative totals that move without a documented reason: case counts naturally shift between reports as cases are upgraded, downgraded, or nullified — but when this year’s serious adverse event figures differ from last year’s, the source file must explain why.
- Causality assessment updates: the same event moves from “possibly related” to “unrelated” between cycles, with nothing in the source file to explain why.
- Interval and cumulative data blurred together: numbers covering only the current reporting period get blended with totals covering the product’s entire development to date, so neither figure is easily interpretable.
These issues typically occur when DSUR authoring is treated as a fresh writing exercise each year rather than an update to a living document, often because the safety physician or medical writer involved has changed, or because of changes to how the source data was pulled from the safety database.
Before signing off on a DSUR draft, compare it to last year’s. If the case numbers have changed, has this been explained? If a causality assessment has changed, was the decision documented in the source? A change in event term, additional follow-up information, or a revised company position should be stated explicitly, not left for the reviewer to infer.
2. Reference safety information that doesn’t match what’s being assessed
Reference safety information (RSI) is the section of the IB used to determine whether an adverse event is expected or unexpected. Getting it wrong creates three recurring problems:
- The DSUR cites one version of the brochure, while the expectedness assessments performed during the reporting period were made against an earlier or later one.
- The mismatch goes unnoticed mid-cycle, particularly during periods of active enrollment, because the safety team doesn’t formally reconcile which version applied to which case.
- Every suspected unexpected serious adverse reaction (SUSAR) determination in the report becomes questionable, not just the one in dispute, because expectedness depends entirely on which version of the RSI was used.
That distinction is relevant beyond the development safety update report itself, since the same expectedness conclusions often feed into other regulatory submissions for the same product.
Before submission, confirm the exact IB version and date that was current for each case in the reporting period, and state that version explicitly in the DSUR. Where the brochure changed mid-cycle, document the cutover point and reassess any cases that fall near it. Changes to the RSI should be summarised in the DSUR.
3. Signal discussion that doesn’t hold up under questioning
When a safety signal is mentioned and described as “being monitored,” the report moves on. But if no methodology is stated for how the signal was identified, no timeline is given for when a conclusion is expected, and no rationale is offered for why “no new safety concerns” was the final judgment for the period, regulators will likely ask questions.
This is because the reviewer is forced to take the sponsor’s conclusion on trust rather than follow the reasoning behind it. A defensible signal discussion shows:
- How the signal was identified, such as a disproportionality check, a cluster of similar events, or a literature finding.
- What additional data was reviewed to determine whether it represented a genuine change in the safety profile.
- What the benefit-risk conclusion was based on, stated explicitly rather than simply repeated from the prior report.
Where a signal remains open at the data lock point, say so plainly and describe the plan for closing it out, such as further case accrual or a planned analysis. Leaving a signal undefined reads as unmanaged.
4. Other gaps that often invite questions
A handful of smaller recurring issues can also accumulate. For example:
- Line listings and case narratives sometimes disagree on basic facts, such as outcome or seriousness criteria, because they were finalized at different points using different data exports.
- Serious adverse events get classified inconsistently across sites, with one investigator coding an event as “hospitalization” and another describing the same clinical picture as “medically important” without a documented basis for the difference.
On their own, these are small inconsistencies. However, they’re also the kind of detail a reviewer cross-checks first, because they’re quick to verify and quick to flag. A short reconciliation review between the narratives, the line listings, and the site-level coding closes both gaps before submission.
Sign-off timing is the other gap. If the final review and approval of the DSUR happens ahead of the final reconciliation checks, the signature is approving an outdated version of the document.
A pre-submission quality checklist
Before your development safety update report goes to a regulatory authority, run it against this checklist:
- Reconcile cumulative totals: check this year’s serious adverse events and SUSAR counts against last year’s report before drafting begins.
- Confirm RSI version control: make sure the IB version used for expectedness determinations matches the version cited as reference safety information.
- Document every signal’s methodology and conclusion: include the rationale behind any “no new concerns” statement.
- Cross-check classifications: compare line listings, narratives, and site-level case coding for consistency.
- Ensure clinical review and PV expert sign-off before submission: a comprehensive medical review should accompany the PV scientist’s review and final signal discussions to ensure coherent benefit-risk conclusions.
- Align with other regulatory submissions: verify causality language is consistent with the position taken elsewhere (e.g. in the IB or risk management plan).
- Confirm the data lock point: check that reporting period dates are accurate and match the cover letter.
Building these checks into your pharmacovigilance processes helps ensure a defensible submission.
Make your DSUR a record of control, not a yearly hurdle
Most of these failure points come from treating the DSUR as an annual writing task instead of a continuous discipline. The fix isn’t more data; it’s reconciliation: checking this year’s report against last year’s, against the RSI in active use, and against the regulatory submissions sitting alongside it.
TMC Consulting supports emerging biotech and pharma companies with pharmacovigilance services spanning DSUR preparation, RSI management, signal evaluation, and ongoing safety surveillance, including medical review or qualified person for pharmacovigilance (QPPV) support.
Our specialists work alongside your existing team to keep safety documentation consistent year over year, rather than being rebuilt from scratch each cycle.
If your next DSUR is approaching and you want a second set of eyes on the signal discussion or the reference safety information before it goes to a regulator, speak to our pharmacovigilance services team today.