Privacy Policy

This Privacy Policy explains how BenAsk ("BenAsk," "we," "us") collects, uses, shares, and protects personal information—including consumer health data—when you use our websites, apps, and related services (the "Service"). Use of the Service is also governed by our Terms of Service.

BenAsk serves individual consumers and their households as a direct-to-consumer product. We are not a HIPAA-covered health plan, clinic, insurer, or clearinghouse for this offering, and we are not acting as your HIPAA business associate for the Service described here. We do not hold HIPAA-covered status, SOC 2, ISO 27001, or HITRUST certifications. We do not sell your personal information for monetary consideration to data brokers as commonly understood. Audited BenAsk frontend bundles today omit Meta Pixel, LinkedIn Insight, TikTok Pixel, Taboola, or similar remarketing trackers whose primary purpose is profiling consumers across unrelated sites. We bundle display fonts via Next.js. Regulatory definitions nonetheless treat certain analytics transfers as "sharing"; Google Analytics loads only after you affirmatively choose Accept all in our cookie banner, then receives narrowly typed engagement events (some include pseudonymous Clerk IDs for funnels)—not raw chat text or uploads. Choosing Reject non-essential, honoring Global Privacy Control, or never accepting analytics cookies avoids Google Analytics altogether (§ 2). BenAsk is intended for residents of the United States. We do not target the Service to residents of other countries and we do not warrant compliance with the data protection laws of jurisdictions outside the U.S. See § 11 (International users) for important information if you are accessing from outside the U.S.

U.S. law we design this notice around includes the Federal Trade Commission Act ("FTC Act," including Section 5), the Federal Trade Commission Health Breach Notification Rule ("HBNR") (16 CFR Part 318), Washington's My Health My Data Act ("MHMDA"), California's Consumer Privacy Rights Act ("CCPA"/"CPRA") and Confidentiality of Medical Information Act ("CMIA"), analogous laws in jurisdictions such as Virginia, Colorado, Connecticut, Texas, Oregon, Montana, Florida, and other states as they evolve, and breach notification statutes. Residents of states with comprehensive privacy laws not called out separately may still exercise similar rights starting at privacy@benask.com — cite your state when you write in.

1. Who we are and what BenAsk does

BenAsk is a U.S.-based software company. We built an informational benefits assistant so you can compare employer-sponsored coverage, organize plan documents and consumer health paperwork, estimate costs using the information you upload, and ask questions using AI that is anchored to plan materials you supplied. Nothing in this Service replaces your insurer, broker, clinician, accountant, lawyer, HR department, plan documents, or official government programs.

2. Information we collect

