UNDA

Appearance

UNDA — Legal, Privacy & Compliance Engineering Rules ​

Document type: Internal development policy
Applies to: UNDA mobile apps, web app, backend, APIs, analytics, integrations, recommendation engine, support tooling, and infrastructure
Primary launch market: European Union / Spain
Last verified: 8 August 2026
Status: Development baseline — must be reviewed by qualified EU/Spanish counsel before production launch

Purpose: This document translates UNDA's main legal/privacy risks into concrete product and engineering rules. It is not a substitute for formal legal advice.

1. Product Regulatory Position ​

UNDA is intended to be a fitness and training support product, not a medical device.

1.1 Approved intended-purpose direction ​

UNDA may:

  • track menstrual-cycle information;
  • track workouts, recovery, sleep and user-reported energy;
  • identify patterns in a user's own historical data;
  • estimate cycle states or windows;
  • generate training-readiness signals;
  • suggest changes to workout intensity, duration or recovery;
  • explain which training/recovery/cycle inputs influenced a recommendation.

Examples of acceptable product language:

  • "Training that moves with your cycle's rhythm."
  • "Training adapted to your cycle, recovery and individual response."
  • "Understand patterns between your cycle and training."
  • "A training recommendation informed by your recent recovery and cycle pattern."
  • "Consider reducing intensity today if the session does not feel right."

1.2 Prohibited medical positioning without separate regulatory review ​

Do not ship functionality or marketing that claims UNDA:

  • diagnoses PCOS, endometriosis, amenorrhoea, hormonal imbalance or another condition;
  • detects disease or reproductive disorders;
  • treats PMS or another medical condition;
  • prevents RED-S or other disease/injury;
  • measures actual hormone levels without a validated measurement source;
  • determines that exercise is medically safe or unsafe;
  • replaces a doctor, physiotherapist or other healthcare professional;
  • prescribes treatment;
  • provides clinical decision support.

Avoid domain names and database fields such as:

text
diagnosis
medical_condition_detected
risk_of_pcos
hormonal_imbalance
treatment
patient_status
disease_probability

Prefer:

text
training_readiness
cycle_pattern
estimated_cycle_state
recovery_signal
training_adjustment
user_feedback
recommendation_factor

1.3 Regulatory trigger ​

Any planned feature that moves from fitness/personalisation into diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease must receive a medical-device regulatory assessment before implementation or public description.

2. Data Classification ​

UNDA must assume that menstrual-cycle, reproductive, symptom and many physiological data points are sensitive health-related personal data.

2.1 Sensitive data ​

Treat at least the following as SENSITIVE_HEALTH:

  • menstrual dates;
  • cycle length;
  • period flow;
  • period symptoms;
  • cramps/pain;
  • cycle irregularity;
  • ovulation estimates;
  • fertility-related information;
  • pregnancy-related information;
  • HRV;
  • resting heart rate when tied to health/recovery;
  • sleep data;
  • body temperature where used physiologically;
  • recovery scores;
  • subjective fatigue;
  • physical symptoms;
  • inferred cycle phase/state;
  • inferred physiological response;
  • readiness/recovery outputs derived from health data.

2.2 Fitness data ​

Treat workout and performance information as sensitive personal data internally even where it is not automatically Article 9 health data in every context.

Examples:

  • workouts;
  • cycling power;
  • FTP;
  • heart rate;
  • training load;
  • RPE;
  • pace;
  • exercise history.

2.3 Identity data ​

Keep identity data logically separated where practical:

text
users
  user_id
  email
  account_status
  created_at

health_profiles
  user_id
  ...

cycle_records
  user_id
  ...

training_records
  user_id
  ...

Use an internal UUID or equivalent pseudonymous identifier rather than email as a cross-system key.

3. GDPR Baseline Rules ​

UNDA development must follow these principles:

  1. Lawfulness, fairness and transparency
  2. Purpose limitation
  3. Data minimisation
  4. Accuracy
  5. Storage limitation
  6. Integrity and confidentiality
  7. Accountability
  8. Privacy by design and by default

3.1 Data minimisation rule ​

Every new personal-data field requires an answer to:

