Privacy Notice

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 organization is the controller and OctoDoc is the processor. We act on the Sender's documented instructions, and the data processing agreement published in the trust center at /trust is the instrument that says so.

1.3 For our own account records, billing, security logs and product analytics about Senders, OctoDoc, Inc., a Delaware corporation, 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 — a clause-level index of where signers stall — is not offered. If a per-tenant version is introduced, a Sender's index will use only 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. A cross-tenant version will not ship 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. OctoDoc 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.

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 five 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; a request log holding a truncated IP address is kept for 24 hours to stop the link being abused; and the Sender is sent a notice that the link was opened. If the Sender required an email address before the file was shown, the address you typed is in that notice, and nothing else about you is. Truncation is to the /24 for IPv4 and the /48 for IPv6.

2.3 The consent-conditional reading log contains only how long you spent on each page and the maximum depth you scrolled. Neither signal 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 decision 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, receives the opened notice described in 2.2 with the address you typed if one was required, 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 honored 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 organizations in the EU region, which have no legitimate-interest route to them under ePrivacy Article 5(3).

2.7 Read links are offered to Senders. Opening one applies the rules in 2.2 through 2.6; no consent-conditional reading data exists about a visitor who declines or sends Sec-GPC: 1.

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 defense 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 consent time, your IP address, your browser's user-agent string, whether you opened the PDF for a required disclosure, the version and hash of each consent artifact, and the geometry and value of each mark you confirmed. It is written to an append-only hash-chained ledger.

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. The Service separately records agreement to transact electronically, acceptance of the signer terms, and the statutory electronic-records disclosure when it applies. Optional per-page dwell and maximum scroll depth are offered behind a separate consent on the signing surface. Biometric capture is not offered and would require its own additional consent before collection.

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 has one login email and may hold several separately verified signing addresses, plus the documents that person has signed; it does not make that person a member of any workspace or expose another organization's data. The signing route checks that the literal invited Party address is verified on the authenticated account before it exposes a file.

3.6 This document does not establish production availability. The deployed state of the signing path, the ledger and the seal must be verified from the service.

3.7 A sender may ask a named signer or copy party to pay them a stated amount once the file is sealed. Paying is optional and separate from signing, and the payment goes to the sender's own Stripe account on a page Stripe hosts. OctoDoc records the amount, the description the sender wrote, who was asked to pay, the payment's state and the Stripe identifiers of the session, payment and refund, and keeps them for as long as the file itself. OctoDoc never receives, stores or sees a card number or bank details; Stripe collects those on its own page under its own privacy notice. The payer's name, email address and billing address are passed to the sender's Stripe account so that Stripe can send the payer the receipt and the sender can meet its own obligations to the payer; the sender is the controller of that copy. OctoDoc sends no receipt of its own. Erasing the organization deletes the payment rows; the sealed file, which prints the amount and the payer's name at the mark, follows section 5.

3.8 To deliver document notices and recover interrupted delivery, OctoDoc stores workspace, file, party and session identifiers, comparison hashes, retry and lease metadata, and provider delivery facts. Protected signing and approval credentials use separate application recovery keys and authenticated purpose boundaries. This protects recovery credentials; it does not encrypt document bytes. Provider acceptance, receiving mail server delivery, inbox placement and reading are distinct facts.

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 This tier is not yet offered, 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 it is offered.

5.1 You may ask for access to what is held about you, for it to be corrected, and for it to be erased. An Organization's owner can also download a manifest-backed export of classified tenant data and execute an account or organization erasure instruction that returns a written confirmation naming every deleted and retained class. The runbook covering those requests carries a 30-day service level. Where OctoDoc is processor, a request is passed to the Sender's organization 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 defense of legal claims. 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 not offered. 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.

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 Service sends every generated-text model request through Vercel AI Gateway with zero-data-retention routing required for that request; the launcher's closed-set judgment in 6.7 is the one request that goes elsewhere, and 6.7 says where. Where OctoDoc cannot reliably read an uploaded page as text, the request carries a rasterised IMAGE of that page rather than text, so that its words can be transcribed; only pages routed that way are sent, and no other page of the document accompanies them. The Gateway is configured to route those requests only to providers covered by its zero-data-retention arrangements, including a prompt-training opt-out. These are application controls that the Service enforces in code. The Vercel and Anthropic agreements covering these model surfaces were executed on 1 September 2026 and are filed with OctoDoc's own records.

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 register is published at /trust#subprocessors with a version and an effective date; the version in force is 2026-09-23, effective 23 September 2026. The table below is that same register.

