InnieHub Privacy Policy

Controller: T&T Consulting Business, LLC ("T&T")
Service: InnieHub (inniehub.com and the InnieHub iOS application)

Version: 1.0
Last updated: 23 August 2026
Effective: 23 August 2026

Table of contents

1. Read this first
2. Who is responsible for your data
3. Scope of this policy
4. What we collect
5. Where the information comes from
6. Why we use it, and our legal basis
7. Health and wellbeing data, special category
8. Consumer health data (United States)
9. InnieCare, the AI support assistant
10. Crisis detection
11. InnieDate
12. Anonymous posting
13. Who we share information with
14. International transfers
15. Cookies and similar technologies
16. How long we keep things
17. Automated decisions
18. Your rights
19. How to exercise your rights
20. Region-specific information
21. Age and minors
22. How we protect information
23. If something goes wrong
24. Changes to this policy
25. How to contact us

1. Read this first

1.1 InnieHub is a community for adults living with agoraphobia, social anxiety and related experiences. That has one consequence you should understand before you read anything else:

The fact that you have an InnieHub account says something about your mental health. It does so before you write a single word. We treat your membership itself as sensitive information, and we have built the service so that it is not visible to anyone who does not need to see it.

1.2 Beyond that, the service holds material that is more sensitive still: your mood history, your exposure plans, your thought reframes, your social battery log, and the full text of your conversations with the InnieCare assistant. Section 7 explains exactly how we treat it and section 9 explains where it goes.

1.3 This policy is written to be read. Where a plain-language explanation would be clearer, we have used it. The Privacy Center in the application explains the same things more informally; if the two ever appear to disagree, this document governs.

1.4 We do not sell your personal information, we do not share it for cross-context behavioural advertising, we do not run advertising on the service, and we do not use your content to train artificial intelligence models. There is no ad network, no advertising identifier, no Meta Pixel and no Google Analytics anywhere in the product.

1.5 One thing we will not do in this document. We will not describe a protection we have not built. Where something is planned rather than live, this policy says so or does not mention it, and section 13.2.5 sets out a data flow that existed until August 2026 and no longer does.

2. Who is responsible for your data

2.1 The controller of your personal data is:

T&T Consulting Business, LLC
A limited liability company formed under the laws of the State of Florida
13575 58th Street North, Suite 200
Clearwater, FL 33760
United States
Privacy contact: privacy@inniehub.com

T&T operates the InnieHub service and holds the InnieHub brand. Where these documents say "we", "us" or "InnieHub", they mean T&T.

2.2 Data Protection Officer. We have not appointed a Data Protection Officer. We keep this under review and will appoint one before the scale of our processing of health data requires it under Article 37(1)(c) of the GDPR. Until then, all privacy questions, rights requests and complaints go to privacy@inniehub.com, which is monitored by the person responsible for privacy at T&T.

2.3 Why no representatives are named here. Article 27 of the GDPR, and Article 27 of the UK GDPR, require a controller outside those territories to designate a representative there. We do not offer the Services in the European Economic Area, the United Kingdom or Switzerland, and accounts cannot be created from them, so those obligations do not arise. Clause 4.8 of the Terms of Service sets out the territories.

2.4 What that means if you live in one of them. You can read this website, and this policy applies to the limited data that reading it involves. You cannot open an account. If you believe we hold personal data about you and you are in one of those territories, write to privacy@inniehub.com and we will answer, whatever the reason we hold it.

2.5 We are not using this to avoid anything. The obligations those laws impose are ones we intend to meet in full, including designating representatives, before we admit a single member from those territories. Being absent from a market is a decision we can defend. Being present in it without what it requires is not.

2.6 If this changes, we will designate the representatives first and name them in this section, and only then open the Services there.

2.7 Our development partner. The InnieHub software is built and maintained by Tudor Adriatic d.o.o., trading as iSkra, a company in Croatia related to T&T by common control. iSkra acts as our processor, and where it operates infrastructure on our behalf the providers behind it are our sub-processors. Section 13.2.2 names them. iSkra is not a separate controller of your data and has no purposes of its own for it.

3. Scope of this policy

3.1 This policy covers the InnieHub website, the InnieHub iOS application, and every feature within them, including InnieCare and InnieDate. One account, one policy.

3.2 It does not cover:

• Third-party sites you reach from links posted by members;
• What a listed Professional does with information you give them directly. When you book a session and then speak with a Professional, they are acting as an independent controller of what you tell them in that session. We are not. See section 13.5;
• Apple's handling of your purchase when you buy through the App Store. Apple is an independent controller for that transaction under its own privacy policy;
• Google's or Apple's handling of your account with them, when you sign in through either. What happens on their side is theirs, under their own policies. What we receive is in section 5.3.

3.3 This policy forms part of the Terms of Service. On questions of how personal data is handled, this policy prevails over the Terms.

4. What we collect

4.1.1 Why we keep a provider identifier. When you sign in with Google or Apple, we store the stable, meaningless identifier that provider gives us for you, alongside your account. We need it because an email address is not a reliable key: Apple lets you hide yours, and somebody who does that would otherwise be a new person to us every time. The identifier means nothing outside that provider's system and is not used for anything else.

4.1.2 What is no longer collected here. Earlier versions of the sign-up form asked whether you have anxiety and why you were joining. Those questions have been moved out of registration and into the wellbeing area, behind the consent in section 7, because they are answers about your health and asking for them at the door meant collecting Article 9 data before we had asked to. They are optional there, and section 4.2 covers them.

4.2 Health and wellbeing

This is the material that matters most, and we set it out item by item so there is no ambiguity:

