Choosing an EDMS Before a First IND

For a small biotech preparing its first U.S. commercial IND, choose an EDMS around approved source documents, external contributors and the handoff to publishing. Establish who owns the content, which revision is released, and how your publisher receives that revision before buying a broader platform.

Our first recommendation to evaluate is Assyro when the proposed scope matches a new FDA eCTD 4.0 pathway and the required document workflow can be demonstrated. Assyro publishes this guide; that placement is our editorial choice, not an independent test result. Assyro's confirmed eCTD scope for this evaluation is 4.0. A present requirement for 3.2.2 publishing needs another verified publishing route.

This is a documentary shortlist for an early biotech with a first human drug or biologic commercial IND, not a ranking of every EDMS or a guide to investigator-sponsored noncommercial submissions. Public sources were rechecked on October 6, 2026. We have not run comparative product trials or obtained comparable private quotes.

Four options to evaluate against a first-IND workflow

The shortlist includes applications that address regulatory source documents or a related submission workspace. They are not interchangeable bundles. Use the exact application names when requesting a quote.

The application boundaries above come from Assyro's document-management offering, Veeva's Basics catalog, Ennov's Regulatory suite and Montrium's RegDocs Connect features. The profiles below explain what those descriptions establish and what remains a buying decision.

Set the submission route before selecting the repository

“First IND” does not by itself tell a vendor whether the application is commercial, which FDA center is involved, or who will publish it. Record those facts in the evaluation brief.

FDA's September 2024 eCTD guidance, Revision 8, includes commercial INDs within the eCTD submission requirements, subject to applicable exceptions or waivers. It exempts submissions to noncommercial INDs, defining that category by a product not intended for commercial distribution and including research and investigator-sponsored INDs. A company having no sales yet does not establish this exemption. Confirm the application's classification rather than inferring it from company size. See the FDA guidance, sections III.B and III.C.

As checked on October 6, 2026, FDA lists both eCTD 3.2.2 and 4.0 as supported versions. New applications can use 4.0; FDA's implementation page says forward compatibility for existing 3.2.2 applications is a future phase. The fact that your company is filing an application for the first time does not establish that an acquired application's regulatory history is new. See FDA's supported-format page and 4.0 implementation status.

Use three distinct scope statements:

• Document management: author, review, approve, identify and retain the source documents.
• Publishing: assemble the selected eCTD format and manage its technical structure and lifecycle.
• Transmission and follow-up: send through the agreed route, retain acknowledgments, and assign responses to technical or regulatory issues.

An EDMS purchase may cover only the first statement. That can be the right arrangement when a publishing service handles the other work. Write the interface into both contracts: expected files and metadata, release authority, revision cutoffs, rework responsibility, returned output and archive ownership.

FDA's current eCTD 4.0 Technical Conformance Guide, June 2026, version 1.5, is a separate technical source from the format guidance. A supplier saying “we support eCTD” should identify the actual version, regional configuration and workflow being offered. A technical check result also does not establish that the IND's scientific content supports proceeding with the proposed investigation.

1. Assyro: evaluate a focused source-to-submission workspace

Assyro belongs first on our evaluation list for a small team seeking to connect its regulatory documents with submission preparation. The public document-management page describes a controlled repository with version history and review/approval tracking. Treat those descriptions as the starting scope for a demonstration, then confirm the exact deployed features and contractual responsibilities for your use.

The strongest evaluation case here is a new FDA application using eCTD 4.0, with a clear document owner and a bounded initial workload. Bring one representative CMC document, a nonclinical report and a protocol-related document. Ask the team to show how the selected approved revisions are identified and handed to the agreed next step. Require evidence from the offered configuration, not a proposed roadmap.

The limit is consequential: do not buy Assyro on an assumption of currently supported 3.2.2 publishing. If an existing application or chosen publishing operation requires 3.2.2, keep a verified compatible publisher in the design and separately assess whether the source-document workflow fits. Do not infer complete QMS, training management or eTMF capability from an EDMS demonstration either.

For an AI-assisted authoring evaluation, include a source passage that does not support a requested conclusion. The operator should show how the team notices and corrects unsupported text before approval. That is a proposed acceptance exercise, not a claim that this guide has tested Assyro's output. Scientific authors and reviewers still need an explicit responsibility in the workflow.

The buying decision should end with a written scope: current application and version support, supported inputs/outputs, review controls, onboarding work, evidence to retain and responsibility for any external publishing or transmission step. If that scope matches, Assyro is our suggested starting discussion. If a mandatory item remains unknown, keep the decision open until demonstrated.

