Privacy policy

Effective date: 5 August 2026

Version 1.0 — English version, Thailand PDPA-focused. A Thai-language version is issued with this one; see section 21.

This Privacy Policy explains how Education AI Group Co., Ltd. handles personal data in connection with PetFlow HQ, the pet-care management software we license to pet-care businesses. It covers petflowhq.com, the back office at app.petflowhq.com, the venue-branded surfaces we host on a venue's behalf, our operator tools, and our sales and customer-support channels (together, the "Platform").

This policy is addressed to venues and their people — the business that buys PetFlow HQ, the person responsible for that business, and the staff who log in. It is not the privacy notice that a venue's own customers are entitled to receive. If you are a dog owner who books with a pet-care business, that business is the controller of your personal data and owes you its own notice under section 23 of the PDPA. There are, however, two narrow sets of records about dog owners that we hold as controller in our own right, and one channel through which we contact dog owners directly. We do not hide those. They are set out in sections 2, 7 and 18.2, and a venue is required to reflect them in its own notice before it can trade (section 4).

There is no PetFlow HQ mobile application. We do not operate a consumer marketplace, and we have given a binding covenant that we will not build one on the back of a venue's data (section 6.6).

This document contains no unresolved placeholders. Every period, figure and commitment in it is final.

1. Who We Are

PetFlow HQ is a software product brand operated by Education AI Group Co., Ltd. (บริษัท เอ็ดดูเคชั่น เอไอ กรุ๊ป จำกัด), a company incorporated in Thailand. In this policy, "Education AI Group", "PetFlow HQ", "we", "us" and "our" mean Education AI Group Co., Ltd.

• Company registration number: 0845568020186
• Registered office: 2/1 Moo 6, Bophut, Ko Samui, Surat Thani, Thailand
• Privacy contact: support@petflowhq.com

This policy is governed by Thai law, including the Personal Data Protection Act B.E. 2562 (2019) (the "PDPA").

Terms used in this policy

