Subprocessors

Glo, operated by Connor Wu trading as Glo, ABN 23 380 080 435.

This page lists every third party service that helps us run Glo, or that may run on the public pages where we advertise it, and that may handle personal information while it does. If you find something on it that is wrong, tell us at hello@welcomeglo.com and we will fix it.

This is the page our Privacy Policy relies on when it tells you which overseas recipients we are likely to disclose personal information to, and which countries they are likely to be in. Those are the disclosures Australian Privacy Principles 1.4(f) and (g) and 5.2(i) and (j) call for. Australian Privacy Principle 8 is a separate obligation, to take reasonable steps before we disclose anything overseas, and clause 3.2 is what we do about it.

---

1. What a subprocessor is, in plain terms#

We do not build everything ourselves. To run Glo we use a small number of other companies for things like hosting the software, storing the database, sending email and taking card payments. Those companies are our subprocessors. A subprocessor is a third party service we use to run Glo, which may handle personal information in the course of doing its job, on our instructions and under terms agreed with us. They are not free to do what they like with it. They do the one job we engaged them for, and nothing else.

Two things follow from that, and both are worth saying out loud:

• They are our responsibility, not yours. You did not choose them, so you should not have to chase them. If something goes wrong at one of them, you come to us.
• The shorter the list, the smaller the risk. Every extra provider is another place information can go and another company that has to be trusted. The list below is short on purpose, and we would rather it stayed that way.

---

2. Who this page is for#

If you are a business that uses Glo, this page tells you where your business data, and the personal information of your own clients that you have entered into Glo, actually goes. It is the page to read before you answer a question from one of your clients about it, and it is the page your accountant or your insurer will ask for.

If you are a client of a business that uses Glo, this page tells you who else may handle your name, your mobile number, your email address, your address and your messages while the booking you made is being run. It also covers the details of the thing the work is on, which Glo today records as a vehicle, including its registration. You do not have an account with us and you never signed up with us, but we still hold information about you, so you are entitled to know this.

Where this page fits with our other documents. Each is published at the address shown.

This page and our Privacy Policy are written to agree. This page carries the detail, the Privacy Policy carries the summary, and we update both in the same piece of work. If you ever find them disagreeing, tell us at hello@welcomeglo.com and we will fix it, and until we do, the Privacy Policy governs how we handle personal information.

How this page relates to your subscription agreement. Your subscription agreement is made up of six documents, in this order: the Terms of Service, the Refunds and Cancellations Policy, the Acceptable Use Policy, the Privacy Policy, the Data Processing Addendum, and the Plan you chose. The Terms come first, except that the Refunds and Cancellations Policy comes first on anything about refunds, cancellations or what happens when a payment fails, and the Data Processing Addendum comes first on our handling of personal information about your clients.

This page is a register rather than a seventh contract document. It does not need to be a contract document to bind us, because the commitments in section 8 below are also written into clause 16.2 of our Terms of Service: the 30 days' notice, the narrow urgent exception with its 7 day backstop, the exit right and the refund. So the notice period, the exit right and the refund in section 8 are promises you can hold us to as contract terms, whether or not you have signed a Data Processing Addendum with us, and whether or not you ever read this page.

---

3. The subprocessors we use today#

These are the providers that handle personal information for us, and this is the complete list. Address autocomplete is switched on, and clause 3.1 item 4 sets out exactly what is sent to Google and what is not. Our own public marketing pages, where we advertise Glo to businesses that might want it, may carry advertising tags from Meta and Google, and the providers behind those are rows in this table too. Where we use them, they handle information about somebody visiting those marketing pages and nothing else, they handle nothing about a business's clients, and clause 3.3 sets out exactly what that does and does not mean.

3.1 Five things about that table that are easy to miss#