text
Why do we need it?
Which product feature uses it?
Can the feature work without it?
How long do we need it?
Which systems receive it?
Is it exposed to analytics/logging/support tools?

If the purpose cannot be stated clearly, do not collect the field.

3.2 No speculative collection ​

Do not collect data merely because:

"It may be useful for AI later."

A defined present purpose is required.

3.3 Privacy by default ​

New users should start with the most privacy-protective reasonable settings.

Optional processing should be off by default unless there is a documented legal/product reason otherwise.

4. Consent Architecture ​

UNDA must not represent all consent with one boolean.

4.1 Required consent model ​

Implement a versioned consent record, e.g.:

text
consents
  id
  user_id
  consent_type
  policy_version
  granted
  granted_at
  withdrawn_at
  source

Possible values:

text
health_data_processing
product_analytics
marketing_email
research_use
apple_health
health_connect
garmin
strava

4.2 Health data ​

For the consumer product, UNDA's baseline design should obtain explicit consent for health/cycle-data processing used for personalisation unless qualified counsel documents another applicable GDPR Article 9(2) condition.

Health-data consent must be:

  • specific;
  • informed;
  • affirmative;
  • recorded;
  • versioned;
  • withdrawable.

4.3 Bundling prohibited ​

Do not bundle:

text
Terms + Health processing + Marketing + Research

into one checkbox.

4.4 Withdrawal ​

Users must be able to withdraw optional consent.

Withdrawal must trigger the correct system behaviour, including stopping processing that depends solely on that consent.

5. Analytics Rules ​

5.1 Core rule ​

Sensitive menstrual, reproductive, symptom or health-state values must never be sent to generic analytics, advertising or marketing systems.

5.2 Prohibited analytics ​

Do not send:

javascript
analytics.track("Workout Modified", {
  cycle_day: 24,
  phase: "luteal",
  symptoms: ["cramps", "fatigue"],
  expected_period: "2026-08-11",
  hrv: 48
});

5.3 Preferred analytics ​

Use non-sensitive interaction events:

javascript
analytics.track("Recommendation Viewed", {
  screen: "today",
  source: "dashboard"
});

5.4 Event allowlist ​

Maintain:

text
/docs/privacy/analytics-event-allowlist.md

Any event or property not on the approved list should require review before production.

5.5 Advertising ​

Do not use menstrual, cycle, symptom, HealthKit, Health Connect or similar health/fitness data for:

  • targeted advertising;
  • behavioural advertising;
  • ad audience creation;
  • remarketing;
  • cross-service profiling;
  • sale to data brokers.

UNDA's preferred commercial model should not depend on monetising intimate user data.

6. Logging and Observability ​

6.1 Never log sensitive payloads by default ​

Bad:

text
ERROR recommendation failure
email=user@example.com
cycle_day=24
symptom=heavy_bleeding
period_expected=2026-08-11

Good:

text
ERROR recommendation_calculation_failed
request_id=3c771b
algorithm_version=0.4.1
error=insufficient_input

6.2 Logs must exclude ​

  • menstrual dates;
  • symptoms;
  • pregnancy/fertility fields;
  • free-text health notes;
  • HealthKit / Health Connect payloads;
  • access tokens;
  • refresh tokens;
  • authentication secrets;
  • exact recommendation input snapshots unless held in a dedicated protected store.

6.3 Sentry / crash tooling ​

Before enabling a crash/observability SDK:

  • inspect automatic breadcrumbs;
  • disable request-body capture where sensitive data may appear;
  • scrub URLs/query strings;
  • scrub user email unless required;
  • scrub headers/tokens;
  • document retention.

7. Database and Backend Architecture ​

7.1 Domain separation ​

Prefer separate logical domains:

text
Identity
Health/Cycle
Training
Integrations
Recommendations
Billing
Analytics

Do not create an unrestricted "full user profile" object that is replicated into every service.

7.2 Sensitive data access ​

Production health data must use least-privilege access.

Developers should not automatically receive unrestricted database browsing rights.

7.3 Development environments ​

Never copy raw production health/cycle data into:

  • local development;
  • QA;
  • demos;
  • staging;
  • screenshots;
  • test fixtures.

