Does Your Booking Widget Send Patient Data Overseas? How to Check
You do not need to take a vendor's word for it. An embedded booking widget makes network requests you can read in your own browser in about ten minutes, and those requests tell you which countries the data actually reaches.
Vikas Thakur Founder, RockingWeb 7 min read 
Key Takeaways
- You can observe the destinations yourself in a browser network tab in about ten minutes
- Storage location and access location are different questions. Australian hosting with offshore support access still involves an overseas recipient
- APP 8.1 requires reasonable steps before disclosure, and a written vendor answer is the evidence those steps were taken
- Section 16C accountability can apply even where you took reasonable steps and even where a subcontractor was the party that breached
- Iframe versus redirect changes who collects what, not whether your obligations apply
- In force, and has been since the APPs commenced in March 2014
The previous post in this series set out what APP 8 requires and how to build a vendor map. This one is the practical half: how to find out where your booking widget actually sends data, without waiting for a vendor to answer an email.
The useful thing about an embedded widget is that it runs in your patient’s browser, which means it runs in yours too, and everything it transmits is visible.
The Ten-Minute Check
- Open your booking page in a desktop browser.
- Open developer tools and select the Network tab.
- Tick Preserve log, so a redirect does not clear the list.
- Complete a test booking end to end, using obviously fake details.
- Sort the request list by Domain.
You now have every host the booking flow contacted. Most will be your own domain and the vendor’s. The interesting ones are the rest.
| What you see | What it means |
|---|---|
| Vendor’s own domain only | Simplest case, one recipient to assess |
| A separate API subdomain | Often a different infrastructure region, worth asking about |
| An SMS or email provider | A second recipient your privacy policy probably omits |
| An analytics or session-replay host | A third recipient, often offshore, receiving form context |
| A CDN or bot-protection host | Usually low risk, but it does see request metadata |
Write the list down. That list is the beginning of the vendor map APP 8 expects you to have.
The proportions are an illustrative composition drawn from typical clinic booking stacks, not a measured average. What is reliable is the category list: these five are what a booking flow usually contacts.
What the Network Tab Cannot Tell You
Be honest about the limits of this method, because overclaiming from it is easy.
An endpoint’s apparent location tells you where the request terminates, not necessarily where data comes to rest, and certainly not where a support engineer sits when they open a ticket. Anycast routing and CDNs make IP geolocation unreliable for inferring storage location specifically.
So the browser check answers “who is involved” with high confidence, and “where is it stored” only weakly. The second question needs the vendor.
The Three Questions to Send
Once you know who is involved, ask each of them, in writing:
- In which country is our data stored at rest?
- From which countries can your staff or subcontractors access it?
- Which subprocessors do you use, and where are they located?
Ask for a written answer. Under APP 8.1 you must take such steps as are reasonable in the circumstances before disclosing to an overseas recipient, and a documented vendor answer is what “reasonable steps” looks like in practice. A screenshot of a marketing page is not.
Remember that section 16C accountability can still apply even where you took reasonable steps and the recipient breached anyway, and even where the recipient passed information to a subcontractor who breached. Reasonable steps are required; they are not a complete shield.
A Worked Example
Cosmetic clinic. A network check on a clinic’s booking page found five hosts: the vendor, a tag manager, a session replay tool, a CDN, and an SMS gateway. The clinic knew about two of them. The session replay tool was recording the booking form, including the treatment selection, and its recordings were stored offshore.
Session replay came off the booking flow entirely. The SMS gateway was documented and named in the updated privacy policy. The vendor confirmed Australian storage with offshore support access, which was documented as a known overseas disclosure rather than discovered later during an incident.
Dental practice. A practice using an iframe widget found the widget itself loaded a font and an analytics script from two further hosts. Neither received patient details, but both received the referring URL, which named the treatment page. The fix was the same URL-structure fix that solves the pixel problem: generic booking paths.
What to Check on Your Own Site
- Run the network check on the full booking flow, including the confirmation page.
- Repeat it on mobile, because some widgets load different resources on small viewports.
- Cross-check the resulting host list against your privacy policy. Does the policy mention overseas disclosure at all?
- Send the three questions to every vendor on the list, not just the booking platform.
- Diarise a repeat check each quarter. Vendors add and change subprocessors quietly.
- Keep the written answers somewhere retrievable. Evidence you cannot find is evidence you do not have.
The Enforcement Anchor
The OAIC’s determinations register covers health service providers and cross-border disclosure falls within its remit under section 16C. There is no published Australian determination against a clinic specifically for a booking widget’s offshore transmission at the time of writing, and this post does not assert one.
What is on the record is the accountability provision itself and the OAIC’s guidance on how far it reaches, which is unusually explicit about liability surviving both reasonable steps and subcontractor involvement.
Where This Gets Hard
Vendors frequently cannot answer question three. Subprocessor lists are often incomplete, out of date, or treated as commercially sensitive. A small clinic has little leverage to insist, and switching platforms over a subprocessor disclosure is rarely proportionate.
The pragmatic position is to document what you asked, what you were told, and what you could not establish. A written record showing you asked and were refused is materially better than no record, both practically and as evidence of reasonable steps.
The regulator says you must take reasonable steps before disclosing personal information to an overseas recipient; the build consequence is a documented host list and written vendor answers; whether your particular arrangement satisfies APP 8 in your circumstances is a question for your medical defence organisation or your lawyer.
Status
In force. APP 8 and section 16C have applied since 12 March 2014. Nothing above depends on the proposed second tranche of Privacy Act reform, which has not passed and has no commencement date.
Frequently Asked Questions
How can I tell where my booking widget sends data without asking the vendor?
Open the booking page in a desktop browser, open developer tools, go to the Network tab, and complete a test booking. Every request the widget makes is listed with its destination host. Resolving those hosts tells you which services are involved, and a WHOIS or IP lookup on the endpoints gives you a strong indication of where they terminate. This is observation of your own page, not testing anyone’s system.
Does an Australian data centre mean the data never goes overseas?
No. Data at rest in Sydney can still be accessed by support staff or subcontractors in other countries, and that access is a disclosure to an overseas recipient in its own right. Storage location and access location are two separate questions, and the second one is the one clinics almost never ask.
Is an iframe booking widget better or worse than a redirect for privacy?
Neither is inherently better. What changes is who collects what. With an iframe the patient stays on your domain while the vendor’s code runs inside it, so both parties are involved. With a redirect the vendor collects directly on their domain. Your APP obligations follow the personal information you disclose, not the embedding technique.
What should I ask a booking vendor in writing?
Three questions. Which country is data stored in at rest. Which countries can your staff or subcontractors access it from. Which subprocessors do you use and where are they located. Ask for the answers in writing, because a written answer is the evidence that you took reasonable steps under APP 8.1.
Get the Host List Built for You
Get in touch with RockingWeb and we’ll run this check across your whole site and return the written host inventory, not just the booking page.
Sources
- OAIC - APP Guidelines Chapter 8, cross-border disclosure, reasonable steps under APP 8.1 and accountability under s 16C. Checked 10 August 2026.
- OAIC - Australian Privacy Principles. Checked 10 August 2026.
- OAIC - Notifiable Data Breaches scheme. Checked 10 August 2026.
Last reviewed: 10 August 2026.
Vikas Thakur
Founder of RockingWeb. 16 years building for companies like TPG, iiNet and Monadelphous, now focused on websites and marketing that comply with AHPRA's advertising guidelines and still book patients.
