Sub-processor Register

LodgeHQ Pty Ltd · ABN 52 696 192 677 · 12 Rindle Street, Lara VIC 3212

Last updated:

4 August 2026

Last reviewed against the running system:

4 August 2026

Next scheduled review:

4 November 2026

What this page is

LodgeHQ is a case-management platform for Australian registered migration agents. To run it we use a number of third-party services. Some of those services receive personal information belonging to your clients — the people whose visa matters you manage in LodgeHQ.

This page lists them: the legal entity, the country, what the service is for, what data it receives, whether you can switch it off, and where the processing happens.

We publish it because you cannot properly assess a supplier you cannot see. If you are completing a due-diligence questionnaire, a professional indemnity disclosure, or a collection notice for your own clients, this page is where the detail comes from.

How this register was compiled. It was derived on 4 August 2026 from the production source code and the live production configuration — not from an internal wiki, and not by reading the previous version of the list. Where LodgeHQ authenticates to a service, that service is listed only if a working credential for it exists in the running production environment. Where no LodgeHQ credential is involved — an unauthenticated public API, a service your own firm supplies the credentials for, a browser push service your browser chooses, or a government system — the test is whether a production code path sends data there. Both kinds appear below.

On completeness. We believe this list is complete as at the date at the top of the page, and section 7 sets out how it is kept that way. Where we know it is not complete, the table says so rather than leaving a gap — the individual translators who complete a translation order are the current example.

Where the entity names come from. Which service receives what, and whether it is live, is derived from the running system, and we stand behind those columns. The legal entity column is different in kind: a contracting entity cannot be read out of our own configuration, so unless the cell says otherwise those names are taken from the vendor’s own published terms, data-processing addendum or privacy notice as at the date at the top of this page — not from an invoice or an order form we hold, and not independently confirmed against a corporate register. Group structures change, and the acquisition of a vendor can change the contracting entity without changing anything we would see. If you are relying on a specific entity name for your own assessment, ask us at support@lodgehq.com.au and we will confirm it from the contract or tell you plainly that we cannot.

Where this sits in the Privacy Act. This page is how we give effect to Australian Privacy Principles 1.4(f) and 1.4(g) — the kinds of personal information we disclose to overseas recipients, and the countries they are in. It is the detail behind the overseas-disclosure section of our Privacy Policy (APP 8), and it exists so that you can see what we disclose and to whom before you decide whether our security arrangements are reasonable for your practice.

What this page is not. It is not advice about your own obligations. Where you connect one of your own accounts to LodgeHQ, we are not telling you where the APP 8 accountability line falls for your practice, because that depends on your arrangements and not on ours. We are telling you exactly what is sent and to whom, so that you can decide.

How to read the table

Sub-processor — a third party that stores or handles personal information on our behalf, or on your behalf at your direction.

Always on means the service is part of how LodgeHQ works. You cannot switch it off and keep using the platform. Firm-enabled means nothing is transmitted until an administrator at your firm connects an account.

Client case data means information about your clients: names, dates of birth, passport and travel-document numbers, transaction reference numbers, addresses, questionnaire answers, file notes, and uploaded documents such as passports, birth certificates, police clearances and English-test results.

Where processed. Where we can prove the region from configuration, we state it. Where we cannot, we say so and treat the service as an overseas disclosure. We do not describe a service as Australian because its vendor has an Australian office, and we do not treat an edge or content-delivery point of presence as a storage location.

LodgeHQ stores your practice’s records, your clients’ records and your uploaded documents in Australia — on Amazon Web Services infrastructure in the Sydney region (ap-southeast-2) — and AI processing runs on Amazon Bedrock in Australia (Sydney and Melbourne, ap-southeast-4). Some data does leave Australia. It leaves through parts of the platform that are always on — outbound email and its attachments, card payments, SMS and WhatsApp, browser push notifications, and document translation — and it leaves through optional integrations your practice chooses to connect, such as a mailbox, a calendar, an accounting connection or a cloud-storage mirror. Which data leaves, to which recipient, in which country and for what purpose is set out in the cross-border disclosure section of our Privacy Policy.

1. Core platform — always on

These are our own supplier choices. They apply to every firm on LodgeHQ and cannot be switched off firm by firm.

