Current status
This page is a public security overview, not a certification statement. Formal provider, uptime, incident, backup, and support commitments are confirmed through onboarding or signed service documents.
Public and private data boundaries
Public club profiles are designed for approved information that a club is comfortable showing to anyone. Member records, child profiles, invoices, payments, role access, staff permissions, private messages, reports, exports, and performance records stay behind signed-in app boundaries.
The public club profile endpoint returns public profile sections such as club identity, activities, programmes, venues, media, sponsors, and updates. Private dashboard and profile records are handled by separate signed-in journeys.
Roles and scoped permissions
- Club authorities can assign staff access based on role and responsibility.
- Some finance, public profile, programme/team, member, setup, and dashboard actions are permission-controlled.
- A coach, treasurer, volunteer, or administrator does not automatically need access to every private area.
- The club remains responsible for deciding who should receive staff access and reviewing that access as responsibilities change.
Accounts, passwords, and official club links
Private areas require users to sign in. Users should keep their account details accurate, protect their password, and avoid sharing account access.
Club-branded links can preserve club context so parents, players, officials, and staff understand which club journey they are opening.
Invoices, signed downloads, and payments
- Invoices, receipts, payment records, and payment history belong in private signed-in areas.
- Invoice and receipt downloads can use signed links or signed routes and should be shared only with people allowed to see the invoice.
- Stripe is the intended payment provider direction, but online payment routes can be enabled only after provider setup and club readiness are confirmed.
- Manual bank transfer instructions appear only when a club includes bank details on the invoice, and the club confirms manual payments.
Analytics and sensitive query protection
The public portfolio includes consent-aware GA4 wiring and optional public attribution storage. These stay disabled unless the deployment is configured and the visitor accepts optional analytics.
Google Analytics should not load unless the deployment has a measurement ID, analytics is explicitly enabled, and the visitor accepts optional analytics.
Token-bearing auth URLs and sensitive query parameters are scrubbed before public page view events or lead attribution payloads are sent.
Admin and support access
MySportsHive internal and admin access should be limited to people who need it for support, security, service delivery, finance, legal, or platform maintenance.
Production admin roles, lead records, payment-provider resources, logs, and support tooling need ongoing least-privilege review before stronger public commitments are made.
Report a suspected security issue
To report a suspected security issue, contact support@mysportshive.com with "Security report" in the subject or use the contact form. Include the page, link, account context, club name if relevant, and a short description of the concern.
Do not send passwords, full payment card details, or unnecessary sensitive child or medical information in the report.
Availability, backups, and incident communication
Early public support is handled by email/form during UK business days. Exact support hours, response targets, incident communication, and priority launch support should be confirmed in the relevant order form or approved public support policy.
Until those operational details are approved, MySportsHive should avoid uptime percentages, 24/7 support promises, certification claims, fixed response-time promises, or provider-specific guarantees in public copy.