Stash Privacy Policy

Effective date: October 2, 2026

1. Our commitment and who is responsible

Stash Diabetes, Inc. provides Stash and is responsible for the personal information it processes as controller. Contact us at support@stashdiabetes.com.

Stash is built on transparency. We use bounded community contributions to improve supply management and help the diabetes community understand supply availability, reliability, and reported safety concerns. We explain the information each feature sends, its purpose, and your choices.

You do not need a Stash account. Our community systems do not require your name, email address, Apple ID, or Google account. They use a random Community Data ID, also called an Install ID. Your app stores this ID, and Stash receives and stores it with your contributions. We do not maintain a routine mapping from that ID to your identity, but we can link contributions made under the same ID. That is pseudonymity, not a promise that identifying a person is impossible. Any future intentional link between your identity and community contributions for research requires your separate, explicit, study-specific consent, as described in section 6.

Community source records are pseudonymous: direct identity fields are generally omitted and access and disclosure are restricted, but the records can still be personal data or sensitive health data under law. Research datasets described as “de-identified” must undergo the documented assessment described in section 6; source records are not automatically qualified merely because they lack a name. We reserve “anonymous” for information that cannot reasonably be linked to an individual under the applicable legal standard. Aggregation alone does not automatically make information anonymous.

There are important exceptions to the no-name/no-email design: newsletter subscriptions and support correspondence identify you if you provide an email address; Shared Stash can include your display name; and incident notes or contributed product names can identify you if you type personal information into them. We do not use those channels to build an identity profile of community contributors. If you provide your Community Data ID in a support or rights request, we can associate that correspondence with the ID for handling your request. This does not authorize research identity linkage or research recruitment.

This policy covers the consumer apps, their associated community services, and the secondary research uses described in section 6. Active study participation, a separately offered institutional service, or a future account feature requires any additional notice and authorization applicable to that activity before it starts.

2. What stays with you and how the platforms differ

Your device stores supply records, quantities, product and lot details, serial numbers, expiration dates, active supplies, use and dose records, placement history, trips, notes, barcode mappings, settings, optional A1C and insurance-type history, and manually entered meter/sensor reading pairs and sensor-test sessions. Stash's community backend does not receive a full copy of that database. Only the specific community fields below are transmitted through those channels.

Turning off Community Alerts does not turn off iCloud or OS backup. Turning off iCloud inventory sync does not necessarily stop iCloud key-value storage of the Community Data ID. Uninstalling or changing an identifier does not delete previous backend records. Do not rely on signing out of iCloud as a deletion mechanism.

Private CloudKit synchronization uses your Apple account; it is not a Stash-operated copy available for community analysis. The optional Shared Stash feature uses a different, public CloudKit path described in section 7.

3. Community contributions: fields, purpose, and identity protection

The following categories use the Community Data ID so Stash can deduplicate contributions, compare changes over time, and handle deletion requests. These source records are pseudonymous as described in section 1; they have not automatically met a formal research de-identification standard. Combining them can reveal a detailed supply and health history even without a name. Our hosting provider, Supabase, receives these records on Stash's behalf.

Incident and wear submissions also carry record IDs, submission type/time, app and OS version, platform, manual-entry and applicable consent flags. Their bounded device-context bundle can contain regimen (pump, injections, or hybrid), pump and CGM manufacturer, up to eight standardized insulin product names, a uses-GLP-1 flag, category-specific wear statistics, up to 30 placement-zone labels, and a session placement zone. These fields provide context for community comparisons. Zone labels are included; body-map coordinates are not.

These community channels do not include continuous blood-glucose streams, insulin dose or fill amounts, body-map coordinates, full trip itineraries, side-stash names, or general inventory notes. A1C and the paired glucose values in an opted-in sensor test are health measurements that do leave the device. Sensor contributions omit per-reading notes and exact per-reading timestamps, but include exact test start/completion times and server receipt times. Those dates and the common ID can make records linkable. Information you put in incident notes is also transmitted, so please do not include identifying or unrelated medical information there.

4. Community controls, history, and consent records

