Security
Personal-injury work concentrates exactly the data nobody should leak — medical records, settlement figures, client identities. This page states the controls Lexboard enforces, names the mechanism behind each one, and lists the claims we refuse to make.
A control you cannot name the mechanism for is a slogan. Each of the seven below says where it runs, what enforces it, and — where one exists — the limit that comes with it.
Every record carries your firm's id. The application authenticates the firm member on every API route and scopes every read and write to that firm — the id comes from the session's signed claim, not from anything a request can vary. Postgres row-level security then enforces the same boundary a second time, inside the database: an application bug that drops a filter still returns zero rows, because the database itself refuses to produce another firm's data.
File storage is firm-scoped at the storage layer as well, and documents are served through signed URLs that expire.
Every state change writes a row to an append-only log: the actor, the timestamp, a plain-English summary, and the before-and-after of what changed. Firm members can read the log. No member role holds the database privilege to insert into it, edit it, or delete from it — the restriction is row-level security in Postgres, not a switch in the interface — so the people the log records cannot rewrite it.
Money movements carry the amount on the transaction and on its reversal, so a void never vanishes from the record. External disclosures — an email sent, a document shared, an export downloaded — are logged in both directions too, including the moment access is revoked. And coverage is enforced before code ships: continuous integration blocks any mutating endpoint that neither writes an audit row nor carries a verified exemption.
Audit trail · Khan v. Southeast Logistics
Append-only200+ tables carry the audit trigger · no member role can insert, update, or delete
RENDERED RECREATION OF THE LIVE PRODUCT — NOT A SCREENSHOT
The credentials your integrations entrust to us — Gmail and Microsoft 365 OAuth tokens, Google Drive, RingCentral, firm AI keys, check-payment keys — are encrypted with AES-256-GCM before they reach the database. Nothing is stored in plaintext, and platform secrets live in environment configuration, never in code.
Disk-level encryption of the database at rest is our hosting provider's control, and we say so rather than claim it as our own.
Backups are a control you hold, not a promise you take on faith. Schedule daily, weekly, or monthly backups of your firm's data — full, or narrowed by data domain — or run one on demand. Each can be encrypted with AES-256-GCM under a passphrase only your firm holds, and a separately signed manifest makes tampering with the artifact detectable.
Retention pruning keeps the newest copies automatically, and a failed run notifies your admins instead of failing silently.
An external share can require a PIN, carry an expiration date, and cap its total views — and you can revoke it instantly. Those checks run where the bytes are served, not on a landing page in front of them, so a revoked link is dead at the file proxy itself. PIN attempts are rate-limited, and every access and every revocation lands in the audit trail as a disclosure event.
One limit, stated plainly: links created by a departing team member are not revoked automatically. Review them when someone leaves.
When a client texts STOP, the number is suppressed across every sender on the platform — not just the thread it arrived in. Consent is evaluated against the message's timestamp, and the system fails closed: if consent cannot be verified at send time, the message does not go out. A bare YES does not quietly re-subscribe anyone.
People are retired, never deleted. Removing a team member disables their access; a database trigger blocks the hard delete outright, so their cases, notes, tasks, hours, and attribution survive and remain reassignable. Historical records keep naming whoever actually did the work — rewriting them would falsify the record, so nothing is rewritten.
The same discipline runs through the product: no case is ever deleted.
A security page is a set of representations your firm relies on in its own vendor diligence, so this one carries the limits as well as the controls. A disclosed limit survives your diligence. A discovered overstatement would not — and it would become your problem as much as ours.
Everything above the line is a mechanism in shipped code. Everything on this list is a limit we publish on purpose.
No SOC 2 report exists, and no audit is in progress. The control work above — access control, audit logging, backups — is being built and documented now. When an auditor is engaged we will publish the name and the date, and not before.
We do not sign Business Associate Agreements. Signing one before every upstream processor in the PHI path is itself under a BAA would be a promise we could not keep. Medical records get the controls above; treat Lexboard as not-HIPAA-covered until we say otherwise in writing.
Lexboard is pre-launch, and we say so — here, in the footer, and on every legal page. What you read on this page describes controls that exist in the shipped code today, not a roadmap. If a sentence here ever stops being true, the sentence changes before the sales copy does.
We answer security questionnaires in writing, and we send a data-flow diagram and our subprocessor list on request. When the honest answer is “not yet,” that is the answer you will get. Write to security@lexboard.net.
The legal suite — privacy, terms, data processing, continuity — lives at lexboard.net/legal.
Reporting a vulnerability
Send a description and reproduction steps to security@lexboard.net. A person reads every report. There is no bounty program yet; there is a thank-you on this page, with your permission.