Privacy notice

DrakonSign is operated by Drakon Systems Ltd, a company registered in England and Wales (company number 16867343), registered office 34 Lumina Way, London EN1 1FS, ICO registration C1833149 (“we”, “us”). This notice explains what personal data we process, why, and what rights you have under the UK GDPR and the Data Protection Act 2018. Contact for anything privacy-related: support@drakonsystems.com.

Our roles under UK GDPR

For customer account data (the business that subscribes: contact details, billing records, API usage) we are the data controller.

For the content of documents sent for signature, our customer is the controller and we are their processor: we handle that content only to run the signing ceremony on their instructions. Our data processing terms form part of the terms of service you accept when you subscribe; a standalone data processing agreement is available and can be countersigned on request.

For the tamper-evident audit trail we generate — the chained record of signing events, including signer IP and browser — we act as a controller in our own right. We determine that this record is created and how long it is kept, because its purpose is to give both parties evidence designed to support authenticity and attribution. It does not guarantee that a signature is genuine or any legal result. Being straight about this matters: it means we, not just our customer, owe signers the duties a controller owes.

What we process, and why

Cookies: two, and only when you sign in

DrakonSign sets two cookies, and only on the dashboard sign-in journey. Neither is a tracker and neither is optional to the thing you asked for.

The first is a session cookie named ds_session that keeps you signed in. It is marked HttpOnly and Secure, so no script can read it and it only ever travels over HTTPS. It ends at whichever of three things happens first: you sign out, 7 days pass without you using it, or 14 days pass since you signed in. The 7-day idle clock and the 14-day absolute clock are both enforced on our servers on every request, not just by the cookie’s own expiry, which your browser controls.

The second is ds_mfa, and you only receive it if you have turned on two-step sign-in. It carries the short-lived ticket between your email link and your authenticator code — nothing else — and it is deleted as soon as the second step succeeds, when you sign out, or after about ten minutes, whichever comes first. It is HttpOnly, Secure and SameSite=Lax on the same terms as the session cookie, and it contains no account details: just an opaque one-time value.

We run no analytics, advertising or tracking cookies, and no third-party scripts or fonts; every asset is served from our own domain. Signing pages set no cookies at all. If someone sends you a document to sign, you never receive one: your signing session is held in the page itself and sent back to us in a request header.

There is no cookie banner, and there does not need to be one. A cookie that is strictly necessary to deliver a service you have asked for is exempt from the consent requirement under regulation 6(4) of the Privacy and Electronic Communications Regulations. Keeping you signed in to the dashboard you just signed in to is exactly that, and so is carrying a two-step sign-in you started from one screen to the next. Analytics and advertising cookies would need your consent — which is one of the reasons we do not use any.

If you subscribe, checkout runs on stripe.com, which applies its own cookie policy.

Where your data lives

The application and database run in London, United Kingdom, on Fly.io; your document content is stored separately, in a Tigris bucket configured as single-region London, United Kingdom. Everything is encrypted in transit and at rest, and the live copies of your document content and signing records stay in London. Encrypted nightly backup archives are also written to the globally distributed Tigris service described below. Because our hosting and storage providers are US-headquartered, remote access from the US is possible and counts as an international transfer under UK GDPR — where that happens it is covered by the safeguards described below.

There is one exception, and it is entirely your choice: if you switch on the optional AI features, text from the documents you have them analyse is sent to Anthropic in the United States. Those features are off unless you turn them on. Leave them off and no document content is sent to Anthropic; the separate globally distributed backup copies are described below.

Sub-processors and international transfers

We use a small number of sub-processors. Some are US-headquartered companies, so limited personal data may be transferred to, or accessible from, the United States. Where that happens we rely on appropriate safeguards under UK GDPR — the UK International Data Transfer Agreement or Addendum to the EU Standard Contractual Clauses, or an adequacy decision where one applies.

