For businesses using Glo
Glo Data Processing Addendum
For a business that needs one in writing: how Glo handles personal information about that business's own customers, on its instructions.
Version 1.5. Effective 1 October 2026.
This Addendum forms part of the Glo Terms of Service. It sets out the terms on which we handle personal information about your clients on your behalf.
Glo is operated by Connor Wu trading as Glo, ABN 23 380 080 435, of Unit B14, 161 Arthur Street, Homebush West NSW 2140. You can reach us at hello@welcomeglo.com.
You do not need to sign anything for this Addendum to apply. It applies automatically to every Glo account, from the moment the account is created. Clause 12.4 explains how to get a countersigned copy if a customer of yours asks you for one.
The short version
This summary is here so you can see the shape of the Addendum quickly. It is a summary and nothing more. It does not change, limit or add to the numbered clauses below, and where the two differ the numbered clauses are the agreement.
- You decide what you record about your clients, and why. We hold it for you. Clause 3.
- This Addendum covers your clients' information, not your own account information. For your own account we act for ourselves, and the Privacy Policy covers that. Clause 1.4.
- We only handle your clients' information to run Glo for you, plus a short, closed list of things we do for our own reasons: keeping Glo secure, fixing faults, answering support, meeting the law, and defending a claim. Clause 3.5 sets out that list in full and clause 3.6 sets out what we never do.
- We tell you about a data breach fast. Within 24 hours of first having reasonable grounds to suspect one, not 24 hours after we have worked it out. Clause 7.2.
- You get 30 days' notice before a new subprocessor touches anything, and if you do not like it you can leave with a refund of the unused part. Clause 8.6.
- Your records are never deleted as a punishment, and there is a permanent free download of your financial records that keeps working even when your account is locked. Your client, vehicle, booking and message records are not in that download, and we will produce them for you on request. Clauses 9.3 and 9.4.
- We will answer your questions about how we handle this information in writing, within 30 days. We do not offer an on-site audit right. Clause 10.
- You can ask us for your own account's audit log entries and we will send them to you. The log is append only. Clauses 5.3 and 10.4.
- If you think we have got something wrong, there is a complaints route with the same timeframes, it is free, and there is no limit on how often you can use it. Clause 5.10.
- Our privacy and security obligations to you are not capped. Clause 19.3 of the Terms carves them out of the liability limit, and clause 11.2 says so again here.
- If you or your clients ever come under European or United Kingdom privacy law, Annex A switches on. It is already written, except for the transfer mechanism in Schedule 1, which has to be completed and countersigned before any actual transfer. Clause A.7 says so plainly.
1. What this Addendum is, and when it applies
1.1 Who this is between
This Addendum is between Connor Wu trading as Glo, ABN 23 380 080 435, which operates the Glo software ("we", "us", "our"), and you, the business that holds a Glo account.
It is part of your agreement with us. It is not a separate contract and it does not create a separate relationship. Clause 3.2 of the Terms names this Addendum as part of the agreement and clause 30.1 of the Terms says the same, so this is not a claim this document makes about itself unilaterally.
1.2 Why this document exists
Glo is a tool you use to run your own business. When you use it, you put personal information about other people into it: your clients' names, mobile numbers, email addresses, the street addresses you do work at, the things you work on, which the Service records today as vehicles, their bookings, your messages with them, and the invoices and quotes you send them.
Those people are not our customers. They never signed up with us, they never agreed to anything with us, and most of them will never know our name. You decided to collect that information, and you decided what to do with it. We hold it and handle it for you so that Glo can do its job.
That split needs to be written down for three reasons, and all three are yours:
- So you know exactly what we may and may not do with your clients' information. Clause 3.5 is a closed list, and clause 3.6 is a list of things we never do.
- So you have something to hand a client who asks. If you take work from a larger organisation, for example a corporate fleet, a dealership, a hire company, a council or a large employer, their procurement people will eventually ask you who holds their staff's or their customers' details and on what terms. This document is that answer, and you can send them the link.
- So the roles are settled before something goes wrong, rather than argued about during an incident. Clause 7 allocates the data breach work in advance.
1.3 What this Addendum covers
This Addendum covers Client Personal Information, defined in clause 2.3. In short, that is personal information about your clients and about any other individual whose details you or your team put into Glo, which we handle on your behalf so we can supply the Service.
1.4 What this Addendum does not cover
It does not cover your own account information. That includes your name, your email address, your password, your phone number, your business details, your ABN, your GST status, your booking settings, your subscription and billing records with us, your sign-in security records, and your correspondence with us.
For all of that, we act for ourselves, not on your instruction. We decide what we collect and why, we answer for it directly, and our Privacy Policy is the document that governs it. Clause 2.3 of the Privacy Policy sets the same split out from the other direction.
The same goes for the account information of the people on your team. A User's login, role, and sign-in security records are part of your account with us and sit outside this Addendum. If you need that included for a reason of your own, tell us at hello@welcomeglo.com and we will talk about it.
It also does not cover:
- what you do with your clients' information outside Glo, such as a paper diary, a spreadsheet on your laptop, or a text you send from your own phone;
- information that is not personal information, including aggregate counts and totals that cannot be connected back to any individual;
- your contract with your client, which is yours, on your terms, under clause 9.4 of the Terms.
1.5 Some records sit on both sides, and we treat them protectively
A few records mix the two. An audit log entry records one of your people doing something to your client's record. A message thread has your words on one side and your client's on the other. A receipt image is your business record that may happen to carry somebody else's name.
We do not try to split those apart clause by clause. Where a record contains both, we apply whichever of this Addendum and the Privacy Policy gives the individual more protection. That rule is here so nobody, including us, can use the boundary as a gap.
1.6 When it applies
This Addendum applies from the moment your Account is created, for as long as we hold any Client Personal Information for you, and for the parts of it that survive under clause 12.5.
It applies whether or not you asked for it, and whether or not you or we have signed anything.
1.7 How this fits with the rest of the agreement
The Terms of Service are the agreement. The Privacy Policy says what we do with personal information generally. This Addendum says what we do with your clients' personal information specifically, and on what instruction.
Clause 3.2 of the Terms is the precedence rule, and this clause restates it rather than inventing a second one. Your agreement with us about your Subscription is made up of six things, and this is the order they come in:
- the Terms of Service;
- the Refunds and Cancellations Policy;
- the Acceptable Use Policy;
- the Privacy Policy;
- this Data Processing Addendum; and
- the Plan you chose.
If they conflict, 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;
- this Addendum comes first on our handling of personal information about your Clients;
- the Privacy Policy always governs how we handle personal information, including all of the information in clause 1.4; and
- where any of those documents gives you a shorter timeframe, a larger refund or a stronger protection than the Terms, that document applies. A precedence rule exists to resolve a genuine conflict, not to cut down a promise we have already published to you.
Two other documents sit inside that list rather than beside it. The Cookie Policy is read as part of the Privacy Policy. The subprocessors page is read as part of this Addendum, and it is the register clause 8 relies on.
Two documents are not part of your agreement with us at all. The Client Terms and the SMS terms govern a different relationship, between us and your client. Neither of them is part of your Subscription agreement, and clauses 2.18 and 2.19 of the Terms say the same.
Nothing in this Addendum reduces a right you have under the Terms, and clause 11.2 says so about the liability limits in particular.
2. The words we use
We have written these definitions to Australian privacy law first, because that is the law that applies to you and to us. Where a word from European or United Kingdom privacy law means roughly the same thing, we have put it in brackets, so that this document still makes sense to somebody trained on those laws and so that Annex A can switch on without anything above it being rewritten.
2.1 The Privacy Act means the Privacy Act 1988 (Cth). The APPs or the Australian Privacy Principles means the 13 principles in Schedule 1 to that Act. The OAIC means the Office of the Australian Information Commissioner.
2.2 Personal information has the meaning it has in the Privacy Act: information or an opinion about an identified individual, or an individual who is reasonably identifiable, whether or not it is true and whether or not it is recorded in a material form. (GDPR and UK GDPR: personal data.)
2.3 Client Personal Information means personal information that we handle on your behalf in supplying the Service, being:
- personal information about your Clients, as defined in clause 2.6 of the Terms; and
- personal information about any other individual whose details you or your Users put into the Service, or cause to be put into it, including a person named in a note, a person named on a receipt image you upload, a contact at a business client, and a person named in a message thread.
It does not include anything in clause 1.4.
2.4 Sensitive information has the meaning it has in the Privacy Act. It includes health information, racial or ethnic origin, political opinions, religious beliefs, sexual orientation, criminal record and biometric information. (GDPR and UK GDPR: special category data, plus criminal offence data under Article 10.) Clause 6.3 is about this and you should read it.
2.5 Handle and handling mean anything we do with personal information, including collecting it, holding it, storing it, using it, organising it, transmitting it, showing it to somebody, changing it, exporting it, de-identifying it and destroying it. (GDPR and UK GDPR: processing.)
2.6 You decide, we act on your instruction. Australian privacy law does not use the words "controller" and "processor", so this Addendum does not build itself on them. What it says instead is the same thing in plain English: you decide what personal information is collected about your clients and what it is for, and we handle it on your instruction to supply the Service. (GDPR and UK GDPR: you are the controller and we are the processor of Client Personal Information. For the information in clause 1.4 we would be the controller in our own right.)
2.7 Your Instructions means, together: this Addendum; the Terms; the Privacy Policy; the settings, options and configuration you choose inside the Service; the actions you and your Users take in the Service; and any further written instruction you give us that we accept in writing. Clause 3.4 explains how a further instruction works.
2.8 A Subprocessor means an outside service we use to run Glo that may handle Client Personal Information while it does its job. The current list is published at /legal/subprocessors, and the providers connected as at the date of this Addendum are also named in clause 8.4. (GDPR and UK GDPR: sub-processor, Article 28(2) and (4).)
2.9 A Data Breach means unauthorised access to, or unauthorised disclosure of, personal information we hold, or the loss of personal information we hold in circumstances where unauthorised access or disclosure is likely to occur. (GDPR and UK GDPR: personal data breach, Article 4(12).)
2.10 An Eligible Data Breach has the meaning it has in Part IIIC of the Privacy Act: a Data Breach that a reasonable person would conclude is likely to result in serious harm to any of the individuals it relates to, where remedial action has not prevented that likely serious harm. The NDB scheme means the Notifiable Data Breaches scheme in that Part.
2.11 An Individual means a living person that personal information is about. (GDPR and UK GDPR: data subject.)
2.12 A Privacy Request means a request or a complaint from an Individual about their own personal information, including a request for a copy of it, a request to correct it, a request to delete it, a request to stop marketing, a question about where it went, or a complaint about how it has been handled. (GDPR and UK GDPR: a data subject rights request under Chapter III.) A complaint from you, about our handling, is dealt with under clause 5.10 rather than under clause 5.5.
2.13 Words defined in the Terms have the same meaning here. The ones used most in this Addendum are the Service, a Glo App, Your Account, a User, a Client, Your Data, Finances, the Records Download, the Records Export, your Subscription and Stripe. Clause 2 of the Terms defines each of them. Two of those definitions matter here and are worth repeating: the Records Download and the Records Export are both defined in the Terms as covering your financial records. Neither of them contains Client Personal Information, and clause 9.4 of this Addendum says what that means for you.
2.14 Medium neutral, on purpose. "The Service" is defined in the Terms to cover Glo however you reach it: a browser, any Glo App we publish, any interface or API we make available, and any page we host for you or for your clients. This Addendum uses that definition deliberately, so that it keeps saying something true if we later add a mobile app, push notifications, or a connection to another business system such as accounting software. Nothing in this Addendum says that any of those exists today. Glo does send text messages about a booking, and clauses 6.6 and 8.4 say what goes where. Where a clause says "where we provide" something or "if you use" something, that is a conditional, not a claim.
2.15 A reference to writing includes email. Money is in Australian dollars. Times are Australian Eastern time.
3. Who decides what: the roles
3.1 You decide
You decide what personal information is collected about your clients, and what it is for. Concretely, you decide:
- which clients you take on and which you keep records about;
- what your booking form asks for, within the fields Glo offers;
- what you write in a free text note about a client or a vehicle;
- what services, prices, deposits and discount codes you offer;
- what your own terms and conditions and cancellation policy say;
- who on your team can see what, by choosing their role;
- whether to record a marketing preference for a client;
- what you upload, including receipt images;
- what you say in a message to a client;
- when to archive a client, and when to ask us to delete something.
None of those decisions is ours, and we do not make any of them for you.
3.2 We handle it to supply the Service to you
We handle Client Personal Information only to supply the Service to you, on Your Instructions, and for the narrow additional purposes in clause 3.5.
Supplying the Service means the things Glo actually does: running your dashboard, publishing your booking page, taking bookings on it, working out prices from your own rules, running the tracking pages, running the message threads, sending the service emails about a booking or a document, where you have connected Stripe, taking deposits and payments through it, producing your invoices, adjustment notes, quotes and reports, holding your expenses, receipt images and logbook entries, and giving you the exports described in clause 9.4.
3.3 We do not decide what you collect
We do not tell you what to record about a client, we do not enrich your records from anywhere, we do not buy data, and we do not look up a person, a vehicle or a registration against any outside source. What is in your account is what you and your clients put there.
3.4 What counts as an instruction, and what happens if you give us a new one
Your Instructions are defined in clause 2.7. Using a feature is an instruction. When you turn on deposits, invite a staff member, send a message, issue an invoice or export a report, you have instructed us to handle the information that feature needs.
If you want us to do something outside that, email hello@welcomeglo.com. We will either confirm in writing that we will do it, or tell you we will not and why. We will not charge you for a request that takes us a few minutes. If a request would take real work, or would need us to build something, we will tell you what it involves and what it would cost before we start, and you can say no.
3.5 Where we handle it for our own reasons, and this is the complete list
Here is the list, and it is closed. Beyond supplying the Service to you, we handle Client Personal Information only:
| What we do | What it uses | Why |
|---|---|---|
| Keep the Service secure and stop abuse | Sign-in events, IP addresses, browser user agent strings, the audit log | So one business cannot reach another's data, and so we can see what happened if something goes wrong |
| Keep the audit log | The action taken, when, by whom, an IP address, and a record of the details of the action | It is append only. We do not change or delete entries. It is your evidence as much as ours, and we will send you your own account's entries on request under clause 10.2 |
| Diagnose and fix a fault | Whatever the fault touches, and no more | This is part of running the Service. Clause 7.5 of the Privacy Policy sets out our access rule and the audit trail behind it |
| Answer a support request | Whatever is in the request, plus enough of the account to find the problem | Including a support request that comes from one of your clients rather than from you |
| Meet a legal obligation of our own | Account, billing and transaction records | Principally the tax record keeping rules. Clause 9 has the detail |
| Deal with a serious threat, or suspected unlawful activity | Whatever is relevant | Lessening or preventing a serious threat to somebody's life, health or safety, or taking appropriate action about suspected unlawful activity or serious misconduct |
| Establish, exercise or defend a legal claim, or get legal advice | Whatever is relevant | Ours or yours |
That is the whole list. It matches clause 7.3 of our Privacy Policy, because the two documents are meant to say the same thing.
A note on "improving the Service", since most addendums claim it. We are not claiming it. We do not mine your client list for product ideas, we do not build benchmarks out of it, and we do not use it to train anything. Product work here runs on aggregate operational information that is not personal information, such as how often a page errors and how long a query takes. If that ever changes we will describe exactly what changed rather than quietly widen this clause.
A note on fraud prevention. Ours is the security work in the first two rows of that table. The risk checks that happen on a card payment are Stripe's, made on Stripe's own systems under Stripe's own terms, for Stripe's own reasons. They are not ours and we do not direct them. Clause 18.5 of the Privacy Policy says the same.
3.6 What we never do with it
- We never sell or rent personal information. Ever, to anybody.
- We never market anything to your clients, ours or anybody else's.
- We never use your clients' information to train machine learning models, ours or a third party's.
- We never build a separate product, benchmark or data set out of what you put into Glo.
- We never share information between the businesses that use Glo. Every record in Glo belongs to exactly one business and there are no cross-business lookups.
- We never use it for our own marketing, including to work out who to sell Glo to.
3.7 We are still directly answerable, and that protects you
Handling your clients' information on your instruction does not make us a bystander. Under Australian law we hold that information, so we are directly answerable for how we secure it and how we deal with a request or a complaint about it, whatever this Addendum says about who decided what.
Two things follow, and both are for the benefit of your clients and therefore of you:
- Your clients can come to us directly. We will not turn a client away and tell them to go to you. Clause 13.3 of the Privacy Policy explains why coming to you first is usually faster for them, and clause 5.5 below explains how we work with you on it.
- The statutory right to sue for a serious invasion of privacy applies to us, whatever our size, and it is available to your clients directly against us, with no need to go through the OAIC and no need to prove loss. Its shape matters: it reaches a deliberate or reckless invasion, not an ordinary security failure caused by somebody else. A database broken into by an outsider is not, without more, an intentional or reckless invasion by the business that was broken into. So it is not the answer to a break-in. It is the answer to us doing something with your clients' information on purpose that we should not, which is why clause 3.6 is written as flatly as it is and why clause 5.3 exists.
3.8 We are not your privacy adviser
We can tell you what Glo does with information. We cannot tell you what your own privacy obligations are, whether a particular collection is lawful for you, or what your collection notice should say. That is advice about your business and we do not give it. Clause 13.5 of the Terms says the same about tax, accounting, financial and legal advice generally.
4. What we handle, why, for whom, and for how long
This clause sets out the shape of the handling in one place, so you can hand it to somebody who asks without them having to read the whole document.
| Subject matter | Handling Client Personal Information so that we can supply the Glo software to you |
| Nature of the handling | Collecting through pages we host for you and for your clients, storing, organising, retrieving, displaying, transmitting, sending emails, generating documents and exports, restricting, archiving, de-identifying and destroying |
| Purpose | Supplying the Service to you under the Terms, on Your Instructions, plus the closed list in clause 3.5 |
| Duration | For as long as your Account exists, and afterwards for the retention periods in clause 9 |
| Types of personal information | Name; mobile number in E.164 format and whether it was verified; email address; billing email address; billing address; ABN where the client is a business; the free text notes you write; a marketing preference flag; details of the things you work on, which the Service records today as vehicles, being make, model, year, colour, size class, how the size class was decided, whether a person has approved that size, notes and registration, and if we ever record another kind of item we will update this Addendum before we do; the full street address the work happens at and, where the address was picked from a Google suggestion, the Google place identifier for it; booking date, time, notes, service and add-on lines and their prices, deposit, discount code and amount, status and how the booking ended; message content and read times; payment amounts, methods, statuses, timings, references and the payment provider's identifiers; invoices, adjustment notes and quotes and the details frozen onto them; expense records and receipt images; vehicle logbook entries; in-app notifications; audit log entries including IP addresses; and the tokens behind the public links |
| Categories of Individual | Your clients, whether individuals or people at a business client; anybody else you name in a note, a message, a receipt image or a logbook entry |
| Sensitive information | None is asked for and none should be entered. See clause 6.3 |
| Card numbers | Never. Card details are typed on Stripe's own pages, which are a full page redirect away from Glo. We never see a card number and never store one |
| Where it is stored | Our database and the systems that run Glo are hosted in Sydney, Australia. Clause 8.4 sets out which providers are overseas recipients and which of them also process outside Australia |
If you need this table as a standalone record for your own privacy register, ask at hello@welcomeglo.com and we will send it to you.
5. What we promise to do
5.1 We handle it only on your instruction, or where the law requires it
We handle Client Personal Information only on Your Instructions and for the purposes in clause 3.5, unless an Australian law, or a court or tribunal order, requires us to do something else.
If the law requires us to do something else, we will tell you before we do it, unless the law forbids us from telling you. If we are forbidden, we will tell you as soon as we are allowed to.
We do not hand over information because somebody asked nicely. If a law enforcement agency or a regulator makes a request, we check that it is valid and that it covers what is being asked for, and we give only what it covers. Clause 8.6 of the Privacy Policy sets that out in full.
5.2 If we think an instruction is unlawful, we tell you
If we form the view that something you have instructed us to do would breach the Privacy Act or another law, we will tell you promptly and we will not do it until it is sorted out.
We will say what our concern is and why. We are not your lawyer and we may be wrong, so this is a conversation, not a ruling. But we would rather have the conversation than quietly do something neither of us can defend.
5.3 Our people keep it confidential
Everyone who can reach Client Personal Information, whether an employee, a contractor or the owner, is under an obligation of confidentiality that continues after they stop working on Glo.
We do not look at a business's data except where it is needed to run the Service, to answer a support request, or where we are required to by law. Two things back that up rather than leaving it as a promise:
- actions taken in your account are written to the audit log, and an operator's actions are tagged with the operator's email address. Ask us at hello@welcomeglo.com and we will send you your own account's entries under clause 10.2;
- we do not sign in as you. If we need to see what you see, the supported way is for you to add us to your team through your own Team page, with your knowledge, and remove us afterwards.
Access is limited to the people who need it, which in a business of our size is a short list.
5.4 We keep it secure
We take reasonable steps to protect Client Personal Information from misuse, interference and loss, and from unauthorised access, modification or disclosure. That obligation includes technical and organisational measures.
In general terms, those measures include controls on who can access information and what they can reach, encrypted connections, separation between the records of one business and another, and an append only audit log. Our database and the systems that run Glo are hosted in Sydney, Australia. Section 11 of the Privacy Policy describes our security measures as well.
No system is completely secure. We cannot guarantee that personal information will never be reached by somebody who should not have it. What we can commit to is the measures above, and the response in clause 7. If you believe your account or your clients' information has been affected, email hello@welcomeglo.com and we will treat it as a priority.
Where we change a security measure, the replacement will provide a comparable or better level of protection. We will not quietly downgrade.
5.5 We help you with a request from one of your clients
If one of your clients contacts us about their own personal information, here is exactly what happens.
5.5.1 We do not turn them away. We will not tell a client to go and deal with you instead. We are answerable for information we hold.
5.5.2 We will normally pass it to you, and tell them we have. You know who they are, you can verify them on the spot, and the record is yours. In most cases you can resolve it in minutes and we cannot.
5.5.3 We still respond ourselves. We acknowledge within 5 business days and respond within 30 days, whether or not you have acted. If a request is complicated and we need longer, we tell them before the 30 days is up, tell them why, and give them a date.
5.5.4 We deal with it ourselves where passing it on is not right, or where you do not act. If we have passed a request to you and you have not dealt with it within 14 days, we will deal with it ourselves and tell you what we did.
5.5.5 What you have to do. If we pass a request to you, respond to it within 14 days and tell us what you did. That is the deal: we route it to you because it is better for the person asking, and that only works if you act.
5.5.6 If we disagree with you. If you tell us not to action a request that we think the law requires us to action, clause 5.2 applies. We will tell you why, and we will not simply do what you say if doing so would put us in breach.
5.5.7 Free, always. We do not charge you for this, and neither of us charges the Individual for making a request or for a correction. Correction is always free.
5.5.8 Where the Service already does it for you. You can look up, correct and archive a client record yourself, at any time, without asking us, and that is usually the fastest route. If a client asks you for a copy of what you hold, email us at hello@welcomeglo.com and we will produce it under clause 5.5.3, at no charge. Clause 9.4 sets out how that works.
5.6 We help you with a data breach
Clause 7 sets this out in full, because it is the part most worth getting right.
5.7 We help you meet your own obligations, within reason
Where you reasonably need it in order to meet your own privacy obligations, and taking into account what the Service actually does and what information is available to us, we will help you with:
- describing what Glo does with information, so you can write your own collection notice and your own privacy policy. We publish a plain English version at /legal/collection-notice that you may use and adapt;
- answering a question from a client, a regulator or a customer of yours about our handling;
- an assessment you have to do of the privacy risks of using Glo, by answering questions in writing under clause 10;
- an inquiry or investigation by the OAIC into your handling, so far as it concerns information we hold for you.
What this does not mean. We do not promise open ended consulting. Clause 3.4 applies: quick things are free, and anything substantial we will scope and price first, and you can decline.
5.8 We give it back, and we delete it
Clause 9 sets out what happens to Client Personal Information when your Account ends, what we keep, for how long, and why. Clause 9.4 sets out which records you can get out of the Service yourself and which ones we produce for you. Clause 9.6 explains what we are required to keep, and why.
5.9 We keep records of this
We keep a written record of the handling described in clause 4, our subprocessors, our security measures, and our data breach process. Clause 10 tells you how to ask for information out of it.
5.10 If you think we have got something wrong
Clause 5.5 is about a request or a complaint from an Individual. This clause is about you, because the person most likely to notice that we have breached this Addendum is the customer reading it, and a contract that gives a third party a full process and gives its own counterparty nothing is not a fair contract.
Email hello@welcomeglo.com and tell us what happened. That includes a concern that we have gone outside the closed list in clause 3.5, that we have not met clause 5.4, that a subprocessor change did not follow clause 8.6, or anything else in this Addendum.
- We will acknowledge within 5 business days and give you a substantive written answer within 30 days, and we will tell you what we are doing about it. If it is complicated and we need longer, we will tell you before the 30 days is up, tell you why, and give you a date.
- This is free, and there is no limit on how often you can raise something. Clause 10.2's once in twelve months limit is about full written information responses and does not apply to a complaint under this clause.
- If you are not satisfied with our answer, you can take a privacy complaint to the Office of the Australian Information Commissioner at oaic.gov.au. Nothing in this Addendum requires you to come to us first, and nothing in it stops you going to a court, to NSW Fair Trading, to the fair trading or consumer affairs office in your own state or territory, or to the Australian Competition and Consumer Commission. Clause 13.2 says the same.
6. What you promise to do
These are the things only you can do. We have kept the list short and every item is here because the Service cannot work properly without it.
6.1 You collect it lawfully, and you tell your clients
You are responsible for having the right to collect your clients' information and to put it into Glo, and for telling those people what is happening to it.
In Australian terms, that means:
- collecting only by lawful and fair means;
- collecting it for a purpose that is reasonably necessary for your business;
- taking reasonable steps to notify each person, at or before the time you collect their information, of the things Australian Privacy Principle 5 requires: who you are, that a booking and invoicing platform is used, why you are collecting it, what happens if they do not give it, who you usually disclose it to, that some recipients are overseas and where, and how to get access, seek a correction and complain.
Notifying each person under Australian Privacy Principle 5 is yours, including where the client enters their own details on the booking page you publish through Glo. A notice shown on a page we host for you does not discharge that obligation on its own. The notice you give is yours.
We help with the wording, and we do not leave you to guess. /legal/collection-notice sets out, in plain English, what Glo does with a client's information, and gives you wording you can use on your own forms, your own website and your own paperwork, including the wording for a booking page notice.
Where you type a client's details in yourself, rather than the client entering them on a booking page, telling that person is something only you can do, because we have no way to reach them.
6.2 You keep it accurate, and you collect only what you need
- Accuracy. You are the source of most of this information. Keep it up to date, and correct it when you learn it is wrong. The Service lets you edit a client, a vehicle and a booking, and clause 5.5 covers a request that comes to us.
- Minimisation. Do not record more than you need. A note is a permanent record that we, and anyone you give access to, can read, and it stays in the record for as long as clause 9 says.
6.3 Do not put sensitive information into Glo
Glo is not designed to hold sensitive information and you should not put any into it. This is the most important sentence in this clause, so it gets a paragraph of its own.
The Service has no field for health information, no field for anything about a person's race, religion, politics, sexual orientation or criminal record, and no biometrics. Nothing in the booking flow asks for any of it. The risk is the free text boxes, because a free text box will hold anything you type into it.
Two examples of how it happens by accident, both realistic:
- a note recording why a client cannot get to you, which turns into a note about a disability or a medical condition;
- a note recording that the thing you were asked to work on had been in an accident, which turns into a note about a criminal matter.
Sensitive information carries higher obligations under the Privacy Act, and holding health information about another individual can change our own legal position under the Privacy Act in a way neither of us has planned for. So:
- do not put sensitive information into a note, a message, a vehicle record, a logbook entry or a receipt description;
- do not upload a document containing it;
- if you have already, tell us at hello@welcomeglo.com and we will help you remove it.
If you do put sensitive information in anyway, we will handle it exactly as we handle everything else in this Addendum, because we are not going to treat it worse. But you are responsible for the consequences of having collected it, and clause 20 of the Terms applies.
6.4 You keep your team's access appropriate
- Give each person their own login. Do not share one. Team seats exist so that sharing is unnecessary.
- Give each person the smallest role that lets them do their job. A Staff user cannot reach Finances at all, and that is deliberate.
- Remove people who have left, through your own Team page. That ends their access.
- Tell us promptly at hello@welcomeglo.com if you think a login has been compromised.
- Treat booking tracking links, invoice links and quote links as private. Anybody holding one can open it, which is what makes them work without a login.
6.5 Your instructions must be lawful
You must not instruct us to do something with Client Personal Information that would breach the Privacy Act, the Spam Act 2003 (Cth) or another law. Clause 5.2 says what we do if we think you have.
6.6 Messages that go to your clients are yours
The Service sends emails to your clients about their booking, their job, their payment or their documents. Those messages exist because of your business, and they are your messages. The same applies to the text messages Glo sends about a booking, and to push notifications where we provide them.
So:
- you are responsible for having the right to contact that person at the address or number you or they gave;
- the messages carry your identity, because the law requires the business that authorised a message to be the one identified in it, so keep your business name and contact details accurate;
- the messages carry no promotion, for us or for you, and you must not try to make them carry one. That is not a style preference. A booking confirmation with a promotion in it changes character under the Spam Act 2003 and drags the whole set of messages with it;
- where we provide an opt-out route for a message type, you must not work around it.
We are answerable too. Sections 16(1),
17(1) and 18(1) of the Spam Act 2003 are each framed as "a person must not send,
or cause to be sent". The obligations therefore fall on the business that
authorised a message and on the person who sends it or causes it to be sent.
That is you and us respectively, in parallel, not one instead of the other, and
neither of us can point at the other. The carriage service carve-outs in sections
16(10), 17(6) and 18(7) do not cover a platform that composes, schedules and
dispatches, which is what we do. What this clause 6.6 allocates is the part only
you can do: having the right to contact that person, and keeping your business
name and contact details accurate so the message identifies you correctly. Our SMS
terms at /legal/sms tell the person receiving a text that Glo sends it on your
behalf.
Clause 24.3 of the Terms says the same thing from the other side.
6.7 Tell us if you are inside a regime we do not know about
Tell us before you put data into the Service if:
- you are, or you supply, a responsible entity for a critical infrastructure asset, or the information would be business critical data for one;
- you are a contracted service provider under a Commonwealth contract and Glo would be used for that work; or
- you or your client are subject to the European Union General Data Protection Regulation or the United Kingdom GDPR. In that case, tell us and Annex A applies, and clause A.9A in particular is one you should read before you rely on it.
Why this is here. Each of those regimes puts obligations on a supplier that we have not planned for, and some of them attach automatically the moment the data arrives. We would rather have the conversation and either meet the obligation or tell you that we cannot, than acquire it silently. If we cannot meet it, we will say so and you can walk away under clause 21.2 of the Terms with no fee and no notice period.
7. Data breaches
This is the clause that matters most on the worst day, so it is the longest and the most specific.
7.1 What we do when something happens
We follow a written data breach response plan with four stages:
- Contain. Stop it getting worse. Revoke sessions and keys, rotate credentials, disable the affected path, and preserve the logs and evidence before changing anything.
- Assess. Work out what happened, what information was involved, whose it was, who could have obtained it, and whether it is likely to cause serious harm.
- Notify. Clauses 7.2 to 7.6.
- Review. Work out how it happened, fix it, and record what was done.
7.2 We tell you fast, and we tell you before we have the full picture
7.2.1 The first notification. Where we become aware of, or form a reasonable suspicion of, a Data Breach that affects or may affect Client Personal Information we hold for you, we will tell you without undue delay and in any case within 24 hours of first having reasonable grounds to suspect it.
7.2.2 We do not wait until we understand it. The 24 hours runs from suspicion, not from confirmation and not from the end of the assessment. We will tell you what we know when we tell you, say plainly what we do not know yet, and keep you updated under clause 7.3. A late complete answer is worse than an early incomplete one, because you may have your own clock running.
7.2.3 Where we conclude it is notifiable, you hear that too. If we conclude that there are reasonable grounds to believe an Eligible Data Breach has occurred, we will tell you within 24 hours of reaching that conclusion, in addition to the first notification under clause 7.2.1.
7.2.4 Why 24 hours from suspicion. Because you may have your own clock running, and you are the one who knows your clients. Our written data breach response plan sets the same number internally, so this is a commitment we already run on rather than one written for a contract.
7.2.5 How we tell you. By email to your Account email address, and by phone as well if we have your number and the matter is urgent. Keep your Account email address current, because a notice sent to it is effective even if you no longer read it.
7.2.6 A near miss is not a notification. We will not tell you about every blocked sign-in attempt and every request our security measures turn away. This clause is about a Data Breach as defined, or a reasonable suspicion of one, not about the ordinary background noise that those measures exist to absorb.
7.3 What we will tell you, and how often
As far as we know it at the time:
- what happened, and when;
- when we became aware of it or first suspected it, and how;
- what kinds of personal information were involved, and whose;
- roughly how many Individuals and how many records are affected;
- who is likely to have obtained the information, if we know;
- what we have done to contain it and what we are doing to fix it;
- our assessment of whether serious harm is likely, and why we think that;
- what we recommend you tell affected people, specifically and practically;
- whether we have notified, or intend to notify, the OAIC;
- a contact for you to deal with on the matter.
And then we keep going, on a schedule, so you are not chasing us:
- a written update at least every 3 days while the incident is open, even where the update is that nothing has changed;
- the assessment outcome within 48 hours of our concluding it, whichever way it goes, including where the conclusion is that it is not notifiable;
- the post-incident review summary within 30 days of our closing the incident.
We will also give you the information you reasonably need in order to meet your own notification obligations, and we will not make you ask twice.
7.4 Who notifies whom: the NDB scheme, handled in advance
This part is genuinely complicated, so we are setting it out before anything goes wrong rather than negotiating it during an incident.
Under the NDB scheme, the obligation to assess and to notify falls on an entity that holds the personal information and is bound by the scheme. In a breach of Glo's systems, both of us may hold the same information, and depending on your own circumstances the scheme may bind you, or us, or both, or neither. Neither of us should be guessing about that at the time.
So here is the allocation.
7.4.1 We assess, and we do it on the clock. Where the incident is in our systems, we run the assessment, because we are the ones who can see the logs. We will complete it as quickly as we can and within 30 days of first having reasonable grounds to suspect an Eligible Data Breach, which is the maximum the scheme allows. 30 days is a maximum and not a target. We record when the suspicion arose, who assessed it, what they looked at and what they concluded. Note that our obligation to tell you under clause 7.2.1 runs from the same suspicion and is 24 hours, not 30 days: you hear from us long before the assessment is finished.
7.4.2 We notify the OAIC where the breach is in our systems, and we will tell you before we do, and give you a copy of the statement.
7.4.3 We agree with you who tells the affected people, and we agree it quickly. Where your clients are affected, we will tell you and we will agree with you who notifies them, so that each person is told once and told properly, rather than twice or not at all. Our starting position, which either of us can vary by agreement at the time:
| Situation | Who notifies the Individuals |
|---|---|
| The breach is in our systems and affects several businesses | We do, because a single consistent notice from the operator of the software is clearer than several different ones, and we will show you the wording first |
| The breach is in our systems and affects only your clients | You do, because you are the business those people dealt with and a notice from a name they recognise gets read. We will give you the wording, the facts and the recommended steps |
| The breach is on your side, for example a shared login, a lost device or a staff member who kept access they should not have | You do. We will help with facts we hold |
| We cannot agree, or you do not act within a reasonable time given the risk | We do, and we will tell you before we send anything |
7.4.4 Where one of us has notified, the other does not have to do it again. The NDB scheme is designed so that a person is not notified twice about the same breach by two entities. Clause 7.4.3 exists to make sure that somebody does notify, rather than each of us assuming it was the other.
7.4.5 We will not notify your clients behind your back. We will not contact your clients about an incident without telling you first, unless a law or a regulator requires us to act immediately, in which case we will tell you as soon as we can.
7.4.6 Where the law requires you to notify, that is yours. Nothing in this clause transfers a legal obligation from you to us or from us to you. It allocates the work, not the duty. If a regulator asks you a question, you have to answer it.
7.5 Cost, and no admission
- We do not charge you for any of this. Not for the assessment, not for the notification, not for the help.
- Telling you about an incident is not an admission that we caused it or that we are liable for it. We are telling you because you need to know, and we would rather tell you and be wrong about the seriousness than sit on it.
7.6 If the breach was on your side
Tell us at hello@welcomeglo.com as soon as you suspect it. We can revoke sessions, rotate what needs rotating, and pull the audit log for you, and we will. The sooner you tell us the more of that is still useful.
8. Subprocessors, and information that goes overseas
8.1 You authorise the subprocessors on the list
You authorise us to use the subprocessors published at /legal/subprocessors. That page is the operative list. It names each provider, what it does for Glo, what personal information it may handle, where it processes, and what entity and country it is.
The providers connected as at the date of this Addendum are named in clause 8.4, so that the authorisation you are giving has a subject you can see without leaving this document: Vercel, Supabase, Upstash, Stripe, Twilio, Resend, Google and Hostinger. Clause 8.4 sets out what each one gets and where it goes, and clause 8.7 covers the services that are not connected and that receive nothing.
We deliberately do not reproduce the whole of that page here, only the names and what each one gets. A list in two places is a list that goes out of date in one of them, and this Addendum should not need reissuing every time a provider changes a detail. The page moves and this Addendum follows it, within the notice and exit rights in clause 8.6, which are commitments of this Addendum and do not depend on the page.
8.2 What we require of each of them
Before a provider handles anything, we require it by contract 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;
- pass equivalent obligations to anybody it uses in turn; and
- tell us about a security incident that affects it.
We are clear about what that is and what it is not. These are the providers' own published data protection terms, accepted by us, rather than terms negotiated line by line. What we can do, and do, is choose providers that publish terms of that standard and refuse the ones that do not. Section 6 of the subprocessors page sets out how we choose.
Who "each of them" means, and the one carve-out, stated the same way in all three places. These five requirements apply to every provider we engaged to run the Service, which is the whole of the list you authorise in clause 8.1 and the whole of the table in clause 8.4. The subprocessors page also lists two advertising providers, Meta and Google, for the advertising tags Glo's own public marketing pages may carry. That page has covered them since 7 September 2026. They are not Subprocessors as clause 2.8 defines the word, because they never handle Client Personal Information: where we use them they run on Glo's own marketing pages, never on a page you or your clients are sent to, and nothing from inside the Service is sent to them. Requirement 2 above, that a provider use the information only for the job we engaged it for, is the one an advertising provider cannot meet, so we do not claim it of them. Clause 3.2 of /legal/subprocessors carves them out in the same terms and sets out what we require of them instead, and clause 8.2 of our Privacy Policy says the same thing again. If either were ever given anything about your clients, it would become a Subprocessor under clause 2.8 that day, and clause 8.6's 30 days' notice and your right to leave would apply to it in full.
8.3 We stay responsible for them
We remain responsible to you for what a subprocessor does with Client Personal Information, as if we had done it ourselves. Handing a job to a supplier does not hand you to the supplier.
8.4 Where the information is, and where it goes
Stored in Australia: our production database and the systems that run Glo are in Sydney. That covers almost everything the Service holds, including client records, vehicles, bookings, messages, payment records, invoices, quotes, expenses, receipt images, logbook entries and the audit log.
Recipients outside Australia. This is the part most policies fudge, so here it is straight: every provider in the table below is, or may be, an overseas recipient, and some of them also process outside Australia. Here is exactly which, and exactly what each one gets.
| Provider | What it gets | Where |
|---|---|---|
| Vercel, Supabase and Upstash | Hosting, our server functions and the production database. Everything in clause 4 that is stored, is stored by these three | Stored in Sydney. All three are United States companies, and their own personnel may be able to reach their systems from outside Australia, so we treat them as overseas recipients for Australian Privacy Principle 8 and section 16C purposes |
| Stripe | Where a client pays through Stripe: the client's email address, so Stripe can send its own payment confirmation, the amount, and internal Glo references. Card details are typed on Stripe's own pages and we never see them | Overseas, including the United States. Its Australian entity is Stripe Payments Australia Pty Ltd |
| Twilio | Where you have text messages switched on: your client's mobile number and the words of the message, which are your business's name, what happened to their booking (confirmed, cancelled, changed, or a quote sent) and, for a confirmation or a cancellation, the booking's day and time. No link, no amount and nothing else from your records | Overseas, including the United States |
| Resend | The recipient's email address and the contents of the message, which can include a client's name, the booking date and time, the full street address of the job, the service and the price, and links to a tracking, invoice or quote page | Overseas, including the United States |
| Google (Places) | Address autocomplete is switched on, so the address text being typed into an address box is sent to Google to fetch suggestions, together with a session token that ties the keystrokes of one address entry together. Also what any web request from a browser carries: the person's IP address, their browser user agent and the page they were on. No name, no email address, no phone number, no booking, no account, and nothing from your records. Suggestions as somebody types are the whole of it. There is no map, no geocoding, no routing and no location tracking anywhere in the Service, so nothing beyond the address text and the session token is ever sent. This request goes from the browser directly to Google and does not pass through our servers, which is also why Google sees the person's IP address and we cannot prevent that | Overseas, including the United States |
| Hostinger | Our support mailbox at hello@welcomeglo.com, so whatever you or one of your clients puts in an email to us. Support correspondence can carry Client Personal Information | Overseas. Hostinger International Ltd is based in Lithuania |
A distinction that matters, and we are keeping both halves of it. Where a provider stores data in Sydney we say the data is stored in Australia, which is true, rather than that it stays in Australia, which we cannot verify. But storage is not the test. Australian Privacy Principle 8 asks where the recipient is, not where the bytes are, so a Sydney storage region does not take a United States company outside APP 8. That is why the first row of the table is there rather than in a footnote.
Address autocomplete is switched on, and here is exactly what that means. It went live on 24 August 2026 and it is on today. When your client types into an address box on your booking page, or when you or your team type one in, what is typed is sent to Google as it is typed so that Google can offer suggestions, along with a session token that ties one address entry together. That is the whole of it, and the limit is the part worth reading. Google is not used for a map, for turning an address into coordinates, for a route, or for anybody's location, because the Service has none of those things. Nothing else about the person, the booking or your records goes with the request. If it is ever switched off we will change this clause rather than leave it standing. If you want the position confirmed on the day you ask, email hello@welcomeglo.com.
What that means for your own collection notice. When you tell your clients that some recipients are overseas and where, name the United States for every provider in the table above, and Lithuania for our support mailbox, not only for the ones that also process outside Australia. You should describe it the same way we do, including the address suggestions that go to Google.
8.5 The accountability rule, and why it protects you
Australian privacy law does not let us send information overseas and then point at the recipient when something goes wrong.
Under section 16C of the Privacy Act, if an overseas provider we disclose information to handles it in a way that would breach the Australian Privacy Principles had we done it ourselves, the law treats that as our breach. Taking reasonable steps in the contract does not get us out of it. We carry it, and we carry it for every provider named in clause 8.4, not only for the ones that also process outside Australia.
That rule is one of the strongest protections you have. It is a large part of why our provider list is short, why we do not add a provider casually, and why we keep as much as we can in Sydney.
8.6 Notice before a new subprocessor, and your right to leave
This clause is the commitment. Section 8 of the subprocessors page states the same process on the page itself, and where the two ever differ, this Addendum applies, because clause 3.2 of the Terms puts this Addendum first on how we handle personal information about your Clients. We have written it out here rather than only pointing at the page, so that the right does not depend on a page you would have to go and check.
- we update the page before a new provider starts handling personal information, not afterwards;
- we email you at least 30 days beforehand, telling you who the provider is, what it will do, what kind of information it will handle and where it will process;
- if you are not comfortable with it, you can cancel before the change takes effect, with no fee, no notice period, and a refund of the unused part of anything you have already paid for;
- export your records before your access closes, using the Records Download at
/dashboard/finances/records, which is free and is not gated on your billing status. That download covers your financial records. Ask us at hello@welcomeglo.com for anything it does not cover, including your client, vehicle, booking and message records, and we will produce those for you under clause 9.4, free, within 10 business days, which is the same commitment section 8 of the subprocessors page makes; - there is one narrow exception, for a provider failure, an urgent security or availability need, or a legal requirement. In that case we may act first, we update the page immediately, we email you within 7 days, and the exit right above stays open for at least 30 days from the day we tell you, refund included. Convenience is not an emergency and a better price is not an emergency;
- removing a provider does not need 30 days, because removing one cannot expose you to one. Replacing a provider with a different one is a new provider and gets the full notice.
We have deliberately given you an exit with a refund rather than a right to veto a provider. Here is the reason. If one customer could veto a provider that every other customer depends on, we could not honour the veto without shutting the Service down, so it would be a promise we would break the first time it was used. An exit that costs you nothing is a right we can actually deliver, every time, to every customer. We would rather give you a smaller right that is real.
8.7 Providers that are not connected
Some services Glo could use are not connected and receive nothing. As at the date of this Addendum that includes accounting software such as Xero or MYOB, and a separate storage service, because receipt images are held in our database. None of them holds any Client Personal Information. If one of them connects, clause 8.6 applies in full.
9. How long we keep it, and what happens when you leave
9.1 The rule
We keep Client Personal Information for as long as we need it to supply the Service to you and for the purposes in clause 3.5, and for as long as an Australian law requires us to keep it. After that, we destroy it or de-identify it.
9.2 The schedule
These are the retention periods we commit to.
| When | What we commit to |
|---|---|
| When your access is about to close | We generate a complete export of your financial records and email it to the Account owner's email address before access closes. That covers a lock for non-payment, a Plan downgrade, a restriction, the end of the agreement and closing your Account, exactly as clause 14.6 of the Terms explains. Your client, vehicle, booking and message records are not in that export. Ask us and we will produce them |
| For the next 2 years | Records are kept. Whether you can reach them through the Service is governed by the billing rules in clause 14 of the Terms |
| At 2 years | We stop making the records reachable through the Service |
| From 2 to 7 years | Held in the background only. Where we need to reach them, we do it through an authenticated internal process that leaves a record of who looked and when |
| At 7 years, counted per record | We delete them, except where a longer obligation is still running on a record. See the two paragraphs below. This is our retention limit and our commitment |
| Audit log entries | 2 years from the action they record, not seven, unless the entry is part of a live investigation or a legal claim, in which case until that is finished. Clause 12.1a of the Privacy Policy sets that period and this clause does not contradict it |
Which clock, because there are two and they run differently. The two access windows above run from the moment access closes, because access is a property of an account rather than of a record. The seven year destruction date runs from when each record was made, or the transaction it records was completed, whichever is later. That is the Australian Taxation Office's own measure, it is the only one a per-record retention rule can apply, and it is the one that governs. For a business that used Glo for five years the two measures would give the same invoice destruction dates up to five years apart, so it is worth being exact rather than tidy. Clause 12.2 of the Privacy Policy says the same thing, and clause 22.2 of the Terms carries the same schedule.
One exception, and it exists to protect you. Some records have to be kept for longer than seven years. Records about a business asset are the clearest case: they have to be kept for as long as you hold the asset plus five years after you dispose of it. Buy a work van in year one, sell it in year eight, and the purchase records are needed until year thirteen. A flat seven year rule would destroy them and leave you unable to answer the ATO about a deduction you correctly claimed. So we do not delete a record while a longer obligation is still running on it. If you know a record falls into that class, tell us at hello@welcomeglo.com and we will mark it as held, and we will confirm that we have. Clause 12.2 of the Privacy Policy and clause 22.3A of the Terms carry the same carve-out.
9.3 You always keep a way to get your records out
This is the part of the retention design that exists for you, so we are stating it as a commitment rather than leaving it as a product behaviour that could change.
- At the moment your account is locked for non-payment, and before access closes, we generate a complete export of your Finances records and email it to the Account owner's email address. Once per lapse.
- There is a permanent, free, one click download of all your financial records at
/dashboard/finances/records, and that page keeps working while your account is locked. It is deliberately not tied to your subscription. An Owner or an Admin can use it while signed in; a Staff user cannot reach Finances at all. - We do the same at a plan downgrade, which is not the same thing as a lapse: you keep read access to everything already issued, you simply cannot issue more, and we email you a complete export of your financial records when your plan changes, as clause 14.9 of the Terms explains.
- We do the same on a cancellation, on a termination, on a restriction and when an Account is closed. Those exports are commitments and not courtesies, and we send them before your access changes. Clause 12.2a of the Privacy Policy says the same thing, and clause 14.6 of the Terms sets out the same commitments.
- We never delete your records as a punishment. Not for a missed payment, not for a locked account, not for a plan change, and not for making a complaint.
Why we built it that way. The ATO requires you to keep your business records for five years and to be able to get at them. That is your obligation, not ours, and a problem with your subscription must never stop you meeting it. Clauses 14.6, 14.7 and 22 of the Terms carry the same commitments, and clause 19.7 of the Terms tells you to use them.
9.4 Getting your data back
At any time while your Account exists, and without asking us:
- CSV exports of your Finances reports;
- PDFs of the documents you have issued, being your invoices, adjustment notes, quotes and expense receipts;
- the Records Download at
/dashboard/finances/records, which covers your financial records: invoices, invoice lines, payments, expenses, adjustment notes, the vehicle logbook and a transaction ledger.
Your client, vehicle, booking and message records are not in any of those exports, and none of those exports contains Client Personal Information. Ask us at hello@welcomeglo.com and we will produce those records for you, at no charge, within the timeframes in clause 10.2, and we will do the same where one of your clients has asked you for a copy under clause 5.5.8.
If you need Client Personal Information in a particular form for a reason of your own, ask and we will do what we reasonably can. Clause 3.4 applies to anything that would take real work.
9.5 Deletion
To close your Account and have your data deleted, email hello@welcomeglo.com from your Account email address. We will confirm what you are asking for before we act on it, because it is not reversible, and we generate and send you a complete export of your financial records first. If you also want your client, vehicle, booking and message records before we delete them, say so and we will produce those too under clause 9.4.
Deletion covers Your Data, including Client Personal Information, subject to clause 9.6.
A deletion request is handled by a person, within the timeframes in clause 5.5.3. Where we provide a way to close an Account inside the Service or inside a Glo App, you will be able to use that instead, and it will follow the same steps: export first, then confirmation, then deletion.
9.6 What we cannot delete, and why we say so
If you ask us to delete, we delete what we are allowed to delete, and we keep what the law requires us to keep. We will tell you which is which.
Australian tax law requires business records to be kept for five years. A booking that was paid for is part of your business's records. So is an invoice, an adjustment note, a receipt and a payment. A request to delete does not override a legal obligation to retain, and any business that told you otherwise would either be misleading you or breaking a different law.
In practice:
- financial records are never hard deleted. An issued invoice or adjustment note is never edited and never deleted. A correction is made by issuing an adjustment note or by voiding the document, and the original stays visible. That is what the record keeping rules require and it protects both sides of a dispute about what was actually agreed;
- client and vehicle records are archived rather than erased when you remove them, because your entire job and takings history hangs off them and a hard delete would rewrite records the ATO requires you to keep. An archived record drops out of every list and picker;
- some records have to be kept for longer than seven years, and the asset carve-out in clause 9.2 is the clearest case. We do not delete a record while a longer obligation is still running on it;
- where we cannot delete something, we say so, say why, and say for how long. We will not quietly keep it and let you believe it is gone;
- where we can delete something, we do, and we confirm when it is done.
9.7 Why seven years
Why seven. The ATO requires five years, from when the record was prepared or the transaction completed, whichever is later. That is the hard obligation and it sits on you, not on us. Six years is the longest limitation period that could apply, being the period for bringing a contract claim in New South Wales and most other Australian states. Seven is six plus a deliberate one year margin. It is our choice, not a legal minimum.
Two things we specifically do not rely on, because over-keeping information on a basis that does not apply is itself a privacy problem:
- the company record keeping rules, which bind companies. Glo is operated by a sole trader, so that section is not available to us and we are not using it;
- anti-money laundering rules, which do not apply to us. Your client's money goes from them, through Stripe, into your own Stripe balance. It never passes through our hands. Stripe carries those obligations, not us.
10. Information and audit rights
10.1 What you can ask for
You can ask us for the information you reasonably need to satisfy yourself, or your own customer or regulator, that we are handling Client Personal Information the way this Addendum says. That includes:
- how a particular feature handles information;
- which subprocessors touch what, beyond what the subprocessors page already says;
- our security measures;
- our retention and deletion practice;
- how we would handle a specific request or a specific incident;
- your own account's audit log entries, which we send to you under clause 10.4;
- your client, vehicle, booking and message records, which we produce for you under clause 9.4;
- a completed security or privacy questionnaire, where it is of a reasonable length and asks about things we actually do.
10.2 What we commit to
We will acknowledge your request within 5 business days and give you a substantive written response within 30 days. If a request is large and we need longer, we will tell you before the 30 days is up, tell you why, and give you a date.
We will not charge you for a reasonable request. Clause 3.4 applies to anything that would take real work: we will tell you what it involves and what it would cost before we start, and you can decline.
Once in any 12 month period is the frequency we can sustain as a routine matter, and it is a limit on how often we will do a full written response, not a limit on asking us a question. That limit does not apply:
- where there has been a Data Breach affecting your information;
- where a regulator has required it;
- where you reasonably believe we are not doing something this Addendum says we do;
- where the request is short enough that answering it costs us less than arguing about it; or
- to a complaint under clause 5.10, which has no limit at all.
If you need a second full response in the same year and none of those applies, ask anyway and tell us why. We will not refuse a reasonable request, and if we do refuse we will tell you in writing why.
10.3 What we do not offer
We do not offer a right to send auditors into our premises or into our systems. What we offer instead is set out in clause 10.4: the information in clause 10.1, written answers on the timeframes in clause 10.2, and the complaints route in clause 5.10.
If your own regulator, or a contract you have with your own customer, requires an audit right or an attestation that clause 10.4 does not give you, tell us before you rely on Glo for that work. We will tell you whether we can do anything about it, and if we cannot, you can leave under clause 21.2 of the Terms with no fee and no notice period. That is a better answer for both of us than a promise on paper.
10.4 What you get instead
- the subprocessors page, kept current, with 30 days' notice before it changes and an exit with a refund if you do not like the change;
- section 11 of the Privacy Policy, which describes our security measures;
- written answers under clause 10.2, and a complaints route under clause 5.10;
- your account's audit log entries on request. Actions in your account are written to an append only log with the actor, the time and the IP address, and operator actions are tagged with the operator's email address. Ask us at hello@welcomeglo.com and we will send you your own account's entries under clause 10.2.
10.5 Regulators
We will cooperate with the OAIC, and with any other regulator with proper authority, in an inquiry, assessment or investigation concerning Client Personal Information we hold for you. Where we are allowed to tell you, we will.
11. Liability
11.1 The Terms govern
Clause 19 of the Terms applies to this Addendum, and this Addendum does not create a separate or additional cap. Clause 18 of the Terms, which is about your rights under the Australian Consumer Law, applies here exactly as it applies everywhere else, and nothing in this Addendum excludes, restricts or modifies a right or remedy you have under that law that cannot lawfully be excluded.
11.2 Our privacy and security obligations are not capped, and that is deliberate
Clause 19.3 of the Terms says the liability limit does not apply, at all, to a failure by us to meet our privacy and security obligations to you. That carve out covers this Addendum.
We are repeating it here because it is the single most important thing in this document for you. Your real fear about putting your clients' details into somebody else's software is a data breach. We are not going to sell you a limit on that. The obligations in clauses 5 and 7 are exactly the ones you should be able to hold us to without arguing about a cap.
11.3 Your side
Clause 20 of the Terms sets out when you cover us, including for your own dealings with your clients and for what you or your Users put into the Service. It does not apply to the extent we caused or contributed to the problem, it is capped, and it carries obligations on us to tell you promptly, let you take part and not settle without asking you first. It has not been widened by this Addendum.
11.4 No new rights for anyone else
This Addendum is between you and us. It does not give your client, your customer or any other person a right to enforce it. That does not affect any right your client has directly under the Privacy Act or any other law, which they keep in full and which clause 3.7 exists to acknowledge.
12. Term, changes, and how this is accepted
12.1 When it starts
This Addendum starts when your Account is created, or on 26 August 2026 if your Account already existed on that date.
12.2 How long it runs
It runs for as long as your agreement with us runs, and afterwards for as long as we hold any Client Personal Information for you.
12.3 Changes
We change this Addendum the same way we change the Terms, under clause 25 of the Terms. In summary:
- we email you at least 30 days before a change takes effect, at your Account email address. We do not post a new version on a website and treat that as telling you;
- we tell you in plain English what changed and why;
- you can cancel before the change takes effect, with no fee and no notice period, and if you cancel because of the change we refund the unused part of anything you have already paid for;
- a change that takes nothing away from you takes effect as soon as we publish it, which covers a correction, a clarification, a new protection and anything the law requires, and it still gets a version number, an effective date and a plain English note of what changed;
- the 30 days is for a change that takes something away from you, and where it is not obvious which kind a change is we treat it as the kind that needs the 30 days, because that call is not ours to make in our own favour;
- a change never applies retrospectively to something that has already happened.
Adding or changing a subprocessor is handled under clause 8.6, not under this clause.
12.4 How this is accepted, and how to get a signed copy
You do not need to sign anything. This Addendum applies automatically to every Glo account as part of the Terms, from the date in clause 12.1. That is deliberate: we would rather every customer have it than only the ones who thought to ask.
If you need a countersigned copy, for example because a fleet customer, a dealership, a hire company or a council has asked you for one, email hello@welcomeglo.com with the name and details of the entity to be named. We will send you a copy signed by us, at no charge. Sign it and send it back by email, scan or electronic signature. A signed copy does not change any of the terms above unless we have both expressly agreed a change in writing.
Where a customer of yours needs additional terms that this Addendum does not cover, send us what they are asking for. We will tell you what we can agree to and what we cannot.
12.5 What survives
The test we applied to this list is simple: while we still hold your clients' information, the obligations that protect it have to still be running. Clause 9.2 keeps Client Personal Information for up to seven years, counted per record, and longer where a longer obligation is still running on one, and clause 12.2 says this Addendum runs for as long as we hold any of it, so a survival list that dropped our security obligation while we still held the data would be a list that contradicts the rest of the document.
So: clause 2 (definitions), clause 3.5 (the closed list) and clause 3.6 (what we never do), clause 3.7 (we are still answerable), clauses 5.1 to 5.5 (instructions, unlawful instructions, confidentiality, security and Privacy Requests), clause 5.10 (complaints), clause 6.5 (your instructions must be lawful), clause 7 (data breaches, so far as it concerns an incident affecting information we still hold), clauses 8.2, 8.3, 8.5 and 8.6 (what we require of a subprocessor, our responsibility for them, the accountability rule, and notice before a new one), clause 9 (retention and deletion), clause 10 (information rights, for 12 months), clause 11 (liability), clause 13 (general) and this clause survive the end of your agreement with us, for as long as we hold any Client Personal Information for you.
13. General
13.1 Governing law. This Addendum is governed by the laws of New South Wales, Australia, and both of us submit to the non-exclusive jurisdiction of the courts of New South Wales and the courts that hear appeals from them. Non-exclusive means you are not shut out of a court somewhere else that would otherwise be able to hear the matter.
13.2 Nothing here funnels a dispute back to us. Clause 26.4 of the Terms applies: nothing in this Addendum stops you starting court proceedings, taking a complaint to NSW Fair Trading or to the fair trading or consumer affairs office in your own state or territory, taking a complaint to the Australian Competition and Consumer Commission, taking a privacy complaint to the OAIC, or exercising any other right you have under the law. Clause 5.10 gives you a route to us, and it is there because it is usually faster, not because you have to use it first.
13.3 Notices. Clause 29 of the Terms applies. For anything under this Addendum, including a data breach notification under clause 7.2, we will email your Account email address. You give us notice by emailing hello@welcomeglo.com or writing to Unit B14, 161 Arthur Street, Homebush West NSW 2140.
13.4 Severability. If a part of this Addendum is unenforceable, it is severed and the rest continues to apply.
13.5 No agency. Nothing in this Addendum makes us partners, and neither of us is the other's agent, employee or joint venturer.
13.6 Interpretation. Headings are for convenience and do not affect meaning. "Including" means including without limitation. The short version at the top of this document is a summary and does not change the numbered clauses.
13.7 Contacting us.
- 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.
Annex A. If you or your clients are in the European Union or the United Kingdom
Nothing in this Annex applies today. We offer the Service to businesses in Australia. We do not offer it to people in the European Union, the European Economic Area or the United Kingdom, and we do not monitor your clients' behaviour anywhere: we track none of them across sites, we profile none of them, and we measure nothing whatever about a data subject of yours, which is the category this Addendum governs.
The personal information covered by this Addendum is your clients' information, and none of it is measured. Since 6 September 2026 we do record which parts of the dashboard our subscribing businesses use, so that we can tell which features are worth keeping. That is information about you and your team, held by us as controller under our Privacy Policy clause 4.1, and it is outside this Addendum rather than an exception within it.
Our public marketing pages may carry advertising tags, the pages where we advertise Glo to detailing businesses, and where we use them those tags follow a visitor to those pages across sites. Your clients never open those pages in any event. A booking page, a tracking page, an invoice page and a quote page carry no advertising tag and no third party script of any kind, and they never will. That measurement is about people looking at Glo, held by us as controller under our Privacy Policy, and like the dashboard measurement above it is outside this Addendum rather than an exception within it.
This Annex is here so that if the answer ever changes, the terms already exist and nobody has to reopen a contract to write them. It switches on by itself under clause A.1 and it is drafted to the obligations those laws actually impose. Two parts of it have to be settled with you in writing before you rely on them, and each says so where it sits: clause A.7 and Schedule 1, on the transfer mechanism, and clause A.9A, on deletion and return.
A.1 When this Annex applies
This Annex applies, and forms part of this Addendum, from the moment either of the following is true:
- you are subject to the EU GDPR or the UK GDPR in respect of personal data you put into the Service, and you have told us so under clause 6.7; or
- we begin offering the Service to people in the EU, the EEA or the UK, or begin monitoring the behaviour of people there.
Where it applies, it applies in addition to everything above. Nothing in this Annex reduces a protection in the body of this Addendum, and where the two differ on the same point, whichever gives the Individual more protection applies.
A.2 The roles
- You are the controller of Client Personal Information, and we are your processor of it.
- We are the controller of the information in clause 1.4: your own account, business, billing and sign-in information.
- Clause 4 of this Addendum is the record required by Article 28(3) of the subject matter, duration, nature and purpose of the processing, the types of personal data and the categories of data subject.
A.3 The Article 28(3) obligations
Each of the following is already in the body of this Addendum. This table maps them, so a reviewer can check the list off without reading the whole document, and so that nothing has to be duplicated and kept in sync in two places.
| Article 28(3) | What it requires | Where it is |
|---|---|---|
| (a) | Process only on the controller's documented instructions, including for transfers to a third country, unless required by law, and if required by law then inform the controller first unless the law forbids it | Clauses 3.2, 3.4, 5.1 |
| (b) | Ensure people authorised to process are under a duty of confidentiality | Clause 5.3 |
| (c) | Take the security measures required by Article 32 | Clause 5.4, and clause A.4 below |
| (d) | Respect the sub-processor conditions in Articles 28(2) and 28(4): authorisation, back to back terms, and the processor remains fully liable | Clauses 8.1, 8.2, 8.3, 8.6 |
| (e) | Assist the controller in responding to data subject rights requests | Clause 5.5 |
| (f) | Assist with security, breach notification to the supervisory authority and to data subjects, data protection impact assessments and prior consultation | Clauses 5.4, 5.7, 7, and clause A.5 below |
| (g) | At the end of the services, delete or return the personal data at the controller's choice, and delete existing copies unless law requires retention | Clauses 9.4, 9.5 and 9.6, subject to clause A.9A, which you should read before relying on this row |
| (h) | Make available the information needed to demonstrate compliance, and allow for and contribute to audits and inspections | Clause 10, subject to clause A.6 below |
| plus | Immediately inform the controller if an instruction infringes the GDPR or member state law | Clause 5.2 |
A.4 Article 32 security
The measures in clause 5.4, and the ones described in section 11 of the Privacy Policy, are the technical and organisational measures we have, taking into account the state of the art, the costs of implementation, the nature, scope, context and purposes of the processing, and the risk to Individuals.
A controller relying on Article 32 should satisfy itself that those measures are appropriate for the personal data it puts into the Service. Clause 10.1 sets out what you can ask us for, and clause 10.2 is the timeframe we answer in.
A.5 Article 33 breach notification
Clause 7 applies, with these additions:
- our notification to you under clause 7.2 is the Article 33(2) notification, and it runs on the 24 hours from reasonable suspicion commitment in clause 7.2.1, which is tighter than the 72 hour clock Article 33(1) puts on you;
- the content in clause 7.3 is drafted to cover what Article 33(3) requires, and the update schedule in clause 7.3 is drafted so that Article 33(4), which allows information to be provided in phases, is met by a schedule rather than by us deciding when you next hear from us;
- you remain responsible for notifying your supervisory authority within 72 hours under Article 33(1), and for notifying data subjects under Article 34 where the risk is high. Clause 7.4 allocates the work, not the duty.
A.6 Audits under Article 28(3)(h)
Clause 10 applies, and clause 10.3 applies with it: we will provide information and written answers, and we do not offer an on-site audit.
Where a controller's own legal position requires an audit or an inspection right that clause 10 does not give, that must be agreed in writing before this Annex is relied on. Do not assume it. We will engage with a reasonable request, and if we cannot meet it we will say so, and clause 10.3's exit applies.
A.7 International transfers
Australia does not have an EU adequacy decision. A transfer of personal data from the EEA or the UK to us therefore needs a transfer mechanism, and the mechanism for any such transfer is the one selected and countersigned in Schedule 1 to this Annex.
Before this Annex is relied on for any actual transfer, Schedule 1 to this Annex must be completed and countersigned. Until it is, this clause does not take effect, and nothing in this Annex should be read as asserting that a transfer mechanism is in place.
Schedule 1 is drafted so that completing it is a form-filling exercise rather than a drafting exercise.
A.8 Representative
If the EU GDPR or the UK GDPR applies to us directly, we may be required to appoint a representative in the Union or in the United Kingdom under Article 27. Where one is required, we will appoint one and publish the details in our Privacy Policy and in Schedule 1 to this Annex. Until those details are published, nothing in this Annex should be read as asserting that a representative has been appointed.
A.9 What does not change
Everything in the body of this Addendum continues to apply, including the closed list in clause 3.5, the list of things we never do in clause 3.6, the subprocessor notice and exit right in clause 8.6, the retention schedule in clause 9, and the uncapped privacy and security liability in clause 11.2. Clause A.9A is the one place where this Annex changes how clause 9 runs.
A.9A Deletion and return where this Annex applies
Where this Annex applies, clause 9.2's seven year schedule does not override your choice under Article 28(3)(g). On the end of the services you may choose deletion or return of Client Personal Information, and we will act on that choice, except for records we are required to retain by a law that binds us.
One point needs stating plainly. Article 28(3)(g) allows a processor to keep personal data where "Union or Member State law requires storage" of it. The law we rely on for retention is Australian tax law, which is neither. So Article 28(3)(g)'s exception, read strictly, does not cover our retention basis, and clause 9.6 and clause 9.7 describe a retention position that an EU or UK controller cannot simply assume away.
What to do about it. If you are a controller under the EU GDPR or the UK GDPR, raise this with us under clause 6.7 before you put data into the Service. We will either agree a retention position with you in writing, or tell you that we cannot, in which case clause 10.3's exit applies and you leave with no fee and no notice period.
And on the return side: return is by an export we produce for you on request under clause 9.4.
Annex A, Schedule 1. Transfer mechanism
Not completed. This Schedule takes effect only when it has been completed and countersigned by both parties.
1. The mechanism. One of the following applies. Tick one.
- EU Standard Contractual Clauses. The Standard Contractual Clauses annexed to Commission Implementing Decision (EU) 2021/914 of 4 June 2021, Module Two (controller to processor), are incorporated into this Addendum and take precedence over it to the extent of any conflict. The optional docking clause applies. The parties' choices under those Clauses are recorded at item 2 below, and Annexes I, II and III to those Clauses are completed at items 3, 4 and 5.
- UK International Data Transfer Addendum. The Information Commissioner's International Data Transfer Addendum to the EU Standard Contractual Clauses, version B1.0, is incorporated, applied to the EU Standard Contractual Clauses selected above.
- UK International Data Transfer Agreement (IDTA). The Information Commissioner's IDTA is incorporated in place of the EU Standard Contractual Clauses.
- Another mechanism, being: ................................................
2. Choices under the EU Standard Contractual Clauses, where selected.
| Item | Choice |
|---|---|
| Clause 7, docking clause | Applies |
| Clause 9, sub-processors | Option 2, general written authorisation. The notice period is 30 days, as set out in clause 8.6 of this Addendum, and the list of authorised sub-processors is the page at /legal/subprocessors, the connected providers being the ones named in clause 8.4 |
| Clause 11, redress | The optional independent dispute resolution paragraph: ...................... |
| Clause 17, governing law | ...................... |
| Clause 18, forum and jurisdiction | ...................... |
3. Annex I to the Clauses.
- Data exporter: name, address, contact person's name, position and contact details, activities relevant to the transferred data, role: ......................
- Data importer: Connor Wu trading as Glo, ABN 23 380 080 435, Unit B14, 161 Arthur Street, Homebush West NSW 2140, contact hello@welcomeglo.com, activities relevant to the transferred data: supplying the Glo software as described in clause 4 of this Addendum, role: processor.
- Description of the transfer: the categories of data subject, categories of personal data, sensitive data, frequency, nature, purpose, retention period and sub-processor details are as set out in clause 4, clause 6.3, clause 8 and clause 9 of this Addendum, which are incorporated into this Annex I.
- Competent supervisory authority: ......................
4. Annex II to the Clauses, technical and organisational measures. The measures in clause 5.4 of this Addendum and section 11 of the Privacy Policy are incorporated into this Annex II.
5. Annex III to the Clauses, sub-processors. The page at
/legal/subprocessors, as amended from time to time under clause 8.6 of this
Addendum.
6. Transfer impact assessment. The data exporter is responsible for carrying out its own assessment of the transfer. We will provide the information in clauses 5.4, 8.4 and 8.5 of this Addendum, and answer reasonable written questions under clause 10, to support it.
Signed for and on behalf of the data exporter: ......................
Signed for and on behalf of Connor Wu trading as Glo: ......................
Date: ......................
Signature block, for a countersigned copy
To be completed only where a countersigned copy has been requested under clause 12.4. An unsigned copy applies in full without this block.
Customer
| Legal name | ...................... |
| ABN | ...................... |
| Glo account email | ...................... |
| Signed by | ...................... |
| Name and position | ...................... |
| Date | ...................... |
Glo
| Legal name | Connor Wu trading as Glo |
| ABN | 23 380 080 435 |
| Address | Unit B14, 161 Arthur Street, Homebush West NSW 2140 |
| Signed by | ...................... |
| Name and position | ...................... |
| Date | ...................... |
Related documents
| Document | Where | Part of your agreement with us? |
|---|---|---|
| This Addendum | /legal/data-processing | Yes |
| Terms of Service | /legal/terms | Yes |
| Refunds and Cancellations | /legal/refunds | Yes |
| Acceptable Use Policy | /legal/acceptable-use | Yes |
| Privacy Policy | /legal/privacy | Yes |
| Cookie Policy | /legal/cookies | Read as part of the Privacy Policy |
| Subprocessors | /legal/subprocessors | Read as part of this Addendum |
| Collection notices | /legal/collection-notice | No. Wording for you to use and adapt |
| Client Terms | /legal/client-terms | No. They govern our relationship with your client |
| SMS terms | /legal/sms | No. Same reason |
Version 1.4. Last updated 22 September 2026.
Questions about this document?
Email hello@welcomeglo.com.