Trust & Security

1. Non-clinical product boundary

WellOps is designed for non-clinical operations, not clinical records. We ask users not to enter diagnoses, treatment records or other clinical content. Validation and pattern-based screening can flag or limit some sensitive entries but cannot detect or prevent every health disclosure, including information supplied in optional free text, intake, waivers or feedback. Providers should use their approved clinical system for clinical records.

• WellOps handles business logistics: corporate requests, quotes, event schedules, booking slots, invoices, and provider account data.
• We do not ask for, and we ask employees not to submit, medical histories, diagnoses, medications, or treatment records. Free-text fields on our booking pages are limited to general session preferences (for example, pressure preference or mobility notes).
• Where a provider offers a licensed-healthcare service (such as acupuncture or IV hydration), clinical records remain in that provider’s clinical system of record. Our request and booking pages for those services deliberately skip health and medical questions.

HIPAA or other health-privacy obligations depend on the actual organization, data, relationship and jurisdiction; this page does not decide whether WellOps or a provider is covered or exempt. Discuss regulated use cases with appropriate counsel before use.

2. What data we collect

The categories below are examples, not an exhaustive inventory. See our Privacy Policy for other data and role-specific handling.

• Providers and practitioners: business and contact details, brand preferences, uploaded documents, practitioner assessments, native tax/bank form answers encrypted in the database and complete-value private PDFs, and Stripe-handled card payment credentials.
• Corporate clients: company and contact details and event preferences submitted with a wellness request.
• Employees: name, work email, and chosen appointment time, plus optional non-medical session preferences, an optional phone number for opted-in SMS reminders, and — where the provider enables them — intake responses and signed waivers. No account is required.
• Other interactions: support, prospect/outreach, survey and feedback records, browser storage, and minimized analytics metadata where enabled.

We do not sell, rent, or trade personal data for marketing purposes.

3. Encryption in transit and at rest

• In transit: the application serves browser traffic over HTTPS. Data passed to third-party services follows the applicable integration.
• At rest: Supabase provides encryption at rest for database and stored files. Stripe handles full card credentials; native practitioner bank and tax answers are separately encrypted in database storage and included in private generated PDFs.

4. Tenant isolation & access control

Provider tenancy uses multiple access boundaries. No isolation mechanism is a guarantee that unauthorized access is impossible:

• Row-Level Security (RLS): database policies scope supported table access to the authorized tenant; server-side authorization is also necessary for privileged operations.
• Role-based access control (RBAC): provider teammates have roles (Owner, Admin, User, Viewer). Sensitive dashboard areas have role restrictions; actual access depends on feature and record type.
• Token-scoped public flows: supported review, quote, booking and invoice flows use scoped access links with applicable expiry or revocation checks. Link recipients should protect these links.
• Privileged operations: sensitive actions require server-side authorization, with appropriate role checks.

5. Sub-processors

Service providers and conditional external destinations differ by workflow. Their access depends on the feature used; this list is not a certification of vendor contracts:

• Supabase — database, authentication, and file storage.
• Stripe — subscription and provider-connected payments, including corporate payer cards and eligible bank payments; WellOps does not store full card numbers.
• Resend — transactional email delivery (quotes, confirmations, notifications).
• Twilio — SMS (text message) delivery for opted-in reminders and notifications. Processes phone numbers and message content solely for delivery; SMS consent data is never sold or shared with third parties for their marketing purposes.
• PostHog and Google Analytics 4 — minimized analytics on approved routes when configured; network metadata can accompany requests.
• Replit — application hosting and runtime infrastructure that processes application requests and responses.
• OpenAI via Replit AI Integrations — help-chat submissions/history and founder-selected prospect details, public-source web-search results and outreach drafts. A user-authorized external AI connection such as Claude is a separate destination.
• Gelato — optional print fulfillment; receives publicly addressable artwork URL, delivery name/address and provider account email.
• AWS S3 — private owner-controlled destination used for a documented manual independent file snapshot, not a verified daily schedule.
• Coverdash — optional insurance partner. WellOps does not transmit personal data to Coverdash; a provider only reaches Coverdash by clicking through to Coverdash’s own site.

6. Data retention

Configured retention windows define eligibility for a limited, conditional sweep, not a promise of live execution or deletion of every record:

• Corporate contacts: selected personal fields of eligible inactive contacts (default 730 days; minimum 365).
• Bookings, intake responses, terminal waitlist: selected fields of eligible records (default 730 days; minimum 365), measured from booking creation where applicable.
• Operational free text: selected request messages, terminal event and eligible quote notes (default 365 days; minimum 180); signed, active or charged records are not covered by this sweep.
• First-party analytics: eligible event metadata, not necessarily event rows (default 365 days; minimum 90).
• Other records: accounts, uploads, practitioner records, messages, survey/support records, vendor copies and backups require separate case review or lifecycle processes.

When enabled, applicable legal holds stop the affected category sweep. Whether production purging is enabled or scheduled has not been established here. See the Privacy Policy (§5).

7. Backups & disaster recovery

• Documented database backup, restore, and incident-recovery procedures.
• Private uploaded files can use a trash workflow; print-ready artwork uploaded for fulfillment has a publicly addressable URL.
• A documented manual owner-controlled private S3 file snapshot is distinct from a live daily file-backup schedule, which is not verified.
• Recovery settings and restore evidence are verified operationally before a recovery window is represented as active.

WellOps does not claim a specific backup-retention or recovery window unless the current infrastructure configuration and a restore test support that claim.

Availability monitoring of public health/homepage endpoints has been documented with Better Stack; it is not evidence that customer records are sent to that monitor or that those monitors are currently active.

8. Breach notification

We assess security incidents and any notification duties under applicable law and agreements. Where notice is required, we provide information available at that stage of the investigation.

9. Your data rights (access, export & deletion)

Provider Owners and Admins can request a Settings export of supported account records, not every row, file or vendor copy. You may email us about access, correction or deletion; we verify and review each request, including provider-controlled records and applicable exceptions. We do not promise a universal 30-day deadline. Details are in our Privacy Policy.

10. Reporting a vulnerability & security contact

We welcome reports from security researchers and customers. If you believe you’ve found a vulnerability or have a security question, email hello@wellopsapp.com. Please give us reasonable time to investigate and remediate before any public disclosure. Our machine-readable security contact is published at /.well-known/security.txt.

11. What we do not claim

In the interest of honesty for due-diligence reviews: WellOps has not completed a SOC 2, ISO 27001, or comparable third-party audit, and does not claim one. We do not perform routine external penetration testing at this time. This page describes the real, currently-implemented controls above — nothing more. We will update it as our program matures.