1. Three of the providers in that table process in Australia, and that was a deliberate choice. The database is in Sydney, the rate limit counters are in Sydney, and our server functions are pinned to Sydney rather than left on a United States default. That is not a legal requirement. We did it because it is faster and because it keeps the data where the people it is about live.
2. Storing in Australia is not the same as staying in Australia. Vercel, Supabase and Upstash are all United States companies. Their own staff may be able to reach their systems from outside Australia. So we say the data is stored in Australia, which is true and verifiable, rather than that it stays in Australia, which we cannot verify. Section 5 deals with what that means for you.
3. We never see a card number. When a payment is made, the browser goes to Stripe's own page to take the card, and comes back afterwards. Card numbers are never sent to Glo, never stored by Glo, and are not in the database in any form.
4. Address autocomplete is switched on, and this is exactly what that means. When you type into an address box on a booking form, what you type goes from your browser straight to Google and never through our servers. Google receives the characters you type, a short-lived session token that ties one lookup together, the address you pick from the list, and the ordinary technical details of that request including your IP address. That is the whole of it. It is address suggestions and nothing more: no map is drawn, no address is turned into coordinates, no route is planned, and your location is never asked for or tracked. We deliberately do not load Google's map library either, so no Google script runs on the booking page and Google sets no cookie there. Nothing else about your booking travels with the lookup: not your name, not your phone number, not your email address, and not the job you are booking. If we ever switched autocomplete off, the address box would go back to being an ordinary text box, nothing at all would be sent to Google, and we would update this page to say so in the same piece of work.
5. A vehicle registration goes to the database and nowhere else. Where the work a business does is on vehicles, Glo records details of them, and today that means the make, model, year, size and registration. If we ever record another kind of item, we will update this page before we do. A registration recorded by a business is stored in the Supabase database in Sydney, and passes through Vercel on the way there like everything else typed into Glo. It stops there. It is never shown on any public page, the public booking form never asks for one, and it is never sent to Stripe, Resend, Upstash or Google.

3.2 What we require of every provider on this list#

There are two kinds of provider on this list, and what we require of each is not the same. Most of them are engaged to run the Service, and they handle a business's information and its clients' information because the job we gave them cannot be done without it. The two advertising rows, Meta and Google, are here for a different purpose entirely: the advertising tags our own public marketing pages may carry. Where we use them, they receive information about somebody visiting those pages and nothing else, and they never receive a business's information or a client's information at all. This page has covered them since 7 September 2026, and clause 8.7 sets out the addition in full. Because the two are engaged for different purposes, what we require of them is set out separately below. One sentence covering both would be true of neither.

The providers we engaged to run the Service. Before one of them handles anything, we satisfy ourselves that its published data protection terms require it to:

• handle personal information consistently with the Australian Privacy Principles;
• use it only to provide the service we engaged it for, and not for its own purposes;
• keep it secure, with measures appropriate to what it holds;
• pass equivalent obligations to anybody it uses in turn; and
• tell us about a security incident that affects it, so that we can assess it and tell you.

These are the providers' own published data protection terms, accepted by us, rather than terms negotiated line by line. What we do is choose providers that publish terms of that standard and refuse the ones that do not. Section 6 sets out how we choose, and clause 8.5 sets out what we do about the information a provider still holds after we stop using it.

The advertising providers, and the second requirement is the one that cannot apply to them. An advertising network uses what it collects for its own advertising purposes as well as for ours. That is what an advertising company is, no wording of ours changes it, and we will not print a promise here that its terms do not make. So what we require of Meta and Google is this instead, and most of it is a limit on us rather than on them:

• they will run only on our own public marketing pages, and on no page a business or a client is ever sent to;
• they will receive only what a visit to one of those pages carries: which page was opened, the ordinary technical details of that request, and the identifier each one sets in its own cookie;
• we send them nothing from inside Glo. No client, no client list, no booking, no upload of anybody's contact details, and nothing at all from the database. That is the requirement that matters most, and it is one we keep rather than one they promise;
• we still read what they publish before naming them here. We would not use a provider that did not commit to keeping what it holds secure, to binding anybody it uses in turn, and to handling personal information as the law requires of it; and
• if either is ever proposed for anything wider than that, it is a new use of a provider, and clause 8.7 and clauses 8.2 to 8.4 apply to it in full.