2. Veeva Submissions Basics: evaluate a standardized starting model

Veeva's Basics catalog presents preconfigured applications for emerging biotechs. Submissions Basics addresses planning, collaborative authoring, review and approval of regulatory documents. The same catalog lists Submissions Publishing Basics and Submissions Archive Basics separately. That distinction matters when a quote is casually described as “Veeva RIM.” See the current Basics catalog.

This is a useful candidate when the biotech prefers adopting an established application configuration to designing a highly tailored document model. Start the demonstration with your actual contributors: internal CMC, an external nonclinical writer and a regulatory consultant. Ask who can work directly in the application, which licenses they need and how review proceeds when a contributor is outside the organization.

The practical tradeoff is the fit between the standardized model and your operating process. A lean team may benefit from limiting configuration decisions, but it still has to assign owners, prepare documents and make the release process work. Do not assume “preconfigured” eliminates sponsor work. Likewise, a supplier validation package is an input to your assurance process; obtain agreement on the intended use, configuration and responsibilities.

For the first IND, request two separately scoped proposals if appropriate: Submissions Basics with an external publisher, and Submissions Basics with the publishing and archive applications you actually require. Have the supplier identify the current supported eCTD version and licensing in each proposal. This guide does not infer version support from the application name.

The decisive exercise is a released document being assembled into the chosen submission route, then a corrected revision arriving after the first handoff. Identify which application receives the correction, who decides whether it enters the package, and where the final published output is retained. If the answer crosses applications, those applications and services belong in the implementation plan and quote.

3. Ennov Regulatory Documents: evaluate configurable regulatory source control

Ennov Regulatory Documents is the relevant application for this shortlist; it should not be confused with Ennov Quality Documents or the entire Ennov platform. Its current page describes a metadata-based document model, configurable lifecycles and a document inventory aligned with the DIA EDM Reference Model. It also describes revision control, document relationships, automatic PDF rendering and Microsoft 365/Google Drive connectivity. See Ennov Regulatory Documents.

This makes it a candidate for a biotech that needs a defined structure spanning CMC, clinical and nonclinical source content, with room to adapt document types or approval paths. The first discussion should be about what can remain standard. Ask the implementation team to configure only the first program's necessary document classes and demonstrate how an administrator maintains them afterward.

Configuration flexibility creates decisions. Who controls the metadata vocabulary? Can the consultant create a new document type, or only use approved ones? Who checks a rendered PDF against a complex source report? Those are proposed buyer questions arising from the described model, not claims of a product deficiency. A first-IND project benefits from resolving them before a large legacy import.

Ennov's suite distinguishes Regulatory Documents from Ennov Dossier, its submission-publishing application, and from broader regulatory information management. Ask for the scope of each rather than treating a suite diagram as proof that all modules are licensed or configured. The suite overview establishes these separate application roles, not your project price or current publisher compatibility.

Use a document with repeated report components in the demonstration. Check how the source relationships remain understandable after PDF rendering and transfer to your publisher. Ask for the returned file and metadata package as well as the in-application view. Choose this route when the agreed configuration and administration effort fit the available team, not merely because the configurable feature list is longer.

4. Montrium RegDocs Connect: evaluate document planning with an external publisher

Montrium positions RegDocs Connect for lean regulatory teams. The product page describes Word-integrated template management, document review/approval workflows, content planning and correspondence/commitment management. Its features page lists submission plans, document indexes, ZIP/Excel export and export to eCTD publishers. See RegDocs Connect and its document and submission features.

That combination makes it worth evaluating when a sponsor wants to own its regulatory source content while continuing to use a specialist publishing partner. The operational question is whether both parties agree on what the exported content means. A ZIP of files can be a useful handoff without being a complete, technically valid eCTD submission.

Have the actual proposed publisher inspect a small export. Can it identify the intended document revision, destination and release status without asking the sponsor to reconstruct everything in email? If a report is replaced, can the two teams distinguish a document correction from an instruction to change the submission lifecycle? Record the answers before treating “export to publishers” as an implemented integration.

The tradeoff is a deliberately shared workflow. It can preserve specialist publishing expertise, but the sponsor still needs a receiving contact, handoff checks and ownership of rejected or incomplete packages. Ask which product functions, service hours and migration tasks are in the proposal. Montrium offers implementation services, but the existence of a service offering does not establish that all work is included in your subscription. See Montrium's implementation services.

