Privacy policy.

This policy applies to three distinct groups of people whose personal information may flow through the Service:

• Senders — account holders who create and send signing requests from a paid or free Ink. workspace.
• Signers — recipients who view, sign, or otherwise interact with a document a sender has dispatched. Signers do not need an Ink. account to sign.
• Visitors — anyone who browses the Ink. marketing site or the public landing page of a bulk-signing link.

Where a sender is itself an organisation (a “workspace tenant”), that organisation is the data controller for the documents and signer records inside its workspace, and Ink. acts as its processor. Senders are responsible for the lawful collection and use of any personal information they upload and dispatch through the Service.

We collect personal information in five categories:

• Account information. When you create an Ink. workspace we collect your name, email address, and (if you use a social sign-in) the identifier from your identity provider. We never receive or store your provider password.
• Document content. PDFs you upload, the field layouts you place on them, the signers you nominate, and the signature, initials, text, or other field values that signers contribute. Documents are tenant-isolated and enforced by Row-Level Security in our database.
• Signer identity & proof-of-execution. Each signer event (viewed, signed, declined) is captured with a timestamp, the signer’s IP address, a user-agent string, and — if you enabled OTP — the verification channel used. These are written into the Certificate of Completion that travels with every signed PDF.
• Communications metadata. Email delivery, open/click, and bounce events from our transactional mail provider; signing-link redemption events; support correspondence you send us.
• Billing information. Subscription tier, seat count, invoice history, and the payment processor’s opaque customer identifier. Card numbers are tokenised by Stripe and never reach our servers.

We do not knowingly collect personal information from children under 13, and the Service is not directed at them. If you believe a child has provided us personal information, please contact us and we will delete it.

We use the information above only for these purposes:

• To operate, secure, and improve the Service.
• To deliver signing requests over the channel(s) the sender chose — email, SMS, or WhatsApp.
• To produce the per-document Certificate of Completion that establishes proof-of-execution and tamper-evidence (dual SHA-256, signer audit trail).
• To process payment, send invoices, and detect fraud or abuse of the Service.
• To respond to your support requests, security disclosures, and to comply with legal obligations.
• To send service announcements (billing changes, security incidents, scheduled maintenance). Marketing email is opt-in only.

We do not sell personal information, we do not rent it, and we do not use signer documents to train any model — generic or our own.

The Service’s authoritative database, file storage, and identity provider are operated by Supabase Inc. in the AWS ca-central-1 region (Montréal, Canada). All tenant data — document bytes, signer records, audit events, membership rows — is stored in that region. Browser-to-API traffic is TLS 1.2+, and stored data is encrypted at rest using AES-256.

The marketing site and the Next.js web client are served from a global CDN; that CDN does not store tenant data — the browser makes the database queries directly, over TLS, to the Canadian project. This is the residency wedge.

