GDPR Compliance Summary

1. Applicable framework

NexusFit is a subscription fitness/wellness platform with health-related processing, AI analysis and a community for members aged 16+. Its UK framework includes the UK GDPR and Data Protection Act 2018 as amended by the Data (Use and Access) Act 2025, and PECR for electronic marketing and storage/access technologies. England and Wales contract jurisdiction does not limit a regulator’s powers or remove mandatory rights of users elsewhere.

If NexusFit offers services to people in the EEA or monitors their behaviour there, assess EU GDPR territorial scope, representative requirements and separate cross-border obligations. Language/currency localisation and international marketing make this a practical review point; UK wording alone is not a global compliance solution.

2. Observed controls and their limits

Source review found account-scoped data access, restrictive active-account controls, private media paths, limited health-photo links, audited staff functions, separate health access and protected founder permissions. The founder inherits all staff access, including health. AI planning uses bounded food references and several safety/validation checks. Community reporting/blocking and optional badge sharing exist. Stripe signature verification/deduplication and a billing portal are present.

These are relevant safeguards, not evidence of a completed security audit, legal compliance, encryption certification, approved DPIA, tested deletion programme or lawful basis for all processing. Access control does not itself supply explicit consent. A 50-row admin directory is not a 5,000-member compliance or security load test.

3. Required governance before adoption

Confirm controller identity, public privacy contact and ICO fee/registration position. Record processing purposes, categories, recipients, transfers, security and retention in a record of processing activities; the small-organisation exception cannot simply be assumed for regular special-category processing.

Approve an Article 6 basis for each purpose and an Article 9 condition for health/religious information and relevant inferences. Build granular explicit health consent, AI disclosure, optional sharing and withdrawal, with dated/versioned evidence. Do not rely on the automatic marketing flag or Terms acceptance. Review whether any reliance on a DPA Schedule 1 condition requires an appropriate policy document; such a document is not a substitute for choosing a valid condition.

Complete a DPIA for combined health data, AI profiling, private photos, offline storage, founder/staff access and 16–17-year-old users, and reassess at scale or on material changes. Assess whether a DPO is required because core activities involve large-scale special-category processing or regular/systematic monitoring; 5,000 accounts is not by itself a definitive legal threshold.

Obtain processor agreements, verified subprocessors, hosting/data locations, AI training/retention terms, transfer mechanism and assessment. Minimise fields sent to AI and ordinary logs. Document access reviews, staff confidentiality/training and why any broad founder access is necessary; full entitlement must not mean unrestricted operational browsing.

4. Individual rights and incident readiness

Provide usable access/portable-data, correction, erasure, restriction, objection and consent-withdrawal routes covering live records, photos, archives, internal recipe copies, device information and processors. Respond normally within one month, subject to lawful rules. Provide a clear privacy complaint channel, acknowledge within 30 days and communicate an investigated outcome.

Maintain a breach process: detect and contain, assess risk, keep a record and notify the ICO within 72 hours of awareness where required and feasible; notify affected people without undue delay where the high-risk threshold is met. A draft policy is not a tested incident response. Verify backups separately for database and storage files, and test restoration without resurrecting deleted data.

Assess automated processing under the amended UK GDPR significant-decision framework; do not quote the former Article 22 position as though it were unchanged. Provide meaningful explanation/challenge/human-review safeguards where required and apply the additional restrictions for special-category data. Adult-only calculation restrictions must be enforced consistently across paid gates and AI entry points.

5. Children, community and publication status

A 16+ service intentionally includes children under 18. Review the ICO Children’s Code, best interests, age assurance, high privacy defaults, understandable notices and risks of nudging weight loss, fasting, badges and photo sharing. Paid access must not imply access to age-inappropriate adult recommendations.

Separately assess whether the community is an in-scope user-to-user service under the Online Safety Act. If so, complete the illegal-content assessment and children’s access/risk assessments and implement proportionate reporting, complaints, protections and records. A “16+” statement or Community Guidelines alone do not discharge these duties.

This summary is an operational review framework. It is not “GDPR compliant”, ICO-approved or a certification. Publish only accurate, approved statements after the corresponding processes are in operation; keep the detailed risk report internal.