Data Processing Agreement
Effective: 19 July 2026 · MyJanji (myjanji.com)
This Data Processing Agreement ("DPA") is entered into by MyJanji ("Processor", operating the MyJanji platform at myjanji.com) and the business customer identified in the applicable order or subscription ("Controller"). It forms part of, and is governed by, the master Terms of Service between the parties (the "Main Terms"). It takes effect on 19 July 2026 or, if later, the date the Controller first uses the platform, and governs the Processor's processing of Personal Data on the Controller's behalf. Where the Main Terms and this DPA conflict on the subject of data protection, this DPA prevails.
1. Roles of the Parties
The parties acknowledge that, in respect of the Personal Data processed under this DPA, the Controller determines the purposes and means of processing and the Processor acts only on the Controller's documented instructions.
Who is who. For the personal data of the Controller's end-guests and clients (for example, a resort's guests or a clinic's patients), the Controller is the data controller and the Processor is a data processor. The Processor is an independent controller only for a narrow set of platform-level data it determines itself — the business account-holder's own account data, billing and subscription records, platform security logs, and aggregate platform analytics — which is governed by the Processor's own Privacy Policy, not by this DPA.
Where the Controller is itself acting as a processor for a third party, the Processor is a sub-processor and the terms of this DPA apply *mutatis mutandis* to that relationship.
2. Definitions
Capitalised terms not defined here have the meaning given in the Applicable Data Protection Law. The following definitions apply:
- Applicable Data Protection Law — all laws applicable to the processing under this DPA, including the EU General Data Protection Regulation (Regulation (EU) 2016/679, "GDPR") and the UK GDPR; the Malaysian Personal Data Protection Act 2010 as amended in 2024 ("PDPA"); and, in respect of tourist guest data processed in the Maldives, applicable local law and, as a matter of best practice, GDPR-grade standards pending comprehensive Maldivian legislation.
- Controller — the entity that determines the purposes and means of processing Personal Data; under the PDPA, the "data user".
- Processor — MyJanji, which processes Personal Data on behalf of the Controller; under the PDPA, the "data processor".
- Sub-processor — any third party engaged by the Processor to process Personal Data on the Controller's behalf, as listed in Annex III.
- Personal Data — any information relating to an identified or identifiable natural person (a "Data Subject") that the Processor processes on the Controller's behalf under this DPA; under the PDPA, "personal data".
- Special-Category Data / Sensitive Personal Data — Personal Data revealing health, and the other categories protected under GDPR Article 9 and the corresponding "sensitive personal data" category under the PDPA. Under this DPA this centrally means the dive medical questionnaire (RSTC/DMSC) and related health information described in Annex I.
- Data Subject Request — a request from a Data Subject to exercise rights of access, rectification, erasure, restriction, portability, objection, or withdrawal of consent.
- Personal Data Breach — a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, Personal Data.
3. Subject-Matter, Duration, Nature & Purpose
3.1 Subject-matter
The Processor operates a booking, point-of-sale/billing, CRM and operations platform for hospitality and service businesses, including an AI guest concierge ("butler") and dive-activity registration incorporating a medical questionnaire. Processing under this DPA is limited to what is necessary to provide that service to the Controller.
3.2 Duration
Processing continues for the term of the Main Terms and for any wind-down period agreed for deletion or return of data under Section 10. This DPA survives termination for as long as the Processor retains any Personal Data.
3.3 Nature and purpose
The nature of the processing includes collection, storage, organisation, retrieval, use, hosting, transmission to authorised recipients, and deletion, in each case to: manage bookings and guest/client records; process payments and subscription billing (via tokenised gateways — see Section 6); operate staff/HR functionality; deliver transactional communications; power the AI concierge, translation and document parsing; and maintain the security and integrity of the platform. The Processor does not sell Personal Data, and does not use guest or client Personal Data for its own marketing or to train third-party AI models (see Annex III).
3.4 White-labelling
Where the platform is provided under the Controller's own brand (for example, a resort customer whose guests see only the resort's brand), the Processor remains a processor and the Controller remains the controller for the underlying Personal Data; branding does not alter these roles.
4. Categories of Data Subjects & Personal Data
The categories of Data Subjects and Personal Data processed are set out in Annex I. They include guests/clients (including minors), the Controller's staff, and — importantly — special-category health data in the form of the dive medical questionnaire.
Special-category health data — lawful basis and consent capture. The dive medical questionnaire (cardiac, respiratory, neurological and metabolic conditions; pregnancy; mental-health items; medications, allergies and blood type) is GDPR Article 9 special-category data and PDPA sensitive personal data. The Controller, as controller, warrants that it has obtained separate, explicit, affirmative opt-in consent — the condition in GDPR Article 9(2)(a) and the PDPA's explicit-consent requirement for sensitive personal data — from each Data Subject before this data is entered into the platform, and instructs the Processor to process it solely to enable dive-activity registration and safety screening. To support this, the Processor provides a just-in-time consent interface at the point the questionnaire is completed, presenting the purpose and requiring an affirmative, unbundled opt-in before the health data is submitted; the Controller remains responsible for the content and adequacy of that consent for its own compliance.
Vital interests in a diving emergency. Independently of consent, the Processor is instructed to make a Data Subject's medical screening information available to the Controller's dive team where necessary to protect the life or physical safety of the Data Subject or another person in a diving emergency, in reliance on GDPR Article 6(1)(d) and Article 9(2)(c) (vital interests) and the corresponding duty-of-care basis under recognised dive-safety standards (RSTC). This basis applies only where the Data Subject is physically or legally incapable of giving consent.
4.1 Point-of-capture notices for high-sensitivity inputs
For the e-signature liability waiver and the upload of passport / national-ID / dive-certification card images, the Processor surfaces a point-of-capture notice explaining what is collected and why. These are high-sensitivity capture points (identity-document images and handwritten signature images); the Controller instructs the Processor to store them only as described in Annex I and Annex II (private storage, signed-URL access) and not to use them for biometric identification.
4.2 Minors and junior divers
Children's data. The platform is used by family resorts, and dive programmes accept junior divers (typically age 10 and above), who complete the medical questionnaire; date of birth is collected. Where a Data Subject is a minor, the Controller warrants that it has obtained verifiable consent and, where required, the consent or authorisation of a parent or legal guardian for the collection and processing of the minor's Personal Data, including any special-category health data, and instructs the Processor accordingly. The Processor does not itself determine whether a Data Subject is of an age to consent; the Controller is responsible for applying the correct age thresholds and guardian-consent workflow.
4.3 Staff and employees as Data Subjects
Where the Controller uses the platform's staff/HR functionality, the Controller's employees and workers are Data Subjects and the Controller is their controller. The Controller is responsible for providing its own employee-facing privacy notice and establishing a lawful basis for the processing of staff Personal Data (including salary, bank-account, and statutory identifiers such as EPF/KWSP, SOCSO/PERKESO and tax/LHDN numbers). The Processor processes this staff data solely as processor on the Controller's instructions and applies the measures in Annex II to it, including to staff financial data.
4.4 No solely-automated decisions
The dive medical questionnaire produces a binary screening signal ("one or more questions answered yes" / "no conditions flagged") that assists staff in assessing fitness to participate in dive activities. This signal is a decision-support aid only: a qualified member of the Controller's dive team reviews the outcome and makes the eligibility determination. No decision producing legal or similarly significant effects on a Data Subject is taken solely by automated means within the meaning of GDPR Article 22, and the AI concierge does not make automated eligibility determinations.
5. Processor Obligations
The Processor shall:
- Documented instructions — process Personal Data only on the Controller's documented instructions (including this DPA, the Main Terms, and configuration choices the Controller makes in the platform), unless required otherwise by law, in which case it will inform the Controller first where legally permitted.
- Unlawful instruction — inform the Controller without delay if, in its opinion, an instruction infringes Applicable Data Protection Law.
- Confidentiality — ensure that persons authorised to process the Personal Data are bound by confidentiality obligations and process it only as needed for their role.
- Security — implement and maintain the technical and organisational measures set out in Annex II, and keep them under review as the platform matures.
- Sub-processors — engage sub-processors only under Section 7 and Annex III, with equivalent data-protection obligations flowed down by contract.
- Assist with Data Subject Requests — as set out in Section 8.
- Assist with compliance — provide reasonable assistance to the Controller with data-protection impact assessments (DPIAs) — which the parties acknowledge are expected for the large-scale processing of special-category health data and for the AI concierge — prior consultations with a supervisory authority, and breach handling, taking into account the nature of processing and the information available to the Processor.
- Records of processing — maintain a record of the categories of processing carried out on behalf of the Controller in accordance with GDPR Article 30(2), and make it available to the Controller or a supervisory authority on request.
- Contact point / DPO — maintain a data-protection contact point reachable at [email protected]; the Processor is putting in place a designated Data Protection Officer / privacy contact and will cooperate with the Controller's own Data Protection Officer or designated contact where PDPA (as amended 2024) or GDPR Article 37 appointment thresholds apply.
- PDPA 2024 assistance — assist the Controller with its obligations under the PDPA (as amended 2024), including notification to the Personal Data Protection Commissioner and affected individuals following a Personal Data Breach, responding to data-portability requests, and cross-border transfer requirements.
- Breach notification — notify the Controller of a Personal Data Breach in accordance with Section 9.
- Deletion/return — delete or return Personal Data on termination in accordance with Section 10.
- Records & audit — make available the information necessary to demonstrate compliance and support audits under Section 11.
6. Technical & Organisational Measures
The Processor maintains the measures described in Annex II. In summary: encryption in transit (TLS) and at rest; hashed and salted credentials; no raw payment card data is ever stored on the Processor's systems (card entry occurs on the payment provider's hosted checkout and only tokens/customer-ids are retained); private storage for identity and certification scans served only via short-lived signed URLs; access controls including a server-only privileged database key, PIN-gating of sensitive finance actions, brute-force rate-limiting, signed webhooks, fail-closed scheduled jobs, and baseline security headers; and multi-tenant isolation enforced through row-level security together with application-layer access filters.
Continuous improvement — stated honestly. Security is maintained as a living programme, and Annex II distinguishes measures that are in place from those still being hardened. In particular, tenant isolation for staff/manager traffic currently depends in part on hand-written application-layer filters (rather than solely on database row-level security), and a content-security policy, a schema-validation layer, and rate-limiting on public AI endpoints are still being rolled out. The Processor operates a defence-in-depth approach, maintains an internal remediation register, and updates Annex II as measures land. Where a specific security matter affects the Controller's Personal Data, it is handled directly with the Controller under the breach-notification process in Section 9, so that the Controller can assess and respond to residual risk on accurate, current facts.
7. Sub-Processors
The Controller grants general written authorisation for the Processor to engage the sub-processors listed in Annex III to process Personal Data as described there. Each sub-processor is engaged under a written contract imposing data-protection obligations equivalent to those in this DPA (flow-down), and the Processor remains liable to the Controller for its sub-processors' performance.
AI concierge — data minimisation. The AI provider that powers the guest butler, translation and document parsing receives only what it needs: guest name, villa/room number, departure date/time, the names of divers whose medical screen is complete, the binary medical screening outcome ("one or more questions answered yes" / "no conditions flagged"), and the free-text a guest types into the chat. It does not receive the raw structured medical answers, which remain in the Processor's database. Because chat free-text is an open field, a guest may volunteer special-category data (for example, mentioning a pregnancy, an allergy or a medication); any such data is processed under the Controller's Article 9 explicit-consent basis, is minimised where practicable, and is covered by the same US-transfer safeguard (SCCs / UK Addendum) described in Section 11. The provider's API does not train on this data and operates under a zero/limited-retention arrangement. The provider is US-based.
Change notice. The Processor will give the Controller prior notice of any intended addition or replacement of a sub-processor. The Controller may object on reasonable data-protection grounds within a reasonable period; if the parties cannot resolve the objection, the Controller may terminate the affected service in accordance with the Main Terms.
8. Assistance with Data Subject Requests
Taking into account the nature of the processing, the Processor will assist the Controller by appropriate technical and organisational measures, insofar as possible, to respond to Data Subject Requests. Because the Controller is the controller for guest and client data, requests received directly by the Processor will be referred to the Controller rather than actioned unilaterally, unless the Controller instructs otherwise.
Practical scope of erasure and correction — disclosed, not concealed. Some data-subject rights are actioned manually today rather than through self-service tooling. The platform does not currently offer a self-service "download my data" or "delete my data" feature, and does not run a fixed-timetable automated auto-purge; a deletion made through the interface is a soft archive that suppresses the record from ordinary views while the underlying row is retained pending action. Valid access, rectification, erasure and restriction requests are actioned by the Processor via [email protected] within applicable statutory timeframes, subject to the lawful-retention bases in Section 10 and the retention subsection of Annex I. The dive medical questionnaire is currently maintained as an immutable, append-only safety record and, at present, cannot be edited or deleted even by an administrator; the Processor is implementing a logged, access-controlled mechanism to permit lawful erasure and rectification of these records where required. In the interim, where such an entry is demonstrably inaccurate, the Processor will record a logged correction alongside the record. These current constraints are disclosed to the Controller so it can respond to Data Subjects accurately.
9. Personal Data Breach
The Processor will notify the Controller of a Personal Data Breach affecting the Controller's Personal Data without undue delay after becoming aware of it, and in any event no later than 24 to 48 hours after becoming aware, so that the Controller has meaningful time to meet its own notification duties — including the GDPR 72-hour deadline to the supervisory authority (which runs from the Controller's awareness) and the PDPA 2024 mandatory breach-notification obligations to the Personal Data Protection Commissioner and affected individuals.
The notification will include, to the extent known at the time and supplemented on a rolling basis as further information emerges: the nature of the breach and the categories and approximate number of Data Subjects and records affected; the likely consequences; the measures taken or proposed to address it and mitigate harm; and a contact point for further information. The Processor commits to providing sufficient detail to enable the Controller to meet its statutory deadlines, will cooperate with and assist the Controller — including with notifications to the relevant supervisory authority, the Personal Data Protection Commissioner, and affected individuals — and will take reasonable steps to mitigate and remediate. The Processor also assesses each incident against the notification thresholds in Applicable Data Protection Law and documents that assessment.
10. Deletion or Return on Termination
On expiry or termination of the Main Terms, and at the Controller's choice, the Processor will delete or return the Personal Data it processes on the Controller's behalf, and delete existing copies, unless retention is required by law or is necessary for the legitimate interests described below. The Controller may request an export of its data before deletion.
Truthful scope of deletion. The Processor does not commit to an unconditional, scheduled purge it cannot currently perform. Deletion today is carried out on request and, for some records, is a manual and/or soft-archive operation (see Section 8). In addition, certain records are retained where law or a legitimate interest requires it, even against a deletion request: dive medical and safety records are retained as duty-of-care / liability documentation under recognised dive-safety standards (e.g. RSTC) and applicable insurance requirements, and are presently maintained on an immutable, append-only basis; and financial and tax records are retained for statutory periods. Where a lawful retention basis applies, the Processor does not represent that such records can be purged on demand. On termination, the Processor will return or delete all other Personal Data within a reasonable wind-down period.
11. International Transfers
The Processor and its sub-processors process Personal Data across borders — including database and file storage in the sub-processor's region, global edge hosting, and processing in the United States by the AI, payment and email providers. Where Personal Data of Data Subjects in the EEA or the UK is transferred outside the EEA/UK, the transfer is made under an appropriate safeguard, namely the EU Standard Contractual Clauses and, for UK data, the UK International Data Transfer Agreement (IDTA) or the UK Addendum to the EU SCCs, and/or the relevant provider's data-processing agreement incorporating those clauses, supported by a transfer risk assessment for US-based recipients. Cross-border transfers of Malaysian data are made in accordance with the PDPA's cross-border transfer requirements as amended in 2024.
Annex III identifies each sub-processor's processing location and the transfer safeguard relied upon.
12. Audit Rights
The Processor will make available to the Controller information reasonably necessary to demonstrate compliance with this DPA and will allow for and contribute to audits, including inspections, conducted by the Controller or an auditor it mandates. Audits are subject to: reasonable prior written notice; conduct during normal business hours; no more than once per twelve months except where required by a supervisory authority or following a Personal Data Breach; reasonable confidentiality and security constraints; and no access to other customers' data or to Processor confidential information beyond what is necessary.
Where available, the Processor may satisfy an audit request by providing relevant third-party reports, certifications, or the audit materials of its sub-processors, which the Controller agrees to accept as reasonable evidence to the extent they cover the matters in scope.
13. Liability & Interplay with the Main Terms
Each party's liability arising out of or related to this DPA is subject to the limitations and exclusions of liability set out in the Main Terms, and any reference to a party's liability means aggregate liability across the Main Terms and this DPA together — save that the parties may agree in an order a separate, higher or uncapped liability sub-cap for the Processor's breach of its confidentiality and security obligations in respect of special-category health data, ID/passport scans and staff payroll data. Nothing in this DPA or the Main Terms limits or excludes either party's liability where such limitation is not permitted by Applicable Data Protection Law, including liability owed directly to Data Subjects and the allocation of liability as between controller and processor under GDPR Article 82; to the extent the Main Terms' liability cap purports to limit such liability, it does not apply to it.
Controller indemnity. The Controller will indemnify the Processor against losses, claims, and regulatory penalties arising from the Controller's failure to establish a valid lawful basis — including the explicit consent warranted in Section 4 for special-category health data and any parental/guardian consent for minors — or to provide lawful, documented processing instructions, or to provide its own employee privacy notice under Section 4.3, to the extent such losses do not arise from the Processor's own breach of this DPA.
14. Governing Law
This DPA is governed by the laws of Malaysia, with the courts of Malaysia having exclusive jurisdiction and the parties submit to the courts identified there, without prejudice to any mandatory Data Subject rights or supervisory-authority jurisdiction under Applicable Data Protection Law. The Processor's place of establishment is Malaysia. Where the EU Standard Contractual Clauses or the UK IDTA/Addendum apply, their own governing-law and forum provisions prevail for transfers within their scope.
Privacy contact for all matters under this DPA: [email protected].
15. Execution
Agreed by the parties' duly authorised representatives. This DPA takes effect on 19 July 2026 or, if later, the Controller's first use of the platform. Each signatory warrants that they are authorised to bind the party for whom they sign.
| For the Processor | For the Controller | |
|---|---|---|
| Entity | MyJanji (Malaysia), operating MyJanji | The entity named in the applicable order or subscription |
| Signatory name | ||
| Title | ||
| Signature | ||
| Date |
Privacy contact for all matters under this DPA: [email protected].
Annex I — Details of Processing
Categories of Data Subjects
| Category | Description |
|---|---|
| Guests / clients (incl. minors) | The Controller's end-customers — for example, resort guests and dive-activity participants (including junior/minor divers), or salon/clinic clients — including their co-guests and named emergency contacts. |
| Staff | The Controller's employees and workers whose HR and payroll data is managed in the platform. The Controller is the controller for this data (Section 4.3). |
| Account users | Individuals who administer the Controller's account (also platform-level controller data — see Section 1). |
Categories of Personal Data
| Category | Data elements | Notes |
|---|---|---|
| Identity & contact (guests) | Name, email, phone, nationality, date of birth, home address, emergency contact | Date of birth also used to identify minors (Section 4.2) |
| Government / ID (guests) | National ID (e.g. NRIC/IC), passport number, and uploaded photos/scans of passport, ID and dive-certification cards | Stored as images in a private bucket, signed-URL access only; point-of-capture notice (Section 4.1) |
| Stay & booking (guests) | Villa/room number, departure date & time, co-guest names, loyalty tier/tags, free-text staff notes, booking & payment history | Payment history references tokens only; no card numbers |
| Signature (guests) | Handwritten e-signature images on liability waivers | Handled with elevated care; not processed for biometric identification; point-of-capture notice (Section 4.1) |
| SPECIAL-CATEGORY HEALTH (guests) | Full RSTC/DMSC dive medical questionnaire — cardiac, respiratory, neurological (epilepsy/seizures), diabetes, recent surgery, prescription medications, PREGNANCY, mental-health items (depression, suicidal ideation, panic, bipolar, addiction), allergies, medical conditions, blood type | GDPR Art 9 / PDPA sensitive personal data. Explicit consent (Art 9(2)(a)) plus vital-interests basis (Art 9(2)(c)) per Section 4. Raw answers stay in Processor DB; only a binary screening outcome (plus any free-text the guest types) is shared with the AI sub-processor |
| Staff HR & payroll | Name, contact, DOB, NRIC/passport, address, emergency contact, salary, commission, bank account details, statutory numbers (EPF/KWSP, SOCSO/PERKESO, tax/LHDN), attendance, leave, certifications | Employment data; bank + statutory numbers are sensitive financial identifiers. Controller is the controller and provides the employee notice |
| Payment tokens | Payment-gateway tokens and customer-ids; FPX gateway references | No raw card / bank-card numbers stored on Processor systems |
Nature, Purpose, Duration & Retention
Nature/purpose: as described in Section 3 — bookings, POS/billing, CRM, staff/HR, AI concierge and dive-activity safety screening. Duration: for the term of the Main Terms plus any wind-down period (Section 10).
Indicative retention. There is currently no fixed automated auto-purge window (disclosed, not promised); the following indicative periods describe current practice and lawful-retention bases and are refined as retention tooling is implemented: booking, CRM and general guest records — retained while the account is active and for a reasonable period thereafter; dive medical and safety records — retained on a legitimate-interest / duty-of-care and insurance basis under recognised dive-safety standards (currently immutable, append-only); financial and tax records — retained for the statutory period under applicable law; marketing-consent state — retained until consent is withdrawn or the account is closed; staff HR/payroll records — retained per the Controller's employment and statutory-record obligations. Dive-medical/safety and financial/tax records are retained even against an erasure request (Section 10).
Annex II — Technical & Organisational Measures
The following measures are stated truthfully; the Processor maintains a detailed internal remediation register, and items still being rolled out are marked so the Controller can assess residual risk. This annex must not be read as representing tenant isolation, content-security policy, or schema validation as fully implemented.
| Control area | Measure | Status |
|---|---|---|
| Encryption in transit | TLS for all client-server and API traffic; HSTS enforced | In place |
| Encryption at rest | Database and file storage encrypted at rest by the data sub-processor | In place |
| Credential protection | Passwords hashed and salted (pbkdf2); credential handling under continuous review | In place |
| Payment data | No raw card data stored; card entry on provider-hosted checkout; only tokens/customer-ids retained; FPX tokenised | In place |
| Privileged key handling | Service-role database key is server-only and never exposed to the browser; system-admin access via an environment allow-list kept out of the database | In place |
| Sensitive-file storage | ID / passport / certification scans in a private bucket, accessed only via short-lived signed URLs | In place |
| Finance action controls | Sensitive finance actions gated behind a hashed PIN | In place |
| Abuse / integrity controls | Login brute-force rate-limiting; payment webhooks verify signatures; scheduled jobs fail closed on a shared secret | In place |
| Security headers | Baseline headers set (HSTS, X-Content-Type-Options nosniff, X-Frame-Options DENY) | In place |
| Tenant isolation | Row-level security combined with application-layer access filters; staff/manager paths currently rely in part on hand-written filters | In place, subject to continuous hardening |
| Content-Security-Policy | Full CSP | In progress — not yet fully deployed |
| Input / schema validation | Structured schema-validation layer on API inputs | In progress — being rolled out |
| Public-endpoint rate limiting | Rate limiting on public AI/concierge endpoints | In progress — being rolled out |
| Ongoing hardening | Defence-in-depth programme: strengthening isolation invariants, input validation, transport/content-security policies, and abuse-rate controls on public endpoints | In progress — Annex II updated as measures land |
| Breach process | Notify Controller without undue delay, no later than 24-48h, with the information required by Section 9; each incident assessed against statutory notification thresholds | In place |
Annex III — Authorised Sub-Processors
General written authorisation is granted for the following sub-processors. Marketing/social platforms (Meta, LinkedIn, X, TikTok) are used only for the Controller's business marketing content and do not receive guest or client Personal Data, so they are not processors of Controller Personal Data under this DPA. No third-party analytics or tracking SDKs are integrated (only essential/session cookies, Supabase auth cookies, and a marketing referral (?ref=) capture). Where a placeholder region token appears, the specific region is set at provisioning and disclosed to the Controller on request. This list is kept identical to the sub-processor list in the consumer Privacy Policy.
| Sub-processor | Service | Personal Data received | Location | Transfer safeguard |
|---|---|---|---|---|
| Supabase | Primary database, file storage, authentication | All Personal Data, including special-category health data and ID/passport/certification scans | Data-residency region set at provisioning and confirmed to the Controller (Singapore — AWS ap-southeast-1) | Provider DPA + SCCs / UK Addendum |
| Anthropic (Claude) | AI guest butler/concierge, translation, document parsing | Guest name, villa/room number, departure date/time, names of divers with a completed medical screen, the binary medical screening outcome ("one or more questions answered yes" / "no conditions flagged") only, and guest-typed chat free-text — NOT the raw structured medical answers. Chat free-text may incidentally include special-category data volunteered by the guest | United States | Provider DPA + SCCs / UK Addendum; no training on data; zero/limited retention |
| Stripe | Card payment processing and subscription billing | Payment/cardholder data (on Stripe systems), billing identifiers | United States | Provider DPA + SCCs / UK Addendum |
| Resend | Transactional email delivery | Recipient email address and booking-confirmation details | United States | Provider DPA + SCCs / UK Addendum |
| Fonnte / Wassenger (WhatsApp) | WhatsApp messaging — where enabled only | Guest phone number and message body | Provider region (the United States), disclosed to the Controller on request | Provider DPA; used only where the Controller enables it (product direction is in-app messaging) |
| Apple / Google / Mozilla push services | Web push notifications (mostly staff) | Push tokens and notification content | Global | Provider terms / SCCs |
| Vercel | Application hosting / global edge runtime | Transient request data across global edge | Global edge | Provider DPA + SCCs / UK Addendum |
| Cloudflare | DNS and email routing | Email routing metadata; network-level data | Global | Provider DPA + SCCs / UK Addendum |