eCTD Submission Checklist: Evidence and Release Decisions

This checklist is for the submission owner coordinating regulatory affairs, content specialists, publishing and quality. It covers release and delivery control. The actual documents required for an application must come from the applicable regulatory requirements and agreed submission scope.

Set up the record before checking the package

Create one record for an identified application and release candidate. Record the authority and receiving centre, application number, procedure or submission type, new-versus-existing application status, eCTD version, sequence or submission-unit identifier, proposed delivery date, package identifier and responsible submission owner.

For each check ID below, add these writable fields to your tracker: applicability and source; evidence location; named owner; result; reviewer and review date; corrective action; action due date; escalation owner. The tables give suggested roles; replace them with names. Split a row further when different documents or recipients can produce different results.

• Pass: evidence satisfies the stated condition for the identified package and scope.
• Fail: inspected evidence shows that the condition is not satisfied. Record the defect and corrective action.
• Unknown: the evidence or applicability decision is missing. Blank, “requested” and “probably complete” belong here.
• Not applicable: the condition does not apply, with a recorded reason and the person who approved that conclusion.

Before transmission, complete applicable preparation checks and resolve failures or unknowns under your release procedure. Delivery checks become assessable after transmission. Keep them pending until the relevant evidence arrives; do not mark them N/A merely because you have not sent the package yet.

Preparation and source-readiness checklist

The following are recommended operating controls. Where a row depends on an authority requirement, attach the exact current source and its applicability. The checklist does not create a new regulatory requirement or authorise an exception to one.

For S01, “accounted for” means present, validly referenced where allowed, or excluded through a documented applicability decision. A file missing from an approved inventory is a failure. An inventory whose completeness nobody has assessed remains unknown. These situations require different corrective actions.

Use the document QC evaluation exercise for source-to-summary discrepancies that a technical package check does not resolve.

Package and release checklist

A report for an earlier build or an interrupted run does not establish T02 for the package you intend to send. If a document changes after review, identify the affected checks and repeat them as needed. Keep the earlier report and the reason for replacement so the release history remains understandable.

T03 requires a disposition, not necessarily an empty report. Determine the significance of each finding from the applicable criterion and evidence. A commercial tool's colour or label does not independently establish the receiving authority's decision.

Delivery and follow-up checklist

Do not treat “sent,” “uploaded,” “received” and “accepted for processing” as synonyms in the tracker. Copy the meaning of the actual message into the evidence record. A delivery-stage pass leaves every unresolved source or package finding open.

For FDA ESG NextGen, ACK1 describes upload; ACK2, where applicable, describes transmission to the centre; ACK3 and ACK4, where applicable, contain the centre's response. The published matrix differentiates centre, submission type and production/test environment. For CDER ECTD production submissions, it lists ACK2 and ACK3, with no ACK4. Its test notes limit industry ACK3 delivery to coordinated UAT when applicable. FDA submission acknowledgements, checked September 14, 2026.

If follow-up creates an agency request, evaluate the question, response and commitment workflow separately from package delivery.

Attach the right authority and version prerequisites

Check applicability before using a technical checklist from another programme. A familiar application name, a publisher's default configuration or a previous successful transfer is insufficient evidence for a different path.

FDA: As of September 14, 2026, v4.0 support applies to new applications. Forward compatibility for existing v3.2.2 applications is not yet available. An amendment to an existing application does not become a new application because the amendment is new. FDA's current eCTD instructions.

For a v3.2.2 submission, FDA's current standards table identifies validation criteria 4.6 with support beginning August 28, 2026, alongside separate technical-conformance, PDF and transmission specifications. The criteria PDF's revision history is dated August 17, 2026. Record both revision and applicable support dates; they answer different questions. FDA v3.2.2 standards and validation criteria 4.6.

EU: For the v3.2.2 route, EMA's November 28, 2025 notice identifies EU Module 1 version 3.1.1 and validation criteria 8.2 as mandatory from December 1, 2025. The optional v4.0 route for new centralised MAAs has separate implementation instructions. Keep the format and procedure together in P01/P02. EU v3.2.2 specifications and EMA v4.0 implementation.