• Account information. Clerk, our authentication provider, collects and processes identifiers such as your name, preferred email address, password or passkey handshake, MFA tokens, signed-in sessions, audit metadata tied to login attempts, and support tickets you lodge with Clerk. We receive Clerk user identifiers so we can connect your saves to the right workspace.
• U.S. eligibility attestation. When you affirm that you are located in the United States as part of the sign-up flow, we store a dated row in our Postgres database with the attestation wording version, connection IP address, and browser user agent string alongside your Clerk user ID to support compliance and regulator inquiries.
• Family and organization membership. Households ("families") are modeled using Clerk org features. We process organization IDs, invitations, roles such as admins versus members, and related metadata so you can collaborate with people you expressly invite into the workspace.
• Onboarding answers. If you choose to complete our Smart Wizard, we collect the questionnaire data you submit (for example, ZIP/work location, commuting pattern, dependents, utilization scenarios, prescriptions you name, HSAs/HRAs/spousal coverage prompts). For persistence our code saves those answers internally as structured JSON using an HL7 FHIR R5–inspired QuestionnaireResponse-shaped object (resource type + items). This is developer-facing structure only; we do not push QuestionnaireResponse bundles to clinicians, insurers, or health-information exchanges via standard FHIR exchange interfaces.
• Uploaded documents. Uploads use a generic file picker where you label each item as Bill, EOB, Benefits Document, or Other. You might attach anything health- or benefits-related you choose (for example invoices, EOB PDFs, plan PDFs). We retain binaries in Vercel Blob unless you delete them sooner (stored with private, token-based access—not public CDN URLs).
• Document-derived text. Our ingestion pipeline parses PDF and image-heavy files whenever you opt into document analysis, producing extracted text snippets, OCR-style output where the pipeline uses vision/text models, AI summaries, and metadata referencing the originating file slug. When that analysis path chunks text for retrieval, our server may call OpenAI's embeddings API (text-embedding-3-small) and store embeddings alongside chunks in Postgres; uploads you never analyze or chunks we never embed are not routed through that API.
• Chat conversations. If you consent to AI chat assistant, we persist each thread slug, chronological messages, timestamps, identifiers linking to your Clerk user and org, optional attachments routed through the chat API, server-side summaries of recent claims surfaced for context-aware answers, and—when your question includes allow-listed carrier or PBM URLs you attach and routing rules approve—temporary fetch/summarize output from those HTTPS pages blended into prompts (no standing feed of partner portals beyond what your session requests).
• Operational usage logs. Our hosting/platform (for example Vercel) emits standard HTTP and infrastructure logs (timestamps, request paths, status codes, and similar fields per platform defaults—which can include originating IP addresses in raw platform logs outside BenAsk code). When Better Stack (Logtail) credentials are configured in an environment variable, structured server-side log lines are forwarded over HTTPS without intentionally bundling readable chat/message bodies or full document payloads; optional browser-diagnostic uploads require a separate browser token—both are gated by deployed configuration keys. Separately, our security middleware records a shortened SHA‑256-derived digest (not raw IP addresses) correlated with bursts of unauthorized access attempts for internal abuse detection. Crash paths may forward sanitized stack traces to Sentry when its SDK is bundled and SENTRY_DSN resolves at runtime—otherwise crashes stay in hosting logs only. Retention horizons live in § 5.
• Analytics cookies & performance telemetry. Our cookie banner uses the same consent UI for all visitors (we do not geo-fence the banner—see § 6.5). Google Analytics 4 does not load until you click Accept all; until then, only essential/session cookies (for example Clerk sign-in) run. The banner presents Reject non-essential and Accept all side by side with equal visual weight; rejecting keeps Essentials only (no analytics). Your choice persists in localStorage plus a first-party cookie; you may reopen the choice anytime via Cookie preferences in the site footer. In production, after Accept all, Google Analytics receives only narrowly typed events from our frontend helper—onboarding progress counters, categorical upload summaries, chat-send summaries such as counts/labels—and does not ingest raw chat transcripts; some funnel events include pseudonymous Clerk identifiers. Our Google Analytics 4 configuration disables Google signals, disables ad personalization, and anonymizes IP addresses. Google does not use this deployment's measurement configuration to build cross-site advertising profiles from those flags. Selecting Reject non-essential, enabling GPC before first interaction, or never accepting analytics avoids Google Analytics altogether. Separately we load Vercel Speed Insights; it operates under Vercel's policies.
• Global Privacy Control (GPC). We honor the Sec-GPC: 1 signal and browsers exposing navigator.globalPrivacyControl as an opt-out preference for analytics "sharing" under CPRA-aligned regulations to the extent we load optional analytics (Google Analytics only after explicit Accept all). When we detect GPC and you have not already chosen broader cookies, middleware sets Reject non-essential / Essentials only; if you affirmatively clicked Accept all earlier, use Cookie preferences in the footer, the Privacy Policy-linked cookie UX, or browser controls to downgrade.
• Cookies and similar technologies. Clerk installs cookies or localstorage entries required for session continuity ("_cl" prefixed keys), SSO state, MFA challenges, telemetry about failed logins, localization flags, CAPTCHA attestations where enabled, fraud heuristics, and secure CSRF defenses. Clerk's docs list each cookie variant; disabling them may interrupt sign-in.