The Community Alerts / Recall & Community Alerts control in Settings combines lot observations, community reporting, periodic snapshots and supply-use packages, enabled profile/A1C/insurance uploads, and recall/lot-notice/MAUDE downloads. Turning it off withdraws permission for further contributions through those paths from that device and stops the associated downloads. Leaving Community also withdraws sensor-test sharing. Core local supply management remains available. Barcode contributions, analytics, email, and user-directed sharing have separate behavior.

In current builds, Community membership defaults off for a selected EEA country, the United Kingdom, Switzerland, or an unknown region, and defaults on in other selected regions. Onboarding and join surfaces explain the contribution program. Sending a first report can enable ongoing membership. A default or acceptance of Terms is not a substitute for explicit consent wherever the law requires it; the applicable consent requirements govern.

Reports send when submitted; periodic wear and inventory contributions and supply-use packages generally run on a weekly schedule, subject to connectivity and background execution. Lot observations use a separate throttled sync. Profile changes and pending A1C or insurance entries can sync on an app or background activity cycle. Information may be queued locally and retried. Sensor tests follow the separate completion and consent rules below.

On iOS, joining or rejoining can include up to 90 days of prior eligible wear history; the same backfill cursor is used by the inventory path, which reports the available inventory state rather than reconstructing every historic stock level. Android does not use the same 90-day rewind, but can submit eligible existing local records under its sync rules. Supply-use packages are reduced snapshots of stored history and are not limited by the wear backfill window. Where profile uploads are enabled, previously recorded but undelivered A1C and insurance entries, including those entered before joining or while contributions were off, can upload after you join or rejoin. There is no 90-day limit on those histories or on eligible pending sensor tests.

Both apps support sending a minimal receipt of a community or sensor-sharing grant or withdrawal: Community Data ID, event, policy version, choice surface, time if known, platform, app version, and receipt ID. Versioned Terms acceptance can have its own receipt; it is not a sensor-sharing grant. An older membership record may have an unknown time; we do not invent one. A withdrawal receipt may be sent after you turn Community Alerts off so we can record your choice. These records support accountability and your control of contributions, not advertising.

Separate consent for Sensor Accuracy Test

The sensor-test toggle is off by default, including for Community members. Turning it on in Settings enables the experimental feature and authorizes sharing eligible completed tests and their paired readings. Membership alone and acceptance of the Terms do not turn it on. The current feature does not offer a separate local-only test mode or a Send choice for each completed test.

A test with at least three eligible reading pairs can be submitted when you finish it or when its sensor is archived. It can include earlier readings recorded for that sensor. Uploads may happen immediately or on a later sync; failures can be queued and retried. Turning sharing back on can make eligible previously recorded or queued tests available for submission. Not every unfinished check or isolated spot reading is sent as its own contribution.

Sensor sharing requires Community membership, the toggle being on, and a grant for the current sensor consent version. The October 2, 2026 version added paired readings to the earlier summary-only payload and requires an affirmative renewed choice for that expansion. A future material expansion needs an updated disclosure and any required renewed consent before collection or use under the new scope. The research and aggregate commercial uses described in section 6 must also fall within the permissions applicable to each contribution.

You can withdraw sensor sharing in Settings without leaving the general Community program. Turning it off also disables the test feature; core supply management remains available. It does not erase local tests, transmitted contributions, or copies in your own backups. A request already transmitted cannot be recalled by a toggle, and a contribution batch already prepared or in flight when you withdraw may still be delivered. Editing or deleting a local reading does not automatically correct or remove a previously submitted test; use the rights process in section 11 for server-held records.

Turning off either contribution control does not itself erase already transmitted records. Section 11 explains deletion and other rights. Where consent is the legal basis, withdrawing it ends our authority to continue consent-dependent processing; any continued retention or use must have a separate lawful basis, such as a limited legal obligation, and must respect the applicable purpose and safeguards.

5. Analytics, barcode contributions, and reference lookups

Analytics: TelemetryDeck

