Your case files stay yours.

Every table in the database has row level security turned on. What you are allowed to read is decided by a firm id carried inside your signed session token, and a query that arrives without a matching claim comes back empty. That is a rule the database enforces, not a filter in application code that someone has to remember to write.

Uploaded medical records and intake forms sit in a private bucket with its own row level policies, separate from the database ones. No attorney session can read that bucket — there is no policy granting it, so a guessed or leaked file path returns nothing. When you open a document, the server checks your access and issues a link scoped to that one file and valid for sixty seconds. Generated documents are readable only by sessions carrying your firm's id, matched against the firm id in the storage path. The server's own connection bypasses both layers by design, as in any system where a backend reads files on your behalf.

Traffic runs over TLS. The application sends Strict Transport Security with a two year max age across subdomains and submitted for preload, upgrades insecure requests, and restricts the browser to talking with its own origin and the database API and nothing else. You can verify every one of those with a single request against the live site.

At rest, files and database rows sit on Supabase and Vercel infrastructure, which encrypt their storage volumes.

Signing in means clicking a single use link sent to an address on a domain your firm registered in advance. An address outside those domains cannot receive one. The link is spent by submitting a form rather than by loading the URL, which is what keeps corporate mail scanners from quietly consuming it before you get to it.

Session cookies are HttpOnly, so page scripts cannot read them. The application runs a nonce based content security policy: a fresh nonce for every request, and no inline script executes without it.

Sign in attempts are capped at five per email address and fifteen per network address each hour.

Your email tenant is the authentication boundary. Whoever controls a mailbox on your firm's domain can reach the account, so enforce multi factor authentication there.

Administrator access requires two step sign in. A support feature lets the administrator view the application as one of your users while working a problem. It is cryptographically signed, tied to the administrator's own account, expires after an hour, and every use of it writes to the append only log described below.

The Bill of Particulars uses only the last four digits of a Social Security number. CPLR 3043(a)(1) makes those four digits a demanded particular, so a bill that omits them is deficient on its face. The system never asks for or outputs a whole number. A document your firm uploads may contain one, and those uploads are deleted after thirty days as described below.

Full numbers printed inside document text are masked before anything reaches the model. The mask covers the printed three two four grouping and nine digits following a Social Security label, and it replaces each digit in place so citation offsets still land where they should. The limit, in the same breath: pages that go to the model as images — scans, and smaller PDFs forwarded as the firm supplied them — are not masked, because there the number is pixels, and rewriting the file would mean re-rendering a legal exhibit.

Case content is sent to Anthropic's API, which drafts the answers. Under Anthropic's commercial terms, inputs and outputs from the API are not used to train its models.

Anthropic's standard commercial retention applies to what is sent. A zero retention arrangement is not in place on the account today.

The draft is built from the full record. Source PDFs and their extracted text are sent as your firm supplied them, so the medical records, the police report and the intake form are all included, subject to the Social Security masking described above. The pipeline removes the uploaded copies from Anthropic when drafting finishes. A removal that fails is not yet retried automatically.

Nothing from your firm is shared with another firm, sold to anyone, or used to build or tune a model of our own.

The two patient identifying uploads — medical records and the intake form — are deleted thirty days after upload. Those are the files carrying diagnoses, imaging, treatment history, date of birth and employment. The bill of demands and the police report are kept: they are litigation documents already exchanged between the parties, they contain no medical history, and destroying a case's own demand schedule would leave a generated document nobody could later explain. A job runs daily and performs the deletion. A separate monitor checks daily that it actually ran, and alerts if it fails twice in a row.

Thirty days is a minimization policy, not a legal rule. CPLR 3042(a) gives thirty days to answer a demand, so the drafting work those files support is finished well inside that window and there is no reason for us to go on holding Social Security numbers and treatment histories. Your own file retention obligations are separate from ours and they run far longer. Keep your own copy of everything you upload. This is not a system of record.

Deleting those PDFs does not make the medical facts disappear from the system. The drafted answers carry the injuries, the treatment, and the disability dates. The citation snippets quote the records word for word. The Bill of Particulars recites all of it, because reciting it is what the document is for. Those stay until you delete the case.

You can delete a matter. It is real and it is irreversible: the case row, every generated document, the citation review, the answer sets and every uploaded file go, in the database and in both storage buckets. There is no trash and no restore, and a deleted case cannot be regenerated, because its inputs are gone. One line survives in the activity log recording that a deletion happened, so you can evidence it — the case name, who pressed the button, and a count of files removed. Nothing read out of a document.

