Trust

Everything a reviewer asks for, including the answers that are no.

The register, the flow, the measures and the ruleset — each rendered from the same value the published instruments read, so no two of them can disagree.

Nothing on this page is a certification. OctoDoc holds none, and /security lists which ones by name.

What exists, and what does not

A trust center is only useful if it is complete in both directions, so the absences are rows in this table rather than a paragraph further down.

Artifact	Status	Where
Sub-processor register	Published, version 2026-08-04	This page, and every legal instrument
Data flow	Published	This page
Retention and deletion	Published	Privacy notice, sections 5 and 7
Technical and organisational measures	Published, with each measure's real status	This page, from DPA Annex II
Send-policy ruleset	Published, version 1.0.0	/octodoc-policy-ruleset-v1.0.json
Outside-counsel review of that ruleset	Not recorded	Stated in the ruleset file itself
Incident history	No incident to report	This page
AI classification memos	Not published	Neither memo is written
Data-flow diagram	Not published as a diagram	The flow is published as text on this page
SOC 2, ISO 27001, HIPAA BAA, penetration test	None held	/security
Legal entity and registration	Not incorporated	Stated on every instrument

The sub-processor register

This is the authoritative register. Version 2026-08-04, effective 4 August 2026.

At least 30 days' notice is given before a provider is added or replaced. Within that period a customer may object on reasonable grounds relating to data protection, and if we cannot accommodate the objection the affected subscription may be terminated for a prorated refund.

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. A row marked "No — planned only" holds nothing today and will not before the named capability is available; it is published in advance so a reviewer can object before engagement rather than after.

The same rows render on the privacy notice and inside the data processing agreement, from this one source, so the three cannot disagree.

Sub-processor	Purpose	Location	Document content	Party personal data	Engaged today
Vercel (including AI Gateway)	Application hosting, document processing and transport for model calls	US	Yes — while preparing, flattening or sealing, and as bounded model context under required zero-data-retention routing	Yes — application requests and incidental document content	Yes
Supabase	Postgres, authentication and private object storage	US, us-west-2	Yes — including page bytes in private Storage	Yes	Yes
Cloudflare	Authoritative DNS and inbound email routing for the OctoDoc domain	US	No	No signer data; operational inbound email may contain personal data	Yes
Resend	Account email, signature requests, reminders, sealed-copy delivery and the early-access mailing list	US	Document names and email content, never page bytes	Yes — name and email address	Yes
Stripe	Subscription billing	US	No	Sender billing data only	Yes
Anthropic	Document authoring, edit proposals, classification and cited questions	US	Yes — bounded document content routed by the Gateway under required zero-data-retention and prompt-training opt-out controls	Incidentally, where document content contains it	Yes
Twilio Verify	One-time passcode delivery for a future stronger-identity tier	US	No	Telephone number	No — planned only
Identity-verification vendor	Government identity document, selfie and liveness checks for a future verified-identity tier	Not selected	No	Yes — including biometric data	No — planned only; Vendor not selected
AATL-member certificate authority	Future managed document signing	US or EU	Document hash only, never bytes	No	No — planned only
Timestamp authorities	Future RFC 3161 timestamp tokens	EU and US	Hash only	No	No — planned only

Where a document goes

Every step, in order, naming the provider that touches the document at that step and the country it is in.

1You upload or author a file. It is held in private object storage that no browser reaches without a scoped, expiring grant (Supabase, United States).
2The bytes pass through the application process to be admitted, extracted, prepared, flattened and sealed (Vercel, United States). They are not written anywhere a browser can reach.
3If you ask the document a question, or ask for a draft or an edit, bounded document text is sent through the AI Gateway to one named model provider under required zero-data-retention routing (Vercel, then Anthropic, United States).
4The signature request, reminders and the sealed copy leave as email carrying names, addresses and the document's name — never its page bytes (Resend, United States).
5The sealed PDF and the hash-chained ledger record stay in the same private storage and database. Nothing is copied to a logging or analytics vendor, because none is connected.

Technical and organisational measures

Annex II of the data processing agreement, rendered from the same value. The third column is the part worth reading: each measure carries its real status rather than an implied one, and a measure that is a post-v1 design says so.

