Privacy Policy

1. Who controls the data, and who merely handles it

This is the most important paragraph on the page, and everything else follows from it.

The law firm is the controller of its client data. BRON is a processor acting on the firm's instructions. The firm decides which matters exist, what goes into them, who at the firm may see what, which outside services are connected, what is shared with a client, and what is retained or deleted. BRON provides the software that carries out those decisions, and holds the data in order to do so.

The practical consequence for a client of a law firm: your relationship, and your rights over the material in your matter, run to your law firm. BRON cannot decide on its own to hand over, correct, or delete matter records, because they are not BRON's to decide about. Section 11 explains how to make a request.

BRON is the controller for a narrow, separate set of data: the account records of the people who sign in, the security and audit events the service generates, and product-support correspondence. Those are described below and are not matter material.

2. What BRON handles

The content of a matter is whatever the firm chooses to put in it, so this is a description of categories rather than a fixed list.

• Account and firm records. Name, email address, role at the firm, bar number where the firm records one, and sign-in and session events.
• Matter records. Case captions, parties, contacts, court and jurisdiction, phase, notes, tasks, and deadlines that an authorized user entered or confirmed.
• Documents and their contents. Files a firm or its client uploads, text extracted from them, and the search index built over that text.
• Communications. Messages within the platform, client portal correspondence, and email handled through a connected mailbox.
• Signature records. Described in section 6.
• Billing and trust records. Time entries, invoices, and the trust ledger.
• Security and audit events. An append-only record of sensitive actions, described in section 7.
• Support correspondence. Described in section 9.

Information is used to operate the features an authorized user asks for, to secure and audit access, to retrieve matter material, to prepare drafts and analysis that an attorney then reviews, to run the integrations the firm selected, and to diagnose reliability and security problems. It is not used to build advertising profiles, and it is not sold.

3. Privileged and work-product material

BRON is built on the assumption that most of what it holds is privileged or confidential, and the separation between what a firm sees and what its client sees is enforced in the software rather than left to a setting.

Documents carry a classification of privileged, work product, confidential, or none. A separate decision controls whether a document is shared to the client portal, and a third, independent screen marks material received under a protective order as attorneys' eyes only. All three are checked before anything reaches a client, on every path that can deliver a document: the document list, an individual document, a download link, version history, the matter timeline, and the portal export.

These checks are built to fail closed. A document whose privilege has never been reviewed is treated as not cleared, so it is withheld rather than released. If a check cannot be completed, the portal returns a temporary error instead of a list that silently omits the filter. Ethical walls work the same way: if the screen cannot be read, access is denied rather than granted.

4. AI providers, and exactly what reaches them

Read this section carefully before deciding whether the product suits your practice. The full provider list is on the sub-processors page.

The commitment.BRON's posture is that client data sent to a model provider is to be processed only under no-training and zero-data-retention terms, and that a model path which cannot offer that posture should not carry client information.

What that commitment rests on, stated plainly. It rests on the terms BRON holds with those providers. It is not currently enforced at runtime by the software. There is no check inside the product that inspects a retention setting and refuses to send. A firm evaluating BRON should treat this as a contractual assurance from BRON and its vendors, and should ask for those terms in diligence rather than assume the application blocks a non-conforming path. The one place the software does constrain the choice is the client portal assistant, which ignores any requested model and pins itself to a provider chosen for its terms.

What is sent, and when. Drafting, analysis, and the assistant send document text and matter facts, which in a law practice means privileged material. Two further paths are on by default and are easy to overlook:

• Search indexing. Making documents searchable sends every uploaded document, in pieces, and every search query, to an embedding provider. This happens even where every model a user talks to is from a different vendor.
• Audio transcription. Live deposition audio and dictation are sent to a transcription provider as recorded speech. This is privileged testimony leaving the deployment. A self-hosted transcriber is the intended replacement and is not built.

Provider failover. If the primary provider is unavailable or a quota is exhausted, a request can be retried automatically with a different provider. A firm that needs its work confined to a single vendor should say so before deployment.

No pre-send redaction. Material is not stripped of names or personal information before it is sent to a provider. Doing so would make the output useless for legal work, and BRON does not claim to do it.

Retrieved text is treated as data, never as instructions.Content pulled from a firm's own documents is wrapped in explicit markers, and the model is instructed never to obey directions found inside them. This defends against a document that has been crafted to hijack the assistant, which matters when the other side chooses what it produces to you.

