Trust
How we handle your firm's data
A PI caseload contains medical records, and that makes this the page worth reading before the product pages. Everything below is what the system does today. Where something is not done, it says so.
The shape of it
Your data is isolated at the database, not the query
Every tenant's rows are separated by row-level security in Postgres, so a query that forgets to filter returns nothing rather than somebody else's case. Isolation enforced in application code is isolation that fails the first time a query is written by hand.
PHI is treated as PHI throughout
Medical records and bills are the substance of a PI file, so the platform is built for protected health information rather than adapted to it. That shapes logging, retention and who can see what.
A business associate agreement, not a promise
Firms handling PHI need a BAA, and we sign one. It is a contractual matter and it is not what this page or any web page can settle - ask for it and we will send it before you commit to anything.
Where it lives, and how it is protected
United States, in AWS
The platform runs in AWS's Ohio region. Data does not leave the United States in the ordinary course of running the product.
Encrypted in transit and at rest
TLS on every connection, and encryption at rest on the database, the object storage and the backups. Backups are encrypted with the same key management as the data they came from - a backup that is easier to steal than the database is the way in.
Backups you can actually restore
Automated snapshots with point-in-time recovery. The number that matters is not the snapshot schedule but whether a restore has been rehearsed, which is a separate discipline and one we hold ourselves to.
Who can reach it
Multi-factor authentication, on by default
Not an option a firm has to find and enable. Enforcement is at the application layer, which is why it holds regardless of how a user was provisioned.
Permissions decided centrally
Authorisation is evaluated against a policy engine rather than scattered through the code as role checks. One place to read, one place to change, and no route that quietly forgot to ask.
Least privilege for us, too
Our own access to production is scoped and audited. The people who can reach customer data are few, and which of them did what is recorded.
How we run it
Changes go through review and CI
Every change is reviewed and every merge runs the full test suite, dependency scanning and static analysis. Nothing reaches production from somebody's laptop.
Dependencies are watched
Automated dependency updates on a weekly window, and vulnerability scanning that fails the build on a high or critical finding rather than filing a ticket nobody reads.
We know when it breaks
Errors and availability are monitored, and alerts reach a person rather than a dashboard. An alert nobody receives is not monitoring.
Certification, and what is coming
We do not hold a security certification today - not SOC 2, not ISO 27001 - and we have not yet had an independent penetration test. Both are coming: a SOC 2 Type II needs an observation window a company our age has not had yet, and the controls described above are the groundwork it will be audited against. We would rather show you that groundwork than describe an audit as though it were finished. If your procurement needs a certificate in hand today, we will not be a fit yet - and we would rather you learned that here than three meetings in.
Reporting something, or asking for more
Security reports go to security@onecounsel.legal, which is the same address published in our security.txt and on the security page - one address, monitored, so a report never arrives at a mailbox nobody reads. For a security questionnaire, a BAA, or our subprocessor list, ask and we will send them.