6.5 An organization may decline model processing, and 6.3 then describes something that does not happen to its uploaded pages. The owner turns it off in the organization's profile, and while it is off no page of an uploaded file is rasterised or sent to be transcribed — a page OctoDoc cannot read as text simply stays unread. The choice is reversible in the same place, it changes nothing already uploaded or sealed, and the upload control states which of the two is true for the reader's own organization before a file is chosen. PDF upload, reviewed Word conversion, reusable PDF forms, field preparation and cited questions remain available. The same choice also governs the launcher described in 6.7.

6.6 The send-policy check is not a model request. Before a document may be sent, its text is checked against the published excluded-category ruleset at /trust by a fixed set of rules that runs inside OctoDoc, so that OctoDoc refuses the categories the federal E-SIGN Act removes from electronic signature. No part of the document leaves OctoDoc for that check. It is a condition of sending rather than a feature of reading, and declining model processing leaves it unchanged because it uses no model to switch off.

6.7 The launcher — the prompt box that turns a request you type into a place inside the product — sends that typed request, and nothing else, to TypeSafe as a single closed-set judgment that answers with a probability rather than generated text, under executed enterprise zero-data-retention terms and the vendor's published commitment not to train on inputs. It never carries document text, a file name or another party's name, and it only chooses among a closed set of destinations; it cannot create, send or sign anything. It is governed by the choice in 6.5: while model processing is declined, the launcher matches your request against that same closed set on our own servers and sends nothing to a model. The same vendor and the same terms apply to one more request, also governed by 6.5: when a sender asks a question of their own uploaded document and our own ranking cannot separate two or more passages, those tied passages and the question, and nothing else, are sent so that one can be chosen. The answer is always the document's own text, no page image is sent, and a signer's questions are never sent.

7.1 The Service runs on Vercel in the United States: the marketing pages, the sender plane, the signer surfaces, and the document work that prepares, flattens and seals a file. Private object storage, authentication and the database are provided by Supabase in the United States. Document bytes pass through the application process while a file is prepared, flattened and sealed, and the signing identity is supplied to that process as configuration; neither is written to any location a browser can reach.

7.2 An organization'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 Signed artifacts and the Ledger are HOSTED for the published retention period, subject to section 5, and this clause publishes it: at least one year from the seal for a File sealed while its Organization is on the Free plan, and at least seven years from the seal for a File sealed while its Organization holds a paid plan. A later change of plan, a cancellation or a missed payment never shortens the period that applied when a File was sealed. That window is the whole of what OctoDoc undertakes to keep. Separately, and without limit of time, a sealed PDF you hold checks against the digest its Sender published without an OctoDoc account and without OctoDoc taking part, so a copy you keep outlives anything we host. Reading-log data collected on consent follows the 13-month purge schedule; stronger identity-verification schedules attach only if that tier is 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.

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 The signer Margin answers locally from the frozen document text and does not persist a transcript or route a question to the Sender. Escalation, private-mode controls and a separately exportable transcript store are not offered.

8.4 The Margin is available on the signing surface. Consent-conditional reading telemetry is offered on read links and signing surfaces, and the sender's per-page rollup is offered for read links. Escalation and configurable kill switches are not offered.

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 organization 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 Privacy requests may be sent to privacy@octodoc.org, or by post to OctoDoc, Inc., 400 Laguna Street, San Francisco, CA 94102.

10.1 OctoDoc may send a small number of plain-text product introductions to named people at companies that published a contact address on their own website. We do not buy lists, infer addresses from naming patterns, or use enrichment services. Each row is created when a human reads a published page, records the exact URL and the date, notes whether that page carried a no-solicitation line, and records the country and entity type before any message is composed. A message carries no image and no tracking pixel.

