How we handle your data

The product has three data paths. Each is described below in the order data moves through it.

On the clinic side, clinic admins manage their own roster (provider bios, photos, specialties, fees, locations) through our org-admin portal. That data is stored in our database and is rendered in the widget. Clinic admins can only see and edit their own clinic's data — enforced both by row-level security policies in the database and by middleware-level authorization on every request.

FindMyProvider is built on a small set of infrastructure providers. Each is named below along with what they process and where.

We don't use third-party email, SMS, analytics, or error-tracking providers at this time. Payments are handled by Stripe (above), used only for clinic billing. If we add another subprocessor, this list updates and clinics receive an in-app notice 30 days before the change takes effect.

We use Anthropic's Claude models for three things: parsing what a client types into structured filter categories, generating a short personalized “why this might fit” sentence per match, and analyzing the chat conversation for the same.

What we send

• The client's short text (after server-side PII redaction — emails, phone numbers, SSN/SIN, DOB-shaped dates, and long numeric IDs are masked before the request leaves our server).
• Provider profile fields visible on the public card: name, bio, listed specialties, treatment approaches, matching tags. Never client identifiers.
• A system prompt that instructs the model not to ask for, repeat, or store identifying information — defense in depth alongside the redactor.

What we don't send

• Client name, email, phone, mailing address, date of birth, health-card or insurance ID.
• Booking history, appointment details, or any clinical record.
• Provider contact details (email, phone, license number) — those are stripped before any provider data leaves our server, even on internal AI calls.

Anthropic's retention

Anthropic retains API inputs for up to 30 days for trust-and-safety review and does not use API inputs to train its models. Their current commercial terms are at anthropic.com/legal/commercial-terms. We don't currently have Zero Data Retention enabled — that is on our roadmap for clinics with stricter requirements.

Rate limits

The AI endpoints are rate-limited per IP (30 requests per minute on chat, 10 per minute on insights and concern parsing) so a scripted abuse pattern cannot dump data through our API key.

We keep different categories of data for different windows. The principle: keep clinic-owned data while the clinic is a customer, and keep client-side analytics for the shortest practical window.

When enabled, Demand Insights dashboards aggregate widget events into category counts (e.g., “top searched concerns this month”). Cells with fewer than 10 distinct sessions are suppressed so a clinic admin can't infer an individual client's search.

Access to data is enforced at three layers, in this order, on every request:

1. Edge middleware — confirms the requester has a valid session and the right role for the URL (app admin, clinic admin, provider). Unauthenticated traffic is redirected before any page renders.
2. API route checks— every server endpoint re-verifies authorization against the specific resource, not just the role. A clinic admin from clinic A passing clinic B's ID receives a 403, not just a redirect.
3. Database row-level security — Postgres policies enforce org scope at the table level. If middleware and API checks both regress, the database itself rejects cross-clinic reads. Tested per-table with audit assertions.

Roles

• App admin (FindMyProvider staff): full read access for support and moderation. Actions are audit-logged.
• Clinic admin: read/write on their own clinic's providers, widgets, locations, and analytics. No cross-clinic visibility.
• Provider: read/write on their own profile only. Cannot see other providers' drafts or another clinic's data.
• Public (anonymous): can read only published providers and only the fields the client-facing card needs (name, bio, photo, listed specialties, fees). Email, phone, and internal identifiers are stripped from public responses.

Embed boundary

Each clinic widget can optionally lock the domains it loads on. When a domain allow-list is set, browsers refuse to embed the widget anywhere else (CSP frame-ancestors), and the widget's public APIs reject calls whose Origin doesn't match — so a third party can't reuse a clinic's embed snippet on a different site.

• In transit: TLS 1.2+ on every public endpoint (HTTPS only; HTTP redirects). Internal traffic between our application server and Supabase is also TLS-encrypted.
• At rest: Supabase encrypts the Postgres database and storage buckets at rest using AES-256. Backups are encrypted with the same standard.
• Secrets: API keys and database credentials live in Vercel's encrypted environment-variable store and are never written to source. The application server uses a service-role key with row-level security bypass only for two narrowly-scoped functions: the rate-limit counter and the daily retention prune. Both are tested.
• Passwords: handled by Supabase Auth (bcrypt- equivalent, no plaintext stored).

If we detect or are notified of a security incident affecting clinic or client data, our response is:

1. Contain — revoke compromised credentials, isolate affected systems.
2. Investigate — identify scope, root cause, and what data was reachable.
3. Notify — affected clinics within 72 hours, including what we know, what we don't yet, and what they should tell their clients.
4. Remediate — patch the underlying cause and add a regression test before closing the incident.
5. Post-mortem — public summary on this page within 30 days.

To report a suspected vulnerability or incident: info@findmyprovider.app. We acknowledge reports within one business day. We don't yet run a paid bug-bounty program; we credit researchers who report responsibly with their permission.

FindMyProvider is a Canadian product currently used by Ontario- based clinics. We design with PHIPA (Ontario's Personal Health Information Protection Act) in mind: minimize the client-side data we collect, store no clinical content, and keep what we do collect de-identified or short-lived.

What we have today

• Documented data flows, subprocessors, retention windows, and access controls (this page).
• Server-side PII redaction on every outbound AI request.
• Row-level security policies on every public-readable table, with audit tests pinning cross-org boundaries.
• 90-day retention sweep on widget telemetry, scheduled and tested.
• Per-widget embed allow-list for both iframe loading (CSP) and API origin enforcement.

What we're honest we don't have yet

• SOC 2 Type 2 — not in place. On the roadmap once customer demand justifies the audit cost.
• HIPAA / Business Associate Agreement (BAA) — not currently offered. The product is designed for Canadian clinics; HIPAA-covered US workflows aren't supported and we don't market to them.
• Anthropic Zero Data Retention — not enabled by default. Available on request as part of negotiated enterprise terms.
• Independent penetration test — not yet completed. Will be commissioned ahead of a formal SOC 2 audit.

If your clinic has compliance requirements not covered above — whether that's a specific data-residency policy, a contract clause, or a security questionnaire — email info@findmyprovider.app and we'll work through it with you. For procurement's sake we'd rather have the conversation than have you assume.