For a submission to EMA, verify its Gateway/Web Client instructions and XML delivery-file requirements. Do not assume that a national-authority route or CESP instructions describe delivery to EMA. EMA eSubmission Gateway and Web Client.

Health Canada: Its electronic-filing index makes format dependent on regulatory activity and links the applicable preparation, validation and enrolment material. Retrieve any required instructions available on request before closing applicability. Verify the eligible transaction route using the Common Electronic Submissions Gateway instructions. Health Canada electronic filing and CESG guidance.

These are starting sources, not a universal configuration table. Retain the relevant document revisions with your release record. If a source lists an effective date as unresolved, or the procedure is outside its scope, keep the affected check unknown until the decision is supported.

Preserve module-specific content checks

ICH M4 organises the CTD; it explicitly does not determine which studies are required. Module 1 is regional, while Modules 2–5 organise summaries, quality, nonclinical and clinical information. A release may update only part of an application's dossier. Avoid treating every possible CTD heading as a document required in every sequence. ICH M4(R4), June 15, 2016, scope and organisation.

Use the following review tasks to expand S01–S03 for your agreed scope. Each task needs its own result when the evidence can differ. These are suggested content checks, not substitutes for the applicable scientific or administrative requirements.

Module 1: confirm the administrative basis

Reconcile the required forms, cover letter, labelling and supporting administrative documents to the selected application and activity. Check the form revision against its current source, the authorisation of any required signature, and consistency of application identifiers and sponsor details.

Do not apply one form, fee category or signature-age rule to every submission. If the administrative reviewer cannot identify the source for a claimed deadline or exemption, record the question for resolution. Keep the detailed Module 1 review linked to the authority-specific checklist rather than copying a different region's section numbers.

Module 2: trace summaries to their supporting content

For each summary included or changed, record the supporting documents and revisions. Reconcile the quality summary with the relevant quality data, and nonclinical and clinical summaries with their source reports. A reviewer should be able to follow a material statement to the source used to approve it.

For example, if a specification changes after the quality summary is approved, reopen the affected summary check. An unchanged summary filename is not evidence that its contents remain aligned. Use the Module 2 summaries guide for a deeper review alongside your submission-specific scope.

Module 3: reconcile the quality data that this release changes

Retain the useful discipline of a batch reconciliation record. Track which batches appear in the relevant batch analyses, stability material and process documentation, then investigate unexpected differences. Different datasets may legitimately include different batches; the check is whether the relationship is explained and the references are accurate.

Review changed specifications against their supporting procedures and any affected summary tables. Confirm that manufacturer information and product descriptions agree across the relevant documents, or that differences have an approved explanation. Assign each discrepancy to the CMC owner rather than asking a publishing operator to decide scientific acceptability. The Module 3 quality guide supports that content review.

Module 4: reconcile nonclinical study identity

For the nonclinical material in scope, compare study identifiers across the inventory, reports, summaries and references. Check that the supplied report revision is the approved one. Where a supporting statement is required, identify its location instead of assuming it is somewhere in the report package.

Treat study metadata as a separate review task from document presence. A report can be present while its study identifier or classification is wrong. Resolve that discrepancy before using it to support summary sign-off.

Module 5: reconcile clinical reports and supporting files

Map each clinical study in scope to its report, supporting files and references in the submitted summaries. Ask the clinical and data owners to confirm the applicable reporting and dataset requirements. Do not infer that a technical publisher has evaluated the study's scientific adequacy.

Where the release includes updated supporting material, confirm which report or summary references change with it. Review omissions against the approved inventory and applicability decision; a generic “not required for this submission type” note is insufficient when the actual activity has not been assessed.

Review technical evidence without overextending it

Identify which checks your validation tool actually ran and which require another source or manual review. FDA's v3.2.2 criteria state that error codes 2–7 are not validated by the commercial product FDA uses. That statement does not establish the capabilities of every commercial validator. Ask your supplier for its documented coverage and retain unresolved checks separately. FDA validation criteria 4.6, introductory notes.

