Privacy Notice

This is an earlier version. The version in effect now is at /privacy.

ChekSign is provided by Chek Accounting Pty Ltd (ABN 43 671 776 300, ACN 671 776 300), Kenmore Hills, Queensland 4069, Australia. This notice explains how we collect, hold, use and disclose personal information in connection with ChekSign. We use the Australian Privacy Principles as the standard for how ChekSign handles personal information, and comply with the Privacy Act 1988 (Cth) where it applies to us or to the activity concerned. Contact: kent@chekaccounting.com.au.

1. Whose information this is about

• Customers and Users. A Customer is the business that holds a ChekSign workspace. A User is a person it authorises to use that workspace.
• Signers. A Signer is someone a Customer sends a document to, to sign, witness or view. The Customer decides what the document says, why it is sent and who it goes to. We handle Signer information to provide the signing, evidence and verification service the Customer asked for. That does not remove any obligation either of us has under the law.
• Visitors. People who use this website, the sign-up form or the verification page.

2. What we collect about Customers and Users

• Each User's name and email address; their password, stored only as a one-way hash; and two-factor and passkey details where they set them up.
• Workspace membership and role, when each person joined, and a history of membership changes: who invited, promoted, removed or left, and when.
• The business's details where entered: trading name, ABN, address, phone, email, logo and brand colour, because they are printed on the documents it sends.
• The business's contacts: names, email addresses, mobile numbers and company names of the people it sends to.
• The documents it uploads or composes, its templates and saved messages, and its requests.
• Billing: the plan, subscription status, the Stripe customer reference, invoice numbers and amounts, envelope usage, and which User is responsible for the bill. We never receive full card details.
• Support requests it raises.
• A record of each message sent on its behalf: recipient, subject, time, and whether a mail server accepted it. The message text is recorded with any signing link removed.
• Which version of the Terms of Service and of this notice was accepted or acknowledged, by whom, for which workspace and when.
• Security and audit events, and technical information generated by using the service.

3. What we collect about Signers

Some of this comes from the Customer before we have any contact with the Signer.

• The name, email address and, where the Customer supplied them, mobile number and company the request was sent to, as they stood when the Signer was added to the request.
• What they did and when: opened the request, asked for a code, passed a check, signed, declined or witnessed.
• The identity check actually enforced on them, which is recorded as enforced and not as configured.
• Two IP address observations for each act, kept separately: the connection's own address and any forwarded address header, because the header is supplied by whoever is connecting.
• The name they typed and their signature, drawn, typed or uploaded.
• The consent or attestation statement exactly as it was shown to them, and, for a witness, whose signature they witnessed and how.
• Document hashes, and the information in the certificate and the verification record.

A one-time code is never stored as the code itself: only a salted hash of it is kept, with its expiry.

4. What documents may contain

Customers choose what they upload, so a document may contain information we do not ask for, including financial, tax, employment, identity or health information, tax file numbers, and information about people who are neither Users nor Signers. Customers must be authorised to provide it to us. We handle it only to provide, secure, retain and verify the document, and as otherwise permitted or required by law. We do not use document contents for advertising, for sale or to train any model.

5. How we collect it

Directly from Users when they create or use an account; from Customers when they add contacts, upload documents and send requests; from Signers when they use a signing page; automatically as the service runs and is secured; from Stripe about subscription and payment status; from email and SMS providers about delivery; and from anyone who contacts us.

6. Why we use it

To create and secure accounts; run workspaces; send requests, reminders, verification codes, invitations and password resets; produce signed documents and certificates; keep evidence of signing; answer verification requests; bill; answer support requests; prevent abuse, fraud and unauthorised access; keep the service reliable and secure; investigate incidents; enforce our terms; comply with the law; and establish, exercise or defend legal rights.

We do not sell personal information, we do not use it for behavioural advertising, and we do not use Customer documents to train artificial intelligence or machine-learning models.

7. Messages we send

