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, whether a deposition is captured, which of its own systems hold a credential to read the record, 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 15 explains how to make a request, and what no one can promise.

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, product-support correspondence, and Counsel Club applications. Those are described below and are not matter material.

2. What BRON handles

Counsel Club applications. BRON collects the contact and professional details you submit, what you can help with, whom you would like to meet, and any person you name as an inviter. BRON uses this information to review your application and contact you about membership. Applications are private to the club review team; submitting one does not publish a profile, create a BRON firm account, or subscribe you to product marketing. We record your participation consent and, separately, your optional choice to receive club news and event invitations. You can withdraw that choice, request a correction, or ask us to delete your application by emailing contact@bronlaw.com. Do not include confidential client or matter information.

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.
• Deposition and hearing transcripts. Where a firm runs the live deposition surface, the spoken record becomes transcript turns on the matter. Section 6 describes the microphone, where the audio is transcribed, and the gate that decides when anything is captured at all.
• Signature records. Described in section 10.
• 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 11.
• Credential and agent-access records. The prefix, class, scopes and usage of any API key a firm mints for its own systems, and the proposals an outside agent has filed. Section 7.
• Support correspondence. Described in section 13.

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, and the shape of that matters. Clearance is granted by a positive allow-list of the two reviewed values, never by subtracting the forbidden ones. A document whose privilege has never been reviewed carries no value at all, so it is withheld rather than released. A document whose record cannot be found in the lookup is dropped rather than passed through. If the lookup itself fails, the portal returns a temporary error instead of a list that silently omits the filter, because a subtractive filter over an empty result removes nothing and would have exposed everything. Ethical walls work the same way: if the screen cannot be read, access is denied rather than granted.

4. The client portal boundary

A client of a law firm sees a deliberately narrow slice of their own matter, and nothing outside it.

What a client can reach. The status and published narrative of matters they are a party to, documents the firm shared that also passed the privilege and protective-order screens in section 3, their own messages with the firm, signature requests addressed to them, their obligations and document checklists, decisions the firm has put to them, discovery answers they are drafting, a calendar feed of their own dates, their invoices and trust balance where the firm has granted a billing entitlement, and an export of their own matter.

What scopes a portal read. Every portal endpoint is scoped to the signed-in client and the specific record, never to a session or a matter identifier alone. That pairing is not decoration: a cross-client write was once possible when only one half was checked. Ethical-wall screens apply to a client seat exactly as they apply to a firm seat.

Organizations. Where the client is a company rather than a person, several authorized users can hold seats, each with a role and a view scope: the whole matter, billing only, documents only, or status only. The scope is resolved on the server for every read. A billing contact does not see strategy because the interface hides it; they do not see it because the read never returns it.

The portal assistant. The assistant a client talks to carries privileged matter context, so it is pinned to one model path and opts out of the substitution described in section 5. If that path is capped or unavailable, the turn refuses rather than sending the client's matter context to a different vendor, and the record of the turn stores no answering model rather than claiming one.

5. AI vendors, 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 vendors in use. The model vendors that receive client content are Anthropic, reached directly or through Amazon Bedrock where the deployment selects that transport; OpenAI, for chat when a firm selects one of its models (it receives no audio); Google, when a firm selects a Gemini model; Voyage AI, which computes the embeddings that make documents searchable; and OpenRouter, a model router, for a firm that has permitted it, as described below. What each one receives is set out on the sub-processors page.

What the software enforces, stated exactly. The enforced control is vendor identity. A gate runs at every credential factory that can carry client content to a model vendor, and it throws before the key is read and before a request body is built, so a refusal sends no bytes. The set of permitted vendors is a reviewed constant in code. An environment variable can narrow it and cannot widen it, so an operator typo cannot open a new egress path, and a firm running in sovereign mode contracts the set to its own endpoint. The refusal names the vendor and the code path only, never a key, a prompt, or a document byte. The embedding vendor has one more gate: its egress also refuses unless an operator has recorded it in a second, separate setting, because a single setting moves a firm's entire corpus through it. OpenRouter has that second gate too, and a third: the firm's own record, described below.

What this page does not claim. The software does not observe what a vendor keeps or whether it trains on what it receives, and this page makes no statement about either. A firm that needs particular vendor terms should ask about them in diligence.