Stash sends app-use signals to TelemetryDeck to understand whether features work and where people need a better supply-management experience. Signals include launches/sessions, screen and feature use, onboarding progress, settings-change events, error categories, and app/device/OS/locale information. Limited profile signals can include pump/CGM manufacturer, regimen flags, optional sex/age-range/diabetes-type/relationship answers, selected country/subdivision, and the initial insurance-type selection where provided (including a first entry after onboarding). Later insurance changes are not sent as analytics history. A caregiver's profile answers can describe the person with diabetes, including a child.

The SDK uses its own identifier or hash, separate from the Community Data ID. Stash does not send the Community Data ID to TelemetryDeck; the iOS and Android builds use the same TelemetryDeck application configuration. We do not send inventory lots, GTINs, serials, A1C values, meter/sensor glucose values, doses, quantities, trip details, body-map coordinates, or free-text notes through analytics. Health-context profile fields are still potentially sensitive; absence of a name does not make them legally anonymous by itself. SDK identifiers may allow events within the analytics dataset to be associated with one another.

The current builds initialize analytics automatically and do not provide an in-app analytics opt-out. Apple's Allow Apps to Request to Track switch is not a TelemetryDeck opt-out in these builds. Community Alerts does not control analytics. Contact us to exercise any applicable rights; this description does not remove consent requirements that apply to the processing.

Barcode contributions: Send to Stash

If you tap Send to Stash in My Barcodes, the app sends the saved mappings in that batch: GTIN, product name, original name where present, category, manufacturer, region, app version, record ID, and Community Data ID. This separate, one-time contribution helps identify supplies in different markets. It is not controlled by Community Alerts. Mappings are pseudonymous, but a custom name may contain identifying information; avoid putting personal details in names you contribute. Validated product facts may be incorporated into Stash's shared reference catalog without contributor attribution.

Product and safety reference lookups

An active internet connection through Wi-Fi or cellular data is required to download or refresh recall alerts, manufacturer notices, and community alerts. Without connectivity, Stash cannot retrieve new or updated alerts and notices. Previously downloaded information may remain visible while offline but may be out of date.

For an unrecognized barcode, Stash may send its product-code digits directly to NLM AccessGUDID or, for supported US-locale drug lookups, FDA openFDA. The app does not attach a Community Data ID, inventory records, or camera images to those identification queries. The query carries digits read from the scanned barcode; for an unrecognized code, those digits can occasionally include other machine-readable data printed on the package label, such as a serial number. The services nevertheless receive normal network information such as an IP address. These lookups support accurate product identification, operate independently of Community Alerts, and currently have no separate off switch; manually entering a supply avoids initiating a barcode lookup.

Recall and lot-notice lists are downloaded from Stash's Supabase service and matched with inventory locally. A matching recall does not require uploading your entire inventory. MAUDE and lot-community lookups can send the lot number as a query filter to Stash's Supabase-hosted service. MAUDE information is mirrored from public FDA records by Stash's backend; that path is distinct from the direct barcode lookups above. These requests do not attach the Community Data ID, but hosting systems can still receive the IP address, request time, and query details.

6. Community outputs and future partnerships

Community information can appear in aggregate counts, charts, safety notices, and limited structured report summaries. Current public outputs include lot summaries subject to contributor thresholds; dated lot-report summaries when the reporting threshold is met; and a recent-activity feed showing product, structured outcome, and a rounded time. The sensor-lot API can expose manufacturer, sensor type, lot, test/contributor counts, summary error/agreement measures, and the latest test completion timestamp when at least three distinct Community Data IDs qualify. This threshold counts IDs, not verified people. Public outputs omit Community Data IDs, serial numbers, incident notes, A1C values, individual paired glucose readings, and direct identifiers. Some are individual report summaries rather than large-group statistics. Thresholds and rounded times reduce risk but cannot guarantee anonymity in every context.

As of October 2, 2026, Stash has not sold community data or reports derived from it. We reserve the ability to sell or license qualifying de-identified aggregate data in the future under the limits below. We may work with researchers, clinical and academic institutions, universities, nonprofits, patient organizations, public-health bodies, industry partners, and manufacturers to improve supply access, quality, reliability, and safety. We may sell or license aggregate reports or analysis derived from community reports, wear sessions, and opted-in sensor tests, including their paired readings, when the outputs meet applicable legal de-identification or anonymization standards and the source permissions allow that use. We may receive payment, and partners may derive commercial value. Contributing does not entitle you to payment or a share of that revenue.