• Fly.io (US-headquartered) — infrastructure hosting. Our application and database are pinned to Fly’s London (lhr) region.
• Tigris Data (US-headquartered) — live document storage and encrypted off-site backup storage, in two separate buckets with separate credentials. Your document content — uploads, completed signed PDFs and certificates of completion — is held in a bucket configured as single-region London (lhr), United Kingdom. Full nightly backups of the database and the document store are written to a different Tigris bucket and kept for 30 days; that backup bucket is globally distributed, so — unlike the live service — those backups are not confined to the UK or the EU. We would rather say so than imply a guarantee we do not operate.
• Resend (US-headquartered) — transactional email delivery for signing links, one-time verification codes, reminders, protected completion/evidence links, authenticated-decline alerts, cancellation notices, dashboard magic sign-in links and provisioning welcome messages (signer/recipient/user email and document title where applicable). We do not represent its infrastructure as confined to the UK or EU.
• Stripe (US-headquartered, with UK/EU entities) — subscription payments for customers who buy a plan.
• DigiCert (US-headquartered) — RFC 3161 trusted timestamping. We send a cryptographic digest to their public timestamp authority and receive a signed token back; no document content is transmitted. Their independence from us is precisely what makes the timestamp worth anything. This digest transfer occurs in production because timestamping is active by default. An executed UK IDTA or UK Addendum has not yet been verified; that is an open pre-sales/legal gap, and sending only a digest is not by itself an Article 46 safeguard.
• Anthropic (US-headquartered) — the optional AI features below, and only for organisations that have switched them on. They are off by default; while they are off, nothing is sent to Anthropic.

Webhooks you configure are not a sub-processor. If someone in your workspace sets up an outbound webhook, we send an HTTPS request to the address you chose whenever one of the events you subscribed to happens. That is a transfer we make on your instruction, to a system you control — not a company we appointed — so it is not in the list above. If the address you give us is outside the UK or the EEA, that onward transfer is yours to make lawful.

Outbound webhooks (optional, and off unless you set one up)

A webhook destination is an HTTPS address you register so your own systems hear about envelope events — viewed, completed, declined, voided — without polling us. Nothing is sent anywhere until an owner in your workspace creates one, and disabling or deleting it stops both future events and anything still queued.

What we send is deliberately thin, and the content is fixed by us rather than chosen per request: your organisation identifier, the envelope identifier, its status and timestamps, how many signers there are and how many have signed, the opaque identifier of the recipient whose action raised the event, and links back to the signed-in service. It does not contain any signer’s name or email address, the document title, any field value, any typed signature, any document content, or any fingerprint of a document or certificate. Anything more than that is one authenticated API call away, where the caller has to prove who they are.

Every request is signed with a secret unique to that destination (HMAC-SHA256 over a timestamp and the exact bytes of the request), shown to you once when you create or rotate it and stored encrypted under a key held only by us. We connect only to publicly resolvable HTTPS addresses, we verify the destination’s TLS certificate, and we never follow a redirect. Delivery is at-least-once — the same delivery identifier can arrive more than once, and your receiver should ignore one it has already handled. We keep a record of each delivery attempt (status, HTTP response code, and the exact body we sent) for 30 days so you can debug your receiver, and then delete it.

Optional AI features

DrakonSign can use Anthropic’s Claude models for two things: summarising a document in plain English for the person being asked to sign it, and flagging notable clauses to the sender before they send it. Doing either means sending text extracted from that document to Anthropic’s API in the United States.

We are not willing to make that trade on your behalf. These features are disabled by default for every organisation, including existing ones, and stay off until your organisation chooses to enable them. That is a deliberate decision: London hosting for the live service and precise control of international transfers matter, and no convenience feature gets to quietly widen them.

If you do enable them, Anthropic acts as our sub-processor, the transfer relies on the safeguards described above, and under Anthropic’s commercial terms your content is not used to train their models. Only document text is sent, only for the documents being analysed — never typed signatures, one-time codes or the audit trail. What comes back is advisory only: it is not legal advice, it is not added to the document you sign, and it never becomes part of the evidential record. Turning the features off stops any further text being sent.

DrakonSign captures typed signature text only. It does not capture drawn signature images. Typed field values are stored with the envelope until erasure and their digests may remain in the evidential audit residue described below.

