Privacy Policy
Last updated: 2026-07-19.
This Privacy Policy explains how LeakGuard collects, uses, protects, and lets you control your information across our website, dashboard, account flows, monitoring service, alerts, weekly digests, billing workflows, and support communications.
Scope
This policy covers the website, dashboard, account flows, monitoring service, alerts, weekly digests, billing workflows, and support communications.
LeakGuard is designed not to store raw breach dumps, leaked passwords, Social Security numbers, government IDs, payment card data, or full source payloads.
Data Handling Summary
Monitored email addresses and alert phone numbers must remain usable for scans and alerts, so production storage uses encryption-at-rest patterns and decrypts only in trusted server-side paths needed to provide the service.
Payments are handled by Stripe. LeakGuard should store only limited billing metadata and relies on provider-specific retention for Stripe billing records where applicable.
Public Email Scan
When the optional public email scan is enabled, LeakGuard sends a pseudonymous, shortened token derived from a normalized submitted email to LeakCheck to obtain only a count of potential matching exposure records. LeakGuard does not send the raw submitted email to LeakCheck, and the page does not persist the email, CAPTCHA token, or result in browser storage or analytics.
The scanner uses Cloudflare Turnstile or hCaptcha to help prevent abuse; those providers may process IP address, cookies, and verification telemetry under their own notices. LeakGuard retains only a transient normalized input for the request plus HMAC-based, minimized rate-limit evidence for up to 25 hours before pruning. A count can be affected by token collisions and does not prove identity, ownership, safety, complete coverage, or a particular account. Marketing opt-in is separate and never inferred from using the public scanner.
SMS Security Alerts
SMS security alerts are strictly opt-in. A signed-in customer turns on SMS alerts and enters a phone number in their authenticated account Settings, and can turn them off at any time in Settings or by replying STOP.
Mobile phone numbers collected for SMS security alerts are used solely to deliver those alerts through our messaging provider (Twilio). We do not sell, rent, or share mobile opt-in information, consent, or phone numbers with any third parties, and mobile opt-in data is never shared for marketing or promotional purposes.
Message frequency varies because alerts are event-driven. Message and data rates may apply. Reply STOP to unsubscribe or HELP for help.
Data Access & Portability
Settings includes a self-serve JSON export for GDPR/CCPA portability covering account profile fields, monitored assets, monitored email addresses, scan and alert metadata, posture/remediation records, DMARC aggregate (RUA) report metadata (reporting organization, report id, date range, and pass/quarantine/reject/none counts), webhook/API-key metadata, achievements, and legal document acceptance versions where available.
Security sign-in/telemetry logs, encrypted legal-acceptance IP address and user-agent evidence, domain-claim audit records, DMARC RUA per-source detail (raw sending IP addresses) and inbound routing-token metadata, and Stripe-held billing records such as invoices, receipts, card/payment-method data, tax, charge, dispute, and accounting records are not included in the self-serve file. You can request them — including formal GDPR/CCPA data requests — by contacting us.
Cookies & Analytics
LeakGuard uses strictly necessary cookies for Supabase authentication and to remember a visitor's analytics consent choice. These keep the site and account flows working and do not require optional analytics consent.
If Google Analytics 4 is enabled, optional analytics cookies are set only after a visitor accepts the cookie banner. Rejecting the banner or clearing cookies withdraws consent; analytics stays off unless the visitor later accepts.
Public page views and Google Analytics configuration use only the site origin and an allowlisted public path. Only on the exact root page, and only after consent, LeakGuard may add exactly one strictly validated Google-minted gclid, gbraid, or wbraid click identifier to that root location. Duplicate or ambiguous identifiers are rejected. We never send arbitrary query parameters or fragments, UTM parameters in the page location, email/customer/account or monitored data, tokens, or other URL parameters. Without a click identifier, individually nonduplicated and strictly sanitized UTM source, medium, and campaign values may be sent as manual campaign fields. This is best-effort and does not prove ad attribution. Google signals and ad-personalization signals stay disabled.
When analytics is enabled and a visitor has consented, LeakGuard also sends a small, fixed set of non-identifying product-funnel events (for example signup completed, checkout started, first scan seen, and dashboard view) that carry only fixed enumerated parameters (such as a surface label, plan tier, or scan status) and a sanitized path-only location that may include the top-level /dashboard and /dashboard/onboarding funnel paths. These events never include email addresses, monitored domains, account or user IDs, dashboard sub-route identifiers, scan results, query strings, tokens, session identifiers, or Stripe identifiers. The root click-identifier exception applies only to public page views and configuration; custom funnel-event locations always remain path-only with no query or fragment.
After analytics consent and a successful waitlist conversion dispatch, LeakGuard may store a fixed, non-identifying, tab-scoped session marker to avoid counting repeat waitlist conversions in the same tab. The marker contains no email address or submitted form value, is not sent to LeakGuard's server, and is removed when the tab closes. LeakGuard also removes it on a best-effort basis when the waitlist path observes that analytics consent is no longer granted.
Google LLC may process optional analytics data in the United States and other countries where Google operates. The legal basis for optional analytics is consent.
Acceptance
Direct signup and the public payment-first checkout require explicit Terms/Privacy acceptance and record encrypted, minimized legal-acceptance evidence.