Do not extend RegDocs Connect's inclusion here into a claim that every Montrium application is needed before the IND. Its clinical and quality products are separate evaluation decisions. The concrete purchase outcome should be a usable source-document and planning workflow with a demonstrated publisher interface, not an unexamined platform bundle.

Minimum requirements for a first-IND evaluation

Use this matrix as a starting artifact, then change its must-have decisions to match the approved project scope. It is an editorial procurement tool, not an FDA-mandated checklist or a complete validation protocol.

Create a response sheet with these columns: candidate/application; requirement ID; must-have; evidence location; result; owner; open action; due date. Record results as Pass, Fail, Unknown or Not applicable. A must-have marked Fail excludes the proposed scope; Unknown blocks selection until resolved. Not applicable requires a named owner's reason, such as publishing being separately contracted. Do not assign positive points to an unanswered item.

For each test, identify the evidence that would cause a failure before the demo starts. R1 fails if “approved” resolves to an unapproved later draft. R2 fails if the consultant can access the other program. R3 is Unknown if the receiving publisher has not examined the handoff. A slide showing a capability does not satisfy a test that calls for an observed role or exported artifact.

The document set should reflect the first IND's scientific work. FDA describes the application in terms including pharmacology/toxicology, manufacturing information and clinical protocols/investigator information. Use representative content from your actual development program rather than assuming a software template establishes all required evidence. See FDA's IND overview. Our IND application guide provides additional planning context.

A completed response example and a changed requirement

Consider a fictional biotech, Cedar Bio, preparing a genuinely new commercial IND. It proposes a 4.0 publishing route, and its internal owner Maya releases CMC-014 revision 2. The source system also contains revision 3 as an unfinished draft. An external publisher is responsible for assembly and transmission under a separate contract; its precise capabilities still need verification.

This example has no winning product yet. R4 blocks selection, even though three controls passed. R5 also shows why a successful software evaluation cannot be reported as IND readiness: the system correctly exposes work that the development team still needs to complete.

Extend Cedar's packet with two short fictional records: REL-01: Maya authorizes CMC-014 revision 2 for handoff H-01 at 13:00 UTC; APR-03: revision 3 receives document approval at 14:00 UTC. Neither record authorizes replacing H-01. A publisher who automatically pulls the latest approved document would therefore fail this exercise's release-control requirement, even though revision 3 is no longer a draft.

The correct response is to pause the proposed substitution and ask the IND release owner whether revision 3 should enter this package. If authorized, create a traceable amended handoff identifying the replacement revision, the approving owner and the publisher's receiving confirmation. If no release decision is available, the correction stays Unknown/Hold; retain H-01 as the recorded prior instruction without assuming that the package is ready to send. This distinction between document approval and release for a particular submission makes late corrections manageable without erasing what each party previously received.

Now change one input. Cedar acquires an existing application maintained in 3.2.2 and requires continuity in that format. Assyro cannot be assumed to satisfy that publishing requirement. Reopen R4, require a verified 3.2.2 route, and revisit the handoff. Do not rename the application “new” because the sponsor changed. A document-management application could remain suitable alongside a different publisher, but the complete scope must be reevaluated.

Keep the first implementation proportionate to the filing

Start with the source set needed for the current program and a small number of clearly owned document classes. Import a representative sample before committing to a full migration. Reconcile its count, identities, revisions, relationships and access. An unexplained count difference should produce an exception list, not an assumption that the missing files were duplicates.

Keep approved material distinguishable from working drafts during cutover. Agree where new edits occur, who closes the old editing path and how late corrections are handled. If the submission deadline leaves too little time to test a new workflow, evaluate a bounded initial deployment or retain the established controlled process for that filing. A broad migration during final assembly is a separate operational risk decision.

Budget for internal ownership as well as software. Compare equivalent users, external contributors, programs, storage, migration, supplier support, publishing services, training, assurance work and export arrangements. Ask suppliers to mark services as included, separately priced or unresolved. An unknown fee is not zero, and an included service should not be added again. The eCTD software cost guide expands that quote comparison.

The first-IND decision is ready when the team has an agreed format route, demonstrated source controls, an accepted publisher handoff and owners for unresolved scientific work. Begin an eligible Assyro evaluation with those requirements through a workflow discussion, and apply the same matrix to every other candidate. Select the scope that passes the must-haves; keep submission acceptance and permission to begin the clinical investigation as separate regulatory outcomes.