Measure	What it covers	Status
Tenant isolation in the database	Row-level security enabled and forced on every tenant table; a WITH CHECK clause on every update policy; non-owning runtime roles that hold no bypass attribute; an explicit organisation predicate in application queries as a second layer; and every scoped mutation returning rows, with zero rows treated as failure rather than success. The managed database platform retains its own administrative roles which do carry a bypass attribute, as every managed Postgres does; no OctoDoc application path uses one.	In service for the tables that exist, verified by a structural test suite run against a live database; every table added later lands under the same rule, asserted by a migration test
Encryption in transit	TLS for every connection to the public surface, to the database and between platform components.	In service for the surfaces in service
Encryption at rest of document objects	Private Supabase Storage with platform encryption, tenant-prefixed content-addressed names and no-overwrite writes. V1 makes no per-file encryption, WORM or Object Lock claim.	V1 design
Signing identity custody	V1 applies a basic cryptographic PDF signature in the application process using a certificate and private key supplied through protected server configuration. The key is never sent to a browser or stored with a document. Hardware-backed certificate-authority custody is a post-v1 measure and is not claimed.	V1 software-key path in service; managed hardware custody post-v1
Immutable retention of sealed records	AWS Governance-mode Object Lock with dual-approved break-glass deletion is a post-v1 storage-hardening option. V1 private Supabase Storage is administrator-removable.	Post-v1, not part of the v1 Service
Evidence integrity	An append-only, hash-chained ledger, one row per event. RFC 3161 anchoring, inclusion proofs and proof-file delivery are post-v1.	Ledger in v1; external anchoring and proof delivery post-v1
Erasure mechanism	V1 erasure uses deletion under the Customer's instructions and applicable legal-retention limits. Per-file crypto-shredding is post-v1.	V1 deletion; crypto-shredding post-v1
Personnel access control	A single named operator constant; a closed aggregate-metadata console with no tenant identifiers or Customer content; break-glass as the only route to Customer content; audit records of grants and reads.	Operator constant in service; break-glass tooling and its audit trail specified, not in production
Authentication of Customer users	Password policy, magic link and external identity providers; session refresh performed at the edge with no database read; provider configuration held in two places that must agree.	In service
Signer session security	256-bit tokens generated from a cryptographic source, stored only as SHA-256, and delivered in the URL fragment with a code-based fallback. Redemption adds one file-, party- and session-scoped grant to an HttpOnly, Secure, SameSite=Lax cookie jar whose base64url claims are HMAC-authenticated, not encrypted. Each grant expires 45 minutes after its own redemption, the jar retains at most 20 unexpired grants, and every signing route selects one grant through a session-bound opaque route identifier before reading a file. That signer-session cookie uses Path=/ because both /sign pages and /api/signing routes read it. The separate pre-account stash cookie lasts at most 30 minutes, is sent only under /api/signing/sessions, and is cleared after a terminal redemption. Rate limits and session burn apply to repeated failure.	In service
Browser and transport hardening	An enforced Content Security Policy with per-request nonces, object-src none, frame-ancestors none, and Referrer-Policy no-referrer on every confidential prefix. Enforced, never report-only.	In service
Confidential-surface indexing policy	The prefixes that serve document bytes, party names or a hash are disallowed to crawlers and marked noindex, nofollow, noarchive, nosnippet, noimageindex at the edge, in page metadata and in robots.txt, derived from a single declaration so the layers cannot disagree.	In service, with tests pinning each layer and a live header check
Secret leakage prevention	A post-build byte scan of the browser artifacts for the values of every secret across raw, JSON, JS, RSC, HTML-entity, base64 and URL encodings. Reports name and path, never the value. Fails closed when zero secrets or zero artifacts are scanned.	In service, wired into the build, with tests asserting it stays wired and that it fails when its inputs are absent
Supply chain	Exact pinned versions with a lockfile, and a dependency licence gate that walks the installed transitive JavaScript tree, rejects AGPL, SSPL and non-commercial licences, denies named packages, and fails closed on an unreadable required manifest or an empty dependency set.	In service for the installed transitive JavaScript tree; cross-platform optional-binary coverage and the install-time vulnerability scanner are specified and not yet in service
Malicious document handling	Active content stripped at ingest with a recorded repair log; hard caps on byte size and page count; a decompression ceiling; per-page and per-document timeouts; a worker memory limit that kills rather than swaps.	Specified, not in production
Egress control	Worker networking deny-by-default with a named allowlist, and URLs declared inside a document never fetched.	Specified, not in production
Logging and observability	An allowlist of loggable field names with redaction of everything else; the ledger, document content and party names never sent to an observability vendor; a test asserting no document text, email body or party name appears in a log statement.	Specified, not in production — no observability vendor is connected to any surface
Backup and recovery	Point-in-time recovery on the primary database, object versioning on storage, and documented recovery point and recovery time targets.	Committed before launch — the database exists; point-in-time recovery and the documented targets are not yet verified
Availability and resilience	Redundant machines on the document plane with health checks, queue-based durable job execution, and idempotency keys on every mutating call.	Specified, not in production
Testing and evaluation of effectiveness	A pre-merge gate chain of typecheck, lint, vocabulary and licence gates, tests, build with the secret scan, and dead-code analysis; plus periodic review of this Annex.	In service for the gates that exist; the gates that depend on unshipped capabilities are deliberately not wired in, because a gate that scans an empty set reports a false pass
Independent penetration test	Web, API and signing pipeline, unauthenticated and authenticated, including a tenancy-isolation test targeting row-level-security bypass.	Committed before the Service is made available to paying customers — not yet performed
Independent audit report	SOC 2 Type II, Security criteria.	Not held. No certification, attestation or report is claimed. See section 10
Sub-processor assurance	Written terms with each sub-processor imposing data-protection obligations no less protective than this agreement.	Partly in place — Annex III marks which sub-processors are engaged today; terms for those not yet engaged are a condition of engaging them