3. Consumer health data

For Washington MHMDA and parallel state expectations, BenAsk acknowledges that many items above qualify as consumer health data: personal information reasonably linkable to a consumer describing past, present, or future physical or mental health status, healthcare received, pharmacy or drug identifiers, billing or coverage details, wellness or preventive care references tied to benefits, vaccination entries you provide, and any other consumer health information you choose to upload through our generic document upload (where you label files as Bill, EOB, Benefits Document, or Other). We do not run separate algorithms to infer biometrics or health conditions from uploads beyond what you explicitly type, upload, or consent to through document analysis and chat.

• Categories collected. Medical and pharmacy charges and claims information visible on bills or Explanations of Benefit (EOBs); plan documents and Summaries of Benefits and Coverage; clinician or facility names that appear on those documents; insurance member or subscriber identifiers visible on documents you upload; prescription drug names you enter or that appear on uploads; and household composition details (such as dependents) that you describe in onboarding or in chat.
• Sources. Voluntary submissions from your devices, manual uploads you export from insurer portals, OCR extractions after you opt into document analysis, AI summarizations after you approve scopes in Settings, NLM drug synonyms when autocomplete runs, Clerk profile fields used for account recovery, claims rows you already stored for concierge context, short-lived HTTPS fetches of carrier/PBM pages you paste when chat routing approves the domain, email or support exchanges with our published aliases, and operational logs routed to Better Stack/Sentry/hosting vendors only when those integrations are configured in the deployment's environment.
• Purposes. Secure storage, ingestion, OCR, summarizing plan language, conversational answers locked to the plans or documents you selected, fraud/abuse mitigation, enforcing household-scoped ACLs inside Clerk org RBAC, notifying you when long-running ingestion jobs succeed, complying with subpoenas narrowly tailored after legal review, providing DSAR tooling, notifying regulators plus you if a breach occurs, benchmarking latency for Rx autocomplete, tailoring deductible math using household archetypes only after you affirm onboarding personalization scopes, syncing plan intelligence caches so chat threads stay truthful, and powering exports you request inside Settings → Your data.
• Recipients. Clerk; OpenAI (document + chat workloads); Vercel (+ Blob hosting in U.S. East / IAD1), NLM NIH drug autocomplete endpoints, managed Postgres/Vercel storage partners, and transactional email if you contact support@benask.com. Detailed rows live on /subprocessors.

Consent before collection. We collect consumer health data only when you voluntarily take action in the product—such as uploading a sensitive file, answering onboarding prompts that reference health situations, opting into AI scopes, or acknowledging the first-dashboard notice. We do not buy health information about you from data brokers, and we do not scrape your medical records.

Consent before sharing. Before we dispatch consumer health data to an AI model or another subprocessor that needs it for the Service, we rely on Settings → Privacy & AI scopes that cite this Privacy Policy (version 2026-05-10). Turning off scopes stops new sharing immediately while older vendor retention windows noted above may still apply. Lawful subpoenas are handled narrowly after legal review—we do not volunteer uploads for unrelated marketing.

Washington rights reminders. You may withdraw consent, request deletion subject to carve-outs spelled out below, escalate a denial via privacy@benask.com, expect non-discrimination for exercising MHMDA rights, and contact the Washington Attorney General if informal resolution is unsatisfactory. Contact for MHMDA-specific requests: privacy@benask.com with subject line [MHMDA REQUEST] so prioritization aligns with statute timers.

4. How we use AI

Dedicated disclosure so we remain truthful under FTC Act Section 5: BenAsk plugs large-language-model APIs into chat, document summarization, and onboarding helpers. Providers and payloads stay explicit—we never bury AI processing in vague “assistive" jargon.