10.2 The lawful basis depends on where the person works. In the United States, CAN-SPAM permits opt-out marketing to business addresses when the message identifies itself as an advertisement, carries a working opt-out honored within ten business days, and includes a valid physical postal address. In the United Kingdom and the European Union, we rely on legitimate interests in introducing a document product to a named person whose address the employer published for business contact, and the first message carries the source URL and date, a separate line stating the right to object to direct marketing, and a link to this section. In Canada, New Zealand and Australia we send only where the published address, the absence of a no-solicitation line and the relevance of the message to that person's role together support implied or deemed consent; New Zealand's five-working-day unsubscribe clock is the shortest in that set and is the one we honor on those rows. We do not send to jurisdictions where counsel has not closed the outbound gate.

10.3 Two personal-data classes are created. A prospect row holds the name, the work email, the source URL, the read date, the country, the entity type, the segment key and the outcomes of each touch. A suppression row holds an opted-out or hard-bounced address and the timestamp only. Prospect rows are kept for twelve months after the last lawful send or until a valid erasure request, whichever is first. Suppression rows are kept for three years after the opt-out so the address is not contacted again on any path; they hold no message body, no signal text and no source URL.

10.4 You may object to direct marketing at any time. On United Kingdom and European Union rows the first message states this right separately from the unsubscribe link, because a footer that only says unsubscribe does not discharge Article 21(4). Objections, access requests, rectification and erasure go to privacy@octodoc.org under the same thirty-day service level as every other class in section 9.

10.5 To stop prospecting messages, reply "stop" to the message, use the signed unsubscribe link in its footer, or write to privacy@octodoc.org. An opt-out is honored the same day and writes the outreach suppression table; a hard bounce retires the address immediately. Opting out of prospecting does not affect a signature request you have already received or consented product mail you asked for separately.

11.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.

11.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.

11.3 Marketing email goes to people who asked for it and to named prospects reached through published-business prospecting described in section 10. A signature request is not marketing and is not a channel we will use for it.

12.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.

12.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.

13.1 A username is an optional address for your account, not a public profile or proof of identity. Receiving by username stays off until you save an explicit choice in Profile after seeing the disclosure and your defaults.

13.2 A signed-in person preparing a document can look up your exact username and default name. Lookup does not reveal your email. Only when that person explicitly selects you into their authorized draft do we disclose your selected verified email, optional signing capacity and who you sign on behalf of. Selection does not send or sign a document, and these defaults do not establish authority to represent anyone.

13.3 The selected defaults become private facts of that draft. Later Profile edits do not rewrite those facts or signed records. A changed or ineligible selection requires a fresh check before sending. Turning receiving off prevents new username requests and does not remove access to existing records.

13.4 Unused lookup references expire after ten minutes and selected references after thirty days. Expired references disclose no defaults. Hourly cleanup removes expired references and username throttle counters older than seven days. Sending removes the file's temporary references without deleting its party facts or signing evidence.

13.5 Removing a username does not release it: it cannot be reassigned. Account deletion removes its live defaults and detaches the former account from the reserved name. The reserved name is not anonymous because outside information may still identify its former user. Historical party facts and retained signing evidence follow section 5.

14.1 Slack account linking is available in the OctoDoc Slack workspace and in a Slack workspace where an owner of your OctoDoc workspace installed the OctoDoc app through Slack's install flow. Installing the app does not link anyone's OctoDoc account. You choose linking separately in Profile, pick the Slack workspace, then enter a single-use code in a direct message with the OctoDoc app there. Your Slack email or display name does not establish your OctoDoc identity.

14.2 To provide linking, replies and web handoffs, OctoDoc processes app, workspace and member identifiers, commands and message text in memory. It stores the account and organization link, each consent version, digest and time, and a digest of each temporary linking code. It stores delivery state and time with hashed event, member and thread identifiers to prevent duplicate replies and limit abuse. These hashes are pseudonymous, not anonymous. For a file followed under 14.8, it also stores that direct message's conversation and thread identifiers unhashed, the file, and the last state it reported, so it can post there again. Raw message transcripts and callback URLs are not stored. Drafts explicitly requested under 14.9 store the reviewed form and supplied field values as OctoDoc documents. No Slack message or supplied field value is sent to AI providers.

14.3 Without a separate content consent, Slack receives account-linking notices and generic web links only. With that consent, described in 14.7, your direct messages with the OctoDoc app may also carry the titles and states of files you can already open, what each is waiting for, and cited excerpts from those files in answer to your questions. Channel messages and mentions never carry document or personal details. This integration can create private reviewed-form drafts under 14.9. It does not provide summaries or Slack attachment imports. Sending, approval, decline, signature and final field review finish on the web, and a reply links to the page where they happen. Slack holds delivered messages under the workspace's own access and retention rules; removing the OctoDoc link cannot recall those copies. A reply already in flight may still arrive.

