Privileged data, handled securely

FirmSpan holds bank transactions, sworn financial figures, client documents and text-message evidence on behalf of the firm that requested them. This page summarizes how that data is protected, who else touches it, and what happens when something goes wrong. The four policies it summarizes are published in full below.

Every claim on this page traces to a published policy or to the infrastructure we run on.

The security baseline

Six controls that apply to every document and every figure in the system.

Encrypted in transit and at rest

Every connection is carried over TLS 1.2 or higher, served exclusively over HTTPS with Strict Transport Security enabled. Documents, financial records and database contents are stored on managed infrastructure that encrypts them at rest with AES-256.

Stored in the United States

Compute runs on Vercel and the database and file storage on Supabase, both on paid tiers and both configured to store and process customer data within the United States. Every processor that handles client data is configured the same way.

Firm-scoped, enforced server-side

Each firm workspace is logically segregated. Authorization, including tenant isolation and role-based permissions, is enforced on the server and at the database layer. Client-side controls are never treated as a security boundary, and no user can reach data belonging to another firm.

Clients upload, and only upload

A client signs in through a single-use magic link to a stateless session. Clients cannot view, download or retrieve anything previously uploaded, so a compromised link exposes no history. The attorney, as custodian of the file, releases documents to the client through their own channels.

Private buckets, signed URLs

No document bucket is public. A file is reachable only through a short-lived signed URL issued to an authorized firm session. Uploads are constrained by type and size and stored so that their contents can never execute.

Secrets stay out of the code

Production secrets, database credentials and API keys live encrypted in the hosting platform and are injected at runtime, never committed to source or shipped to the browser. Suspected exposure is treated as actual exposure: the secret is rotated immediately, and secrets are rotated at least annually wherever the platform supports it without disruption.

How the program runs

Security is a standing process, not a launch checklist. These are the routines the Information Security Policy commits us to.

Quarterly security reviews: Each quarter the engineering team audits access, evaluates infrastructure configuration and assesses emerging threats. Findings and remediation actions are written down and retained for at least two years. A risk register records every identified risk with its owner, treatment and residual rating, and any risk of disclosing client documents or financial data is rated no lower than High by default.
Vulnerability and patch management: GitHub Dependabot continuously scans application dependencies between reviews. Vulnerabilities are triaged by CVSS severity against written remediation targets: seven days for Critical, thirty for High, and ninety days or the next deployment cycle for Medium and Low. Any exception is documented with a rationale and a compensating control.
Change management and deployment: All code and infrastructure configuration live in GitHub and reach production through a pull request. Deployments are immutable and each one is retained as a restorable version, so rolling back to the last known good release is the default first response to a defective change. Changes touching authentication, tenant isolation, authorization, data deletion, encryption or the financial integration receive explicit security review.
Production data stays in production: Customer data is never copied into preview, development, testing or local environments; those use synthetic or anonymized data. Production secrets are never used outside production, and migrations that delete or transform customer data are validated against a non-production restore first.
Logging with a hard exclusion list: We log authentication and session events, document uploads and downloads, administrative actions, and financial-integration calls in enough detail to reconstruct what was requested and when. Credentials, tokens, magic links, full account numbers and the contents of client documents are never written to any log, in any environment. Finding one there is itself treated as a security incident.
People and devices: Multi-factor authentication is required on every account with access to our infrastructure, source control or customer data. Anyone with production access completes security training and signs a confidentiality agreement first, works from a device with full-disk encryption and screen lock, and may not submit customer data to any AI tool that is not an approved processor. Access is revoked within one business day of departure, and the secrets they could reach are rotated.

When something goes wrong

The Incident Response and Business Continuity Plan names one Incident Commander, a documented alternate, and external forensic and legal support identified before they are needed.

Preserve evidence first

Platform log windows are as short as one day, so in any suspected unauthorized access the relevant logs are exported and preserved outside those windows as the first documented action, in parallel with containment and before any step that would destroy evidence.

Notify within 72 hours

Where unauthorized access to customer data is confirmed or reasonably suspected, we notify the affected firms without undue delay and target initial notice within seventy-two hours of confirming a reportable breach. Notice covers what happened, which categories of data were affected, what we did, and a point of contact. We do not wait for a complete investigation.

Recover within a day

Encrypted database backups run daily and are kept on a rolling seven-day basis. The stated recovery point objective is up to twenty-four hours and the recovery time objective is twenty-four hours for core functionality after a total database loss. A backup is not treated as proven until it has been restored, which we do at least annually.

Roll back in minutes

A defective deployment is met with a rollback to the last known good release, measured in minutes. Loss of the financial integration degrades collection without touching the confidentiality of data already held. Each year we walk through at least one incident scenario against the plan and record any deficiencies.

What we hold, and for how long

FirmSpan is a collection platform, not a system of record. The firm remains custodian of the client file, and everything here is designed to keep the window of exposure short.

What is collected: Name, email and phone number to reach the client; account balances, transaction history and statement data pulled with the client's explicit consent; documents the client uploads; and, where a firm asks a client to preserve a text-message conversation, the screen recording the client chose to upload.
Consent is the trigger: Nothing financial is collected without an affirmative act by the client, whether initiating a bank connection or uploading a file. Screen recordings add a disclosure step: the client is shown what is uploaded, where it goes and who processes it, and the version they agreed to is recorded. Decline, and nothing is sent.
Who it is shared with: The law firm that requested it, and the processors listed below. Customer data remains the property of the firm and its clients. We assert no ownership, do not sell, rent, license or trade it, and never use it to train machine learning models.
A retention schedule you can calculate: Every deletion date is knowable in advance. All data for a matter is permanently deleted thirty days after an attorney archives it, and in any case nine months after the last upload, export or attorney access on that matter. If a firm closes its account, the entire workspace is deleted sixty days later, with export available throughout. We notify the firm before a scheduled deletion, in time to export. A documented legal hold suspends deletion for the affected data.
Deletion is hard, not hidden: We do not soft-delete customer files. When an attorney deletes a document or a retention threshold is met, the file is purged from object storage and its database rows are dropped. Residual copies persist only in encrypted daily backups, which roll off after seven days, after which no copy remains in our environment. Deleted data is never retained for analytics, model training or product development.
Export is always available: Attorneys can export every document and its metadata for any matter, in the originally uploaded formats, at any time within the retention period and throughout the sixty-day window after account closure. Exporting to the firm's own document system before the schedule runs out is the firm's responsibility, and the retention policy says so plainly.