How long we keep things

Documents, signed artifacts and audit trails are retained while the sending customer’s account is active, because their entire purpose is long-term evidence.

Account sign-in records are kept for 30 days after the session ends. A device row survives while that device is signed in. It ends at whichever comes first: you sign it out or revoke it, 7 days pass without use, or its 14-day lifetime runs out — and the row is deleted 30 days after that moment by an automatic housekeeping pass, not 30 days after the latest of them. Every finished two-step sign-in ticket is deleted on the same 30-day rule, except that a ticket still owed you an “unfinished sign-in” email is kept until that email has been queued. Live sessions are never removed by that pass, whatever their age. Closing your account deletes all of them immediately.

Spent invitations are kept for 30 days, on the same clock. An invitation ends when it is accepted, withdrawn, or simply expires unused — whichever comes first — and the row is deleted 30 days after that moment by the same housekeeping pass. A pending invitation is never removed by it. The workspace activity log is kept while the workspace is open, because it is the organisation’s record of who was given and denied access to its own documents; closing the account deletes the invitations and the activity log outright, and neither is retained as evidence the way a signed envelope’s audit trail is.

You can delete specific envelopes yourself, at any time, from the dashboard or the API. The live database deletion is immediate and irreversible; file removal is then verified. If the file store cannot confirm removal, the response reports cleanup pending and the recovery sweep retries it. Files and field values are destroyed outright, not merely marked hidden. Closing your account removes access, users, keys and live database content in the closure transaction and verifies the live file-store purge. If that filesystem cleanup cannot be confirmed, the response says so, our operators are alerted and the recovery sweep retries it. If you’d rather we do it, or you need help, email support@drakonsystems.com.

A closed account’s redacted organisation row retains its opaque Stripe Customer ID as a billing-reconciliation handle. The closure timestamp means a late Stripe webhook cannot restore access, plan or allowance. We use the handle to verify subscription cancellation and support later Stripe-side retention, deletion or redaction review. This release does not automatically delete a Stripe Customer or put that handle on a timer; support removes it when reconciliation and applicable tax, accounting and payment-record duties permit. You may ask us to review it at support@drakonsystems.com; Stripe may independently retain records it is legally required to keep.

Lifecycle-email delivery data is minimized sooner. Signing-invitation, cancellation, reminder, OTP, completion, authenticated-decline, dashboard sign-in, post-checkout welcome, new-sign-in and account-security-event rows include the recipient, document title and frozen provider request; invitations and reminders also include their fresh signing links; dashboard sign-in and welcome rows contain a fresh single-use login link; each acting signer’s completion request also includes a personal receipt-page link specific to that signer. New-sign-in and account-security-event rows carry no link and no code at all — deliberately, because a one-click action in a security warning is a phishing template — but their frozen request does contain the IP address and device description of the sign-in or change being reported, because that is the fact you need to judge it. A pending OTP request temporarily contains its plaintext code; a keyed candidate hash and request IP/browser metadata wait for provider acceptance. Acceptance activates the challenge only inside its original first-attempt expiry window and only if it is the newest accepted sequence, then appends otp_sent atomically. A delayed or older acceptance is recorded but its credential is invalidated; automatic recovery never resubmits once the original window lacks provider-timeout and clock-skew headroom, and instead terminalizes and redacts that unusable request so a fresh code can be requested. Terminal redaction or erasure removes those duplicated values. Invitation token hashes, frozen requests and sent audit events commit before any provider call. Completion transactionally queues the owner and every acting signer. Each signer receives one personal bearer link to an inert receipt page, not an artifact URL. Explicit browser confirmation names one artifact and mints a short-lived, artifact-bound header session; only then can that SHA-verified completed signed PDF or certificate be returned and audited. Dedicated receipt/session credential columns store only hashes, but an unredacted frozen provider request necessarily contains the raw link it must submit. The payload is redacted under the rules below, and envelope erasure deletes the row and credential hashes. Once the email provider accepts or authoritatively rejects a payload or its content, we immediately redact the duplicated recipient email, document title and frozen provider payload. An unsubmitted manual-review row has a 30-day target and is then terminalized and redacted. If explicit durable state says a request may have crossed the provider boundary, it stays fail-closed beyond that target and blocks envelope erasure and account closure until our support team performs controlled reconciliation after all old application processes/containers have been affirmatively terminated. No dashboard or API caller can assert what the provider did. Status, payload hash and provider identifiers remain for operational audit. Deleting the envelope removes any unsubmitted notice immediately. A live submitting row blocks while its worker could still run; after recovery, a provably unsubmitted row is erasable. If submission may already have crossed the provider boundary, erasure makes a bounded wait for a normal in-progress submission. If that wait expires, the request returns a temporary 503 and does not report erasure or account closure; retry after delivery settles. A worker/fence failure instead remains blocked for explicit support reconciliation; it never reports completion while the outcome is unresolved. Signing or declining can still complete if a reminder outcome is uncertain: the link is revoked and durable state records that a stale reminder may arrive. This does not remove the erasure/account-closure block while duplicated personal data remains.