A model router, only where a firm permits it. Since 1 October 2026 OpenRouter, a model router, is in use again for a firm whose administrator has permitted it and recorded a declared agreement for it; for any other firm it is refused. For such a firm it is, by default, the first choice for most of the product's AI tasks, among them the attorney assistant, extraction from uploaded documents, search, the daily brief, document analysis and privilege classification, so privileged material reaches it. It passes each request to an upstream company that hosts the model, from a list reviewed in BRON's code. Each firm's routed spending is capped by the request, the day and the month, and a request that any check refuses goes to a model reached directly instead, or is not sent where a task allows no substitute. It carried routed requests in a pilot from 4 to 9 September 2026 and none from 10 to 30 September; the owner decided on 17 September 2026 to stop routing through it, and on 1 October 2026 to keep it in use. The sub-processors page sets out the details.

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

• Scanned pages. When a PDF page has no text layer, or a document is uploaded as an image, the image of the page is sent to the primary model vendor to be read, in addition to a first reading inside the deployment. A deployment that runs its own recognition host sends fewer pages, not none: a page that looks handwritten, or whose readings disagree, still goes to the vendor.
• Search indexing. Making documents searchable sends every uploaded document, in pieces, and every search query, to an embedding vendor. This happens even where every model a user talks to is from a different vendor.
• Deposition audio. Since 29 September 2026, live deposition audio is transcribed on BRON's own servers, in BRON's AWS account, not by a hosted model vendor; before that date it went to OpenAI. It is still privileged testimony leaving the firm's office for those servers, and section 6 sets out the whole path.
• Dictation. Dictated audio, and call recordings a firm sends for transcription, go to the same BRON transcription servers, also since 29 September 2026. No audio goes to OpenAI.

Vendor substitution. If the primary vendor is unavailable or a quota is exhausted, a request can be retried automatically with a different one. The client portal assistant is the exception and refuses instead, as section 4 describes. A firm that needs all of 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 vendor. 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.

6. Deposition capture on firm-supplied glasses

A firm can run a deposition with a heads-up display on glasses its own attorneys wear. This is the most sensitive capture path in the product, so it is described in full rather than summarized.

The hardware is the firm's. Glasses are not supplied with the product, and nothing is captured without a paired device in the room. Pairing uses a short code the attorney reads across the table, valid for ten minutes, redeemable once, rate limited. The device credential that results is identity and nothing more: before a device can join a session, the server re-proves current licensed-attorney membership in that exact firm, ownership of the session, access to the matter, and the ethical-wall screen.

Capture starts only when an attorney goes on the record, and that is a server rule. With the session off the record the audio path refuses and answers that it is not on the record; nothing is transcribed and nothing is stored. On the record, the microphone is testimony and the voice-command path refuses instead. The two can never both be open, because a command spoken on the record would be heard by the reporter and land in the transcript as testimony. Going on and off the record is itself written to the audit record as an event with the attorney who did it.

Where the audio goes. Since 29 September 2026 a silence-bounded utterance is sent to BRON's own transcription servers (gpu.bronlaw.com, in BRON's AWS account), described on the sub-processors page, and what comes back is stored as a transcript turn on the matter. The software sends audio only to a host the deployment declares by name as keeping nothing beyond the job. No hosted model vendor receives it, and there is no fallback to one: if those servers cannot transcribe an utterance (they are starting, or down), the transcript shows "[audio not transcribed]" at that point instead. Before 29 September 2026 the utterance went to OpenAI. While a session that uses the room microphone is open, BRON keeps the servers running so answers are not lost to a start-up, for at most 10 hours per session. The platform keeps the transcript text; it does not file the recorded audio as a document in the matter. A firm that does not want testimony audio to leave the room at all should attach a stenographic feed instead of using the room microphone.

No invented citation. Only a licensed stenographic feed carries a real page and line. A turn captured from a room microphone is stored with none, because an anchor derived from speech would be a fabricated record cite.

Rehearsals are fenced off from the record. A preparation session with a firm's own witness runs the same pipeline but mints no transcript row, never runs the end-of-session rollup, and never touches the on-record machinery, because nobody is being sworn. Every alert it produces is marked so that production sets, the client portal, and opposing-facing exports filter it out.

Two runtimes, at two maturities. The Even G2 path is the shipped one. The MentraOS path is in beta and is not cleared for a client deposition: audio isolation and all-day residency are both unproven on that host, and two owner-run checks stand between it and client use.

7. A firm reading its own record through its own software

A firm can point its own systems, including its own AI assistant, at the record through a credential it mints and revokes itself. This is a real egress path and it is governed rather than open.

