Privacy policy

You sign in with your email address. We send a one-time link to it. There is no password.

• Email address. It identifies your account and is where we send sign-in links and notifications. Requesting a sign-in link creates an account record for that address, even if the link is never used.
• Full name, if you add it to your profile. Recipients see it as the sender of your documents.
• One-time sign-in links. We store only a hash of the link, not the link itself. A link works once and for 15 minutes. We also record the IP address it was requested from.
• Sessions. After sign-in your browser keeps a session cookie. On our side the session record holds the IP address, the browser's user agent and the time of last activity. A session works for up to 14 days or until you log out; the record itself is deleted 7 days after the session expires.
• Account details: credit balance, account status, the time of your last sign-in.

• The PDF file, its original file name, size, number of pages and a SHA-256 checksum of its contents.
• The fields you place on the pages: type, position, label and whether they are required.
• Recipient details you enter: email address, name and the optional message.
• Sending details: when the document was sent, how long the link works, how many times the invitation was sent.
• An access code, if you set one for the recipient. We store only a salted hash of it (scrypt), never the code itself, so we cannot show it to you or send it to anyone. You share the code with the recipient yourself, outside our emails.

You can delete a document while it is still a draft. Once a document has been sent it stays in your account together with its event log; see “How long we keep data”.

If someone sent you a document through SignClearly, or you sign your own document in your account, we process the following:

• Your email address and name, as entered by the sender (or taken from your account when you sign your own document) and as you type your name when signing.
• Your consent to sign electronically: the time and the version of the consent text.
• Your drawn signature, stored as an image, and the values you enter in text, date and checkbox fields.
• The reason you give, if you decline to sign.
• For each step (opening the link, consent, signing, downloading, declining): the time, your IP address and your browser's user agent.
• If the sender protected the document with an access code: each attempt to enter it, with the time, IP address, user agent and whether it was correct. The code you type is not stored. After a correct code, a signing session that lasts 2 hours, stored as a hash.

The signed PDF includes a certificate page with the document ID, a SHA-256 checksum of the original file, the names and email addresses of the sender and the signer, how the signer got access (a link sent by email, or the account owner signing in their account), whether an access code from the sender was required, the result of an ID check if the sender required one (see “ID check of the signer”), the signer's IP address and browser user agent, the version of the consent text, and the list of events with times and IP addresses. After signing, the signer gets an email with a link to download the signed PDF for 7 days. When you sign your own document, you get only the sender's email. The sender gets an email with a link to the document and can download the signed PDF from their account.

A sender can require the signer to verify their identity before signing. The check happens only for documents where the sender turned it on, and only before the signer signs. It is never used when you sign your own document in your account.

The check is run by Didit, an identity verification service that works for us as a processor. You leave SignClearly for Didit's page. Didit asks for what its check needs, for example photos of an identity document and a selfie or a short video, checks them and sends us the result. Didit's own Verification Privacy Notice explains how Didit handles the images and biometric data.

Before you go to Didit, the signing page explains the check and asks you to agree to it. We record that you agreed, when, and which version of that text you saw. You do not have to take the check: you can decline to sign or ask the sender for another way to sign.

What we receive from Didit and keep:

• Whether the check passed, failed or was not finished in time, the method and level of the check as short codes, and a reason code if it failed.
• The name shown on your ID document, only if the check passed.
• The country that issued the document.
• Didit's reference number for the check.
• When the check started and finished, the IP address and browser user agent from which you started it, and the version of the consent text.

We do not keep images of your document, your selfie or video, biometric data, your date of birth or the document number. They stay with Didit.

The sender sees the result on the document page: whether the check passed, the provider, when it finished, the name on the ID and the issuing country. The result is also written to the document's event log, which the sender can open; there it also includes Didit's reference number, the method and level codes and, for a failed check, the reason code. The certificate page of the signed PDF shows the provider, the method, the time and the name on the ID. If the signature is made with a SignClearly signing certificate, the certificate contains the name on the ID (see “Signing certificates”).

ID check results, including failed and unfinished checks, are kept with the document and deleted together with it: when the account is deleted, or when a closed document reaches the retention period (see “How long we keep data”). The name on the ID stays in the signing certificate record after that.

When SignClearly's own certificate authority is turned on, the signature is made with a key that your browser creates on the signing page, and SignClearly issues a certificate for that key. The key exists only in the page's memory and is gone after signing; we never receive it. Each certificate is for one signature and is valid for 24 hours.

The certificate contains:

• Your email address: the address the signing link was sent to, or your account address when you sign your own document.
• The name on your ID, if the sender required an ID check and it passed. Without an ID check the certificate has no name: the name you type when signing is not checked and does not go into the certificate.
• Markers of what was checked: control of the email address, an access code from the sender if one was required, and an ID check if one passed.
• A serial number, the validity period and the public key.

The certificate is part of the signed PDF, so anyone who has the file can read it.

We keep a record of every certificate we issue, including certificates that were issued but never used for a signature: the certificate itself, the email address, a hash of the public key, when it was issued and used, and, if it was revoked, when and why. The record stays after the document is deleted, whether by the retention period or together with the account; only its link to the document is removed. We need it to publish the list of revoked certificates (CRL), which programs use to check signatures in files that are already signed, and to handle revocation requests and notify the signer. The published list contains only serial numbers, revocation times and reasons, no email addresses or names.

The document owner, or the signer named in a certificate, can ask us to revoke it by writing to us from the email address we have on record for them: the account address or the address in the certificate. We reply to that address and revoke the certificate after you confirm. If the document has already been deleted, only the signer can ask. After a revocation we email the document owner and the signer; if the document has been deleted, we email only the signer, at the address in the certificate, without the document name. Revocation does not change the signed PDF; programs that validate PDF signatures will show its certificate as revoked.