• your health profile, including mood history and streak counts;
• your exposure plans and their progress;
• your recorded small wins;
• your thought reframes;
• your practice sessions;
• your social battery entries;
• the full transcript of your conversations with the InnieCare assistant;
• whether you tell us you have anxiety, and your free-text reasons for being here, if you choose to answer.

None of this is shown to other members. None of it is sent to our analytics provider. None of it appears in any log. Section 7 sets out how we treat it and section 9 sets out the single third party that ever sees part of it.

4.3 What you post in the community

Posts, comments, likes and reactions, group memberships, event attendance, forum topics and replies, stories (which expire on their own), direct messages, course enrolments and quiz attempts.

The member marketplace is switched off, so nothing is collected through it. If it is ever turned on we will say so before it opens.

4.4 InnieDate

If, and only if, you opt in: your InnieDate profile, your photos, your preferences including who you are interested in, your likes, your matches, your age filter, and, if you use it, a photo verification selfie. See section 11.

4.5 Voice and video calls

Call media passes through our call infrastructure provider in order to reach the other participant. We do not record calls and we do not store call media.

4.6 Technical, and what that actually means here

This section is longer than it would be elsewhere, because the honest answer has three parts rather than one.

a) There is no request log. Nothing in InnieHub writes an access log, no table, no file, no row per request carrying your IP address and what you asked for. That is unusual and it is deliberate.

b) There is a diagnostic log, and you should know what can appear in it. The application writes diagnostic lines to standard output when something goes wrong or when a scheduled job runs, the ordinary output of a running program. Our hosting provider retains that output for a limited period so that failures can be investigated.

Those lines are about events, not about people, and they are never a record of what you did on the service.

c) One IP address is stored, in one place. Alongside a consent decision, as evidence of when and from where it was given. It is removed after 90 days, leaving the consent record itself intact. Our analytics provider does not retain IP addresses at all. If you were expecting a longer list here, there is not one.

Also collected: your device push token if you enable notifications; an approximate last-active timestamp; error reports when something breaks; and two product analytics events, a post being created, and an event RSVP changing, plus page views and web performance measurements, none of which load before you consent. See section 15.

4.7 Payments

• Web purchases: you enter your card details on our payment provider's own hosted page. Card numbers never reach our servers and we never see them. We receive a record that a subscription started, changed or ended, and whether you waived your withdrawal right at checkout.
• iOS purchases: Apple handles the transaction. We match it to your account through a random identifier we generate, which means nothing outside our system.

4.8 Support and correspondence

What you write to us at any of our published addresses, and our replies. Email sent to us is received and stored by our email host, named in section 13.2.1, including anything you send to appeals@, safety@ or privacy@, which by their nature can contain sensitive information about you. If you would rather not send health information by email, the appeal route in the Terms works in the application and does not require you to write to us.

4.9 What we never collect

No advertising identifiers. No precise or device location, the location field is free text you type, and nothing reads your GPS. No contacts, no calendar, no photo library beyond the images you deliberately upload. No biometric data, the optional app lock uses your device's own Face ID or passcode, and your device never shares the biometric with us or with anyone. No browsing activity outside InnieHub.

5. Where the information comes from

5.1 From you, everything in sections 4.1 to 4.5 and 4.8.

5.2 From your device automatically, the items in section 4.6.

5.3 From your sign-in provider, if you use one.

• Google: your name, email address and profile picture, through the standard OAuth exchange. Your profile picture is copied once to our own storage and the Google address is not kept, see 13.2.4.
• Apple: your name and either your email address or a forwarding address, depending on what you chose, plus the stable identifier in 4.1.1.

We receive no password and no access to your account with either of them beyond that exchange.

5.3.1 If you used Apple's "Hide My Email". We receive a forwarding address ending in privaterelay.appleid.com rather than your own. We treat it exactly as we would any other address. Two consequences worth knowing: it is the address every message from us goes to, and you can switch it off in your Apple account at any time without us being able to tell. From that moment our messages stop arriving, silently on both sides. Clause 5.2.1 of the Terms explains what else follows from this.

5.4 From Apple and from our payment provider, the subscription records in section 4.7.

5.5 From other members, if someone reports you, the report and its reason become part of the record on your account. We never tell you who reported you.

6. Why we use it, and our legal basis

The table below is written in the language of the GDPR, and we should explain why, given that clause 4.8 of the Terms of Service means we do not offer the Services in the European Economic Area, the United Kingdom or Switzerland.

We use that vocabulary because it is the most demanding framework we know of and because it forces a discipline the others do not: naming a lawful basis for each purpose, one at a time, in writing, before the processing starts. We hold ourselves to what this table says wherever you live, including in places whose own law would ask less of us. If you are in Brazil, Mexico, Chile or another place with equivalent law, the correspondences to your own statute are in section 20. If you are somewhere with no such statute, read the table as a plain statement of what we do and why.

6.1 Our legitimate interests, stated plainly. Where we rely on legitimate interests, we have weighed our interest against your rights and concluded that a member of a mental health community would expect the processing in question. You may object to any of it under section 18, and where you do we will stop unless we have compelling grounds that override your objection. You can ask for our balancing assessment.

6.2 We do not use your data for advertising, profiling for marketing, or scoring you in any way.

7. Health and wellbeing data, special category

7.1 Our position

We treat everything in section 4.2 and the "interested in" preference in InnieDate as data concerning health or sexual orientation under Article 9 of the GDPR and UK GDPR, and as sensitive personal information under the California Consumer Privacy Act as amended. We have taken that position deliberately, because the alternative reading would put the burden of a doubt on you rather than on us.

7.2 Our Article 9 condition is your explicit consent

Article 9(2)(a). And because everything in this section depends on that consent being real, here is exactly how we ask for it.

