Security
Private company financials, encrypted with a key we cannot read.
Spread handles private company financial statements. This is how that data is stored, encrypted, accessed and audited — written for the information-security teams who approve tools like ours.
[email protected] · questionnaires completed on request
Encryption at rest
AES-256
Per-account envelope keys in Cloud KMS
Data residency
United States
Google Cloud us-east1, and US-region providers
Standing staff access
None
You grant time-boxed, read-only support access
Reportable incidents to date
Zero
72-hour notification commitment if one occurs
Per-account envelope encryption
TagniFi staff cannot read your financial data
Each account's financial data is encrypted with its own AES-256-GCM data key, which is itself encrypted by a master key held in Google Cloud KMS. The master key never leaves KMS and cannot be exported.
The data key exists in plaintext only in memory — while a document is being processed, or while an authorized member of your team views it. On disk, in both the database and the storage bucket, everything is ciphertext. Anyone with direct infrastructure access sees ciphertext only, and the separation between accounts is cryptographic rather than merely logical.
Master key
Never leaves KMS, cannot be exported
Cloud KMS
Account data key
AES-256-GCM, unique per account
Encrypted at rest
Plaintext key
Exists only while processing or authorized viewing
Memory only
Stored data
Database rows and uploaded documents
Ciphertext
Controls
The full picture, area by area.
01
Infrastructure
Containers on Google Cloud Run, documents in Cloud Storage, financials in Cloud SQL for PostgreSQL — all in US data centers, delivered through Cloudflare. Infrastructure is defined as code, so every change is reviewed and traceable.
02
Network boundaries
The only path in is HTTPS through Cloudflare, screened by a web application firewall and bot protection. The database accepts connections only from the application; storage buckets enforce public-access prevention.
03
Access control
Multi-factor authentication is enforced for every user. Short-lived bearer tokens, individually revocable API keys, and no anonymous path to data. Sessions expire after 30 days.
04
Roles and publishing
Account roles govern the account; company-level roles — Admin, Manager, Editor, Publisher, Viewer — govern the data. Extracted financials stage as drafts and are published only by an authorized person.
05
Document uploads
Files move from the browser to private storage over a signed URL that expires in 15 minutes and is valid for one path. Content type is verified against actual bytes and every file is screened for malware.
06
Audit log
Append-only and hash-chained — the database rejects updates and deletes, and each entry links cryptographically to the one before. Sign-ins, data changes and every decryption are recorded, retained for the life of the account.
07
Support access
No standing staff access to customer financial data. You grant a time-boxed, read-only window scoped to an account, company or upload; every action is logged and access ends automatically.
08
Retention and deletion
Delete documents and financials at any time. On termination, all data and encryption keys are deleted within 30 days, confirmed in writing on request, with an export provided beforehand.
09
Secure development
Every change is reviewed by someone other than the author, with automated build, test and dependency scans. Dependencies are refreshed weekly and containers rebuilt on current base images each deploy.
10
Monitoring
Structured OpenTelemetry traces, metrics and logs on every request, with alerts paging an on-call team on errors or anomalies. Operational telemetry is retained 90 days.
11
Incident response
Managed on-call process with direct notification no later than 72 hours after a confirmed incident affecting your data. No reportable incident or breach to date.
12
Backups and recovery
Daily automated database backups with point-in-time recovery, restores tested annually, and a 24-hour RTO and RPO. The environment can be re-provisioned from code after a region-level failure.
Five commitments on how Claude reads your documents
Not used for training
Claude is accessed through Anthropic's commercial API, whose terms prohibit using customer data for model training.
Zero data retention
Claude runs under a zero-data-retention agreement with Anthropic: the prompts and document contents sent for extraction are not stored or logged on Anthropic's side once the response returns, and are never used for training. Nothing your firm uploads persists with the model provider.
Documents are untrusted input
Content in an upload is never treated as an instruction. Model output must match a defined schema, and the extraction agent runs with hard resource limits.
Human review before publishing
Extracted financials land as draft data your team reviews and publishes.
Contents stay out of logs
Operational logging records processing outcomes, not document contents.
SOC 2 roadmap
We do not yet hold a SOC 2 report
We are executing a Type II readiness program scoped to the AICPA Trust Services Criteria for Security and Confidentiality. The controls on this page are the ones that program covers.
Gap analysis
Controls mapped against each applicable criterion and documented.
Control operation
Encryption, access, audit logging, monitoring and change management run in production.
Evidence collection
Access reviews, audit-log verification and change records collected continuously.
Independent audit
Type II examination once the evidence window is established; report shared under NDA.
We complete HECVAT and similar questionnaires on request, and share the SOC 2 report once issued, plus penetration-test summaries, under NDA.
Service providers
A small number of providers process data on our behalf. None receives more than its role requires.
Questions beyond this page go to [email protected]. This summary reflects the Spread Security Overview dated July 2026; the full document is available on request.