ChekSign sends only the messages the service needs: signing requests, reminders, verification codes, invitations, password resets, billing notices, service notices and replies to support requests. We do not send marketing. If that ever changes, it will comply with privacy and spam law and this notice will be updated first. We do not market to Signers.

8. Cookies and similar technologies

ChekSign uses only cookies it needs to work and to stay secure: a sign-in cookie, anti-forgery cookies, and, after sign-up or confirming an email address, a cookie that remembers that email address for up to 24 hours so the sign-in form can fill it in. There are no advertising or analytics cookies. Fonts are served from our own servers, so the signing page loads nothing from a third party and emails carry no tracking pixel. Where Cloudflare Turnstile is enabled on a public form, it processes technical signals from the visitor's browser to detect bots; it never receives the contents of a document.

9. Monitoring and logs

We use monitoring and logging to keep the service secure, diagnose errors and understand performance. This can include request details, errors, performance data, IP addresses, email delivery errors and security events. Before our application telemetry is recorded, signing links, password-reset and invitation codes and every query-string value are removed from it. Our application does not write one-time codes or message bodies to its logs.

The infrastructure providers we use, including our hosting platform, keep their own operational logs, which may record the full address of a request. Access to monitoring information is restricted to people who need it, and it is kept for the retention period configured for that service rather than indefinitely.

10. Who receives it

Each provider receives only what is described here.

• Microsoft Azure: hosting, database, document storage and secrets. Receives what ChekSign processes, as our host. Located in Azure's Australia East region.
• Microsoft Application Insights: reliability, error and performance monitoring. Receives the telemetry described in section 9. Located in Australia East.
• Azure Communication Services Email: sends our emails. Receives recipient names and addresses, subjects (which name documents), and message text, including signing links and one-time codes. Our resource is configured with Australia as its data location; Microsoft may transit or process messages in other regions to deliver them.
• Mobile Message: sends our SMS messages. Receives the Signer's mobile number and the message: a one-time code naming the sending business or, where the Customer turns it on, a notification that may include the signing link. Mobile Message is an Australian provider and states that its platform, messages and contacts are hosted in Sydney.
• Stripe: subscriptions, invoices and payments. Receives the billing User's email address, workspace identifiers, subscription and invoice details, envelope counts (each tagged with an identifier derived from the request, not its content), and the card details a person enters on Stripe's own page. Stripe's service involves Stripe entities in Australia and Ireland and service providers elsewhere, so this information may be processed outside Australia, including in Ireland and the United States.
• DigiCert: independent trusted timestamps. Receives only the SHA-256 hash of a finished document, which identifies the document cryptographically without disclosing its contents or anybody's details. DigiCert is based in the United States.
• Cloudflare Turnstile, where enabled on a public form: bot detection. Receives browser and device signals and the visitor's IP address. Cloudflare operates internationally.
• Anyone holding a signed document, through the verification page, as set out in section 19.

We may also disclose information where the law requires or authorises it.

11. Processing outside Australia

The documents and database ChekSign holds are hosted in Australia. Some of the providers above are international, so some personal information may be transmitted, processed or accessed outside Australia, including in Ireland, the United States and other countries where those providers or their service providers operate. Where the Privacy Act applies and an arrangement is a disclosure to an overseas recipient, we take the steps Australian Privacy Principle 8 requires unless an exception applies. Not every cross-border technical transmission is a disclosure: information that passes through a provider's network while it stays under our control is not.

12. Where it is held

ChekSign's application, database and document storage are hosted in Microsoft Azure's Australia East region. Documents are stored write-once and identified by their contents, so the same bytes always land in the same place and a stored document cannot be altered. This does not mean every provider we use is located only in Australia; see sections 10 and 11.

13. How long we keep it

