Firmviz ENES Create your firm

Security and technology

Last updated 2026-11-05 · Effective [date]

How Firmviz is built to keep a firm's records private, whole and provable. Everything on this page describes what the software does today; the items marked in brackets depend on the hosting arrangement and are confirmed on the order form.

1. One firm, one fence

  • Every record carries the firm it belongs to. The application refuses any query that is not scoped to the firm signed in, and the database enforces the same rule on its own with row-level security on every firm table, so even a flaw in the application cannot read or write another firm's rows.
  • Identifiers cannot be guessed into another firm: a record that exists but belongs to another firm answers exactly as one that does not exist.
  • Firmviz's operator can reach a firm's data only through a support grant the firm approves, limited in time, shown on every screen while it is active, and written to the firm's own audit log.

2. Who you are and what you may do

  • Passwords are stored as scrypt hashes. Changing a password signs out every other session of that person.
  • Passkeys (WebAuthn: Windows Hello, Face ID, security keys) sign people in and approve sensitive actions. No biometric ever leaves the device; Firmviz stores only the public key.
  • Actions are tiered. Reading needs nothing beyond sign-in. Changes show a confirmation card first. Money leaving or entering trust, access changes, releasing a legal hold, disposal and anything sent outside the firm need a Tier 2 approval: a passkey, or a password where the firm allows it. Voice never approves Tier 2.
  • Roles (attorney, paralegal, staff, bookkeeper, admin) decide who may see and do what. Trust entries are posted only by a bookkeeper or an attorney; above the amount the firm sets, a second person approves and it can never be the person who entered the line.
  • Losing a passkey is recovered by an administrator starting a reset that a second attorney approves on the card; the person is signed out everywhere and told.

3. An audit log that cannot be quietly changed

  • Every view, change, approval and refusal is written to an append-only, hash-chained audit log. The database refuses updates and deletes on it.
  • On every commit the chain's head is anchored outside the database, so a tampered database would disagree with the anchors.
  • The trust ledger is append-only too: no edits, no deletes; a mistake is a reversing entry that leaves the original line in place. A month that has been reconciled and signed can never receive a backdated line.

4. Encryption

  • Uploads, voice memos and backups are sealed at rest with a key per firm (authenticated symmetric encryption); the keys are kept outside the database.
  • Connections use TLS [1.2 or later; certificate issuer]. Passkeys only work on the firm's real domain.
  • Backups are encrypted and verified by a restore drill that opens the files with the key, checks their hashes and the audit chain against its anchors, and refuses a wrong key or a changed byte.

5. What comes in

  • Uploads are identified by their content, never by their file name or extension, limited in size and type, and scanned for malware (ClamAV) before they are stored.
  • Every page is served with a strict Content Security Policy (scripts only from Firmviz itself with a per-request nonce, no third-party scripts, fonts self-hosted), plus the usual headers against framing, sniffing and referrer leaks.
  • Sign-in, approvals, uploads and the demo form are rate-limited per account and per network address. Forms carry anti-forgery tokens.

6. Voice and artificial intelligence

  • The browser's speech recognition is never used; a recording goes to the firm's own Firmviz server, is transcribed there and sealed. Transcripts are kept with the memo.
  • AI drafting is off by default and needs both the firm's administrator and the server operator to turn it on. When on, client details are replaced by placeholders before any text leaves the server, the exact text sent is shown and kept, and every output is a draft until an attorney approves it.
  • The law card on a matter shows only law that was retrieved from an official source, with the citation and the retrieval date; the assistant never presents a case or statute it did not retrieve.

7. Retention and legal holds

  • Closed matters keep their files for the period the firm sets. Nothing is disposed of without an attorney's Tier 2 approval, and a legal hold blocks disposal until an attorney releases it, also Tier 2.
  • The firm can export its data at any time.

8. Hosting and operations

  • Firmviz runs on [provider, region] or on a server the firm controls. The database is PostgreSQL [version] with row-level security on; the application runs as a non-privileged database role that cannot bypass it.
  • Backups: [frequency], encrypted, kept [retention], restore drill [schedule].
  • A production check refuses to start the service with development settings, a missing key, debug on or an insecure cookie configuration.
  • Changes are reviewed and tested before release; the test suite includes cross-firm isolation tests that try to read and write another firm's data with the application's own guard bypassed, and must fail to.

9. Sub-processors

[Hosting provider, region, purpose] · [Email provider for notices, purpose] · [AI provider, only if the firm turns the feature on]. The current list is also in the Data processing addendum; firms are told of additions in advance.

10. Reporting a vulnerability

Write to [security@firmviz.example]. We acknowledge within [2 business days], keep you informed, and do not take legal action against good-faith research that respects other firms' data and does not disrupt the service. Please do not test against firms' live data; ask for a test account.

11. Independent review

[Penetration test: date, firm, summary available on request under NDA.] [SOC 2 or other attestation: status.] [Cyber liability insurance: carrier and limit.]