7.2.1 It is not bundled into anything.

Accepting the Terms of Service is a contract. It is not consent to process your health data, and we do not treat it as such. You will not find a box at registration that mixes the two, and there is no combined "I agree to everything" anywhere in the product.

We are explaining the mechanism rather than just asserting the outcome, because bundling is the specific failure Article 7(2) is written against, and because here it would also simply be untrue. Somebody may well want the community and not the mood tracker.

7.2.2 We ask at the point of first use, once per area.

Each is a separate screen, in plain language, describing that specific processing. Each is refusable, and refusing costs you nothing else: you can use the whole community, indefinitely, having consented to none of the three.

7.2.3 Asking at first use rather than at registration is a deliberate choice, and it is the more protective one. At registration you would be consenting to an abstraction, most members never open InnieDate, and being asked about it at the door produces a tick rather than a decision. At first use you are consenting to something you are about to do, having just read what it involves. The record we keep is correspondingly worth more: it carries the version of the notice that was actually in front of you.

7.2.4 What the record holds. Each consent is stored against your account with the date, the version of the document you saw, whether you were on the web or in the application, and, for 90 days, the IP address it came from. Withdrawing stamps the record rather than deleting it, because the history is the evidence. You can see all of it, including everything you have ever withdrawn, in your settings.

7.2.5 A new version does not silently carry over. If we materially change one of these notices, the consent you gave to the previous version stops satisfying the gate and we ask you again. Your old record stays exactly where it is, still true about the day you gave it.

7.3 Withdrawing, and what actually happens

You can withdraw any of the three at any time, from your settings, in as few steps as it took to give.

The feature stops. Not "we stop using it for new purposes", the gate closes and that part of the product no longer works for you. That is the same mechanism that let you in, running the other way.

Your existing entries stay. We want to be precise about this rather than comfortable. Withdrawing consent stops the processing; it does not, by itself, delete what you already wrote. Your mood history, your exposure plans and your InnieCare conversations remain in your account, unreachable by the feature you switched off, until you delete them, individually, or by deleting your account under section 16.2. We do not delete them for you, because a withdrawal is not obviously a deletion request and guessing wrong destroys something irreplaceable.

If you want both, do both: export your data first if you want a copy (section 18), then withdraw, then delete. Or simply delete your account, which does all of it.

Withdrawing does not close your account and does not affect your standing in the community.

7.4 We use it for one thing

Your wellbeing data exists to give the tools back to you. We do not analyse it to profile you, do not use it to target anything, do not use it to train models, do not sell it, do not share it with other members, and do not send it to our analytics provider. The only third parties that ever touch it are our hosting provider, which stores it as our processor, and, for InnieCare conversations only, the AI provider described in section 9.

7.5 We are not a healthcare provider

InnieHub is not a covered entity or business associate under HIPAA, this is not a medical record, and no clinician-patient relationship exists between you and us. That is a statement about what we are, not a reduction of the protection we give this data.

8. Consumer health data (United States)

8.1 This section is the consumer health data notice required by Washington State's My Health My Data Act, and applies equivalently to residents of Nevada and of any other state with comparable law. It is also published on its own page at /consumer-health-data-privacy, with its own link from our homepage, as those statutes require.

8.2 What consumer health data we collect. The categories in section 4.2. In the terms these statutes use, that includes information about your mental health condition, your efforts to manage a mental health condition, and, because of what InnieHub is, the bare fact that you hold an account.

8.3 Where it comes from. You. Every item is something you entered yourself. We do not buy health data, we do not infer it from your browsing, and we do not obtain it from data brokers or from any other source. The single inference we make is the crisis signal in section 10, and it is made from what you wrote to the assistant.

8.4 How we use it. To provide the wellbeing tools and the InnieCare assistant back to you, and to show you crisis resources if a safety signal is raised. Nothing else.

8.5 Who we share it with. Our hosting provider, which stores it on our behalf, and, for InnieCare conversation content only, our AI provider, in order to generate a reply. Both are contractually bound to use it only on our instructions. See section 13.

8.6 We do not sell consumer health data. We have never sold it and we do not intend to. If that ever changed, we would obtain your separate, signed authorisation first, as those statutes require, and we would not make it a condition of using the service.

8.7 Your rights. You may confirm whether we hold consumer health data about you, access it, obtain a list of everyone we shared it with, and have it deleted. Deletion reaches the live system immediately and our encrypted backups within the cycle described in section 16.5; a backup restored in the meantime is re-processed against pending deletions so that nothing comes back. To exercise any of these, use section 19. We will not deny you the service, charge you differently or degrade your experience because you exercised a right.

8.8 Employees and contractors may access consumer health data only where it is necessary for the purpose in 8.4 or for a safety or legal reason, access is restricted accordingly, and every access is logged, see section 22.8.

9. InnieCare, the AI support assistant

9.1 What happens when you write to it. The InnieCare assistant is powered by a general-purpose artificial intelligence model provided by Anthropic, PBC, a company in the United States. When you send a message, the recent messages of that conversation are transmitted to Anthropic so that a reply can be generated. The reply comes back and is stored in your conversation.

9.2 This is the most sensitive processing we do, and we state it in the plainest terms we can: the things you tell the assistant about your mental health leave our systems and are processed by another company in order to produce an answer.

9.3 What Anthropic receives. The recent messages of the conversation, and a catalogue of public InnieHub groups, events and listed professionals so that the assistant can point you at real things inside the service. It does not receive your name, your username, your email address, your other wellbeing records, your community activity or your InnieDate data.