Note on Amazon Bedrock and Anthropic. Anthropic is the vendor of the Claude models we run, but under Amazon Bedrock, Anthropic is not a recipient of your data. AWS operates the model deployment accounts, and AWS’s published Bedrock terms state that model providers have no access to those accounts, to Bedrock logs, or to customer prompts and completions, and that Bedrock does not share inputs or outputs with model providers or use them to train models. We name Anthropic here because you should know whose model is reading your client’s passport; we do not list Anthropic as a recipient because it is not one.

Note on the Department of Home Affairs. DHA is not a sub-processor of ours — it is the regulator you lodge with, and the disclosure to it is one you make. We list it because omitting it from a register of where client data goes would be misleading.

2. Integrations your firm enables

Nothing in this section transmits anything until an administrator at your firm connects an account. When you connect one, you are choosing the recipient, and in most cases the destination is your own tenancy — your Dropbox, your Microsoft 365, your Xero. Your agreement with that provider governs where the data lands. We do not verify or control the region of an account you connect, and we cannot give you any assurance about what that provider does with the data once it arrives. We list them anyway, because they are still disclosures of your clients’ personal information and your clients are entitled to know they exist.

Files already copied cannot be recalled. Cloud Mirror writes into storage you control. If you disconnect it, we stop sending — but the files already in your Dropbox, Drive, OneDrive or WorkDrive are yours and stay there. That is the point of the feature, and it is also a limit on what disconnecting achieves.

3. Business operations

These support the business of selling and running LodgeHQ. Most of them handle your information as our subscriber rather than your clients’ information. One does not, and it is set out in full: Stripe receives your client’s email address and the description of your services whenever you invoice a client through LodgeHQ.

4. What we do not do, and services we do not use

This section exists because a register that only lists what we do use is half an answer. Everything below is a deliberate statement of absence, correct as at 4 August 2026.

We do not sell your data

We do not sell or rent personal information— yours or your clients’ — to anyone, and we do not disclose it to anyone for their own marketing purposes. We receive no payment or other benefit for any disclosure described on this page. For completeness, because the word “sell” gets used loosely: Apollo.io in section 3 is a sales-intelligence service we buy from, not one we supply. We send it a single email address to stop our own sales sequence, and we receive nothing for doing so. That flow is disclosed above rather than tucked behind this sentence.

We do not train AI on your client files

We do not use client case data to train, fine-tune or improve any AI model, and we have not licensed any sub-processor to do so. Our AI features run on Amazon Bedrock; AWS’s published Bedrock terms state that Bedrock does not use inputs or outputs to train models and does not share them with model providers. Data from a connected mailbox is used only to deliver the send and email-filing features you switched on — it is not used for advertising, is not sold or transferred, and is not used to train generalised AI or machine-learning models. Our use of information received from Google APIs complies with the Google API Services User Data Policy, including its Limited Use requirements. The limit of that statement: where you connect one of your own accounts under section 2, what that provider does with data in your own tenancy is governed by your agreement with them. We are not a party to it and we cannot warrant it.

Services people assume we use, and we do not

• Error monitoring. The error-monitoring service we previously used was removed from production on 14 July 2026 and has not been a recipient since. No credential for it exists in the production environment. It stayed on our disclosure list after it stopped being a recipient, and that is recorded in the change log because it is exactly the kind of drift this register exists to prevent.
• Third-party IP geolocation. Until 4 August 2026 an internal administration screen looked up login IP addresses through a free geolocation API with no published operator and no agreement with us. That lookup has been removed. The equivalent signal is now computed locally and never leaves our own infrastructure.
• GoHighLevel (CRM). Not in use. Integration code exists but no working credential is configured in production. No data is transmitted.
• MYOB (accounting). Not in use. An adapter exists but no working credential is configured in production, so no firm can complete the connection. Xero is the only live accounting integration.
• Meta WhatsApp Business (direct). Not in use. WhatsApp messaging runs through Twilio (section 1), not through a direct Meta connection.
• Resend (email delivery). No longer in the platform’s email path; removed 20 June 2026.
• Amazon SES. Provisioned but not in the mail path. Outbound email currently goes through the Google Workspace relay listed in section 1. If that changes, this register will be updated first.
• Google Fonts. Not in use. Fonts are served from our own origin; an external font load would be blocked by our content security policy.
• CyberCert / TAC Security. Not data recipients. CyberCert issued our SMB1001:2026 Level 3 (Gold) certification, which is certified against a director’s self-attestation — independent verification begins at the Platinum and Diamond levels. TAC Security performed our CASA Tier 2 assessment, which is a scanner-driven dynamic application security test together with a security questionnaire, and is not a manual penetration test. Neither organisation has an integration, a credential, or access to any customer or client data.