Those five requirements for the providers that run the Service are the same five, in the same words, as clause 8.2 of our Data Processing Addendum and clause 8.2 of our Privacy Policy. One standard, stated once. The two advertising rows are carved out of it in the same terms in all three places, and held to the separate list above, so there is still nothing to reconcile.

3.3 What no provider on this list does#

These are commitments, not descriptions of a feature, and they are here because they are the questions people actually ask:

• We do not sell or rent personal information to anybody, ever.
• No advertising tag, no session recorder and no third party tracking of any kind runs on a page your clients open. The public booking page, the tracking page, a public invoice, a public quote, an unsubscribe page and these legal pages carry no third party script and no third party frame at all. That is a boundary built into the product rather than a habit we have to remember to keep, and it applies page by page. Nothing a business's client can reach measures anything at all.
• Our own public marketing pages are the exception, and we would rather name it than have you find it. We pay to advertise Glo to businesses that might want it, and the marketing pages where we do that may carry an advertising tag from Meta and one from Google. Both have rows in the table above. Where we use them, what they receive is what any advertising tag on any marketing website receives: that a browser opened one of our marketing pages, with that request's ordinary technical details. What they never receive is anything from inside Glo: no booking, no client, no client list, no upload of anybody's contact details, and nothing at all from the database. The pages a client is sent to, the booking page, the tracking page, an invoice, a quote and an unsubscribe link, are not marketing pages and carry neither tag, so a client's details are not in this at any point. And the part of this worth being blunt about: an advertising network does not only work for us, it also uses what it collects for its own advertising purposes, which is exactly why we keep it off every page a client opens and would rather tell you that than let it read as an ordinary supplier arrangement.
• The one thing we measure inside the product, we measure ourselves, and no provider on this list touches it. Which parts of the signed-in dashboard our subscribing businesses use is recorded by Glo, stored in our own database, and sent to nobody. That measurement added no provider to this list when it was built, and that is an answer about the measurement only: the advertising in the bullet above is a different question, and it is why this list grew. See Privacy Policy clause 4.1 and Cookie Policy section 5.1.
• We do not market to a business's clients. Their clients are theirs.
• We do not send your information, or your clients' information, to an artificial intelligence provider, and no provider on this list is engaged to train a model on it.
• Only one provider holds the database, and that is what a database provider is. Supabase holds everything in the Supabase row above, because that is where Glo's records live. Every other provider on this list gets only the narrow slice its job needs: Upstash gets a key and a count, Resend gets the email it is sending, Twilio gets the text it is sending and the number it goes to, Stripe gets what a payment needs, Google gets an address as it is being typed and nothing else about the booking, an advertising tag gets a visit to one of our own marketing pages and nothing else, and Hostinger gets the email you chose to send us. None of them is given a copy of the database.

---

4. What is not on that list, and what happens when something joins it#

There is no separate storage provider, and clause 4.1 explains where receipt images live, because that is the question people ask next.

4.1 Where receipt images live#

Receipt images are stored inside the database, not in object storage.

When a business photographs a receipt and attaches it to an expense, that image is written into the Supabase database as part of the expense record. It is not uploaded to a separate storage service, and there is no storage provider in the picture at all. So a receipt image sits exactly where every other record sits: in the Sydney database, under the same protections, and covered by the Supabase row of the table in section 3.

This matters more than it sounds, for two reasons:

• A receipt can contain personal information by accident. A name, an address, a card's last four digits, sometimes more. So receipt images are handled as personal information, in the same way as everything else.
• Tax law requires a business to keep its records for at least five years, in English and readily accessible. The five years runs from when a record was prepared or obtained, or the transaction completed, whichever is later, and some records run longer: anything to do with a work vehicle has to survive for as long as you own it plus five years after you sell it. That obligation is yours, not ours, and we are not advising you on it. A record that lives behind a link to a service that might expire is not really a record, which is why the image itself sits next to the expense.

If we ever move receipt images to object storage, that is a new subprocessor handling personal information, and the commitment in section 8 applies to it in full.

