Electronic Signature Policy for Documents
Revision: 09.06.2026
1. Introduction
This document describes the electronic signature system used by SmartCLM, https://www.smartclm.ai/ (ID No. 404793238), when signing electronically drafted documents. The document describes the technical processes that ensure verification of the signer's identity, the integrity of the document, the record of consent, and the generation of the audit trail.
Under Georgian legislation, the legal regulation of electronic signatures is as follows:
Under Article 134 of the Civil Procedure Code of Georgia, an electronic document that meets the requirements of the Georgian Law “On Electronic Document and Electronic Trust Services” has evidentiary force.
Furthermore, under paragraph 2 of Article 1 of the Georgian Law on Electronic Document and Electronic Trust Services, the law does not restrict the right of natural persons and private legal entities to use, at their own discretion, a physical document and/or handwritten signature, as well as an electronic document and/or electronic signature executed under terms other than those set out in this law. Under paragraphs 7 and 8 of Article 3 of the same law, it is not permitted, in administrative proceedings and court proceedings, to refuse an electronic document solely on the grounds that it is submitted in electronic form; nor is it permitted, in administrative proceedings and court proceedings, to deny evidentiary force to an electronic signature and/or electronic seal solely on the grounds that it does not meet the requirements established by this law for a qualified electronic signature and/or qualified electronic seal. Under paragraph 8 of Article 3 of the law, where an agreement exists between natural persons and/or private legal entities, an electronic document and electronic signature have, for those persons, legal force equal to that of a physical document and handwritten signature, respectively.
Accordingly, the signing of an electronic document through SmartCLM is carried out in accordance with the Georgian legislation on Electronic Documents and Electronic Trust Services.
2. Overview of the Signing Process
The electronic signature process consists of the following stages:
- Document sharing — the document owner creates a secure, unique sharing link (a cryptographic token) and sends it to the recipient by email. The shared link has an expiry period, which the user sets manually.
- Identity verification (OTP) — before signing, the signer must verify their identity using a one-time code (OTP) sent by email. Alternatively, SMS OTP via msg.ge may be used.
- A 6-digit code is generated on the server and sent to the recipient;
- The code received is valid for 5 minutes;
- The recipient has a limited number of verification attempts;
- The system records the verification method, timestamp, phone number, IP address, and user information.
- Consent — after identity verification, the recipient must confirm consent to the following:
- the parties' identities have been verified by email/SMS OTP;
- the signing parties fully understand that by means of the electronic signature they are expressing intent/consent, and that the document accordingly acquires legal force;
- the signing parties agree to all terms set out in the document;
- the parties confirm that they have fully read this Electronic Signature Policy and agree to it;
- the text of the consent is converted into a hash (SHA-256) and stored in the database.
- Creating the signature — the recipient creates a signature using one of the following methods:
- Text: typed name in a calligraphic font
- Drawing: a hand-drawn signature on a digital pad (using the signature_pad library)
- Image upload: an uploaded image of the signature (PNG/JPG, max 5MB, background automatically removed)
- Signing the document — the signature is inserted into the document at the designated positions and sent with a timestamp in the Georgian locale. The branding “Prepared and signed with SmartCLM.ai” is included.
3. Signing Order
The system supports a configurable signing order:
- Company last (owner_last) — the recipient signs first, followed by the company/owner;
- Company first (owner_first) — the owner signs first, the recipient sees the owner's signature, and then signs;
4. Document Integrity
- When a document is sent, its content is converted into a unique SHA-256 hash and stored;
- By comparing hashes, any modification of the document between sharing and signing can be detected;
- Hashing is performed on the server, using the Web Crypto API;
5. Activity History
Every significant activity is recorded in the signature_audit_log table, which contains:
| Activity | Recorded Data |
|---|---|
| Document sharing | Timestamp, Share ID, recipient's email |
| Document viewing | Timestamp, IP address |
| Sending verification code | Method (Email/SMS), recipient, timestamp, IP |
| Completing verification | Timestamp, IP, User Agent |
| Consent | Hash of consent text, timestamp, IP |
| Document signing | Signature data, timestamp, IP, user agent |
All timestamps are stored in ISO 8601 format. IP addresses and User Agents are recorded from the HTTP request headers.
6. Signature Certificate
After both parties have signed, the system generates a PDF signature certificate, which contains:
- the document ID and title;
- the document number;
- the identities of both parties (owner's/company's email, recipient's email);
- the verification method and timestamp;
- the consent timestamp;
- the signing timestamp of both parties;
- the recipient's IP address;
- document integrity hashes (at the time of sharing and signing);
- a full list of activities;
- a reference to material information — a legal notice;
- the identifier and browser version of the technical device (personal computer, smartphone, etc.) used to sign
7. Technical Security Measures
- Unique cryptographic tokens: each sharing link uses a 32-byte random hexadecimal token;
- Link expiry: sharing links may have a configurable expiry period;
- Email matching: if a recipient's email is specified, only that email can complete verification;
- Restrictions: OTP verification has an attempt limit to protect against brute-force attacks;
- Immutability: once signed, a document becomes read-only within the system
For data storage, we use Amazon Cloud servers (AWS Cloud), located in Stockholm.
8. Legal Framework
The system provides a simple electronic signature (non-qualified electronic signature) with enhanced verification and audit capabilities.
9. Contact
If you have any further questions, please contact us:
