Introduction
An information request from FDA during an active review is one of the more routine events in a regulatory affairs career, and also one of the easiest to handle badly under time pressure. Whether it arrives as an information request during a drug or biologic review, or as an additional information hold during a device submission, the underlying skill is the same: understanding exactly what is being asked, scoping a response that answers it fully without volunteering more than was requested, and moving it through internal review fast enough that the clock, wherever it applies, starts running again as soon as possible. This is a craft skill that experienced regulatory professionals develop through repetition, and one that newer specialists are rarely taught directly.
Understanding What Kind of Request You Actually Received
The mechanics differ meaningfully depending on the submission type, and confusing them leads to real mistakes. For a 510(k) device submission, an additional information request typically places the submission on hold, and the review clock stops until a complete response is received; under the current device user fee framework, a sponsor generally has a defined window, commonly referenced as up to 180 days, to respond before the submission is considered withdrawn, which is a real deadline with real consequences, not a soft suggestion. For a drug or biologic submission under the prescription drug user fee framework, an information request during review functions differently: it does not necessarily pause a statutory clock the way a device hold does, but a response that constitutes a major amendment can extend the review timeline, sometimes by a matter of months, depending on the nature and timing of what is submitted. Knowing which regime governs your submission, and what the practical consequence of your response type will be, has to be the first thing you establish, not an afterthought.
Read the request itself slowly and more than once before drafting anything. Reviewers write these under their own time pressure, and the phrasing is not always as precise as it should be. Identify every discrete question being asked, since a request that reads as one paragraph often contains three or four separable asks that deserve separate, clearly labeled answers rather than one blended narrative response. If any part of the request is genuinely ambiguous, and you cannot resolve the ambiguity through your own regulatory judgment or a check of the submission history, it is almost always better to request a brief clarifying call than to guess and produce a response that misses the actual question, which just generates a second, more frustrated request later.
Scoping the Response: Answer What Was Asked
The single most common mistake in responding to an information request is scope creep, in both directions. Under-scoping happens when a response answers the literal question but omits context a reviewer clearly needs to actually evaluate it, forcing a follow-up request that could have been avoided. Over-scoping happens when a response includes additional data, additional justification, or additional documents that were not asked for, in an effort to be thorough or preemptively address anticipated follow-up questions. Over-scoping feels responsible, but it routinely backfires: volunteered information can raise new questions the reviewer had not been considering, can inadvertently highlight an inconsistency elsewhere in the submission, and in the case of a major amendment framework, can itself trigger clock consequences that a narrower response would not have.
The discipline worth building is to draft an answer to exactly the question asked, then deliberately review it and ask whether anything beyond that scope has crept in, rather than trying to get the scope right in a single pass. It helps to literally restate the reviewer's question at the top of each response section before answering it, both because it forces you to confirm you are answering the actual question and because it makes the response easier for the reviewer to map back to their own request, which speeds up their read.
Coordinating Internally Without Losing Time
An information request response usually needs input from people outside regulatory affairs: a clinical scientist, a CMC or manufacturing expert, a biostatistician, a quality engineer. The regulatory affairs professional's job is rarely to write the technical content from scratch; it is to translate the reviewer's actual question into a clear, scoped request to the right internal expert, set a realistic but firm deadline given how much runway the overall response has, and then edit what comes back for regulatory tone, completeness against the original question, and consistency with the rest of the submission.
The most common point of delay is not the technical work itself but ambiguity in the internal ask. A vague request like "can you address FDA's question about the stability data" invites a subject matter expert to write more than is needed, in whatever direction seems most defensible to them, which then requires a second round of editing to bring back into scope. A specific request, quoting the reviewer's exact language and stating clearly what form the answer needs to take, produces a first draft that is far closer to submission-ready and saves real time on a compressed timeline.
The Cover Letter Sets the Tone for the Whole Response
A short, well-organized cover letter at the front of an information request response does real work beyond formality. It should state clearly that this is a response to a specifically dated request, list each question being addressed in the same order the reviewer asked them, and briefly indicate where in the response each answer can be found. Reviewers manage a heavy caseload, and a response that is easy to navigate gets reviewed more efficiently than one that requires the reviewer to hunt through pages to confirm every question was actually answered. This is a small piece of the response but it meaningfully affects how the response is received, and it costs almost nothing to get right.
When to Push Back Instead of Just Answering
Occasionally a request asks for something the sponsor genuinely believes is unnecessary, already addressed elsewhere in the submission, or based on a misreading of previously submitted data. In these situations, the right move is rarely to simply refuse or to quietly provide a non-answer; it is to directly and respectfully address the discrepancy in the response, pointing precisely to where the information already exists in the submission, or explaining the scientific or regulatory basis for why the requested data is not applicable. Reviewers are working through a large submission and can miss something that was already addressed; a clear, well-cited correction is a normal and professional part of this process, not a confrontational one. What does not work well is silence or evasion on a point the reviewer clearly cares about, since that reliably produces a second, more pointed request.
Keeping a Clean Internal Record
Every information request and every response should be logged in a way that a colleague could reconstruct months later without asking you directly: the date the request was received, the date each internal draft was requested and returned, the date the final response was submitted, and a brief note on any judgment call made about scope. This is not bureaucratic overhead for its own sake. Regulatory affairs teams turn over, submissions sometimes take unexpected turns that require revisiting an earlier response, and an inspector or auditor reviewing the submission history later has no patience for a team that cannot clearly explain why a particular response was scoped the way it was. Building this habit early, even when a submission feels routine, saves real time during the submissions that turn out not to be routine at all.
It is also worth keeping a personal or team-level file of past information requests and how they were handled, organized by topic rather than by submission. Over time, this becomes a genuinely useful internal reference: when a similar question comes up on a different program, having a record of how a comparable request was scoped and answered previously, and whether that approach worked well, is far more useful than starting from a blank page each time. Some of the best regulatory affairs teams treat this kind of institutional memory as a real asset and actively maintain it, rather than letting it live only in the heads of whoever happened to handle the original request.
This record-keeping habit also pays off during training. A newer regulatory affairs specialist learns this craft far faster by reviewing a handful of past requests and their actual responses, side by side, than by reading a general description of best practice. Walking through a real example together, including the parts that had to be revised after an internal reviewer pushed back on scope, teaches the underlying judgment in a way that no checklist fully captures on its own.
Conclusion
Handling an information request well is a specific, learnable skill rather than a generic writing task, and it rewards precision over both defensiveness and over-eagerness to please. Know which regulatory framework governs the clock consequences of your response, read the request carefully enough to separate every discrete question being asked, scope your answer tightly to those questions, and coordinate internally with clear, specific asks rather than vague ones. Done well, this work is largely invisible, since a clean response simply lets the review proceed. Done poorly, it becomes one of the most visible ways a regulatory affairs professional's judgment gets tested under real time pressure.