4.2 What happens when we add a subprocessor#

The same thing, every time, in this order:

1. We satisfy ourselves the provider meets the tests in section 6.
2. We satisfy ourselves that the terms in section 3.2 are in place before anything is sent.
3. We add the provider to the table in section 3, and update the version line at the top and the change history in section 12.
4. We give notice under section 8, before it starts handling personal information.

This covers any new provider, whatever it does. A new capability does not get a shortcut around this section.

We are following it for the advertising providers, and this is the record. Meta and Google were added to the table in section 3 on 7 September 2026, which is step 3, and the version line at the top and the change history in section 12 were updated in the same piece of work. Step 4 is this page, published before either provider receives anything at all. Clause 8.7 sets out the addition in full: what the tags do, what they receive, what they never receive, and the exit right that goes with it.

---

5. Personal information that goes overseas, and why we stay responsible for it#

This section names the overseas recipients and their countries, which is what Australian Privacy Principles 1.4(g) and 5.2(j) require, and explains what we do about Australian Privacy Principle 8, which is the separate obligation to take reasonable steps to ensure an overseas recipient handles the information consistently with the Principles. Clause 3.2 is the reasonable steps. This clause is the disclosure.

5.1 Yes, some of it goes overseas#

We are likely to disclose personal information to recipients outside Australia. Specifically:

The countries those recipients are likely to be located in are the United States and Lithuania. Every provider named in the table above other than Hostinger is a United States company, and Hostinger is a Lithuanian company.

Each of these companies uses providers of its own, and some of those are in other countries. The annual review in clause 7 includes re-reading each provider's published subprocessor list, and we update this page as those answers change. If a particular country matters to a decision you are making, email hello@welcomeglo.com and we will tell you what we know.

If a provider will not tell us who it uses, that is a provider we cannot describe on this page, and criterion 3 in section 6 is what we do about it.

5.2 "Stored in Australia" and "stays in Australia" are different claims#

We will not blur them, because a lot of Australian software marketing does.

• What we can say and stand behind: the database is in Sydney, the rate limit store is in Sydney, and our server functions are pinned to Sydney.
• What we will not say: that the data never leaves Australia. Vercel, Supabase and Upstash are United States companies. Their staff and their own providers may be able to access their systems from outside Australia, and we have no way of proving otherwise.

So we treat every provider in section 3 as involving disclosure to an overseas recipient, and we apply the same requirements to all of them. Doing it that way costs us nothing and means this page does not depend on a claim we cannot check.

5.3 We stay accountable. This is the part that protects you#

Australian privacy law does not let a business hand personal information to an overseas provider and then point at the provider when something goes wrong.

We do not get to point at a provider. Where an entity is bound by the Privacy Act, section 16C means that if an overseas recipient it disclosed information to handles that information in a way that would breach the Australian Privacy Principles, the law treats it as the entity's own breach, and taking reasonable steps in a contract does not get it out of that. We commit to being answerable on that basis whether or not the section applies to us. If something goes wrong at one of these providers, you come to us, we assess it, we tell you, and we do not treat "it happened at a supplier" as an answer.

That is a commitment we are making to you here, in writing, and not a piece of law we are asking you to take on trust. It also explains the rest of this page: it is why the list is short, why we do not add a provider casually, why we keep what we can in Sydney, and why section 8 commits us to telling you before a new one starts.

We handle personal information in accordance with the Australian Privacy Principles. Where a clause on this page exists because that standard requires that kind of protection, we have said so.

---

6. How we choose a subprocessor#

The first question is always whether we need one at all. The best answer to "which provider should handle this?" is often "none of them". Receipt images are the example: adding a storage vendor to hold them would have been easy, and keeping them in the database we already had was better.

If we do need one, we look at:

