Data Privacy and Security in Health and Fitness Technology
Linas JuozėnasShare
Data Privacy and Security
Use health and fitness technology with a clearer understanding of what you share, who can access it and what protection means.
A workout record can help you follow progress. A secure message can support a consultation. A route can help you remember a good day outdoors. Each becomes more useful when its purpose, audience and limits are understood.
This guide explains how personal information moves through connected services, separates security features from privacy promises, and offers practical steps for individuals, coaches and organizations.
Understand why information is needed and where it goes.
Connection security, storage encryption and end-to-end encryption protect different things.
Review sharing, correct mistakes and understand how to leave a service.
Privacy, security and trust
Health and fitness technology often works by turning personal information into something useful: a record, a reminder, a conversation or an analysis. The value of that use depends on what the person wants to achieve and whether the service handles the information responsibly.
A useful starting question is simple: What information is needed for this task, and who needs it? Answering it can clarify both the benefit and the boundaries of a service.
Privacy concerns the use of information
Privacy includes why information is collected, what conclusions are drawn from it, who receives it and how it affects the person. A system can keep intruders out while still using information for an unexpected or inappropriate purpose.
For example, someone may be comfortable sharing a training log with their coach but uncomfortable having the same information used for advertising. The data have not changed. The purpose and relationship have.
Security protects information and services
Security includes protecting confidentiality, maintaining the integrity of records and keeping information available when it is needed. A private record that has been altered without authorization, or a health service that cannot recover its records after an incident, presents a different problem from a public disclosure.
These goals support one another. People need information to be accessible to the right person, accurate enough for its purpose and protected against inappropriate access. No single setting addresses all three.
Personal information extends beyond a name
Under the GDPR, personal data concern an identified or identifiable person. Identification may be indirect: an account number, a location record or other linked information can be enough to connect a record to someone. Removing the name does not automatically remove that connection.[1]
Consider the business relationship
A service may earn money from subscriptions, hardware, organizational contracts, advertising or other activities. The price alone does not reveal how information is used. A paid service still needs a clear privacy policy, and a free service should not be assumed to sell personal data without evidence.
Look for a specific explanation of the service’s purposes and recipients. “Improving your experience” is less informative than describing which records support which feature, whether information goes to another organization and what optional uses you can decline.
Trust grows when those explanations match the product’s behavior. It should be possible to benefit from a useful feature while understanding what the feature asks in return.
What health and fitness services may collect
Different products collect different information. A basic offline timer, a connected watch, a nutrition app and a clinical portal should not be treated as interchangeable. The table below is a guide to questions worth asking, rather than a claim that every service collects every category.
| Information | Examples | A useful question |
|---|---|---|
| Account and profile | Contact details, age, preferences, accessibility needs and account identifiers. | Which details are necessary, and which are optional? |
| Activity and physiological records | Workouts, steps, heart-rate readings and sleep-related signals. | What is measured, what is estimated and how long is it kept? |
| Location and timing | Routes, timestamps, recurring starting points and live activity sharing. | Is this visible to other users, the provider or connected services? |
| Health and genetic information | Symptoms, diagnoses, test results, treatment records or DNA reports. | What purpose justifies collecting this sensitive information? |
| Messages, images and consultations | Chats, uploaded photographs, documents and any enabled recordings or transcripts. | Is recording or transcription active, and who can access the result? |
| Technical and inferred information | Device identifiers, connection logs, usage patterns and calculated scores. | What is inferred or linked to my account beyond the information I entered? |
Measurements and conclusions are different records
A sensor signal may be processed into a heart-rate estimate, which may then contribute to a recovery score. The score is another layer of interpretation. A privacy review should ask about both the original records and the conclusions stored about the person.
That distinction also matters when something is wrong. A device was not worn, an activity was misclassified or a note was attached to the wrong account. The service should have a way to explain and correct relevant errors, including downstream interpretations where appropriate.
Sensitivity depends on context and use
Health and genetic data receive additional protection under the GDPR. For biometric data, Article 9 specifically concerns processing for the purpose of uniquely identifying a person. A fitness company’s broad marketing use of the word “biometric” does not settle the legal classification of every measurement.[2]
A step count and a clinical record do not automatically answer the same question. However, ordinary-looking records may reveal more when linked with symptoms, location, appointments or other information. Ask what the service actually does with them.
A consultation does not automatically create a recording
Video calls can be live without being recorded. Recording, transcription, AI-generated notes and storage of a clinician’s final record are separate functions. A provider should explain which are used, their purpose and the relevant choices or legal basis.
For the participant, a useful question before the call is: “What will be retained from this consultation, and where can I find that explanation?” That avoids assuming either that nothing is saved or that every interaction is permanently recorded.
Follow the information through the service
A person may think of an activity record as belonging to “the watch”. In practice, it might pass from the device to a phone, then to the provider’s cloud, an analytics service and an account connected by the user. Each step can introduce a different purpose, recipient or retention period.
Map the actual journey
Take one feature and trace it in ordinary language. Where is the information first created? Does it stay on the device? What is synchronized? Which people or organizations can read it? What happens when the feature is disabled?
You do not need to reconstruct the network. A provider should be able to explain the important parts clearly. When the explanation is missing, ask about the specific feature instead of requesting a broad assurance that everything is secure.
Understand who is responsible
In GDPR terms, a controller determines the purposes and essential means of processing. A processor handles personal data on a controller’s behalf. The actual activities determine those roles, and an organization may have different roles for different processing. A contract label alone does not settle the issue.[3]
For a consumer, the practical question is who can answer a request about the information. For a clinic or coach purchasing a service, it also means understanding the provider’s role, subcontractors and instructions for handling data.
Include the countries and organizations involved
The GDPR has additional conditions for transfers of personal data outside the European Economic Area. A transfer mechanism does not replace the other requirements for lawful processing.[4]
Ask where information is stored, which organizations receive it and who can access it from elsewhere. A statement about the location of a server answers only part of that inquiry. The provider should explain the relevant arrangements without leaving you to guess from the brand name.
Connections create additional copies and permissions
Linking two apps may allow access to historical records, future records or both. It may also allow one app to write information into another. Review the permission requested at the time of connection.
Disconnecting an integration may stop future access while leaving records that were already transferred. If removal of those records matters, ask the receiving service about deletion as well. Revoking permission and deleting a copy are separate actions.
Public visibility and provider access are separate
Making a profile private usually changes what other users can see. It does not necessarily change what the service itself stores, analyzes or shares under its policy. Similarly, hiding part of a public route does not prove that the original coordinates were removed from the provider’s records.
Check both levels: audience settings for other people and the policy governing the provider’s processing. A clear product should make the distinction understandable.
Include exports and backups
A downloaded health report becomes a file wherever you save or send it. It may appear in a downloads folder, a synchronized drive, an email attachment or another person’s records. Decide where you want that copy to live before exporting it.
The aim is not to avoid every transfer. It is to make each useful transfer deliberate, with a clear recipient and purpose. A report shared through an agreed clinical channel can be valuable precisely because the information reaches the right person.
How privacy and security problems arise
Some problems begin with an attacker. Others arise from a misleading setting, an unnecessary data transfer, an overly broad staff permission or a record kept long after its purpose has ended. It helps to identify the mechanism before deciding what protection is needed.
Unauthorized access
A stolen password, a compromised device, an exposed database or inappropriate internal access can make information available to someone who should not have it. The appropriate safeguards depend on the route: stronger sign-in protection does not fix a publicly exposed database, and database encryption does not resolve a deceptive consent screen.
Unexpected sharing without a break-in
Tracking pixels and similar integrations can transmit information to another organization as a normal part of how a website operates. The FTC has explained how such tools can expose sensitive health-related activity and discussed this issue in connection with its 2023 GoodRx and BetterHelp enforcement actions.[5]
The lesson is broader than those historical cases: an information transfer can be a privacy problem even when no criminal has broken into the system. The purpose, authorization and disclosure to the person still matter.
Linking records can reveal identity
Research on human mobility has shown that location traces can be highly distinctive, making supposedly de-identified records vulnerable to identification when combined with outside knowledge. Findings depend on the dataset and circumstances; they are not a universal identification rate for every fitness app.[6]
For a route-sharing feature, the practical concern may be a repeated starting point or a recognizable routine. For research, it may be whether location and time can be linked back to an individual despite removing obvious identifiers.
Labels do not all mean anonymous
Pseudonymization replaces or separates identifying information while retaining the possibility of linking records back using additional information. Such data remain personal data under the GDPR. Effective anonymization requires that the person is no longer identifiable by means reasonably likely to be used; it is more demanding than deleting a name.[7]
Aggregation also needs context. A summary about a large group and a result describing a tiny, recognizable group can create different risks. Ask what is released and what a recipient could reasonably infer.
Incorrect or unavailable records can also cause harm
An altered record, a mistaken account link or a service outage can undermine the purpose of the system even without public exposure. A clinic may need dependable access to records; a person may need a way to challenge a misleading profile.
Keep the response proportionate to the situation. A missing workout is usually a different problem from a compromised clinical account. Understanding the difference helps avoid both complacency and unnecessary alarm.
What encryption protects—and what it leaves open
Encryption transforms readable information into a form that requires the appropriate key to recover. Its protection depends on where encryption begins and ends, who controls the keys and what happens when an authorized system reads the information.
| Protection | What it is intended to protect | An important limit |
|---|---|---|
| Encryption in transit | Information moving across a connection, such as between an app and a server. | The receiving server normally decrypts it and may process the readable content. |
| Encryption at rest | Stored information, such as a database, backup or device storage. | An authorized application or key holder may still be able to read it. |
| End-to-end encryption | Content between the intended communicating endpoints. | The endpoints and recipient behavior still matter; not every kind of metadata is necessarily hidden. |
HTTPS protects a connection
HTTPS uses Transport Layer Security, or TLS, to protect communication with a website or service. TLS supports confidentiality, integrity and authentication of the connection.[8]
This helps protect information in transit. It does not establish that the receiving business uses the information appropriately, that the page is honest or that the provider cannot read what you submit. A misleading website can also use HTTPS.
The older term SSL still appears in marketing, but current secure web communication uses TLS. A decorative security badge is not a substitute for understanding the actual service and connection.
End-to-end encryption concerns the content’s endpoints
In end-to-end encrypted messaging, message content is protected between the communicating endpoints rather than being readable by the servers that deliver it. The IETF’s Messaging Layer Security protocol describes this model for group communication.[9]
A normal encrypted connection from your phone to a provider’s server does not, on its own, establish this protection. If the server decrypts a message to analyze it, the provider can access that readable content at that point.
Check the boundaries of the claim
Ask whether encryption covers messages, attachments, recordings, backups and newly linked devices. A product may protect one feature differently from another. The phrase “private consultation” is not enough to identify which technical model is used.
Even when message content is protected end to end, someone at a legitimate endpoint may save, photograph or share it. The device itself also needs protection. Encryption cannot make a recipient forget information they have already read.
Cloud analysis requires an explanation
If a service claims both that it cannot access your content and that it analyzes the readable content on its servers, ask how those statements fit together. Some systems use local processing or specialized privacy techniques. Others simply decrypt information on the server under controlled access.
Each architecture has a different trust model. A clear explanation is more useful than treating “military-grade”, “zero knowledge” or “fully secure” as self-explanatory guarantees.
For a health service, the right question is whether the chosen design supports the necessary care, access and recordkeeping while appropriately protecting the information. Encryption is a part of that design, alongside purpose, permissions and accountability.
Accounts, devices and everyday security
Everyday account protection can reduce common risks without requiring constant attention. Concentrate first on the accounts that provide access to other accounts, such as the email address used for recovery, and on services holding information that matters to you.
Use unique credentials
Use a different strong password for each account. A password manager can help create and store them, reducing the need to remember many unrelated secrets. CISA recommends strong passwords and password managers as part of basic account protection.[10]
Reusing a password connects otherwise separate services: a compromise at one can make another easier to access. Changing one account’s password does not resolve reuse elsewhere.
Add stronger sign-in protection
Multifactor authentication adds verification beyond a password.[11] Where supported, use an appropriate additional method and learn how account recovery works before you need it. Keep recovery information in a place you can access securely.
Passkeys use public-key authentication and are designed to resist phishing. They may be stored on a device or synchronized through a provider. A device PIN or local biometric check can approve their use; biometric information used for that local check is not sent to the website as the passkey credential.[12]
The relevant choice depends on what the service supports and what you can manage reliably. Strong sign-in protection should be paired with a practical recovery method, especially before replacing a phone or security key.
Protect the device and active sessions
A phone that remains unlocked can expose an already signed-in account without anyone needing the password. Use an appropriate screen lock, review notification previews and sign out of shared devices.
If the service provides an active-session list, use it to review devices you no longer use. Remember that changing a password, revoking a session and disconnecting another app may be separate controls.
Keep supported software updated
Security updates address known software weaknesses. Enable automatic updates where appropriate, and include the phone, app and connected device’s firmware in your review.[13]
A device can continue performing its basic function after the manufacturer stops providing updates. Ask about the support period when continued online use matters. Plan replacement or a different way of using the device according to the information it handles and the remaining risk.
Verify unexpected requests
Phishing messages imitate trusted people or organizations to obtain information or persuade someone to take an action. An urgent request about an account, delivery or breach may be part of the deception.[14]
When in doubt, open the service through a route you already trust and check there. Do not provide a password or approval code merely because a message claims to come from support. Report suspicious requests through the service’s established channel.
These measures support the user’s side of security. The provider remains responsible for its own systems, access controls and lawful handling of information.
Routes, communities and online consultations
Sharing can make technology more useful. A coach can review a session, friends can enjoy an activity together and a clinician can receive information before an appointment. The key is to choose the audience and detail needed for that relationship.
Review routes before making them public
Check whether a route reveals a home, workplace, school or recurring schedule. Consider whether you want to share the whole map, a reduced view or a summary without the route. If a platform offers start-and-end hiding, review the published result rather than assuming the default is sufficient for your situation.
Live sharing and posting after an activity also have different implications. A trusted person following an agreed live route for a specific purpose is a different audience from a public profile.
Look beyond the main profile setting
Separate controls may govern activities, photographs, leaderboards, group membership and who can follow you. Changing one setting may not change older posts. Review the parts you actually use and any information already visible.
If another person appears in a photograph or their route is included in a shared activity, consider their preferences as well. Your decision to publish your own progress does not automatically settle theirs.
Use the intended clinical channel
For a consultation, confirm the provider, appointment link and agreed way to send documents. Check the recipient before sharing a report, especially where names or addresses are similar.
If you need help joining the call, ask the provider about accessible alternatives or assistance. Privacy arrangements should support access to care. They should not leave someone unable to participate because the instructions or controls are difficult to use.
Clarify recording and AI assistance
Ask whether a consultation uses recording, transcription or an AI note-taking service. Find out what material is retained and which organizations process it. The final clinical record, a full transcript and an audio recording are different records with potentially different purposes.
A clinician may need to keep an appropriate medical record even when a patient account is later closed. The provider should explain the applicable retention requirements and distinguish them from optional recordings or product-improvement uses.
Keep shared-device arrangements understandable
Households and care relationships sometimes involve practical help with accounts. Use authorized sharing or proxy-access features where available, so that assistance does not require everyone to use the same password.
Discuss the scope of access and how to change it when circumstances change. A helper may need appointment details without needing every private message. A coach may need a training summary without needing an entire health history.
A useful sharing arrangement is specific enough that everyone understands what is shared and why. It should remain possible to review that arrangement as the relationship or purpose changes.
The legal landscape: EU context and international differences
Privacy laws do not all cover the same people, organizations or information. A fitness product’s international availability can make several legal systems relevant, but a familiar legal acronym is not a complete explanation of the user’s protection.
GDPR is not simply an EU-citizenship rule
The GDPR can apply to processing in the context of an EU establishment. It can also apply to certain organizations outside the EU when they offer goods or services to people in the EU or monitor behavior there. Citizenship alone does not determine coverage.[15]
For a reader, a useful question is which organization provides the service and why it says the relevant rules apply. A statement such as “available worldwide” does not answer that question.
A lawful basis is needed, and sensitive data have extra conditions
Processing personal data needs an appropriate legal basis under Article 6. Processing health or genetic data generally also needs an applicable Article 9 condition. Explicit consent is one possible condition; healthcare, research and other situations can involve different conditions and safeguards.[2]
Consent is therefore not a universal explanation for every record a clinic must keep. Equally, accepting a service’s terms does not automatically authorize any future use the company may find useful.
HIPAA has a particular U.S. scope
In the United States, HIPAA applies to covered entities and their business associates in the relevant circumstances. An independently chosen consumer health app is not automatically covered merely because it stores health information or a clinician recommends it. HHS guidance uses practical scenarios to explain the distinction.[16]
Information moving from a clinical system into a separate consumer service may therefore enter a different legal and contractual setting. Ask about the receiving service as well as the original source.
Other laws may still apply
The FTC’s Health Breach Notification Rule addresses certain businesses handling personal health records outside HIPAA’s coverage. Its scope and notification requirements are distinct from HIPAA’s rules.[17]
California’s CCPA provides rights to California residents in relation to businesses covered by that law, subject to its conditions and exceptions.[18] Other jurisdictions have their own provisions. These examples illustrate differences rather than provide a global compliance checklist.
Read the specific promise
A provider should identify what a claim such as “compliant” refers to. Does it concern the whole service, one feature, a contractual arrangement or an audit of a defined system? A security certification and compliance with data-protection law are different questions.
For consequential decisions—such as clinical record retention, workplace monitoring or insurance use—seek guidance relevant to the country and situation. General product marketing should not be the final authority on those questions.
Meaningful consent and ethical use
A well-designed service should explain a choice at the point where it matters. Someone deciding whether to share a route should see the audience. Someone considering research participation should understand the proposed research use. A long policy cannot replace a clear explanation in the relevant moment.
Consent needs more than a tick box
Where consent is the legal basis, it must be freely given, specific, informed and unambiguous. Explicit consent is required in some circumstances, including where it is the applicable condition for special-category processing. Withdrawal must be possible, and it does not retrospectively make earlier lawful processing unlawful.[19]
For the reader, useful questions include: What exactly am I agreeing to? Can I decline this optional use? How would I change the choice later? A vague promise of “better wellness” does not identify a specific purpose.
Separate purposes that need separate choices
Using information to provide a requested feature, publishing a testimonial, sending marketing messages and supporting a research project are different activities. A product should make those distinctions clear instead of presenting every choice as a condition of basic account use.
Permission from a phone’s operating system answers a technical access question, such as whether an app may use location. It is not, by itself, a complete explanation of every subsequent use of that information.
Notice the relationship around the request
Workplace consent can be difficult to give freely because of the imbalance between employer and employee. EDPB guidance specifically addresses that problem.[19] Similar practical questions arise when a person feels that refusing a wellness feature could affect selection, support or access to an activity.
An organization should explain what is necessary, what is optional and what happens if someone declines. It should avoid turning private health information into a condition for unrelated opportunities without an appropriate justification.
Research participation deserves a clear explanation
Research can offer public benefit, but a person should be able to understand the study’s purpose, information requested, recipients and relevant withdrawal arrangements. “Research” should not be used as a catch-all description for every future commercial experiment.
The legal basis and safeguards depend on the project. Do not assume that every research activity requires the same consent process, or that agreeing to one project means agreeing to all future projects.
Design for the people using the service
Readable text, accessible controls and a clear way to ask questions help people make informed choices. This matters for users with different languages, abilities and levels of technical familiarity.
For services used by children, consider the applicable age and consent rules, the child’s understanding and the necessity of the information requested. The setting should support participation and appropriate protection, with an explanation suited to the child and their caregivers.
Distinguish a suggestion from a consequential automated decision
The GDPR places restrictions and safeguards around decisions based solely on automated processing that produce legal or similarly significant effects. Exceptions have conditions. An ordinary workout suggestion does not automatically meet that threshold.[20]
If a decision affects an important opportunity, ask what information it used, who is responsible and how it can be challenged. A reassuring explanation generated by the same system is not necessarily meaningful human review.
Ethical use also asks whether the result serves the person’s interests. Information collected to help someone exercise should not quietly become a score that limits their opportunities or targets a vulnerability.
Your rights and leaving a service
Data-protection rights help people understand and influence what happens to information about them. Under the GDPR, the available right and its conditions depend on the processing. A service should make requests understandable and accessible.[21]
| Right | Purpose | Scope matters |
|---|---|---|
| Access | Obtain your personal data and information about its processing. | Other people’s rights still require protection.[22] |
| Correction | Correct inaccurate or incomplete personal data. | Identify the record and the relevant error. |
| Erasure | Request deletion where the conditions are met. | Legal obligations and other exceptions can apply. |
| Restriction | Limit processing in specified circumstances. | This can differ from deletion. |
| Portability | Receive eligible provided data in a reusable format. | Generally concerns automated processing based on consent or contract. |
| Objection | Object to relevant processing. | An objection requires processing for direct marketing, including related profiling, to stop. |
Ask a specific question
A useful access request might identify the account, the relevant service and the information you want to understand. You do not need to use complicated language. Keep a copy of the request and the response.
Access includes information about processing as well as the personal data themselves. Identity checks should be proportionate to reasonable doubts about who is making the request; they should not become an excuse to collect unnecessary documents.[22]
Understand the response period
Organizations generally must respond to a rights request within one month. A justified extension of up to two additional months can apply, with notice and reasons provided within the first month. Conditions also apply to refusing or charging for manifestly unfounded or excessive requests.[22]
If a response does not answer your question, identify what is missing. A clear follow-up can be more effective than starting a new, much broader request.
Deletion is meaningful, but not unconditional
Erasure can apply when information is no longer needed or was processed unlawfully, among other circumstances. Exceptions include necessary processing for legal obligations or legal claims.[20]
A clinic may therefore need to retain certain records under applicable law. It should explain what it retains, why and for how long. A requirement to keep a particular record does not itself justify every unrelated use of that record.
Separate the steps involved in leaving
Canceling a subscription, closing an account, uninstalling an app, revoking integrations and requesting deletion may be separate actions. Before leaving, decide whether you need an export and where you will store it.
Ask what happens to existing copies, backups and material already sent to other services. A provider should explain the relevant retention and deletion process rather than leaving you to infer it from the disappearance of the app icon.
An example of a focused request
“Please explain what personal data you retain for this account, the purposes and retention periods, and the recipients. I would also like to know how to close the account and request deletion of data that no longer need to be retained.”
Adapt the wording to your purpose. An access request and an erasure request can have different consequences, so say clearly what you want.
Where to seek further guidance
If the issue remains unresolved, consult the relevant data-protection authority. In Lithuania, the State Data Protection Inspectorate—Valstybinė duomenų apsaugos inspekcija, or VDAI—provides official guidance and current contact information.[23]
Keep the relevant messages, policy wording and dates. They help explain the issue without requiring you to send every unrelated record in your account.
What organizations should build and maintain
People should not have to compensate for unnecessary collection, confusing defaults or poorly controlled internal access. Organizations that handle health and fitness information need to make responsible behavior part of the service’s design and daily operation.
Collect with a defined purpose
Data protection by design and by default means building appropriate measures into processing and limiting default collection, use and accessibility to what is necessary for the purpose. EDPB guidance explains this as an ongoing obligation, rather than a feature added at the end.[24]
For a product team, a practical question before adding a field is: “Which decision or feature needs this, and what would happen if we did not collect it?” The answer should be specific enough to guide retention, access and user explanation.
Give people the access their role requires
A receptionist, coach, clinician, software engineer and billing team may need different information. Design permissions around the task, review them when roles change and remove access that no longer has a purpose.
Shared staff accounts make it harder to understand who accessed or changed a record. Individual access, appropriate authentication and useful audit records can support accountability. Logs themselves should avoid collecting unnecessary sensitive content.
Treat suppliers as part of the service
Using a well-known cloud provider does not remove responsibility for configuration, staff access or the organization’s own purposes. A small provider is not automatically unsafe, and a large brand is not a complete security assessment.
Ask what the supplier processes, where, under which instructions and with which subcontractors. Review the practical arrangements for incidents, deletion, service termination and access requests. Responsibility should remain clear when the service changes ownership or a supplier is replaced.
Maintain protection over time
NIST’s Cybersecurity Framework 2.0 supports organizations in identifying and managing risks across governance, protection, detection, response and recovery. It is a framework for organizing work, not proof that a particular service is secure.[25]
In practice, organizations need supported systems, controlled updates, appropriate backups, restoration testing and a way to identify and resolve weaknesses. An audit or penetration test provides evidence within its scope and timing. It cannot guarantee that no vulnerability will ever arise.
Make privacy controls work as described
If a button says “private”, test the relevant audience settings. If an optional feature is turned off, check the associated data flow. If a user deletes a record, make the resulting behavior match the explanation, including any justified retention limits.
These are product-quality questions as well as privacy questions. A control that looks clear but does something different undermines informed choice.
Prepare for change and failure
Organizations should know how they will notify affected people, restore important services and answer questions after an incident. They should also plan for routine departures: an employee leaves, a customer closes an account or a device reaches the end of support.
Responsible data handling is visible in those ordinary transitions. It depends on clear ownership and repeatable work, as well as technical safeguards.
Responding to an incident or breach notice
An incident notice should help the person understand what happened and what to do next. It should distinguish known facts from matters still under investigation and identify the types of information involved.
If you receive a notice
Verify it through the provider’s established website, app or contact channel. A real breach can be followed by fraudulent messages that imitate support or offer unnecessary “recovery” services.
Read what was affected. A password exposure, an unauthorized account session, a payment-data issue and an exposure of health records may require different responses. Follow relevant, verified instructions rather than assuming every notice means every kind of information was disclosed.
Take actions connected to the exposure
- Account access: Use the genuine service to change affected credentials, review active sessions and strengthen sign-in protection where appropriate.
- Password reuse: If the same password was used elsewhere, change it on those services too.
- Financial information: Contact the relevant payment provider through a trusted channel when payment data or suspicious transactions are involved.
- Health information: Ask what records were affected, what the provider has done and how it will communicate further findings.
- Ongoing concern: Keep the notice, dates and relevant correspondence for follow-up or a complaint.
Some information cannot simply be replaced like a password. Clear explanation and appropriate support matter when the exposure concerns a health history or genetic information.
What organizations must distinguish under the GDPR
A personal data breach can involve loss of confidentiality, integrity or availability. Controllers must document breaches. Notification to the relevant authority is generally required without undue delay and, where feasible, within 72 hours of awareness, unless the breach is unlikely to create a risk to individuals’ rights and freedoms.[26]
Communication to affected individuals has a different threshold: likely high risk, with communication without undue delay and relevant exceptions. Processors must notify the controller without undue delay. The rules do not mean that every technical incident requires a public announcement within 72 hours.[26]
Respond and learn
NIST’s incident-response guidance treats preparation, detection, response and recovery as part of continuing risk management. The work includes improving the organization’s ability to handle future incidents.[27]
Useful communication tells people what is known, what remains uncertain, which steps are relevant and where to obtain updates. A generic reassurance that security is important does not answer those questions.
For the individual, the aim is to regain useful control and obtain a clear account of the situation. For the organization, it is to contain the problem, meet its obligations, restore appropriate service and address what allowed the incident to happen.
Privacy technologies and future directions
Some privacy improvements are straightforward: collect less, process locally when appropriate and give users clear controls. Other improvements involve specialized mathematical or cryptographic methods. Each deserves an explanation of what it protects and what it assumes.
| Approach | Potential benefit | Question that remains |
|---|---|---|
| Local or edge processing | Analyze information on a device and reduce what is uploaded. | What still leaves the device, including backups and technical logs? |
| Federated learning | Train across separate data holders without centrally collecting all raw records. | What can model updates reveal, and which additional protections are used? |
| Differential privacy | Bound an individual’s influence on released results under a defined mathematical guarantee.[28] | What parameters, accounting and implementation support the guarantee? |
| Secure computation | Use methods such as multiparty computation or homomorphic encryption to limit disclosure during calculation.[29] | Which parties, outputs and assumptions remain trusted? |
| Zero-knowledge proofs | Prove a specified statement without revealing the underlying secret information.[29] | What exactly is proved, and what other information does the service collect? |
Evaluate the whole implementation
A privacy method can protect one part of a process while another part still exposes information. For example, keeping raw data on devices does not automatically make every transmitted update harmless. A protected calculation can still produce an output that reveals more than intended.
ENISA’s data-protection engineering report describes several technical approaches and the importance of choosing measures for the relevant purpose.[29] Their presence in a product should lead to better explanations, rather than replacing explanation with a label.
Differential privacy requires more than adding arbitrary noise
Differential privacy provides a formal way to reason about privacy loss. NIST’s guidance emphasizes that real implementations require attention to assumptions, parameters and practical hazards.[28] A provider should be able to explain the scope of its claim and how it was evaluated.
End-to-end protocols are part of an architecture
Messaging protection also depends on how accounts, devices, groups and supporting services work together. The IETF’s MLS architecture document describes those wider considerations.[30]
For a user, the practical questions remain recognizable: Which devices can read the content? What happens when a new device joins? How are backups handled? What can the service still learn from the surrounding activity?
Blockchain does not make misuse impossible
A ledger can help make certain changes detectable. It cannot establish that the original information was accurate, that collection was appropriate or that nobody copied information outside the ledger. Permanent records can also create difficulties for correction, deletion and minimization.
CNIL’s analysis of blockchain and the GDPR discusses these data-protection challenges.[31] Sensitive records should not be placed on an immutable public system merely because immutability sounds reassuring.
Ask how the person benefits
A useful innovation may reduce unnecessary disclosure, make access easier to understand or help researchers answer a question with less identifiable information. The evaluation should include usability, cost, access and what happens when something goes wrong.
The strongest claim identifies a particular protection, the conditions under which it holds and the remaining limitations. That gives people a basis for deciding whether the service fits their needs.
A practical privacy review
You do not need to review every device and account at once. Begin with one service that holds information you care about, then work through the choices that are relevant to it. The following framework is an original teaching aid.
-
Name the purpose.
Write down what the service helps you do. Identify the records needed for that purpose and the people who need access.
-
Review collection and sharing.
Check profile visibility, location, recordings, connected apps and optional uses. Confirm how the settings affect existing information as well as future records.
-
Protect access.
Review sign-in methods, device locks, recovery arrangements, active sessions and updates. Prioritize the account used for recovery as well as the fitness service itself.
-
Understand retention and departure.
Find out how to export useful records, cancel the subscription, close the account and request deletion. Note any distinct requirements for clinical records or information already shared elsewhere.
-
Resolve the important gaps.
Ask the provider a focused question when a material point is unclear. Keep the answer and review the arrangement when your needs, connections or the service change.
Example: a public activity profile
A person enjoys sharing completed cycling rides but does not want to disclose a recurring starting location. They review who can see their activities, examine a published route and choose the level of detail appropriate for the intended audience.
They also check whether older activities retain different visibility settings. The purpose is to keep the enjoyable part of sharing while making the audience and detail deliberate.
Example: sending information to a clinician
A person wants to send a relevant history before an appointment. They confirm the accepted channel and send the requested information to the correct recipient. They ask whether an uploaded file becomes part of the clinical record and how access is controlled.
They do not need to connect every fitness service simply because one report is useful. The scope of the transfer follows the clinical purpose.
Example: leaving an unused app
A person no longer uses a nutrition app. They save a copy of the information they want to keep, cancel any paid plan, review connected accounts and follow the account-closure process.
If they want data erased, they make that request explicitly and ask about anything retained. They store the export deliberately instead of leaving a sensitive file in an unnoticed downloads folder.
Example: a coach choosing software
A coach needs clients to record attendance and agreed exercise notes. Before selecting a service, they compare what information is necessary, how access works and how clients can leave.
They ask the provider about responsibilities, subcontractors, support and incident handling. The decision includes both the client experience and the coach’s ability to manage the information responsibly.
Review when something meaningful changes
Useful review points include connecting another app, replacing a device, enabling AI assistance, adding a caregiver, joining an organizational program or receiving notice of a new data use.
The goal is a manageable relationship with technology. You should know what you are using, understand the important information flows and have a practical way to change the arrangement.
Common questions
Does HTTPS mean the provider cannot read my information?
No. HTTPS protects the connection to the service. The receiving service normally decrypts the information. Its further use depends on the service’s design, purposes, permissions and legal obligations.
Is end-to-end encryption the same as encryption at rest?
No. Storage encryption protects stored information according to who holds the keys. End-to-end encryption protects content between communicating endpoints. Ask which feature, devices and backups a claim covers.
Is a private profile private from the company too?
Not necessarily. Profile visibility usually concerns other users. The provider’s collection, analysis and sharing are separate questions governed by its actual processing and applicable rules.
Does removing my name make a dataset anonymous?
Not automatically. Other details may still identify you or allow records to be linked. Pseudonymized information remains personal data when identification is possible using additional information.
Do all fitness apps fall under HIPAA?
No. HIPAA coverage depends on the organization’s role and circumstances. A health-related purpose or a clinician’s recommendation alone does not make an independent consumer app a business associate.
Can I withdraw consent and delete everything immediately?
Withdrawal and erasure are different actions. Earlier lawful processing is not undone by withdrawal, and erasure has conditions and exceptions. Ask what will stop, what will be deleted and what must be retained.
Does uninstalling an app close the account?
Usually it only removes the software from that device. Check the service’s separate controls for subscriptions, account closure, integrations and deletion of stored information.
Does signing in with a passkey send my fingerprint to the website?
The local biometric check can authorize use of a passkey on the device. The website receives cryptographic authentication, rather than your fingerprint as the passkey credential. Protect the device and recovery arrangements too.
Must every data breach be announced within 72 hours?
No. GDPR documentation, authority notification and communication to individuals have different conditions. The authority-notification deadline concerns awareness and risk; communication to individuals generally concerns likely high risk.
Can useful research happen while protecting privacy?
Yes, with an appropriate purpose, legal basis, safeguards and governance. Techniques can reduce exposure, but claims about anonymity or protected computation need to be evaluated in the actual setting.
Sources and scope
This guide uses official European data-protection guidance, primary technical documents, selected research and limited international comparisons. Legal rules, a security protocol and an organizational framework answer different questions; none alone establishes that an entire consumer service is appropriate.
Historical examples illustrate mechanisms such as tracking or the identification of mobility traces. They do not describe every present-day provider or supply a current product ranking. Technical standards are cited for the relevant concepts, rather than as a deployment checklist for a particular system.
The examples, review questions and five-step framework are original teaching illustrations. They are intended to support understanding and practical discussion. Specific obligations depend on the processing, jurisdiction, contract and circumstances.
Sources checked: 6 September 2026. Service settings, evidence and law can change. Use current official guidance when making a consequential decision.
- European Data Protection Board. Data protection basics. Guide for small businesses; accessed 6 September 2026.Explains personal data, sensitive categories and core data-protection concepts. Return to text ↑
- European Data Protection Board. Process personal data lawfully. Guide for small businesses; accessed 6 September 2026.Explains lawful bases and the additional conditions for special-category data. Return to text ↑
- European Data Protection Board. Guidelines 07/2020 on the concepts of controller and processor in the GDPR. Final version adopted 7 July 2021.Explains responsibility according to the actual purposes, means and processing arrangements. Return to text ↑
- European Data Protection Board. International data transfers. Guide for small businesses; accessed 6 September 2026.Explains the additional GDPR conditions for transfers outside the European Economic Area. Return to text ↑
- Federal Trade Commission, Office of Technology. Lurking Beneath the Surface: Hidden Impacts of Pixel Tracking. 16 March 2023.Technical account of tracking pixels and the health-information risks highlighted by FTC enforcement. Historical examples do not describe every current service. Return to text ↑
- de Montjoye YA, Hidalgo CA, Verleysen M, Blondel VD. Unique in the Crowd: The privacy bounds of human mobility. Scientific Reports. 2013;3:1376; doi:10.1038/srep01376.Research on the distinctiveness of mobility traces in a particular dataset; not a universal re-identification rate for fitness platforms. Return to text ↑
- European Data Protection Board. Secure personal data. Guide for small businesses; accessed 6 September 2026.Explains risk-based safeguards and distinctions between encryption, pseudonymization and anonymization. Return to text ↑
- National Institute of Standards and Technology. Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations. SP 800-52 revision 2; publication announcement, 29 August 2019.Used for the role of TLS in connection security, not as a current configuration checklist. Return to text ↑
- Barnes R, Beurdouche B, Robert R, et al. The Messaging Layer Security (MLS) Protocol. IETF RFC 9420; July 2023.Primary protocol document explaining end-to-end protection between communicating endpoints. It does not validate any particular health app. Return to text ↑
- Cybersecurity and Infrastructure Security Agency. Use Strong Passwords. Secure Our World guidance; accessed 6 September 2026.Consumer guidance on unique passwords and password managers. Return to text ↑
- Cybersecurity and Infrastructure Security Agency. Turn On MFA. Secure Our World guidance; accessed 6 September 2026.Consumer guidance on using more than a password for account access. Return to text ↑
- FIDO Alliance. Passkeys. Technical and consumer explanation; accessed 6 September 2026.Explains public-key authentication, phishing resistance, local user verification and synced or device-bound credentials. Return to text ↑
- Cybersecurity and Infrastructure Security Agency. Update Software. Secure Our World guidance; accessed 6 September 2026.Consumer guidance on security updates; product support periods differ. Return to text ↑
- Cybersecurity and Infrastructure Security Agency. Recognize and Report Phishing. Secure Our World guidance; accessed 6 September 2026.Guidance on deceptive messages and safe reporting. Return to text ↑
- European Data Protection Board. Guidelines 3/2018 on the territorial scope of the GDPR (Article 3). Final version adopted 12 November 2019.Explains establishment and targeting criteria. GDPR coverage is not determined by EU citizenship alone. Return to text ↑
- U.S. Department of Health and Human Services, Office for Civil Rights. Health App Use Scenarios & HIPAA. February 2016; linked from HHS developer resources reviewed 22 April 2026.Explains when an app developer acts as a business associate. A clinician’s recommendation alone does not establish that role. Return to text ↑
- Federal Trade Commission. Health Breach Notification Rule: The Basics for Business. July 2024.Explains the FTC rule’s scope and its distinction from HIPAA breach requirements. Return to text ↑
- California Privacy Protection Agency. Frequently Asked Questions. Official consumer and business guidance; accessed 6 September 2026.CCPA rights concern California residents and qualifying businesses, subject to the law’s conditions and exceptions. Return to text ↑
- European Data Protection Board. Guidelines 05/2020 on consent under Regulation 2016/679. Adopted 4 May 2020; version 1.1, 13 May 2020.Covers freely given, specific and informed consent, withdrawal and power imbalances. Return to text ↑
- European Commission. Information for individuals. Official guidance; accessed 6 September 2026.Explains individual rights, including erasure and safeguards for consequential automated decisions. Conditions and exceptions apply. Return to text ↑
- European Data Protection Board. Respect individuals’ rights. Guide for small businesses; accessed 6 September 2026.Overview of GDPR rights, conditions, exceptions and response periods. Return to text ↑
- European Data Protection Board. Guidelines 01/2022 on data subject rights — Right of access. Adopted 28 March 2023; version 2.1 with corrections dated 30 May 2024.Detailed guidance on access requests and reasonable identity checks; not a universal right to every document or algorithm. Return to text ↑
- Valstybinė duomenų apsaugos inspekcija (VDAI). State Data Protection Inspectorate. Official Lithuanian authority website; accessed 6 September 2026.Official starting point for Lithuanian data-protection guidance and current contact information. Return to text ↑
- European Data Protection Board. Guidelines 4/2019 on Article 25 Data Protection by Design and by Default. Version 2.0; adopted 20 October 2020.Design and default-setting obligations. The article’s product examples are original illustrations. Return to text ↑
- National Institute of Standards and Technology. The NIST Cybersecurity Framework (CSF) 2.0. NIST CSWP 29; 26 February 2024.Organizational risk-management framework; use of it is not certification that a service is secure. Return to text ↑
- European Data Protection Board. Data breaches. Guide for small businesses; accessed 6 September 2026.Distinguishes documentation, authority notification and communication to individuals, with different conditions. Return to text ↑
- Nelson A, Rekhi S, Souppaya M, Scarfone K. Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile. NIST SP 800-61 revision 3; April 2025.Connects incident preparation, detection, response and recovery with continuing risk management. Return to text ↑
- Near J, Darais D, Lefkovitz N, Howarth G. Guidelines for Evaluating Differential Privacy Guarantees. NIST SP 800-226; March 2025.Explains assessment of differential-privacy guarantees; the label alone is not a complete privacy assessment. Return to text ↑
- European Union Agency for Cybersecurity (ENISA). Data Protection Engineering. 27 January 2022.Technical overview of privacy-enhancing methods. The benefits of any implementation depend on its design and assumptions. Return to text ↑
- Beurdouche B, Rescorla E, Omara E, Inguva S, Duric A. The Messaging Layer Security (MLS) Architecture. IETF RFC 9750; April 2025.Describes the wider messaging architecture and the limits of protocol protection within a complete service. Return to text ↑
- Commission nationale de l’informatique et des libertés (CNIL). Blockchain and the GDPR: Solutions for a responsible use of the blockchain in the context of personal data. 29 October 2018.Discusses data-protection challenges. A ledger does not make inappropriate collection or disclosure impossible. Return to text ↑