Use synthetic data.

7.4 Encryption ​

At minimum:

  • TLS in transit;
  • encryption at rest;
  • encrypted backups;
  • secure secret storage;
  • strong managed authentication or equivalent;
  • MFA for administrative access.

7.5 Secrets ​

Never store OAuth tokens, API keys or passwords:

  • in source code;
  • plaintext configuration files;
  • application logs;
  • analytics;
  • public CI variables.

Use an approved secret manager / encrypted token store.

8. Connected Apps and Wearables ​

Applies to Apple HealthKit, Google Health Connect, Garmin, Strava and future integrations.

8.1 Minimum necessary scope ​

Only request data required for an active feature.

Possible UNDA inputs:

text
workouts
heart rate
resting heart rate
HRV
sleep
cycling power

Avoid unrelated permissions such as contacts, messages, full location history or unrelated medical categories.

8.2 Incremental permissions ​

Prefer asking for permission when the user enables the relevant feature, not all permissions during first launch.

8.3 Connection record ​

Store:

text
integration
provider
user_id
scopes_granted
connected_at
last_sync_at
revoked_at
token_reference

Do not store raw tokens where unnecessary.

8.4 Disconnect behaviour ​

Define and document whether disconnecting:

  1. stops future sync only; or
  2. stops sync and deletes previously imported data.

The UI must explain the effect.

9. Recommendation Engine Rules ​

9.1 No deterministic phase prescription ​

Do not implement rigid logic such as:

python
if phase == "menstrual":
    workout = "easy"
elif phase == "follicular":
    workout = "HIIT"

Cycle phase may be one input, but recommendations should incorporate relevant individual data and uncertainty.

9.2 Suggested architecture ​

text
Population-level evidence/prior
        +
User cycle history
        +
Recent training
        +
Sleep/recovery
        +
User-reported energy/symptoms
        +
Historical individual response
        ↓
Training recommendation

9.3 Provenance ​

Store the origin of data:

text
user_reported
device_measured
provider_imported
unda_inferred

Examples:

text
cycle_phase_source = "unda_inferred"
period_start_source = "user_reported"
hrv_source = "apple_health"

9.4 Uncertainty ​

Predictions must not be stored as observations.

Bad:

text
ovulation_date = 2026-08-17

Better:

text
estimated_ovulation_start = 2026-08-15
estimated_ovulation_end = 2026-08-18
confidence = 0.61

9.5 Explainability ​

A recommendation should retain machine-readable factors:

json
{
  "recommendation": "moderate_endurance",
  "algorithm_version": "unda-readiness-0.4.2",
  "factors": [
    {"type": "recent_training_load", "impact": -12},
    {"type": "sleep", "impact": -8},
    {"type": "individual_cycle_pattern", "impact": -5}
  ]
}

The app should be capable of showing a user-facing explanation such as:

text
What influenced today's recommendation?

Sleep              ↓
Recent load        ↓
Cycle pattern      ↓
Resting HR         →

9.6 Manual correction ​

Users must be able to correct important cycle observations and user-entered health information.

Corrections should propagate to future predictions.

9.7 Algorithm versioning ​

Every recommendation must record the algorithm/model version.

Minimum:

text
recommendation_id
user_id
created_at
algorithm_version
input_reference
result
factors

10. Automated Decision-Making ​

UNDA should avoid designing recommendations that create legal or similarly significant effects for users.

Training suggestions should remain advisory and user-controlled.

If future automation materially affects:

  • healthcare;
  • employment;
  • insurance;
  • financial eligibility;
  • access to important services;

stop development and perform a separate GDPR/AI Act assessment.

11. AI Features ​

If UNDA adds generative AI, an AI coach, chatbot or ML-based inference:

  1. document the model/provider;
  2. document which personal data is sent to the model;
  3. prohibit provider training on UNDA user data unless separately lawful and intentionally approved;
  4. sign appropriate processor/data-transfer terms;
  5. minimise prompts;
  6. do not send full user health history when a smaller context is sufficient;
  7. add appropriate AI-interaction transparency where required;
  8. evaluate the EU AI Act before launch;
  9. do not allow the AI layer to turn UNDA into medical diagnosis/treatment without regulatory review.