1. Whether it needs personal information at all, and whether we can give it less. Upstash gets a key and a number, and that is all it needs.
2. Whether it can run in Australia. Where an Australian region exists and is practical, we take it. That is why three of the providers in section 3 are in Sydney.
3. What it publishes about its own security and its own subprocessors. A provider that will not say who it uses is a provider we cannot describe on this page, which makes it a poor fit.
4. Whether its published terms meet section 3.2. If a provider's terms do not say that it handles personal information consistently with the Australian Privacy Principles, uses it only for our job, secures it, binds its own providers, and tells us about incidents, we do not use it. That test is for a provider we are engaging to run the Service, and the two advertising rows in section 3 are not that. They are engaged to advertise Glo on our own pages, they are never given anything a business or a client put into Glo, and what we require of them instead is the separate list in clause 3.2. We would rather say that plainly than claim they passed a test they were never set.
5. Whether we could leave. A provider we could not migrate away from is a risk in itself, not just a supplier.
6. Whether the benefit is worth it. Address autocomplete removes a real source of wrong addresses and duplicate records, which is why it is built, switched on and on this page. A map on the booking page would not have earned the extra disclosure, so we did not build one, and geocoding, routing and location tracking did not earn it either.

How we answer those questions. We rely on what a provider publishes about its security and its own subprocessors, and on the terms we accept from it.

---

7. How we review a subprocessor#

What we do:

• We re-read this page whenever the Service changes, and we treat a change that touches a provider as a reason to update it in the same piece of work.
• We review the whole list at least once a year, whether or not anything has changed, and we add a row to section 12 even where the answer is "no change". That review includes re-reading each provider's published subprocessor list.
• We read the notices our providers send about security incidents, changes to their own subprocessors, and changes to their terms.
• If a provider has a security incident that affects information we hold, we assess it the same way we would assess our own. We tell an affected business within 24 hours of first having reasonable grounds to suspect a breach affecting their data, whether or not we have finished working out what happened, and within a further 24 hours of concluding that there are reasonable grounds to believe it is an eligible data breach. Those are the numbers in clause 7.2 of our Data Processing Addendum, because there should only ever be one set. We notify the Office of the Australian Information Commissioner and affected individuals under the Notifiable Data Breaches scheme where the test is met. A separate and different clock applies to that assessment: the scheme allows a maximum of 30 days to assess whether a suspected breach is an eligible data breach, and we treat that as a maximum rather than as a target. We will not treat "it happened at a supplier" as a reason not to tell you, and we will not repeat a provider's press release to you as though it were our own assessment.
• If a provider we engaged to run the Service stops meeting the requirements for those providers in clause 3.2, we replace it. That is the point of criterion 5 in section 6. The two advertising rows are held to the separate requirements in clause 3.2 instead, because they do not run the Service, and if either stopped meeting those the answer is simpler: the tag comes off our pages. Taking one off is a removal under clause 8.5, and it needs nobody's agreement but ours.

If you have asked us a question about one of these providers and we do not know the answer, we will tell you that we do not know rather than guess.

---

8. When we add, change or remove a subprocessor#

This is the commitment that makes this page worth having, and it is the standard our Data Processing Addendum refers to.

8.1 We update this page before a new subprocessor starts handling personal information, not afterwards. That is the core promise. A page that is updated after the fact is a record, not a disclosure.

8.2 We give you at least 30 days' notice. Where we intend to engage a new subprocessor that will handle personal information, or to start sending personal information to a provider already named here that was not receiving it, we will email the address on the account at least 30 days before it starts, and tell you which provider, what it will do, what it will handle, and where it will process.

8.3 There is an exception, and here is exactly how narrow it is. If a provider fails, withdraws its service, or has to be replaced urgently to keep the Service secure or running, we may act with less than 30 days' notice. If that happens:

• we will tell you as soon as we reasonably can, and in any event within 7 days of the change;
• we will tell you what happened, what moved, and where it went; and
• the exit right in clause 8.4 applies in full for 30 days after the day we tell you, refund included. Because an urgent change has already happened by the time you hear about it, "cancel before it takes effect" cannot apply to it, so instead you get a clear 30 day window running from our email, in which you may cancel, we refund the unused part of anything you have paid, and you keep the free records download. An urgent change never costs you the chance to respond.