14.4 Linking codes expire after ten minutes and work once. Hourly cleanup deletes expired, spent or revoked codes, delivery records older than 24 hours, and followed threads older than 90 days; scheduled processing also deletes a followed thread when it detects that its file is sealed, declined, withdrawn, expired or superseded. Delivery limits can delay this processing. Account links and consent remain while enabled. Removing Slack access in Profile deletes the link, consent, codes, followed threads and associated delivery records and cancels unsent replies. Account closure does the same. A verified app-uninstall or token-revocation event deletes this installation's integration data and blocks new work. A minimal app and workspace denial record remains to prevent reactivation without review; it holds no member or account identifier.

14.5 Profile lets you download your account's Slack integration records and remove access even when linking is unavailable or your workspace membership changes. Contact privacy@octodoc.org for access, correction or deletion and support@octodoc.org for help. If an uninstall event is not delivered, report it there so we can disable the installation and delete its associated data within 14 business days. Service discontinuation uses the same deletion deadline.

14.6 OctoDoc acts as controller for its account-linking, installation and security records. Slack is the chosen communication service of the organization that operates each Slack workspace; its role and terms follow that organization's agreement with Slack. This notice does not describe Slack as an OctoDoc document subprocessor. OctoDoc stores integration records with its existing United States hosting and database providers described in sections 6 and 7. Slack data is not used for model training, advertising, contact enrichment or unrelated profiling.

14.7 Document replies are a second, separate consent in Profile, shown in full before an unchecked checkbox. It authorizes your own direct messages with the OctoDoc app to carry the titles, states and next steps of files you can already open in OctoDoc, and cited excerpts from those files answered by the same local reader the web uses; your question is not sent to an AI provider. Each reply re-checks that your link, your workspace membership and both consents still hold at that moment. Turning document replies off stops new content replies and thread updates while keeping the link; removing Slack access removes every consent. Neither can recall a message Slack already holds.

14.8 Thread updates are a third, separate consent in Profile, available only while document replies are on and shown in full before an unchecked checkbox. With it, a file you ask about in a direct message with the OctoDoc app, or ask to prepare, send, approve, decline or sign there, is followed in that thread until it is sealed, declined, withdrawn, expired or superseded or 90 days pass. OctoDoc checks for changes every five minutes and attempts an update in the followed thread, subject to delivery limits and service availability. Asking about the same file in another direct-message thread moves its follow there. For a file you sent, an update gives its title, its state, how many signers have signed, a three-day expiry warning and a link; for a file sent to you, an update says only that it ended. An update never names another person or carries document text. Each update re-checks your link, your workspace membership and all three consents at that moment. Saying stop following and the file name in the thread stops that file; turning thread updates off stops every update and deletes every followed thread.

14.9 In the OctoDoc Slack workspace, with the current document consent, an explicit creation request can create a private draft from the same reviewed-form catalog used by the other OctoDoc surfaces. In any other Slack workspace, draft creation is not offered. Exact field names and supplied values may fill that draft; ambiguous facts remain unfilled. This stores the form and supplied values in your OctoDoc workspace under the document retention rules in section 8. Removing Slack access stops new requests but does not delete those documents or reverse a creation already accepted. Delete an unwanted draft from OctoDoc. No invitation, send or signature occurs from draft creation. Earlier linking and document consents do not authorize this capability; accept the current artifacts before using it.

14.10 When an owner of an OctoDoc workspace installs the OctoDoc app into a Slack workspace, OctoDoc stores the app, workspace and bot identifiers, the bot's access token encrypted with a key held only by the OctoDoc application, the OctoDoc workspace and owner that installed it, and the install time. The install is confirmed by a single-use code that expires after ten minutes, of which only a digest is stored. A Slack workspace installed from one OctoDoc workspace cannot be moved to another. A verified uninstall or token-revocation event deletes the stored token and that workspace's links, codes, followed threads and delivery records; a person's Slack consents are deleted too unless they remain linked in another installed workspace. The minimal denial record described in 14.4 remains until an owner installs the app again.