No engineer may connect production health data to a third-party LLM API without an approved privacy/security review.

12. User Rights and Privacy Controls ​

UNDA must be designed so GDPR rights are technically executable.

12.1 Delete account ​

Provide a real deletion workflow.

Suggested flow:

text
request deletion
      ↓
re-authenticate
      ↓
disable account
      ↓
delete health/cycle records
      ↓
delete training records as applicable
      ↓
delete recommendation profile
      ↓
disconnect integrations
      ↓
delete/revoke tokens
      ↓
delete identity data not legally required
      ↓
trigger processor deletion where needed
      ↓
record completion

Data required by law to be retained for another purpose (for example certain payment/tax records) should be isolated from active product profiles.

12.2 Export ​

Provide a machine-readable export where applicable.

Suggested package:

text
UNDA-export.zip
  profile.json
  cycle.csv
  training.csv
  recommendations.csv
  integrations.json

12.3 Rectification ​

Users must be able to correct inaccurate user-entered personal information.

12.4 Privacy Center ​

Target product capability:

text
Privacy & Data

Cycle data
[Export] [Manage] [Delete]

Connected apps
[Manage]

Personalisation
[Manage]

Analytics
[Manage]

Marketing
[Manage]

Account
[Delete account]

13. Retention ​

Do not keep personal data indefinitely by default.

Create a retention configuration for each data category.

Example development baseline:

DataPolicy
Account identityWhile account exists + lawful residual obligations
Cycle historyUser-controlled / while feature is used
Training historyWhile account exists unless user deletes
Raw wearable samplesMinimise; retain only if required
Recommendation historyProduct-useful period only
Debug logsShort fixed retention
Security logsDefined security retention
OAuth tokensUntil disconnect/revocation
BackupsFixed rotation/expiry

Retention periods must be finalised before production.

14. Third-Party Vendor Rules ​

Before adding a vendor that can receive personal data, create an entry in:

text
/docs/privacy/processors.md

Minimum fields:

text
Vendor
Purpose
Data categories
Sensitive data? yes/no
EU/EEA location
Transfer mechanism if outside EEA
Retention
Subprocessors
DPA signed/reviewed
Security review
Deletion support
Owner

Examples requiring review:

  • hosting/database provider;
  • authentication provider;
  • Sentry;
  • PostHog;
  • Mixpanel;
  • Amplitude;
  • Firebase;
  • Intercom;
  • customer support;
  • email service;
  • AI provider;
  • cloud storage;
  • Garmin/Strava integration services.

A well-known vendor is not automatically compliant by default; configuration and data flows matter.

15. Security and Incident Response ​

15.1 Minimum controls ​

  • MFA for privileged access;
  • least privilege;
  • environment separation;
  • dependency vulnerability scanning;
  • secrets scanning;
  • patching process;
  • secure backups;
  • access revocation for departing team members;
  • protected admin tools;
  • auditability of privileged access where practical;
  • rate limiting and abuse protection;
  • incident response procedure.

15.2 Personal-data breach procedure ​

Create:

text
/docs/security/incident-response.md

It must include:

  • detection;
  • containment;
  • severity assessment;
  • personal-data impact assessment;
  • responsible decision maker;
  • processor notification handling;
  • regulatory notification assessment;
  • user communication assessment;
  • evidence preservation;
  • post-incident remediation.

GDPR breach notification deadlines can be short; this process must exist before production health data is stored.

15.3 Cyber Resilience Act ​

The EU Cyber Resilience Act's reporting obligations begin 11 September 2026 for covered products with digital elements, while the main obligations apply from 11 December 2027.

Before public release, UNDA should maintain:

text
security contact
vulnerability intake
vulnerability triage
incident classification
patch workflow
regulatory-reporting assessment
dependency inventory

A formal CRA applicability assessment should be completed before launch.

16. Minors ​

Initial product policy:

UNDA v1 is intended for users aged 18+.

Implement an age confirmation during onboarding.

