— Regulatory sciences · CMC

ICH M4Q(R2): What Needs To Be Done And When

By Carina Veloso · February 2026 · 12 min read

Why this revision R2 exists and what it signals

Regulators revised ICH M4Q because the way industry presents CMC information no longer supports how regulators assess risk, manage lifecycle change, or evaluate increasingly complex products. Two signals are clear from the revision.

First, lifecycle expectation is now explicit, not implied. The submission is no longer a snapshot. It is expected to show how process understanding, control strategy, and product performance evolve, and how that evolution is governed.

Second, narrative coherence is now a review tool. Regulators in the agencies are not expected to reconstruct your logic from Module 3. The applicant should present that logic explicitly, in a form that supports scientific and regulatory decision-making.

This aligns with the broader regulatory direction established through ICH Q8 to Q14: reliance on prior knowledge, structured data, platform approaches, and risk-based post-approval change management. M4Q(R2) is the quality module catching up with that reality. It removes the ability to comply by structure without actually integrating the underlying science.

One uncertainty to state upfront: the mid 2027 adoption date for ICH M4Q(R2) is widely expected, but the transition period after adoption has not yet been confirmed by the commission. So, plan for 2027. Do not assume a generous runway beyond it.

What actually changed, in operational terms

The DMCS (Description, Manufacture, Control, Storage) architecture forces a different assembly of information. Product understanding, manufacturing process, and control strategy are not parallel narratives, they are interdependent and should be clearly linked. Development history is no longer a background section; it is part of the evidence base for the control strategy. Platform knowledge, prior knowledge, and comparability are expected to be integrated, not appended.

The operational implication is direct: you cannot compile Module 3 sequentially from functional silos. The structure requires close cross-functional collaboration: process development, analytical, manufacturing, and regulatory must converge on a single, coherent model of the product.

Module 2.3: from summary to regulatory narrative

Under ICH M4Q(R1), experience shows that many applicants treated Module 2.3 as a compressed version of Module 3. That approach is now obsolete.

Under ICH M4Q(R2) Module 2.3 is a standalone narrative that explains the product, process, and control strategy. It is a lifecycle document that must remain valid post-approval, and a review tool for assessors rather than a convenience summary. It should answer questions that most current Module 2.3 documents do not even attempt: What are the critical quality attributes and why? How does the process design ensure they are consistently met? What is the control strategy, and how is it justified? How will changes be managed within the established knowledge space? The capability gap here is significant. Many organisations do not have authors trained to write this type of document. Medical writers are not (yet) equipped for it; CMC scientists are not trained to construct regulatory narratives at this level; regulatory affairs often acts as editor rather than owner of the scientific story.

Integration of ICH Q8–Q14 and QbD implementation

The integration of ICH Q8-Q14 into the structure means that design space, control strategy, and lifecycle management must be visible and coherent; prior knowledge and platform approaches must be substantiated and traceable; and risk management is expected to be embedded, not described.

If Quality by Design (QbD) was implemented as language rather than practice, the inconsistency will be exposed. The DMCS structure does not allow to describe a control strategy without demonstrating the development rationale behind it.

Three gaps to close on the path to ICH M4Q(R2) readiness

Gap 1: Module 2.3 capability needs to be established
In practice, many organisations do not have a defined author role for Module 2.3, do not have governance for maintaining it post-approval, and do not have review standards beyond consistency checks. The result is predictable: Module 2.3 becomes either superficial or internally inconsistent. Under ICH M4Q(R2), both are visible and consequential.

Gap 2: QbD needs to be structurally embedded
Across the industry, critical quality attributes are listed but not always justified, design space is described but not operationalised, and control strategies are defined but barely linked to development data. Under ICH M4Q(R1), this could be managed through narrative flexibility. Under ICH M4Q(R2), the DMCS structure exposes the discontinuities directly, for examples, development data does not support control limits, risk assessments are not reflected in control strategy, platform claims are not substantiated. This is not a documentation issue. It is a scientific and organisational coherence issue.

Gap 3: Data and knowledge need to be structured for reuse
The typical current state: development reports in Word or PDF; analytical data in LIMS, disconnected from submission content; process knowledge distributed across teams and individuals; no single, traceable source of truth. This makes it difficult to assemble a coherent DMCS-compliant Module 3, maintain consistency between Module 2.3 and Module 3, or update submissions efficiently post-approval.

Where ICH M4Q(R2) has the greatest impact

ICH M4Q(R1) applies to all product types. In practice, however, it was structurally better suited to chemically synthesised products, and less effective at representing the science behind more complex product modalities. ICH M4Q(R2) addresses this issue. It places greater emphasis on process–product linkage and the need to integrate comparability, process changes, and lifecycle knowledge. It also increases scrutiny of control strategy justification for biologics.

For advanced therapy medicinal products (ATMPs) and cell and gene therapies (CGTs), variability and limited batch numbers require robust narrative justification. Development knowledge is often sparse, yet it must be structured and defensible. Platform approaches involving viral vectors or mRNA, for example, must be explicitly integrated rather than assumed.

For combination products, the integration of the device and drug domains has to be coherent, and control strategies spanning multiple regulatory paradigms must be presented as a single, intelligible system.

Companies with these product categories in their pipeline or portfolio experience the impact ICH M4Q(R2) the earliest. The structure aligns better with the science, but the underlying knowledge needs to be organised accordingly.

The implementation plan