We do not sell identifiable or pseudonymous contributor-level records, provide community data for targeted advertising, or create advertising audiences. Partners may not identify or contact contributors from community data except through the separate, expressly authorized study process described below. We do not authorize uses that make individual insurance, employment, credit, treatment-access, or supply-access decisions. A manufacturer's involvement does not authorize matching a product serial to a customer.

Before a paid or nonpublic partner release, we must assess re-identification risks, minimize the information, suppress or generalize small or distinctive groups, and impose appropriate use, security, onward-transfer, and retention restrictions. We commit to keeping de-identified partner information in de-identified form, not attempting re-identification, and requiring the same of recipients where applicable. Removing the Community Data ID alone is insufficient. We will identify the partner, purpose, information categories, and paid or unpaid nature of a new partner program before it begins.

Clinical studies and secondary research. Stash may use existing contributions, including contributed A1C history and appropriately authorized sensor-test summaries and paired readings, and provide properly de-identified datasets to academic, clinical, nonprofit, public-health, industry, or manufacturer research partners for the disclosed community-benefit research purposes. These datasets may contain de-identified individual records as well as aggregates. This research pathway is distinct from the paid aggregate products described above. We will document the applicable legal basis, institutional/IRB or ethics determination, data protections, and any required approval or waiver before proceeding. Some secondary-data projects may be exempt or outside human-subjects research rules; others require review and consent or an authorized waiver.

Research datasets disclosed as de-identified must meet an appropriate documented standard, such as HIPAA Safe Harbor or HIPAA Expert Determination, together with any additional applicable legal requirements. We do not represent that our existing pseudonymous database already meets those standards, or that use of a HIPAA method alone establishes anonymity under every other law. Researchers receive only the data permitted for the project and remain bound by our restrictions on re-identification and unauthorized reuse.

We do not require a new opt-in for each secondary research project when the governing law, institutional determination, applicable platform rules, and existing permissions allow the use without further consent. We obtain additional consent or authorization when required and not lawfully waived. Research use of existing data does not itself recruit you, authorize contact, enroll you in an intervention, or permit identifiable linkage to clinical records; those activities need their own applicable study process. See Terms of Service section 8.4.

Optional research identity linkage: if a future study offers this option, you may voluntarily provide your Community Data ID and identifying information through its disclosed enrollment process and give separate, explicit, study-specific consent to connect them. Stash already holds the ID with your contributions; your choice authorizes linking those records to the identity you provide. The study notice must explain the purpose, records, recipients, retention period, withdrawal process, and any lawful limits on removing information already used in research. Only the authorized connection and use are permitted. We will restrict access to the identity link and keep it separate from de-identified partner datasets; linked information is treated as identifiable research information. We will not make or permit this research link without your explicit choice, even if a secondary-research consent waiver is otherwise available. Providing an ID alone, accepting these Terms, or supplying an ID for support or deletion does not establish research consent. The study process must appropriately verify the request and record your authorization. Declining this option does not affect core supply management. This describes a possible future study process, not an identity-linking feature in the current apps.

A1C in studies and partner research. Stash may use contributed A1C history in studies of relationships between supply access, supply disruptions, device failures, recall exposure, insurance coverage, and glycemic outcomes over time. Within Stash, we may connect A1C readings to supply, incident, insurance, and other relevant community records through the same Community Data ID for those purposes. This connects contributions to one another; it does not authorize linking them to your name or other identifying information.

For those research purposes, we may share appropriately de-identified A1C research datasets and aggregate findings with future academic, clinical, nonprofit, public-health, industry, and manufacturer partners. These datasets may include properly de-identified individual A1C records as well as group statistics, subject to the source permissions, de-identification assessment, research requirements, and partner safeguards in this section. Any required additional consent or authorization must be obtained before the relevant use or disclosure; active study enrollment and research identity linkage follow their separate processes above.