Completed signing records. Long-term verification is a core purpose of ChekSign. A completed record includes the document as presented, the signed document, the certificate, the recorded events, the Signer information in section 3, the consent and attestation statements, the hashes, the trusted timestamp and the verification entry. We retain completed records while we reasonably need them for the signing, evidence, verification, legal or related purposes in this notice, and we currently retain them indefinitely. A Customer ending its subscription does not by itself delete a completed record. We may still be required to destroy, de-identify or restrict information where the law, a court or a regulator requires it, or where continued retention is no longer lawful. Where privacy law requires us to destroy or de-identify personal information that is no longer needed, we will weigh that against the continuing evidence, verification, legal and regulatory purposes the record serves.

Everything else:

• Drafts, templates, saved messages and content items: until the Customer deletes them, subject to backups and legal requirements.
• Contacts: until the Customer archives them; archived contacts are retained.
• Account details: while the account is open; afterwards only where records that name the person need to stay accurate (section 14).
• Billing records: for as long as needed for accounting, tax, dispute and legal purposes.
• Support requests, membership history, audit records and message records: while reasonably needed for support, security, governance, evidence, dispute or legal purposes.
• Monitoring data: for the retention period configured for that service.

14. Closing an account or a workspace

Closing a User account deletes the sign-in and the profile. It does not rewrite history: where the person sent a request, signed or witnessed a document, administered a workspace or took another recorded action, their name and email address stay in those records, because other people rely on them as evidence. Closing a workspace does not ordinarily erase completed records.

15. Access and correction

Anyone may ask us for access to the personal information we hold about them, or ask us to correct it, by writing to kent@chekaccounting.com.au. A Signer may also ask the business that sent them the document. We may need to confirm who you are before we answer. We may decline or limit access where the law permits or requires it, and will give reasons where the law requires. Users can also see and change their own details, download their account data and close their account from their account settings.

A completed signing record preserves what happened at the time, so we will not rewrite a historical event because information has since changed. Where a correction is appropriate we may correct the information used from now on, add a note, or record the correction separately.

16. Complaints

If you think we have mishandled your personal information, write to our Privacy Officer at kent@chekaccounting.com.au. We will acknowledge your complaint, look into it, ask for more information if we need it, and aim to respond within 30 days. If you are not satisfied with our response and the Privacy Act applies, you may be able to complain to the Office of the Australian Information Commissioner.

17. Security

We use technical and organisational safeguards intended to protect personal information from misuse, interference, loss and unauthorised access, change or disclosure. They include encryption in transit, encryption at rest by the storage services we use, password hashing, hashed one-time codes, signing links that are unguessable and stored encrypted, roles within each workspace, optional or required two-factor sign-in, rate limits on public pages, audit records, and restricted support access: our support operators must record a reason before opening a workspace, and no support path can sign in as a User or open a document. No system is completely secure.

18. Data breaches

We have procedures for responding to a suspected data breach. Where the Notifiable Data Breaches scheme or another law requires it, we will assess the incident and notify affected people and the regulator. Customers must tell us promptly if they become aware of a security incident affecting their ChekSign account.

19. Checking a document

Anyone holding a signed document, or its SHA-256 hash, can check it at our verification page without an account. The page answers about that one document only; it cannot be used to browse or search for people or documents. A match shows the document's title, the Signers' names, when it was signed and how many signatures it carries. A file checked there is hashed and not stored. Signers are told on the signing page that this record will exist.

20. Changes to this notice

We may update this notice as ChekSign, our providers, how we handle information or the law change. The current version and its effective date are always on this page, and every earlier version stays readable at /privacy/versions. Where a change materially affects how information we already hold is handled, we will email the workspace Owners before it takes effect.

21. Contact

Chek Accounting Pty Ltd, ABN 43 671 776 300, ACN 671 776 300, Kenmore Hills, Queensland 4069, Australia. Privacy questions, requests and complaints: kent@chekaccounting.com.au. A Signer may contact us directly as well as through the business that sent them the document.

About this version

Version 1 of the Privacy Notice, effective 29 September 2026. It is always readable at /privacy/versions/1, and every version is listed. The SHA-256 of its text is 228f184f4f0dc25da395a7b80d72efc971b56d96acdda96cdbae2eafe8a6a616; a record of acceptance names this value.