Compliance Overview

This page summarizes where SecuSign’s electronic signatures meet applicable legal frameworks today, and what is in progress. It is informational only and not legal advice. For regulated use cases, please contact us.

Status legend
Baseline means a typical e‑signature evidence set: identity (email delivery + re‑auth), intent, integrity (hashing), and an audit trail. It is not a guarantee of legal sufficiency for every jurisdiction or regulated use‑case.
Baseline Advanced-ready (PAdES/PKI + TSA) Planned (QES / local schemes)
Last updated: 2025-12-19
SecuSign

Regional Status

Region / Framework Law / Reference Status Notes
Thailand Electronic Transactions Act B.E. 2544 (2001) (as amended) Baseline Email delivery + re‑auth (OTP), intent, integrity (SHA‑256), time‑stamped audit trail; PDPA B.E. 2562 (2019)-aligned practices.
Singapore Electronic Transactions Act 2010 Baseline Identity + intent + integrity with time‑stamped logs.
Malaysia Electronic Commerce Act 2006; Digital Signature Act 1997 (digital signatures) Baseline Functional equivalence approach.
Philippines Electronic Commerce Act (Republic Act No. 8792, 2000) Baseline Electronic signatures are recognized when reliability/integrity can be shown; keep a complete audit trail.
India Information Technology Act, 2000 (as amended) — Chapter II (Digital & Electronic Signature) Baseline Electronic signatures are recognized in law; for higher‑assurance / regulated workflows, certificate‑based signatures are common.
Indonesia ITE Law (Law No. 11/2008, as amended) + Government Regulation 71/2019 Baseline Planned General e‑sign validity depends on meeting statutory criteria; for higher‑risk use cases, certified e‑signs using electronic certificates (PSrE) may be required.
Vietnam Law on Electronic Transactions 2023 (effective 2024‑07‑01) + Decree 23/2025/ND‑CP Baseline Advanced-ready Electronic signatures are recognized; trust services are regulated. Foreign e‑signature recognition is being formalized under the new framework.
United States ESIGN Act (15 U.S.C. §7001) + UETA (state law) Baseline Consent to do business electronically + strong audit evidence; consumer disclosures/affirmative consent apply in many consumer contexts; some record types are excluded.
Canada Provincial/territorial e‑commerce laws (often UECA‑based) + PIPEDA (privacy) Baseline Consent + audit evidence; privacy compliance (PIPEDA / provincial laws). Some workflows may require a “secure”/digital signature.
Australia Electronic Transactions Act 1999 Baseline Consent + reliability evidence retained.
EU / EEA eIDAS Regulation (EU) No 910/2014 Advanced-ready PKI (CMS/PKCS#7) + RFC-3161 TSA integration underway. QES via QTSP planned.
United Kingdom UK eIDAS (retained) Advanced-ready Mirrors EU path; QTSP integration planned.
Japan Act on Electronic Signatures and Certification Business Advanced-ready Qualified timestamp integration planned; local TSA options under review.
Brazil ICP-Brasil Planned Integration with ICP-Brasil CAs for qualified signatures.

Technical Controls

  • Signer identity: Email link delivery plus a short‑lived email re‑authentication code (OTP) required before a signature is finalized. Higher‑assurance identity proofing (KYC/eID) and per‑signer certificates are planned.
  • Intent to sign: Explicit consent checkbox and unambiguous “Sign” action.
  • Document integrity: SHA‑256 hashing with a tamper‑evident audit trail. Optional embedded PDF digital signature (PAdES / CMS/PKCS#7) and optional RFC‑3161 timestamping (TSA) when enabled.
  • Link expiry: Signing links can be time‑limited at the envelope level; per‑recipient signing windows are planned.
  • Audit trail: Envelope ledger with IP, user agent, times, and methods; exportable as a PDF ledger. CSV/JSON exports are planned.
  • Data protection: Encryption in transit (HTTPS/TLS). Encryption at rest depends on your hosting/storage (managed vs. self‑hosted). Data minimization and customer‑controlled export/deletion.
  • Verification: Signed PDFs can include a QR code linking to verification details (including document hash) and a public ledger download.

Roadmap to EU Qualified (QES)

  1. Finalize PKI + TSA integration and validation harness (major PDF viewers).
  2. Partner with a Qualified Trust Service Provider (QTSP) for QES.
  3. Introduce per-signer certificates and identity proofing (KYC/eID).
  4. Publish CPS-lite and security controls aligned to ETSI EN 319 401/411/421.

Country Notes (Selected markets)

Quick, non‑exhaustive notes for common commercial agreements in key markets. This is not legal advice. Some document types (e.g., deeds, wills, notarized instruments, certain regulated filings) may require wet‑ink, notarization, or a local certified signature scheme.

Thailand — Electronic Transactions Act B.E. 2544 (2001)
How SecuSign maps to typical expectations
  • Baseline use: Commercial agreements where parties accept electronic execution. Thai law recognizes electronic signatures; practical enforceability depends on having reliable evidence for the transaction and scenario.
  • Evidence & reliability: OTP re‑auth + explicit intent + a complete audit trail (times, IP/user agent, document hash). ETDA guidance commonly frames e‑signature strength on a risk basis (from simple methods like OTP to certificate‑based digital signatures).
  • Higher assurance: For higher‑risk or regulated workflows, use certificate‑based digital signatures (PKI) and trusted timestamping (TSA) where appropriate; some sectors/counterparties may prefer a local certificate provider.
  • Data protection: Handle personal data in line with Thailand’s PDPA (lawful basis/consent, security, retention, and data subject rights).
India — IT Act 2000 (as amended)
How SecuSign maps to typical expectations
  • Baseline use: Business contracts where parties accept electronic execution and you retain strong evidence (OTP re‑auth, audit trail, document hash).
  • Higher assurance: For government/regulated workflows, a certificate‑based digital signature (DSC) is commonly used; SecuSign’s roadmap supports “bring your own certificate” style signing.
  • Recommended settings: OTP required + explicit consent + keep ledger PDF + enable PAdES/PKI + TSA where available.
Philippines — RA 8792 (E‑Commerce Act)
Practical guidance
  • Baseline use: Electronic signatures can be equivalent to handwritten signatures when a reliable procedure is used and integrity is maintained.
  • Recommended settings: OTP required + clear intent (“Sign” action) + audit trail export for evidentiary use.
Indonesia — ITE Law + GR 71/2019
What to watch for
  • Baseline use: Validity depends on meeting statutory requirements (attribution, integrity, and control over the signature creation data).
  • Certified e‑signatures: For higher‑risk or specific regulated contexts, electronic signatures secured by an electronic certificate issued by a recognized provider (PSrE) may be required.
  • Roadmap: Add PSrE / electronic‑certificate integration option for Indonesia‑focused deployments.
Vietnam — LOET 2023 + Decree 23/2025
Current direction
  • Baseline use: Electronic transactions are broadly recognized; keep strong evidence and reproducible records.
  • Trust services: Decree 23/2025 regulates trust services and signature service providers; foreign e-signature recognition is being implemented under the post-2024 framework.
  • Recommended settings: Enable PAdES/PKI + TSA for higher assurance; consider local trust service alignment for regulated sectors.
United States — ESIGN Act (15 U.S.C. §7001) + UETA (state law)
Practical guidance
  • Baseline use: ESIGN generally prevents denying legal effect to a signature/contract solely because it is in electronic form, when parties choose to transact electronically.
  • Consumer consent: In many consumer contexts, ESIGN requires clear disclosures and affirmative consent to receive required records electronically; keep records that are accurate and reproducible.
  • State variation: UETA (or state equivalents) governs many state-law transactions; exclusions and requirements can vary by state and document type.
  • Recommended settings: OTP required + explicit intent (“Sign” action) + exportable ledger; enable PAdES/PKI + TSA for higher assurance where available.

Note: ESIGN contains exclusions for certain categories of records (for example, some court/probate/family law records, product recall notices, hazardous materials papers, and some notices).

Canada — Provincial/territorial e-commerce laws + PIPEDA (privacy)
Practical guidance
  • Baseline use: Provinces and territories have enacted electronic commerce / electronic transactions laws (many modeled on the Uniform Electronic Commerce Act) that support legal recognition of electronic records and signatures for common commercial agreements.
  • Privacy: PIPEDA applies to many private-sector organizations handling personal information in commercial activities (with provincial privacy laws also relevant in several provinces).
  • Higher assurance: Some workflows (especially public sector / regulated) may refer to “secure electronic signatures” (typically PKI-based digital signatures) under federal or program-specific rules.
  • Recommended settings: OTP required + explicit intent + keep ledger PDF; for higher assurance enable PAdES/PKI + TSA where available, and consider local “secure e-signature” expectations per use-case.

Data Protection & Security

  • Controller vs. processor: In most cases you remain the data controller for the content of your envelopes; SecuSign (and any hosting provider you use) acts as a processor.
  • Transport security: All browser access to SecuSign is intended to run over HTTPS/TLS via your chosen reverse proxy or hosting provider. We recommend HSTS and modern cipher suites for production.
  • Access control: Access to envelopes and signed documents is authenticated and restricted to the envelope owner and intended recipients; verification links can be shared by the owner for third‑party validation.
  • Retention: Envelopes and documents can be deleted from SecuSign when they are no longer needed. We recommend aligning retention and backup policies with your own PDPA/GDPR or sector-specific requirements.
  • Data subject requests: Because your documents and ledger entries are stored per account, you can search, export, and delete records to help respond to access/rectification/erasure requests where applicable.

The exact technical and organizational measures depend on how and where SecuSign is deployed (self-hosted vs. managed). This page describes the intended baseline and design assumptions; your own deployment and policies complete the picture.

Important Notes

  • This page is for information only and does not constitute legal advice. Requirements vary by use-case and jurisdiction.
  • Where “Advanced-ready” is shown, cryptographic PDF signing (PAdES/PKI) and RFC‑3161 timestamping (TSA) are available or in rollout; EU Qualified (QES) requires a QTSP partner and identity proofing.
  • If you have a regulated or high-assurance need, contact us to review your scenario.