The restriction on paid A1C products does not prohibit these authorized studies or research sharing with commercial organizations. We will not include A1C in a paid data product under a general community contribution permission without separately disclosing and obtaining any necessary specific authorization for that expanded use. Describing a paid data product as research does not avoid that requirement. Active study participation remains voluntary and separate from core supply management.

Earlier contributions are included where existing permissions cover the use. Our earlier Terms already described analysis of community contributions, aggregate sharing with researchers, manufacturers and public-health bodies, and the licenses supporting those purposes. The September 17, 2026 Terms also described the specific profile/A1C research purpose. We may continue those authorized activities using contributions made before this policy takes effect; older data do not require a fresh opt-in solely because of their age or because this policy restates an existing purpose. Terms of Service section 8.5 identifies the earlier provisions.

We apply the permission and any specific restrictions that governed each contribution. Earlier aggregate-sharing permission does not automatically extend to individual-record disclosure or every paid use. If a proposed use exceeds the applicable prior permission, we obtain any required additional authorization before including that data. Updating the policy does not remove withdrawal, deletion, or other applicable rights.

7. Sharing that you direct

Private Apple sync. On iOS, your records can synchronize through your own Apple account, including sensitive local fields that community contributions exclude. Apple processes that data under its applicable terms and privacy practices. Stash does not use your private CloudKit database for community or partner analysis.

Shared Stash on iOS. If enabled, Stash publishes an updated snapshot to Apple's public CloudKit database so someone with your sharing code can view it. It can include your chosen display name, supply names/categories, side-stash location labels, quantities, expiration groups, days remaining, active-supply dates/status, device-setup preferences, and limited recent supply history. Current snapshot creation omits raw notes and product serials. This is a user-directed, potentially identifiable disclosure, not de-identified community data. Treat the code as access to the snapshot. Turning sharing off or changing the code requests deletion of the old snapshot; if the network deletion fails, access may persist until retry succeeds. Recipients may retain copies they already made.

Files, reports, calendar, and external links. A backup or report you export can contain detailed supply and health information, including notes, serials, doses, placements, trips, A1C, insurance history, and sensor readings/tests, depending on export type. You choose its recipient or storage provider. Adding a reorder event to a calendar sends its title, category, date, and reminder information to the calendar you choose, which may synchronize through that provider. Opening a government, manufacturer, or other external page sends a normal web request to that service. These transfers are not anonymous merely because you initiate them, and the community deletion request does not remove the resulting copies.

8. Newsletter, support, and device permissions

Email updates. If you subscribe, your email address, app platform/source, and app version pass through Stash's Cloudflare-hosted email proxy to Loops, our email provider. This is identifiable information, kept separate from community IDs and used to send the updates you requested. Unsubscribe in the app or through the email's unsubscribe mechanism. Unsubscribing stops marketing; request erasure separately if you want any remaining contact or suppression records reviewed. Delivery, unsubscribe, and provider log records may be retained where needed to honor your choice or satisfy law.

Support and rights requests. Emailing us supplies your email address and whatever you send, such as a question, screenshot, Community Data ID, or attachment. We and our email provider use it to respond and resolve the request. This information is not de-identified at collection. Please share only what is needed. Support information is not a community or partner dataset.

Camera. Camera access supports on-device barcode recognition. Scanning does not upload camera frames to Stash. Decoded product digits may trigger the reference lookups in section 5.

Location and region. Onboarding requires a selected country and, for the US, state. This is your selection, not a GPS reading; it supports regional setup and contribution context. You can edit it in Settings. Where offered, an incident-report location action requests a one-time device location and reverse-geocodes it using the platform's location/geocoding service. That provider may process coordinates. Stash's community payload retains only country/state, not GPS coordinates, street address, postal code, or city. No continuous or background location monitoring is used for this feature.

Notifications, calendar, and files. The platform asks for applicable permission or lets you choose a destination when you request these features. Local reminders and widgets may display supply information on the device or lock screen. You control their visibility through app and system settings. Declining optional permissions leaves core supply management available.

9. Recipients, infrastructure, and international processing