Automated decision-making. BenAsk uses AI to help you understand benefits materials you provide. AI-generated cost illustrations, summaries, or plan comparisons are informational—not eligibility determinations about you from BenAsk. We do not use AI outputs to automatically deny service, change individualized pricing, or produce legal effects about you without a human or clearly disclosed business rule in the product; employers, carriers, and regulators remain the authorities on eligibility and enrollment.

• Providers. OpenAI powers chat completions, document summarization, OCR follow-ups, embeddings for chunked document retrieval when that pipeline runs, and selective carrier-site summaries surfaced after allow-listed HTTPS fetches—all subject to scopes in Privacy & AI. We do not route production traffic through any LLM vendor beyond OpenAI as of this disclosure; adding another processor requires updating this subsection before customer data flows there.
• Categories we send. Extracted PDF text or OCR output, pasted carrier HTML snippets we fetch server-side after allow-list checks, wizard summaries (ZIP, household shape, prescriptions you typed), drug autocomplete strings tied to NIH lookups, chat transcripts with optional base64 attachments, claim slugs surfaced for concierge context-locking tables, onboarding JSON packaged for personalization scopes, benign system prompts that enforce benefits-topic fencing.
• Training posture. OpenAI's standard API disclosures state customer prompts/completions tied to qualifying tiers are typically not used to train consumer-facing ChatGPT-scale models. Read the vendor's live commitments when conducting diligence—we cannot supervise their roadmap.
• Vendor retention. OpenAI typically retains API inputs/outputs for about 30 days for abuse monitoring absent a superseding enterprise retention deal you negotiate directly with them. BenAsk deletes or overwrites tenant-controlled copies sooner when you remove content, but transient vendor buffers may remain for that window.
• No BAAs today. BenAsk does not sign HIPAA Business Associate Agreements with OpenAI for this direct-to-consumer product, and BenAsk itself is not SOC 2/ISO/HITRUST certified. Treat uploads accordingly unless a bespoke enterprise agreement states otherwise in writing.
• Controls. Manage AI scopes at /dashboard/settings/privacy. Revocation halts new transmissions even though vendors may retain prior calls per their policy.

5. How long we keep data

Subprocessors publish their own retention promises—please see Clerk Privacy, OpenAI API data usage policies, Vercel Privacy, and NIH RxTerms API documentation.

6. Your rights

6.1 All users

Wherever you live, you may ask for access, correction, deletion, or a portable JSON export beginning inside Settings → Your data—that flow re-authenticates you so we avoid email impersonation scams. Statutory rights vary by jurisdiction. U.S. state-specific subsections appear below. Visitors from outside the United States should review § 6.5 first — BenAsk is not designed for non-U.S. data protection regimes.

6.2 California (CCPA/CPRA)

• Know, delete, correct, and opt out rights where statutes apply—including sale of personal information or certain "sharing" disclosures. Today we configure BenAsk without paid data sales or cross-context behavioral advertising through ad networks; however, opting into analytics cookies enables Google Analytics, which under some interpretations can constitute that same statutory category vis-à-vis Google—see Cookie preferences / § 2. Use Reject non-essential cookie settings to keep Google Analytics from loading while still using authenticated features subject to Clerk's own cookies.
• Limit use of sensitive personal information (SPI). California regulators let businesses that use SPI strictly for permitted statutory purposes—such as providing services you request, security, short-term transient use, service quality assurance, and verifying or maintaining your account—avoid offering a separate limitation toggle if the disclosures are clear. BenAsk uses SPI solely to operate, secure, troubleshoot, and personalize the Service within the scopes you authorize (for example AI toggles); we do not use SPI for cross-context behavioral advertising. Because we limit SPI in this way, we do not surface a dedicated "Limit sensitive information" switch distinct from revoking AI scopes, deleting content, or exporting then closing your account at Settings → Your data / Privacy & AI. If guidance changes requiring a mirrored control in-product, we will ship it promptly.
• Non-discrimination when you exercise CPRA rights.
• Shine the Light: we do not disclose personal information to third parties for their direct marketing as traditionally defined; if that changes we will offer the statutory opt-out track.