What is kept, and what cannot be deleted

The deletion table from the privacy notice, rendered from the same value. One category survives an erasure request — the sealed artifact and its ledger evidence, under the Article 17(3)(e) legal-claims exception — and that is stated here as plainly as it is there.

Residency is a single United States region, fixed when an organisation is created and unchangeable afterwards. EU and UK residency are not offered.

Data class	Erasable on request	Mechanism
Post-v1 reading log, page timing, scroll depth	Not collected in v1	A deletion and expiry contract is required before collection
Margin questions and answers	Not retained in v1	Processed in memory for the response; no transcript store
Post-v1 identity-verification evidence	Not collected in v1	Vendor and deletion terms are required before collection
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

The send-policy ruleset

OctoDoc refuses whole categories of document as a matter of product policy. The rules are published as a versioned file carrying each rule identifier, its statutory citation and its effective date, so the boundary can be read and disputed rather than discovered at send time.

A refusal is OctoDoc product policy. It is not a claim that an electronic signature would be void in that category.

Ruleset version: 1.0.0
Rules published: 14
Outside-counsel review: Not recorded
Download: /octodoc-policy-ruleset-v1.0.json

Incident history

There has been no security incident, no personal-data breach and no unplanned disclosure to report. This page is where one would be published, and an empty history is stated as an empty history rather than left out.

If one occurs, the data processing agreement governs what happens: notification without undue delay once we are aware, with what we know at the time rather than a delayed complete account, and the facts published here afterwards.

Uptime and component status will be published on an independent host when that page exists. It does not exist yet, so nothing on this site links one.

AI, and the memos that are not written

Two classification memos belong here — the EU AI Act transparency analysis for the signer-facing assistant, and the classification of the send-policy classifier. Neither is written, so neither is published, and this section says so rather than describing an intention as an artifact.

What is true today, and independently checkable: every model request requires zero-data-retention routing and prompt-training opt-out, routing is restricted to one named provider, and the assistant identifies itself as software on every signer surface.

Structurally, nothing a model produces can reach the bytes that get signed. Proposals, summaries, answers and citations live in a sidecar layer, and the server re-measures the stored document before accepting where anything is placed on it. An answer with no matched geometry is not shown as a citation, and the assistant escalates to the sender rather than guessing.

On the name

OctoDoc is unrelated to other businesses using the word octodoc, including a commercial printer and an unrelated consumer AI application. The operating entity and its registration will be published here once it is incorporated; until then every published instrument names no counterparty and binds nobody, which each of them states before its first clause.

Privacy and security questions go to privacy@octodoc.org.