Generated output is attorney work product and requires attorney review. It is never the product itself. See the terms.

5. Security measures that are actually in place

Described at the level a general counsel can verify, and no further.

• Encryption in transit. Enforced, not merely offered. In production a plain request that carries a body is refused outright rather than redirected, so its contents are never replayed over an insecure connection. Strict transport security is set.
• Encryption at rest. Provided by the managed database and storage platform. BRON does not add a second layer of its own over document bytes, with the exception below.
• Credential encryption. Model-provider keys and third-party integration secrets a firm supplies are encrypted in the application with AES-256-GCM before storage.
• Document access. Files live in a private bucket and are served only through signed links that expire.
• Authorization. Every route checks access in code against matter ownership, firm membership, role, and ethical-wall screens, and denies on error rather than allowing. Client portal requests are scoped to both the signed-in client and the specific record, not to a session alone.
• Database row-level security.Enabled and deny-by-default across the schema. Stated precisely, this is a second layer that protects against direct database access; it is not what constrains the application's own queries, which are governed by the authorization checks above.
• Key custody. The key that can read the database is server-side only and is never sent to a browser. The release build is verified to run with secrets absent from its environment.

Two limits worth stating rather than hiding. First, uploaded files are not scanned for malware unless an operator enables scanning, which runs inside the deployment rather than at an outside vendor; on a default install, files are stored and served unscanned. Second, the rule against writing secrets or document text into logs is enforced by engineering practice and code review, not by an automated check.

No online service can promise absolute security, and this page does not.

6. Signature records

Signing is performed in house; no e-signature vendor receives your documents. When a person signs, the record keeps the signer's address on the network, their browser identification, whether the signature was drawn or typed, the mark itself, where it was placed, and the times at which the request was sent, consent was given, and the signature was applied. The exact consent disclosure that signer accepted is stored word for word on their own record, along with any decline and its reason.

Before signing, a signer must affirmatively consent to do business electronically. That consent is required by the server, not merely presented by the page. The disclosure covers the legal effect, the hardware and software needed, the right to a free paper copy, and how to withdraw consent. A signer can obtain their executed copy, request a paper copy, or withdraw consent, and withdrawal permanently disables the signing link.

What a sealed record is, and is not. On completion the executed document is stored as a new version and a SHA-256 fingerprint of its exact bytes is recorded. That fingerprint is submitted to a public timestamping service which anchors it in the Bitcoin blockchain. This gives two real things: tamper-evidence, because re-hashing an altered file will not match, and independent proof that the document existed at a date. Anyone can check a document against its fingerprint without an account. Nothing runs on a blockchain, no contract self-executes, and no money or cryptocurrency moves. The anchor state is reported honestly as submitted, pending confirmation, confirmed, or unavailable, and is never presented as a blockchain proof that does not yet exist.

What it is not.The signing link is a secret address sent to the signer's email. BRON does not separately verify a signer's identity with a one-time code, a knowledge test, or an identity document. A person holding the link can sign. A firm that needs identity verification for a particular document should use a process that provides it.

7. The audit record

Sensitive actions are recorded to an append-only log: sends, signatures, phase changes, movements recorded in the trust ledger, changes to privilege or classification, conflicts decisions, deadline changes, and the creation and release of litigation holds. Updates and deletions are refused by the database itself, not merely avoided by convention.

Each entry is linked to the one before it by a cryptographic hash, so a removed, altered, or reordered entry can be detected, and the chain is periodically anchored to an external timestamp so the record cannot be quietly truncated at the end. The chain can be verified on demand. Records written before this mechanism was introduced remain in the log and are reported as unchained rather than being backfilled, because a backfilled hash would assert an integrity guarantee over history that nobody actually proved.

8. What is stored on your device

BRON's application code sets no cookies.Sign-in uses a token held in the browser's local storage rather than a cookie. There is consequently no cookie consent banner, because there is nothing for one to gate.

Local storage also holds interface preferences such as theme and panel widths, dismissal flags for notices you have closed, and drafts of work you have typed but not yet sent, including document drafts, questionnaire answers, and unsent portal messages. Drafts are kept so that a closed tab or a lost connection does not destroy your work. None of it is an identifier kept for measurement or advertising.

There is no analytics or tracking of any kind.No analytics package, product telemetry service, session recording, heatmap, advertising pixel, or tag manager exists anywhere in the application. No third-party error-tracking service is used. Interface fonts are served from BRON's own address rather than an outside font provider.