9.4 What Anthropic does with it. Anthropic acts as our processor and is bound by our agreement with them. We will not describe Anthropic's retention or training practices in this policy until we have confirmed them against our contract, because a privacy policy that overstates a third party's commitments is worse than one that says less.

9.5 Your conversations on our side. Stored against your account, never shown to other members, never sent to our analytics provider, included in your data export, and deleted when your account is deleted.

9.6 Consent. Using the assistant requires the explicit consent described in section 7.2, plus your acknowledgement of the AI Assistant Disclosure. You can use every other part of InnieHub without ever writing to it.

9.7 When nothing is sent at all. If you exceed the number of AI-generated replies included in your membership tier, or if the service reaches its overall monthly limit on model use, the assistant falls back to a simple non-AI responder. In that mode nothing whatever is sent to Anthropic, not the message, not context, not a classification. The crisis check in section 10 still runs, because it runs on our side and always has.

9.8 The assistant can be wrong. It is software, not a clinician. It does not diagnose or treat, and it may produce statements that are inaccurate or invented. This is set out in full in clause 13 of the Terms of Service and in the AI Assistant Disclosure.

9.9 Generative AI is used nowhere else in InnieHub. It does not write posts, moderate content, rank your feed, or make decisions about your account.

10. Crisis detection

10.1 What we do. Messages you send to the InnieCare assistant are checked automatically for indications of suicidal ideation or self-harm. The check is deterministic, it looks for defined patterns, in English and Spanish, and it runs before any message is sent to the AI provider, on our own servers. The AI model may also raise the same signal itself; either is enough. The check runs on every membership tier, is never limited by your usage allowance, and is never behind payment.

10.2 What happens when a signal is raised.

a) You are shown crisis helplines, held inside the application, for the country you are set to. In the iOS application they work with no network connection and without being signed in; on the web the page has to have loaded.
b) A notification is sent to the people described in 10.3, naming you and stating that a signal was raised. It does not contain your conversation, a quotation from it, or the words that triggered it. Repeat notifications about the same person are suppressed for fifteen minutes.

10.3 Who receives it, precisely.

Administrators, always. And a community Moderator only while all three of these are true: they hold the moderator role, they have a current acceptance of the Moderator Terms at the version in force, and they have not paused the role. If any of the three stops being true, the notifications stop reaching them, without anyone having to remember to remove them from a list.

We want to be clear about who these people are. Moderators are members of this community whom we invited into the role, not employees and not clinicians. That is why the Moderator Terms have to be accepted before the role does anything at all, and why a paused moderator receives nothing: the crisis notifications are the heaviest thing the role carries, and needing to stop is the likeliest reason someone pauses.

10.4 What this is in data protection terms. A crisis signal is an inference about your health, made automatically, and shared internally with a small number of named people. We rely on your explicit consent under Article 9(2)(a), given as part of section 7.2, and, where a person appears physically or legally incapable of giving consent, on Article 9(2)(c), vital interests.

10.5 What it never does. A crisis signal creates no clinical record and no risk score. It writes nothing else anywhere: no report, no moderation record, no strike, no mark on your account, and no change to your access or standing. Reaching for help is not an infraction, and a system that filed it next to the infractions would eventually treat it as one.

10.6 This is not a clinical assessment. It is a pattern check. It will miss real crises and it will flag things that are not crises.

10.7 We are not an emergency service. We cannot dispatch help and we do not monitor the service in real time. If you are in danger, contact your local emergency number.

10.8 If you would rather not be checked. The check is inseparable from the assistant: it is not possible to use the InnieCare assistant with it switched off, and we are not willing to offer that. You can use everything else in InnieHub without using the assistant.

11. InnieDate

11.1 It is entirely opt-in. You are not in InnieDate unless you join it, and your participation is not visible anywhere else in the service.

11.2 Sexual orientation. Your "interested in" preference can reveal your sexual orientation, which is special category data under Article 9 in its own right. We ask for explicit consent before you create an InnieDate profile, separately from any other consent, and you can withdraw it by leaving InnieDate.

11.3 What other members can see before a mutual match. An alias, an age, and what you wrote in your profile. Your username, your full name and your city are withheld by default, so there is no route from an InnieDate card back to your main account.

11.3.1 That protection is a setting, and it is on when you join. If you deliberately turn it off, your username and city become visible before a match, which also makes your InnieDate card traceable to your main account, and therefore to your membership of this community. We say it here because the consequence is a disclosure about your health, and that is not something anyone should discover by accident.

11.4 Your photos. Stored as authenticated assets and delivered through signed URLs, with blurring applied on our server. The unblurred image is not delivered to any device until there is a mutual match. Blurring is not a visual effect applied in the app over a full-quality image; the full-quality image is not sent. We test this by trying to defeat it.

11.5 Photo verification, if you use it. You take a selfie with the camera, not from your library, a person at T&T compares it with your profile photos, and the selfie is deleted whatever the outcome. If nobody has reviewed it within 30 days it is deleted anyway and the request stays open. We do not ask for identity documents and do not want them.

11.6 Likes. A one-directional like is never revealed to the person who received it.

11.7 Unmatching. Either party can unmatch, which re-blurs photos and removes each of you from the other's deck.

11.8 Leaving. Leaving InnieDate deletes your InnieDate photos from storage, not merely from view.

11.9 No third party receives InnieDate data, other than our hosting and media storage providers, which store it on our behalf.

11.10 What we cannot control. Once you match with someone, what they do with what they see is up to them. They can screenshot. Share only what you are willing for a stranger to keep.

12. Anonymous posting

12.1 Some posts and comments can be marked anonymous. This hides your identity from other members.

12.2 It does not hide your identity from us. Anonymous content remains linked to your account in our database, so that we can enforce the Terms, respond to reports, action copyright notices and comply with legal process.