Each document has an event log. It records when the document was created, uploaded, sent, opened, signed, completed, downloaded, declined, revoked, expired or copied, when the owner started signing it themselves, when the recipient gave consent or entered an access code (correct or not), when the recipient agreed to an ID check, started it, passed or failed it, when a signing certificate was issued or revoked, and when invitation and completion emails were sent or failed. An event records when it happened, who caused it (the sender, the recipient or the system), details such as an email address, a name or the file name, and an IP address and user agent for actions made in a browser.

Each event includes a hash of the previous one, so a later change to the log can be detected. The log exists to show what happened to a document, and it is the main reason we keep IP addresses.

The log can also be protected with a secret key kept outside the database: each new event then gets a keyed checksum (HMAC), so someone who can only change the database cannot rewrite the log without it showing. Once a day the service stores a checksum over the new events (an anchor). The anchor contains only event numbers and hashes, no names, email addresses or IP addresses.

The signed PDF can carry a SignClearly platform seal: a digital seal of the service, not the signer's signature. It shows whether the file was changed after SignClearly produced it. The seal does not add any personal data to the file beyond what the certificate page already shows.

The seal, a signature made with a SignClearly signing certificate and the daily log anchor can be timestamped by an external timestamp authority (RFC 3161). We use DigiCert's public timestamp service. For each timestamp our server sends DigiCert only a SHA-256 hash of the signature or of the log anchor and a random number. The hash is derived from the document, but the document cannot be recovered from it. DigiCert never receives the document, names, email addresses or your IP address: the request comes from our server, not from you. The timestamp DigiCert returns goes into the signed PDF, or into our database for the log anchor.

Credits are bought through Stripe Checkout. You enter your card details on Stripe's page. We never receive or store your card number.

• We send Stripe your email address and an internal account identifier so the payment can be matched to your account.
• We store the pack you chose, the number of credits, the amount and currency, the payment status and the Stripe identifiers of the checkout session and its events.
• Each credit spent on sending a document is recorded with a link to that document.

Stripe processes payment data under its own privacy policy and keeps its records under its own rules.

We send sign-in links, signature requests, notices that a document was signed, declined or expired, the signed copy, notices that a signing certificate was revoked, and a confirmation when credits are added. Most subjects include the document name. An email delivery provider receives the recipient address and the content of each message.

SignClearly sets one cookie: the session cookie that keeps you signed in. Scripts in the browser cannot read it. We do not use analytics, advertising or third-party tracking cookies, and the app does not keep data in your browser's local storage.

Stripe sets its own cookies on its checkout page.

Our API server logs record the request method, the path with tokens and IDs removed, the response status and the duration. When an email cannot be sent, the log records the domain of the address (the part after @). The logs are set up to leave out full email addresses, tokens, request bodies and file contents, but an error report can include technical details of the operation that failed.

To limit abuse, for example many sign-in requests in a row, we count requests per IP address and per email address. Counters are stored as hashes and deleted after one day.

• To sign you in and keep your session.
• To store, prepare and send your documents, and to let recipients review and sign them.
• To produce the signed PDF and keep a record of how it was signed.
• To check the signer's identity when the sender requires it.
• To issue signing certificates and publish which of them are revoked.
• To send the emails listed above.
• To take payments and keep your credit balance correct.
• To protect the service from abuse and to investigate errors.

Account data, document details and event logs are kept in a database. PDF files, signed copies and signature images are kept in file storage. The app opens a file only through a link that expires after a few minutes.

In production the app's address and the file storage links must use HTTPS; the server refuses to start otherwise.

Service providers that process data for SignClearly:

• Stripe: payments.
• An email delivery provider: sending emails (see “Emails we send”).
• Didit: ID checks of signers, only for documents where the sender requires one (see “ID check of the signer”).
• DigiCert, as the timestamp authority if timestamps are turned on: receives hashes only (see “Platform seal and timestamps”).

• Sign-in links and sessions: deleted 7 days after they expire.
• Abuse protection counters: deleted after one day.
• Drafts with no uploaded file: deleted after 24 hours.
• Signing links work for the period the sender chose, 30 days at most. The signer's link to download the signed copy works for 7 days after signing.
• Your account record, documents, files, signatures, ID check results, event logs and payment records: kept while the account exists and deleted when the account is deleted. This includes account records created by a sign-in request that was never used.
• Signing certificate records: kept after the document and the account are deleted (see “Signing certificates”).

The operator can set a retention period for closed documents (signed, declined, expired or revoked). When it is set, such a document is deleted that many days after it closed, together with its files, signature image, field values, ID check results and event log. What stays: the record that a credit was spent, without a link to the document; the records of signing certificates issued for it (see “Signing certificates”); and for each deleted event only its number and hash, which cannot be turned back into the event. The numbers and hashes keep the daily log anchors verifiable.

• You can change or remove the name in your profile and delete drafts at any time.
• You can ask for a copy of your account data. The export contains your profile, documents with field values, signers' names, email addresses, signing times and IP addresses, ID check results as shown on the document page, details of the signing certificate (serial number, issuer, validity and revocation status), event logs and transactions. It does not include signature images, browser user agents or sign-in records. PDF files can be downloaded from your account.
• You can ask us to delete your account. This removes your files, profile, documents, signatures, ID check results, event logs, payment records and sessions. Of the event logs only the numbers and hashes of the events stay, as described in “How long we keep data”. Signing certificate records stay too (see “Signing certificates”).

Deletion does not reach copies that already left the service: signed PDFs that you or the signer downloaded, and records Stripe keeps. Recipients who signed a document can send requests too. Their data is part of the sender's document, so a request about it may also involve the sender.

When the way SignClearly handles data changes, we update this page and the date at the top.