This is neither a one-quarter exercise nor a template refresh. Depending on the complexity of the portfolio and the readiness of the organisation, expect a process spread over nine to twenty-four months for an effective implementation of ICH M4Q (R2) .

The working framework below is a staged approach intended for CMC, quality and regulatory leaders and team members who are involved in change planning:

Phase 1: Diagnostic (1–3 months)
Select one or two submissions, across different type of products if possible, and map their content against ICH M4Q(R2) expectations: Module 3 against DMCS alignment, and Module 2.3 against narrative completeness and independence. Identify structural gaps, data fragmentation points, and QbD inconsistencies. The output is a gap assessment report, prioritised areas to improve and an initial resourcing estimate. Do not start redesigning templates before understanding how your organisation actually works. Be diligent. The diagnostic is where you find out what gap needs to be solve first.

Phase 2: Template and model redesign (1–3 months)
Redesign Module 3 templates aligned to DMCS structure. Define content ownership clearly: who authors each section, who integrates across functions, and who signs off. Templates should enforce thinking, not just formatting.
TIP: use AI to write the first redesigned templates. You can use EMA’s mock-ups as structural reference.

Phase 3: Capability build (3–6 months, overlapping with phase 2)
Train CMC scientists in regulatory narrative construction. Train regulatory affairs in scientific integration and not just compliance review. If your organisation doesn’t have one yet, consider establishing a “Module 2.3 author role”; best would be someone with a RA/CMC hybrid profile. Develop internal exemplars so teams have something concrete to write against.

Phase 4: Data and infrastructure alignment (6–12 months, parallel)
This phase looks different depending on where your organisation starts. If you are operating with a RIMS, a structured eCMC system, or an integrated CMC data platform, the question is not whether your electronic platform is adequate. Rather, the focus is on ensuring that it is configured to support submissions aligned with ICH M4A(R2), with emphasis on verifying that CQA justifications are traceable to development data, control strategy logic is retrievable and linkable across modules, and the system effectively maintains Module 2.3 as a living document rather than a static file. For organisations at this level, Phase 4 is largely a configuration and governance exercise. For organisations still operating with document-centric models, for example, many pharma companies in Asian and South America, the objective is more fundamental: structured accessibility. Know where your CMC knowledge lives. Be able to retrieve it consistently. Establish linking mechanisms between data and submission content, even if these mechanisms are initially manual. Prioritise CQA justification and control strategy data, as these will carry the most weight upon the implementation of ICH M4Q(R2). Realistically, sponsors will not invest in a full CMC data platform just for R2. This may be a constraint, but it is not a limitation. The objective at this phase is not digital transformation, the focus is organised knowledge. Do not let the “perfect” be the obstacle to the necessary.

Phase 5: Pilot on a real submission (6–9 months)
Select a mid-to-low complexity submission for which active development data is available. Apply the new Module 3 structure. Write Module 2.3 as the primary narrative document, not as a summary, not at last, but as the document that defines what supporting data will go to Module 3. Conduct internal review cycles with focus on scientific coherence rather than regulatory compliance. Simulate health authority questions. Expected and plan for rework, it will happen and should be treated as a positive way to learn and improve.

Using consultants for Module 2.3

It’s reasonable to assume that any decision maker who is not a consultant and reads this article will have to face this topic. Therefore it is introduced here and it gets a direct answer. The case for using a consultant is strongest when timelines are tight and internal capabilities are lacking. For instance, if a company lacks someone who can write a Module 2.3 narrative independently, a specialist can significantly shorten the initial learning curve. This is especially important for complex product types, where internal regulatory writing experience may be limited . Meanwhile, consultants who are working on submissions aligned with ICH M4Q(R2) have developed pattern recognition that most internal teams have not yet acquired.

The case for not using a consultant is equally compelling. While a consultant could write Module 2.3, they would not have all the necessary product knowledge. If the internal team cannot clearly explain the product’s story, neither can a consultant. They will write around the gaps based on the information they receive from the applicant but will not resolve them. Furthermore, lifecycle management cannot be outsourced. Module 2.3 under ICH M4Q(R2) needs to be maintained post-approval. Even if a consultant wrote the original, the internal team has to maintain it, which requires a level of understanding that many externally authored documents lack. Outsourcing does not close the capability gap. It defers it.

The practical approach is to use a consultant for the pilot submission with the explicit intent of building internal capability. For subsequent submissions, the consultant could transition to a coaching and quality review role instead of being the author. This model closes the capability gap instead of working around it indefinitely.

The Now To-Do List

Pre-Phase II products: make sure to establish QbD properly from the beginning. Do not leave it until later. Establish the what, when and how for data collection early on. Define narrative ownership before it is needed.

Phase II to III products: conduct a diagnostic assessment as soon as possible to avoid identifying critical gaps later on. Define priorities, focus on high-value, high-potential products. Start designing the Module 2.3 narrative, before submission-related pressure builds up.

Pre-marketing authorisation submissions: do not attempt a significant transformation within the submission timeline. Instead, focus on narrative consistency and identify weaknesses and risks. Prepare a defensible, data-driven control strategy. QbD requires data, do not list QbD element just to “comply with the guideline”. Experience shows that this will not work with either the EMA or the FDA.

Approved products: use lifecycle updates to align progressively with ICH M4Q(R2). Improve data traceability and control strategy articulation with each variation cycle.

References

ICH M4Q(R2) Draft version, www.ich.org