Who Can See Your Period Data? An Honest Map
Not a name, but a list of routes. The seven ways cycle data can reach somebody else, which of them your app leaves open, and the one that catches almost everybody.
If your cycle data never leaves your phone, the honest answer is nobody — and if it does leave, the answer is not a name but a list of routes. Seven of them exist: the company itself, the suppliers it hires to run analytics and crash reporting, advertisers where the app has an advertising model, an acquirer if the business is sold, an attacker after a breach, a party making a lawful request to whoever holds the data, and the person who picks up your unlocked phone. That last one is the likeliest, and it is the one nobody plans for. Which routes are open depends on where the data is stored, not on how sincere the company sounds.
This page maps the routes. It names no app as having sent anything down them, because only two matters against period apps have ever been documented by a regulator and they are set out below in the regulator's own words. Everything else here is about how software is built.
Start with the shape, not the villain
Every question on this page has the same first step: find out where the data sits. There are three shapes, and they open different routes.
If the app writes only to a database on your phone and makes no network request containing your cycle, most of the map below is simply closed. There is no server copy for a supplier to receive, an acquirer to inherit, an attacker to reach or anyone to ask for. If the app syncs to the cloud behind an account, all of those routes are open, whether or not the company has ever used one. If the phone is a window onto a database the company owns, the same is true and the copy is the original.
None of that is an accusation. It is a description of what is architecturally possible, and it is the only part of this subject you can check for yourself. What the app actually holds in the first place is a separate question, answered in what period apps actually collect.
The seven routes
The company itself
You send it every time you log, if the app stores anything on a server.
No server copy. An app that stores only on the device never receives it.
Its suppliers
Analytics, crash reporting, email delivery, install attribution and hosting all run on somebody else's software, and the app's own code sends to them automatically.
Nothing sensitive in the request. Diagnostics can carry crashes and device models without carrying anything you logged.
Advertisers
Only where there is an advertising model: an ad network in the app, or measurement of which advert your install came from.
No advertising business. An app with no ads and no advertising identifier has nothing to feed one.
An acquirer
Almost every privacy policy says that in a merger or sale, user data transfers with the business.
Nothing to transfer. A buyer inherits the servers, and empty servers stay empty.
An attacker
Any stored copy is reachable if the store itself is reached, however well it is encrypted at rest.
No stored copy. The safest database is the one that was never built.
A lawful request
Requests go to whoever holds the data, and a company that holds it can be required to produce it.
Holding nothing. There is no procedure that produces records a company does not have.
Somebody with your phone
They open the app, or they read the notification on your lock screen. No hacking involved.
An app lock, and quiet notifications. A PIN or Face ID on the app, and reminders that do not print anything on the lock screen.
Read down the last column and one pattern repeats. Six of the seven routes close for the same reason, and it is never a promise. It is that there is nothing at the other end.
The three people underrate
The acquirer. This is the quietest clause in any privacy policy and it sits near the bottom of almost all of them. It usually says your data passes to the buyer along with the business. Every good sentence above it — the pledges about sharing, the named suppliers, the retention limits — is a policy the current owner wrote, and a new owner can write a new one. You are not only judging the company in front of you. You are judging every company that might own it later.
The breach. Encryption at rest protects a database from someone who walks off with the disk. It does not protect it from someone who gets in as the application, because the application must be able to read the data to work. This is not a criticism of anybody's engineering; it is why "we encrypt everything" answers a narrower question than the one people think they asked.
The person holding your phone. A partner, a parent, a flatmate, someone at work who picked it up off the desk. No server, no supplier and no policy is involved. This is by a wide margin the commonest way a period log is read by somebody it was not meant for, and the two things that address it are an app lock and lock-screen notifications that say nothing specific. Both take a minute to set, and almost nobody sets them.
What regulators have actually found
This is the part of the subject where the internet is loudest and the evidence is thinnest, so here is all of it, in the wording that matters.
In January 2021 the US Federal Trade Commission announced a settlement with the developer of a widely used fertility-tracking app. The FTC's complaint alleged that the company promised to keep users' health data private while disclosing it to third-party analytics providers. The company settled, neither admitting nor denying the allegations, and agreed to obtain express consent before sharing health data in future.
In May 2023 the FTC charged the developer of an ovulation app with sharing users' sensitive personal information with third parties and failing to notify them, in breach of the Health Breach Notification Rule. That matter also resolved by stipulated order, again with the company neither admitting nor denying the charges.
Against those two, the counterweight belongs in the same breath: when the UK's Information Commissioner's Office reviewed period and fertility apps in 2024, it reported that no serious compliance issues or evidence of harms were identified, while urging developers to prioritise privacy.
The category around this one is less comfortable. A peer-reviewed scoping review of health apps found that most of those examined, twenty out of twenty-three, shared user data with third parties. That is the reason to ask about routes rather than to assume the worst about any particular name, and it is why Google requires developers to declare in the Data safety section how their app collects, shares and handles data.
The law probably covers you less than you think
Most people assume health information in an app is governed by medical privacy law. In the US it generally is not. The FTC's own guidance says that many companies collecting people's health information — a fitness tracker, a diet app, a connected blood pressure cuff — are not covered by HIPAA, and that the FTC Act and the Health Breach Notification Rule apply to them instead.
That is real protection and it produced both actions above. It is also mostly a rule about being told after a disclosure has happened, which is a different kind of protection from a disclosure being impossible. Nothing on this page is legal advice, and your rights depend on where you live; the point here is narrower and it is about mechanisms. A rule can require a company to tell you. It cannot un-send a request.
How to shorten your own list
Four things, in the order they pay off. Set an app lock and turn off detailed lock-screen previews for your tracker. Check whether the app works with the connection off, because an app that keeps working in airplane mode is doing its arithmetic where you can see it. Read the sale-and-merger clause in the policy, not the headline. And find the export, so that changing your mind later costs you nothing.
The whole procedure, timed, is in the ten-minute privacy check, and the argument for why architecture beats a promise is in what actually makes a tracker private. If you would rather stand outside all of it, a printable period tracker has none of these routes at all: paper has no suppliers, no acquirer and no breach. It also has no backup, which is the same trade in a different coat.
Where Athena stands
Athena is the app this site is being built for. It is in development, it is in no store, and there is nothing here to buy or sign up to, so this is a description of a design rather than something you can verify today.
Cycle data is written to a private database on the phone and predictions are calculated on the device. There is no account, so there is no server copy for a supplier, an acquirer, an attacker or a request to reach. What does leave, and what this page would be dishonest to omit: when the app ships it will send anonymous diagnostics to Firebase — which features get used, crash reports, device model and OS version — carrying nothing you log and no advertising identifier. This website uses web analytics with IP anonymisation. Route seven, the person with your phone, is not closed by architecture at all, which is why an app lock and quiet notifications are worth more than most privacy features.
The cost of the design is the one thing every article like this should say out loud. Local-only means no automatic backup. Lose the phone with nothing exported and the history is gone, and no support team can restore what nobody ever had.
In the meantime the tools on this site work the same way for a different reason: they run in your browser and nothing you type into them is transmitted anywhere. The cycle length calculator is the plainest demonstration — it takes a few start dates, gives you your average and the spread around it, and forgets all of it when you close the tab.
Questions people ask
Where this comes from
- US Federal Trade Commission (2021). Developer of Popular Women's Fertility-Tracking App Settles FTC Allegations that It Misled Consumers About the Disclosure of their Health Data. https://www.ftc.gov/news-events/news/press-releases/2021/01/developer-popular-womens-fertility-tracking-app-settles-ftc-allegations-it-misled-consumers-about
- US Federal Trade Commission (2023). Ovulation tracking app Premom will be barred from sharing health data for advertising under proposed FTC order. https://www.ftc.gov/news-events/news/press-releases/2023/05/ovulation-tracking-app-premom-will-be-barred-sharing-health-data-advertising-under-proposed-ftc-order
- US Federal Trade Commission (2024). Complying with FTC's Health Breach Notification Rule. https://www.ftc.gov/business-guidance/resources/complying-ftcs-health-breach-notification-rule-0
- PubMed Central (2022). Data sharing practices of medicines-related and health apps: a scoping review. https://pmc.ncbi.nlm.nih.gov/articles/PMC9123546/
- Information Commissioner's Office (UK) (2024). ICO urges all app developers to prioritise privacy. https://ico.org.uk/about-the-ico/media-centre/news-and-blogs/2024/02/ico-urges-all-app-developers-to-prioritise-privacy/
- Google Play Help (2026). Understand app privacy & security practices with Google Play's Data safety section. https://support.google.com/googleplay/answer/11416267
Every link above was checked when this page was last updated. Athena is not affiliated with any of these organisations, and none of them has reviewed this page. Nothing here is medical advice.