Your fitness data is part of the workout—even on the day you do nothing.

The rest day that never became data-free

A rest day can still be a data-production day: the workout may stop while collection, inference and sharing continue.

Alex is a recreational runner midway through an eight-week block. The original plan is simple: leave continuous sensing enabled and let a coach see relevant trends, including on rest days. On Sunday, Alex does no formal training. Yet the watch records pulse intervals and low-level movement, estimates sleep, timestamps a sync and communicates with an app. The phone may also log app openings, device identifiers, notification interactions and location-related information, depending on permissions and product design.

The new signals create a real conflict. Longitudinal heart-rate and movement trends may support the declared coaching purpose. Precise background location, an unexplained analytics recipient and open-ended retention may not. Alex does not disable everything. The adapted response is to maintain proportionate coach sharing, reduce unnecessary permissions, hold optional analytics or advertising flows, shorten retention where controls permit and ask what deletion reaches. If the provider cannot explain recipients or server-side copies, the conservative action is to hold extra sharing and reassess.

That is the hidden labour of fitness data. The body produces signals; the user charges, wears and configures the device; software labels the record; and the user must later inspect permissions, interpret notices and clean up a trail that may have outlived the feature that created it.

One wrist movement, several new meanings

Consider one accelerometer sample. At the wrist, it is a time-stamped measurement of movement. Software groups many samples into patterns, applies thresholds or models, and may label periods as steps, stillness, sleep or activity. Combined with pulse records, app events and time of day, the stream may support an inference about routine, recovery or likely availability. Joined with an account or stable device identifier, it can become part of a durable personal profile.

The business decision comes later. Depending on its declared purpose and integrations, a product might use the derived pattern to change a prompt, personalise a feature, rank content, measure engagement or build an advertising audience. These are distinct decisions with different privacy costs. The original motion sample did not arrive carrying a marketing instruction; people and systems added that meaning.

Inferences are also fallible. A quiet night can reflect sleep, charging on a bedside table or a device left unworn. A shift worker’s schedule may look irregular without being unexpected. No single metric should settle a consequential choice. Signal quality, agreement, recent trends and human context matter; weak inputs should be discounted rather than dressed in false precision.

Raw data can be sensitive. Derived information may be more revealing than any individual sample. The privacy risk is created not only at the sensor, but at every join, label and decision that follows.

Collection, inference, retention and sharing are different acts

Four operations are often collapsed into one vague word: tracking. They should be separated.

Collection includes direct entries, observed behaviour, sensor measurements, third-party inputs and information created from existing records. The ICO’s consumer IoT guidance recognises observed, sensor-derived and inferred data. Australian regulator guidance also treats the creation of new personal information through analytics as collection. Minimisation cannot be made meaningful by counting only the fields a person typed.

Inference converts records into classifications, estimates or predictions. A device may measure motion directly while estimating sleep. An app may observe session timing while deriving a routine. An inference can relate to an identifiable person even when it is probabilistic or wrong; uncertainty does not make it inconsequential.

Retention preserves optionality. A long history can support trend analysis, but it also expands the period in which information may be reused, accessed after an account compromise or exposed in a breach. Sharing moves the boundary again: cloud processors, analytics providers, advertising technology, integrations and human recipients may each receive different fields under different terms.

The research perspective is cautionary rather than absolute. A systematic review retrieved for this draft reports that de-identifying wearable records can create a false sense of security when they remain open to re-identification. Other scholarship indicates that raw movement patterns, including short gait sequences, may identify people more readily than expected. De-identification can reduce some exposure, but should not substitute for minimisation, access control and bounded retention. A serious research question is therefore not only whether a name was removed, but what the remaining record can reveal when combined.

Permission is not comprehension

A permission screen can record a tap. It cannot show that the person understood a data supply chain.

OAIC guidance says consent cannot simply be inferred because a notice was displayed or because a person did not object. For sensitive information, express consent is generally expected unless an exception applies. Meaningful agreement should be voluntary, current, specific and informed—not buried inside acceptance of unrelated functions.

For product teams, that means replacing a broad request with a sequence the user can follow: what the sensor records; which inferences will be produced; what feature needs them; whether another organisation receives them; how long raw and derived records remain; what changes if permission is declined; and how withdrawal or deletion works. Contextual, in-app explanations are more useful than forcing the person to reconstruct the answer from a long policy after collection has begun.

Explainability should continue after the tap. A data-use decision should answer what changed, why it changed, which signals mattered, which were discounted and why another option was not selected. Users should be able to compare that explanation against current privacy information rather than rely on memory of an old permission screen.

Permission is an event. Comprehension is a condition that must survive changes in purpose, recipients and product design.

Australia: minimisation has legal context, not universal reach

The Australian position needs dates and boundaries. The OAIC APP 3 guidance retrieved for this draft is marked updated May 2026. As described there, an APP entity should take a data-minimisation approach and collect personal information only where it is reasonably necessary for its functions or activities. Sensitive information generally requires consent unless an exception applies. Whether a particular organisation, record or inference falls within those rules depends on facts, statutory definitions, exemptions and jurisdiction.

OAIC analytics guidance adds an important point for fitness technology: collection can include creating new personal information from existing data. It uses heart rate, gait and sleep patterns as examples of information fitness devices can generate. Analytics may also turn inputs that appeared non-identifying into information about an identified or reasonably identifiable person.

Purpose limitation is tested downstream. APP 6 restricts secondary use or disclosure unless consent or another permitted basis applies. APP 11 addresses security and reasonable steps to destroy or de-identify personal information that is no longer needed. That does not displace Commonwealth record-keeping requirements or another Australian law or court order requiring retention.

