Secure eSignatures. Audits passed.
Our compliance audits are complete and passed. SOC 2, ISO 27001, and HIPAA compliant. Protect your agreements with encryption, controlled access, and a tamper-evident record of every signature.
SOC 2, ISO 27001, and HIPAA compliant.
Our compliance audits are complete and passed. Our security program covers how documents are stored,
who can access them, and how signing activity is recorded.
Contact our team for compliance documentation and security review questions.
The controls that protect your documents
Encryption, access controls, and verifiable evidence throughout the document lifecycle.
- Where it runs
- The application runs on DigitalOcean in NYC3, United States. Documents, backups, and the evidence anchors live in private Amazon Web Services S3 buckets in us-east-1, United States. Both providers are named on the sub-processor list.
- Encryption at rest
- Document object storage and backups use server-side AES-256 encryption. Buckets are private and versioned.
- Encryption in transit
- Public application and API connections use HTTPS.
- Document-signing keys
- Held in a KMS/HSM and used through its signing API. The private key never leaves the module, and no person can export it.
- Sealed artifacts
- Completed PDFs carry a digital seal using a self-issued certificate and a recorded hash. PDF readers may report the certificate as untrusted. Third-party timestamping is not enabled, so the recorded signing time is ours, not an independent attestation.
- Tamper-evident history
- Each event carries the hash of the one before it, making changes detectable when the chain is verified. A scheduled job publishes a signed Merkle anchor over everything sealed in a UTC day, so a whole day of records can be checked at once. Object storage is versioned; Object Lock retention is not enabled.
- Isolation
- Every query is scoped to a workspace. A 404 from the API is authoritative: it means the record does not exist for your workspace, not that you are not allowed to see it.
- Signer sessions
- Short-lived, sliding, scoped to one recipient of one document, revocable by bumping a token version, and accepted only by the signer endpoints.
- SSRF protection
- Every URL the product fetches for you — a presigned file, a webhook target — goes through allow-listing and address checks so it cannot be pointed at internal infrastructure.
- Access to production
- Least privilege, MFA required, no shared accounts, reviewed quarterly, and logged. Nobody approves their own access, their own change, or their own exception.
The control program
143 controls across seventeen domains, each naming what must be true, who owns it, how often it runs, and the evidence retained for review. Mapped to SOC 2 Trust Services Criteria, ISO/IEC 27001:2022 Annex A, and the HIPAA Security Rule. Contact our team for the documentation relevant to your security review.
| Domain | Controls | What it covers |
|---|---|---|
| Governance and policies | 8 | A written information security policy, an acceptable use policy, a secure development standard, and eleven more, each owned by a role and reviewed on a schedule. |
| Risk management | 5 | A risk register, an annual assessment, and a treatment plan with named owners. |
| Human resources security | 7 | Background checks, confidentiality agreements, security training at hire and annually, and a leaver checklist tied to access removal. |
| Access control and identity | 14 | Least privilege, two-factor authentication available to every user and required for our own production access, quarterly access reviews, separation of duties on approvals, and no shared accounts. |
| Cryptography and key management | 10 | Server-side AES-256 at rest on object storage and backups, TLS 1.2 and above in transit, the document-signing key held in Amazon Web Services KMS where nobody can export it, and documented rotation. |
| Secure development and change management | 11 | Peer review on every change, no self-approval, automated tests and security checks in CI, and separate environments with no production data in them. |
| Vulnerability and threat management | 7 | Dependency scanning, static analysis, patch SLAs by severity, and an annual third-party penetration test. |
| Logging and monitoring | 8 | Centralised, tamper-evident application and infrastructure logs with defined retention, plus alerting on security-relevant events. |
| Incident response | 7 | A written plan with severity levels, an on-call rota, defined notification timelines, and post-incident reviews. |
| Backup, availability, and continuity | 8 | Automated encrypted backups, tested restores, a documented recovery time and recovery point objective, and a continuity plan. |
| Network security | 8 | Segmented networks, deny-by-default egress, WAF and rate limiting at the edge, and SSRF protection on every URL the product fetches on your behalf. |
| Data classification, retention, and deletion | 8 | Every data type classified, retention periods set per class, and deletion that actually deletes, including from backups on a defined schedule. |
| Vendor and third-party management | 5 | A review before any vendor touches customer data, an inventory, and annual reassessment. |
| Privacy | 8 | A lawful basis for every processing activity, data subject request handling with deadlines, and a sub-processor list available on request with change notice. |
| HIPAA-specific safeguards | 11 | Administrative, physical, and technical safeguards mapped to the Security Rule, plus breach notification procedures. |
| Physical and cloud provider reliance | 5 | Data centre controls inherited from DigitalOcean, which runs the application, and Amazon Web Services, which stores documents and backups. Their reports are collected and reviewed rather than assumed. |
| Product evidence controls | 13 | The controls that make the evidence model real: the frozen revision manifest, the hash chain, the daily evidence anchor, key custody, and artifact hashing. |
What to check before you send
Where the program stands today, so you can decide what belongs in it.
- Choose the identity assurance your use case needs. By default, attribution rests on possession of an email address, plus any passcode you require. That is adequate for a simple electronic signature under ESIGN and UETA and inadequate for an advanced or qualified signature. Government-ID verification, through Stripe Identity or Persona, is available on Enterprise.
- Do not send protected health information yet. Signclad does not sign business associate agreements today. The HIPAA controls are built and the audit is complete and passed; a BAA will be offered on Business and Enterprise once the HIPAA programme finishes. Until then, healthcare teams can send administrative, employment, and vendor paperwork that carries no PHI. Review the sub-processor list and the data processing addendum before you start.
- Compliance documentation. Contact our team for information about our completed audits and how our controls map to SOC 2, ISO 27001, and HIPAA.
Reporting a vulnerability
Report it through the contact form. Our disclosure policy, contact, and PGP key live at /.well-known/security.txt. We acknowledge reports and will not pursue researchers who act in good faith and give us a reasonable window.
Every third party that touches customer data is named on the sub-processor list. For data transfers and retention, see the data processing addendum. For how the evidence model works, see audit and compliance.
Send your first document today.
The free plan covers three documents a month, with the same sealed PDFs and audit trails as every paid plan. No card required.