A small number of sub-processors are unavoidable for normal operation. Each is subject to a Data Processing Agreement (in most cases, the sub-processor's own standard DPA that we have accepted) and uses encryption in transit and at rest:

• Supabase Inc. — database, authentication, storage, Edge Functions (ca-central-1).
• Wildbit / Postmark — transactional email delivery (USA). Email payloads are limited to envelope metadata, signer name, the document title, and the signing link.
• Stripe Payments Canada Ltd. — billing and card tokenisation (Canada).
• Netlify Inc. — static site hosting and CDN edge (global). Netlify does not see tenant data.

Workspace and document data are retained for as long as your account is active. After you cancel or request workspace deletion, your data remains available for a re-activation window of up to ninety (90) days, after which we permanently delete tenant data from the authoritative database and storage on request, or on our next scheduled purge pass. Encrypted backup snapshots, where present, roll off according to our backup retention policy with our infrastructure provider.

The per-document audit trail and Certificate of Completion are retained for the retention period your workspace configured in Trust Center (default seven years). This is the minimum supported by Ink.’s evidentiary stance — shorter retention removes the certificate’s usefulness in contract enforcement.

Billing records are retained for seven (7) years to meet Canadian tax-record requirements.

Under PIPEDA, Law 25, and equivalent Canadian provincial legislation you have the right to:

• Access the personal information we hold about you.
• Correct it where it is inaccurate or incomplete.
• Withdraw consent for processing, where consent is the legal basis, on reasonable notice.
• Request deletion of your account and the associated workspace data, subject to the retention rules above.
• Request data portability — you can download an individual signed PDF (with its embedded Certificate of Completion) directly from the workspace at any time, and we will work with you to scope and fulfil a broader workspace-level export on written request.
• Object to automated decision-making. Ink. does not currently make decisions about you using automated profiling.
• Lodge a complaint with the Office of the Privacy Commissioner of Canada or the Commission d’accès à l’information du Québec.

To exercise any of these rights, email privacy@inksign.ca. We respond within thirty (30) days. If you are a signer (not an Ink. account holder) we may direct your request to the sender that dispatched the signing request, because they are the data controller for that document.

Customers ask us this directly, so we want it in writing: we do not read your documents, your signers’ identities, or your audit-trail entries in the ordinary course of operating the Service. Not for product development, not for sales or marketing, not for model training, not for “QA,” and not out of curiosity.

We will be honest about what is technically possible. Ink. is a Software-as-a-Service platform and our engineers hold the database service-role key and the storage-bucket service-role key required to operate it. That key bypasses the per-tenant Row-Level Security that protects you from other customers. Whether or not we ever use the key on your workspace is therefore a question of policy, not a question of capability — and the policy is what follows.

Privileged access to a specific workspace, document, signer record, or audit row is taken only in one of three situations:

• You asked us to. You opened a support ticket asking us to help with a specific artifact (a stuck send, a misconfigured field, a signer who can’t open a link) and we need to look at that artifact to answer. Access is scoped to what your ticket described; we do not browse adjacent workspace state.
• We are legally compelled to. A court order, search warrant, subpoena, or other binding instrument issued by a court of competent jurisdiction in Canada requires production of specific records. We notify you before complying unless the order or applicable law prohibits notice, and we challenge over-broad or extraterritorial requests.
• An active security investigation requires it. We have a credible signal of abuse, account compromise, or ongoing breach. Access is the minimum necessary to scope and contain the incident, and we document the justification.

We do not use the service-role key for any other reason — not to generate aggregate analytics on your behalf, not to fix a bug we suspect (we ask first), not to onboard you (you onboard yourself), and not to upgrade or downgrade your plan (the Stripe webhook does that without an engineer looking).

We maintain an internal written record of privileged access taken in response to a support ticket, legal compulsion, or security investigation. We are working toward an append-only system log that records who accessed what and when; until that is in place, the record is the engineer's log entry filed against the ticket or incident that authorised the access.

One closely-related class of access is automated and worth calling out separately: Edge Functions and webhook handlers that move data between Ink. components (for example, the cross-device signing handler that mints a signed URL for a signer's baked PDF, or the Stripe webhook that updates your plan when a checkout completes). These run under service-role credentials by necessity; their scope is fixed in code that we are happy to walk a customer through on request, and no human reads what they touch. They do not constitute privileged access in the sense of this section.

Ink. uses a small number of strictly necessary cookies to keep you signed in and to remember your workspace preferences. We do not use third-party advertising or behavioural-tracking cookies, and we do not load Facebook Pixel, Google Ads conversion, or similar fingerprinting scripts.

We collect aggregated, non-identifying usage metrics (Service uptime, error rate, page-load timing) using first-party infrastructure to maintain the Service. These metrics never include document content or signer identity.

We apply industry-standard safeguards to protect personal information against loss, theft, unauthorised access, disclosure, copying, use, or modification — including:

• TLS 1.2+ for all data in transit.
• AES-256 encryption at rest.
• Row-Level Security in Postgres scoped by tenant membership.
• HMAC one-shot tokens on cross-device signing links, with timing-safe verification.
• Dual SHA-256 fingerprints on every signed PDF.
• Logical access controls, MFA on administrative accounts, and audit logging of privileged actions.

No method of transmission or storage is one hundred percent secure. If we ever experience a breach of security safeguards involving your personal information that creates a real risk of significant harm, we will notify you and the relevant Canadian regulator(s) as required by law.

We may amend this Privacy Policy from time to time. Material changes will be announced via email to workspace owners at least thirty (30) days before they take effect. The “Effective” date at the top of this page always reflects the most recent revision. Continued use of the Service after the effective date constitutes acceptance of the revised policy.

Ink Signature Inc. is the controller of the personal information described above (except where a workspace tenant is the controller of its own document content). Reach our Privacy Office at:

privacy@inksign.ca
Ink Signature Inc., Canada

For questions specific to Quebec residents under Law 25, our designated Person in Charge of the Protection of Personal Information may be reached at the same address.