What we hold, and why.

Two UK companies run this service and both handle personal data about it. AI Search Labs Ltd (company number 16719803, Windrush House, Windrush Park Road, Witney, OX29 7DX) owns the product and the customer database. Search Intelligence Ltd (company number 09361526, Witney Business and Innovation Centre, Windrush Park Road, Brighthampton, Witney, OX29 7DX) operates the service, takes payment and answers support. They are joint controllers for account, billing, support and security data, under a written arrangement between them. The legal and company page explains the structure.

Search Intelligence Ltd is your single point of contact. A request or a complaint sent to it reaches both companies, and you can exercise every right in section 12 against either of them.

For personal data a customer puts into their own workspace, including everything about the people they ask to sign, the customer is the controller and both companies act on that customer’s instructions in running the service. If you were sent an agreement, the organisation that sent it decides what happens to your data and section 12 explains how to reach them and us.

The public pages, the sign-up and sign-in flow, the application, the API, the signing pages a counterparty opens, the retrieval and verification pages that need no account, and the emails the service sends.

Where a workspace has applied its own brand to the signing pages and the outbound email, the page still runs on our systems and this policy still applies to it.

• Your account. Name, email address, a password stored only as an Argon2id hash, your time zone and locale, the workspaces you belong to and which one is your default.
• Your place in a workspace. Your role, the permission set applied to you, whether you are an owner, and if a workspace disables you, when and the reason recorded.
• Invitations. The name and email address an invitation was sent to, who sent it, when, how many times it was resent, and whether it was accepted, declined or withdrawn. The invitation link is stored only as a SHA-256 digest.
• Sign-in sessions. The IP address and browser user agent of each sign-in, when the session was issued, last seen, rotated or revoked and why. The session token itself is stored only as a SHA-256 digest.
• Single sign-on and directory sync, where a workspace uses them: the identity provider’s address and certificate, the email domains claimed, and a digest of the directory sync token.
• API keys. The key name, its visible prefix, a digest of the key, the person it acts as, and when it was last used, expires or was revoked.
• Administrator activity. Each change to workspace settings, with the name and email of the person who made it, a plain sentence describing it, the values before and after, the time, the IP address and the user agent.
• Billing. The plan, the billing state, the renewal date, and the Stripe customer and subscription references. Your card details go to Stripe and never reach us. Stripe holds the billing address and any tax identification number you give at checkout.
• Support requests. The email address you gave, the topic, what you wrote, the reference we issue, and your workspace and user identifiers if you happened to be signed in.

A signer has no account. Their identity on the record is the name and email address the sender gave, together with what they did on the page.

• From the sender: name, email address, the role on the agreement, the stage they sign at, any private message written to them, and any access code set for them.
• What they enter: every field value they type, choose or upload, including the value as first entered where a field was later corrected, and any attachment requested from them.
• Their signature: the full name and initials as written, and the signature and initials images, whether typed in a style, drawn or uploaded.
• Consent: which version of the electronic records disclosure was accepted, when, from which IP address and with which user agent.
• The signing session: a digest of the link token, when it was issued, first used and last seen, when it expires, the IP address and user agent, and the number of failed attempts where a code was required.
• Delivery: a record of every email sent, holding the recipient name and address, the sender name and address, the subject and the full text and HTML of the message, the provider’s message identifier and the outcome. Where a message bounces or is reported as spam, the provider’s reason and its verbatim diagnostic are stored so the sender can be told the address did not work.
• Retrieval: a digest of each retrieval link, when it was created, when it expires, when it was last used and how many times.

A signer can ask the sending organisation to correct or remove what it holds about them, and can ask us as well. Section 12 explains what happens to the record itself in that case.

Every agreement carries a history that is only ever added to. Each entry holds the kind of event, the name and email of the person it concerns, the time on our server clock, the IP address the connection came from, a classification of that address as an internet provider, company network, VPN exit or mobile connection, the browser user agent, and any location the address suggests. Entries are fingerprinted with SHA-256 over their contents and over the fingerprint before them, so an entry cannot be quietly changed after the fact.

The record is the point of the product, so it works differently from the rest of the data here. It is never edited and never deleted. The name and email address on an entry are stored on the entry itself, so that the record still says who did what after the account it named has gone.

When an agreement completes, a signing certificate is issued that publishes the party names, email addresses, roles and statuses, the document names and digests, and the event list including the IP address and user agent of each event. Anyone holding the verification code can read that certificate at the check page without an account, which is what makes the record independently checkable. Those pages are not indexed by search engines and are not cached, so the protection is that the code is unguessable and given only to the people on the agreement.

An IP address shows where a connection came from and not where a person was. The certificate says so on its face, and the evidence page sets out what the record demonstrates and what it does not.

Where the basis is legitimate interests, we have weighed those interests against the rights of the people concerned, and you can object under section 12.

Four companies process personal data on our behalf. Each is bound by a written agreement, may use the data only to provide its service to us, and may not use it for its own purposes.

Data is also disclosed to our professional advisers under a duty of confidence, to a public authority where the law requires it, and to a buyer and its advisers if either company is sold or reorganised.