12.3 We say this plainly because "anonymous" is a word that invites a stronger assumption than the feature supports. Do not post something anonymously that you would not be willing to have attributed to you if a court required it.

13. Who we share information with

13.1 We do not sell personal information and we do not share it for cross-context behavioural advertising.

13.2 Two different kinds of third party, and the difference matters to you.

Some companies receive data because we send it to them from our servers. We choose them, we contract with them, and we can see exactly what goes.

Others are contacted by your own browser or device, because a page you opened includes something they host, or because you were sent to them. Those companies see your IP address directly, and no contract of ours can prevent that, only removing, proxying or gating the feature can.

We list them separately because the second kind is the one most privacy policies bury.

13.2.1 Providers our servers send data to

Each processes data on our instructions, under contract, and for no purpose of its own.

13.2.2 Sub-processors engaged through our development partner

iSkra (section 2.7) operates the infrastructure accounts and the operational monitoring on our behalf. The following are our sub-processors through it:

iSkra is bound by a data processing agreement under Article 28, which requires it to impose the same obligations on each of these, keeps them behind authentication, and makes iSkra fully liable to us for their performance. Diagnostic output no longer carries anything that identifies you, see 4.6(b).

13.2.3 Domain infrastructure, which is not a processor

DreamHost is our domain registrar and operates our authoritative DNS. We name it for completeness and then say why it is not in the tables above: an authoritative name server answers queries from recursive resolvers, your internet provider's, or Google's, or Cloudflare's, and not from you. The address it sees is the resolver's, not yours, and it receives nothing else about you at all. Calling it a processor of your data would be tidier and it would not be true.

13.2.4 Third parties your own browser contacts

That is the entire list, established by running the application and watching what it contacts, and then confirmed by reading the code, not by asking anyone what they believed was there.

13.2.5 A data flow that existed until August 2026, and does not now

Until August 2026, default profile pictures were generated by a third-party service, and the member's name was contained in the image address. Every screen showing such an avatar caused the viewer's browser to contact that company and hand it the viewer's IP address together with the name of the person being looked at. No cookie choice governed it, because an image is not a cookie. Separately, a member who signed in with Google had their Google-hosted profile picture shown from Google's own servers.

Both are gone. Initials are now drawn by the interface itself, Google profile pictures are copied once to our own storage on first sign-in, and the stored third-party addresses have been cleared from every account. No avatar in InnieHub is served by anyone but us.

We mention it because it happened before this service had a single member outside our own team. Nobody else's data reached either company, and we would rather record a flow that once existed than quietly present the current list as though it had always been the list.

13.3 How we know. The tables above were established by running the application and recording every host it contacts, then confirming it against the source code, rather than by asking anyone what they believed was there. We intend to keep checking them the same way.

13.4 The things your browser contacts, in detail.

13.4.1 Giphy, for the images themselves. GIF search goes through our servers, so Giphy does not learn your IP address or what you typed. But the GIF image is loaded from Giphy's servers, so displaying a GIF reveals your IP address to Giphy. It reveals nothing else: no name, no account, and no idea what was searched for. It is the same kind of exposure as any content delivery network. We have chosen to disclose it rather than pay to proxy every image or remove a feature people use to say things they find hard to write.

13.4.2 YouTube and Vimeo, for lesson videos, and you decide when. Some course lessons contain a video hosted by YouTube or Vimeo.

Opening the lesson contacts neither of them. You see a still image served from our own storage, with a play button. Nothing is requested from any video platform, and no cookie of theirs is written, until you press it.

When you do press play, that platform loads the player and sees your IP address, as any video host would. We use the privacy-enhanced embed in both cases. It receives no name, no account and nothing else about you, only that a device at your address is watching that video.

So a lesson you open and read costs you nothing, and a video you choose to watch costs exactly what watching a video costs. That seemed the right place to put the choice.

13.4.3 Google and Apple, when you sign in with them. Pressing "Continue with Google" or "Continue with Apple" sends your browser to that company's own page. That is how the sign-in works and there is no version of it that does not.

We are listing it because of what it means here specifically. The provider sees your IP address and the fact that you are signing in to InnieHub, and on this service, that second fact is itself information about your mental health. If that matters to you, registering with an email address and a password avoids it entirely, and everything in InnieHub works identically either way.

13.5 Listed Professionals. If you book a session, the Professional sees the information necessary to hold it. What you then tell them in the session is between you and them. They act as an independent controller of it and their own privacy practices apply, ask them for theirs. We do not receive, store or have access to the content of your session.

13.6 Other members. What you post is shared with whoever you posted it to. That is the feature, not a disclosure by us.

13.7 Legal disclosures. We may disclose information where we are legally required to, where it is necessary to establish or defend a legal claim, or where we believe in good faith that it is necessary to prevent death or serious harm. Clause 10.7 of the Terms describes the one situation in which we contact authorities on our own initiative. Where we are permitted to tell you about a request, we will.

13.8 Corporate transactions. If the operation of InnieHub is transferred, including a future transfer from T&T to another entity in the same group, your data moves with it, subject to this policy as it then stands, and we will tell you before it happens.

14. International transfers

14.1 All of the providers in sections 13.2.1 and 13.2.2 are established or headquartered in the United States, and the accounts we hold with them are in their United States regions, including our email host, whose data centre for our account is in the United States. Wherever you live, your data is transferred to and stored in the United States, and there is no version of this service in which it is not.

14.2 The safeguards behind those transfers. Our agreements with these providers incorporate the European Commission's Standard Contractual Clauses (Decision 2021/914) where the provider offers them, together with the supplementary measures in 14.3.