Optional AI calls are also coordinated with erasure. Before extracted document text can reach Anthropic, DrakonSign commits a transient provider-boundary row under the same organisation/envelope delivery fences. It contains opaque identifiers, operation kind and time only — never document text or model output. Erasure or closure either wins the final locked check so no call starts, waits through a healthy bounded call, or remains blocked if a lost worker may still submit. Support clears a stranded boundary only with a maintenance-only CLI after every old application process or container has been affirmatively terminated. The command requires exact stopped-app proof, records actor and incident/change provenance in the document audit trail, emits an operations alert and has no customer HTTP route; connection loss alone is never treated as proof that erasure is safe.

Correction lineage retains a PII-free tombstone after envelope erasure or account closure: organisation, source and successor UUIDs and creation time only. It contains no title, recipient, correction reason or file content, and prevents a deleted replacement from opening a second direct correction branch.

A content-free allowance ledger also keeps opaque organisation/document UUIDs, consumption time and whether the allowance was trial or paid. It prevents deletion from refunding quota and prevents delayed billing reconciliation from erasing paid usage; it contains no title, recipient or file content.

Backups, said honestly. A deleted document leaves the live system at once and never appears in any future backup, but backups already written are immutable dated archives — we do not surgically edit them, because an archive that can be rewritten is not a backup. Those copies age out with ordinary rotation within 30 days, and are only ever read to restore the service after a failure. Anyone who tells you deletion is instantaneous everywhere, including their backups, is describing something other than how backups work.

One carve-out: where an envelope has already been signed, we may retain its audit records even after a deletion request, so far as necessary to establish, exercise or defend legal claims — the exemption in UK GDPR Article 17(3)(e). This protects both parties’ ability to rely on the signature later. We will still delete the underlying document content on request; it is the evidential record of the signing that may be preserved.

Concretely, what survives the deletion of a signed envelope is the audit trail itself: the event log with its timestamps, the IP address and browser recorded against browser-driven events, the signer identifiers those events reference, the SHA-256 fingerprints of the document and certificate, and any timestamp token. Signer names and email addresses are redacted. Where a signer typed a reason for declining, that reason is part of a hashed event and is retained with it. The events cannot be edited without destroying the chain that makes them worth keeping — that is the trade this carve-out exists to make, and we would rather describe the residue precisely than call it “anonymised”.

Your rights

You have the rights of access, rectification, erasure, restriction, portability and objection. If you are a signer, two controllers may be involved: for the content of your document the sender is the controller, so we’ll route those requests to them and help them honour them; for the audit-trail record we generate (your signing events, IP and browser) we are the controller and will handle your request ourselves, subject to the legal-claims retention described above. Either way, email support@drakonsystems.com and we’ll make sure it reaches the right controller; we respond within one month. You can also complain to the Information Commissioner’s Office (ico.org.uk).

Changes

We’ll update this notice as the product evolves and change the date at the top. Material changes affecting customers are notified by email.