• The class is set per key. A key is either attorney class, which acts as its owner and reaches the attorney-grade record, or client-safe class, which is forced onto the same privilege-gated view a client would get. Minting an attorney-class key requires a firm administrator; any firm staff member may mint a client-safe one. An administrator can list and revoke every key held by anyone at the firm, which was not true when keys were visible only to the person who created them.
• Scope, not reach. Each key carries its own scopes and an optional per-matter allow-list. Every matter identifier a caller supplies is resolved through the key owner's own matter set, minus ethical-wall screens, intersected with that allow-list. A matter identifier that skips that funnel is refused rather than trusted.
• Authorization is re-proved, not leased. Every request re-presents the key and is re-authorized from scratch. A held streaming connection is re-authorized on a timer, so a revoked key loses its stream rather than keeping it until it disconnects.
• Reads carry their own provenance. An answer comes back with the record identifiers behind it, a verification status, and the as-of time of the data rather than of the response. Where the verification lane cannot be read the status is reported as unknown, never upgraded, and a mixed payload reports its weakest item rather than an average.
• An outside agent cannot act. It can file a proposal, which writes a row into the same approval inbox a person already uses and executes nothing. The proposal is capped at the lowest rung of the trust ladder whatever a firm has granted elsewhere, and any attempt to supply a confirmation token, a matter identifier, or an override flag is stripped and shown on the card rather than silently dropped. If a person approves, the full gate stack runs again from the stored row.
• Logs over that surface are an allow-list. Only fixed event shapes may be emitted. Prose logs are not forwarded and not heuristically scrubbed, because existing log lines can contain document text, client names, or matter captions.

8. Phones, extensions, and document add-ins

The iOS app. There is a native app for firm staff and for portal clients. What it holds on the device is the signed-in session and whatever it has fetched to display. Two protections are worth naming because they are about people in a room rather than attackers on a network. A privacy cover obscures the content the moment the app stops being active, whether or not the lock is switched on, because that frame is what the system captures for the app switcher and a matter caption in it is a disclosure. Re-authentication uses Face ID, Touch ID, or the device passcode, defaults on for firm staff and off for portal clients, and is remembered per signed-in user so one person's preference does not follow the next. The app also watches whether the screen is being recorded, mirrored, or sent to an external display, and treats an undetermined answer as exposed rather than private.

The share extension. Sharing a file into a matter from another app uses a protected shared container that holds one short-lived access token. Refresh credentials never enter it and it is removed on sign-out. The container is context, not authority: the server still proves the bearer may see the selected matter on every call.

The widgets. Home-screen and lock-screen widgets read a single file the app writes, and the widget process holds no token, no client, and makes no network call of its own, so everything a widget can ever show passed through one place first. The contents are counts and neutral phrases. Matter names are off by default and are opt-in, and the file is wiped on sign-out.

The document add-ins. Panels for Word, Outlook, Google Docs, and Gmail run BRON's citation and pre-filing checks where an attorney already works. Each sends the text of the open document or message to BRON to run those checks, against the same server core the application uses, so the two cannot return different answers about the same draft. Permissions are deliberately narrow: the Outlook add-in asks to read the open item rather than for mailbox write access, and the Gmail add-on asks for the open message and an outbound request and nothing else. Neither sends, edits, or files mail.

9. 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-vendor 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.
• Second-factor enforcement. When an account has a verified second factor, the API requires it rather than leaving that to the screen, so a client that renders without it still cannot call. If the API cannot tell whether an account has one, it refuses rather than guess. There is no setting yet by which a firm can require its members to enroll a second factor.
• Database row-level security. Switched on table by table as tables are created, denying by default. A read-only check of the production database on 27 September 2026 found it on for all 703 tables in the application's schema, with no policy that lets a signed-in user or an anonymous caller read or write a row. No automated test repeats that check, so it is a reading on that date, not a guarantee. 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, with the one exception named in section 7.

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

10. 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. When signing finishes, 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.

11. 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, going on and off the record in a deposition, 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 guard over history that nobody actually proved.

Several separate ledgers are kept this way, and they are not all worth the same thing. A hash chain over sequence-numbered rows makes both backdating and selective omission detectable. A set digest detects a later edit but carries no ordering evidence between anchors. A one-off receipt proves that one artifact existed at a time and nothing more. The internal surface reports which kind each ledger is rather than showing one green mark for all three, and a firm reading it is told its ledgers' legacy row counts rather than having them netted away.

If rows ever are removed, the removal is disclosed rather than suppressed. A removal that happened is recorded in the firm's own hash-chained activity log, naming the ledger, the exact range, and the person, where it cannot be backdated, removed, or made anonymous. A ledger known to have been cut can no longer claim nothing was ever removed. It can claim that everything that happened to it is on the record and checkable, and that is the claim BRON makes.

12. What leaves the building, and what an outsider can check

There is one place where anything related to your matter is visible to a party with no account, and it is worth stating precisely what that is.

What leaves is a digest, never content. The thing submitted to the public timestamping service is a SHA-256 fingerprint. It is not the document, not an extract, not a title, and not a matter or party name. A fingerprint cannot be turned back into the file it came from.

