Quick Answer
An eCTD software RFP should specify the authority, application lifecycle, technical versions and operating responsibilities the buyer needs. Require a demonstrated output and evidence record for every mandatory requirement. Use the worksheets below to connect user requirements to compatibility, validation documentation, API behavior, deadline support and recovery. Compare preferences only after required capabilities are established; an unanswered item remains unresolved.
Resource format: This Assyro workbook, version 1.0 dated September 14, 2026, is provided as copy-ready tables in the article. Copy the sections into your procurement document or spreadsheet and replace bracketed fields. It is an editorial procurement resource, not an official agency form, certified validation package or executed vendor assessment. All numerical examples are fictional. No download or registration is required.
Download the editable eCTD RFP templates
Use the Word template for the written request and the Excel workbook for scope, requirements, supplier evidence, support and integrations. Both preserve unresolved requirements and space for the offered product, evidence and buyer decision. The inline version remains available below; add application-specific requirements before issuing the RFP.
Download the editable workbook (XLSX)
Download the procurement template (DOCX)
1. State the exact scope of supply
Complete one scope record for each materially different application or operating arrangement. A new application and an established submission history can create different requirements even within one authority.
| Scope field | Buyer entry |
|---|---|
| Authority and application | [Authority, application type and relevant procedure] |
| Starting lifecycle | [New application or existing history, including current technical version] |
| Required operations | [Preparation, validation, publishing, viewing, transmission, archive; assign each owner] |
| Technical baseline | [Applicable specifications, controlled vocabularies, validation criteria and dates] |
| Users and clients | [Internal roles, external reviewers, separately controlled clients/programs] |
| Deployment and connections | [Environment, repositories, required APIs and customer-managed components] |
| Evaluation output | [Representative package, report, record export and receiving reviewer] |
| Commercial scenario | [Users, programs, expected work, term, currency and included services] |
FDA maintains distinct standards resources for eCTD v4.0 and eCTD v3.2.2. The listed documents and implementation dates are inputs to the compatibility record; a generic “supports FDA” answer does not identify the configuration being offered.
For other authorities, use their applicable current documents and dates. Do not infer regional support from another market's successful demonstration. Agree who checks changes to the baseline during procurement and before production use.
Use the product-and-edition comparison sheet to name the actual components in each supplier’s proposal.
2. Build the user requirements specification
A user requirements specification, or URS, describes what the intended users must be able to do. Keep the requirement separate from the vendor's proposed implementation. The following rows are a starting set to adapt with the responsible users and quality team.
| ID | User requirement | Observable acceptance evidence | Priority and owner |
|---|---|---|---|
| U01 | Publish the defined application activity using the agreed technical baseline | Inspect the actual output and version-specific check results | [Mandatory/preference; owner] |
| U02 | Review the relevant existing submission history | Retrieve the agreed prior/current content and explain its lifecycle relationships | [Priority; owner] |
| U03 | Identify and resolve a deliberate technical defect | Retain initial finding, correction and rerun result | [Priority; owner] |
| U04 | Limit each user to authorized client/program content | Test permitted access and prohibited search, direct link and export paths | [Priority; owner] |
| U05 | Trace release to the approved input set | Identify source versions, release decision and resulting package | [Priority; owner] |
| U06 | Retrieve documents and agreed records outside the application | Open the exported files and interpret the supplied history | [Priority; owner] |
| U07 | Recover the agreed service and records after interruption | Observe the recovery scenario and reconcile restored content | [Priority; owner] |
| U08 | Connect required systems without ambiguous duplicate actions | Demonstrate the specified API or handoff behavior | [Priority; owner] |
Split rows when separate behaviors can reach different results. For example, a viewer that retrieves prior files may still fail to explain their lifecycle relationship. If both are mandatory, record both decisions.
For each vendor response, retain requirement ID, exact product/edition, configuration, availability status, evidence reference, observed limitation, additional cost, buyer disposition and next owner. Allowed dispositions are pass, fail, unresolved, or excluded with an approved reason. A roadmap response does not pass a current-use requirement.
3. Establish compatibility with an application-specific example
Use a permitted representative package with an agreed expected result. Ask the operator to name the standard and rule-set versions used, show the resulting package and retain the report that belongs to that exact output.
FDA's current v4.0 status distinguishes acceptance of new applications from future forward compatibility for existing v3.2.2 applications. Accordingly, a new-application v4.0 demonstration cannot establish maintenance of a legacy application. FDA implementation status.
Record the boundary in the RFP: “The proposed configuration must demonstrate [specified activity] against [specified starting history].” If the vendor needs a conversion, service or alternate product, require that dependency and its evidence explicitly. An authoring workflow can be useful while leaving this publishing requirement unresolved.
Use the eCTD proof-of-concept reference inputs to make the compatibility demonstration repeatable.
4. Request the supplier validation documentation you can use
Ask for documentation tied to the actual supplied version and configuration. A folder labeled “validation package” is not enough to establish its relevance to your intended use.
| Requested evidence | Question for the supplier | Buyer verification |
|---|---|---|
| Scope and version record | Which product, release, environment and functions are covered? | Reconcile with the quoted deployment |
| Requirements-to-test mapping | Which supplied tests address each relevant requirement? | Identify covered and uncovered URS rows |
| Executed evidence | What inputs, expected results and actual outcomes support the claim? | Inspect representative records and exceptions |
| Known limitations and defects | Which open issues affect the intended workflow? | Assign disposition and required mitigation |
| Change and release information | What changes require customer assessment? | Agree notification, impact review and verification ownership |
| Customer work | What configuration and use-specific checks remain with the buyer? | Include the activities and owners in implementation planning |
Keep supplier software assurance separate from validating the technical contents of an eCTD package. They are different evidence questions. Similarly, a passed technical report does not establish scientific adequacy or agency acceptance.
Your quality and regulatory owners should determine the controls and documentation needed for the intended use. This workbook does not prescribe a universal qualification package or assert that a product-page compliance statement meets those needs.
5. Make deadline support terms operational
Define the business event that triggers urgent support. Then distinguish acknowledging a request, beginning investigation, providing a workaround and restoring the required operation. Those commitments can have different clocks and owners.
| Support field | Entry required from the proposal |
|---|---|
| Covered hours | [Time zone, working days, holidays and out-of-hours route] |
| Incident classification | [Observable trigger and who can assign or escalate severity] |
| Response commitment | [What action counts as response and when the clock starts] |
| Restoration or workaround | [Commitment, exclusions and definition of a usable workaround] |
| Escalation | [Named role, contact path and next escalation point] |
| Responsibility at handoff | [Software vendor, infrastructure provider, publisher and sponsor actions] |
| Commercial scope | [Included service, premium coverage and additional charges] |
For a fictional exercise, report a blocked release shortly before the buyer's internal deadline. Ask the vendor to walk through the actual support route. An automated ticket receipt should not be counted as restoration of the publishing operation. A workaround is useful only if your authorized team can use it and verify the result.
These are terms to negotiate for the buyer's circumstances, not universal recommended response times. Record dependencies outside the vendor's control and the sponsor's fallback responsibilities.
6. Test recovery with content and access checks
State the recovery time objective, or RTO, and recovery point objective, or RPO, in the proposal. Define the clock boundaries and which records each objective covers. RTO concerns the agreed time to restore service; RPO concerns the acceptable period of data loss. A backup schedule alone does not prove either outcome.
Use a controlled exercise rather than interrupting production. Include a recent document revision, a review decision and a role change. After restoration, verify the records and permissions as well as the ability to log in.
| Fictional acceptance value | Observation | Disposition |
|---|---|---|
| RTO: 180 minutes, measured from interruption to usable restored service | Interruption 15:20; usable service 17:40: 140 minutes | Meets this time objective |
| RPO: 60 minutes for the agreed record set | Latest complete restored state is 14:10: 70 minutes before interruption | Fails this data-loss objective |
| Required restored permissions | Removed reviewer's access remains blocked | Must be checked separately; timing results do not prove it |
The restoration is not an overall pass. The RPO failure remains even though the RTO succeeds. If files reappear but the associated review record is absent, determine which requirement failed and retain the exception. Do not change the definition of “recovered” after observing the result.
The data-portability acceptance checklist defines which records must remain usable during recovery or contract exit.
7. Specify API behavior without inventing endpoints
An API requirement should name the business operation and expected record, not just ask whether an API exists. Complete one record for each required integration.
| Integration field | Buyer requirement to complete |
|---|---|
| Operation and direction | [System A sends/requests which object from System B] |
| Identity and version | [Stable identifier, source version and authoritative system] |
| Authorization | [Permitted client/program scope and service-account ownership] |
| Duplicate handling | [Expected result when the same request is retried] |
| Conflicting updates | [How a stale version is rejected or routed for reconciliation] |
| Completion evidence | [How the caller distinguishes accepted work from completed work] |
| Failure and recovery | [Error record, retry limits, reconciliation and accountable owner] |
| Limits and maintenance | [Documented quotas, version policy, change notice and support] |
Ask for current documentation and a demonstration of the exact operation. Retry a permitted sample request after an intentionally uncertain response. Verify that the result contains the intended single operation, or a clearly documented duplicate disposition, rather than silently producing conflicting records. Then attempt a request outside the test account's permitted program and confirm the restriction.
A connector logo or successful authentication does not establish upload, publishing or status-retrieval behavior. If an integration relies on services or manual handoff, document the actual arrangement and price it accordingly.
8. Compare preferences after requirements pass
For eligible candidates, an illustrative preference score can use usability 35%, administration effort 25%, support fit 20% and commercial predictability 20%. Agree the definitions and weights before evaluation. These weights are editorial choices, not regulatory requirements.
Rate each dimension from 0 to 4 against agreed evidence: 0 does not meet the preference; 1 has substantial limitations; 2 meets it with material manual effort; 3 meets it with manageable limitations; 4 meets the agreed preference without a material limitation observed in the exercise. Contribution equals weight multiplied by rating divided by 4.
Ratings of 3, 2, 4 and 3 yield 26.25 + 12.5 + 20 + 15 = 73.75/100. That score cannot override the recovery failure in the example. A missing rating leaves the final score unresolved; do not remove the dimension to improve the denominator.
Include licenses, implementation, validation support, migration, integrations, training, recurring administration and exit assistance in the commercial comparison. Record unknown mandatory charges as unknown and compare the same currency, term and workload.
Use the completed scope and URS as the starting point for an Assyro evaluation, our first candidate for connected preparation and submission workflows subject to the same evidence gates. For other candidates, retain the same requirements and demonstration records. The purchase should end with a clear map of what is supplied, what has been verified and which responsibilities remain with your team.
Request Assyro pricing against this scope once mandatory format and workflow requirements are explicit.
About the author
Assyro Team
Expert regulatory operations consultants helping pharmaceutical companies navigate complex compliance challenges.