6.3 California (CMIA)

CMIA requires authorization before many disclosures of medical information except where you direct us to share data with subprocessors necessary to run the Service (for example, AI analysis you explicitly enabled). You may revoke authorization by toggling AI scopes off, deleting documents, or closing your account; residual subprocessors purge on their timelines noted above even after revocation.

6.4 Washington (MHMDA)

Consumers may withdraw consent, request deletion absent statutory exceptions, appeal denials, expect nondiscriminatory treatment, and complain to the Washington Attorney General. Use privacy@benask.com with subject [MHMDA] for routing.

6.5 Non-U.S. visitors

BenAsk is intended for residents of the United States. The Service, its content, and these notices are designed around U.S. law. We do not target the Service to residents of other countries, do not localize for non-U.S. markets, do not advertise outside the U.S., and do not warrant that the Service complies with the data protection laws of any country other than the United States.

If you access the Service from outside the United States:

• You acknowledge your personal data is transferred to and processed in the United States.
• We do not undertake to comply with the GDPR, UK GDPR, the Swiss Federal Act on Data Protection, Brazil's LGPD, Canada's PIPEDA, or other non-U.S. data protection regimes.
• We do not currently appoint representatives in any jurisdiction outside the United States.
• You should discontinue use if your local law restricts processing of your personal data by U.S.-based services without specific safeguards we do not provide.

If you have questions about your data and you are outside the U.S., contact privacy@benask.com—we will respond in good faith but we do not guarantee compliance with the timelines or processes required by laws of your jurisdiction.

6.6 Appeals (Virginia, Colorado, Connecticut, and similar statutes)

Certain states guarantee the right to appeal if we deny a privacy request within the window prescribed by law. Reply to our written denial—including the rationale we supplied—or email privacy@benask.com with subject line [PRIVACY APPEAL], cite your jurisdiction, summarize the disputed request ID, and attach correspondence for continuity. Appeals receive an additional review promptly; outcomes reference applicable Attorney General escalation paths whenever statutes require them.

6.7 Authorized agents

California and other statutes allow verified agents after we receive signed authorizations plus proof they act on your behalf. Impostors are rejected—even if timelines slip we respond with what we need rather than risking unlawful disclosure.

7. How to exercise rights

• In-product tools at /dashboard/settings/data and /dashboard/settings/privacy.
• Email privacy@benask.com for DSAR ticketing when you lack dashboard access. We ordinarily verify continuity by matching your inbox to Clerk records and asking you to complete a refreshed sign-in or MFA prompt—consistent with CPRA/CCPA minimizing unnecessary identification. We request photocopies of physical government IDs only in narrowly scoped escalation situations (such as simultaneous conflicting deletion instructions from administrators of the same workspace) following written notice.
• California CCPA/CPRA: we acknowledge requests within statutory windows and deliver responses within 45 calendar days (extendable once with notice when complex).
• Washington MHMDA: we align to the same 45-day benchmark for consumer health data requests unless law demands faster relief.
• Verification: For self-service exports we require a live Clerk session tied to your account. For email-based tickets we confirm control of your registered inbox and escalate only necessary factors—for example, when multiple adults share a workspace and issue conflicting deletion instructions.

8. Security

• Encryption in transit: TLS 1.2+ across benask.com, Clerk auth flows, OpenAI API calls, Vercel Blob signed fetches, Postgres connections, observable logging endpoints reached over HTTPS, RxTerms lookups, and browser→API JSON exchanges.
• Encryption at rest: Vercel Blob and managed Postgres disks rely on underlying cloud encryption as described by those vendors’ documentation; Clerk secures credential material per its published guidance (using Clerk does not confer independent SOC 2/ISO attestations onto BenAsk).
• Access controls: Clerk session cookies, org-scoped roles, server routes that verify family membership before returning data, signed URLs minted server-side only, environment secrets via Vercel, database roles with minimal grants, least-privilege practices in deployment.
• Private file storage: Blob objects default to private access; retrieval uses server-side Vercel Blob APIs so browsers do not receive permanent public CDN links.