This is a summary. The privacy policy and the Data Retention and Disposal Policy carry the controlling language.

Who else touches it

Every processor that receives client data, the single job each one does, and the terms it does it under. Each is reviewed before onboarding and reassessed at least annually. We will not onboard a provider whose terms claim ownership of customer data or permit its use for unrelated purposes, and we will not onboard a model provider without terms prohibiting training on submitted data. All of them store and process client data in the United States.

Vercel: Hosts the application and API. Client data passes through it in transit and in memory only; nothing is stored there.; Terms: Pro tier, US region. Holds independent SOC 2 and ISO/IEC 27001 attestations that our infrastructure controls inherit.
Supabase: Database, authentication and document storage: the private buckets, AES-256 encryption at rest and the firm-scoped access rules described above.; Terms: Pro tier, US region. Provides encryption at rest and key management; holds independent SOC 2 and ISO/IEC 27001 attestations that our infrastructure controls inherit.
Plaid: Connects the client's financial institutions and returns transactions, balances and statement data, and, where enabled, categorizes transactions read from statements a firm uploads.; Terms: Every connection requires the client's explicit consent; access tokens are stored encrypted and destroyed when the matter's data is deleted, and Plaid's own privacy policy governs its handling of connection data. For statements a firm uploads, only each transaction's description (with the account holder's labelled ACH name/ID fields, recognised wire-party fields and account-number-like digit runs removed; the counterparty's name, which can be a person, is kept because it is what gets categorized, and a name or other identifier printed without a recognised label can remain), amount, direction and account type are sent for categorization; that includes statements about parties who have not consented, and Plaid's handling of it is governed by our agreement with Plaid. Plaid secrets never reach the browser or a log.
OpenAI: Screens uploaded documents against what was requested, classifies financial entries, and organizes text extracted from a screen recording into a readable transcript.; Terms: Zero data retention: submitted content is not stored by OpenAI after the request completes, and is never used to train, fine-tune or evaluate any model.
Google Cloud Vision: Reads the text out of still images taken from an uploaded screen recording. The video itself is never sent; only the stills and the text read from them.; Terms: Zero data retention: submitted images are not stored by Google after the request completes, and are never used to train any model.
Microsoft Azure AI Document Intelligence: Reads the text and layout of financial declarations and bank statements an attorney uploads for the opposing party, so the figures on them can be compared and used in the attorney's worksheets.; Terms: Documents are processed to return the reading and are not used to train any model; analysis results are deleted by Microsoft within 24 hours. Used only on attorney uploads, never on anything a client submits.
Surge: Delivers the SMS upload links and reminders to clients.; Terms: Receives phone numbers and message text only, never documents or financial data. Texting STOP ends messages permanently.
Resend: Delivers the transactional email FirmSpan sends: upload requests, reminders and status notices.; Terms: Those messages name the client, the attorney and the firm, and can quote the matter and a preview of a client message, so that content passes through Resend. Documents and financial records never do.
PostHog: Product analytics for the attorney-facing application.; Terms: Receives the user id and email of a signed-in firm user, page views and interaction events. Uploaded documents and financial records are not sent, and privileged content is masked out of the interaction events that are.
Clio (if the firm connects it): A firm-authorized integration rather than a processor we select. When a firm connects its Clio account, FirmSpan uploads the client's documents and generated forms into the matter in Clio so the file of record stays in the firm's own system.; Terms: No firm is required to turn it on, and nothing is sent to Clio until one does. The firm's own Clio agreement governs the data once it arrives.

Vendors that never see client data

Named in the Information Security Policy for completeness. None of them receives client, matter or document data.

Stripe: Payment processing for the firm's own subscription. Sees the firm's billing details only.
GitHub: Source code and the pull-request record. Production customer data is never stored in source control.
Google Workspace: Internal identity and email for FirmSpan staff. Customer data is never sent or stored by email.

What we say plainly

The policies disclose their own gaps rather than implying controls we do not operate. So does this page.

FirmSpan holds no SOC 2, ISO 27001 or HIPAA attestation of its own. The attestations we cite belong to our infrastructure providers, and our controls inherit from theirs.
Multi-factor authentication is available to attorney accounts but not yet enforced on them. Tenant isolation and authorization do not depend on it, failed-login patterns are reviewed quarterly, and enforcement is tracked as an open item in the risk register.
FirmSpan is a small company. The CEO also serves as Chief Information Security Officer and engineer, so full separation between the person who approves, implements and reviews a change is not yet possible. Compensating controls are version control, an attributable deployment pipeline and written quarterly reviews; governance separates from engineering once four or more people hold production access.
Platform log windows are short: one day for application logs and seven for database, authentication and storage logs. The compensating control is immediate export and preservation the moment an incident is suspected.
There is no secondary hosting provider capable of independent failover. During a provider outage we monitor status channels and keep affected firms informed.
Founders have not undergone third-party background screening; personnel engaged beyond the founding team do.

The policies themselves

This page is a summary. These four documents are the controlling language, and each is reviewed at least annually.

Effective July 27, 2026