Three scripts load from another company, each only on the screen that needs it: payment fields on the client retainer screen, the bank-linking dialog used for trust reconciliation, and the Microsoft library required by the Word and Outlook add-ins. Each corresponds to a provider named on the sub-processors page, and each appears only if the firm enabled that feature.

BRON does not control what a hosting or network provider may set at the edge, and this section describes the application rather than that layer.

9. Support reports

When a signed-in user submits a support report, it carries the page they were on, the matter identifier if there was one, the application build, their browser identification, and recent error messages the browser had already logged. The form displays all of this before it is sent. It carries error messages and page paths only, never a request or response body, never a query string, and never document text. Errors are held only in the browser's memory until a person chooses to submit them; nothing is transmitted automatically.

10. Public intake and the demonstration

A public intake can collect contact details, an account of a possible matter, and documents a visitor chooses to provide. That information is delivered to the legal team for review; submitting it does not itself create an attorney-client relationship, and no matter exists until a firm accepts one.

The public demonstration reads fictional, isolated records. It cannot open a firm or client record and cannot write, send, sign, upload, download, export, or move funds. Do not put confidential information into it.

11. Retention, deletion, and your rights

Depending on where you live, you may have rights to access, correct, delete, restrict, or receive a copy of personal information, and to be free from discrimination for exercising them.

If you are a client of a law firm, direct your request to the firm. The firm is the controller and decides how professional duties, privilege, and litigation holds apply. A request sent to BRON about matter records will be referred to the firm. If you are a user of the platform and your question is about your own account, use Support.

What can be deleted, and what cannot. Some records are deliberately not deletable, and a firm cannot promise otherwise:

• Trust ledger entries and the audit log are append-only. Corrections are made as adjusting entries. They are not edited or removed.
• Material under a litigation hold cannot be deleted or edited while the hold is in force. Deletion attempts are refused, and if the scope of a hold cannot be determined the deletion is refused rather than allowed.
• An account that still owns matters or a firm with other members will not delete, because financial and court records must be retained under professional rules.

Retention.A matter that is closed is stamped with a seven-year retention date and raises a review task when that date passes. Nothing is destroyed automatically. Beyond that stamp, retention follows the firm's own professional obligations and instructions rather than a period set by BRON. This page does not state a general retention period, because the software does not implement one.

Getting your data out. A firm can export its records at any time, for one matter or for the whole firm, without asking BRON. The archive contains the document files, the matter data in a documented interchange format, the audit trail, and a manifest of fingerprints with an independent timestamp proof.

12. International transfers

Data is held in a single configured cloud region. Model providers and any other connected services process data in the locations described in their own terms, which can be outside that region and outside your country.

[OWNER: name the hosting region, and state the transfer mechanism relied on for users in the UK, EU, or Switzerland, for example standard contractual clauses. The repository records neither, so nothing is asserted above.]

13. Children

BRON is professional software for law firms and is not directed to children. Accounts are created for people working at a firm or for a firm's clients. A matter may nonetheless contain information about a minor, because litigation records sometimes do. That material is handled as matter content under the firm's control and subject to the protections in section 3.

14. Security incidents

A suspected security incident is triaged and scoped, and the firm is informed so that it can meet its own obligations to its clients and to regulators. The append-only audit record described in section 7 exists in part so that the extent of an incident can be reconstructed rather than guessed at.

[OWNER: state a notification commitment and its timeframe, for example notice without undue delay and within a stated number of hours of confirming an incident affecting a firm's data, and name the channel notice will be given through. The repository records no commitment, so none is made above. A firm's general counsel will ask for this.]

15. Changes to this notice

This notice is updated as the product changes, and the date at the top reflects the most recent revision. A firm with a signed services agreement should look to that agreement for any notice commitment; this public page is not itself a notice mechanism.

16. Contact

Signed-in users can reach the team through Support. Prospective firms can use Request a consultation. A client of a law firm should contact the firm.

[OWNER: publish a monitored privacy contact address and, if one is appointed, a data protection officer or EU or UK representative. No email address exists anywhere in the repository, so none is printed here. A privacy notice reachable only by signing in is a real gap for anyone who cannot sign in.]

This notice, and each firm's configuration of the product, should be reviewed by qualified privacy counsel for the jurisdictions in which the firm practices.