LEGAL
Privacy Notice
What is recorded about you when you create, send or sign a file, written so a signer can read it before the first thing is collected.
Document status
Published for review before launch. This notice is not yet effective because OctoDoc's operating entity has not been incorporated or named.
Features described as unavailable are not currently collecting data. The effective notice will identify the controller, contact route and effective date before the service launches.
Read links, reading telemetry, the Margin, stronger identity verification, public verification and proof files are post-v1. Sections about them are specifications for later capabilities, not statements that those capabilities are available.
A v1 Signer uses a free account whose verified address matches the invited Party. The honest time to explain the signing record is before collection begins, not after the person has signed.
01
Who this covers, and in which role
1.1 Three groups of people appear in this notice. A "Sender" is someone with an account who uploads a file and routes it for signature. A "Signer" is someone with a free account who receives and signs that file. Someone "On Copy" receives a copy of the sealed file without signing. Signers and On Copy together are the "Parties", and they are the people with the least relationship to us and the most recorded about them.
1.2 For the contents of a file and for everything recorded about a Party in the course of signing it, the Sender's organisation is the controller and OctoDoc is the processor. We act on the Sender's documented instructions, and the data processing agreement at /dpa is the instrument that says so.
1.3 For our own account records, billing, security logs and product analytics about Senders, OctoDoc is the controller. That is a genuinely different role with a different lawful basis, and the two are not merged.
1.4 The friction map — the clause-level index of where signers stall — is per-tenant only. A Sender's index is built from that Sender's own files, for that Sender, with OctoDoc as processor. Aggregating it across tenants would make us controller of behavioural data about people who never chose us, and it is a decision that has been taken explicitly rather than allowed to happen as a benchmarking feature. It is not built, and it will not ship cross-tenant without its own lawful basis, its own purpose statement here, and an opt-out.
1.5 Nothing on this page is a claim that OctoDoc staff can read your documents. The single named platform operator can see platform-wide counts and operational event types, but the console excludes tenant and target identifiers, personal data, document content, payloads, hashes, IP addresses and user agents. Operator status is not a document key and grants no access to a tenant's rows. V1 uses private Supabase Storage and does not use a per-file encryption key or make a WORM claim. A support need that genuinely requires a tenant's data requires a break-glass flow with recorded consent, bounded scope, an audit row per read and a notification afterwards.
02
The read link, and what fires before you agree to anything
2.1 A read link is a URL a Sender shares instead of an email attachment. Opening one is the moment at which the most is collected from a person who has agreed to nothing, so it gets the strictest rule in this notice and its own consent gate.
2.2 Before you have given an affirmative answer, exactly four things happen and no others: the file is served to you; an opaque session cookie is set so the page works; a single row records that the link was opened; and a request log holding a truncated IP address is kept for 24 hours to stop the link being abused. Truncation is to the /24 for IPv4 and the /48 for IPv6.
2.3 Everything else is consent-conditional: how long you spent on each page, how far you scrolled, where you stopped, whether you forwarded it. None of it is collected until you have said yes on a full-width block shown before the first page renders, and the answer is recorded as a versioned, hashed event so it can be shown later to have been asked.
2.4 If you decline, the Sender is told that you opened the link and that you declined, and is told nothing else. That the decline itself is visible to them is disclosed here because it is a fact about you that they learn.
2.5 A Sec-GPC: 1 header on your request is a declined answer. It is honoured as a standing opt-out of every consent-conditional collection, you are not asked again, and there is no Sender setting that overrides it. The Do Not Track header is not parsed, not logged, and never reaches the reading log or the proof file.
2.6 Device fingerprinting and TLS fingerprinting were specified for this product and have been removed from it, not switched off. There is no configuration that re-enables them. If they are ever reintroduced they will be consent-gated everywhere and unavailable entirely to organisations in the EU region, which have no legitimate-interest route to them under ePrivacy Article 5(3).
2.7 None of this is running. The read link and the reading log are unbuilt, so no reading data exists about anyone. This section is the contract the feature has to be built against.
03
Signing, and the record that cannot be optional
3.1 A signature is only worth anything if there is a record of who made it, when, and what they were shown. That record is collected under Article 6(1)(f) for the establishment, exercise and defence of legal claims, and it is not optional: you cannot decline it and still sign. You can read exactly what it contains before you start, which is the trade this notice is making explicit rather than burying.
3.2 The record holds the time, your IP address, your browser's user-agent string, which pages you opened, the exact text of every disclosure you were shown and your answer to each, and the geometry of each mark you placed. It is written to an append-only hash-chained ledger, and the ledger is what makes the record checkable by someone who does not trust either of us.
3.3 The consents are separate because they are legally distinct, and merging them into one checkbox is both a legal defect and a dark pattern. Consent to do business electronically, the statutory electronic-records disclosure, acceptance of the signer terms, the optional page-timing consent above and — where identity verification applies — the biometric release are five separate answers with five separate records.
3.4 Every page can be downloaded and printed before you sign and after, and there is a review screen before the final action so you can correct your own mistake before it becomes a signature. Both exist because the law requires them, and both are stated here so you know to expect them.
3.5 Signers are never charged. A signer account holds verified addresses and the documents that person has signed; it does not create a Sending Seat or expose another organisation's data. The signing route checks that the authenticated address matches the invited Party before it exposes a file.
3.6 This document does not establish production availability. The signing path, ledger and basic seal belong to v1, and their deployed state must be verified from the service.
04
Identity verification and biometric data
4.1 The highest identity tier would ask for a government ID and a liveness selfie, checked by a third-party vendor. That involves a biometric identifier, which is the most sensitive thing this product would ever touch and the only category with an uncapped private right of action in a US state.
4.2 Before any such capture, and before the vendor's code loads a frame rather than after, you would be shown written notice of what is collected, the specific purpose, and the length of term of collection and storage, and asked for a separate written release. An electronic signature is a valid written release; a bundled checkbox is not, and this consent is never merged into any other.
4.3 The retention schedule and destruction guidelines would be published before we ever hold a biometric identifier, not afterwards: destruction on satisfaction of the purpose or within three years of your last interaction, whichever comes first.
4.4 The tier is not built, no vendor is selected, and no biometric identifier has ever been collected by this product. Vendor selection, on-device processing, statutory possession and regional availability will be settled and disclosed before this tier is offered.
05
Deletion, and the one thing that cannot be deleted
5.1 You may ask for access to what is held about you, for it to be corrected, and for it to be erased. The runbook covering those requests carries a 30-day service level. Where OctoDoc is processor, a request is passed to the Sender's organisation as controller and we assist them; where OctoDoc is controller, we answer it ourselves.
5.2 Signed artifacts and the evidence block of the Ledger may be retained where Article 17(3)(e) applies for the establishment, exercise or defence of legal claims. V1 storage is administrator-removable private Supabase Storage, not Object Lock, and this notice does not claim physical undeletability.
5.3 Per-file encryption, crypto-shredding and public erased-state verification are post-v1 designs. V1 erasure uses deletion under the controller's instructions and applicable legal-retention limits.
5.4 No database relationship may make a person undeletable. Where a user's identity is preserved as evidence that they confirmed something, the user record is tombstoned and the two are decoupled, rather than the person being retained because a foreign key points at them.
| Data class | Erasable on request | Mechanism |
|---|---|---|
| Reading log, page timing, scroll depth | Yes | Row delete, with a 13-month expiry job as a backstop |
| Margin questions and answers | Yes | Segregated store, exported and deleted independently of the document |
| Identity-verification evidence | Yes | 30-day expiry here, plus a deletion request to the vendor |
| Account, billing and product analytics | Yes | Standard deletion |
| Sealed artifacts and the ledger evidence block | Subject to the Art. 17(3)(e) legal-claims exception | Delete when no lawful retention ground applies; no v1 Object Lock or crypto-shredding claim |
06
Every subprocessor, and whether it sees your document
6.1 The two columns that matter are the last two. Most of this list never sees a document and never sees a party's name, and saying which is which is more useful than the list itself.
6.2 The ledger never enters a logging or analytics vendor, and neither does document content or signer personal data. No observability vendor is connected to any surface today. When one is, that boundary is enforced by an allowlist of field names in the exporter that drops everything else, rather than by a policy someone has to remember — but the exporter does not exist yet, so today the guarantee rests on there being nothing to export to.
6.3 The model provider will operate under a contractual prohibition on training on customer content and on retention. The provider and governing addendum will be identified before document processing is offered.
6.4 At least 30 days' notice is given before a subprocessor is added or replaced, and a customer may object and terminate the affected subscription for a prorated refund if we proceed. The authoritative versioned register lives with the data processing agreement.
| Subprocessor | Purpose | Location | Document content | Party personal data |
|---|---|---|---|---|
| Vercel | Sender and marketing hosting | US | No | Sender only |
| Fly.io | Document plane and workers | US | Yes | Yes |
| Supabase | Database, authentication and private object storage | US | Yes | Yes |
| Anthropic | Sender drafting, edit proposals and cited insights | US | Yes | Incidentally, where a document holds it |
| Vercel AI Gateway | Transport for sender model calls | US | Yes | Incidentally |
| Resend | Signature requests, reminders, copies | US | Filenames and subjects only | Yes |
| Stripe | Billing | US | No | Sender only |
| Sentry, Grafana Cloud | Errors and metrics | US | No, enforced | No, enforced |
07
Where data lives, and how long
7.1 The sender and marketing plane runs on Vercel in the United States and holds no document bytes and no private signing keys. The document plane, the signer surfaces and the workers run in the Pacific Northwest, and private object storage, authentication and the database are provided by Supabase in the United States.
7.2 An organisation's region is fixed when it is created and cannot be changed afterwards. Serving another region is a separate deployment, not a migration of your data. EU and UK residency are not offered today, and that is stated as an absence rather than left to be inferred.
7.3 V1 signed artifacts and the Ledger are retained for the published v1 period, subject to section 5. Reading-log and stronger identity-verification schedules attach only if those post-v1 capabilities are made available.
7.4 Transfers out of the EEA or the UK would rely on the Standard Contractual Clauses carried by the data processing agreement. A transfer impact assessment will be finalised before OctoDoc accepts its first customer in either region.
08
The Margin, and what happens to what you ask it
8.1 The Margin is the assistant a signer can ask about the file in front of them. It quotes the file and cites the page it quoted. It gives no advice, it will not tell you whether to sign, and it is not a substitute for the advice of an attorney.
8.2 What it writes never enters the signed file. Nothing it produces is part of the bytes that are hashed and sealed, and every mark bound into a sealed file requires a human confirmation recorded against that exact geometry.
8.3 Questions you ask reach the Sender only where the answer routes to them, and you are told which of those you are doing before you ask. A question asked privately is not shown to the Sender. Prompts and answers are held in a store separate from the documents, so they can be exported and deleted on their own.
8.4 The Margin is post-v1. This section applies only if it is made available and is not a statement about production use.
09
Your rights, and how to use them
9.1 Depending on where you live you have some or all of the rights below. Where OctoDoc is processor we route the request to the Sender's organisation and assist; where we are controller we answer it. Either way the 30-day service level applies and you are told which of the two happened.
9.2 A monitored privacy contact and request route will be published with the effective notice before launch.
- 1Access — A copy of what is held about you, and what it is used for
- 2Rectification — Correction of anything inaccurate, including a misspelled party name on a record
- 3Erasure — Deletion, subject to the single disclosed carve-out in section 5
- 4Portability — Your data in a machine-readable form, including a full export before you leave
- 5Objection — To processing based on legitimate interests, including the security and abuse logs
- 6Withdraw consent — For anything collected on consent, at any time, without affecting signing
- 7Opt-out signal — Sec-GPC honoured as a standing decline, with no re-ask
- 8Complain — To your supervisory authority, without going through us first
10
Children, and marketing
10.1 The Service is not directed at children and is not intended for anyone under 18. We do not knowingly collect personal data from children, and where we learn we have, it is deleted.
10.2 We do not sell personal data and we do not share it for cross-context behavioural advertising. There is no advertising pixel, no third-party analytics beacon and no session-replay script on any surface where a document, a party name or a hash is visible.
10.3 Marketing email goes to Senders who asked for it and carries a working unsubscribe link. A signature request is not marketing and is not a channel we will use for it.
11
Changes to this notice
11.1 Material changes are announced before they take effect, and the version of this notice a signer was shown at the moment of collection is recorded with their consent — so what you were told is a fact about the record, not a claim about a page that has since been edited.
11.2 A change that widens what is collected, or that changes who acts as controller, is not applied retroactively to data already collected under an earlier version.