Stash's authorized personnel can access backend contributions for the disclosed purposes. Service providers receive information needed to host, secure, analyze, or deliver the relevant feature: Supabase for community data; TelemetryDeck for analytics; Cloudflare and Loops for requested email; our email provider for support; and Apple, Google, or your selected backup, calendar, storage, or sharing provider for user-directed features. Government reference services receive their own lookup requests. They are not all performing the same role: some act for Stash and others provide independent services directly to you.

Network services necessarily process routing and connection information, which may include an IP address, request time, device/browser headers, error information, and URL/query details. Some providers retain operational or security logs. Omitting an identifier from a JSON payload does not mean the recipient receives no personal information. We use operational data to deliver and secure services, not to identify community contributors for advertising.

We may disclose information when legally required, to respond to valid legal process, or as necessary and lawful to protect rights or security. Any business transfer must preserve applicable privacy commitments; it is not permission to expand use of health information without the required authorization. We disclose only what is appropriate to the lawful purpose.

Stash and its providers can process information in the United States and other countries where they operate. Provider headquarters do not establish a particular database's hosting location. Where applicable law restricts transfers, we must use an appropriate transfer mechanism, such as a valid adequacy decision or approved contractual safeguards with any required additional measures. Contact us for information about the safeguards applicable to your data.

10. Retention and security

We retain information for the purposes described here only for as long as reasonably needed and legally permitted. We consider the need to study supply reliability over time, detect duplicate reports, maintain accurate community statistics, resolve support requests, respect withdrawal, and meet legal obligations. We do not treat pseudonymity as permission to keep personal data forever.

Deletion from active systems and expiry from backups or provider logs may occur on different schedules. Any retained backup copy must remain protected, unavailable for ordinary research or commercial use, and subject to deletion being reapplied if restored. Required downstream deletion and backup handling are not avoided by calling data de-identified.

We use transport encryption, restricted backend read access, and other technical and organizational measures appropriate to the information. Our contribution systems are not end-to-end encrypted against Stash: authorized operators can read server-held records. No system is perfectly secure. Where a security incident triggers notification duties, we will provide the notifications required by applicable law.

11. Deletion, access, correction, and other rights

Delete community data

Use Settings → Data Management → Delete My Community Data. The app sends its Community Data ID to a request queue. No Stash account or government identification is required for that in-app request. Requests are processed manually. A “Requested” message confirms receipt, not completed removal. We aim to complete ordinary community deletion requests within 30 days, and will meet any shorter applicable deadline. If GDPR applies, we respond without undue delay and within one calendar month; any lawful extension must be explained within that initial period.

The documented sweep covers incident reports, wear submissions, inventory snapshots, lot observations, barcode contributions, supply-use packages, transmitted profile information, A1C readings and insurance-type history, sensor-test summaries and paired readings, consent receipts, and associated install-linked operational counters. Related community caches and counts are refreshed and affected lot notices are reviewed. We retain the request's ID, timestamps, and limited processing status to document handling, subject to applicable retention limits.

The request does not switch Community Alerts off. To stop further contributions, turn it off on each device before submitting the request and keep it off. Rejoining, queued or new contributions, or later barcode contributions can recreate backend data. Either platform can have multiple devices contributing under the same ID, including Android devices restored from backup or transfer. The request covers the submitted ID, not every historical or separate ID automatically. Keep the ID available until your request is resolved; uninstalling first may remove your easiest way to locate older contributions.

The request does not erase local supplies, Apple private-cloud copies, Shared Stash snapshots, recipient exports, calendar events, newsletter records, support email, or analytics keyed by a different identifier. Use the relevant feature or contact us for help with those categories. Truly anonymous published statistics or validated public product facts may not be attributable to you and may remain; this does not exempt source records or outputs that are still personal data from deletion obligations.

Other requests and applicable rights

Email support@stashdiabetes.com if you cannot use the app or want access, a copy, correction, restriction, withdrawal, objection, or portability where applicable. State the category of information and, for community contributions, the Community Data ID if available. Do not send government identification unless we explain why additional verification is legally necessary. We use proportionate verification and ask only for information needed to locate records and protect them from unauthorized access or deletion.

