Privacy Policy

Last updated: 22 October 2025

1. Introduction

EverWellAI Ltd (“EverWellAI”, “we”, “us”, or “our”) is committed to protecting your privacy and complying with the UK General Data Protection Regulation (UK GDPR), the Data Protection Act 2018, and all applicable data protection laws. This Privacy Policy and Privacy Notice explains how we collect, use, store, and share personal data in relation to our services. EverWellAI provides an AI-powered supervision transcription platform for social care teams – we record one-to-one supervision sessions, transcribe the audio into text, and generate structured supervision documentation. We also operate a secure web platform for authorized users to access these transcripts and documents, and we provide related support services.

This notice applies to personal data processed by EverWellAI in connection with our website (https://www.everwellai.co.uk) and services. It is intended for individuals whose data we process, including social care professionals using our service (e.g. supervisors and supervisees employed by our customers) and any other individuals whose personal information may be captured in supervision sessions (such as children or service users discussed in those sessions). It also covers personal data of our business contacts and website visitors. We aim to use clear and accessible language while ensuring legal accuracy, so you understand how your information is handled. If you have any questions, you can contact us using the details provided at the end of this notice.

UK GDPR Applicability: EverWellAI is a UK-based company and our processing of personal data is subject to the UK GDPR and DPA 2018. Where we service customers in the European Economic Area (EEA) or otherwise handle EU personal data, we also comply with the EU GDPR as applicable. We adhere to core data protection principles such as lawfulness, fairness and transparency, purpose limitation, data minimisation, accuracy, storage limitation, integrity/confidentiality (security), and accountability. This means we only collect the data we need for defined purposes, and we protect it with appropriate security and care.

Important Note – Controller vs Processor: Depending on the context, EverWellAI may act either as a Data Processor or a Data Controller of personal data. In most cases, for the supervision session content we handle on behalf of our customers (your employer or organisation), we are acting as a Data Processor and your employer (or the relevant social care provider) is the Data Controller. This means we process that data only under their instructions and for their purposes. In other situations – for example, when we collect account information to manage your login, or when you interact with our website or support team – EverWellAI is acting as a Data Controller, determining how and why that personal data is processed for our own business purposes. We explain these roles in more detail below.

Finally, please note that this Privacy Policy may be updated from time to time as our services or legal requirements evolve. We will notify you of any material changes and indicate the “last updated” date at the end of this document. By using our services or website, you acknowledge this Privacy Policy and Privacy Notice. This document is not a contract, but a transparency notice to inform you about our data practices.

2. Who We Are

EverWellAI Ltd is a company incorporated in the United Kingdom (UK). EverWellAI is the provider of the EverWellAI supervision transcription platform and related services.

EverWellAI Ltd (“EverWellAI”, “we”, “us”) is a UK company providing an AI-assisted supervision transcription service for social care teams.

• Legal entity: EverWellAI Ltd (Company No. 16701230)

• Registered office: 33 Kinghorne Road, Barnard Castle, DL12 8GZ, United Kingdom

• Privacy contact/DPO: privacy@everwellai.co.uk

• Role: Controller for our website, accounts, security logs and support; processor for supervision recordings/transcripts handled on behalf of client organisations.

Data Protection Officer (DPO): Given the nature of our services (which can involve processing sensitive data and information about vulnerable individuals), EverWellAI has appointed a Data Protection Officer to oversee our privacy strategy and compliance. You may contact our DPO at privacy@everwellai.co.uk (please specify “Attn: DPO” in the subject line) or via the postal address above. If we have not yet formally appointed a DPO, we have a designated Privacy Officer or team fulfilling the DPO function, and they can be reached through the same contact details. We will update this notice with the DPO’s details once confirmed.

3. Scope of this Privacy Notice

This Privacy Notice applies to all personal data processed by EverWellAI in relation to our website and services. It covers:

• Clients and Users: Social care organizations (our clients) and their employees who use our platform (such as supervisors and social workers being supervised). For these individuals, most data processing happens as part of our service to the employer (where we act as a processor).

• Individuals Discussed in Supervision Sessions: Third parties whose information might be referenced during supervision sessions – this can include children or service users under the care of our client, as well as their family members or other related persons. These individuals do not directly use our service, but information about them may be contained in the audio and transcripts we process.

• Website Visitors and Business Contacts: People who visit our website, request information about EverWellAI, or communicate with us (for example, via a contact form or email). For these interactions, EverWellAI is typically the controller of any personal data collected (like your name, contact details, etc.).

• EverWellAI Personnel: (Note: This Privacy Notice is primarily for external individuals. Any data we process about our own employees or contractors is managed under a separate internal policy.)

We provide this notice to ensure transparency under Articles 13 and 14 of the UK GDPR. If your personal data is being processed by EverWellAI indirectly (for example, a child’s data mentioned in a supervision record), please refer to Section 9 on Children’s Data and Section 12 on Your Rights for information on how we protect that data and how you can exercise your rights.

4. Our Services and Purposes of Processing

EverWellAI offers an AI-powered supervision transcription service for social care teams. In practice, our platform assists with the following activities:

• Recording Supervision Sessions: With consent and appropriate notice, our platform can record audio of one-on-one supervision meetings between social care staff (e.g. between a manager/supervisor and a social worker or care worker). This is done to ensure accurate capture of what is discussed, including any concerns, actions, or reflections shared during the session.

• Transcribing Audio to Text: We use automated speech-to-text technology (artificial intelligence) to convert the recorded audio into a text transcript. This saves supervisors time from having to take extensive handwritten notes, and it creates a consistent record of the conversation.

• Generating Structured Documentation: Beyond a raw transcript, our system can help produce a structured supervision note or report (for example, summarising key points, agreed actions, outcomes, and any wellbeing concerns). We may employ natural language processing (NLP) or large language model (LLM) assistance to structure or summarize the content, under the guidance of the supervisor. The supervisor can review and approve this before it’s finalized.

• Delivering Records to the Organisation: Once a supervision record is finalized, our platform can securely store it for the organisation or deliver it into the organisation’s chosen system (e.g. saved to a secure drive, emailed to a designated address, or integrated into a case management system). We do this only on the instruction of our client (the data controller).

• Supporting the Platform’s Operation: In order to provide the above services, EverWellAI also processes some data for operational purposes, including: account creation and authentication (so that only authorized users can access the system), user interface features, and security logging/monitoring (to keep the service safe and prevent misuse). We also will use contact details to provide customer support or communicate with client administrators about service updates.

• Service Improvement: We may process limited data to improve the reliability and user experience of our product. Importantly, we do not use the content of supervision sessions for product development or marketing. Any analytics or feedback we gather for improvement are either non-personal or sufficiently aggregated/anonymised so that they do not identify individuals. For example, we might track overall system performance metrics or general usage patterns (like the average length of recordings or frequency of use) without referencing any names or content details. We do not profile individuals or make automated decisions that could significantly affect individuals – our AI features are assistive and the final decisions or actions (such as evaluating an employee’s performance) remain with human supervisors and the client organisation.

We process personal data only for the purposes above and compatible purposes. We will not use personal data for wholly new, unrelated purposes without updating this notice or obtaining appropriate consent/legal basis.

5. Personal Data We Collect and Process

We only collect personal information that is necessary for the purposes described. The categories of personal data we process, and the sources of that data, depend on your interaction with EverWellAI:

A. Supervision Session Content (Audio and Transcript Data)

Processed as a Data Processor on behalf of our clients. This is the core of our service. It includes:

• Audio Recordings: The voices and speech of participants in the supervision session (typically a social care employee and their supervisor). This will naturally capture whatever those individuals say during the meeting. The content often includes personal data such as names of the people involved or discussed, their roles, opinions and reflections, and details about cases or individuals under care.

• Transcripts: The text output of the audio, which contains the conversation details. This transcript will include personal information present in the conversation. For example, supervisors and staff may mention employees’ personal data (like the supervisee’s performance, training needs, or well-being) and third-party personal data. Third-party data can include information about children or service users that the staff member supports, or their family members. This might encompass names or identifiers of those individuals, descriptions of incidents or concerns, health and well-being information, and other sensitive details shared for supervisory or safeguarding purposes. The transcripts might also incidentally include special category personal data about the staff or others (see Section 8 below for what this entails). For example, a supervisee might discuss their own health condition or stress (health data), or mention that they are part of a union (trade union membership data), or discuss a service user’s health or ethnic origin. Our system does not deliberately seek this information, but it may appear as part of normal supervision dialogue.

• Derived Supervision Reports: After transcription, our platform may create a structured report or summary. This report is derived from the transcript and contains much of the same personal data (just organised or rephrased). It will include key points like action plans, any issues raised (possibly including personal data of children or others if relevant to the case), dates of the session, and the names/roles of participants.

Sources: The source of the above data is the participants themselves (they supply the information by speaking during the session). In effect, the employer (our client) or its staff provide this data to us by using our recording tool. We do not collect it from the individuals mentioned in the sessions directly (for instance, children discussed are not providing their data to us; it is provided indirectly via the conversation).

B. User Account and Authentication Data

Processed as a Data Controller (for running our service securely). When a social care organisation uses EverWellAI, we create user accounts for the authorised staff (such as the supervisors or admin users). The personal data in this context includes:

• Account Information: Name, work email address, and other contact details of users who register on our platform or are given access by their employer. We may also record the user’s role or permission level (e.g. supervisor, administrator) to manage access controls.

• Authentication Credentials: We securely store login information such as usernames and password hashes (we do not store plain text passwords). If single sign-on (SSO) or multi-factor authentication (MFA) is used, we store token identifiers or public keys as needed.

• Profile/Preferences: If the platform allows, users might provide optional profile info (like a profile picture or preferred settings), though generally our service uses minimal profile data.

• Device and Technical Info: When you access our platform, we automatically collect technical information like your IP address, browser type, and device identifiers as part of security and session management. We also collect timestamps of logins and activity logs (see next item).

This data is provided either by the users themselves or by their employer’s admin setting up the account. For example, a manager might send us a list of user emails to onboard, or users enter their details during sign-up.

C. Operational Logs and Security Data

Processed as a Data Controller. To safeguard our service and comply with our legal obligations, we keep logs and records of certain system events that may contain personal data:

• Access and Activity Logs: Our systems automatically log user activity such as login times, IP addresses, and actions taken (e.g., “User X viewed Transcript Y at 10:00 AM”). These logs generally do not include the contents of supervision sessions, only metadata (who accessed what and when). We use these logs for auditing, troubleshooting and security monitoring.

• Support and Communications Records: If a user or client contacts us for support, we will keep a record of that communication. This could include the requester’s name, email, and the content of the request. We ask customers not to send any sensitive personal data in support tickets if possible. If troubleshooting requires sample data, we either use dummy data or ensure any real personal data is redacted. Support emails and tickets are stored in our secure support system (e.g., our email or helpdesk, which is protected and accessible only to our support team).

• Website Data and Cookies: When individuals visit our marketing website (everwellai.co.uk), we may collect basic web analytics information via cookies or similar technologies (see our Cookie Policy for details). This may include your IP address, browser type, pages visited, and referral source. We do not try to personally identify website visitors from this data; it’s mainly to understand and improve our website. If you fill out a contact form or sign up for a newsletter on our site, we will collect the information you provide (e.g., name, email, organization, and your inquiry). That information will be used only for the purpose of responding to you or sending the requested information.

D. Special Categories of Personal Data

During the processing described above, we may handle special category data about individuals, particularly within supervision content. “Special category” data under the GDPR includes information about health, racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, genetic or biometric identifiers, sex life or sexual orientation. In our context, the most likely special categories to appear are health information (e.g., discussing a child’s health condition or a staff member’s mental health) and possibly data about union membership or ethnic background if mentioned in a case discussion. We do not actively collect these sensitive details as separate fields, but if they are spoken in a session, they may be recorded and transcribed. We treat all such data with extra security and only process it under strict legal conditions (see Section 8 on Lawful Bases and Section 9 on Children’s Data for more on how we lawfully handle sensitive data). We do not use any special category data for marketing or profiling.

E. Children’s Personal Data

As noted, our service is not aimed at children to use, but we do process personal data about children indirectly if they are being discussed in supervision sessions (for example, a social worker might talk about a child in their care, including the child’s name, age, health or family situation). Children’s data is considered particularly sensitive. We do not create accounts for children, and children cannot directly use our platform. However, any child-related data appearing in transcripts is processed in a safeguarded manner on behalf of the organisation responsible for that child’s care. We implement measures to minimize the amount of identifying data about children (e.g., encouraging use of first names or pseudonyms if feasible, offering tools to redact unnecessary details) and we segregate or flag such data for special handling (like stricter access controls and expedited deletion). See Section 9 for more information on our approach to children’s data.

6. How We Use Personal Data (Purposes of Processing)

We use the personal data we collect strictly for the following purposes, which align with the description in Section 4 and 5. For each purpose, we also note our role (controller or processor) and the relevant data involved:

• Providing the Supervision Transcription Service (Processor): The primary use of personal data is to facilitate and deliver our transcription service to our customers. This includes recording the session (capturing audio data), processing it through speech-to-text transcription, using AI tools to assist in structuring the notes, and outputting the final transcript/document to the authorized users. All of this is done on behalf of and under the instructions of our client (your employer). We do not determine the content of the sessions; we simply convert it into another format (text and documents) as a service. We use the data in the recordings only to produce the corresponding transcript and for no other purpose. For example, we don’t use your session content to train our AI models (we ensure our AI providers do not learn from your data – see Section 10 on sub-processors) and we don’t use it to profile or evaluate employees; that is entirely up to your employer’s internal processes.

• Facilitating Communication and Collaboration (Processor): As part of delivering the service, we might integrate with our client’s systems. For instance, a use case could be emailing the final supervision notes to a supervisor’s official email or uploading it to the client’s case management system. In doing so, we use personal data from the transcript (like names or case IDs) to properly label and route the document. Again, this is under the client’s instruction. If the client uses collaboration platforms (like Google Workspace, Microsoft 365, etc.), our service may interface with those systems to deliver documents. Any such processing is limited to fulfilling the client’s requested workflow.

• User Account Management and Authentication (Controller): We use account-related personal data to create and maintain user accounts for our platform. For example, we use your email and password to authenticate you when you log in, to authorize your access to the appropriate data, and to contact you for account-related matters (like sending a password reset link or notifying you of important service changes). We also use this information to manage user roles and permissions within the platform (ensuring, for example, that only supervisors see their supervisees’ records). This is an essential use of data to provide a secure service.

• Service Operations and Security (Controller): We use technical information and log data to ensure the service is working correctly and securely. This includes using IP addresses and device information for security monitoring (e.g., alerting on unusual login locations as a protection against unauthorized access). We analyse logins and usage patterns to detect fraud or misuse (for example, if an account has many failed login attempts, we may flag or block it to prevent a breach). We also use logs to debug issues – for instance, if there is an error uploading an audio file, our team might review the system logs (which contain timestamps and user IDs) to diagnose the problem. Importantly, our security logs do not include the content of transcripts, only metadata about actions. All these uses are aimed at maintaining the integrity, confidentiality, and availability of the platform.

• Customer Support and Enquiries (Controller): If you contact EverWellAI for support or with a question (whether you are a client administrator, an end-user, or even a member of the public curious about our service), we will use the information you provide to respond. For example, if you email us at our support address, we will use your email address to reply and may refer to your account or recordings (with your permission and only as necessary) to resolve your issue. If you report a bug or a problem with a transcript, we may need to access the relevant transcript or recording for troubleshooting; in doing so, we will only access the minimum required data and will maintain confidentiality. Support interactions may be recorded in our ticketing system for quality assurance and to build a knowledge base of common issues.

• Service Improvement and Product Development (Controller, with anonymisation/pseudonymisation): We continually seek to improve EverWellAI. To do this responsibly, we mostly rely on anonymous data or feedback rather than personal data. For example, we might measure how long transcription generally takes to help optimize our algorithms (this doesn’t require knowing whose data it is, just overall metrics). In some cases, we might use pseudonymised data – for instance, analyzing transcripts after removing or masking names and identifiers, to improve our AI’s accuracy on social care terminology. Any development use of actual content is done in a controlled environment, not for marketing or profit, and typically we’d seek permission from our client first. We do not use personal data for any automated decision-making that produces legal or similarly significant effects on individuals. Humans are always in the loop in our service output. Also, we never sell personal data to third parties for any purpose.

• Legal Compliance and Administration (Controller): We may need to process personal data to comply with our legal obligations or for routine business administration. For example, we might retain invoices or records containing client contact personal data for financial accounting and tax purposes (as required by law). If we receive a lawful request from a law enforcement agency or a court order, we may process and disclose personal data to the extent compelled by law (after verifying the request and legality). Additionally, to comply with UK data protection law, we maintain records of processing activities and conduct audits/DPIAs (Data Protection Impact Assessments) which might incidentally involve reviewing how certain data is used – this is done internally by our privacy team or consultants under strict confidentiality.

We will not use personal data for purposes that are incompatible with those listed above. If we ever need to expand the use of your data (for example, introduce a new feature that uses personal data in a novel way), we will update our privacy information and, if required, obtain consent or ensure another valid lawful basis.

7. Our Role as Data Controller vs Data Processor

It is crucial to understand whether EverWellAI is acting as a Data Processor or a Data Controller in a given context, because this affects how your data rights are fulfilled and who is responsible for what. We play both roles:

• EverWellAI as a Data Processor: For the core supervision session data (audio, transcripts, generated reports) and any personal data contained within those, EverWellAI is a processor working on behalf of our client (the social care organisation that employs the staff and runs the supervision). The client is the Data Controller for that data. This means:

  • The client determines the purpose and legal basis for processing that supervision data, and we merely act on their instructions. We have a Data Processing Agreement (DPA) in place with each client that outlines our obligations and the client’s instructions in detail, in accordance with Article 28 of the UK GDPR.

  • We do not use or disclose the supervision content for any purposes other than those instructed by the controller (your employer). For instance, we will not share transcripts with anyone except authorized client personnel, and we won’t analyze or mine those transcripts for our own purposes.

  • If you are a data subject who is mentioned in a supervision record (for example, you are an employee whose supervision was transcribed, or a child whose situation was discussed), your primary point of contact for exercising data rights (access, correction, etc.) is the controller (the organisation that has the direct relationship with you). We will assist that organisation in fulfilling any data rights requests (see Section 12 on Data Subject Rights) but typically we cannot fulfil such requests directly without the controller’s authorization.

  • In practice, this means EverWellAI takes instructions from our client regarding retention or deletion of the supervision data, any disclosures needed (e.g., if the client needs to share a transcript with a regulator, they might ask us to provide an export), and handling of any data incidents involving that data. We also rely on the client to provide any required notices to individuals and to obtain any necessary consents (for example, if recording a supervision session requires notifying the employees or getting consent, the employer handles that with their staff policies). We do, however, provide tools and support to help our clients meet these obligations (like features to export or delete data on request, and configuration settings for consent prompts in the app).

• EverWellAI as a Data Controller: For other types of personal data that we collect directly for running our service and business, EverWellAI is the controller. This includes:

  • Account and Admin Data: We decide how to use account registration details, authentication data, and admin contact information. While we collect this to perform our contract with the client, we determine, for example, the retention period for login data or how we structure user accounts on our platform. We also might use admin contact info to send service updates or information about new features. In these cases, EverWellAI is acting as the controller because we have discretion in these uses (within the scope of providing the service).

  • Website and Marketing Data: If you visit our website or sign up to hear more about EverWellAI, we are the controller for any data you provide (like if you subscribe to a newsletter or download a whitepaper with your email). We decide how to use that information (for example, to send you the newsletter), of course within the bounds of what you expect and consent to.

  • Support Communications: When you email or call us directly for support or inquiries, we are the controller of that communication data because we determine how to handle and retain those communications (e.g., logging a ticket, following up, improving our support process based on queries).

  • Operational Logs and Analytics: The logs we keep for security and performance, as well as any analytics about service usage (that do not include personal content), are under our control. We use them to run our business effectively and safely.

To summarize, for supervision session content, think of EverWellAI as an extension of your employer’s team (bound by their instructions), whereas for account, support, and website data, think of EverWellAI as a standalone service provider making decisions on how to manage that data. In practice, we maintain this distinction through internal controls: segregating personal data processed on behalf of clients from data we use for our own purposes, and ensuring strict limitations on any access or use of client-controlled data.

If you are unsure who the relevant data controller is for your personal data, feel free to contact us. We can clarify whether we are acting as a controller or processor in the context of your data, and we will direct you to the appropriate entity if needed (for example, your employer’s HR or Data Protection Officer if the matter relates to supervision records).

8. Lawful Basis for Processing Personal Data

Under the UK GDPR (and EU GDPR where applicable), every processing activity must have a lawful basis (for ordinary personal data under Article 6) and, if it involves special category data, an additional condition under Article 9 (plus UK DPA Schedule 1 where required). EverWellAI is committed to ensuring that all personal data we handle is processed lawfully, fairly, and transparently. This section outlines the legal grounds we rely on for different contexts of processing:

A. Lawful Bases when EverWellAI is a Data Controller

For personal data that we determine the purposes for (such as account data, support data, etc.), our processing is justified by one or more of the following Article 6 bases:

• Performance of a Contract (Article 6(1)(b)): We process certain personal data because it is necessary to perform our contract with our customers or to take steps at their request prior to entering a contract. For example, when we create user accounts and authenticate users, we do so to provide the service that our customer has subscribed to – without processing names, emails, and credentials, we cannot deliver the transcription platform service that we contractually owe. Similarly, if a user requests support, processing their contact information and issue details is necessary to fulfill our support obligations. This basis covers most of the service-related uses of personal data that are directly required for the platform to function for you.

• Legitimate Interests (Article 6(1)(f)): We process personal data where it is necessary for our legitimate interests (or those of a third party) and those interests are not overridden by individuals’ data protection rights or interests. We always perform a “Legitimate Interests Assessment” (LIA) to ensure balance and fairness. Examples of where we rely on legitimate interests include:

  • Service Improvement and Analytics: We have a legitimate interest in understanding how our service is used and how to improve it. For instance, analyzing non-sensitive usage patterns or feedback helps us enhance user experience and reliability. We ensure this does not override users’ rights by anonymising data or giving opt-outs where appropriate.

  • Security and Fraud Prevention: It is in our legitimate interest (and that of our clients and users) to keep our platform secure. We therefore process log data, IP addresses, and utilize security measures like monitoring logins for suspicious activity. This may involve processing personal data (like an IP address is technically personal data) to prevent unauthorized access, detect breaches, and ensure network and information security. These actions benefit all users by protecting their data.

  • Customer Relationship Management: We might use admin or business contact information to maintain our relationship with our clients – for example, sending service update emails to client contacts, or inviting client staff to provide feedback. This is a legitimate interest to foster good communication and service delivery. We ensure communications are relevant and not excessive, and we honour any request to opt-out of non-essential communications.

  • Support and Issue Resolution: When a customer’s staff member contacts us, it’s in our mutual legitimate interests to use their info to resolve their query. We consider this low-privacy-impact (often they are contacting us in a professional capacity) and necessary for running an effective service.

• Legal Obligation (Article 6(1)(c)): In some cases, we must process personal data to comply with a legal or regulatory obligation. For example, UK financial regulations may require us to keep records of transactions or invoices (which could contain personal data like a contact name on a billing statement) for a certain number of years. If the law requires us to report or retain specific data, we will do so. Another example is complying with data protection laws themselves – we might process data to fulfill your data access request or to demonstrate our compliance (which is a legal obligation under UK GDPR). If we receive a lawful request from authorities (e.g., an Information Commissioner’s Office (ICO) investigation or a court order), processing data to respond would fall under this basis. We will only disclose what is necessary and always verify demands before releasing data.

• Consent (Article 6(1)(a)): As a rule, we do not rely on consent for most processing activities, because we typically have other bases that apply (and because consent can be withdrawn, which might make it impractical for essential service functions). However, we will seek consent in certain scenarios, especially for optional or marketing-related processing. For instance, if we ever wish to use a testimonial with someone’s name or if we send a newsletter to people who are not already our customers, we would do so based on consent (e.g., you signing up and agreeing to receive such communications). Also, for cookies and analytics on our website, we rely on consent for any non-essential cookies (see our Cookie Policy). Where we do process based on consent, we will present you with a clear choice and the ability to withdraw consent at any time. Withdrawing consent will not affect the lawfulness of processing that happened before the withdrawal.

• Vital Interests (Article 6(1)(d)): This basis is unlikely to apply in our context. It is intended for life-and-death situations. We mention it for completeness that if ever we had to process data to save someone’s life (for example, if we overheard something in a supervision that indicated imminent serious harm, we might share data to appropriate authorities to prevent it – though normally that would be done by the controller, not us), such processing could fall under vital interests. This would be extremely rare, and we currently have no routine processing under this basis.

• Public Task / Official Authority (Article 6(1)(e)): Some of our clients may be public authorities (e.g., local government social services). Those controllers might rely on this basis for their processing. EverWellAI itself, however, is a private company; we do not perform tasks carried out in the public interest on our own behalf. So, we generally do not use Article 6(1)(e) for our own purposes. We operate under contract to public bodies, which is covered by 6(1)(b) or (f) typically. We will defer to the public body’s lawful basis in such cases and ensure our processing enables them to fulfil their public tasks.

B. Lawful Bases when EverWellAI is a Data Processor (on behalf of Clients)

In this scenario, it is the responsibility of the Data Controller (our client) to establish a lawful basis for the supervision data we process on their behalf. EverWellAI, as a processor, doesn’t choose the basis, but for transparency we can outline the typical bases that our clients use for such data:

• Legitimate Interests of the Employer (Article 6(1)(f)): Many employers will rely on legitimate interests to record and transcribe supervision sessions. The interest in this case could be ensuring quality of care and effective staff supervision, maintaining accurate records, and supporting staff development. They would balance this against employees’ privacy. Given supervision is a normal employment activity and data is kept confidential, a legitimate interests basis can often be appropriate (with proper safeguards).

• Performance of an Employment Contract (Article 6(1)(b)): Alternatively, or additionally, an employer might argue that supervisions are part of the employment duties and support (especially if they are mandated by employment policy or necessary to enable the employee to do their job safely). In such a case, processing the employee’s data (like recording their supervision discussion) could be considered necessary for the performance of their employment contract – for instance, to fulfill obligations to support and evaluate the employee. However, this basis might be stretched if the data captured goes beyond strict contractual necessity.

• Legal Obligation (Article 6(1)(c)): In some settings, there may be regulatory requirements to conduct supervisions (for example, care industry regulations or safeguarding laws might require regular supervision and record-keeping). If so, an employer could use legal obligation as a basis for processing the personal data in supervision records, to the extent that specific laws or regulatory standards require such processing. This can be applicable in social care if, for instance, the Care Quality Commission (CQC) or local safeguarding boards expect records of staff supervision to ensure quality and safety.

• Public Interest / Official Authority (Article 6(1)(e)): If our client is a public authority (like a local council’s social services department), they may consider the processing of supervision records as part of their public task (ensuring proper care for the public). For example, a council could claim that processing staff and child data in supervision notes is necessary for the exercise of official authority vested in the council (safeguarding children and delivering social care services). In such cases, Article 6(1)(e) could be the basis. However, even public bodies often prefer legitimate interests or legal obligation if those fit, since public task is a bit general unless clearly mandated by their function.

• Consent (Article 6(1)(a)): Generally, our clients do not rely on consent for employee data because consent in an employment context is tricky (it may not be freely given due to power imbalance). Likewise, they wouldn’t ask for consent from children or families for their data to be discussed in supervision – instead, they rely on the necessity for safeguarding or care. So, while consent is not usually the basis for the core processing, clients might seek consent for the actual act of recording audio (some organisations may ask staff “Do you consent to this meeting being recorded for transcription purposes?” as a courtesy and transparency measure). Even if consent is sought for recording, the subsequent use of the information is generally justified by the organisation’s legitimate interest or legal duty rather than consent, to ensure they can still use the notes if someone withdraws consent to record in the future (withdrawing consent would stop further recordings but not typically require deletion of past transcripts that were made for business purposes).

Special Category Data (Article 9 conditions): When supervision sessions involve special category data (like health or data about children’s well-being), additional legal conditions apply. As a processor, EverWellAI relies on our clients to determine and document the appropriate Article 9 condition (and to have an “Appropriate Policy Document” where required by Schedule 1 of the DPA 2018). Common applicable conditions are:

• Employment, Social Security and Social Protection Law (Article 9(2)(b)): This condition can apply if the special category data in supervisions is necessary for carrying out rights or obligations in employment or social protection law. For example, if an employee discusses their own health or a support need, the employer processes that to fulfill their obligation to provide a safe workplace or accommodations (employment law obligation). Similarly, if supervisions are part of ensuring staff well-being under health and safety law, 9(2)(b) could apply. The DPA 2018 Schedule 1 provides specific conditions under this category (like for occupational health or assessing working capacity). Our clients would need to identify the relevant law and have an appropriate policy in place.

• Health or Social Care (Article 9(2)(h)): Many of our clients operate in the social care sector, and they may use this condition since it covers processing necessary for the provision or management of health or social care services or systems. A supervision discussion about a child’s health or a care plan, for instance, could be considered part of managing a social care service, and thus allowed under 9(2)(h) (with duty of confidentiality). The UK DPA 2018 Schedule 1 also has provisions (paragraph 2, etc.) that align with this for health or social care purposes.

• Substantial Public Interest (Article 9(2)(g)): If the data is processed under a specific substantial public interest condition defined in UK law, that can be used. A relevant one here is “Safeguarding of children and individuals at risk”, which is a condition in Part 2 of Schedule 1 of the DPA 2018 (paragraph 18). This allows processing of special category data where necessary for safeguarding children or vulnerable people, and the individual is either unable to consent or it’s not reasonable to get their consent, and it’s in the substantial public interest. Supervision sessions often cover safeguarding issues, so this condition could apply especially for information about children. Another public interest condition might be the administration of justice or regulatory functions if the notes are used in those contexts, but primarily safeguarding would be most relevant.

• Explicit Consent (Article 9(2)(a)): As noted above, consent is generally not relied upon for special category in this context due to impracticality. However, if in some rare scenario explicit consent was obtained (for example, an employee explicitly consents in writing to the processing of their health info in supervision notes for a specific support purpose), then 9(2)(a) could be a basis. Explicit consent must be a clear, affirmative statement and can be withdrawn. We typically see our clients avoid this for routine operations, using one of the other bases that provides a more stable legal footing.

Children’s Data Legal Basis: Personal data about children that appears in supervision notes would be covered by the controller’s lawful basis as described (likely public interest in social care or legitimate interests in safeguarding). UK GDPR has special provisions for children’s data, particularly around consent for “information society services” (which require parental consent if under 13 for online services). However, EverWellAI’s service is not provided directly to children, and we do not offer any online service “to a child” that would require parental consent under those rules. Instead, children’s data is handled as a matter of necessity for social care – which falls under the bases above (public task, legitimate interest, etc., plus a safeguarding condition for special data). We ensure that processing of children’s data is done with appropriate safeguards (see Section 9) as required by Recital 38 of GDPR (which emphasizes protecting children’s data).

9. Special Category Data and Children’s Data – How We Protect Sensitive Information

Some of the data we handle is especially sensitive – this includes special category personal data (like health information or data about an individual’s vulnerability) and personal data about children. We recognize the heightened risks and concerns around such data and take additional measures to protect it, beyond our standard practices.

Special Category Data: As explained, special category data under GDPR includes things like health, racial/ethnic origin, sexual orientation, etc. In our context, this may appear in supervision discussions (for example, discussing a child’s mental health assessment, or mentioning an employee’s stress leave due to mental health, or referencing that someone is of a certain ethnic background relevant to their care). Our approach to special category data is as follows:

• Strict Need-to-Know Access: We limit who at EverWellAI can access any content that might contain special category data. Our staff generally do not access the content of recordings or transcripts unless it’s absolutely necessary for a support task or technical troubleshooting – and even then, only authorized personnel (with higher training and background checks) can do so. Within the client organisation, they control which of their users can access transcripts that might contain sensitive details. Our platform supports role-based access control (RBAC) and we encourage clients to restrict access to supervision notes to only those who require it (e.g., the supervisee, their supervisor, and perhaps a manager or HR if appropriate).

• Confidentiality and Training: We treat all supervision content as confidential. Our employees and any contractors are bound by confidentiality agreements. We provide training about handling sensitive data and the importance of not sharing it or even looking at it unnecessarily. We have policies in place to sanction any inappropriate access or disclosure. Essentially, we treat sensitive client data as we would medical records or similar highly confidential info.

• Data Minimisation and Redaction: We implement features and guidelines to minimize the capture of special category data. For example, if it’s not necessary to mention a person’s full name or exact health diagnosis in a supervision record, we encourage omitting or anonymising it. Our transcription and LLM processing pipeline can be configured to automatically redact certain types of sensitive information if desired. For instance, if a national ID or a particularly sensitive keyword appears, we could mask it in the transcript (with the client’s agreement on what to redact). We also pre-process prompts to our AI models to avoid unnecessary sensitive details (prompt minimisation). The idea is to only process what is needed for the purpose. If, say, a supervisee starts discussing something highly sensitive and irrelevant, supervisors can mark that section to be excluded from the official record. We put control in the hands of our users to manage what ultimately becomes part of the stored transcript.

• Additional Safeguards for AI Processing: For any AI components (like speech-to-text or text summarization), we choose providers that either do not retain the data or have opt-outs for model training. For example, our speech recognition sub-processor (AssemblyAI) is configured not to use our clients’ audio/transcripts to train its models. Where possible, we utilize EU-based processing and even zero-data-retention (ZDR) modes on AI services, meaning after the output is generated, the AI provider does not keep the input or output text. This is especially important for special category data – we don’t want it lingering on external servers longer than necessary.

• Appropriate Policy Documentation: Under UK law, when special category data is processed on certain bases (like employment or substantial public interest), the controller must have an “Appropriate Policy Document” (APD) describing how they handle that data (retention, etc.). We assist our clients by providing information for their APD and abiding by the promises in it (like deleting data as agreed, not processing for other purposes, etc.). For our own part (when we rarely might handle any special category data as a controller, e.g., if someone volunteers such info in a support ticket which we try to avoid), we also maintain necessary documentation and justification, and we’ll delete it when not needed.

Children’s Personal Data: Although EverWellAI’s service is not directed at children, we find it important to highlight how children’s data is treated, since our platform can indirectly handle data about children in a social care context. We fully align with GDPR Recital 38, which states that children merit specific protection of their personal data. Here are the key measures we take:

• Not Collected from Children Directly: We do not provide services directly to children nor knowingly collect data directly from children under 18. Children cannot create accounts on EverWellAI, and we do not have features that target them. All children’s data we process comes from our clients (e.g., social workers talking about their child service users) – so it’s second-hand, indirect collection. This means any obligation to inform those children or their guardians about their data being processed primarily lies with the Data Controller (the care organisation). We do, however, stand ready to assist our clients in providing such transparency. For instance, if a social care organisation needs to include EverWellAI in their privacy notices to service users, we supply them with the relevant details. If it’s appropriate in a given case to provide an Article 14 notice to a data subject (because their data was obtained indirectly), the client would typically handle that, but we ensure they have the info necessary (like categories of data, etc.) to do so.

• Enhanced Transparency: If a child (or their parent/guardian) were to inquire whether our system has any of the child’s data, we would cooperate fully with our client to provide an answer. We recognize that children might not easily exercise their rights, so we encourage our clients to incorporate information about this type of processing in the privacy notices that they give to families. We also can support by providing a simplified explanation if needed (though generally, communication with service users will come from the care provider, not EverWellAI directly).

• Minimisation and Anonymisation: We strongly encourage that wherever possible, information about children in supervision notes is recorded in a minimised way. For example, perhaps using first names or initials for children, or referring to “the child in Case ABC” rather than using full identifying details, if that suffices for the supervision’s purpose. Our platform could offer tools like auto-redacting a child’s surname after transcription, leaving just an initial. We defer to the social care professionals on what’s necessary, but our default stance is don’t include extra personal data about a child if it’s not needed. We also allow clients to configure shorter retention specifically for any records tagged as involving children (see Data Retention section below).

• Parental Consent and Children’s Rights: Because we do not provide online services to children directly, the typical requirement for parental consent (for under-13s in the UK) for using online services doesn’t apply directly. However, when it comes to children’s data being processed, their rights still apply. A child capable of understanding their rights (often around age 12+ depending on maturity) or their parent/guardian can request access, correction, etc. of the child’s data. In practice, those requests would be handled by the organisation that holds the relationship with the child (the care provider). EverWellAI will assist if needed, by extracting any relevant data from our system for the controller to give to the requester. We treat any such requests with utmost priority due to the sensitive nature. If we ever were in a position to act on a child’s data directly (which is rare, since we’re the processor), we would handle it with appropriate child-friendly communication and in liaison with the responsible adults.

• Safeguarding and Mandatory Reporting: We are aware that in social care contexts, certain information about children might indicate harm or risk. EverWellAI’s role is not to monitor or intervene in that content – we simply transcribe. We rely on the professionals to take action if needed. However, EverWellAI staff are trained that if in the very unlikely scenario they inadvertently see something in a transcript that clearly signals an urgent safeguarding issue (e.g., a child is in immediate danger and somehow no one else is acting), they should escalate it to the appropriate authorities or at least to the client. This would be a rare scenario because normally the client’s own processes handle safeguarding disclosures. But we include this in our training as a fail-safe, given our ethical commitment to protect children.

• Tighter Access Controls: Within our platform, any data related to children (which might just be embedded in a supervision record) is protected by the same high access standards, but we can add further restrictions. For instance, we might mark certain records as “sensitive” which could require an additional confirmation or higher role to access, to reduce casual browsing. Also, as mentioned, not all EverWellAI staff can access production data, and those who can are generally not looking at content unless needed for support. When it comes to children’s data, we impose an even stricter policy: ideally, no EverWellAI staff would open a transcript containing identifiable child information unless absolutely required (like during a support issue where that part of the content is causing a technical error).

• Data Protection Impact Assessment (DPIA): We have conducted (or will conduct) a Data Protection Impact Assessment for our service, which specifically addresses the risks to the rights and freedoms of data subjects, including children. The DPIA ensures we have considered and mitigated risks like unintended exposure of sensitive child data, retention issues, or any bias in our AI that could affect outcomes for children. The DPIA forms part of our compliance measures and demonstrates how we incorporate privacy by design for high-risk data like this.

In essence, children’s data gets all the protections of special category data (since information about a child’s welfare is usually also special category or at least highly sensitive) plus additional care due to the vulnerability of minors. We apply the principle of the best interests of the child – meaning in any decision involving a child’s data, we give weight to what would best protect and benefit the child.

If you are a parent or guardian and have concerns or questions about any potential processing of your child’s data by EverWellAI, please reach out to the social care organisation first (as they are the controller). You can also contact us at privacy@everwellai.co.uk, and we will coordinate with the relevant organisation to address your queries. We understand the trust you place in social care providers and their tools, and we strive to justify that trust by handling children’s information with the highest level of care and integrity.

10. Disclosure of Personal Data – Recipients and Sub-Processors

We do not sell or rent your personal information to any third parties. We only share or disclose data in a few carefully considered scenarios, primarily to provide our services (using sub-processor vendors under strict controls) or as required by law or your organisation’s instructions. Here we explain who might receive some of your data and under what conditions:

A. Sharing with the Client (Data Controller)

First and foremost, the content we process (like transcripts and supervision notes) is accessible to the organisation that is our client and their authorized users. This is obvious, but worth stating: if you are the employee being supervised, your employer (and specifically your supervisor, manager, and possibly HR or auditors) will see the transcripts we produce. If you are a service user (child) whose information is in a note, those notes are seen by the care professionals managing your case. EverWellAI’s role is to ensure the client’s designated people have access via our platform or via export to their systems. We do not disclose the content to anyone else internally or externally except on the client’s behalf.

B. EverWellAI Personnel and Contractors

Within EverWellAI, your data may be disclosed to our employees or independent contractors only on a need-to-know basis. For example, our technical team might have access to the database where transcripts are stored, but they will only actually view a transcript if required for a support issue or system maintenance. Our support staff might see your email address and name if you contact us. All staff and contractors with such access are bound by confidentiality agreements and undergo training in data protection. We also maintain access logs and can trace which staff accessed what data, to ensure accountability. In short, internal access to personal data is tightly controlled and monitored.

C. Authorized Sub-Processors (Service Providers)

EverWellAI uses a number of trusted third-party services to run our platform. These sub-processors process personal data on our behalf (and ultimately on behalf of our clients). We have Data Processing Agreements (DPAs) in place with each of them, requiring them to protect the data to GDPR standards, to only process it for our instructed purposes, and to keep it confidential. We carefully select these providers for their expertise and security posture, and we regularly review their compliance (including ensuring they have appropriate certifications like ISO 27001 or SOC 2 where relevant). Below is a list of key sub-processors we use, including what they do and measures in place:

• AssemblyAI (Speech-to-Text Transcription): We use AssemblyAI’s automated speech recognition service to transcribe audio recordings into text. We utilize their EU-based processing endpoint (which is hosted in Europe) for handling our data. AssemblyAI, as a sub-processor, receives the audio data and returns a text transcript to us. They are prohibited from using the audio or transcripts for any purpose other than providing the transcription to us – specifically, we have opted out of any machine learning model training on our data. This means AssemblyAI does not retain the audio or derived text beyond the processing period. They have signed a GDPR-compliant DPA with us. If in an exceptional case the EU endpoint is unavailable or a client explicitly allows a US endpoint, standard safeguards (see International Transfers) apply, but by default we keep this in the UK/EEA.

• Mistral AI (Language Model for Text Structuring): We use a Large Language Model (LLM) provided by Mistral AI (or similar EU-hosted AI model) to assist in generating structured summaries or documentation from transcripts. We prioritize using models hosted in the EU or even hosting models on our own infrastructure when possible. The model processes text (transcripts) and outputs a refined text. We ensure that any model or service we use in this way does not store or learn from the input data. Either the model is a self-hosted instance (so data never leaves our environment) or the provider has a zero-retention policy for API inputs. We also apply prompt minimisation and redaction techniques – before sending data to the LLM, we strip out or mask any especially sensitive identifiers that aren’t needed for context. Mistral AI (if used via their platform) operates under EU law and we have or will have a DPA ensuring GDPR compliance. If we ever use alternative models (like Azure OpenAI or others), we will ensure similar or greater safeguards (such as using an EU region and “no log/training” mode, with SCCs in place if outside UK/EU).

• Railway (Cloud Hosting Platform): Our application and processing pipeline are deployed on Railway, which is a Platform-as-a-Service (PaaS) cloud hosting provider. We use Railway to run our servers and backend infrastructure. We configure Railway to use European data centers for our deployments (e.g., EU regions). Railway as a company is based in the US, so we have an agreement that includes the necessary Standard Contractual Clauses for any remote management access (see International Transfers). Railway may incidentally process encrypted data and store our databases, so they are considered a sub-processor. They do not access customer content in plaintext; their role is mainly infrastructure. Railway’s DPA commits them to confidentiality and security best practices. We manage the encryption keys and secrets for our data on their platform (so even Railway staff cannot read sensitive data).

• Supabase (Database, Authentication, and Storage): We use Supabase as a cloud backend service for our application database, user authentication, and file storage. Supabase is a company based in the US, but we host our data in their European region (Frankfurt, Germany). Personal data such as user account information, transcripts, and other stored content resides in the Supabase managed PostgreSQL database and storage buckets in the EU. Supabase acts as a sub-processor by handling the data storage and providing authentication services (like managing user login tokens). They have signed a GDPR-compliant DPA with us and incorporate Standard Contractual Clauses for any potential admin access from outside the EU/UK. Supabase maintains strict data access controls; typically, data is only accessed by automated systems unless we or they initiate support. We have encryption at rest enabled for our database, and we use secure authentication flows that do not expose user passwords (only hashed values). Supabase also provides real-time logs and an API that we utilize for security monitoring.

• n8n (Workflow Automation): n8n is a workflow automation tool that we use to orchestrate certain processes, such as delivering the final documents to clients’ systems or sending notification emails. We either use n8n’s cloud service in an EU data center (Germany) or host our own instance in the EU. In either case, any personal data that flows through n8n (for example, a document file and a recipient email address) is processed within European infrastructure. n8n enables us to integrate with other services in a secure manner (like taking a finished PDF of a supervision note and uploading it to a Google Drive folder, as per client configuration). n8n as a sub-processor is covered by a DPA; they will not inspect or use the data passing through the workflows except as needed to operate the automation. We ensure that workflows are designed to minimize data exposure – e.g., data is usually transient in the workflow and not stored long-term in n8n.

• Google Workspace (Cloud Email, Storage, Docs) – for Support and Deliverables: EverWellAI uses Google Workspace (Gmail, Google Drive, Docs) for our internal email and document collaboration. We may also use it as part of the service if, for instance, a client opts to receive supervision documents via a shared Drive or if our system sends an email via Gmail on behalf of a supervisor. Google is a large provider with robust security; we configure our Google Workspace with EU data region preferences where available (Google can store certain core data in European data centers). However, Google may transfer data globally for efficiency and backup, so we have SCCs and the UK Addendum in place with Google. Google Workspace is ISO 27001 and SOC 2 certified. As a sub-processor, Google might process personal data in emails (like if a supervisor’s account sends an email to someone with a note attached) or in documents (if a transcript is stored as a Google Doc). Google does not access these contents for any purpose other than to host/store them for us. They have strong privacy commitments in their Cloud Data Processing Addendum. For support communications, when you email us at support@everwellai.co.uk, it’s handled by Gmail – so personal data in that email is obviously processed by Google as our email provider. We trust Google’s security in this regard but still treat support emails as confidential internally.

• Other Partners or Integrations: In the future, we may integrate additional services or offer optional features that involve other third parties (for example, an SMS service to send notifications, a translation service, or an analytics service). We will update our sub-processor list and ensure any new partner is held to the same standards before we use them with real data. As of the latest update of this notice, the above list covers our main data processors. If you would like the most up-to-date list of sub-processors, you can contact us or check our website where we maintain a “List of Sub-Processors” page for transparency.

D. Other Third-Party Disclosures

EverWellAI will not disclose personal data to third parties outside of the above without a valid reason and legal basis. The limited additional circumstances where we might share data are:

• Legal Requirements and Safety: If we are compelled by law to disclose data, we will comply after verifying the request’s legitimacy. This could include court orders, law enforcement requests, or regulatory audits. Wherever possible, we will notify the affected customers or individuals before disclosing, unless legally prohibited. Additionally, if necessary to protect someone’s vital interests (life or safety) or to address fraud or security issues, we might share information with appropriate authorities. For example, if we detected content indicating an imminent serious harm during a supervision (again, typically the client would handle it, but in a dire emergency we might inform law enforcement ourselves in line with safeguarding laws).

• Business Transfers: If EverWellAI were to be involved in a merger, acquisition, or sale of assets, personal data might be transferred to the new entity as part of the business transfer. If such a situation arises, we would ensure the data continues to be protected and provide notice to customers. Your choices regarding your data would remain (for instance, you could request deletion if appropriate). Any new owner would still be bound to use your data only for the purposes we’ve disclosed here (unless you consent to changes).

• Professional Advisors: We may share necessary personal data with our professional advisors (lawyers, accountants, auditors) when that information is needed for them to provide us with their services (for example, an auditor reviewing our processes might see some sample records, or our lawyers might need to know about data usage to advise on compliance). We’ll ensure such advisors are under obligations of confidentiality and data protection.

• Aggregated or Anonymised Insights: We might share aggregated statistics or insights externally (for example, “EverWellAI helped reduce administrative time by X% according to client feedback” or trends about usage across clients). These will never contain personal data – any identifiers are removed and data is combined so that individuals cannot be re-identified. This kind of information might be used in marketing or research about our service’s effectiveness, but it poses no privacy risk.

11. International Data Transfers

EverWellAI is based in the United Kingdom. Wherever possible, we aim to store and process personal data within the UK or the European Economic Area (EEA) to take advantage of strong data protection laws and to minimize the need for international data transfers. However, some of our service providers or our own operations may involve transfers of personal data outside of the UK/EEA. When we do transfer data across borders, we take steps to ensure it remains protected to the standards of UK GDPR.

UK and EEA Adequacy: The UK government and the European Commission have frameworks for which countries are considered to have “adequate” data protection laws. Data transfers from the UK to the EEA (and vice versa) are permitted as if within one territory, since the UK has deemed EEA countries adequate and the EU has granted the UK adequacy (as of the date of this notice). So moving data between UK and EU servers or clients is not seen as “restricted.” We consider storing data in the EEA effectively equivalent to storing in the UK for legal purposes, and we do both as needed (for instance, we might use an EU datacenter that still fully complies with UK laws due to adequacy).

United States and Other Non-EU Countries: Some of our sub-processors are headquartered in or may have personnel in countries outside the UK/EEA, notably the United States. For example, AssemblyAI and Supabase are U.S.-based companies, and Google and Railway are also U.S.-based, though they provide EU hosting options. Data might be accessed by these companies’ staff in the U.S. for support or maintenance. The US (and many other countries) are not currently deemed “adequate” by the UK (or EU) in terms of data protection laws. Therefore, to legally transfer personal data to those countries, we implement appropriate safeguards:

• Standard Contractual Clauses (SCCs): We have signed the UK International Data Transfer Addendum and/or the EU Standard Contractual Clauses (as applicable) with our non-UK/EEA service providers. These are legal contracts approved by regulators that obligate the recipient of the data (e.g., a US service provider) to protect the data to GDPR standards and give individuals enforceable rights. For UK transfers, we use either the UK’s International Data Transfer Agreement (IDTA) or the UK Addendum combined with EU SCCs, whichever format the provider supports. Essentially, these clauses bind the provider to treat the data as if it remained under European-level protection.

• Transfer Impact Assessments (TIAs): In line with the recommendations from regulators and the Schrems II ruling, we conduct Transfer Impact Assessments when using service providers in countries like the US. A TIA evaluates whether the laws of the destination country might undermine the protections of the SCCs (for instance, risk of government access to data). We consider factors like the nature of data (ours is typically not of interest to intelligence services, as it’s social care related, not national security), the likelihood of access, and the measures the provider uses (like encryption). If a risk is identified, we work with the provider to implement supplementary measures.

• Supplementary Technical Measures: These are additional steps to secure data during transfers. For instance, we use strong encryption in transit (TLS) for all data flows, so when data travels to a sub-processor or between our servers, it’s encrypted. We also use encryption at rest, meaning even if data is stored on a server in another country, it’s encrypted on the disk. Some providers offer end-to-end encryption or zero-access encryption – for highly sensitive data, we may consider such approaches (e.g., if we email a document via Google, it can be encrypted such that only the recipient can open it). Another measure is pseudonymization: before sending data to an external service, we might replace personal identifiers with codes. This way, even if data were intercepted, it wouldn’t directly identify individuals without the key. We tailor these measures to the context – for example, transcripts stored in our DB on Supabase are encrypted; if Supabase had to hand over the DB content, it would be gibberish without our decryption keys.

• Service Providers with Data Privacy Framework: Some of our U.S. providers may be certified under the new EU-U.S. Data Privacy Framework (DPF) and the UK extension of it (if finalized). For instance, as of 2025, companies like Google have certifications to facilitate EU-US data flows. While the UK is considering similar adequacy for these frameworks, we currently still rely on SCCs/Addendum for UK transfers, since that is the established mechanism. If in the future the UK deems certain countries or frameworks as adequate (like if the U.S. gains an adequacy decision for DPF participants), we will adjust accordingly, possibly using those certifications as an additional comfort. But until then, we treat it as SCCs are the baseline, with or without DPF.

• Data Residency Options: We try to use UK or EU data residency options to avoid transfers outright. For example, as mentioned, we use AssemblyAI’s EU endpoint (so the audio stays in Europe). We use Supabase EU servers, Railway EU, n8n EU, etc.. Google has UK/EU storage for some data. By configuring these, we significantly reduce the routine transfer of personal data outside of Europe. The only remaining transfers are typically for things like support (where a US engineer might access a system to fix an issue) or for global services like Google’s network. But even then, the data largely stays regional.

• Your Rights on International Transfers: Regardless of where data goes, we ensure that your rights travel with it. The contracts guarantee that you can exercise your GDPR rights and seek legal remedy even if your data is stored in, say, the US. If you have concerns about our international transfers, please contact us. We can provide more details on specific transfer safeguards for your case. If needed, we can also consider requests to host data exclusively in the UK (for certain enterprise clients, we might offer a UK-only deployment, for example).

By using our services, you acknowledge that your personal data may be transferred and stored outside your country of residence, including to countries that may have different data protection standards. However, rest assured we only do so in compliance with applicable law and as described. If you want more information about our international transfer arrangements (like a copy of the relevant SCCs), you can contact us at privacy@everwellai.co.uk.

12. Data Retention and Deletion

We retain personal data only for as long as necessary to fulfil the purposes for which it was collected (as described in this notice), or as required by law or legitimate business needs. We also strive to implement the principle of storage limitation, meaning we don’t keep data indefinitely on the off-chance it might be useful – we define retention periods and have processes to delete or anonymize data that is no longer needed.

Our retention practices vary based on the type of data:

• Supervision Audio Recordings: We recognize that raw audio files of supervision sessions can be quite sensitive. EverWellAI’s policy is to delete audio recordings once they have been successfully transcribed and the text transcript is confirmed or approved. In practice, raw audio is retained typically for no more than 14 to 30 days in our system. This short window allows for quality assurance – for example, to replay audio if the transcript has an issue or to correct any transcription errors – and to accommodate any delay if a supervisor hasn’t reviewed the transcript immediately. After this period, the audio file is automatically and securely deleted from our storage, unless a longer retention is specifically requested by the client (which is uncommon).

• Text Transcripts and Generated Supervision Documents: The retention of transcripts and final documents is largely determined by our clients (the data controllers). Typically, these records form part of the organisation’s official supervision records or case records, which they might need to keep for a certain period (often several years) for regulatory or operational reasons. EverWellAI’s platform provides flexibility: we can retain transcripts for as long as the client’s subscription lasts, and we offer export and deletion functions to clients. By default, we will retain the transcripts on our platform until instructed otherwise by the client, or until the client’s contract with us ends, in which case we will facilitate a bulk export and then purge the data.

• User Accounts and Profile Data: For user account information (like your name, email, etc. used to login), we retain it as long as your account remains active. If a user account is deactivated or if our contract with a client ends, we will typically retain the account data for a short additional period in case the service is renewed or for troubleshooting. Our standard is to delete or anonymize user account data approximately 12 months after an account is closed or after contract termination.

• Security Logs: Logs that contain personal data (like IP addresses, login timestamps) are kept for a limited time necessary for security monitoring and investigations. By default, we keep detailed security logs for around 90 days.

• Support Tickets and Communications: If you contacted us for support, we retain those communications for up to 24 months by default.

• Backups: We maintain encrypted backups of our databases and files for disaster recovery purposes. These backups are retained for a limited duration (commonly 30-60 days rolling backups) after which they are overwritten or deleted.

• Legal Requirements or Disputes: In certain cases, we might need to retain data for longer than our standard period due to legal reasons.

• Anonymisation: As an alternative to deletion, sometimes we will anonymise data after a certain time.

When we delete data, we do so securely. That means simply deleting a reference or marking for deletion is not enough – we ensure data is actually expunged from our systems.

13. Data Security Measures

EverWellAI takes data security extremely seriously. We understand that the data we handle can be highly sensitive – it may involve private discussions about employee performance and welfare, and information about vulnerable individuals (children and families). Therefore, we implement a comprehensive set of technical and organisational measures to protect personal data from unauthorised access, alteration, disclosure, or destruction. Below we outline our key security practices:

• Encryption in Transit: All data transmitted between your device and our servers, and between our servers and any sub-processors, is encrypted using industry-standard protocols (HTTPS/TLS).

• Encryption at Rest: We encrypt personal data at rest on our systems and databases.

• Access Controls and Authentication: We implement strict access control both for our users and our internal team.

• Secure Development Practices: Our engineering team follows secure coding guidelines.

• Network and Infrastructure Security: Our cloud infrastructure is configured for security: we use firewalls and security groups to restrict which ports are open.

• Logging and Monitoring: We maintain audit logs of key activities in the system.

• Data Loss Prevention: We implement measures to prevent unauthorized exfiltration of data.

• Backups and Recovery: We perform regular backups of critical data to ensure we can recover from any data loss scenario.

• Penetration Testing and Audits: We subject our platform to security testing.

• Vendor Security and Reviews: We choose sub-processors who have strong security credentials.

• Employee Training and Policies: We have internal policies on data protection and security that all EverWellAI team members must follow.

• Incident Response Plan: EverWellAI has an Incident Response Plan that outlines steps to take in case of a suspected or confirmed security incident.

• Physical Security: We are a cloud-based service provider, so we rely on the physical security of our cloud providers.

14. Data Subject Rights

As an individual whose personal data may be processed by EverWellAI, you have certain rights under data protection law. We are committed to honoring these rights.

• Right of Access (Subject Access Request): You have the right to obtain confirmation whether we are processing your personal data, and if so, to receive a copy of that data.

• Right to Rectification: If you believe that any personal data we hold about you is inaccurate or incomplete, you have the right to ask us to correct it.

• Right to Erasure (“Right to be Forgotten”): You have the right to request that your personal data be deleted in certain circumstances.

• Right to Restrict Processing: You can ask us to restrict the processing of your personal data under certain conditions.

• Right to Object: You have the right to object to certain processing of your personal data.

• Right to Data Portability: This right allows you to receive the personal data you provided to us, in a structured, commonly used, machine-readable format.

• Right not to be subject to Automated Decision-Making (including profiling): You have rights in relation to automated decisions that have legal or similarly significant effects on you.

• Right to Withdraw Consent: In cases where we rely on consent to process your data, you have the right to withdraw that consent at any time.

To exercise any of these rights, you can contact us at privacy@everwellai.co.uk. To ensure we protect your data from unauthorized access, we may need to verify your identity before fulfilling a rights request.

15. Children’s Privacy

EverWellAI’s services are not directed to children and we do not knowingly collect personal data from anyone under the age of 18 directly. Children cannot sign up for or use our platform; user accounts are only for authorized adult professionals. However, because our platform is used in the social care sector, it is possible and even likely that information about children (under 18) will be processed by our system. We treat such data with special care due to children’s enhanced rights and the sensitivity involved.

16. Contact Us and Complaints

We encourage you to contact us with any questions, concerns, or requests regarding your personal data or this Privacy Policy. We are here to help and aim to be transparent and accountable in all our privacy practices.

Contact Details:

• Email: You can reach our privacy team at privacy@everwellai.co.uk.

• Postal Mail: EverWellAI Ltd (Attn: Data Protection / Privacy), 33 Kinghorne Road, Barnard Castle, DL12 8GZ, United Kingdom.

If you believe that we have not handled your personal data properly, or you are dissatisfied with our response to any privacy issue, you have the right to lodge a complaint with the supervisory authority. In the UK, that is the Information Commissioner’s Office (ICO).

17. Updates to this Privacy Policy

We may update or revise this Privacy Policy and Privacy Notice from time to time to reflect changes in our services, legal obligations, or data protection best practices. If we make substantial or material changes, we will notify our clients and users through appropriate channels. The “last updated” date at the top of this Policy indicates when the latest changes were made.