E-signature RFP questions

If you modify the code and make the modified version available to users over a network, the AGPL-3.0 license generally requires you to offer those users the corresponding source of your changes. Internal use without distributing or offering the modified software to outside users is a different position, and your counsel should confirm how it applies to your deployment. Documenso's license is AGPL-3.0, and DocuSeal is distributed under AGPLv3 with Section 7(b) additional terms, so the partner should read both license texts with you before any customization starts. Ask the partner to list every planned change and classify it by whether it is internal, customer-facing or embedded in your own product.

The answer depends on the edition, so the partner should map each required feature to a named edition in writing before the build starts. For DocuSeal, its README lists Pro features as company logo and white-label, conditional fields and formulas, bulk send from CSV or XLSX, and SSO with SAML. The DocuSeal pricing page states that the free on-premises edition has no SSO, bulk send or embedded signing, while On-Premises Pro adds unlimited bulk send, white-label and embedded signing. For Documenso, its pricing page says the Teams plan adds API access and embedded signing, Platform adds white-labeled embedded signing, and the Part 11 module is Enterprise-only. Confirm current edition contents with each vendor, since pages change.

DocuSeal Pro is a published per-user subscription for on-premises use: the DocuSeal pricing page lists $240 per user per year ($20 per user per month billed annually), plus $0.20 per completion for API and embedding usage on its cloud plans. Documenso's Enterprise plan has custom pricing and is available for cloud or self-hosted setups through its self-hosting page. The difference matters for procurement: DocuSeal's cost scales with named users and completions, while Documenso Enterprise is quoted against scope. Ask each vendor for written terms covering what the license permits on your infrastructure, how upgrades are covered, and whether embedding in your own product requires a specific tier. The partner should compare both quotes against the same feature list and expected completion volume.

No. The Documenso pricing page places its Part 11 capability in the Enterprise tier, so a GxP team should not assume it is available in the free or Teams edition. Enterprise licensing does not make a system compliant with 21 CFR Part 11 by itself. The validation evidence, procedures and any FDA-related assessment remain the organization's responsibility, and DeployOpen prepares systems, controls and evidence for compliance assessments without issuing certifications. Ask the partner to confirm in writing which Part 11 controls the chosen edition provides and which must be built or documented separately.

Track releases against the vendor's published tags and changelogs, and pin every deployment to a specific version. At the time of this writing, the latest release sources we can cite are Documenso v2.20.0, published on October 8, 2026, and DocuSeal 3.3.2, published on October 12, 2026. Your partner should record the version in use, subscribe to release notifications, test each upgrade in a staging environment with a restored copy of the production database, and keep a rollback path. Ask how they handle breaking changes, schema migrations and edition-specific features that may change between releases. Confirm the upgrade process and any fees in your written scope, since upgrades can also be covered by a support retainer.

Choose based on the required feature list, the edition that provides it, and the license terms that apply to your plans. Both products are open source, both offer APIs and webhooks, and both run on PostgreSQL. DocuSeal documents an SQLite default with PostgreSQL or MySQL through DATABASE_URL, and includes a WYSIWYG PDF form field builder and PDF signature verification. Documenso documents Docker, Docker Compose, Kubernetes and manual installation, and a self-signed .p12 or Google Cloud KMS signing option. Score each candidate against your must-have features, then have the partner produce a short written comparison showing which edition each candidate needs. Illustrative example: a team that needs only internal signing with no embedding may need a different edition than a team embedding signing in a customer portal.

A useful mapping lists each requirement, the product and edition that provides it, the source confirming it, and the date the vendor page was read. Include SSO, bulk send, embedded signing, white-label, API access, the Part 11 module, signing certificate options and any per-completion fees. Add a column for what the partner must configure or build, since a feature in an edition may still need integration work. Ask the partner to flag any requirement no current edition covers, and to name the owner of each open item. This document becomes the baseline for the license purchase, the scope of work and the acceptance tests.

DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. As part of a fixed-scope engagement, we can document the edition, license and feature mapping and the upgrade plan in writing before work begins. Licensing terms and vendor purchasing remain between your organization and the vendor, and legal interpretation of AGPL-3.0 obligations should come from your counsel. Ask for the deliverables, the owner of each decision and the timing in the written scope, since DeployOpen does not publish a price list and quotes follow from that scope.

A properly configured setup records each step of the signing process, including who was invited, when each event happened, and what the signer completed. Expect records for document creation, sending, opening, field completion, signing and completion, each with a timestamp. Ask the partner to show a sample audit trail from your own test envelope before go-live, and confirm which IP address and user agent fields the chosen edition stores. Signer identity evidence depends on how you verify people, so define that step in writing before the build starts.

A completion certificate is a summary page or file that the platform attaches to a finished document, listing the signers, event timestamps and a document hash. It is produced by the signing software, not by an outside party. Its evidentiary weight depends on the signing certificate you configure, such as a self-signed .p12 certificate or a key held in a cloud key management service, as described in Documenso's signing documentation. Confirm with your legal team which certificate type they accept for each document class.

