If your bank account gets compromised tomorrow, you can call the bank, freeze the card, and reverse the transactions. The damage is bounded. The system was designed assuming things would go wrong, so it has rails to undo them.
Your period data has no equivalent rails. If it leaks, it stays leaked.
A different kind of permanence
A breached bank statement reveals what you bought last Tuesday. A breached period log reveals when you stopped logging, when you started again, how heavy your flow has been for the last four years, and whether you ever logged a pregnancy you did not carry to term. Banking data is a record of transactions. Health data is a record of your body.
That is a meaningfully different category of disclosure. There is no equivalent of a chargeback for a medical record. You cannot un-log a miscarriage from a third party's server. You cannot ask a research data broker to forget what your cycle looked like in 2023.
Why the risk is permanent
A leaked credit card number is useful to a thief for a few weeks at most. After the bank reissues the card, the data is dead. A leaked period log is useful forever, because it is connected to who you are as a person.
Financial fraud has a half life. Health data exposure does not.
The same record that helped a doctor today can be used against you in a custody case ten years from now. Cycle data ages well, because the body it describes does not change identity.
How regulation treats the two
Banking is regulated for reversibility. Consumer protection law, anti-fraud frameworks, dispute resolution rails, and statutory liability caps all exist because the system assumes errors will happen and that those errors should not bankrupt the user. The whole architecture is "be wrong, then fix it."
Health data is regulated with the opposite intent. HIPAA, GDPR Article 9, the India DPDP Act 2023, and similar laws around the world recognise that health information cannot be fixed after it leaks. The protection model is "do not let it happen in the first place." Once a record exists somewhere it was not supposed to be, there is no patch.
That difference is the reason the strictest privacy laws in the world treat reproductive and health data as a special category. It is not an abstract preference. It is a recognition that this kind of data carries permanent exposure risk.
What it means for the apps that collect it
Most period tracking apps store your cycle data on a company server. They do this for product reasons that are easy to justify in a planning meeting. Backup. Cross device sync. Predictive insights. Aggregate research. All of those are real product values, and all of them are paid for with a permanent copy of your reproductive history sitting on infrastructure outside your control.
That copy is the asset, and it is also the liability. Every server-stored copy of cycle data is:
- A subpoena target. Courts and law enforcement can request it. Companies can be compelled to produce it.
- A breach target. Every database has a non-zero probability of being exposed. Health records do not get safer over time.
- An acquisition asset. When the company changes hands, the data follows. Your consent to the original company does not transfer cleanly to whoever ends up owning the records.
- A regulator's interest. Privacy authorities in multiple jurisdictions have already taken enforcement action against period apps for sharing data in ways their users did not understand.
The risk surface is structural. No privacy policy can eliminate it as long as the underlying architecture stores your data on someone else's machine.
What mylune chose instead
mylune does not store your health data on any server. The app holds your cycle history, symptoms, mood, and notes in encrypted local storage on your phone. No upload. No backup. No sync. No analytics. The architecture is the policy.
This is not a marketing decision. It is the only architecture that makes the promise verifiable. When we say we cannot share your health data, we mean we technically cannot. There is no database to search, no record to subpoena, no asset to acquire.
The trade off is that mylune cannot offer features that depend on having a copy of your data. There is no website where you log in to see your cycle. There is no cross device sync. There is no "we predicted this for you based on all our users." We accepted those trade offs because we believe the permanence of the data is the reason the trade off is worth it.
The honest summary
Banking systems were designed assuming things will go wrong, and they built rails to fix it. Most period app architectures were designed assuming nothing will go wrong, and they have no rails at all.
If you are choosing a period app today, that asymmetry is the question worth asking. Not "will this company do the right thing." That is a forecast. Ask instead: "could this company do the wrong thing, even if it wanted to." That is a structural answer.
mylune chose an architecture where the answer is no.