We will not use this exception to avoid giving notice for a change we had time to plan. Convenience is not an emergency and a better price is not an emergency.

8.4 If you are not comfortable with a new subprocessor, you can leave. We cannot offer a per-customer opt-out: the Service runs on one stack for everybody, so a business cannot have its own database in a different country. What we do commit to is this:

• you may cancel before the change takes effect, with no exit fee and no notice period. Where you are hearing about the change after it happened under clause 8.3, you have 30 days from the day we tell you instead;
• we refund the unused part of anything you have already paid for. That refund is the point of this clause: you should not be left paying for months of a service you told us you did not want. It is the same refund as clause 16.2 of our Terms of Service, which covers exactly this change, and clause 15.5, which covers a change that takes something away generally; and
• you may download your financial records first, free, from /dashboard/finances/records, whatever your billing status. That download covers your invoices, invoice lines, payments, expenses, adjustment notes, vehicle logbook and transactions. For your client list, your bookings or your message threads, email hello@welcomeglo.com and we will put them together for you within 10 business days, free.

That right exists because a change you did not choose should not be a change you cannot escape. It is also why we would rather over-notify than under-notify.

8.5 Removing a provider. If we stop using a provider, we take this page down to match, and we say so here. Removing a provider is not a change that needs 30 days' notice, because it reduces the number of places information goes rather than adding one.

When we stop using a provider, we ask it to return or delete what it holds for us, and we use whatever deletion route its terms provide. That is a commitment we make, using the mechanisms the provider publishes, rather than a bespoke clause we negotiated.

Replacing a provider is not removing one. If we stop using a provider and start using a different one for the same job, that is a new subprocessor and clauses 8.2 to 8.4 apply to it in full: 30 days' notice, the exit right, and the refund. We will not describe a swap as a removal in order to avoid giving you notice.

8.6 A change of the same provider's location is a change. If a provider moved our data out of Sydney, that would be a material change to this page and clauses 8.2 to 8.4 would apply to it in full, even though the provider's name had not changed.

8.7 What we will never do. We will not add a provider that uses personal information for its own purposes, an advertising or analytics provider, or a provider that would take the database out of Australia, and then tell you about it afterwards. If any of those is ever proposed, it comes with notice, an explanation, and the exit right above.

On 7 September 2026 we decided to add advertising providers, Meta and Google. That is exactly the kind of change this clause is about, so here is the whole of it rather than a line in a table, and here is how each of the three things this clause requires is being done.

The notice. This page is the notice, and it is the notice from 7 September 2026, the day version 1.2 of this page was published. Our own public marketing pages may carry an advertising tag from each of them, and neither tag ever runs anywhere else in Glo. We are telling you which providers, what they do, what they handle and where they process, rather than letting you find it afterwards, which is the difference this clause turns on.

The explanation. The tags belong on our own public marketing pages, which is where we sell Glo to businesses that might want it, so that we can tell whether an advertisement we paid for brought somebody here. Where we use them, what they receive is that somebody's browser opened one of those pages, and nothing else. They receive nothing from inside Glo and nothing about your clients, and none of the pages we send your clients to carries either tag. The table in section 3 sets out what each one handles, clause 3.2 sets out what we require of them and what we will never send them, and clause 3.3 sets out what stays off your clients' pages permanently.

The exit right. The exit right in clause 8.4 applies to this in full, so if you are not comfortable with it you may cancel, with no exit fee and no notice period, we refund the unused part of anything you have already paid, and you keep the free records download in clause 8.4. You have 30 days from 7 September 2026 to decide, and you do not have to give us a reason. Clause 8.3's urgent exception is not being used here and could not be: nothing about this was an emergency.

We are not treating this as a smaller change because it happens on our own pages rather than yours. Adding a provider is adding a provider.

On 10 September 2026 we added Twilio, to send the three text messages about a booking. The table in section 3 has named it since that day, but this page did not give the notice clause 8.2 requires, and the other documents that list our providers did not name it. Our email about version 1.3 of this page is that notice. The exit right in clause 8.4 applies in full, and you have 30 days from that email to decide.