The app can export your local data, but does not currently offer a self-service download of all server-held community records. That does not eliminate a right to request a copy. We cannot ordinarily find community contributions from a name or email alone; if additional information enables us to locate them, we will consider it. We will explain any inability to identify the relevant records or other lawful limitation rather than treating pseudonymous data as automatically exempt from rights.

Depending on your location, you can complain to a data-protection regulator, use an authorized agent where permitted, appeal a refused request, and exercise rights without unlawful discrimination. Contact the same email with “Privacy appeal” to request review. We will explain the decision and any available regulator or judicial route. Withdrawing consent does not affect the lawfulness of processing already carried out on that consent, and does not authorize new processing after withdrawal.

12. European, UK, Swiss, and US health-privacy information

For personal information subject to GDPR or analogous law, our legal bases must match the processing: consent for optional community contributions and email subscriptions; explicit consent for health-data processing where required; contract necessity for providing a feature you request; legitimate interests for proportionate service security and ordinary support where applicable; and legal obligation for applicable compliance duties. A legitimate interest alone does not supply a condition for processing special-category health data. Analytics containing health context requires its own assessment; this policy does not declare all such data anonymous or exempt.

We do not make solely automated decisions with legal or similarly significant effects about you. Local supply forecasts and community statistics do not determine treatment, insurance, credit, employment, or access to supplies. Where we rely on legitimate interests, you may object on grounds relating to your situation; direct-marketing objections will be honored.

Consumer health data. The categories in sections 2–8 may reveal diabetes status, treatment or device use, supply availability, reported health impacts, A1C, paired meter/sensor glucose readings, insurance coverage type, and related inferences. They can concern a child whose information an authorized caregiver contributes. Sources are your entries and selections, scans of supply packaging, records and settings generated through app use, and user-directed imports. Public FDA/manufacturer information is a separate reference source. Recipients and purposes are stated alongside each channel and in section 9. Any affiliated company receiving consumer health data must be specifically identified in this notice before such sharing begins.

We do not sell consumer health data or personal information that remains identifiable under applicable law, or share it for cross-context behavioral advertising. The prospective sale of qualifying anonymous aggregate outputs described in section 6 must satisfy the applicable statutory exclusions, not merely our preferred label. Where a law requires a separate consent to sharing or a specific sale authorization, general Terms acceptance cannot replace it.

Where applicable, you can request confirmation/access, withdrawal, deletion, the required information about recipients, and review of a denial using section 11. We will honor required deletion notifications to processors and recipients. You may complain to your state attorney general, including the Washington Attorney General where Washington law applies. This consumer-health disclosure must be made prominently accessible wherever required by law.

13. Children, changes, and contact

Stash is not directed to children under 13 as app users. Our Terms set a 13+ minimum for app use with appropriate adult authorization, and a 16+ minimum for people making community contributions or subscribing to newsletters, subject to local requirements. A caregiver may contribute information about a child under 16 when authorized to make that contribution and to provide any required consent on the child's behalf. This is different from a child using the app or consenting independently. The onboarding relationship question records whether you are a caregiver, and profile age ranges may describe a child, including a child under 13. Selecting a caregiver relationship does not itself verify parental responsibility or provide a separate health-data, research, or commercial-use consent.

Caregivers must have the authority required for the particular contribution and use, including any necessary authorization from a parent or legal guardian and any consent required from the child. The same field limits, sensor-sharing choice, partner safeguards, and withdrawal/deletion routes apply to contributions made on someone else's behalf. Authority to manage supplies is not unrestricted authority to disclose a child's health information. Any future identity-linked study must also obtain the applicable representative authorization and child consent or assent.

The app does not routinely collect a full date of birth or verify identity or parental responsibility. Do not infer that a profile age bucket verifies eligibility. A child or authorized representative can contact us using section 11. If you believe we received a child's information without legally required authorization, contact us so we can investigate and take appropriate action.

We will date policy changes and give appropriate notice of material changes. New purposes, partner disclosures, or study participation require fresh consent where applicable. A policy update does not retroactively remove earlier privacy promises.

Questions or requests: Stash Diabetes, Inc. — support@stashdiabetes.com.