Effective July 1, 2026

Security at MyGymPanel

Your gym's data — members, payments, attendance, plans, conversations — is the lifeblood of your business. Here's exactly how we protect it, what's in your hands, and how to report something that doesn't look right.

Security is shared

We secure the platform, the infrastructure and the code. You secure your account — strong unique passwords, careful staff invites, and reviewing roles regularly. Both halves matter.

1. Security pillars

Encryption in transit & at rest

All traffic is served over HTTPS / TLS 1.2+. Data stored in our managed Postgres database and object storage is encrypted at rest using AES-256 by our cloud providers.

Authentication

Email/password and Google sign-in via a hardened auth provider. Passwords are hashed with bcrypt — we never see or store them in plain text. Leaked-password checks (HIBP) are enabled for new and changed passwords.

Row-level security (RLS)

Every table that holds gym data has Postgres RLS policies. Owners only see their gym's rows; members only see their own. The database itself enforces this — not just the app.

Role separation

Roles (owner, member) live in a dedicated user_roles table and are checked server-side via a security-definer function. Roles can't be escalated from the browser.

Server-side secrets

Service-role keys, payment secrets and webhook secrets live in the server runtime only. They are never bundled into the browser and never returned in API responses.

Trusted infrastructure

Hosted on Cloudflare's edge network with a managed Postgres backend. Both providers maintain SOC 2 / ISO 27001 attestations and run hardened, regularly patched environments.

2. How your data is isolated

MyGymPanel is multi-tenant. Each gym's data is logically isolated using row-level security policies tied to the owner's user ID. A query made from one gym physically cannot return another gym's rows, even if the application code had a bug.

Members are scoped to one gym via owner_id.
Attendance, plans, store products, invoices, messages — all scoped per owner.
Admin operations that need to bypass RLS run only inside trusted server functions and verify the caller's role first.

3. Payments

Subscription payments are processed by Razorpay (PCI-DSS Level 1 certified). We do not store full card numbers, CVVs or UPI credentials on our servers. We only retain the tokenized references and metadata needed to reconcile invoices.

4. Application security practices

Input validation on every server function and public API route with Zod schemas.
Webhook endpoints (e.g. payment callbacks) verify signatures with timing-safe comparison before doing anything.
Server functions that perform privileged actions require both authentication and an explicit role check.
Dependencies are scanned for known vulnerabilities; high-severity issues are patched promptly.
TypeScript strict mode and ESLint run on every change to catch a large class of bugs before deploy.

5. Monitoring & backups

Authentication events, server function errors and database errors are logged for investigation.
Our database provider takes automated daily backups with point-in-time recovery on supported tiers.
Backups are encrypted and retained per provider policy; we do not export raw backups to third parties.

Backups are not a substitute for your own exports

Backups exist to recover from infrastructure failure — not to undo accidental deletions days later. Owners should periodically export their data from Owner → Settings → Export Data. See our Data & Storage Policy.

6. Account security — your part

Use a long, unique password. A password manager is the easiest way.
Never share owner credentials. Invite staff with their own accounts instead.
Revoke access for staff who leave — promptly remove them from members/trainers.
Sign out on shared or public devices.
Be cautious of phishing — we will never ask for your password over email, chat or phone.

7. Data residency & sub-processors

Data is primarily processed in regions operated by our infrastructure providers. The current sub-processors are documented in our Privacy Policy (Supabase, Cloudflare, Google, Razorpay). We update that list when it changes.

8. Vulnerability disclosure

We welcome responsible disclosure from security researchers. If you believe you've found a vulnerability, please email support@mygympanel.com with the subject line [SECURITY].

What to include

A clear description, steps to reproduce, the impacted endpoint or page, and (if possible) a proof-of-concept. Screenshots help.

What we ask

Please don't access data that isn't yours, don't run automated scanners against production, and give us a reasonable window to fix before public disclosure.

What we'll do

Acknowledge within 3 business days, investigate, keep you posted on progress and credit you (if you'd like) once a fix is shipped.

Out of scope

Reports from automated tools without a working exploit, missing best-practice headers without impact, social engineering of staff, and denial-of-service attacks.

9. Incident response

If we detect or are notified of a security incident that affects your data, we will investigate, contain and remediate as our first priority. Where the law requires (GDPR, India DPDP, applicable US state laws), we will notify affected owners without undue delay and within statutory timelines, along with the facts we have, the impact, and the steps you should take.

10. Contact

support@mygympanel.com

For privacy-specific requests (access, deletion, portability), see the contact section of our Privacy Policy.