Your organization sets retention periods, not the partner or the software vendor. Requirements differ by document type and regulator, so the retention schedule should be written before deployment and mapped to storage locations, backups and deletion jobs. Define how long signed PDFs, audit trails and signer personal data are kept, and whether legal holds can override deletion. Ask the partner to show how retention is enforced in the database, file storage and backup tiers.

Signing evidence supports several technical safeguards in 45 CFR 164.312. The audit controls standard in 164.312(b) requires recording and examining activity in systems that hold ePHI, which maps to the audit trail, application logs and admin access logs. The transmission security standard in 164.312(e)(1) maps to TLS configuration on signer links, email delivery and the reverse proxy. Access control evidence, such as account lists and role assignments, supports the access control standard. Your compliance team must decide how these artifacts are assessed, and an independent auditor, not DeployOpen, issues any assessment.

SEC Rule 17a-4(b)(4) applies to broker-dealers and requires preserving originals of communications received and copies of communications sent relating to the business for not less than three years. Whether a signed agreement falls under that rule depends on your business, your registration status and your counsel's reading, so confirm it before design. If it applies, the signed document, its audit trail and metadata must be preserved in a form you can produce on request, which usually means a write-once or otherwise tamper-evident storage design. Ask the partner what storage and retention controls are in scope.

An independent auditor or certification body issues any audit report, attestation or certification. DeployOpen prepares systems, controls and evidence for those assessments but does not issue them. In practice, the engagement produces configuration records, access reviews, backup and restore results, and an evidence map that your auditor can test. Confirm with your auditor which evidence formats they accept before the build, since requirements vary by framework and assessor.

Audit logs need protection against alteration and deletion by the same administrators they record. Send application and proxy logs to a separate log store with restricted write access, and define who reviews them and how often. Document the review as its own evidence artifact, with reviewer name, date and findings. Confirm the log retention period for each log source, as it may differ from the retention period for signed documents.

Delivery is a shared responsibility. The signing platform generates and sends invitations, but the mail path, sending domain and mailbox reputation are controlled by the organization and its mail provider. Before the rollout, agree in writing who owns the SMTP relay, the DNS zone, bounce monitoring and the response when invitations land in spam. A partner should document each handoff so that a failed invitation can be traced to the platform, the relay or DNS.

Most organizations route invitations through an existing relay, such as a managed SMTP service or the corporate mail gateway, because it already has sending limits, logging and reputation management in place. A dedicated sending server gives isolation from other mail traffic but adds a system to patch and monitor. Ask which option the partner recommends for your volume, whether the relay allows the signing platform's sending address, and who holds the credentials. Either way, confirm that outbound mail uses TLS and that the relay logs each message.

The sending domain needs an SPF record listing the servers allowed to send for it, a DKIM key that the relay or platform signs outbound messages with, and a DMARC policy that tells receivers what to do with mail that fails these checks. Start DMARC in a monitoring mode, review the aggregate reports, and tighten the policy once legitimate senders pass. Your DNS administrator, not the signing platform, usually publishes these records, so ask the partner for the exact values to add and confirm the DNS change window before go-live.

Hard bounces, such as unknown mailboxes, should stop further sends to that address and surface to the sender so a corrected address can be entered. Soft bounces and deferrals are retried by the relay according to its queue settings. Spam complaints should be fed back into suppression lists, because repeated sends to complainers damage the sending domain. Ask the partner which events the platform records, whether bounce webhooks reach your monitoring, and how a signer with a bounced invitation gets a replacement link without a second identity check.

Reminder timing and link expiry are product settings that should follow your signing policy, not default values. Define how many reminders a signer receives, the interval between them, and when an unsigned envelope expires. Shorter expiry improves security for sensitive documents but increases re-send requests. Confirm in the platform's documentation how expired links are reissued, whether the reissued link produces a new audit event, and whether reminders stop automatically after a bounce or a complaint.

A well-run test plan sends invitations from the production sending domain to seed mailboxes at the major mailbox providers your signers use, then checks inbox placement, authentication results in the message headers, and link rendering. The plan should also cover the spam-folder case and a failed-DNS scenario. Ask the partner for the list of test providers, the written acceptance criteria, and whether results are delivered as evidence. Note that no tool can guarantee placement, so the test shows current behavior and should be repeated after DNS or relay changes.

Your team typically supplies the sending domain, DNS access or a change request path, relay credentials or a relay allowlist entry, test mailboxes you control, and a named contact for bounce and complaint reports. You should also provide the list of signer domains that matter most, such as large customer or partner organizations, so the test covers them. Ask the partner to put these inputs in the written scope, with the owner and the due date for each, so that delays in DNS changes do not push back the signing launch unnoticed.

DeployOpen plans, implements, integrates, hardens and documents self-hosted open-source platforms inside your own infrastructure, and those services can include configuring the signing platform's SMTP connection and documenting the DNS records your team must publish. Most engagements are fixed-scope, so the mail configuration, testing and handover should be written into the scope before work starts. Ongoing monitoring of bounces and reputation can be covered by a support retainer if you want it. Confirm which parts of the mail path remain with your mail provider.