RecoveryOS · Security & Data Handling Overview

Print-optimized security dossier. Use your browser's Print → Save as PDF. Download as PDF

Section A

What this one-pager answers

This page answers the standard procurement-officer security questionnaire for RecoveryOS. It is written for county ADAMHS boards, ORH, and judicial-officer procurement teams who need to complete a vendor review without round-trip email. What follows is factual and current as of the date above — no marketing padding, no aspirational claims presented as certified posture.

Where records live, who can access them, and how they are protected in transit.
Retention defaults and one-click export for records produced in the system.
What PII is stored vs. derived, and what is never shared externally.
Role-based access model and what the system writes to audit trails.
What we have verified against the running product, and what we have not.

Section B

Where records live

All production data resides with US-based infrastructure providers under separate contractual and certification postures listed below. SoberBase does not operate its own data center.

Component	Provider	Where it lives & how it is reached
Application runtime	Render	US region (Render US default). HTTPS only at the edge; no HTTP fallback for any production route.
Database (PostgreSQL)	Neon	US, managed Postgres instance. Connections from the app enforce TLS (SSL required, hostname-independent verification) on every query.
File / photo / document storage	Cloudflare R2 (via Polsia)	US, object storage. All uploaded artifacts — drug-test photos, intake signatures, incident attachments, court progress reports — are stored here rather than on the application server.
Outbound email delivery	Polsia authenticated email proxy	All platform email is dispatched through the Polsia email proxy at `polsia.com/api/proxy/email/send` — we do not run our own SMTP infrastructure.
Operator / staff sessions	RecoveryOS application	JWT-signed tokens. The signing secret is a required environment variable on the deployed app; tokens carry operator id, role, and tenant id claims, and are verified on every authenticated route.

Encryption: TLS in transit for all production traffic; data is encrypted at rest by the infrastructure providers listed above. SoberBase does not run an additional application-layer encryption layer on top of provider-managed storage.

Section C

What is stored, derived, and never shared

The system stores only what an operator or resident enters into a form. It does not enrich records from third-party data brokers, ad networks, or social platforms, and does not transmit resident data to any external service other than the email proxy (transactional notices) and Stripe (rent collection, where a resident is paying rent to an operator).

Resident name & identifying details

Stored as entered at intake. Visible only to the operator and operator-invited staff inside that operator's tenant; never shared.

Date of birth & demographics

Stored as entered on the intake wizard. Used only for in-app eligibility and reporting; not exported to third-party services.

Phone numbers

Stored as entered. Used to deliver transactional SMS notifications when the operator opts in; never re-sold or shared.

Intake signatures

Stored as an image artifact in Cloudflare R2 with the resident record id and a creation timestamp; not derived or analyzed by any AI model.

Drug-test photos

Stored with GPS metadata and capture timestamp at the device level. The system logs the artifact but does not perform automated result inference — all readings are entered by the operator.

Rent ledger entries

Stored as entered by the operator and as recorded by Stripe (when Stripe Connect is used). Visible only to the operator's tenant and to the resident for their own record.

Incident reports

Stored as written by staff. Visible only inside the operator's tenant and, where the operator has opted in, surfaced to requesting judges via the public judges-portal lookup.

Court progress reports

Generated on demand from the underlying tenant data. Delivered to the requesting judicial officer via email; not retained outside the operator's tenant.

Admin / support audit entries

Written to the court_audit_log table when a SoberBase admin accesses a sensitive artifact on behalf of an operator. Capture: actor, target, action, and a JSON snapshot of the access detail.

Derived / computed signals

Compliance scores, missed-test alerts, and arrears balances are computed at query time from the underlying records. They are not stored in a separate modelling layer and are not shared with any third party.

Section D

Who can see what

RecoveryOS enforces strict tenant isolation. Every authenticated query joins on the requesting user's tenant id; there is no shared-data table in the schema. Roles below map to product behavior, not to a marketing-tier label.

Role	Where it can see	What it can write
Operator (account owner)	Own tenant — every house, resident, ledger, and document.	Full read/write across the tenant, including staff invitations, house settings, and Stripe configuration.
Staff (invited by operator)	Own tenant, scoped to the houses they have been assigned to.	Compliance entries (drug tests, check-ins, incidents, chore logs) inside their assigned houses; no administrative or financial configuration.
Resident	Own record only — via the resident portal (login token).	Own check-ins; read access to their own intake, ledger, and progress notes.
SoberBase admin (support)	Cross-tenant, for the purpose of operator support only. Resident-data access is exceptional and requires a written support ticket from the operator.	Read-only on the operator's tenant; all access is recorded in `court_audit_log` with actor, target, action and detail payload.
Judges & probation officers (public)	Read-only via the public `/judges` lookup. No login required. Only operators who have explicitly enabled `judges_public_opt_in` are discoverable.	Compliance-report request submissions; no record creation, no edits.

Audit trails: every write to a sensitive artifact (drug test, incident, intake, rent charge, document, court progress report) carries a server-side creation timestamp and, where applicable, an actor id linking the change to the user who made it.

Section E

What is honest about our compliance posture

We split this section deliberately. The verified column maps directly to behavior that exists in the running product today; the aspirational column lists items that procurement teams regularly ask about — and where we stand on each.

Verified against the product

TLS in transit to the database — connections from the app to the managed Postgres instance enforce SSL, with verification enabled.
HTTPS-only at the edge — the Render app terminates HTTPS; no production route can be reached over plain HTTP.
Bcrypt-class password hashing for operator, staff, and resident credentials at signup and on every login.
JWT-signed sessions — tokens are signed with a required environment-side secret and carry role + tenant id claims; signatures are verified on every authenticated route.
Per-tenant row-level segregation — every query joins on the requesting user's tenant id; cross-tenant reads are not possible through any UI or API endpoint.
Tamper-evident timestamps on drug tests, incidents, rent charges, documents, and intake assessments — every record carries a server-side created_at that the client cannot alter.
court_audit_log on sensitive accesses — SoberBase admin access to a tenant's sensitive artifacts writes an audit entry with actor, target, action, and detail.
One-click exports — ORH Audit Export (full tenant data) and operator-side PDF reports are available without engineering request.
Data export on account closure — operators retain the ability to export their complete tenant record set at any time, including after account closure.

Not certified (read carefully)

SoberBase LLC is not itself SOC 2 audited. We do not represent the certifications of our infrastructure providers as our own.
We do not offer a Business Associate Agreement (BAA). RecoveryOS is not a HIPAA Business Associate.
No formal HIPAA attestation or HITRUST certification on file.
No FedRAMP authorization.
No formal third-party penetration-test report on file at this time.
No formal disaster-recovery RTO/RPO committed at the SLA level. Records are retained while the operator account is active, with on-demand export available above; extended point-in-time recovery beyond provider-managed backups is not committed.

Where this leaves us. RecoveryOS follows HIPAA-aligned technical safeguards (encryption in transit, role-based access, full audit trails on sensitive access) — but SoberBase LLC is not a HIPAA-certified covered entity or Business Associate. Our infrastructure providers (Neon, Render, Cloudflare R2) maintain their own SOC 2 / ISO 27001 / PCI certifications where applicable; we do not represent those certifications as our own. We are happy to walk through any specific control on a procurement call.