Trust & security
Tax data is sensitive.
We treat it that way.
We run on Cloudflare — one of the most security-certified platforms
in the industry — and add a layer of our own controls on top.
Every page below is honest about what's in place today and what's
still being built; nothing here gets a checkmark it hasn't earned.
Architecture in one paragraph
Each client household gets its own isolated database instance
— a dedicated, separate database for that family. There is no shared
table where one client's data could accidentally show up in another
client's view; separation is structural, not enforced by a query filter
an engineer could forget. Inside that instance, personal information is
encrypted with a key unique to the household — derived, not stored, so
it never sits anywhere we could lose it. When the household is deleted,
the key is destroyed. Any leftover ciphertext is then mathematically
unreadable forever, even if it surfaced in a backup years later.
What we inherit from the platform
Lineage runs on Cloudflare — our compute, storage, and global edge are
all Cloudflare services. Cloudflare carries independent certifications
we rely on directly, and a global security operations team
round-the-clock. We benefit from these without re-implementing them.
SOC 2 Type II
Annual independent audit
Cloudflare's report covers the platform we deposit your data on. We can make it available under NDA.
ISO 27001
Information security management
International standard for the policies, processes, and controls that protect customer data.
PCI DSS Level 1
Card-data handling
Not relevant to tax-data flows directly, but signals platform-wide control maturity.
FedRAMP Moderate
US federal-grade controls
Cloudflare's FedRAMP authorisation covers a US-only operational boundary; we evaluate the FedRAMP jurisdiction option for sensitive deployments.
HIPAA BAA
Healthcare-data handling
Available where applicable — relevant for the healthcare directives some households keep in their vault.
24/7 SOC
Security operations
A continuously-staffed security operations centre handles platform-level threat response across the global edge.
Encryption — two layers, not one
Cloudflare encrypts every disk that holds your data with industry-standard
AES-256 — automatically, transparently, managed by them. That alone is
what most providers stop at. We add a second layer above it:
each household's sensitive fields (names, emails, document content,
secrets) are re-encrypted with a key derived specifically for that
household, and used only inside that household's isolated database
instance.
We're not publishing the exact construction — there's no security
benefit in a public algorithm box — but the design choices we made
give us three properties that matter to you:
Two encryption layers
Cloudflare's, plus ours
An attacker who breaks one layer still faces the other. Both use AES-256.
Crypto-shred on delete
Erasure is mathematical
When you delete a household, the household-specific key is destroyed. Any leftover ciphertext anywhere — including in a backup — becomes permanently unreadable.
Lookups still work
Without bulk decryption
The encryption is designed so we can find the right record by exact value (a payer name, an account suffix) without decrypting everyone's data first.
Data residency — US
Tax data ingested through the US product resides on US Cloudflare
infrastructure. Cloudflare gives us per-component location and
jurisdictional controls — here's how each Lineage data store is
configured today, in plain terms.
| Where it lives | What we configure | Current state |
Application database
Firms, users, engagement records, expectation registries | Pinned to Cloudflare's Eastern North America region. | In place
Migrated from APAC into a US-pinned instance on May 24, 2026. Row counts verified before cutover; the old database has been retired.
|
Document storage
Uploaded tax documents, raw email content | Storage buckets created with US location hint; per-object encryption above the platform layer. | Recreating
The two storage buckets were originally created without an explicit US location hint. We're destroying and recreating them with the Eastern North America hint set — a clean rebuild rather than an in-place migration because there's no production tenant data to preserve yet. Flips to In place immediately after the rebuild verifies.
|
Per-household database instances
Each family's isolated storage | Location hint set to Eastern North America when the instance is first created. | Configured
The per-family storage class is wired with the Eastern North America location hint at creation. No live instances exist yet — they're created on the household's first inbox document, which will land with the next product release. Every instance from that point forward is US-pinned by default.
|
Short-lived session storage
Sign-in tokens, one-time codes — content does NOT include tax data | Move sign-in and OTP storage out of Cloudflare's globally-replicated session store, into the US-pinned application database. | Global today
The store Cloudflare offers for short-lived data does not yet support jurisdictional restriction. Session tokens and 10-minute OTP codes are replicated globally; no tax-document content is held here. Migration is on the roadmap.
|
Workers compute
The code that runs Lineage | Cloudflare Regional Services restricting code execution and TLS termination to the United States region. | Planning
Regional Services is a Cloudflare Enterprise feature; we're evaluating it for v1 GA. Until then, code runs on the global edge under platform-level controls.
|
Outbound email
Sign-in codes, alerts, recovery codes | Sent via Cloudflare Email Sending (US infrastructure). | In place
No third-party email vendor.
|
Why we publish a row-by-row breakdown. A residency claim is
either true or it isn't, and "US-only" gets used loosely by a lot of
providers. We list each store separately so you can see exactly where
your tax data lives versus the small, content-free pieces (session
cookies, OTP codes) that still rely on a globally-replicated layer
while we wait for Cloudflare to expose jurisdictional restriction
there. Each row carries a verifiable status; we update the date at
the top of this page when any of them changes.
Controls & the laws they answer
Every meaningful control in the system, what it does, and the laws or
standards it materially helps you satisfy. We're aligned to NIST 800-53
Rev 5 as the framework backbone; the right-hand column shows which US
statutes a given control helps your firm discharge.
| Control | How we do it | Discharges (US laws / standards) |
| Identity & authentication |
Passwordless sign-in: email one-time code, then a second factor
from an authenticator app (no SMS). Eight single-use recovery
codes are emailed at enrolment, with a copy to an optional
alternate inbox so they survive if the primary is lost.
Redeeming a recovery code forces a fresh second-factor setup.
|
NIST 800-53 IA-2, IA-5 · GLBA Safeguards Rule §314.4(c)(1)(i) ·
IRS Pub 4557 multi-factor requirement · SOC 2 CC6.1
|
| Access control & scoping |
Cross-tenant access (CPA reading household data) is gated on a
per-engagement consent record with read-only scopes, an §7216
purpose statement, and an absolute expiry. Either side can
revoke at any time. CPAs never write to a household's data
through Lineage — read-only by design.
|
NIST 800-53 AC-2, AC-3, AC-4, AC-6 · IRC §7216 use & disclosure
of taxpayer info · GLBA Safeguards §314.4(c)(1)(ii) · State
privacy laws (purpose limitation)
|
| Encryption at rest |
Cloudflare's platform AES-256 encryption across all storage,
plus our second-layer encryption with a household-specific key
that never leaves the household's isolated database instance.
Two layers, both AES-256.
|
NIST 800-53 SC-12, SC-13, SC-28, MP-6 · GLBA Safeguards
§314.4(c)(3) · HIPAA §164.312(a)(2)(iv) for healthcare-directive
uploads · SOC 2 CC6.7
|
| Encryption in transit |
TLS 1.3 enforced at every Cloudflare edge node. Strict transport
security with HSTS preload. Content security policy locked,
frame-ancestors disabled, automatic upgrade to HTTPS in
production.
|
NIST 800-53 SC-8, SC-23 · GLBA Safeguards §314.4(c)(3) · SOC 2
CC6.6, CC6.7
|
| Tenant isolation |
Every household gets its own database instance, addressed
directly — not by a query filter. Cross-household data exposure
from a code bug is structurally impossible because no shared
row holds another household's data.
|
NIST 800-53 AC-4, SC-7, SC-39 · GLBA Safeguards §314.4(c)(1) ·
State privacy laws (data minimisation / segregation)
|
| Audit logging |
Per-household tamper-evident audit log (hash-chained,
append-only). Every authenticated request — including
system-admin reads — is recorded. Exportable on demand.
|
NIST 800-53 AU-2, AU-3, AU-6, AU-12 · GLBA Safeguards
§314.4(c)(1)(iv) · IRS Pub 4557 §V audit trail · SOC 2 CC4.1
|
| §7216 consent capture |
When a CPA onboards a client, the §7216 consent basis is
recorded on the engagement record along with the purpose
statement and grant timestamp. Either side may revoke.
|
IRC §7216 use and disclosure of tax-return information ·
26 CFR §301.7216-3 (taxpayer consent) · State privacy laws
(lawful basis / purpose limitation)
|
| Data minimisation |
Account numbers stored as last-4 only. Social Security numbers
are never stored — we accept them transiently for filing
assembly through the CPA's tax engine, not in our database.
Email subjects and senders are encrypted at the field level.
|
NIST 800-53 PT-3, PT-4 (privacy controls) · GLBA Safeguards
§314.4(c)(6) · CCPA / CPRA · VCDPA / CPA / CTDPA / UCPA / OCPA /
TDPSA — minimisation under all US state comprehensive privacy laws
|
| User rights — access / export / delete |
Households can pull their full audit log, export their data, or
confirm-typed delete their account from a self-service surface.
Delete fires immediately and crypto-shreds the household key.
|
CCPA §1798.105 (delete), §1798.110 (know), §1798.130 (access) ·
CPRA §1798.106 (correct) · VCDPA / CPA / CTDPA / UCPA — 19+ US
state DSAR analogues · GLBA Safeguards §314.4(b)(1)
|
| Written information security plan |
Lineage maintains an internal WISP covering IRS Pub 4557. A
firm-facing template is available so partner firms can list
Lineage as a service provider in their own plan.
|
IRS Pub 4557 (Safeguarding Taxpayer Data) · IRS Pub 5708 (WISP
template) · FTC Safeguards Rule revised 2023 · NIST 800-53 PL-2
|
| Breach notification |
48-hour notification commitment to affected firms with scope,
vector, and remediation timeline. Live incident report on
this page; full post-mortem within 14 days of a confirmed event.
|
~50 US state breach-notification laws · GLBA Safeguards Rule
revised §314.4(j) (FTC reporting within 30 days for ≥500
records) · NIST 800-53 IR-6, IR-8
|
| Vulnerability management |
Zero-vuln CI gate via npm audit on every commit; Dependabot
enforces upstream patching. No password storage to leak.
|
NIST 800-53 SI-2, SI-3, RA-5 · GLBA Safeguards §314.4(c)(8) ·
SOC 2 CC7.1
|
Independent audit posture
Lineage is aligned with the SOC 2 Trust Services Criteria
(Security, Availability, Processing Integrity, Confidentiality, Privacy).
Independent certification is in progress; we will share
the auditor's report under NDA once it is issued. We are not naming a
date here because that report belongs to the auditor — when they are
done, you will see it on this page.
Subprocessors
Every third party that touches operational data — short list by design.
| Vendor | Purpose | Region |
| Cloudflare | All data stores, compute, transactional email, global edge | US (target Eastern North America) |
| Cloudflare Workers AI | Parser fallback for unknown document layouts | US |
| Anthropic Claude API | Failover for parser fallback only — never personal-data prompts | US |
We use no third-party identity, analytics, or aggregator providers.
No Plaid, Mixpanel, or Segment.
Incident report
A complete log of events that affected customer service or data —
availability outages, performance degradation, security incidents, or
any breach. Empty when nothing has happened. We commit to publishing
an entry within 72 hours of an incident becoming clear, and a full
root-cause analysis within 14 days.
No incidents reported as of May 29, 2026.
The categories we report on: availability outages, performance
degradation, security incidents, data breach. None has occurred.
What you'd see here if something happened:
a dated entry with the scope (who was affected), what happened, what
was done about it, and a follow-up root-cause analysis. We don't
privately resolve incidents behind a status page that resets;
the record lives here permanently.
Security questions?
Email security@lineagemoney.com.
For a security questionnaire response, vendor diligence form, or the
Cloudflare / Lineage audit reports once available, reach out from your
firm's domain.
Page last updated May 29, 2026.