Uploaded documents and their contents are never used to train a machine learning model, ours or anybody else’s.

The database and the application both run in London. Documents, rasterised pages, signature images and brand logos are stored in the same database as everything else, in that one region.

Payment and email processing reach outside the United Kingdom, as the table in section 7 shows. Those transfers are covered by the UK international data transfer agreement or the addendum to the standard contractual clauses, together with the measures each provider applies. You can ask us for details of the safeguards used.

The owner of a workspace can close it themselves, from Your data inside the product. Closing stops the workspace sending straight away. Any agreement still out for signature is withdrawn and the people signing it are told, the links they were sent stop working, and open invitations are withdrawn.

Everything in the table above is kept when a workspace closes, and each row says so on its face. Finished agreements stay with their documents, their evidence record and their signing certificate, because the other people on an agreement can still ask for their signed copy and check it against the record. A signature is worth having a year later only if it is still there a year later, and a counterparty’s claim on their own copy is not one the sender gets to end. Verification codes go on working for the same reason, at the check page, with no account.

Section 12 sets out how to ask us about the personal data held about you, including after a workspace has closed. Where a request concerns data a customer put into their own workspace about their own signers, that customer is the controller and we act on their instructions, which is the split set out in section 1.

• Traffic to the service is encrypted in transit, and the database is reached over an encrypted connection.
• Passwords are stored as Argon2id hashes with a per-password salt and parameters set to the OWASP baseline. The password itself is never stored.
• Sign-in sessions use opaque tokens stored only as SHA-256 digests, rotated every fifteen minutes, in a cookie that JavaScript cannot read and that is marked secure in production.
• Signing links, retrieval links, workspace invitations, API keys and directory sync tokens are stored only as SHA-256 digests, so a copy of the database row is not a working link.
• A signing link is single-use in the sense that it covers one visit, it expires seven days after it is issued, and where a code is required it allows three attempts before it stops working.
• Document bytes are served only to a signed-in member of the workspace that owns them or to the holder of a valid signing or retrieval link, and the identifier being hard to guess is never treated as sufficient on its own.
• Brand logos are served publicly, because a signer has no account and a mail client sends no cookies. That endpoint reads only the logo store, is addressed by the digest of the file, accepts PNG, JPEG and WebP, and is served with a policy that stops the file executing anything.
• Webhook deliveries are signed over the timestamp and the body so an integrator can tell a genuine call from a forged one, and an endpoint that keeps failing is disabled.
• Every write to the evidence record commits in the same database transaction as the change it describes, so a change without its record cannot exist.

The service sets one cookie. It holds an opaque sign-in token, is marked HttpOnly so scripts cannot read it, uses the Lax same-site policy, and is marked secure in production. It exists so that you stay signed in, and it is the only cookie the service needs to work.

A signer is not asked to accept a cookie, because the signing link carries the authorisation and no cookie is set for them.

Under UK data protection law you can ask us to:

• give you a copy of the personal data we hold about you;
• correct data that is wrong or incomplete;
• delete data where there is no longer a good reason to hold it;
• restrict how we use it while a question about it is resolved;
• hand over data you gave us in a portable form, or send it to another provider;
• stop processing based on legitimate interests, by objecting and telling us why;
• withdraw a consent you gave, which does not affect anything done before you withdrew it.

Write to us through the support form, which works without an account. We answer within one month, and tell you inside that month if a complicated request needs up to two months more. We may ask you to confirm who you are before we act.

Where the data sits inside a customer’s workspace, that customer is the controller and we pass your request to them and help them answer it. If you were sent an agreement, the organisation named on it is the one to ask first.

One limit is worth stating plainly. The evidence record for an agreement is what makes that agreement checkable by both sides, and removing an entry from it would break the chain for everyone who relies on it. Where you ask for erasure of data held in the record, we will explain what can be removed, what must stay, and why, and you can complain to the regulator if you disagree with the answer.

If personal data is exposed and there is a risk to the people it concerns, we report it to the Information Commissioner’s Office within 72 hours of becoming aware of it. Where the risk to those people is high, we tell them directly and say what happened, what it means and what we are doing about it.

An account holder must be at least 18. The service is aimed at businesses and is not directed at children. If you believe a child’s data has reached us, tell us through the support form and we will deal with it.

We update this page when what we do changes. The date at the top is the date of the current version. Where a change materially affects how personal data is used, we tell workspace owners by email before it takes effect.

The support form reaches both companies and needs no account. Written notice can be sent to either registered office.

• Search Intelligence Ltd, Witney Business and Innovation Centre, Windrush Park Road, Brighthampton, Witney, OX29 7DX, United Kingdom. This is the single point of contact for anything in this policy.
• AI Search Labs Ltd, Windrush House, Windrush Park Road, Witney, OX29 7DX, United Kingdom.

You can complain to the Information Commissioner’s Office, Wycliffe House, Water Lane, Wilmslow, Cheshire, SK9 5AF, or through ico.org.uk. We would rather you came to us first so we can put it right.