Do not intentionally build a minors' reproductive-health product without a dedicated legal, privacy, safeguarding and UX assessment.

Spain's data-protection law allows consent-based processing by minors in certain circumstances from age 14, but this does not make an under-18 sensitive-health product automatically low-risk or simple.

17. Apple App Store Rules ​

Before iOS production release:

  • accurately complete App Store privacy disclosures;
  • include relevant third-party SDK collection;
  • declare health/fitness collection correctly;
  • provide a public Privacy Policy;
  • request HealthKit data only for actual health/fitness functionality;
  • disclose the specific health data collected;
  • do not use HealthKit/health/fitness data for prohibited advertising, marketing or data-mining purposes;
  • confirm HealthKit permissions match product functionality;
  • review all SDK privacy manifests and data flows.

Do not assume an SDK is invisible to App Store privacy disclosure merely because UNDA did not write the SDK.

18. Google Play Rules ​

Before Android release:

  • complete the Health Apps declaration;
  • declare period tracking;
  • declare relevant activity/fitness features;
  • declare health-data access;
  • maintain a public Privacy Policy;
  • provide prominent disclosure and affirmative user consent for sensitive permissions where required;
  • request only necessary permissions;
  • keep declaration answers aligned with actual app behaviour.

The Health Apps declaration applies to published apps including testing tracks.

19. Marketing and Scientific Claims ​

Every public performance/health claim must have an evidence owner.

Maintain:

text
/docs/evidence/claims-register.md

Suggested format:

ClaimSurfaceEvidenceStrengthOwnerApproved
"Training adapts to your individual response"WebsiteProduct logicHighProductYes
"Women perform better in phase X"—Insufficient/generalisedLow—No

Do not publish claims such as:

  • "proven to optimise hormones";
  • "prevents injury";
  • "guarantees better performance";
  • "detects hormonal problems";

without specific substantiation and regulatory/legal review.

20. Research Use ​

Product analytics are not automatically scientific research.

If UNDA later conducts formal health-related human-subject research:

  • create a separate research protocol;
  • assess ethics-review requirements;
  • obtain appropriate participant consent;
  • separate research consent from product consent;
  • define withdrawal;
  • define data handling;
  • review Apple/Google health-research requirements.

Do not silently convert ordinary users' intimate data into a research dataset.

21. Required Internal Documentation ​

The repository should contain:

text
/docs/legal/
  UNDA_LEGAL_ENGINEERING_RULES.md

/docs/privacy/
  data-inventory.md
  data-flow.md
  processors.md
  permissions.md
  analytics-event-allowlist.md
  retention-policy.md
  consent-register.md

/docs/security/
  threat-model.md
  incident-response.md
  vulnerability-management.md

/docs/evidence/
  claims-register.md

/docs/product/
  intended-purpose.md
  recommendation-engine.md

21.1 Data inventory template ​

For every meaningful personal-data field:

text
Field:
Source:
Classification:
Purpose:
Legal basis:
Article 9 condition (if applicable):
Database:
Retention:
Processors:
Analytics:
User editable:
User deletable:
Exported:
Owner:

Example:

text
Field: period_start_date
Source: user
Classification: SENSITIVE_HEALTH
Purpose: cycle modelling and personalised training
Database: cycle_records
Retention: user controlled
Processors: hosting provider only
Analytics: NEVER
User editable: yes
User deletable: yes
Exported: yes

22. Pull Request Compliance Checklist ​

Any PR that changes personal-data handling must answer:

text
[ ] Does this PR collect a new personal-data field?
[ ] Does it collect/infer health or reproductive information?
[ ] Is the field necessary for a documented feature?
[ ] Is the purpose documented in data-inventory.md?
[ ] Does it require consent or a permission change?
[ ] Is any sensitive value sent to analytics?
[ ] Is any sensitive value added to logs?
[ ] Does a new third party receive data?
[ ] Does retention/deletion support this new data?
[ ] Is it included in export where applicable?
[ ] Does it change recommendation/medical claims?
[ ] Does it change Apple/Google privacy declarations?
[ ] Has security impact been considered?

A yes answer is not automatically a blocker, but it requires the relevant documentation/review.

