How the ESIGN Act shapes a self-hosted e-signature deployment
If you run e-signature in-house, you need to show that your signed records hold up under US federal law. ESIGN gives electronic signatures and electronic records legal effect under 15 U.S.C. 7001, but it does not tell you how to prove who signed, how consumers agreed to electronic records, or how long you must keep them. Those choices fall to the implementer. In short, the platform produces the signature and audit evidence, while your organization owns consent handling, document scope and the retention policy. Neither Documenso nor DocuSeal, as open-source projects, makes a deployment compliant on its own, and no product should be described to your auditors as certified for ESIGN.
Start by mapping each document type to the rules that apply to it. ESIGN excludes certain categories, such as some notices and records tied to family law, wills and certain court filings, so confirm the exclusion list against the statute with counsel before you move any template onto the platform. For consumer-facing documents, decide where the consent and disclosure language lives, how the signer's agreement to receive records electronically is captured, and how a signer can request a paper copy. Those are workflow and template decisions, so they belong in your design review, not in a vendor's marketing claims.
Next, define the evidence each signed record must carry. Self-hosted platforms generate audit logs and completion certificates, but you must confirm which events they record (invitation, view, consent, field entry, signature, and any later access), where those logs are stored, who can export them, and whether the signed PDF can be verified outside the application. Documenso's signing options, such as a self-signed .p12 certificate or a key held in a cloud KMS, are documented in its SIGNING.md file, and the certificate choice affects what a third party can check later. Set retention periods with your legal and records team, then confirm the platform can export and preserve records for that full period, including the database and object storage that hold them.
Which ESIGN requirements the platform must meet and how to configure it
This table maps each ESIGN area the signing function must satisfy to the platform behavior it requires and how to configure Documenso or DocuSeal for it. Read each row as a question to answer in your own environment, and treat the configuration column as a starting point for your legal and compliance review rather than a legal conclusion. The main takeaway is that legal effect depends as much on the records and consent workflow you run as on the software itself.
| Requirement area | What the platform must do | How to configure Documenso or DocuSeal |
|---|---|---|
| Legal effect of electronic signatures and records (15 U.S.C. 7001) | Show that a signature or record is not denied effect solely because it is electronic, and that the signer's intent to sign is evident in the workflow | Use a signing flow that requires an explicit signer action on each signature field, keep the signed PDF and completion record together, and document the intent step in your process |
| Consumer consent and disclosure | Where a law requires information to be given in writing, obtain the consumer's affirmative consent to electronic records and disclose the relevant terms before consent | Add a consent and disclosure document as the first signed step in the template, and confirm with counsel how your states and product lines treat consent |
| Excluded document types | Identify documents ESIGN does not cover, such as certain wills, family law records and notices governed by other rules, and route them to wet-ink or another process | Restrict templates by document class, block sending of excluded types through team permissions, and review the exclusion list with counsel before go-live |
| Signing certificates for digital signing | Apply a signature that shows the document has not been altered after signing, using a certificate the organization controls and can explain to an assessor | Documenso documents self-signed .p12 certificates generated with OpenSSL and signing through Google Cloud KMS; confirm which option your key management policy allows and how certificates are rotated |
| Audit trail settings | Record who was sent, opened, signed and completed each document, with timestamps, IP data and the document hash, and keep the trail tied to the signed PDF | Enable and export the completion certificate or audit log for every envelope, confirm which events each edition records, and test that the trail survives a PDF download |
| Database storage (PostgreSQL or MySQL) | Keep audit records and document metadata in a database that is backed up, access controlled and recoverable within your retention commitments | Documenso uses PostgreSQL; DocuSeal defaults to SQLite and supports PostgreSQL or MySQL through DATABASE_URL. Use a production database for records, not the SQLite default |
| Retention of signed PDFs | Keep signed records and their audit evidence for the period your sector and contracts require, and delete them only under a documented policy | Set retention in an external archive or object store linked to the platform, confirm that deleting an envelope does not remove the only copy, and ask the vendor how exports are stored |
| Access control and signer links | Limit who can view signed documents and ensure signer invitation links cannot be used by someone else | Apply role-based team permissions, set link expiry where the edition allows, and confirm SSO requirements, since DocuSeal's free edition lacks SSO |
Which open-source e-signature platforms fit an ESIGN program
Two AGPL-licensed platforms cover most self-hosted signing programs, but their editions, certificate options and supporting services differ in ways that affect ESIGN evidence. The cards below set out what each platform provides, which features sit behind paid editions, and the components you must run around them.
Documenso as the signing core
Documenso is licensed under AGPL-3.0 and can run from Docker, Docker Compose, Railway, Kubernetes or a manual installation, using PostgreSQL as its database. Its README states the code stays open to read, audit, run and fork, which helps your security team review the signing path. Confirm with the vendor which deployment method and version your control environment must support before you choose a topology.
Documenso signing certificates
Documenso needs a signing certificate to apply digital signatures to completed documents. The documented options include a self-signed .p12 certificate generated with OpenSSL and signing through Google Cloud KMS. A self-signed certificate suits internal use but gives a weaker chain of trust for external counterparties, so ask your legal team which certificate the ESIGN evidence file must show. Record how the key is stored and rotated.
DocuSeal and its Section 7(b) terms
DocuSeal is distributed under AGPLv3 with Section 7(b) additional terms, so read the license text before you modify or redistribute the software. Its Docker image runs with SQLite by default, which suits a pilot but not a production audit trail. Plan a move to PostgreSQL or MySQL through the DATABASE_URL variable before go-live, and confirm the current license terms with the vendor.
DocuSeal verification and integration
DocuSeal includes a WYSIWYG PDF form field builder, PDF signature verification, and an API with webhooks. Verification lets a reviewer confirm that a returned PDF has not changed after signing, which supports ESIGN record integrity checks outside the platform. Test the verification step on a file copied out of the system, because an examiner may only have the PDF.
Paid features and edition checks
Several capabilities depend on the edition. DocuSeal's free on-premises edition has no SSO, bulk send or embedded signing, while On-Premises Pro adds them along with white-label branding. Documenso's Teams plan adds API access and embedded signing, and its Enterprise plan covers self-hosted licensing. Ask each vendor in writing which edition includes SSO, audit exports, certificate management and support, and get the answer dated.
PostgreSQL, SMTP and reverse proxy
Both platforms depend on supporting services that you must run and secure. PostgreSQL holds signing records, so it needs backups, encryption and access controls that match your retention policy. An SMTP relay delivers signer invitations and completion notices, and its deliverability decides whether signers receive links at all. A reverse proxy terminates TLS for signer links, so set its certificate and logging standards before any external signer uses the system.
What evidence auditors ask for from a self-hosted signing record
What proves who actually signed a document in a self-hosted system?
The platform records a signer identity and the consent given for that signer, and the evidence is only as strong as the verification step behind it. Auditors look for the email address or verification method tied to each signer, the time the signer accepted electronic delivery and signing, and any identity check the business required before signing. The platform writes these entries to its database, so the database backup and its access controls become part of the evidence. Whether an email link alone is enough for a given matter, or whether a stronger identity check is needed, is a question to settle with your own counsel before rollout.
What should the signed document hash and tamper evidence look like?
Auditors expect the final signed file to be stored unchanged, with a cryptographic hash recorded at completion so anyone can later confirm the file has not been altered. The platform generates the hash and stores the completed PDF in its database or object storage, and the hash should be recorded in the audit trail as well. Confirm with the vendor how the hash is computed, where it is stored, and whether the signed PDF can be re-verified outside the platform, for example with a standard PDF validator. Keep a copy of the hash in a location separate from the platform so it can be checked if the platform is lost.
Which audit trail events does a signing platform need to log?
A usable audit trail records each step in the envelope lifecycle with a timestamp and the source of the event. The usual entries are:
- Document created and sent, with the sender account
- Recipient link opened or document viewed, with IP address and user agent
- Field completed and document signed, with the signer identity
- Document completed, voided or declined, with the reason
The platform's application layer generates these events, and the database stores them. Check that the platform records IP address and time consistently, and that the time source is synchronized, since a timestamp without a trusted clock carries little weight. Confirm the exact fields your matters require with counsel.
How does the platform's certificate support a digitally signed PDF?
Where a platform applies a digital signature to the PDF, the signing certificate is part of the evidence, because it binds the document to the signing identity and shows whether the file changed afterward. Documenso documents options such as a self-signed .p12 certificate generated with OpenSSL or signing through Google Cloud KMS, and auditors will ask which option you chose, who controls the private key, how it is stored, and when it expires. A self-signed certificate proves integrity within your own trust domain but does not establish third-party trust, so ask counsel whether that is sufficient. Record the certificate fingerprint and key custody procedure in your evidence file.
How long should signing records and their exports be retained?
Retention periods come from the law and regulation that governs each document type, not from the software, so the platform must make retention achievable rather than set the period. Some regulated broker-dealer communications, for example, must be preserved for not less than three years under SEC Rule 17a-4(b)(4), which shows how a single rule can set the floor. Confirm the retention schedule per document class with counsel, then test whether the platform can keep completed envelopes, audit trails and exports for that period, and whether deletion is logged. Export logs should show who exported what, when, and to where.
Which logs show who accessed the signing platform itself?
Access logs show who reached the platform and the documents in it, and auditors often test this separately from the signing trail. The reverse proxy records inbound requests, source addresses and TLS details, the application records logins, role changes and document views by internal users, and the database records administrative queries if auditing is enabled. Forward these logs to a SIEM so that they are retained and cannot be edited by administrators of the signing platform. Confirm with your security team which logs your monitoring design already collects, and whether the signing platform has to be in scope for them.
Which component produces each piece of signing evidence?
Each evidence item comes from a different layer, so the evidence map should name the owner of each one:
- The platform produces the signed document, its hash, the audit trail events and the export records
- The database stores envelopes, signer records and the audit rows, and its backups define what survives a failure
- The mail relay delivers signing invitations and reminders, and its logs show whether a notice was accepted or bounced
- The reverse proxy logs requests, and the SIEM retains and correlates them
The signer's email delivery log matters because a signer who never received the link is a common dispute. Document this map in your compliance file before the first live signature.
Who should confirm which signing evidence a matter requires?
Your own counsel should decide which evidence items a given matter requires, because the answer depends on the document type, the jurisdiction, the consumer or business context and the dispute risk. Engineers can build and export every item listed above, but they should not decide legal sufficiency alone. A useful next step is a short written list per document class that names each evidence item, its retention period, its owner and the test that proves it can be produced. An implementation partner can help prepare that record, though the legal conclusions remain with counsel and auditors.
Where consumer consent and excluded documents change the design
When a consumer must receive information in writing, ESIGN allows an electronic record to satisfy that requirement only if the consumer has affirmatively consented to electronic delivery. The consent request has to come before the consumer agrees to anything else, and it must disclose the consumer's right to a paper copy, the right to withdraw consent and what withdrawal means, the scope of the consent, how to update an email address, and the hardware and software needed to open the records. In a self-hosted workflow, build this as a separate consent step ahead of the signing step in Documenso or DocuSeal, and store the disclosure text, its version identifier, the signer's identity and a timestamp in your own audit records. Have counsel approve the exact wording before the first send.
Consent also has to work after it is given. Plan a paper copy path for each consumer transaction, whether that is a downloadable PDF with a clear way to request mailed copies, and document who fulfills those requests and how fast. Withdrawal needs its own workflow: when a consumer withdraws, the platform should stop routing future electronic records to that person for the covered transactions, the withdrawal should be logged with a timestamp, and staff should see the change before the next envelope is sent. Confirm with counsel whether a withdrawal affects only future documents or also records already delivered, and whether any state law adds requirements that ESIGN does not.
ESIGN excludes several categories from its general rule, including wills and codicils, most family law documents, court orders and notices, utility cancellation notices, foreclosure, eviction and repossession notices for a primary residence, notices of cancellation of health or life insurance benefits, product recall notices, and certain hazardous materials documents. Those documents must follow paper or another legal rule. Build an exclusion check into the template library: each template carries a document type field, sending is blocked for excluded types, and a named reviewer clears any template that falls near a boundary. Ask counsel to confirm the exclusion list against the current statute and any applicable state rules before you encode it.
What the signing platform alone does not satisfy
A self-hosted signing platform produces signatures and logs, but legal effect, identity strength, key custody and record durability depend on decisions outside the software. Each card names who owns the gap and what to confirm before go-live.
Consent language and document scope
ESIGN requires consumer consent and disclosures in specific cases, and it excludes certain document types from its general rule. The platform can present consent screens, but counsel must decide the wording, which documents route through electronic signing, and which must stay on paper. Owner: counsel, with the client's compliance lead. Confirm the consent text, the list of excluded document types, and where each version of the consent is stored with the signed record.
Retention schedules and legal holds
Signed records must remain retrievable for the period each regulator or contract requires, and that period differs by record type. Deletion, archiving and legal hold rules are configured by the client, not by the signing product. Owner: the client's records team, reviewed by counsel. Confirm the retention schedule per document class, who can place a hold, and how a hold stops automated purges in the database and file store.
Identity verification beyond email
Most signing workflows confirm a signer by an emailed link, which proves control of an inbox rather than who signed. Stronger methods such as knowledge-based checks, ID document review or government credentials add cost and friction and may need a third-party provider. Owner: the client's risk team, with the implementation partner wiring the chosen method into the signing flow. Confirm which assurance level each document class needs and whether the platform's logs record the method used.
Signing certificate governance and key management
A digital signature on a PDF depends on a signing certificate, and that certificate's private key must be generated, stored and rotated under documented control. A self-signed certificate proves integrity but carries no third-party trust, while a key held in a cloud key service moves custody outside the data center. Owner: the client's security team, with the implementation partner configuring the signer. Confirm who issues the certificate, where the key lives, the rotation and revocation procedure, and who may sign on the organization's behalf.
Audit trail validation for disputes
The platform records events such as views, field entries and completions, but a dispute turns on whether those logs are complete, unaltered and explainable to a third party. Validation means testing that the log captures each event, that timestamps come from a trusted source, and that an exported record can be verified outside the system. Owner: the implementation partner runs the test plan, and counsel reviews the evidence package. Confirm the export format, the time source, and whether logs are protected from edits by administrators.
Backups and disaster recovery for signed records
A self-hosted platform keeps signed PDFs, audit events and signing certificates in its own database and storage, so losing any one of them can break the evidence chain. Backups must cover all three together and be restored in a test, because a backup that restores the PDF but not the matching log has limited value. Owner: the implementation partner designs and tests the backup set, and the client owns recovery targets. Confirm backup frequency, encryption, off-site copies, and a documented restore test.
Questions buyers ask about ESIGN and self-hosted signing
Does self-hosting change the legal effect of an e-signature under ESIGN?
No. Where the ESIGN Act applies, a signature or record is not denied legal effect solely because it is electronic, and the hosting location does not change that rule. What matters is whether the signer intended to sign, whether the signer consented to electronic records where consumer disclosures are required, and whether the signed record can be retained and reproduced accurately. A self-hosted platform has to produce evidence for each of those points: an audit trail showing who signed, when, from where and against which document version, plus a retained copy of the final record. Ask your counsel to confirm how the ESIGN consent and disclosure steps map to your signing flow, and which document types fall outside the Act and need a different process.
What does an open-source e-signature implementation cost, and what drives it?
The software license is only one line. Documenso and DocuSeal both publish free self-hosted editions, while their paid tiers add features such as SSO, bulk send, white-labeling and embedded signing. The DocuSeal pricing page, as read in October 2026, lists On-Premises Pro at $240 per user per year, and Documenso lists Enterprise pricing on request for self-hosted setups. Other costs are one-time or recurring: infrastructure, signing certificate setup, integrations with your systems of record, validation of templates and approval workflows, and ongoing support and upgrades. Costs rise with the number of integrations, the number of signing templates, and how much evidence design your compliance team needs. Ask any implementation partner for a quote built from a written scope, and confirm current edition prices with the vendor.
How long does a self-hosted signing rollout take?
The duration depends on the scope, and no fixed timeline applies to every organization. The main variables are the number of document types, whether identity checks happen before signing, how many systems the signing flow must connect to, how many approvals your counsel and compliance teams need before go-live, and whether signing certificates must be arranged through your own certificate authority or a cloud key service. Simple templates on a single identity provider move faster than multi-department workflows with EHR, CRM or ERP integrations. DeployOpen agrees timelines, deliverables and acceptance criteria in writing before work starts, so ask for a scope-based schedule rather than a generic estimate.
What must our team provide before an implementation starts?
Start with a document inventory: every form, agreement and notice that will be signed, with its owner, version history and the law or policy that governs it. Counsel should review which documents fall under ESIGN, which are excluded, and what consumer consent and disclosure text must appear before signing. You also need signer lists by group, identity verification rules, and retention periods for each record type, since those periods come from your own legal and regulatory obligations. Finally, name the systems the signing flow must read from or write to, and the people who will approve templates and access to signed records. Missing inputs are the most common cause of rework, so settle them before scoping begins.
Can our internal team deploy and run self-hosted e-signature alone?
A capable platform team can deploy simple workflows alone. Documenso supports Docker, Docker Compose, Railway, Kubernetes and manual installation, and DocuSeal runs from its Docker image with SQLite by default or PostgreSQL or MySQL through the DATABASE_URL variable. Most teams can stand up a test instance and a few templates in-house. Partner help becomes valuable when you need a signing certificate chain that your relying parties trust, evidence design that your auditors will accept, integrations with production systems, template validation, and backup, upgrade and monitoring practices. Those last items are where DeployOpen typically works, under a fixed-scope agreement or an ongoing support retainer.
Which e-signature pricing and compliance figures should we confirm with vendors?
Confirm every figure against the vendor's current page before you budget, because pricing changes. The Documenso pricing page, as read in October 2026, lists Free with 5 documents per month, Individual at $25 per month, Teams at $40 per month for 5 users plus $8 per extra user, and Platform at $250 per month. It also lists the ESIGN Act, UETA, 21 CFR Part 11, SOC 2 and HIPAA among its compliance references without tying them to plans, so ask the vendor what each reference covers in writing. The DocuSeal pricing page lists On-Premises Pro at $240 per user per year and API or embedding usage at $0.20 per completion on its cloud plans. Also confirm the current release each vendor supports: Documenso v2.20.0 and DocuSeal 3.3.2 were the latest versions published in the researched facts.
What evidence should a self-hosted signing audit trail contain?
A usable audit trail records the document identifier and version, each signer's identity method, timestamps for sending, viewing and completion, the IP address and device details where your policy allows, the final hash of the sealed document, and any changes made after sending. Under the ESIGN framework, you also need to retain the record in a form that stays accurate and accessible for its retention period. Keep access logs for the signing platform itself, since they show who viewed signed documents. Confirm with your counsel whether the evidence meets your evidentiary needs, and ask any partner to demonstrate how a signed PDF is verified outside the platform.
What to decide before you deploy a signing platform
Settle the document inventory before you choose a platform, because ESIGN does not treat every record the same way. Under 15 U.S.C. 7001, a signature or record cannot be denied legal effect solely because it is electronic, but the statute excludes certain categories, including wills and codicils, most family law documents, court orders and notices of cancellation of utility services, health insurance or life insurance, and notices of product recall or repossession risk for a primary residence. Have counsel mark each template as signable electronically, signable with a stated exception, or kept on paper. Also decide which state uniform electronic transactions law applies to each signer, since it sets the consent rules that ESIGN also relies on.
Next, assign owners for three artifacts that a self-hosted platform cannot decide for you. The first is the consumer consent and disclosure text, which counsel should approve in the form it will be shown to signers, along with the rules for withdrawing consent and requesting paper copies. The second is the signing certificate approach. Documenso documents a self-signed .p12 certificate generated with OpenSSL and signing through Google Cloud KMS, and DocuSeal verifies PDF signatures, so you must decide who issues the certificate, where its private key lives, and how a reviewer outside your environment will validate the result. The third is the audit trail field list, covering signer identity inputs, timestamps, IP address, user agent, document hash and every view, send and edit event, which your security team should confirm against what the chosen edition records.
Finally, set the retention periods with counsel and record who may approve later changes to templates, field definitions, retention rules and certificates. Treat the retention schedule as a legal input, not an engineering default, because it determines how long audit logs and signed PDFs must remain readable and whether they sit under legal hold. Before implementation starts, work through the full list in the e-signature requirements checklist, which covers signature levels, identity checks, templates, API access, SSO and support.
How a fixed-scope ESIGN readiness engagement runs
The sequence moves from agreed document types and consent language to a deployed signing service, tested signer flows and evidence exports, a counsel and auditor review, and a handover the client's own team can run. Scope, deliverables and timelines are agreed in writing before any work starts.
Scope document types and consent language
The client's legal, compliance and business owners list the document types that will be signed, the signer populations for each, and the consent and disclosure wording that applies to consumer signers. DeployOpen maps each document type to the ESIGN requirements it must meet and notes the exclusions that send some records to a different process. The step closes with a written scope that names the documents, signer groups and consent text in scope, which the client approves before work starts.
Deploy the signing platform in the client environment
DeployOpen installs Documenso or DocuSeal in the client's own cloud account, data center or private network, with the database, storage, outbound email and network paths the client's security team has approved. Edition and licensing decisions are confirmed against the agreed scope before installation. The step closes when the application runs in the target environment, is reachable only through the agreed paths, and the client's team has access to the admin console.
Configure signing certificates and audit settings
DeployOpen sets up the signing certificate the platform will use, whether a self-signed certificate generated for internal use or a key held in a cloud key management service, and records who controls the private key. Audit logging, retention settings, access roles and the handling of signer identity data are configured to match the approved design. The step closes with a configuration record that lists each setting, its value and its owner, so the client can show how the evidence is produced.
Test signer flows and evidence exports
DeployOpen runs signer journeys for each document type in scope, including the consent step, invitation delivery, field completion, signing and completion notices. Each run is checked against the audit trail, and the signed PDF is verified with an independent PDF signature validator outside the platform. Evidence exports are produced and reviewed to confirm that the record shows who signed, when, and what was signed. The step closes with a test log that records each case, its result and any defect fixed.
Review with counsel and auditors
The client's counsel reviews the consent language, document scope and the legal basis for each document type, while the client's internal or external auditors review the configuration record, test log and sample evidence packages. DeployOpen answers technical questions and documents changes requested during review. The step closes when counsel and the auditors have recorded their review outcome in writing, and any open points have an owner and a resolution. DeployOpen prepares the evidence; it does not issue an audit opinion or legal conclusion.
Hand over runbooks and training
DeployOpen delivers runbooks covering installation, backup and restore, certificate renewal, user and role management, evidence export and incident response, along with the configuration record and test log. The client's administrators are trained on the procedures they will run day to day. The step closes when the client confirms receipt of the handover package and the admins have completed the agreed walkthrough. Ongoing support, upgrades and testing can be arranged as a separate retainer.
How DeployOpen delivers ESIGN-ready self-hosted signing
DeployOpen plans, implements, hardens, documents and supports self-hosted signing platforms inside your own cloud accounts, data centers or air-gapped networks. For the ESIGN Act, we set up the signing workflow, consent and audit evidence so your team and your auditors can review how each signed record was produced and kept.
How we scope
- Written scope lists which document types, signers and consent flows the platform will cover under ESIGN.
- We document which records must be retained, for how long, and where the signed copies will be stored.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- We deploy Documenso or DocuSeal in your environment with PostgreSQL or MySQL, not the default SQLite, for production records.
- We configure the signing certificate, consent and disclosure screens, and audit trail settings agreed in scope.
- We test signer invitations, completion, certificate verification and exported audit records before go-live.
How we hand over
- You receive configuration documentation, a record of the consent and audit settings, and a retention procedure.
- We prepare evidence packs that show how ESIGN-related controls operate, for review by your compliance team and independent auditors.
- Handover covers administrator training so your staff can run templates, users and exports without us.
How we support
- Ongoing support, upgrades and continuous security testing are available as retainers after handover.
- We review each release of the signing platform and apply upgrades in your environment under the agreed scope.
- Your counsel and compliance team make the legal determinations, and we confirm the platform behaves as documented.