The same holds for collections. Since 29 September 2026, the fingerprint of each collection manifest the firm receives (a hash computed over the hashes of the listed items) is sent to a public time-stamp authority, DigiCert, or Sectigo when DigiCert does not answer, together with a random number. Nothing else is sent: no collected content, no file names, no names. The token that comes back lets anyone check when that fingerprint existed without relying on BRON.

There is also a public lookup that answers, for a digest someone already holds, whether it was committed and when. Holding the digest already means holding the artifact, so the answer is a verdict and nothing else: no matter, no party, no title, no filename, no identifiers. A digest that is unknown and a digest that belongs to a different kind of commitment get the same answer, so the lookup cannot be used to confirm a guess.

What a receipt proves, and what it never proves. A one-off receipt shows that one exact artifact existed at a time. It says nothing about whether anything else was withheld: anchor a hundred documents, show a reader one, and its receipt still checks out. Only the tip of a sequence-numbered append-only chain makes an omission detectable. BRON does not claim that a receipt proves a record holds everything, and a reader who took it that way would have been misled.

13. 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. Optional public-site insights have a separate Privacy choices control, described below.

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. What the mobile app keeps on a phone is in section 8.

Analytics on the public website only. bronlaw.com counts page views and a few named actions, such as opening the walkthrough or sending the demo form, using Umami, an analytics tool BRON runs on its own servers. It sets no cookies, does not store IP addresses, skips visitors whose browser sends Do Not Track, and never records names, email addresses or anything typed into a form. It records the page, the referring site, the browser and device type, and the country. Nothing is measured inside the application your firm or your clients use.

Optional website insights. With your permission through Privacy choices, we also record clicks and scrolling on selected public marketing pages to create heatmaps and session replays. Page text is masked, forms and editable fields are excluded, and URL query strings and fragments are removed. Recordings and heatmap samples are kept for up to 30 days in the active system; encrypted backup copies expire within a further seven days. You can stop future recording through Privacy choices; your preference is stored in this browser. Do Not Track and Global Privacy Control disable recordings. These recordings never run inside the attorney app or client portal.

There is no advertising pixel or tag manager, and no third-party error-tracking service. 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.

14. 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.

15. Public intake and product walkthroughs

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.

A product walkthrough arranged with BRON uses 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 a walkthrough.

16. 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.

If you need help finding the appropriate contact, use Support. Direct requests about matter records to your law firm, which decides how to respond.

Deletion on request is not something this software can promise, and the reasons are structural. Read this list before relying on a deletion right, because a notice that promised erasure without it would be wrong:

• The trust ledger is immutable by database rule. A posted entry on client money cannot be edited or deleted; the database refuses the write. A correction is an adjusting entry. This is a professional obligation over client property under ABA Model Rule 1.15 and its state equivalents, not a product preference.
• The audit log and the other tamper-evidence ledgers are append-only, for the reason in section 11: a record that can be quietly edited proves nothing about what happened.
• Material under a litigation hold is preserved and cannot be removed or altered while the hold is in force. Deleting it, replacing its version, editing it, or reformatting it are each refused by the same gate, and where the scope of a hold cannot be determined the deletion is refused rather than allowed. This is spoliation exposure, not a setting, and the hold is released by an attorney decision that is itself recorded.
• A fingerprint already submitted to a public timestamping service cannot be withdrawn. It is a digest and not content, as section 12 explains, and deleting the underlying document does not recall it. Nobody, including BRON, can un-publish it.
• 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, the common malpractice-record floor, and raises a review task when that date passes. Nothing is destroyed automatically, and an attorney can set a different date. 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. A client may ask their firm for their file at any time; there is no charge for getting it out.

17. International transfers

In BRON's own deployment, the database is in one cloud region, us-east-1; document files are held in us-east-1, and every file is also copied to a second US region, us-west-2; and the application server is in Ashburn, Virginia. Model vendors and any other connected services process data in the locations described in their own terms, which can be outside those regions and outside your country.

The configured hosting region and any transfer safeguards that apply to a particular firm are provided during deployment and contracting. For privacy questions about your environment, email contact@bronlaw.com.

18. 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.

19. 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 11 exists in part so that the extent of an incident can be reconstructed rather than guessed at.

If you suspect an incident, email contact@bronlaw.com. BRON will communicate with the affected firm through the contact route on its account and follow any incident-notice terms in the firm's services agreement.

20. 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.

21. 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.

For privacy questions or a request that cannot be sent through the site, email contact@bronlaw.com. Clients should also contact the law firm that controls their matter records.

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.