23. Hard Engineering Rules ​

These are UNDA's non-negotiable development rules.

RULE 1 — No sensitive health data in generic analytics ​

text
cycle dates
phase
symptoms
fertility information
pregnancy information
HRV values
health notes

must not enter generic analytics/advertising systems unless a specific approved architecture and lawful purpose exists.

RULE 2 — No sensitive health data in generic logs ​

Sensitive payloads must be redacted or excluded.

RULE 3 — No production health data in development ​

Only synthetic/de-identified approved fixtures.

RULE 4 — Explicit provenance ​

Distinguish:

text
user reported
device measured
provider imported
UNDA inferred

RULE 5 — Predictions are not facts ​

Estimated states/windows must remain labelled as estimates internally and in UI where relevant.

RULE 6 — Fitness, not diagnosis ​

UNDA's default product output is training guidance, not diagnosis or medical treatment.

RULE 7 — Every recommendation is versioned ​

Store algorithm/model version and interpretable factors.

RULE 8 — Data must be deletable ​

Do not introduce a datastore without defining deletion behaviour.

RULE 9 — Data must have a purpose ​

No "collect now, figure out later."

RULE 10 — Third-party data sharing requires review ​

No engineer may send user health data to a new external service without privacy/security approval.

RULE 11 — Least privilege ​

No broad developer/admin access by default.

Never rely only on accepted_terms = true.

24. Pre-Beta Gate ​

Before collecting real menstrual/health data from external beta users:

text
[ ] Controller/legal owner identified
[ ] Intended purpose documented
[ ] Data inventory complete
[ ] Health-data consent implemented
[ ] Privacy notice available
[ ] Sensitive logging audit passed
[ ] Analytics allowlist implemented
[ ] Encryption enabled
[ ] Secrets management enabled
[ ] Production access restricted
[ ] Delete-account path works
[ ] Integration disconnect works
[ ] Processor inventory completed
[ ] DPAs reviewed for core processors
[ ] DPIA completed or applicability formally assessed
[ ] Incident-response process documented
[ ] Age policy implemented

25. Pre-Public-Launch Gate ​

In addition to the beta gate:

text
[ ] GDPR Privacy Policy final
[ ] Terms of Service final
[ ] Spanish Legal Notice / applicable provider disclosure final
[ ] Cookie/tracker consent reviewed for web
[ ] Trademark/name clearance completed
[ ] App Store privacy declarations completed
[ ] Google Health Apps declaration completed
[ ] HealthKit / Health Connect permission review passed
[ ] Marketing claims register approved
[ ] MDR medical-device boundary reviewed
[ ] CRA applicability/reporting process reviewed
[ ] AI Act assessment completed if AI features exist
[ ] Data retention jobs active
[ ] User export works
[ ] User deletion verified end-to-end
[ ] Security/vulnerability contact exists
[ ] Third-party licence/IP audit complete

26. Escalation Triggers ​

Stop and request legal/privacy/security review before shipping if a feature:

  • identifies or predicts disease;
  • uses reproductive data for advertising;
  • shares cycle/health information with a new vendor;
  • introduces pregnancy/fertility decision-making;
  • targets users under 18;
  • uses user data for research;
  • trains an AI model on user health information;
  • introduces a chatbot giving medical-style advice;
  • makes automated decisions with important real-world effects;
  • collects precise location without a clear need;
  • adds new HealthKit/Health Connect categories;
  • changes deletion/retention behaviour;
  • creates a new international data transfer;
  • connects health data with insurance/employment eligibility;
  • makes a new clinical/performance claim.

Legal / Platform Sources ​

These sources were checked on 8 August 2026. Requirements can change; re-check before production launch.

European Union / Spain ​

Apple ​

Google Play ​

Final Internal Principle ​

UNDA can learn from intimate physiological information only when the feature genuinely needs it. Collect the minimum, separate sensitive data, make inference visible, preserve user control, never monetise health data indirectly, and never imply medical certainty where UNDA only provides training guidance.

Last updated:

UNDA is a fitness and training support product. It is not a medical device.

The compliance documentation on this site is our internal engineering standard, not legal advice.