Security & Compliance

signID’s security model is built around three principles:

1. Encrypt at rest and in transit. Files are encrypted in S3 with AES-256; all network traffic uses TLS.
2. Seal every finished document. SHA-256 hashes make tampering detectable.
3. Log every meaningful action. An append-only audit trail records who did what, when, and from where.

The architecture is deliberately simple, meaning fewer moving parts, fewer failure modes, easier to reason about, and easier to defend legally.

Every file signID stores (uploaded PDFs, sealed PDFs, completion certificates, audit JSON) is encrypted at rest in AWS S3 with AES-256. This is server-side encryption managed by AWS, meaning:

• Files are encrypted before being written to disk
• Files are decrypted only when read by authorized processes
• Encryption keys are managed by AWS KMS with automatic rotation
• Neither signID staff nor AWS staff can access decrypted file contents without explicit access controls

All traffic to and from signID uses TLS (HTTPS). This includes:

• Web UI (Desk, signer, verify page)
• Partner API
• Webhook deliveries to your endpoints (signID rejects non-HTTPS webhook URLs)
• S3 uploads and downloads (via presigned URLs, always HTTPS)

Modern TLS versions and cipher suites are enforced. Deprecated TLS (1.0/1.1) is rejected.

When an envelope is fully signed, signID:

1. Merges all signatures into the PDF using a patch-based approach (preserving the original bytes as much as possible)
2. Flattens the result so signatures are baked into the document (not interactive form fields)
3. Linearizes the PDF via qpdf for fast web viewing
4. Computes the SHA-256 hash of the final bytes
5. Stores the hash on the envelope record and in the audit trail

The hash is the anchor for tamper detection. See Public Verification for how to use it.

Every meaningful event is recorded in an append-only audit trail, meaning entries can only be added, never edited or deleted. This is enforced at the database level.

The audit trail is stored in PostgreSQL and included as JSON in the complete-bundle download for every completed envelope. Together with the SHA-256 hash, it’s the primary evidence for defending a signature in a legal challenge.

Every event includes:

• Event type: viewed, signed, declined, sealed, etc.
• Timestamp: UTC, ISO-8601 format
• Actor: signer identifier, sender identifier, or “system”
• IP address: where the action originated (redacted on public verify page, full in complete bundle)
• User agent: browser and OS of the actor
• Workspace and envelope IDs
• Context data: for signed events, which fields were filled; for view events, from what page; etc.

Comprehensive enough to reconstruct exactly what happened, in what order, from what devices.

signID is multi-tenant from day one. Every record in the database, envelopes, templates, users, files, audit events, has a tenantId field that ties it to a specific workspace.

Isolation is enforced at multiple levels:

• Query layer: API endpoints scope every query by the caller’s tenant
• Storage layer: S3 paths include the tenant ID as a prefix
• Cache layer: Redis keys are tenant-scoped
• Job queue: background jobs carry tenant context

Cross-tenant access is impossible from normal API/UI paths. Only platform super-admins have cross-tenant visibility, and every super-admin action is audit-logged.

signID’s legal defensibility relies on three artifacts:

• The sealed PDF with all signatures baked in
• The SHA-256 hash as tamper evidence
• The audit trail reconstructing what happened

In a challenge, you present these together to argue: this document was signed by these people, at these times, from these IPs, and hasn’t been modified since (verifiable by re-computing the hash).

signID is designed to produce signatures that qualify as Simple Electronic Signatures (SES) under most global e-signature laws:

• United States (ESIGN Act, UETA): signID signatures satisfy the requirements for electronic signatures to be legally binding.
• EU (eIDAS): signID signatures qualify as SES. They do not qualify as Advanced (AES) or Qualified (QES) Electronic Signatures under eIDAS, which require specific cryptographic infrastructure (PKI, QSCDs, trust service providers).
• UK, Canada, Australia, and most other jurisdictions: signID signatures generally qualify for the local SES equivalent.

Every webhook signID sends is HMAC-SHA256 signed using your workspace’s signing secret. The signature is in the X-SignID-Signature header, format sha256=<hex>.

Your webhook handler must:

1. Read the raw request body
2. Compute HMAC-SHA256 of the body using your secret
3. Compare to the header value (using constant-time comparison)
4. Reject with 401 if signatures don’t match

See Webhooks for implementation examples.

Access is controlled via workspace roles:

• Admin: full access to workspace resources
• Viewer: read-only access

Enforcement is at multiple levels:

• UI: action buttons hidden or disabled for viewers
• API: viewer requests to admin endpoints return 403 Forbidden
• Job workers: background jobs check the actor’s role before executing

Every admin action is audit-logged. Downgrading a user from admin to viewer takes effect immediately, not at next login.

To keep our compliance posture honest, signID does not claim the following certifications, none are formally asserted or audited:

• SOC 2: not certified. signID’s practices align with SOC 2 principles (encryption, access controls, audit logging), but no third-party audit has been completed.
• HIPAA: not covered. signID is not a HIPAA Business Associate and should not be used for signing envelopes containing PHI (Protected Health Information) subject to HIPAA.
• eIDAS: signatures qualify as SES only, not AES or QES.

If you need signID with any of these certifications, contact support to discuss timing and whether we can meet your specific requirement. Do not represent to third parties that signID has certifications it does not have.