eSignature compliance for developers means more than the signature itself being legally valid. eSignatures are legally binding in the US (under ESIGN and UETA), the EU (under eIDAS), and most of the world. But shipping a compliant integration also means handling protected health information correctly under HIPAA, satisfying EU advanced or qualified signature requirements under eIDAS, respecting GDPR data subject rights, and operating on infrastructure that meets SOC 2 controls.
This guide covers what each regulation requires from an integration standpoint and how SignWell handles them, so you can ship compliant eSignature workflows without becoming a regulations expert. A list of all SignWell compliance is available on our Security page.
If you’re building eSignatures into a product that touches healthcare, EU markets, finance, government, or any other regulated space, this post maps the legal requirements to the code you need to write (or, more often, not write).
Who Needs to Think About eSignature Compliance?
If your eSignature workflow touches any of the following, compliance is part of your integration scope:
- Healthcare (US): HIPAA applies to anything that creates, transmits, or stores protected health information
- EU residents or companies: eIDAS governs which eSignature types are recognized for which use cases, and GDPR governs how personal data is handled
- Public sector and government contracts: usually require advanced signature levels and specific audit trails
- Financial services: regulators often require enhanced authentication and retention controls
- Cross-border contracts: multiple regulations may apply simultaneously
If your eSignatures are domestic US, B2B, and not health-related, ESIGN and UETA cover you, and the integration is straightforward. The further you move from that base case, the more compliance you need to think about.
ESIGN and UETA: The US Foundation
The Electronic Signatures in Global and National Commerce Act (ESIGN) and the Uniform Electronic Transactions Act (UETA) are the legal foundation for eSignatures in the US. Together, they make eSignatures legally equivalent to wet signatures for almost all commercial and consumer transactions.
What ESIGN and UETA require for an eSignature to be valid:
- Intent to sign. The signer must intend to sign electronically.
- Consent to do business electronically. The signer must agree to electronic transactions.
- Association of a signature with the record. The signature must be linked to the signed document.
- Record retention. The signed document must be retainable and reproducible.
What this means in practice: SignWell handles all four requirements automatically. The signing flow captures consent, the signature is cryptographically bound to the document, and the audit trail is retained as part of the document record. You don’t have to do anything special in your integration to satisfy ESIGN or UETA.
HIPAA: Signatures Involving Protected Health Information
The Health Insurance Portability and Accountability Act applies whenever your workflow involves protected health information (PHI). Patient consent forms, healthcare provider agreements, business associate agreements, and anything connecting a person’s identity to their health.
For HIPAA compliance, your eSignature provider must:
- Sign a Business Associate Agreement (BAA) with you
- Use encryption in transit and at rest
- Maintain access controls and audit logs
- Handle breach notification obligations
SignWell is HIPAA compliant and signs BAAs with covered entities and business associates. No code changes are needed in your integration to maintain HIPAA compliance, but a few operational practices help:
- Store API keys in a secret manager, not source code
- Use webhook signature verification on every incoming event
- Avoid putting PHI in document names or metadata that might appear in logs
- Use test mode (test_mode: true) in development to avoid creating real PHI in non-production accounts
eIDAS: Signatures in the European Union
The eIDAS Regulation defines three tiers of electronic signatures in the EU, each with different legal weight:
- Simple Electronic Signature (SES): the basic tier, equivalent to most US eSignatures
- Advanced Electronic Signature (AdES): uniquely linked to the signer, capable of identifying them, and using signature creation data they control
- Qualified Electronic Signature (QES): an AdES created by a qualified signature creation device and based on a qualified certificate
For most B2B contracts, an SES is sufficient. For contracts that need to withstand challenges in EU courts, in regulated industries, or in specific public-sector use cases, AdES or QES may be required.
What this means in practice: SignWell’s standard signature flow produces signatures that meet SES under eIDAS. For QES-level signatures, talk to your legal team about what the use case requires and whether additional integration with a trust service provider is needed.
GDPR: Personal Data in the eSignature Flow
The General Data Protection Regulation governs how personal data of EU residents is collected, processed, and stored. eSignature workflows handle personal data by definition (names, email addresses, IP addresses, signature events), so GDPR applies whenever EU residents are involved.
Key GDPR considerations for eSignature integrations:
- Lawful basis for processing. Document why you’re processing the recipient’s data (typically contract performance or legitimate interest).
- Data subject rights. Recipients can request access to, deletion of, or correction of their data.
- Cross-border transfers. If data leaves the EU, you need a transfer mechanism (e.g., Standard Contractual Clauses, an adequacy decision).
- Data Processing Agreement (DPA). Sign one with your eSignature provider.
SignWell is GDPR compliant and provides DPAs to customers operating in the EU. Your integration should ensure you’re not collecting more recipient data than the eSignature flow requires, and that you have a documented process for handling data subject requests.
SOC 2 Type II: Operational Security
SOC 2 isn’t a regulation; it’s an audit framework that demonstrates a company’s controls around security, availability, processing integrity, confidentiality, and privacy. Type II reports cover an extended period (typically 12 months) and are required by most enterprise procurement teams.
SignWell holds SOC 2 Type II (Security, Availability, and Confidentiality) certification. The report is available upon request. Most enterprise procurement reviews of an eSignature provider will ask for this report.
What to Actually Build for eSignature Compliance
The good news for developers: a compliant eSignature integration looks almost identical to a non-compliant one if you pick a compliant provider. Most of what eSignature compliance for developers requires is operational rather than code-level.
What you do need to build into your integration:
- Secret management. API keys in a secret manager, separate keys per environment.
- Webhook signature verification. Verify the HMAC on every incoming webhook event before trusting the payload.
- Audit logging. Log every API call your application makes (request ID, status, duration). This becomes part of your own compliance audit trail.
- Data minimization. Only send the recipient data the signing flow actually needs. Don’t pad documents or metadata with extra PHI or PII.
- Test mode in non-production. Use test_mode: true everywhere except production to avoid creating real signed documents in dev environments.
Final Thoughts
eSignature compliance for developers comes down to choosing a provider with the right certifications and following a small set of operational practices: secret management, webhook verification, audit logging, data minimization, and test mode in non-production environments.
If you’re building on SignWell, the security and compliance work is already done. Your job is to integrate carefully and document your own controls.