No control eliminates risk. BenAsk does not presently maintain SOC 2 Type II, HIPAA, ISO 27001, or HITRUST attestations—we implement industry-hardened baselines knowing those frameworks remain aspirational until formally audited. If certifications change later, we will revise this disclosure rather than implying silent upgrades.

9. Breach notification

If unsecured personally identifiable consumer health information is improperly accessed—for example ransomware compromise, credential theft impacting infrastructure, rogue insider misuse, accidental exposure of backups, or phishing against BenAsk admins—we follow Federal Trade Commission Health Breach Notification Rule (16 CFR Part 318, effective July 29, 2024) plus supplemental state timelines (including Washington MHMDA and California breach statutes) when thresholds trigger.

• Affected consumers: we notify without unreasonable delay and no later than sixty (60) calendar days after discovery, unless law demands faster notice. Notices summarize what occurred, categories of compromised data (for example OCR text, onboarding JSON, hashed emails), recommended mitigations (password rotations, MFA upgrades, watchdog credit freezes when financial data intertwined), remediation steps underway, escalation contacts, FTC reporting links where applicable, and timelines for gratis credit monitoring only if warranted and budgeted.
• Government & press: we file legally required FTC reports contemporaneously, escalate to Attorneys General buckets when thresholds demand, notify major media outlets if more than 500 residents of a jurisdiction are impacted, and summarize filings inside in-app banners with hyperlinks referencing regulator docket IDs when publicly accessible.
• Notice channels: email addresses on file plus persistent banner tiles after sign-in referencing incident IDs and knowledge-base entries.

10. Children

BenAsk markets only to adults. We do not direct the Service at children under 13, and we do not knowingly solicit personal information—including consumer health information—directly from those children. Household administrators may voluntarily record dependent names, dates of birth, or other coverage facts on behalf of their children while organizing family benefits—that processing is incidental to parental use, not COPPA-triggering "collections" from the child absent other facts. Adults should complete sensitive entries on dependents instead of minors creating independent accounts themselves. If you believe a minor under 13 created an account independently, notify privacy@benask.com so we may delete promptly.

11. International users

BenAsk's servers and storage default to the United States (Vercel region IAD1). The Service is intended for U.S. residents. If you access the Service from outside the United States, your personal data is transferred to and processed in the U.S. We do not undertake to provide additional safeguards required by your local law. See § 6.5 for additional information.

12. Changes to this Privacy Policy

We post updates here with a refreshed "Last updated" line. Material changes receive at least 30 days' advance notice via email and in-dashboard banners referencing the forthcoming effective date. Meaningful edits to How we use AI trigger a new consent_version value so you must re-opt into AI scopes after reviewing revised disclosures—even if statutes did not expressly demand reruns across every state patchwork.

13. Contact

Privacy: privacy@benask.com

BenAsk is a small, fully remote company at this stage. We do not currently maintain a public mailing address for routine privacy correspondence. For requests requiring legal service of process, contact us at privacy@benask.com and we will provide an appropriate service address.

14. Privacy change log (summary)

The authoritative text is always this page plus its "Last updated" stamp in the surrounding legal frame. Highlights:

• May 2026 (US-focused revision). Reverted to U.S.-only territorial posture with explicit non-U.S. visitor warning; removed full GDPR/UK GDPR coverage in favor of brief disclosure that the Service is not designed for non-U.S. data protection regimes; removed 72-hour GDPR breach timing (none currently stated in § 9); coordinated with Terms of Service U.S.-only eligibility and product-level signup affirmation.
• May 2026. Consumer health data categories aligned to Bill/EOB/Benefits/Other uploads; GA4 client flags for signals/ad personalization/IP anonymization; cookie banner "Reject non-essential" + footer Cookie preferences; GPC handling retained.