The OAIC’s 2024–2025 digital-health work shows active scrutiny of app notices, privacy policies and sensitive-data handling, but it should not be presented as a wearables-specific ruling. Coverage also varies internationally and between products. This is general education, not legal advice; a current policy, regional notice and applicable law must be checked before drawing a conclusion.

What enforcement reveals about invisible recipients

Enforcement history shows why “we never sold the data” is an incomplete answer. The consequential question is often whether sensitive information reached advertising or analytics systems and what recipients did with it.

In 2023, the US Federal Trade Commission alleged that GoodRx shared sensitive health information with companies including Facebook, Google, Criteo, Branch and Twilio. The resulting order included deletion and remediation measures. In a separate 2023 matter, the FTC’s final BetterHelp order restricted advertising-related disclosures, required affirmative express consent for certain sharing, addressed deletion by third parties and required a retention schedule. These matters concerned different services and US law; they are not evidence about a particular wearable.

In Australia, the Privacy Commissioner’s tracking-pixel investigation found privacy breaches involving health-service web data and warned APP entities to review pixel use. That matter was not about fitness watches, but the architecture is relevant: passive data can leave through embedded technology a user may never see.

Failure to respond is not merely a compliance abstraction. It can leave sensitive inferences available for an unrelated purpose, increase the impact of a breach, impose repeated privacy work on the user and allow weak data to shape later decisions. Enforcement examples are boundary markers, not substitutes for inspecting the actual system.

Decision confidence

High confidence exists when the purpose, sensor list, retention schedule, recipient list and working controls tell the same story. Medium confidence applies when the core purpose is clear but one element remains ambiguous. Low confidence follows when notices conflict, data are missing or a permission is broader than the feature needs. In Alex’s audit, heart-rate and movement trends support coaching; precise background location is discounted because it contributes little, while an opaque analytics recipient is weighted as a material concern. The alternative of disabling every sensor is rejected because it removes useful longitudinal context without addressing copies already held. The decision method is to connect available information before acting. Readiness signals are designed to be interpreted together with context, confidence and safety constraints. Incomplete or conflicting inputs should trigger a conservative hold and human reassessment. Maintaining the original plan is justified when the purpose is specific, the data requested is proportionate, retention is bounded, sharing is understood and the user still freely agrees.

Decision cost

Collecting more fitness data adds privacy and anxiety risk. Collecting less can mean a weaker signal, less personalisation and a missed opportunity to notice a useful trend.

That trade-off deserves more than a reflexive “collect everything” or “turn it all off”. Progressing too aggressively can expose more of a person’s routine, preserve inaccurate inferences and expand third-party access. Reducing unnecessarily can remove useful longitudinal context, make genuine changes harder to distinguish from ordinary noise and weaken a coach’s ability to interpret a disrupted week.

The purpose is not to maximise collection. It is to make the most appropriate decision at an acceptable cost. Sometimes that means maintaining a narrow flow. Sometimes it means reducing sensor access, substituting a manual check-in, shortening retention, delaying a new inference, holding a disclosure or escalating a question to a person.

The same logic applies to readiness-based training: multiple signals can inform a decision without giving every available signal equal weight. Privacy discipline improves the input boundary. It asks whether a piece of information is sufficiently relevant to justify collecting, retaining or sharing it in the first place.

Build the boundary before building the feature

Data minimisation is not a storage setting added at the end. It begins with the product question: which decision is this information meant to change? If no team can state the decision, the collection request has no clear technical boundary.

Product teams should map raw records and derived inferences separately; document each purpose; identify recipients and onward transfers; set bounded retention periods; and test deletion across production stores, backups and third parties. Exceptions should be visible. A user asking for deletion should be told what can be removed, what remains, why it remains and whether derived profiles are handled separately. A deletion control that reaches only the phone may leave account, cloud or recipient copies untouched.

Purpose limitation also needs engineering support. Advertising, coaching, product analytics and safety review are not interchangeable merely because they use the same account. Access rules, event schemas and vendor integrations should reflect those distinctions. A serious human-performance decision system should connect relevant information, test uncertainty, apply safety rules, adapt only when the case is sufficient and explain the reasoning.

Within the approved Flex Force X design boundary, Flex Force X is designed to adapt training recommendations when relevant context justifies a change. The product philosophy favours clear explanations for recommendations and changes. That means adaptive workout plans are a design subject, not permission to collect every available signal. The privacy question remains prior: was each input proportionate to the declared purpose?

Audit the rest day—and the status quo

A practical audit starts with the phone’s permission settings, but it should not end there. Compare those permissions with the product’s current policy and regional notice. Inspect connected apps, coach or clinic portals, advertising choices and data-export settings. Download an export if available: field names, timestamps and derived labels may reveal categories that a high-level dashboard does not show. Then ask the provider specific questions about retention, recipients, account closure and derived profiles.

Do not assume a request labelled “delete account” has one universal effect. Ask whether it reaches cloud records, backups, de-identified datasets, inferences and copies already sent elsewhere. Legal duties or technical backup cycles may limit immediate removal, but those limits should be explained rather than concealed behind a completed-state icon. If the answer remains unclear, reduce optional permissions, hold non-essential sharing and reassess. Higher-stakes workplace, insurance or health uses may justify professional or legal advice.

The counterargument deserves respect. Continuous records can reveal longitudinal patterns that isolated workout logs miss, reduce manual entry and support more relevant coaching. Third-party processors can provide legitimate infrastructure. Longer histories can improve comparison across seasons. None of that makes continuous collection inherently improper. It means the purpose, proportionality and controls must be strong enough to carry the added exposure.

The unsettling point is not that every rest-day record will be misused. It is that a person can do no workout, make no new entry and still perform unpaid governance work around a growing personal record. The workout ends when you stop moving; the data work ends only when someone chooses to stop it.