We keep them in place even though clause 4.8 of the Terms means no member is in the European Economic Area, the United Kingdom or Switzerland, and no European transfer rules therefore apply to us. They are a floor we chose rather than one imposed on us. Removing them because nobody can currently make us keep them would be an odd thing to do to a set of protections that cost us nothing and would have to be rebuilt the day we open those markets.

14.3 Supplementary measures. Data is encrypted in transit and at rest; access is restricted to what each provider needs for its function; and each provider is contractually required to notify us of any government access request it is permitted to disclose.

14.4 Our development partner is in Croatia. The systems it works on are the United States systems in 14.1, so what happens is that a person in the European Union reaches into infrastructure in the United States rather than data being copied to Croatia to sit there. Its access is governed by the data processing agreement described in section 13.2.2, and it is bound by Croatian and European data protection law in its own right, which is a protection for you rather than a complication.

14.5 You may request a copy of the transfer safeguards in place by writing to privacy@inniehub.com.

15. Cookies and similar technologies

15.1 When you first visit, you are asked to choose. Three categories:

15.2 Statistical cookies do not load until you consent. Our analytics provider is not initialised at all before you agree. We took this approach deliberately: loading a measurement tool and then disabling it is not enough, because loading it has already opened a connection and written cookies.

15.2.1 And withdrawing actually removes them. When you withdraw statistical consent we clear the analytics identifiers from your device rather than merely stopping the sending. We mention it because the obvious implementation does not do this, the provider's own opt-out call leaves the identifiers in place, so somebody who withdrew would go on carrying the cookie that was set under the consent they just took back.

15.3 You can change your mind at any time. Reopen the choice from your settings. Your decision is stored both on your device and against your account, so it follows you between devices. We also honour the Global Privacy Control signal where your browser sends one, and where your signal and your stored choice disagree, the more protective of the two wins.

15.4 No advertising cookies exist in InnieHub. None. There is nothing in the product from any ad network.

15.5 One deviation we are telling you about rather than hiding. Error reports are currently sent to our error monitoring provider before you have made a cookie choice, so that a failure occurring during sign-up can be diagnosed. We consider this necessary to keep the service working and rely on our legitimate interests. These reports contain technical information about the failure, session replay is switched off, and they are not used to measure or profile you.

15.6 The cookies of a sign-in exchange, and one thing that looks alarming and is not. When you sign in with Google or Apple, four short-lived first-party cookies are written to carry that exchange safely. They are httpOnly, they carry no information about you, and three of them expire in fifteen minutes.

Four of them are set with SameSite=None, which normally deserves suspicion, so here is why. Apple returns the result of a sign-in as a cross-site form submission rather than a normal navigation, and browsers do not attach SameSite=Lax cookies to those. Without the change, the security check that protects the exchange could not complete and nobody could sign in with Apple at all. The session cookie itself was not touched and remains SameSite=Lax, that is the one that protects your open session.

15.7 The Cookie Policy lists each individual cookie, its purpose and its lifetime.

16. How long we keep things

16.1 While your account is open, we keep what you have given us so that the service can give it back to you. Stories expire on their own.

16.2 When you delete your account. Your account is hidden immediately and a 30-day grace period begins. Signing back in during that window cancels the deletion, no form and no email, just come back. After it expires, a scheduled process removes your account and its content, cascading to your posts, comments, messages you sent, wellbeing records, InnieCare conversations, your InnieDate profile and photos, and any photo-verification record. The files are deleted before the rows that point at them, deliberately: doing it the other way round destroys the only reference to a stored file and leaves it there for good.

16.2.1 Files go before rows. We delete your stored images and documents first, and the database records second. Doing it the other way round destroys the only pointers to those files, leaving them in place and unfindable, which is not deletion whatever the database says. If a file cannot be deleted on a given run, your account is left intact and retried, because an account erased from the database while its photographs survive is the one outcome that cannot be repaired.

16.3 What we keep after deletion, and why.

16.4 The schedule above is enforced automatically, by a process that runs every fifteen minutes rather than by anyone remembering. Consent records are the deliberate exception, for the reason in the table.

16.5 Backups. Data may persist in encrypted backups for up to 35 days after deletion from the live system, after which it is overwritten. A backup restored within that window is re-processed against pending deletions, so a restore does not bring back an account that asked to go.

17. Automated decisions

17.1 Two processes in InnieHub reach a result about you without a person deciding. We list both, and then the one people assume is a third and is not.

17.1.1 Community roles are not in that table, and the distinction matters. Reaching the activity thresholds grants InniePlus automatically, which is a benefit and adds no power over anybody. Reaching the InnieMaster thresholds grants nothing: it makes you eligible, an administrator decides whether to offer it, and the role does nothing at all until you have accepted the Moderator Terms. No algorithm gives anyone power over another member's account.

17.2 Article 22. Where a decision produces legal effects or similarly significantly affects you, the age gate and the precautionary suspension both may, you have the right to obtain human intervention, to express your point of view, and to contest the decision. Use appeals@inniehub.com or the appeal route in the notification we send you. No appeal is ever decided automatically; there is deliberately no code path that resolves one.

17.3 The logic involved. The age gate compares your stated date of birth against today's date. The suspension counts live reports. Role eligibility counts days, posts, interactions, connections, events and groups created against fixed numbers published in clause 12 of the Terms. There is no scoring model, no machine learning and no profiling in any of them.

17.4 We do not profile you for marketing, for pricing, for content ranking or for any assessment of your personality, health or behaviour.

18. Your rights

18.1 Wherever you are, you can:

