Data Protection Impact Assessment
A DPIA summary for NutriScope's special category data, relationship-based access, messaging, files, payments and optional AI-assisted review workflows.
Audience: Internal reviewers, customers assessing NutriScope, and launch approvers
NutriScope can process health-related client information at meaningful scale. A DPIA is therefore expected before production launch and before any material expansion of AI, payments, clinic permissions, wearable imports or automated review prompts.
This page summarises the current DPIA posture from the PRD, data architecture and compliance guidance.
Scope
- Practitioner and clinic accounts.
- Client portal accounts and invite flows.
- Trackers, check-ins, observations and attention signals.
- Questionnaires, bookings, sessions, notes, goals and messages.
- Files and meal photos.
- Stripe-hosted payment metadata for paid bookings and packages.
- Optional video-meeting link creation.
- Optional practitioner-reviewed AI-assisted drafts and review context.
Necessity And Proportionality
The product purpose is to make between-session client progress visible to the responsible practitioner. Structured observations support trend review, adherence signals, export, deletion and minimisation better than opaque completed form blobs.
- Collect only tracker fields assigned or completed for a client relationship.
- Avoid making sensitive metrics such as weight, calories or body composition mandatory or visually over-promoted.
- Use measured_at for analysis so observations represent the client-relevant time.
- Keep public booking and video-provider sharing minimal.
- Keep AI-assisted processing optional unless a later review approves a different basis.
Key Risks And Controls
| Risk | Impact | Current or required controls |
|---|---|---|
| Unauthorised practitioner access | Special category client records could be viewed or edited by the wrong person | Restore strict practitioner scope before production, preserve relationship-scoped RLS, audit sensitive actions and remove testing open access |
| Client access to wrong portal data | Client could see another person's check-ins, plan or messages | Use client-specific policies, invite linking, authenticated portal routes and recipient checks for messaging |
| Opaque check-in data | Harder to export, minimise, delete and explain processing | Preserve structured tracker observations and avoid JSON-only completed check-ins |
| Over-collection of sensitive metrics | Unnecessary body or calorie data may create avoidable privacy and wellbeing risk | Keep sensitive metrics optional, clearly marked and not default for all clients |
| AI-assisted processing without adequate notice | Users may not understand when health context is sent to an AI provider | Keep AI optional, capture consent where used, label drafts and minimise source context |
| Health data in logs, URLs or analytics | Third-party exposure or excessive internal access | Avoid health data in URLs, console output, telemetry and non-essential analytics |
| Payment state manipulation | Bookings or package credits could be incorrectly confirmed | Use Stripe-hosted checkout and verified webhook events as the source of truth |
| Video provider over-sharing | External providers could receive client health context unnecessarily | Send only generic session title and time; do not send notes, symptoms, trackers or client health context |
| Unclear legal basis | Consent and controller obligations may be misunderstood | Finalise Article 6 and Article 9 basis wording before launch and update consent records when wording changes |
| Retention uncertainty | Records may be kept too long or deleted too soon | Approve retention and deletion schedule by record type before production |
Required Actions Before Launch
- Set TESTING_OPEN_ACCESS to false and apply the practitioner-scope restoration migration.
- Confirm production Supabase region and vendor transfer safeguards.
- Finalise privacy notice, terms, DPA, subprocessor list, cookie and email policy, retention schedule and breach process.
- Confirm exact Article 6 lawful bases and Article 9 conditions.
- Confirm whether AI processing is disabled by default until explicit opt-in.
- Document DSAR, correction, export, restriction and deletion processes.
- Complete breach response workflow, including the 72-hour ICO assessment process.
- Have a solicitor, DPO or specialist reviewer sign off the production launch posture.
Consultation And Review
If a launch reviewer concludes that processing is likely to result in a high risk that cannot be reduced by the planned controls, NutriScope should seek appropriate advice before launch, including whether prior consultation with the ICO is required.
The DPIA should be reviewed before material changes to AI-assisted review, clinic permissions, imports, analytics, payments, file processing, messaging, public pages or wearable integrations.