Your firm can read its own activity log: the key actions taken in your account, who took them, and when. It records each thirty day purge, so you can evidence that the deletions happened rather than take our word for it.

The log is append only. No part of the application can change or remove a row — update and delete are not granted to any role the application uses, including the server's own.

Six companies are involved. Four of them process case content, and only to run the service: Supabase stores the database, the sign in system, and the uploaded files, Vercel hosts the application, Modal runs the compute that generates the documents, and Anthropic provides the model that drafts the text. The other two never receive a case file: Resend delivers the sign in emails, and Stripe handles billing.

These are business services, not consumer ones. Each company processes your firm's content on our behalf under its commercial terms, and Anthropic's terms state that API content is not used to train its models. Inside the application, nothing goes to an analytics vendor, an advertising network, or a data broker.

All four companies that process case content are independently audited. Supabase, Vercel, Modal and Anthropic each hold a SOC 2 Type II report, which covers how access to customer data inside those companies is restricted and logged, and Anthropic also holds ISO 27001. Each makes its report available on request. Those audits cover their systems; BP Portal itself has not been audited. If we add a subprocessor we will tell your firm before it happens.

The first question a firm asks us about medical records is whether this is HIPAA compliant. The accurate answer is that HIPAA almost certainly does not reach your firm in this work.

HIPAA binds covered entities and their business associates, and 45 C.F.R. 160.102 and 160.103 say who those are: health plans, health care clearinghouses, providers who transmit health information electronically in connection with a covered transaction, and the vendors who handle protected health information on their behalf. A plaintiff side personal injury firm is none of those. When you obtain your own client's records by authorization to prosecute your own client's case, you hold them as that client's lawyer, not on behalf of a provider. No business associate agreement exists at the top of that chain, which means there is no chain for us to sit in the middle of and no agreement we could sign that would mean anything.

That is not the same as saying the records are unregulated, and here is where it does bite. If your firm also does defense side or provider side work, that engagement can make the firm a business associate, and then a business associate agreement is required and we would need to be under one before touching those files. Records you obtained under a qualified protective order carry a return or destroy obligation at the end of the litigation under 45 C.F.R. 164.512(e)(1)(v), and that obligation follows every copy, including the one here. Substance use disorder treatment records from a federally assisted program are governed by 42 C.F.R. Part 2, which is stricter than HIPAA, travels with the record, and requires a specific written consent plus a notice against redisclosure. HIV related information is governed by New York Public Health Law article 27-F, with its own release requirements and its own redisclosure notice. If any of those four apply to a case, tell us before you upload it, because they change what we are allowed to do rather than only what we ought to do.

What does govern this, for both of us, is New York law. General Business Law 899-bb requires reasonable administrative, technical, and physical safeguards for the private information of New York residents, and 899-aa requires notification when it is breached. That applies to your firm and it applies to us, and it applies whether or not a single page in the file is a medical record. Layered on top of it is your own Rule 1.6(c) duty to make reasonable efforts to prevent unauthorized disclosure of client information, which is a professional obligation the vendor cannot discharge for you. Everything on this page is written so you can perform that judgment on real facts.

Security monitoring covers repeated rate limit trips, spikes in failed sign ins, and administrative access outside working hours. Application errors and failed generations raise automatic alerts. Dependency updates are automated.

There is a written incident response plan. It sets severity levels, containment steps, and how evidence is preserved while an incident is still open.

Our commitment: if we confirm that someone reached your firm's data without authorization, we will tell your designated contact as soon as possible, and no later than 72 hours after confirming the facts, and we will share what we know about how much and how long even while the picture is still incomplete. New York's SHIELD Act, General Business Law 899-aa, places breach notification duties on us directly, separate from anything we sign.

BP Portal has layered security monitoring in place to detect signs of a break in or misuse. It watches for repeated failed sign ins, unusual bursts of requests, and administrator access outside working hours, and it alerts the administrator when something looks wrong. If unauthorized access to your firm's data is confirmed, your firm is told as soon as possible. Application errors and failed generations raise alerts as well, and a written incident response plan sets out what happens next.

The infrastructure BP Portal runs on is independently audited, as described under Subprocessors. If your firm or its carrier needs a completed security questionnaire or a specific level of insurance coverage, tell us what is required.

Write to us and we will reply as soon as possible. Specific technical questions get specific technical answers. The contact page reaches us, and so does replying to any email we have sent you.

This page describes the system as it is built today. It is not legal or compliance advice. Your firm makes its own judgment under Rule 1.6(c) about whether these arrangements are reasonable for the information you hold, and this page is here to give you the facts to make it.