• Access, get a copy of what we hold. You can generate a complete export yourself, at any time, from your settings. It is a single file including your wellbeing records and your InnieCare conversations;
• Correct, fix anything inaccurate. The one exception is your date of birth, which is permanent by design; if it is wrong, contact us and we will treat it as an appeal;
• Delete, remove your account and its content, subject to section 16.3;
• Object, to processing based on our legitimate interests;
• Restrict, ask us to pause processing while a dispute is resolved;
• Portability, receive your data in a structured, machine-readable format. The export is that format;
• Withdraw consent, at any time, for anything we do on the basis of consent, including everything in section 7. Section 7.3 says exactly what happens when you do;
• Complain, to us first, and to your supervisory authority in any event;
• Not be discriminated against for exercising any of these. Your access, your price and your standing do not change.

18.2 The export, and one judgement we made. Your export excludes messages other people sent to you. We took the view that another person's words are their personal data as much as yours, and that a right of access to your own data does not extend to a copy of everything anyone ever wrote to you. Your own sent messages are included. If you disagree with where we drew that line, tell us, we will look at it again.

18.3 What we cannot delete on request. The items in section 16.3, for as long as they are stated to be retained.

19. How to exercise your rights

19.1 In the application: export your data, see and change every consent you have given, and request deletion, all from your settings. These are the fastest routes and none of them requires you to write to anyone.

19.2 By email: privacy@inniehub.com.

19.3 Verification. We verify a request by confirming control of the account's email address. For a request that would disclose sensitive data to someone who might not be you, we may ask for more. We will never ask you for a government ID to exercise a data right.

19.3.1 One place where we do ask for identity, and it is not this one. A professional applying to be listed in the InnieCare directory is asked for a photo ID, so that the name on it can be checked against the name on the licence they are claiming. It is looked at once and deleted, what is kept is the record that the check happened, who made it and when, and any unreviewed document is deleted after 30 days. That is section 13.1 and it has nothing to do with your rights under this section.

19.4 Timing. We respond within 30 days, and within one month for requests under the GDPR or UK GDPR, extendable by two further months for complex requests, in which case we will tell you within the first month and explain why.

19.5 Cost. Free. We may charge a reasonable fee, or refuse, only where a request is manifestly unfounded or excessive, and we will explain if we do.

19.6 Authorised agents. Where the law allows you to use an agent, we will accept a request from one on proof of your written authorisation.

19.7 Complaints. Complain to us at privacy@inniehub.com first if you are willing. You do not have to. You may complain directly to:

• Brazil, the Autoridade Nacional de Proteção de Dados;
• Mexico, the competent federal data protection authority;
• California, the California Privacy Protection Agency, or the Attorney General;
• Chile, the Agencia de Protección de Datos Personales, from the date Law 21.719 is in force;
• Washington State, the Attorney General, under the My Health My Data Act, which also gives you a private right of action.

19.7.1 If you are in the European Economic Area, the United Kingdom or Switzerland, you cannot hold an account with us, but you may still have written to us or read this site, and you may still complain to your own supervisory authority. We have not designated a lead supervisory authority and we do not claim that any of them has jurisdiction over us. We will answer your complaint on its substance either way, at privacy@inniehub.com, because whether an authority can compel us is a different question from whether you are owed an answer.

20. Region-specific information

20.1 European Economic Area, United Kingdom and Switzerland

We do not offer the Services in these territories and accounts cannot be created from them. Clause 4.8 of the Terms of Service lists every country concerned, section 2.3 explains why no representative is designated, and section 2.5 states plainly that this is a decision about market entry rather than a way of avoiding what those laws require.

What this section does not say is that you have no rights. If you are in one of these territories and we hold personal data about you, from correspondence, from a report someone made, or from anything else, sections 18 and 19 apply to you exactly as they apply to everyone else, and section 19.7.1 is your route to complain. We answer on the substance without first arguing about jurisdiction.

If we open these markets, section 2.6 commits us to designating the Article 27 representatives before a single account is created, and to naming them in section 2 before that.

20.2 California

Categories of personal information we have collected in the last 12 months, using the CCPA's own labels: identifiers; personal information under Cal. Civ. Code § 1798.80(e); characteristics of protected classifications (age, gender, and, where you tell us, mental health condition); commercial information (subscription records); internet and network activity (the limited items in section 4.6); audio and visual information (media you upload; call media in transit only); professional information (only if a Professional's listing describes it); sensitive personal information, being your account credentials and information concerning your mental health and sexual orientation; and inferences, none, except the crisis signal in section 10.

Sources, purposes and recipients are in sections 5, 6 and 13.

Sale and sharing: we do not sell personal information and we do not share it for cross-context behavioural advertising. We have not done so in the preceding 12 months, and we do not do so with the personal information of minors under 16, because we have no members under 18.

Use of sensitive personal information: limited to providing the service you asked for, as described in section 7.4. We do not use it to infer characteristics about you. You therefore have nothing to limit under § 1798.121, but you may withdraw the consents in section 7 at any time, which is a stronger remedy.

Your rights: to know, access, delete, correct, opt out of sale/sharing (not applicable), limit use of sensitive information (see above), and not to be retaliated against. Exercise them under section 19.

Shine the Light: we do not disclose personal information to third parties for their own direct marketing.

20.3 Washington, Nevada and other consumer-health states

See section 8, which is your notice under those statutes and which is also published as a separate document at /consumer-health-data-privacy.

20.4 Other US states

Where you live in a state with a comprehensive privacy law, including Colorado, Connecticut, Virginia, Utah, Texas, Oregon, Montana and others, you have rights to access, correct, delete, obtain a portable copy, and opt out of targeted advertising, sale and profiling with legal effects. We conduct none of those three activities. Exercise your rights under section 19. Where your state provides an appeal from our decision on a request, you may appeal to privacy@inniehub.com and, if we refuse, complain to your Attorney General.