Keep PDF review specific. FDA's PDF specifications cover supported versions, navigation, fonts and security. They also distinguish ordinary document security from the supplied security settings in FDA forms, which should be retained. A blanket instruction to remove every security setting can therefore be wrong. FDA PDF specifications v4.1, September 2016, Version, Security and Fonts.

Similarly, do not carry an old standalone Study Tagging File checkbox into every format. FDA's v4.0 Technical Conformance Guide explains that the submission-unit message includes information previously provided in a separate study-tagging XML file. Select the check appropriate to the format. FDA v4.0 Technical Conformance Guide v1.5, June 2026, section 1.5.1.

The same principle applies to file naming, lifecycle references and integrity checks: use the selected authority/version specification, record what was inspected, and avoid universal values copied from another checklist. Keep the actual validation review distinct from scientific-content sign-off.

Completed example: delivery succeeded, readiness did not

This is a fictional retrospective exercise, not a vendor test or actual submission. Assume a CDER ECTD production submission for a CMC supplement to an existing v3.2.2 NDA. The fictional release candidate is “Willow supplement, build B.” Its approved inventory requires an updated specification PDF. After transmission, a review finds that file missing.

All evidence labels below are invented record names used to demonstrate how to fill the checklist. They are not downloadable artifacts or claims of executed checks. The scenario deliberately includes an improper release so the reader can distinguish the delivery outcome from the unresolved readiness findings.

The example review date is September 14, 2026. All checks apply except D04, whose exclusion is justified below. The release owner is the escalation owner for all failed or unknown items, with escalation recorded that day and corrective-action updates due September 15. These are assumed internal dates, not regulatory deadlines. Pass and N/A rows have no corrective action due; their evidence remains assigned to the stated owner.

Recorded decision: build B has delivery evidence, but its readiness record contains failures and unknowns. The successful upload and ACK2 cannot prove that the missing specification was present or that the summary was correct. Do not backfill those rows as passes.

If the same findings were discovered before transmission, the release owner would hold authorisation under the stated procedure. In this retrospective case, preserve the transmitted package and acknowledgements, assess the content impact, and determine the appropriate corrective action with the responsible regulatory lead. Do not overwrite the archive or send a duplicate merely to make the checklist green.

To reproduce the exercise, change one fact at a time. Add the missing approved specification to a new candidate: S01 can be reassessed, but the changed package needs the affected technical and review checks repeated. Supply the absent centre response: D03 can be assessed from its contents, while the source-content failure remains independent. Change the recipient or submission type: reassess D04 rather than reusing its N/A result.

Close exceptions with evidence and an accountable decision

For a failure, identify the condition that failed, the affected files or records, the corrective owner and the evidence needed for re-review. For an unknown, identify the missing information and who can obtain or decide it. A due date and escalation owner keep “waiting for someone” from becoming an undocumented release decision.

Approve N/A only with a defensible scope reason. “We did not receive it” is not a reason that a required acknowledgement is inapplicable. “The selected centre/type matrix does not require it” may be, if the cited row matches the actual submission.

The person closing an exception must have authority under your process and access to the supporting evidence. Internal approval cannot waive an applicable regulatory requirement. Retain the original finding, the decision and the resulting evidence instead of replacing the history with a final tick.

Begin the checklist while documents and responsibilities are being planned, then revisit it at source handoff, package review, release and delivery. Schedule those reviews around the actual submission dependencies; a fixed twelve-week plan does not fit every amendment, supplement or original application.

Use the tables directly in your own controlled tracker. No separate download is needed. Assyro publishes this checklist and supports FDA eCTD v4.0 workflows; eCTD v3.2.2 is not currently supported by Assyro. For an eligible v4.0 project, bring the completed scope record and unresolved checks to an Assyro demonstration. Keep your existing supported publishing route for work that requires v3.2.2.

The eCTD software proof-of-concept pack turns the same input, exception and evidence discipline into a vendor demonstration.