4A. A service we have stopped using that still holds data

We have separated this from section 4 deliberately. “We do not use it” and “it does not hold anything of ours” are different statements, and putting this in the list above would have implied the second.

Cloudflare R2 (Cloudflare, Inc., United States) is no longer a storage destination. R2 held our document storage until the move to AWS Sydney in July 2026, and the platform writes only to Amazon S3 in Sydney today — no R2 credential exists in the production environment. Copies written before the move have not been deleted.They include client documents, e-signature artefacts and historic database exports. The bucket is also still permitted by our content security policy. Deleting the contents, deleting the bucket, rotating the credentials and removing that permission are all recorded in section 8; this entry will be updated with the completion date. This row is the only reason the phrase “documents are stored only in Australia” does not appear anywhere on this page.

5. Objecting to a sub-processor

Integrations your firm enables (section 2). Disconnect it. An administrator can do this from LodgeHQ’s Settings without contacting us.

• Connected mailboxes — Settings → Email. Disconnecting revokes our tokens with the provider on a best-effort basis, deletes the stored connection and credentials, stops all further access, and purges synced mailbox content that has not been filed to a matter. Correspondence already filed to a matter stays in the case record, so that disconnecting an integration does not cut across your own file-retention obligations.
• Xero — disconnecting revokes our access grant with Xero and clears the stored connection. Records already written into your Xero organisation are yours and remain there.
• Cloud Mirror — disconnecting clears the stored access and refresh tokens from our systems and stops all further transfer, and we write a short note into the mirrored folder so that anyone looking at it knows the files have stopped updating. Two limits, both deliberate: it does not revoke our OAuth grant at the provider, so we recommend you also remove LodgeHQ from the connected-apps screen of that provider; and we keep the index of which files were already mirrored — file names and identifiers, not contents — so that reconnecting resumes rather than re-uploading everything. Files already mirrored remain in your own storage.
• Calendars and eWAY — disconnect in Settings; nothing further is transmitted.
• Social accounts and Zernio — disconnect the account in Settings and it is removed from the scheduler; nothing further is published.
• Bitrix24 — the connection is an inbound webhook URL you supplied. Revoking or deleting that webhook in your own Bitrix24 portal stops it immediately. Ask us at support@lodgehq.com.au if you also want the stored URL cleared from our side, and we will do it.

There is no penalty and no consequence beyond losing that feature.

Core platform and business operations (sections 1 and 3). These are not individually optional, and we will not pretend otherwise. LodgeHQ cannot run without its hosting provider, its database, its mail relay or its billing processor. If you object to one of them, tell us at support@lodgehq.com.au. We will tell you within five business days whether we can accommodate the objection — for example by disabling an optional feature that uses that service for your firm, or by changing our own configuration; tell you plainly if we cannot; and where we cannot, treat it as grounds for you to terminate without penalty. We will not charge an early-termination fee.

Taking your data with you. An administrator can request a firm-wide export from within LodgeHQ at any time, whether or not you are leaving, and it keeps working after a subscription lapses. It runs as a background job and produces a single archive containing your records in both JSON and CSV, the uploaded document files themselves, and a manifest listing what is in the archive and anything the run could not include. Platform credentials and access tokens are stripped; your casework is not.

A note on the AI features. AI processing currently has no firm-level off switch. If your practice requires one, tell us — we are tracking the request, and we will say so on this page if and when it is built rather than describing it before it exists.

We would rather lose a subscription than misrepresent what a service does.

6. Notice before we add a sub-processor

Before we engage a new sub-processor that will receive client case data, we will publish the new entry on this page with an effective date, and give at least 30 days’ notice before that entry takes effect, by an in-app announcement visible to firm administrators and by email to every current administrator address we hold. During those 30 days you may object under section 5. If we cannot accommodate the objection, you may terminate without penalty and export your data.