20.5 Brazil (LGPD)

You have the rights in Article 18 of the LGPD, including confirmation, access, correction, anonymisation or deletion of unnecessary data, portability, information about sharing, and revocation of consent. Our legal bases correspond to Article 7 and, for health data, Article 11(I), your specific and highlighted consent, which is what section 7.2 collects. Exercise your rights under section 19.

20.6 Mexico (LFPDPPP)

You have ARCO rights, access, rectification, cancellation and opposition, and may revoke consent at any time. Health data is sensitive personal data requiring your express and written consent, which for these purposes is given electronically through the consent in section 7.2.

20.7 Chile

Law 21.719 takes effect on 1 December 2026 and reaches us because it applies to anyone processing the data of people in Chile, wherever the processor is. It treats data concerning health and data concerning sexual life or sexual orientation as sensitive, which is both of the categories this service is built around.

We are naming it here before it is in force rather than afterwards. From that date you may confirm what we hold, access it, have it corrected, have it deleted, oppose processing, obtain a portable copy, and complain to the Agencia de Protección de Datos Personales. Our condition for processing sensitive data is the same one section 7.2 already collects: your explicit, separate, refusable consent, recorded with the version of the notice you saw.

We are not claiming that nothing changes. Between now and that date we will check this policy and our systems against the final text and correct whatever does not match. Section 24 says how we will tell you if that produces a material change.

21. Age and minors

21.1 InnieHub is for adults. You must be 18 or over. There is no version of the service for anyone younger, and we do not knowingly collect data from anyone under 18.

21.2 We ask for your date of birth before the service opens to you. If you register with an email address we ask at the moment the account is created; if you register through Google or Apple, neither of them gives us a date of birth, so we ask immediately afterwards and nothing inside the platform opens until you answer. A date implying an age over 120 is rejected as invalid.

21.3 If the date you enter indicates you are under 18, the account is terminated permanently and immediately, and you are told why with a route to appeal to a person. Your date of birth is then permanent and cannot be changed.

21.4 If we learn that a member is under 18, we terminate the account and delete the personal data, retaining only the minimum record in section 16.3.

21.5 If you believe a person under 18 has an account, tell us at safety@inniehub.com and we will act promptly.

22. How we protect information

22.1 Passwords are hashed with bcrypt and are never recoverable, by us or by anyone.

22.2 Every read and write is authorised on the server. The interface never grants access that the server would refuse, so a modified client gains nothing.

22.3 Rate limiting protects sign-in, password reset, message sending, uploads, search, the AI assistant, the age gate and data export.

22.4 A new sign-in invalidates an older session, so a stolen session does not persist quietly. A suspension or a deletion takes effect on the next page load rather than waiting for a session token to expire.

22.5 You can enable a device-level app lock using Face ID or your device passcode. This protects the app on your device. It does not encrypt your data on our servers and does not send your biometric anywhere. It is not two-factor authentication, and we do not currently offer any.

22.6 InnieDate photos and professionals' credential documents are stored as authenticated assets behind signed URLs, individually signed per request.

22.7 Data is encrypted in transit and at rest.

22.8 Wellbeing records and InnieCare conversations are protected twice over.

No route serves them to anyone but you. The restriction is enforced by the server when a request arrives, not by hiding a button in an interface, and an automated test fails the build if a moderator account can reach any of those tables by any route.

And we record every access, including our own. A log exists so that the sentence above can be audited rather than merely asserted. Three kinds of entry, kept differently on purpose:

• When another account is refused, the entry is kept in full for three years. Refusals are how we would find out that some part of the product had quietly started reaching for this data.
• When an administrator touches it in the one case where that is necessary, a destructive operation, such as carrying out a deletion, the entry is kept in full, with what was being done. This is the only class of permitted non-owner access that exists, and recording it is the point: "nobody but you can see this" is a sentence somebody may one day have to defend with a query, and a table holding only refusals could not answer it.
• When you open your own records, we keep only the category and the day, never which particular entry, and we delete it after 30 days. A log of when a person with agoraphobia opened their own mood history is a record of their self-care, and it tells us nothing about whether anyone else got in.

22.9 No system is perfectly secure. We do not claim otherwise.

23. If something goes wrong

23.1 We maintain a written incident response procedure that names who assesses a suspected breach, who decides whether it is notifiable, and who notifies.

23.2 Where a breach is likely to result in a risk to your rights and freedoms, we notify the competent authority within 72 hours of becoming aware of it. We hold ourselves to 72 hours everywhere, including in places whose own law allows longer or requires nothing, because it is the shortest deadline any regime that could apply to us imposes and running two clocks would only mean missing one of them. Where a breach is likely to result in a high risk to you, we notify you without undue delay, in clear language, telling you what happened, what data was involved, what we are doing and what you should do.

23.3 Given what this service holds, we treat any incident touching wellbeing records or InnieCare conversations as high risk by default, and we will notify you unless there is a clear reason not to.

23.4 US state breach notification laws apply in addition, and we comply with them on their own timelines.

24. Changes to this policy

24.1 We will tell you before a material change takes effect, by email and in the application, with at least 30 days' notice.

24.2 Where a change means we want to process your health data for a new purpose, we will ask for fresh consent. We will not treat continued use as consent to that, and the gates in section 7.2 will close until you answer.

24.3 Previous versions are kept at the legal centre so you can see what changed and when.

25. How to contact us

T&T Consulting Business, LLC
13575 58th Street North, Suite 200, Clearwater, FL 33760, United States

If you are in immediate danger, do not write to us, contact your local emergency services.