• Venue — the pet-care business that holds a PetFlow HQ account: a daycare, boarding kennel, groomer, walker, trainer or similar operator. The Venue is our customer.
• Authorised User — a named individual given a login to the Venue's account, such as the owner, a manager or a member of staff.
• End Customer — the Venue's own customer, typically a dog owner, and the members of their household.
• Venue Data — the data a Venue, its Authorised Users and its End Customers put into the Platform, including records about End Customers and their animals, and the security, audit and technical records generated by activity inside the Venue's account.
• Platform — the four Venue-facing and Venue-branded surfaces we host (the Venue's public site, its End Customer portal, its staff workspace and its back office/CRM), together with petflowhq.com, app.petflowhq.com, our operator panel and our support channels.
• Terms — the PetFlow HQ Terms of Service.

There is no separate signed Data Processing Agreement today. Earlier drafts of this policy deferred roughly fifteen substantive commitments to a "DPA" that has never been written. We have removed those pointers. Until a separate DPA is executed, this policy and the Terms together are the data-processing agreement between us and the Venue, and every commitment that matters — the sub-processor list, the notice period and objection right, the documented instructions, the transfer mechanism for each destination, the breach-notification window and its contents, the assistance we give with data-subject requests, operator confidentiality, and the export and deletion timetable — is written out in full below. No document ranks above the Terms. See section 20.3.

2. Our Two Roles Under the PDPA

This is the most important section of this policy. Everything else follows from it.

2.1 The Venue is the controller of its End Customer data. The Venue decides why and how information about its customers and their animals is collected and used. It sets the purposes, chooses what to record, and is responsible for having a lawful basis and for giving its customers their own privacy notice under section 23 of the PDPA.

2.2 PetFlow HQ is the processor of that data. We hold and process End Customer and animal data on the Venue's documented instructions, which are set out in section 6.5. We do not decide what a Venue records about its customers and we do not use that data for our own purposes.

This includes the security, audit and technical records generated inside a Venue's account — for example an End Customer's IP address in a security log, or a record of a portal sign-in. An earlier draft claimed controller status over those records. That claim was wrong and we have dropped it. We could not have honoured it: we do not give End Customers a section 23 notice, and the PDPA contains no impracticability exemption from section 23 equivalent to Article 14(5)(b) of the GDPR. Those records are Venue Data, processed on the Venue's documented instruction, with the security, abuse-prevention and accountability purpose written into that instruction at section 6.5(f) and the retention at section 16.2.

2.3 PetFlow HQ is a controller for its own relationship with the Venue. That means the Venue's business and account details, the responsible person's contact details and date of birth, settlement and payout details, staff user accounts, billing and fees, support correspondence, product telemetry, and the platform-level audit and security records that do not relate to a Venue's tenant. For that data we make the decisions, and this policy is your privacy notice for it.

2.4 Two narrow exceptions: records about End Customers where we are controller. There are exactly two, and neither can be honestly described as processing on a Venue's instruction:

• (a) Accounting entries bearing an End Customer's name. Invoices, receipts and credit notes generated through the Platform become Education AI Group's own statutory books. We keep them on a legal-obligation basis, not on the Venue's instruction, and they survive the closure of the Venue's account. See sections 7.1 and 13.2.
• (b) The End Customer's platform account. A dog owner who registers through a Venue-branded portal creates a real account in our authentication system. That account — email address, hashed password, sign-in records and profile identity — is held once at platform level so that one person has one login, and it is shared across every Venue that person deals with. See section 7.2.

For both, we are controller. Because we are, two things follow and both are binding on us: the Venue must cover them in its own privacy notice, and we require written confirmation of that before the account can trade (section 4.2); and an End Customer may exercise rights under sections 30 to 36 of the PDPA directly against us in respect of those records, which we answer substantively within 30 days (section 18.2).

2.5 What is Venue-branded, and what is not. Every End-Customer-facing screen and every message body we render carries the Venue's branding and name. That is true, and it is why the Venue must give the notice. But two things are ours, and earlier drafts of this policy overstated the position by saying "a dog owner never sees the name PetFlow HQ" and "we have no channel to a Venue's customers":

• Transactional email is sent by us. Booking confirmations, reminders and payment messages are dispatched through our email provider from a single PetFlow HQ sending address and domain. The message body carries the Venue's name; the sender, the domain and the signature are ours.
• Authentication is ours. Password-reset and account-confirmation emails are sent by our authentication provider from its own sender, and the links in them land on a PetFlow HQ domain where the dog owner sets a password on an account in our system.

So we do have a limited channel, and we use it only to deliver the Venue's own transactional messages and to run authentication. We will not use it for anything else — see the covenant at section 6.6. We intend to add per-Venue sending domains and Venue-branded authentication email; until that is delivered, the position is as described here, and the Venue's own privacy notice should say so.

3. Scope of This Policy

This policy is our privacy notice to:

• the responsible person named on a Venue account;
• Authorised Users — the Venue's owners, managers and staff who log in;
• people at prospective Venues who enquire, request a demo or take part in a trial;
• visitors to petflowhq.com and app.petflowhq.com;
• anyone who contacts our sales or support channels; and
• End Customers, but only in respect of the two categories of record described in section 2.4 — the accounting entries and the platform account.

For everything else about an End Customer and their animals, the Venue is the controller and the Venue provides the notice. Section 6 describes that data so a Venue understands what we hold and on what footing.

4. What We Require Before a Venue Goes Live

Almost every allocation of responsibility in this document rests on the proposition that the Venue gives its customers a section 23 notice at or before the point of collection. But it is our software, not the Venue's, that renders the booking pages, the registration form and the customer portal where collection actually happens. An obligation with no mechanism is not an obligation, so we gate activation on it.

4.1 Two URLs. Before we activate Live Mode we require the Venue to supply, in the account profile, (a) the URL of its own privacy notice to its customers and (b) the URL of its own customer terms. We render the privacy-notice link on every Venue-branded collection form and on the portal registration screen, so that it is presented prior to or at the time of collection. The Venue should confirm that the link appears on each of its surfaces before it starts trading, and tell us at support@petflowhq.com if it does not.

4.2 A written confirmation about content. We also require the Venue to confirm in writing that its privacy notice covers, at a minimum:

• the accounting route: that invoices and receipts bearing the customer's name are transmitted to Education AI Group Co., Ltd. and to Intuit Inc. in the United States; that Education AI Group holds those entries as a controller in its own right for its own statutory accounting and tax purposes; that they are retained for five years, extendable to seven; and that they are not deleted when the Venue's account closes;
• the platform account: that the customer's login (email address, password and sign-in records) is held by Education AI Group at platform level, that it is a single account shared across any other PetFlow HQ Venue that customer uses, and that it survives deletion of the Venue's own records where that is the case;
• transactional and authentication email: that these are sent by Education AI Group on the Venue's behalf from a PetFlow HQ address and domain (section 2.5);
• security and audit processing: that IP addresses and activity records are processed for security, abuse prevention and accountability;
• aggregation: that anonymised, aggregated statistics are derived from the Venue's records on the Venue's instruction (section 6.4);
• retention: the platform retention defaults the Venue leaves in place — in particular ten years for incident reports and five years for payment records — stated as the Venue's own retention periods under section 23(3) of the PDPA; and
• cookies: the strictly necessary cookies set on the Venue-branded surfaces (section 15.2).

We do not review the Venue's notice for adequacy and we give no advice on it. We check that the URLs resolve and that the confirmation has been given.

4.3 The template notice we ship. Today the Venue's public site renders a privacy page and a terms page that we wrote, and the registration flow requires the customer to accept them. There is no Venue-editable field for either document yet. We are adding one. Until it exists, the honest position is this: we supply a template, the Venue adopts it as its own, and the Venue is the controller responsible for its accuracy and adequacy. A Venue that has not read the template it is publishing to its customers should read it now. We give no advice on whether it is sufficient for that Venue's business.

4.4 Test Mode — what it is and what it is not. An account starts in Test Mode. Completing the account profile, including the responsible person's date of birth, is what permits activation for live trading. You should know that Test Mode is presently a self-declared setup state that we do not technically enforce on the money path. The flag is recorded but the payment, charging, terminal-provisioning and document-issuing routines do not currently read it, and an account with no mode recorded is treated as live. We are building the refusal into those routines. Until that work is delivered, the Venue is contractually responsible for not taking real payments before activation, and we will not describe Test Mode as a technical control.

5. Personal Data We Collect About Venues and Their People

We collect only what is relevant and reasonably necessary for the purposes in section 12. As controller, we collect:

Venue business identity. Legal name, trading name, company registration number, tax identification number, date established, registered and trading addresses, business telephone and email, and business documents uploaded during onboarding such as registration certificates or licences.

The responsible person. Full name, date of birth, email address, telephone number and role. The date of birth is required before an account can leave Test Mode and trade for real. We collect it to verify who stands behind a trading account, to complete merchant onboarding with our payment provider, to help prevent fraud and impersonation, and as evidence of legal capacity to contract. It is access-restricted inside our systems and is not shown to ordinary staff users in the back office. See section 12 for the legal grounds and section 16.1 for how long we keep it.

Settlement and payout details. Where the Venue configures payouts, we hold the bank account name, bank name, full bank account number, branch, bank code and SWIFT code, and where a PayPal account is configured, the PayPal account name and email address. Our payment provider's onboarding also requires, and we record, the tax identification number, company registration number, date established, and the account name and last four digits of the settlement account.

*Legal grounds: performance of a contract (s.24(3)); legal obligation and the identity and settlement requirements our payment provider flows down to us contractually (s.24(6), s.24(5)). Retention: for the life of the account and 90 days after closure, except where the details appear in an accounting or settlement record retained under section 16.1.*

Authorised User accounts. Name, work email address, telephone number where provided, assigned role and permissions, authentication credentials (passwords are stored only in hashed form), multi-factor settings where used, and sign-in and activity records.

Billing and fee records. Subscription plan, fees charged, percentage fees applied to processed payments, deductions and settlement records, invoices, receipts, credit notes and tax details. A payment-method reference is held; card numbers are held by our payment provider and are never stored by PetFlow HQ.

Support and sales correspondence. Emails, in-app messages, chat and messaging correspondence, call and meeting notes, support tickets, surveys and feedback.

Technical, telemetry and platform audit data. IP address, browser and device details, operating system, identifiers, pages and screens viewed, actions taken, timestamps, error reports, approximate location inferred from IP, and cookie identifiers, in each case relating to our own sites and to Authorised User activity.

Business documents and brand assets. Logos, images, copy and other material a Venue uploads to configure its public site and customer-facing pages.

6. Data We Process on Behalf of a Venue

The following is Venue Data. The Venue decides why and how it is used; we hold and process it for the Venue on the documented instructions in section 6.5. This list is given so a Venue understands the scope of what we handle for it.

6.1 Records about End Customers and their animals

• End Customer contact records — names, email addresses, telephone numbers, addresses, emergency contacts and household grouping.
• Dog records — name, breed, sex, date of birth or estimated age, weight, microchip number, markings and identifying features, and photographs.
• Animal health information — vaccinations with dates and expiry, medications and dosages, veterinary practice details, allergies, dietary and feeding instructions, and health notes.
• Behaviour information — friendliness with other dogs and with people, nervousness, bite history and behaviour flags. This is recorded because it bears directly on the safety of staff, of other animals and of the public.
• Incident reports — reports recorded against a severity ladder, which may describe injury to an animal or to a person. Information describing injury to a person is health data about that person and may be sensitive personal data under section 26 of the PDPA. See section 9.
• Bookings and operations — bookings, visits, check-in and check-out records, care tasks, daily reports and staff notes.
• Payments and commerce — payments, invoices, receipts, refunds, credits, packages and memberships.
• Documents — customer-uploaded documents such as vaccination certificates and consent forms, and signed waivers.

6.2 Security, audit and technical records generated inside the Venue's account. IP addresses, device and browser details, request and error records, sign-in records, and the audit trail of actions taken in the account. These are Venue Data and we process them as processor, for the purpose set out at section 6.5(f). A Venue may obtain them on request under section 13.4.

6.3 Message content. The content of transactional messages we dispatch on the Venue's behalf, which includes End Customer first names, dog names, booking references, amounts and payment status. These pass through our email provider (section 13.1).

6.4 Aggregated and anonymised statistics. We produce product and industry-level statistics from Venue Data. Earlier drafts said statistics are produced "only from aggregated and anonymised data", which read as though only already-anonymous data was touched. That was misleading. The aggregation and anonymisation step itself operates on identifiable Venue Data. We therefore treat that step as an instructed processing purpose — see section 6.5(g) — and not as processing for our own account. The output is aggregated and anonymised such that individuals and individual Venues cannot reasonably be identified; we do not attempt to re-identify it; and any Venue may ask us for the benchmarks derived from its own data, which we provide free of charge.

6.5 Our documented instructions. We process Venue Data only to:

• (a) provide, host, configure and support the Platform for the Venue and its Authorised Users;
• (b) render the Venue's public site, End Customer portal, staff workspace and back office;
• (c) dispatch transactional and authentication messages on the Venue's behalf;
• (d) process payments, fees, refunds, invoices, receipts and credit notes at the Venue's instruction;
• (e) carry out the Venue's own instructions given through the back office or in writing, including retention, correction, export and deletion instructions;
• (f) maintain the security, integrity and accountability of the Venue's account — detecting and investigating misuse and unauthorised access, maintaining audit and security logs, and investigating incidents;
• (g) produce aggregated and anonymised statistics as described at section 6.4; and
• (h) comply with a legal obligation to which we are subject, in which case we tell the Venue first unless the law forbids it.

Anything outside this list requires a further written instruction from the Venue. We will tell the Venue if we consider an instruction infringes the PDPA.

6.6 What we will not do with a Venue's data. These are binding commitments, they bind our affiliates, and they bind any buyer, successor or assignee as a condition of any transfer:

• We do not sell personal data.
• We do not use End Customer personal data to train or evaluate machine-learning models.
• We will not contact, market to or solicit a Venue's End Customers for our own purposes or for the benefit of any other business.
• We will not use Venue Data, or insights derived from it, to launch or operate a consumer-facing booking service or marketplace.
• We will not disclose venue-identifying data or insights to any other Venue, and we will not use one Venue's information for the commercial benefit of another.

7. Personal Data About End Customers That We Hold as Controller

There are two categories, both introduced at section 2.4. This section is our section 23 notice for them, and section 4.2 requires the Venue to repeat it in its own notice, because the End Customer will read the Venue's notice and not this one.

7.1 Accounting entries. Invoices, receipts and credit notes generated through the Platform carry the End Customer's name. Those documents are simultaneously the Venue's commercial records and Education AI Group's own statutory books — our revenue, our tax filings. We hold them as controller on a legal-obligation basis under section 24(6) of the PDPA, they are written into the shared QuickBooks company described in section 13.2, they are transmitted to Intuit Inc. in the United States, they are retained for five years and up to seven under section 14 of the Accounting Act B.E. 2543, and they are not deleted when a Venue closes its account or instructs deletion. This is the one carve-out from a Venue's deletion right, and it is limited to accounting and tax records for the statutory period.

7.2 The End Customer's platform account. When a dog owner registers through a Venue-branded portal, an account is created in our authentication system with a password. The profile record is global, not scoped to a Venue: it is keyed on the email address, and the customer portal is deliberately not partitioned by Venue, so one person who registers at two Venues has one account shared across both. We hold that account record — email address, hashed password, sign-in records and profile identity — as controller, on the legitimate-interest ground at section 24(5), the interest being that a person should have a single login and a single set of credentials to secure rather than one per business.

The practical consequence, which a Venue must understand before it gives a deletion instruction: deleting a Venue's records does not delete a person's platform account where that person is also a customer of another Venue on the Platform. It cannot, without destroying the other Venue's customer's access. Where the person has no other relationship on the Platform, we delete the account on the timetable at section 16.1.

7.3 Rights. For both categories an End Customer may exercise the rights in sections 30 to 36 of the PDPA directly against us, and we answer substantively within 30 days. See section 18.2.

8. Animal Records and Personal Data

Dogs are not data subjects and animal information is not, by itself, personal data. But an animal record attached to an identifiable owner is that owner's personal data in practice: a microchip number, a dog's photograph, a behaviour flag or an incident description all lead back to a person.

We therefore apply the same access controls, retention rules and security measures to animal records as we do to records that are obviously about people. A Venue should treat them the same way in its own privacy notice and its own record-keeping.

9. Sensitive Personal Data (Section 26) and Consent Records

Section 26 of the PDPA restricts the collection of sensitive personal data — including health data — and generally requires explicit consent unless a specific statutory exemption applies. Legitimate interest is not available as a basis for section 26 data. Three situations arise on this Platform and should not be confused with each other:

1. Dog behaviour and bite history. This is information about an animal and is not itself section 26 data. It is the owner's personal data by association and is held under elevated access controls. It is recorded for staff and animal safety.

2. Injury to an End Customer or a member of their household. An incident report describing that a named person was bitten or otherwise hurt is health data about that person and falls within section 26. Consent cannot realistically be obtained at the moment an incident is being written up, and must not be relied on then for the first time. The consent has to exist beforehand.

3. Injury to a third party or to Venue staff. Where consent is unobtainable or would not be valid — a passer-by, a delivery driver, an employee — the Venue must identify an applicable statutory exemption, such as the vital-interest ground, the establishment or exercise of legal claims, or the employment and social-security ground for staff injuries.

9.1 Consent must be standalone. Bundling it into your registration terms will not work. An earlier draft of this policy said the explicit consent "should sit" in the Venue's registration terms and signed waiver. That advice was wrong and we have withdrawn it. Section 19 paragraph 2 of the PDPA requires a consent request to be clearly separated from other matters, in an easily accessible and readable form and in clear and plain language, and paragraph 3 requires it to be explicit. Consent to record health and incident information that is bundled into a Venue's terms of service, booking terms or general waiver is very unlikely to satisfy section 19. It must be presented on its own, in its own words, as a separate act, and the customer must be able to decline it without being refused the service where the data is not necessary for that service.

9.2 The consent record. A defensible section 26 consent record identifies which category the consent covers, when it was given, by whom, and against what wording, and provides a withdrawal that is as easy as giving it (section 19(5)), with the consequences of withdrawal notified in advance (section 19(6)).

The honest position on what the Platform does today: it can hold a signed waiver or consent document as a file against the customer's record, and nothing more. There is no structured per-category consent record and no withdrawal mechanism yet. We are building both: a per-category record with a timestamp and a wording-version identifier, and a one-click withdrawal that flags the affected records to the Venue. Until they are delivered, the Venue must keep the consent record itself, and we will not represent a bundled acceptance of terms as evidence of section 26 consent.

9.3 Where responsibility sits. The Venue is the controller and carries the obligation to hold a lawful basis, including any explicit consent required under section 26, and warrants to us that it holds that basis for everything it enters. Our obligations are to treat these categories as sensitive, to apply heightened access controls to the incident module, to record them as section 26 categories in our section 40(3) record, to build the consent tooling described above, and to apply a long retention default (section 16.2).

We do not ask you to keep sensitive data off the Platform. The product is built to record it, because pet care cannot be run safely without it. What matters is that the Venue has the right basis for doing so.

10. Children and Minors

10.1 The operative rule is section 20 of the PDPA. Where the data subject is a minor who is not *sui juris* by marriage or otherwise, consent must be given by the holder of parental responsibility with authority to act on the minor's behalf. Where the minor is under 10 years of age, consent must be obtained from that holder in every case. Where a legal act other than consent is involved, the rules of the Civil and Commercial Code on capacity apply.

10.2 Who captures it and where it sits. The Venue captures and holds the parental consent record, at registration or before the minor's data is recorded, and the Venue is the controller responsible for it. On the Platform today it is held as a document against the household or customer record. The structured consent record described at section 9.2 will cover minors' consent when it is delivered, including identification of the consenting adult and their relationship to the minor. Until then, the Venue must be able to produce the record itself.

10.3 Authorised Users are a separate question, and age is not the test. Earlier wording required Authorised Users to have capacity to contract and noted that majority is reached at 20 — which on its face barred an 18-year-old kennel assistant from holding a login. That was a drafting error. The contracting party is the Venue, not the individual member of staff. The Venue is responsible for its Authorised Users' use of the Platform regardless of any individual's age, for assigning permissions appropriately, and for the acts and omissions of anyone it gives a login to.

11. Where We Obtain Personal Data

• Directly from the Venue and from its Authorised Users, during enquiry, onboarding, configuration and day-to-day use.
• From the Venue's End Customers, through the Venue-branded portal, booking pages and forms we host for the Venue. We receive this data as processor, for the Venue, except for the account record described at section 7.2.
• From our payment provider, in the form of payment status, settlement and dispute information.
• From our own systems, automatically, in the form of telemetry, security records and audit logs.
• From public registries and business sources, where we verify a Venue's business registration details.

12. Why We Use Personal Data and Our Legal Grounds

Under the PDPA we process personal data only where there is an appropriate legal basis. The purposes below are our own, as controller. Most of the purposes for which End Customer data is used — running bookings, managing care, taking payment from customers, marketing to them — are the Venue's purposes, not ours, and the Venue must identify its own legal grounds for them.

Providing and configuring the Platform. Creating and administering Venue accounts and Authorised User logins, configuring the Venue's surfaces, delivering the software and hosting Venue Data.

*Legal ground: performance of a contract, and steps requested before entering a contract (s.24(3)).*

Account verification and activation. Verifying the Venue's business details and the identity, and date of birth, of the responsible person before the account may leave Test Mode and trade; completing merchant onboarding with our payment provider.

*Legal grounds: performance of a contract (s.24(3)); legitimate interest in preventing fraud and knowing who stands behind a trading account (s.24(5)); and, in relation to identity checks, requirements that our payment provider imposes on us under Thailand's anti-money-laundering and payment-systems regime and passes down to us contractually. We describe this as a flow-down obligation rather than a duty imposed directly on Education AI Group.*

Settlement and payouts. Holding and using bank and payout details to route settlement of processed payments.

*Legal grounds: performance of a contract (s.24(3)); legal obligation and payment-provider requirements (s.24(6), s.24(5)).*

Billing, fee calculation and settlement. Calculating subscription and percentage fees, deducting our fee from processed payments where agreed, issuing invoices and receipts, chasing non-payment, and handling refunds, chargebacks and reversals at the Venue's instruction.

*Legal grounds: performance of a contract (s.24(3)); legal obligation for tax and accounting records (s.24(6)).*

Our own statutory accounting records, including End Customer names on invoices and receipts.

*Legal ground: legal obligation (s.24(6)), under the Accounting Act B.E. 2543 and the Revenue Code. See sections 7.1 and 13.2.*

Maintaining the End Customer platform account. Holding a single authentication identity per person across the Platform.

*Legal ground: legitimate interest in secure, non-duplicated authentication (s.24(5)), and performance of the contract between the End Customer and us for the provision of that account (s.24(3)).*

Support. Answering questions, investigating faults, and keeping a record of what was asked and what we did.

*Legal grounds: performance of a contract (s.24(3)); legitimate interest in maintaining service records (s.24(5)).*

Security, abuse and fraud prevention at platform level. Protecting the Platform, detecting and investigating misuse, maintaining platform audit logs, and investigating incidents. (Security records generated inside a Venue's tenant are processed as processor — section 6.5(f).)

*Legal grounds: legitimate interest (s.24(5)); legal obligation where applicable (s.24(6)).*

Product analytics and improvement, using the aggregated and anonymised output described at section 6.4.

*Legal ground: legitimate interest (s.24(5)) in respect of our own telemetry; the derivation step on Venue Data is instructed processing, not our own purpose. Once data is anonymised so that individuals can no longer be identified, it is no longer personal data.*

Business-to-business marketing. Sending product news, updates and offers to business contacts at Venues and prospective Venues. We do not market to End Customers (section 6.6).

*Legal grounds: legitimate interest in marketing our software to businesses (s.24(5)), and consent where the law or the channel requires it. Every marketing message carries an unsubscribe option, and you can opt out at any time by contacting support@petflowhq.com. Service, billing, security and other transactional messages are not marketing and will still be sent.*

Legal, accounting and regulatory compliance. Keeping statutory books and records, meeting tax obligations, responding to lawful requests, resolving disputes, and establishing, exercising or defending legal claims.

*Legal grounds: legal obligation (s.24(6)); legitimate interest (s.24(5)).*

We do not rely on consent for anything a Venue must provide in order to hold an account. Section 19 of the PDPA requires consent to be freely given and prevents it being made a condition of a service where the data is not necessary for that service. The responsible person's date of birth, for example, is required to activate live trading, so we rely on contractual necessity and legitimate interest rather than consent.

13. When We Share Personal Data

We do not sell personal data. We disclose it only where necessary for the purposes above.

13.1 Our sub-processors

The following providers process personal data on our behalf, under contract. This table is the complete sub-processor list.

Resend was omitted from earlier drafts. That was an error of disclosure, not a change of practice: every outbound message from the Platform, and every registration email, has always been dispatched through it.

Change control and your right to object. We give the Venue 30 days' prior notice of any addition to or replacement of a sub-processor, by email to the account address and by notice in the back office. A Venue may object within those 30 days by writing to support@petflowhq.com. We will tell the Venue what alternative, if any, we can offer; where we cannot offer one, the Venue may terminate without penalty and receive a pro-rata refund of prepaid fees. We do not add a sub-processor by quietly updating this table.

13.2 The shared QuickBooks arrangement — stated plainly

You should read this before you activate your account.

The design. Accounting documents generated through the Platform — invoices, receipts and credit notes — are written into a single QuickBooks company operated by Education AI Group. Venues are separated within that company using the Location field.

The current state, stated accurately. Earlier drafts described this in the present tense as though it were running in production. It is not. Today the accounting integration can only be connected to a sandbox (test) company; a production connection is blocked at the database level; the posting route deployed today is a stub, so no document generated by the Platform has yet been written to any production ledger; and Education AI Group's own QuickBooks company has never been connected. Separately, the QuickBooks screen in the back office currently displays sample data — a "connected" status, invented customer mappings and an invented sync queue. It is not a record of anything. We are putting it behind a flag. When we move accounting posting to production we will give 30 days' notice under section 13.1.

Location is a reporting dimension, not an access boundary. When the arrangement is live, anyone with access to that company file can see records belonging to every Venue on the Platform, including End Customer names where those names appear on invoices and receipts. Some Venues on the Platform may compete with each other. That is a real exposure and we state it rather than let you discover it.

What we commit to, because the design does not separate you:

1. A named access list. We maintain a named, capped list of the individuals with access to that company file — our own finance staff and the external accountant or bookkeeper we engage. We publish it to Venues on request and notify Venues of changes to it.

2. Enforceable confidentiality. The external accountant and bookkeeper give written confidentiality undertakings that cover Venue Data and End Customer names, expressed to be enforceable by each Venue as a third party under section 374 of the Civil and Commercial Code.

3. No cross-use. We will not use venue-identifying information from that file for the benefit of another Venue or for our own commercial purposes beyond keeping our statutory books.

4. Migration. We will migrate to per-Venue QuickBooks companies or per-Venue sub-accounts by 31 December 2027. If we miss that date, a Venue may terminate without penalty and receive a pro-rata refund of prepaid fees.

5. Assurance in place of inspection. Letting one Venue inspect the shared company would expose every other Venue's customers, so we cannot grant an inspection right over it. Instead we obtain an independent accountant's report on the access controls over that company file, annually once the arrangement is live, and provide it to any Venue on request.

We are also a controller for those entries. The same entries are Education AI Group's own statutory books. We keep them on a legal-obligation basis, not on your instruction. This is why, when a Venue leaves, we cannot delete the accounting entries even though we delete the rest of that Venue's data. See sections 7.1, 16.3 and 19.3.

If you object. Tell us at support@petflowhq.com before activation or at any time afterwards. The consequences are as set out under change control in section 13.1.

13.3 Other recipients

• Professional advisers — lawyers, accountants, auditors and insurers, under duties of confidentiality.
• Authorities, regulators and courts — where required by law or reasonably necessary to protect rights, safety, property or the Platform.
• A buyer, investor, successor or group company — in connection with a reorganisation, financing, merger, sale or transfer, subject to appropriate confidentiality and legal safeguards, and subject to the covenants at section 6.6, which bind any transferee as a condition of the transfer.

We do not disclose End Customer data to any third party other than as described above or as the Venue instructs us.

13.4 Our own operator staff

A small number of PetFlow HQ personnel can access a Venue's tenant through our operator panel in order to provide support, investigate faults and maintain the Platform. That access is permission-controlled, and the personnel are bound by written confidentiality obligations.

What is recorded, stated accurately. Earlier drafts said that operator *access* is logged. It is not, yet. The audit trail records mutating actions — creating, changing or deleting a record — with the identity of the person who made them. A read leaves no trace, including a read of the responsible person's date of birth, and the audit table is scoped to a tenant, so there is no platform-level trail of operator activity outside a tenant. We are building read-access logging on the sensitive readers and a platform-scoped audit trail. Until that is delivered, the accurate statement is: operator access is permission-controlled and operator actions are recorded in the account's audit log.

What the Venue is entitled to. A Venue may obtain, on request and without charge, within 10 business days, the operator-access and operator-action records for its own tenant, so that it can discharge its own obligations under section 37(2) of the PDPA and investigate a suspected breach.

Break-glass. Where an operator accesses a tenant otherwise than in response to a Venue support request — an urgent security or integrity issue — we notify the Venue of that access, and the reason for it, within 2 business days.

Retention. Operator-access and operator-action records are retained for 3 years, longer than the general 12-month audit retention, because an access that becomes contentious usually becomes contentious in year two or three. See section 16.1.

14. International Transfers

Some of our providers process personal data outside Thailand. Where that happens we rely on appropriate safeguards under section 29 paragraph 2 of the PDPA — contractual protections in the provider's data-processing terms, including standard contractual clauses, together with the cross-border notification to the Office of the Personal Data Protection Committee where required — and, where relevant, on the section 28 exception for transfers necessary for the performance of a contract to which the data subject is a party or made at the data subject's request.

We do not rely on the "appropriate protection policy" route in section 29 paragraph 1. An earlier draft cited it. That route is available only for transfers within the same affiliated business or group, subject to review and certification by the Office. Supabase, Intuit, Cloudflare and Resend are not affiliates of Education AI Group, so the route is not open to us for them and we no longer cite it.

Omise group access. The Opn group is headquartered outside Thailand and group administrative or support access may take place from other group locations. We have asked Opn to confirm the current list and will record each named location, and the mechanism relied on for it, in the sub-processor table at section 13.1 under the 30-day change-control process. We will not leave the destination indeterminate in the way earlier drafts did — "the hosting region configured for the Platform" and "the other locations used by the Opn group" named no country and made it impossible for a Venue to complete its own section 39 record.

A Venue that needs this information for its own records may also ask us at support@petflowhq.com, but the table above, kept current under change control, is the authoritative statement.

15. Cookies and Similar Technologies

15.1 On our own sites. We use cookies and similar technologies on petflowhq.com and app.petflowhq.com to keep the service working, keep you signed in, remember preferences, understand use and protect security. Some are strictly necessary; others are optional. Where the law requires it, we will ask for your consent before placing non-essential cookies, and you can manage or delete cookies through your browser settings or the cookie control on those sites. Blocking necessary cookies will stop parts of the Platform working, including sign-in.

15.2 On the Venue-branded surfaces. Earlier drafts made the Venue responsible for "the notice and any consent required" for cookies on surfaces that we render and where we, not the Venue, decide what is set — and offered no control with which to perform that obligation. Here is the actual position.

On the Venue's public site and End Customer portal we set only strictly necessary storage and cookies: the authentication session token issued by our authentication provider, session and request-integrity values, and Cloudflare's security and bot-management cookies. We set no analytics, advertising, profiling or third-party tracking cookies on those surfaces, and there is no consent banner on them because none is presently required.

What this means for the Venue: describe these strictly necessary cookies in your own privacy or cookie notice (section 4.2), and do not add tags of your own to those surfaces. If a Venue asks us to enable analytics or marketing tags on its site or portal, we will not do so until a configurable consent control exists on those surfaces, and we will tell the Venue so rather than enabling them and leaving the consent problem with the Venue. The corresponding obligation on the Venue to describe these cookies is written into the Terms, so that it is a contractual obligation and not merely a statement here.

16. Data Retention

We keep personal data only for as long as reasonably necessary, unless a longer period is required or permitted by law. Two different retention regimes apply, on two different clocks.

A statement about enforcement, before the tables. There is presently no automated purge or scheduler in the Platform: nothing yet deletes rows from the audit or event tables on a timer, and there is no retention-configuration screen in the back office. Earlier drafts said "retention settings are available in the back office". That was not true and we have removed it. The periods below are our defaults; they are applied by us, on request or on our own manual review, and we are building the scheduled purge that will apply them automatically. Where a period is not yet enforced automatically, we say so.

16.1 Data we hold as controller

• Venue account and business records, including the responsible person's name and date of birth — for the life of the account and five years from closure or the last transaction. This aligns with the record-keeping period under the Accounting Act B.E. 2543 (section 14, which allows the period to be extended to seven years at the direction of the Director-General), Revenue Code assessment periods, and the record-keeping expectations flowed down by our payment provider. The date of birth is not kept indefinitely.
• Settlement and payout details (bank, PayPal and related identity fields) — for the life of the account and 90 days after closure, except where they appear in an accounting or settlement record retained on the line above.
• Billing, invoice, fee and settlement records, including the accounting entries in QuickBooks and the End Customer names on them — five years, extendable to seven under section 14 of the Accounting Act, and longer where a tax authority, a dispute or a legal claim requires.
• Support and sales correspondence — three years from the last contact.
• Authorised User accounts — removed when the user is deactivated by the Venue; sign-in and audit records are retained under the log periods below.
• End Customer platform accounts (section 7.2) — while the person has a relationship with any Venue on the Platform, and 12 months after the last such relationship ends, or earlier on the person's request where we are not required to keep the account.
• General audit logs (who did what in an account) — 12 months. Not yet enforced automatically.
• Operator-access and operator-action records — 3 years. Not yet enforced automatically.
• Technical and security logs (IP addresses, error reports, request records) — 90 days, unless retained longer for an active security or fraud investigation. Not yet enforced automatically.
• Marketing preferences and opt-out records — kept for as long as needed to respect the opt-out.

16.2 Venue Data we hold as processor

The Venue sets the retention. We apply the platform defaults below and act on the Venue's written instruction to change them. There is no self-service retention screen yet; a Venue changes a default, or instructs deletion, by writing to support@petflowhq.com, and we action it within 30 days.

Our current defaults:

• End Customer and dog records, bookings, visits, care records and daily reports — retained while the account is active, then deleted in line with the Venue's instruction or the account-closure timetable in section 19.
• Payment, invoice and receipt records — five years, to match the Venue's own accounting obligations.
• Incident reports — ten years by default, and we recommend leaving this default in place. Under section 448 of the Civil and Commercial Code a claim in tort is generally barred one year after the injured person knows of the injury and the person liable, and in any event ten years from the act. An incident report is the Venue's evidence in a personal-injury claim. Deleting it early carries a greater risk than keeping it.
• Vaccination and health documents — retained while relevant to the animal's care and for the period the Venue sets thereafter.
• Security, audit and technical records generated in the Venue's tenant (section 6.2) — the periods at section 16.1 for audit and technical logs apply, as our default instruction; a Venue may instruct a shorter or longer period in writing.

A Venue's own privacy notice should state the defaults it leaves in place as its own retention periods (section 4.2).

16.3 What we cannot delete on request

Accounting entries in our own statutory books — including the QuickBooks entries described in section 13.2 and the End Customer names on them — are our own records as controller and are kept for the statutory period even after we cease to be a Venue's processor. This carve-out is limited to accounting and tax records and to the statutory retention period. It is not a general right to keep data. The platform accounts described at section 7.2 are also outside a Venue's deletion instruction, for the reason given there.

When retention ends, we delete, anonymise or securely aggregate the data. Some information may remain in backups for a limited period until those backups are overwritten on the cycle stated at section 19.2.

17. Security, Tenant Separation and Breach Notification

17.1 Our measures

We use reasonable technical, organisational and administrative measures designed to protect personal data against unauthorised access, use, disclosure, alteration, loss or destruction. These include access controls and role-based permissions, individual named logins, encryption in transit and encryption of data at rest where our providers support it, restricted operator access, audit logging of actions, monitoring, vetted service providers, and internal access and confidentiality controls. Access to the incident module and to sensitive fields such as the responsible person's date of birth is further restricted. These measures are mapped to the standards in the PDPC Notification on Security Measures of Personal Data Controllers B.E. 2565 (2022).

17.2 Tenant separation — a positive warranty

Earlier drafts disclaimed, at platform level, any representation that Venue Data is held in an isolated environment. That disclaimer was written for the shared accounting ledger but was drafted so broadly that it appeared to disclaim separation in the application database where every customer, health, behaviour and incident record lives. A Venue could not have discharged its own obligation under section 37(1) of the PDPA on that basis. We have narrowed it, and replaced it with a warranty.

We warrant that Venue Data in the application database is logically segregated by tenant. Segregation is enforced in the database itself by PostgreSQL row-level security, enabled on every table that holds Venue Data, with every policy resolving through a per-tenant membership and permission check rather than through application code. No query path is exposed to a Venue user, an Authorised User or an End Customer that returns another tenant's rows. This is covered by automated tests that run against the migration set. The Terms carve a breach of this warranty out of the general liability cap.

17.3 The one place we do not claim separation

The shared QuickBooks company described in section 13.2, and only that. Within that company file, Location is a reporting dimension and not an access boundary. That is the entire scope of the disclosure; it does not extend to the application database, to file storage or to any other system.

17.4 Assurance a Venue can rely on

We hold no security certification and make no certification, standard or audit-attestation claim. What we do commit to:

• an independent penetration test at least once every 12 months, the first within six months of the effective date of this policy, with the executive summary provided to any Venue on request;
• a written response to a Venue's security questionnaire within 20 business days;
• a right for a Venue to appoint an independent auditor, bound by confidentiality, to audit the systems holding that Venue's data, at the Venue's cost unless the audit identifies a material finding, in which case we bear the cost;
• for the shared QuickBooks company, the independent accountant's report described at section 13.2, in place of an inspection that cannot be granted without exposing other Venues; and
• the operator-access records described at section 13.4, free of charge within 10 business days.

No online service can guarantee absolute security.

17.5 What the Venue is responsible for

Security is shared. The Venue is responsible for credential hygiene, for not sharing logins, for assigning permissions appropriately, for removing Authorised Users promptly when staff leave, for the security of the devices its staff use, and for the accuracy of what it enters.

17.6 If a personal data breach occurs

Because our roles differ, so does the notification path.

Where we are the Venue's processor, we will notify the Venue without undue delay and in any event within 24 hours of becoming aware of a personal data breach affecting Venue Data. The clock runs from awareness, not from confirmation. An earlier draft ran it from the moment we "confirmed" a breach, which put an unbounded investigation period in front of the commitment and could have consumed the Venue's whole statutory deadline; that was self-defeating and we have changed it. A suspected breach is notified on the same clock, and we update the Venue as the investigation develops. The same 24-hour figure is stated in the Terms.

The Venue, as controller, must notify the Office of the Personal Data Protection Committee within 72 hours of becoming aware, under section 37(4) of the PDPA. So that the Venue can file without a second round-trip, our notification will contain, so far as known at the time and updated thereafter:

• the nature of the breach, including how it occurred and when it began and was discovered;
• the categories and approximate number of data subjects affected, and whether the Venue's own tenant is affected;
• the categories and approximate number of records affected, including whether sensitive personal data under section 26 is involved;
• the likely consequences;
• the containment, remediation and mitigation measures taken and proposed; and
• a contact point at PetFlow HQ for follow-up.

We will preserve the relevant evidence and logs and will not destroy or overwrite them while an investigation or notification is live. We will assist the Venue with its notification to the PDPC and with any notification to affected individuals, and where the breach arose from our act, omission or systems, we will bear the Venue's reasonable costs of making those notifications.

Where we are controller — for Venue account data, settlement details, billing and accounting records, platform telemetry, platform audit logs, and the End Customer records at section 7 — we investigate, take the steps the PDPA requires, and notify the PDPC and affected people ourselves where required.

This is a commitment about breach notification only. We give no uptime, availability or support-response commitment anywhere in our documents.

18. Your Rights Under the PDPA

Subject to the conditions and exceptions in the law, you may have the right to:

• withdraw consent at any time where we rely on consent — this does not affect processing already carried out lawfully before withdrawal;
• request access to, and a copy of, your personal data (s.30);
• request correction of inaccurate, incomplete or out-of-date personal data (s.36);
• request deletion, destruction or anonymisation of personal data in certain circumstances (s.33);
• request restriction of the use of personal data in certain circumstances (s.34);
• request portability of personal data where applicable (s.31);
• object to processing based on legitimate interests, to direct marketing, or to certain research and statistical purposes (s.32); and
• complain to the Office of the Personal Data Protection Committee.

18.1 If you are a Venue's responsible person, an Authorised User or an enquirer

Exercise these rights against us. Email support@petflowhq.com with "Privacy Request" in the subject line. We may ask for information reasonably needed to verify your identity. We respond within 30 days of receiving the request, which is the period fixed by sections 30 to 36 of the PDPA. Where the law allows an extension we will tell you before the 30 days expire, with the reason.

18.2 If the request is about an End Customer's data

The default route is to the Venue, with two carve-outs and a fallback.

• Requests about End Customer or animal data go to the Venue. The Venue is the controller of that data and is the only party that can decide the request.
• If a Venue asks us to help with a customer's request, we assist — including access, correction, export and deletion — within 10 business days, or sooner where needed to let the Venue meet its own 30-day deadline. Where a task is not yet self-service, we perform it manually (see sections 16.2 and 19).
• If an End Customer contacts support@petflowhq.com directly, we acknowledge the message, tell them that the business they deal with is responsible for their data, and forward the request to that Venue within 3 business days, telling the requester the date on which we forwarded it and giving them the Venue's contact details. For data the Venue controls, we do not answer substantively, because doing so would mean processing outside the Venue's instruction and deciding a controller's question.
• Carve-out — records we control. For the accounting entries described at section 7.1 and the platform account described at section 7.2, we are the controller and we answer the request ourselves, substantively, within 30 days. We do not send the requester to the Venue for records the Venue does not control.
• Fallback — where the Venue is unavailable. If the Venue has been suspended or terminated, has ceased to trade, or does not respond substantively to a forwarded request within 14 days, we tell the requester so, we answer directly in respect of every record for which we are controller, and we identify which controller holds the balance and how to reach it. A person is not left with nowhere to go, particularly when we continue to hold their name in our own accounting records for five to seven years after the Venue's data has been deleted.

18.3 Complaining to the regulator

If you believe your rights under the PDPA have been infringed, you may complain to the Office of the Personal Data Protection Committee (PDPC) in Thailand, through the complaint channels it publishes, whether or not you have raised the matter with us first. We would like the chance to put things right, so please also tell us at support@petflowhq.com.

19. Export and Closing a Venue Account

A Venue may close its account in accordance with the Terms, or by contacting support@petflowhq.com.

19.1 Export — what actually exists, and what we commit to

There is no tenant-wide export tool in the back office. The only export built today is a CSV download of one finance report; the "Data Management" entry in Settings is an unbuilt placeholder; and there is no read-only account mode. Earlier drafts promised export tools in the back office and a read-only post-termination window. Those promises have been removed rather than left standing against software that cannot keep them.

What we commit to instead. We provide an export on written request to support@petflowhq.com, within 10 business days, at no charge, covering:

• End Customer contact records and household grouping;
• dog records, including photographs as original image files;
• animal health and vaccination records, and the original files of every uploaded certificate and document;
• behaviour information and flags, including bite history;
• incident reports with full metadata — severity, author, creation and amendment timestamps and record identifiers — because an incident report stripped of its metadata has little evidential value in the personal-injury claim it exists to answer;
• signed waivers and consent documents, as original files;
• bookings, visits, check-in and check-out records, care tasks and daily reports;
• payments, invoices, receipts, refunds, credits, packages and memberships; and
• the audit log for the Venue's tenant.

Structured records are provided in CSV and JSON, with a written schema description supplied with the export; uploaded documents and images are provided as original binaries. A non-standard export — an unusual format, a bespoke transformation, or a re-export of the same period — may carry a charge, capped at THB 20,000 and agreed in writing before any work starts. Export is available at any time during the subscription, throughout any period of suspension, and for 90 days after termination takes effect.

We will build self-service export. When it exists, this section will be updated under section 22, and the commitment above will remain available until it is.

19.2 Deletion

One set of figures, stated identically here, in the Terms and in any Data Processing Agreement we later execute:

• Export window: 90 days from the date termination takes effect.
• Live systems: within 60 days after the export window closes, we delete or irreversibly anonymise Venue Data.
• Backups: within a further 90 days, on the ordinary overwrite cycle.

How deletion is performed today. There is no automated archive or purge path in the Platform: every foreign key into the tenant record is set to restrict deletion, the tenant archive field has no writer, the profile statuses for pending anonymisation and anonymised have no function behind them, and there is no per-customer, per-dog or per-tenant deletion or anonymisation routine. Deletion is therefore carried out manually by us on written instruction, within the periods above. We are building the archive, anonymisation and hard-delete routines; until they exist we will not describe deletion as self-service, and section 16.2's promise of back-office tooling has been removed for the same reason.

Certificate of deletion. On request we provide a written certificate of deletion, covering live systems and backups, with the dates on which each was completed.

19.3 What is retained

Our own account, billing and accounting records — including the QuickBooks entries described in section 13.2 and the End Customer names on them — are kept for the statutory periods in section 16.1. Platform accounts of End Customers who are also customers of another Venue are retained as described at section 7.2. Records needed to establish, exercise or defend a legal claim may also be retained for as long as that claim is live.

Deletion is irreversible. A Venue should complete its export before the window closes.

20. Records of Processing, Our Data Protection Contact, and the DPA

20.1 Records of processing. We maintain records of processing activities as required by the PDPA — under section 39 for the processing where we are controller, and under section 40(3) for the processing we carry out as a processor for Venues. The section 40(3) record is a duty on us in our own right, and a Venue may ask us for the information it needs from that record to complete its own controller record. Sections 6, 13, 14 and 16 of this policy are written so that a Venue can complete that record without a further request.

20.2 Data Protection Officer. Section 41 of the PDPA requires a DPO to be designated in defined circumstances, including where core activities involve regular and systematic processing on a large scale, or the processing of sensitive personal data as a core activity. Given that incident and health records are core to this product, we keep our position under section 41 under active review and will designate and publish a DPO if and when the threshold is met. In all cases, the contact point for every data protection matter — questions, requests, complaints, breach notifications and regulator correspondence — is support@petflowhq.com, marked "Data Protection". A Venue may have its own obligation under section 41 in relation to the data it controls; that is the Venue's assessment to make and we do not advise on it.

20.3 The Data Processing Agreement. No separate DPA exists at the date of this policy, and neither this policy nor the Terms ranks any unsigned document above the Terms. This policy and the Terms are the data-processing agreement between us and the Venue. The documented instructions are at section 6.5; the sub-processor list, notice period and objection right at section 13.1; the transfer mechanisms per destination at section 14; the breach window and notification contents at section 17.6; the assurance and audit position at section 17.4; operator confidentiality and access records at section 13.4; DSR assistance at section 18.2; and the export and deletion timetable at section 19. If we later execute a separate DPA, it will be offered for signature with 30 days' notice and will not reduce any commitment made here.

21. Language

This policy is issued in English and Thai. The Thai version is published at petflowhq.com and is available on request from support@petflowhq.com. Where the two versions differ, the Thai version governs for PDPA notice and consent purposes — because a notice or a consent request must be readable, in clear and plain language, by the person it is addressed to, and many of the people this document concerns are Thai-speaking — and the English version governs the commercial interpretation of the relationship between us and the Venue. You may correspond with us in either language.

22. Changes to This Policy

We may update this policy when our services, processing activities or legal requirements change. We will post the updated version on the Platform, update the effective date, and give notice through the back office dashboard and by email to the account address.

• Materially adverse changes — to how we process Venue Data, to our security or tenant-separation commitments, to the breach window, to retention, or to export and deletion rights — require the Venue's positive written agreement. Continued use is not agreement to them.
• Other changes take effect on 60 days' notice.
• Sub-processor changes follow the 30-day notice and objection process at section 13.1.
• This policy is a contract document, and we do not amend it by quietly republishing this page.

Version history

23. Contact Us

For privacy questions, requests or complaints, please contact:

Education AI Group Co., Ltd. (operating PetFlow HQ)

2/1 Moo 6, Bophut, Ko Samui, Surat Thani, Thailand

Company registration number: 0845568020186

Email: support@petflowhq.com

This policy should be read together with the PetFlow HQ Terms of Service. Together they are the data-processing agreement between us and the Venue until a separate one is executed.

If you are an End Customer of a pet-care business that uses PetFlow HQ, that business is responsible for your personal data — please contact it and read its privacy notice. If your question is about an invoice or receipt bearing your name, or about the login and password you use for the customer portal, those records are held by us and you may contact us directly at the address above.