Where a shorter notice applies. For a change that does not involve client case data — for example replacing a marketing or analytics tool — we will publish the change here within 10 business days of it taking effect, without advance notice. Emergency substitutions to restore service will be published here within five business days of the change, with the reason. We would rather commit to a period we will actually meet than to one that reads better.

7. Who maintains this page

• Accountable owner: Awais Nisar, Director, LodgeHQ Pty Ltd
• Contact: support@lodgehq.com.au
• Review cadence: quarterly, and on every occasion a production credential for a new external service is added
• Method of review: the register is re-derived from the production source code and the live production configuration. A service is listed where a working credential exists in the running environment, or where a production code path sends data to it without one. The review is not a read-through of the previous version.
• Last full re-derivation: 4 August 2026

Why we are specific about this. Between March and August 2026 this list drifted twice: a provider we had stopped using stayed on it for three weeks, and services we had started using were never added. A list maintained by recollection will drift again. The commitments above — a named owner, a fixed cadence, and re-derivation from the running system rather than from the previous document — are the part of this page we ask you to hold us to.

8. Changes we have committed to and have not yet made

Everything in sections 1 to 4A describes the system as it runs today. This section is the opposite: it is work we have decided to do and have not done. Nothing here is a description of the current state. Each item moves into the change log with a date when it is finished.

• Delete the historic copies in Cloudflare R2, delete the bucket, rotate the credentials, and remove the bucket from our content security policy. Not done. Section 4A states the current position.
• Stop sending a booker’s email address to Apollo.io where the booking is a firm’s own client booking, so that the path applies only to LodgeHQ’s own sales enquiries. Not done. The exception in section 3 applies today.
• Establish and publish Zernio’s contracting entity and country. Not done. We have asked the vendor.
• Confirm and publish where the translation service actually runs. Not done. Until it is, that row stands as an overseas disclosure.
• Publish the translator panel that receives documents on a translation order, or a way for you to be told before you order. Not done.
• Confirm each contracting entity against the contract rather than against the vendor’s published terms, and mark each cell with which of the two it came from. Not done. See “Where the entity names come from” above.

9. Change log

• 4 August 2026 — this register first published. The list was re-derived from the production source code and live production configuration. Added, having not previously been disclosed anywhere: the Google Workspace SMTP relay and support mailbox; all four Cloud Mirror destinations; the translation service, its hosting platform and the translators downstream of it; IMAP mailboxes; Google, Microsoft and Apple calendars; Xero; eWAY; Bitrix24; Zernio; Google Ads; Apollo.io; Cloudflare; web push services; Have I Been Pwned; and the Department of Home Affairs. A named owner and a review cadence were assigned for the first time.
• 4 August 2026 — advertising tag restricted. The Google Ads tag was loaded by the application’s root layout, which meant it ran inside the signed-in application and on the client-facing pages we host for your clients. It is now restricted to our marketing website and sign-up page. The hardcoded conversion ID that made the documented kill switch inoperable was also removed.
• 4 August 2026 — third-party IP geolocation removed. An internal administration screen sent login IP addresses to a free geolocation API with no published operator and no agreement with us. The lookup has been deleted and the host removed from our content security policy.
• 4 August 2026 — portal access tokens stopped being serialised to the eLodge browser extension. Eight API routes returned the whole client-link record, which included the token that authorises a client’s questionnaire, status and document-upload links. It is now stripped server-side.
• 4 August 2026 — error-monitoring status recorded correctly. The service ceased to be a recipient on 14 July 2026 but continued to be named as one in our published disclosure list. That was a false statement of disclosure for three weeks.
• 27 July 2026 — SMB1001:2026 Level 3 (Gold) certification issued by CyberCert, certified against a director’s self-attestation. No change to the sub-processor list; recorded for completeness.
• 14 July 2026 — platform moved to AWS Sydney. Amazon S3 (ap-southeast-2) became the document storage destination; Cloudflare R2 ceased to be written to. The disclosure list was not updated at the time.
• 20 June 2026 — Resend removed from the platform and from the disclosure list.
• 8 March 2026 — first supplier disclosure published, inside the Privacy Policy. There was no standalone register.

Related pages

• Privacy Policy — including how personal information is collected, held and disclosed overseas
• Security — infrastructure, access control, certifications
• Terms of Service

Questions about anything on this page: support@lodgehq.com.au