8.8 Telling your clients. The people whose personal information actually travels to a new provider are usually your clients, not you, so the notice cannot stop with the account holder. When we tell you about a new subprocessor under clause 8.2:

• we update this page and, where a collection notice sits under your booking form, we update that notice in the same piece of work, so anybody who books with you sees the current answer;
• we ask you to pass the notice on to any client who has asked you where their details go, and clause 8.4 of our Data Processing Addendum asks you to describe it to your own clients the same way we describe it to you; and
• we do not email your clients ourselves. They are your clients, not ours, and clause 3.3 is why: we do not market to them, and an unexpected email from a software company they have never heard of is not a privacy improvement.

Anybody at all can also ask to be told directly. Clause 9 says how, and it is open to a client of a business that uses Glo on exactly the same terms as it is open to that business itself.

---

9. How to be told when this page changes#

If you are a business that uses Glo, there is nothing to sign up to. We email the address on your account, under clause 8.2. Keep that address current and you will get the notice.

If you are anybody else, including a client of a business that uses Glo, an accountant, an insurer or somebody doing due diligence on us, email hello@welcomeglo.com with "subprocessor notices" in the subject and we will add you to the list we notify. It is free, we use the address for nothing else, and you can come off the list at any time by replying and asking.

What a notice looks like. Every subprocessor notice we send names us, gives our ABN and a contact address that will still work at least 30 days later, carries no promotion of any kind, and tells you in the message itself how to come off the list. We act on a request to come off within five business days, and usually the same day. That is the standard the Spam Act sets for an unsubscribe: Schedule 2 clause 6 of the Act expresses it as five business days, and the regulator's public guidance renders the same rule as five working days. We send these from a real address you can reply to, never a no-reply address, because an unsubscribe route that cannot receive a reply is not an unsubscribe route.

And you can always just read this page. The version line at the top tells you which version you are looking at and the date it took effect, and section 12 records what changed and when. If you want the version of this page that applied on a particular date, ask us and we will send it to you.

---

10. If we have a Data Processing Addendum with you#

Some businesses that use Glo, and some of their own larger customers, need a written data processing agreement. Where we have entered into a Data Processing Addendum with you:

• this page is the list of authorised subprocessors that the Addendum refers to;
• clause 8 is the notice mechanism that the Addendum refers to, including the 30 day period, the narrow urgent exception, the 30 day window that replaces it, the exit right and the refund; and
• clause 8.2 of the Addendum sets out what we require of each provider. Clause 3.2 of this page states the same five requirements in the same words, so there is one standard and not two.

The Addendum sits at /legal/data-processing. If a term of the Addendum and a statement on this page ever conflict, the Addendum governs the contract between us, and this page remains the current factual list. Nothing in this clause makes clause 8 less binding on us for a business that has not signed an Addendum: clause 16.2 of our Terms of Service carries the same commitments for every business that uses Glo, and section 2 above explains how that fits together.

---

11. Questions, corrections and complaints#

If you think something on this page is wrong, tell us. A factual disclosure page that nobody checks is not much use, and we would rather hear it from you than find it ourselves later.

If you want to know exactly what one of these providers holds about you, ask. Your right to access and correct the personal information we hold is set out in our Privacy Policy, it applies whether you are a business that uses Glo or a client of one, and it is free to ask.

• Email: hello@welcomeglo.com
• Post: Connor Wu trading as Glo, Unit B14, 161 Arthur Street, Homebush West NSW 2140

A real person reads that inbox and will reply. It is not a no-reply address, and the table in section 3 tells you who else handles what you send to it.

If you are not satisfied with how we have handled a privacy question, our Privacy Policy sets out our complaints process, and you can also complain to the Office of the Australian Information Commissioner at oaic.gov.au. Telling us first usually gets it fixed faster, but nothing on this page requires you to come to us before you go to them, and nothing on this page limits any right you have under the Privacy Act 1988 or the Australian Consumer Law.

---

12. Change history#

We add a row here every time this page changes, including when a review under clause 7 finds nothing to change.

---