W3ME Privacy Policy
Document version: 1.1 · Version date: 28 October 2026
This policy explains how W3ME handles personal information.
It has two parts:
Part 1: the global program. How W3ME handles personal information everywhere it operates. Part 1 applies to you wherever you are.
Part 2: region modules. The law, the regulator and the data location for your region. Australia is the only region currently open, and its module is at Part 2.
“We“ and “us“ mean the W3ME entity for your region, identified in the contracting entity table in the Platform Terms of Service and in your regional Schedule. “You“ means whoever is reading this: an operator using W3ME, one of their drivers or staff, or one of their customers.
Part 1 is grouped to follow the Australian Privacy Principles, which are the standard W3ME holds itself to globally. Where a region’s own law requires more, its module in Part 2 says so.
PART 1: THE GLOBAL PROGRAM
1. How we manage privacy
1.1 This policy is published on our website, free to read. We will provide a copy in another format on request. It is our statement of how we handle personal information; the Platform Terms of Service reference it and commit us to complying with privacy law and to keeping this description accurate.
1.2 We hold your information, and we are responsible for it.
W3ME holds the personal information in the platform, and W3ME owes the obligations that privacy law places on the holder of it. Those duties are ours. They are owed to the individuals concerned, they are enforced by a regulator, and nothing in this policy, and nothing in an operator’s agreement with us, displaces them or passes them to someone else.
This does not affect any privacy obligations an operator has of its own: an operator subject to privacy law still owes its own duties to its own people and customers, and our duties being ours neither takes those on nor discharges them.
That is worth stating plainly, because the practical routing can suggest otherwise:
An operator decides what goes into their workspace, which customers, which drivers, which jobs, and what it is used for in their business. Where you are a customer or a driver of a freight business that uses W3ME, the operator is usually the right first door: they know why they hold your details, and they can change them.
But that is about who can answer you fastest, not about who is responsible. If the operator cannot help, or you would rather come to us, come to us. We will handle your request under sections 16, 17 and 18, and we will not send you away on the ground that it is the operator’s data.
1.3 We review this policy at least annually, and whenever we materially change how we handle information.
1.4 Privacy contact: [email protected], marked “Privacy”.
2. Anonymity and pseudonymity
2.1 You can browse our public website without identifying yourself.
2.2 W3ME itself cannot be used anonymously. Freight work requires real names, real addresses and real businesses: for the work, for tax, and for transport law. It is not practicable for us to deal with an anonymous or pseudonymous operator, driver or consignee.
2.3 You may send us a general enquiry without identifying yourself, though we may be unable to answer a question about a specific account.
3. What we collect, and why
3.1 From the operator signing up
Information
Purpose
Business name and business identifier (in Australia, the ABN)
Identifying the business, and tax documentation
Business address
Anchoring the workspace and the first depot
Owner’s name, email address, and mobile number if provided
Creating the account and contacting the account owner
A password
Signing in
Country
Sets the region, and with it currency, tax treatment and business-identity scheme
Tax registration status and tax number
Working out whether to add tax to invoices, and putting the right details on them
Your first vehicle: its registration and body type
Setting the workspace up so it is usable on day one
Payment method details (via Stripe: we never see a full card number or hold bank credentials)
Billing and collection under the Payment Authority
3.2 From the operator’s people
Information
Purpose
Name, email address, role
Providing a login and the correct level of access
Mobile number, where provided
Operational contact and notifications
Driver licence class and expiry, where recorded
Warning before an unsuitable allocation
Other accreditations, where recorded
The same: for example dangerous goods endorsements
3.3 From running jobs
Information
Purpose
Pickup and delivery addresses
Planning and performing the work
Contact names, phone numbers and email addresses at each site
Site access, and notifying the consignee
Freight descriptions, weights, dimensions, hazard details
Planning the work and complying with transport law
Times: planned, actual, waiting
Running the day, billing, and evidencing what happened
Messages between the operator, their driver and their customer
Running the job
3.4 Driver location during a job
While the driver app is open, it shares the phone’s location with the operator. This is a workspace setting: it is on unless the operator turns it off.
When: about every 30 seconds while the app is open and on screen, and once with each event the driver records, arriving at a stop, completing a delivery, capturing a proof of delivery. Nothing is collected while the app is closed, in the background, or the phone is locked. The app says so on screen. A subcontractor’s driver who works a job through a job link shares the same way while that page is open, and the page says so.
What is kept: the latest position for each driver, replaced each time, and for 30 days the series of positions (the location trail). After 30 days the trail is reduced to a record of the route driven, its shape, distance, duration, vehicle class, part of the day and day of the week, with no driver, vehicle, job or stop attached, and the positions themselves are deleted.
The reading comes from the driver’s own device, and is recorded as device-reported and not independently verified. We do not treat it as proof that a person was in a place. Where a device provides no location, that absence is recorded rather than estimated.
Who sees it: the operator’s coordinators, not other operators, and not the operator’s customers. A position is never passed to another operator, including on network work.
How it is protected: location readings attached to a delivery record are encrypted at rest. Four kinds of location are not encrypted at the field level: the latest position and the 30-day trail (comparing a position with the planned route needs the numbers), the reading taken when a driver scans a barcode, and the address and map position of a manual stop a coordinator adds to a driver’s day (for example, a workshop visit). All are protected by the database separation, access controls and encryption in transit described in section 13, and none is visible outside the operator’s workspace.
Purpose: so coordinators can see where their drivers are and how long ago that was known; so a coordinator is told when a driver is well away from the planned route; so an operator can confirm that a delivery record was made at the delivery; and so a dispute about a delivery can be resolved with evidence.
Where the platform shows a driver’s position on a map, it is the last position their app shared, with how long ago that was. Where there is none, a position inferred from completed jobs is shown instead, and labelled as presumed.
3.5 Proof of delivery: photographs and signatures
Photographs taken by a driver at a stop: the freight, damage, the dock, paperwork.
Signatures captured on a driver’s device.
The name of the person who signed, where recorded.
The driver’s own name, on the record.
These are evidence. They exist to prove what happened, they are encrypted at rest, and they are not altered: a correction is recorded as a new version alongside the original, never as a rewrite.
A photograph taken at a delivery may incidentally include a person, a vehicle or a property. Such images are used only for the delivery record and any dispute about it.
3.6 Technical information
Information
Purpose
IP address, browser, device type
Security, fraud prevention, and diagnosing faults
Login times and account activity
Security, and attributing actions
Error reports
Fixing faults
We do not use advertising trackers, and we do not run third-party analytics on the product.
3.7 Sensitive information
We do not seek sensitive information generally: race, religion, political opinion, sexual orientation, criminal record or biometrics are not collected anywhere in the platform, and no screen asks for them.
There are two exceptions, and because they are real ones we state them rather than let them be discovered: the incident report asks about injuries, and the prestart check asks about fitness to drive.
The incident report form asks “Was anyone injured?” and, where the answer is yes, asks for injury details. “Injury” is also one of the incident types the form offers, and the form records whether an ambulance attended. That is health information, and we are asking for it, so we say so here rather than describing it as something that might turn up.
It is asked because a transport incident has to be recorded properly: for work health and safety obligations, for the operator’s insurer, and because a collision where someone was hurt is not the same event as one where nobody was. The people it can concern are the driver, another driver, or a bystander.
Who asks, and when. W3ME supplies the form; the operator turns it on, and it is a driver or a coordinator in that operator’s business who fills it in after something has happened. It is never asked at signup and never asked of a person as a condition of anything.
What we do with it. The injury details, the description and the other-parties field are encrypted at rest, held as evidence in that operator’s own workspace, visible only inside it, and used only for the incident record and anything arising from it. They are not used for suggestions, for models, or for any assessment of a person, see clauses 6.7 and 6A.4.
The prestart check an operator can switch on asks a driver, before a shift, whether they are fit to drive and free from fatigue, alcohol, drugs and impairing medication. The answers are health information. The operator turns the check on; it is never asked at signup. The answers are encrypted at rest, held only in that operator’s workspace, visible only inside it, and used only for the check. They are not used for suggestions, for models, or for any assessment of a person beyond the check itself.
Also sensitive in practice: driver licence and accreditation details, recorded where an operator chooses to record them. We treat these as sensitive, restrict access to them, and use them only to warn about an unsuitable allocation.
A hazard report is different and is not an exception: it asks about an unsafe condition, not about a person, and health information appearing in its free text would be incidental rather than asked for.
4. Unsolicited information
4.1 Where we receive personal information we did not solicit, we assess whether we could lawfully have collected it. Where we could not, and we are not required to retain it, we destroy or de-identify it as soon as practicable.
4.2 In practice this most often concerns free text entered where it did not belong. If you find such material in a workspace, tell the operator or tell us.
5. Notification at collection
5.1 We state what we are collecting and why at the point of collection: on the signup screens, on the network disclosure screen, and in this policy.
5.2 Where an operator provides information about you, because you are their driver, their customer, or a contact at a delivery site, we collect it from them, not from you. Their agreement with us requires them to hold the right to provide it and to give you any notice they owe you.
5.3 That arrangement does not remove our own obligation. This policy is published so that anyone whose information reaches the platform can read what happens to it, whoever put it there. Where we are required to notify you directly, we will.
6. Use and disclosure
6.1 We use personal information to operate W3ME: to provide the platform, perform the service, bill and collect, support you, maintain security, and comply with the law.
6.2 We disclose it to:
the operator whose workspace it is in;
the service providers listed in section 9, for the purposes stated there;
another operator on the network, only as section 8 describes;
anyone you direct us to;
a purchaser of our business, or a related company, on terms requiring them to handle it under this policy; and
a court, regulator or law enforcement agency, where the law requires or authorises it.
6.3 We do not sell personal information.
6.4 One operator’s data, and another operator. We do not use an operator’s raw or identifiable data to benefit another operator, with two exceptions, both described elsewhere in this policy and neither of them a back door:
the network features in section 8, where information crosses only because an operator chose to send or accept a particular job; and
de-identified model improvement and aggregate statistics, under clauses 6.5 and 6.7, which are by construction not about any identifiable operator, customer or person.
What you can switch off, accurately. The controls live in Settings → Network:
Control
Who can change it
Directory listing: whether other operators can browse you
Any workspace, any tier, one tap, either way, immediately
Receive suggestions: whether we suggest work to you
Any workspace, at any time
De-identified model improvement (clause 6.7)
Any workspace, at any time, one act
Network participation: whether you are in the network at all
A workspace that pays no platform fee may pause it, one day at a time, as often as it likes; switching it off permanently is available only to a workspace that pays a platform fee
So “you can switch the network off” is not true of every workspace, and we would rather say so. On a workspace that pays no platform fee, the network is paused a day at a time rather than turned off for good. The control that matters most for privacy, the directory listing, is free, permanent and one tap, on every tier. Network Trading Terms clause 10 sets this out in full.
6.5 Aggregated and de-identified information. We may produce statistics and insights about platform and network usage, lane volumes, typical durations, network performance, and may use and publish them, but only in a form that cannot reasonably identify a person, an operator, a customer or a counterparty.
6.6 Artificial intelligence. The platform sends information to the AI provider named in section 9 for five purposes, and no others:
the in-product operations assistant an operator’s people talk to;
the customer front desk (AI Pro), where an operator chooses it: on the operator’s behalf it handles their customers’ bookings by email and chat, questions about a job’s status, and service requests, so it receives those customers’ messages and the job details needed to answer them;
a text-rewording pass that removes names and contact details from text passing between operators on the network;
an internal support assistant we use to run the platform; and
reading a credential document an operator uploads, a licence or an accreditation, to pull out its details.
We do not permit the provider to train on your data.
Where an operator brings its own AI key, the operations assistant and the customer front desk send their requests under that key, to the provider that issued it, on the operator’s own agreement with that provider; the operator is responsible for that provider’s terms. The other three purposes always run on ours.
The provider keeps each request and its answer for 30 days, and then deletes it: longer, up to two years, only if it flags a request as breaking its usage rules.
When the in-product assistant cannot answer a question, we keep a copy of the question, encrypted, and our own staff read it to find out what the assistant should be able to answer.
6.7 Improving our own models: on by default, de-identified always, switchable off at any time. Separately from 6.6, every workspace contributes de-identified operating data to improving W3ME’s own models from the day it is created. Stating that plainly:
It is on by default. No action is needed for it to be on.
It can be switched off at any time, in Settings → Network, in one act, taking effect immediately.
What is contributed is de-identified, always. There is no raw-data option and we do not offer one: no version of this setting shares identifiable data about you, your people, your customers or your counterparties.
Nothing about the operator’s day changes either way: not what the platform does, not what it suggests, not what is charged.
What “de-identified” means here, and the bar we hold ourselves to. Information is de-identified when it is no longer about an identifiable individual and the risk of re-identification is very low: the standard the Office of the Australian Information Commissioner applies, judged in the context the data is actually held in, not in the abstract. We apply it by removing the identifying facts before the data reaches the modelling work, names, contact details, business identity, customer identity, street addresses, and by never releasing the result to anybody outside W3ME.
We say “de-identified” rather than “anonymised” deliberately. De-identification is the statutory term and it is a standard we can hold; “anonymous” claims something absolute, and a promise that nothing could ever be re-identified in any circumstance is a promise nobody should make. If information ever stops meeting the de-identified standard, it is personal information again and the whole of this policy applies to it.
Operators are told this at signup, on the same screen as the network directory disclosure. The contractual side is Platform Terms of Service clause 5.4.
6A. Computer-generated suggestions about people
This section exists to meet a privacy rule that takes effect on 10 December 2026, requiring a privacy policy to disclose where computer programs make decisions that significantly affect an individual, or do things substantially and directly related to making them. We are stating our position ahead of the date rather than after it.
6A.1 What the platform does. W3ME generates suggestions about how work should be allocated: which driver and vehicle suit a job, how a day should be ordered, and whether a job is worth sending to or taking from another operator on the network. Those suggestions can relate to an identifiable individual, most obviously a driver, because a suggestion about who should do a job is a suggestion about a person.
6A.2 A human makes every decision, with one narrow exception. The platform does not allocate, dispatch, accept or refuse work by itself. A coordinator in the operator’s business makes the decision, and can accept a suggestion, change it, or ignore it. The exception: in a workspace with only one driver, there is no choice of driver to make. When a person in that business creates a job, the platform places it on that driver’s day and sends it to their phone, as part of the same act. It stops as soon as the workspace has a second driver. The platform never accepts, refuses or sends network work by itself.
6A.3 What the suggestions are built from, in plain terms:
which drivers and vehicles the operator has rostered, and which are paired for the day;
where each vehicle is in its day, and how long it takes to travel between stops;
the job’s pickup and delivery windows, and the priority the operator has set for the job and the customer;
the vehicle’s capacity and what it is capable of carrying; and
licence, accreditation and capability facts the operator has recorded: used to warn or to exclude an unsuitable pairing.
6A.4 How drivers are ordered, and what is not used. The platform ranks drivers for a job on availability and current workload only. It holds no rating of a driver and learns no preference between them. Suggestions are not built from a driver’s personal characteristics, their history of complaints or discipline, their pay, their health, or any assessment of them as a person.
6A.4a Carriers are different: their record does affect the order they are offered work, and we say so plainly. Where an operator engages an outside carrier, another business, the platform keeps a performance record for that carrier. Where the carrier is a sole trader, the carrier is a person, so that record is information about an individual, and this clause is written for that case.
What the record is made of. Four measures over the carrier’s completed work, weighted: delivered on time (40%), delivered first time (25%), proof of delivery complete (20%), and claim-free (15%). Recent months count more than old ones and nothing older than twelve months counts at all. An adverse event counts against a carrier only where a recorded cause says it was theirs: an event with no recorded cause, or a cause outside their control, leaves the calculation entirely rather than counting against them. An operator may also record their own 1-to-5 opinion of a carrier, with a reason; that is a human judgement, not a computed one.
There are two layers. An operator’s own record of a carrier is built from that operator’s own jobs. A shared record is built from counts contributed by several operators, and is released only where there are at least ten measured jobs and at least two contributing operators, with no single operator counting for more than half of it, so a shared number can never be one operator’s private opinion wearing a public label.
What it affects: this is the part the incoming rule is about. When an operator’s plan reaches “engage a carrier” and several would do, the platform orders the list of carriers to call, and a carrier’s performance record is one of the two things that decides that order (the other is relative price). The operator sets which leads, in one setting: cheapest first, balanced, or best performers first.
What that ordering never does, by construction rather than by policy:
It never removes anybody. Every carrier that would do is on the list; there is no threshold, no filter and no cut-off, and the person choosing sees all of them.
A carrier with no record is placed neutrally, never last. Having no rating yet does not behave like being rated badly.
It never changes a price. A carrier’s record does not move what anyone is charged or paid.
It never ranks drivers (see 6A.4), never appears in the network directory, and is not used to match or allocate work on the network: the network’s matching does not read it at all.
A person still decides. The order is a suggestion about who to approach first. A coordinator engages whoever they choose.
6A.4b Contesting a carrier record. A carrier can contest how one of their jobs was recorded. While a contest is unsettled, and if it succeeds, that job is left out of every number, on every layer, for every operator. Contest it by emailing [email protected]: we handle it under section 17, and today the lodgement is by that route rather than a screen of your own.
Star summaries are being held pending legal review. Where a rating is shown as stars rather than as the underlying counts, that display is switched off for live operators until this pack has been reviewed. The counts themselves, “38 of 41 deliveries were inside the window”, are statements of fact with a denominator, and they serve.
6A.5 Effect on a driver. The realistic effect of a suggestion on an individual is which work they are offered on a given day. That is a decision their employer makes, using the platform as one input among others, and it is subject to whatever rights the driver has against their employer.
6A.5a Effect on a sole-trader carrier: the case where nobody stands in between. A driver has an employer making the decision. A sole trader working as a carrier does not: the operator’s decision about who to call lands on them directly, and their own performance record is one of the inputs to the order they are called in. We do not think that makes the record unfair: it is built from their own completed work, adverse events count only where a cause says they were theirs, the ordering removes nobody, and a person makes the call. But it is a computer-assisted input into what work an individual is offered, so it is disclosed here rather than left to be inferred.
6A.6 Asking about a suggestion, or about a record. A driver or a carrier, or an operator on their behalf, can ask us what inputs produced a particular suggestion, or how a performance record was worked out. Ask us under section 16. The method itself is published in the product, so a carrier can check the arithmetic rather than take it on trust. Where a coordinator’s decision is what you want explained, the operator is the right door: they made it.
7. Direct marketing
7.1 We email operators about their own account, invoices, statements, service changes, security matters and support. That is service communication, not marketing, and it continues while you hold an account.
7.2 We may send marketing email to an operator’s account contacts about W3ME features and offers. Every such message carries a working unsubscribe link, and unsubscribing takes effect promptly.
7.3 We do not market to an operator’s drivers, or to an operator’s customers.
7.4 We do not provide contact details to third parties for their marketing.
7.5 To stop marketing, use the unsubscribe link or email [email protected].
8. What the network discloses
8.1 Before a job is shared, the network operates on suburb and freight details only: what needs moving, approximately where, and when. No customer names, no street addresses and no personal information cross until an operator chooses to share a particular job.
8.2 The directory shows trading facts only: business name, and when published, vehicle types and service area. Never a street address, a depot pin, a phone number or an email address. Listing is on by default for companies, partnerships and trusts, and off by default for sole traders, because for a one-person operation the trading name and the service area can be personal information. The control is one tap, either way, at any time. The detail is in the Network Directory Disclosure.
8.3 On acceptance of a shared job, the performing operator receives what is needed to run the job: the business name at each site, the addresses, the freight details, the times and windows, and any special instructions. The paying customer is not disclosed to them.
8.3a Site contact details do not cross. Contact names, phone numbers and email addresses for the people at each site stay with the sending operator and are not passed to the performing operator. If the performing operator needs something at a site, access, an instruction, a call made, it goes back through the sending operator, in the platform. This is a design choice and it is enforced in the software: the channel that carries job detail across refuses to carry a contact field at all. It keeps the sending operator’s relationship with their own customer intact, and it means a counterparty cannot come away from a job with a contact list.
8.4 The paying customer is not told who performed the work. Their invoice and proof of delivery come from the operator they engaged, with no carrier name and no W3ME name.
8.5 The performing operator’s driver’s first name may appear on a proof of delivery. The receiver observed that person hand over the freight; recording it is an operational fact.
8.6 Where an operator does come to hold another operator’s own contact details through a network trade, those details are for the job that produced them and not for marketing, prospecting or a contact list. Site contact details are a separate matter and simply do not cross: see 8.3a.
9. Service providers
We use a small number of service providers. This is all of them.
Provider
What they do
Where they operate
Amazon Web Services
Hosts the platform and stores the data
Your region’s data location: for Australia, Amazon Web Services’ Sydney region, with a backup replica in its Melbourne region (primary data and its primary backups both stay in Australia)
Backblaze
Holds a last-resort copy of our database backups, solely to recover the platform if our primary cloud account is lost. The copy is encrypted with keys held by W3ME before it leaves Australia, so Backblaze cannot read it; Backblaze also encrypts it at rest, and it is sent over an encrypted (TLS) connection. It is access-restricted and never used for processing
United States
Stripe
Holds and processes payment methods (a card; bank direct debit only where offered). We never see a full card number
Australia and the United States
Cloudflare
Sits in front of the website; provides Turnstile, the bot check at signup and sign-in
Global network, including Australia
Postmark
Sends our email: notifications, statements, invoices, password resets
United States
Google Places / Google Geocoding
Address lookup and autocomplete. Receives the address text being looked up
Global
Anthropic
AI model provider, for the five purposes in clause 6.6: the in-product operations assistant, the customer front desk (AI Pro), the network text-rewording pass, our internal support assistant, and reading uploaded credential documents. Receives the text or document involved. AI features send message text to Anthropic, which retains inputs and outputs for 30 days, longer only as clause 6.6 sets out.
United States
Xero
Accounting. Where an operator connects their own Xero account, we send their invoices, statements and contact records to it. Only for operators who connect it
Global; Australian data centre for AU organisations
Australian Business Register (ABR)
Business identity. We look up an ABN to confirm the business and its entity type. Sends the ABN, receives the register’s public record
Australia
Browser push services (Apple, Google, Mozilla)
Delivering push notifications to a browser or phone. Receives the notification payload and the device’s push endpoint. Which one is used depends on the browser
Global
Microsoft push service (Windows Push Notification Services)
Delivering push notifications to the Edge browser on Windows. Receives the notification payload and the device’s push endpoint
Global
OpenStreetMap tile servers (OpenStreetMap Foundation)
Map imagery in the driver and coordinator maps. Receives map tile requests, including the IP address of the device viewing the map and the map area being viewed
Tiles are served from outside Australia
Freight carriers and systems you connect (for example Mainfreight, Border Express, Northline, CargoWise, or a webhook address you set up)
Only where an operator connects one. We send the consignment and job details that operator’s connection needs to book, track or report freight, and receive status updates back
Depends on the carrier or system the operator chooses; the major Australian carriers operate in Australia
ntfy (hosted notification service)
Our own operational alerts to W3ME staff phones, about faults in the platform. An alert can name the operator it affects. Operational alerts, which can include IP addresses, usernames and system log lines, are sent to ntfy, which is hosted in the United States.
United States
Cloudflare (second role)
Beyond the website front and Turnstile: we call Cloudflare’s DNS and custom-hostname API to set up an operator’s own domain. Sends the hostname
Global
Self-hosted, and therefore not a third party at all: our routing and travel-time engine (Valhalla) runs on our own infrastructure. Addresses and coordinates used for routing do not leave our systems for it.
9.1 Each provider handles only what it needs for its function, under a contract requiring it to protect the information.
9.2 This table is kept current. If we add a provider we update it, and where the change is material we notify operators before it takes effect.
10. Information crossing borders
10.1 Your data is hosted in your region. The data location for your region is stated in your regional Schedule and in the Part 2 module for your region.
10.2 Some providers operate from other countries, as the table in section 9 shows. In particular:
Postmark sends our email from the United States. Email content, a statement, an invoice, a notification, a password reset, passes through their systems.
Anthropic processes AI requests in the United States.
Stripe operates in Australia and the United States. Payment details go to Stripe directly from your browser.
Cloudflare and Google operate global networks; requests may be handled outside your region.
Browser push services (Apple, Google, Mozilla, Microsoft) deliver notifications through global networks.
Xero, where an operator connects it, holds Australian organisations’ data in an Australian data centre, but operates globally.
The Australian Business Register is Australian and does not leave the country.
OpenStreetMap’s tile servers serve map tiles from outside Australia.
Freight carriers and systems an operator connects operate where that carrier or system operates.
ntfy, which carries our internal operational alerts, operates in the United States.
Backblaze holds a last-resort copy of our database backups in the United States, encrypted with keys held by W3ME before it leaves Australia, see 10.2a.
10.2a Backups. Your primary data and its primary backups are held in your region: for Australia, in Amazon Web Services’ Sydney region, with a backup replica in its Melbourne region. One copy is held outside your region: a last-resort copy of our database backups, kept with a second provider, currently Backblaze, in the United States, solely so that we can recover the platform if our primary cloud account is ever lost. That copy is encrypted with keys held by W3ME before it leaves Australia, so the provider holds nothing it can read. The provider also encrypts it at rest, and it travels over an encrypted (TLS) connection. Access to it is restricted, and it is never used for processing: it is read only to recover from a disaster. If we ever move a backup copy to another country or another provider, we will amend this policy and give notice under clause 21.2 before the change takes effect, not after.
10.3 Before disclosing personal information to an overseas recipient, we take reasonable steps to ensure they handle it consistently with this policy and with the privacy law of your region, through the contract we hold with them.
10.4 We will notify you of a material change.
11. Government identifiers
11.1 We do not use a government identifier as your identifier in our systems. Workspaces are identified by our own identifiers.
11.2 We record the business identifier for your region (in Australia, the ABN), because it is a public business identifier required for tax documentation. We do not record tax file numbers, health identifiers or driver licence numbers as identifiers.
11.3 Where an operator records a driver licence number in their own workspace, that is their record, held for their compliance purposes. We do not use it to identify anyone.
12. Accuracy
12.1 We take reasonable steps to keep personal information accurate, current and complete.
12.2 Most of it is under your direct control: account details, staff details, customer details and job details are editable in the workspace by anyone with access.
12.3 Evidence is treated differently, by design. A proof of delivery, photograph, signature or incident report records what happened at a point in time. We do not edit those. A correction is recorded as a new version alongside the original, so the history remains intact and a dispute can be resolved by reference to both.
12.4 If you believe something we hold about you is wrong, see section 17.
13. Security
13.1 What we do:
Each operator’s data is held in its own database. Separation between operators is at the database level, not by a filter in application code.
Sensitive fields are encrypted at rest: names, addresses, contact details, location readings on proof of delivery and other evidence records, evidence payloads and assistant conversations among them. Four things are not encrypted at the field level: messages between people in a workspace (the conversation on a job); a driver’s latest position and 30-day location trail (section 3.4); the location reading taken when a driver scans a barcode; and the address and map position of a manual stop a coordinator adds to a driver’s day. They are protected by the database separation, the access controls and the encryption in transit described in this section. We are naming the exceptions rather than claiming more than we do.
All traffic is encrypted in transit (TLS).
Access is role-based. People see what their role requires.
Access to production systems is restricted, multi-factor and logged.
Backups are taken and stored in your region, apart from the one last-resort copy of database backups held outside it for disaster recovery only. That copy is encrypted with keys held by W3ME before it leaves (clause 10.2a).
Automated checks fail our own build if a field declared protected stops being protected, or if personal information reaches a log.
13.2 No system is perfectly secure. Section 14 sets out what happens if something goes wrong.
14. Retention
14.1 How long we keep things:
What
How long
Delivery evidence: proof of delivery, photographs, signatures, scan events
7 years from the date of the event it records, then deleted or de-identified. See 14.2
A driver’s location trail (section 3.4)
30 days, then reduced to a route record with no driver, vehicle, job or stop attached, and the positions deleted. Only the latest position is kept beyond that, and it is replaced each time
Everything else in your workspace, while your account is open
For as long as your account is open
Everything else in your workspace, after termination
90 days, so a closure can be reversed and any outstanding amount settled, then deleted or de-identified
Tax and business records, including invoices and statements
For the period the law of your region requires. The Australian position is in Schedule AU clause 4B
The audit record of who did what in your workspace
Retained while your account is open, and deleted with your workspace data on the 90-day cycle. We do not currently run automated deletion of it on a shorter cycle
Server and application log files
Rotated continuously as they reach a size limit, so they hold only recent activity: days to weeks, not years. They are operational diagnostics, not a record we keep
Backups
Under a storage lifecycle policy. Stored media: non-current versions expire after 30 days. Media backups and their Melbourne copy: non-current versions expire after 90 days
Anything we have placed under a legal hold on written request
Until the hold is lifted, regardless of the rows above
14.2 Why delivery evidence is kept for 7 years, and why it is no longer kept indefinitely. Evidence substantiates an operator’s income and their disputes, and a freight dispute can arrive years after the job, so it has to outlive the 90-day workspace cycle. Seven years is set against the tax and commercial record-keeping obligations operators carry (generally five to seven years, depending on the record and the jurisdiction), with headroom rather than an open-ended promise. The period runs from the date of the delivery or event, not from the date your account closes, so evidence ages out on its own clock whether you are still a customer or not.
14.3 These are the two classes, and they are the same two the Platform Terms of Service state at clause 13.5. Delivery evidence on the 7-year clock; everything else on the 90-day post-termination cycle. The one shorter period inside “everything else” is a driver’s location trail, which is reduced after 30 days whether or not the account is open (section 3.4).
14.4 A different period can be agreed. If your business needs evidence kept for longer, or deleted sooner, email us at the address in section 16.
14.5 When we destroy information, we destroy it or de-identify it so that it cannot reasonably be re-identified.
15. Data breaches
15.1 We comply with the data breach notification law of your region, identified in the Part 2 module.
15.2 Where a breach is likely to cause serious harm, we notify the affected people and the regulator as soon as practicable, and within the time the law requires.
15.3 We notify the affected operator first, ahead of the minimum the law requires, because they may need to notify their own customers.
15.4 We will state what happened, what information was involved, what we are doing, and what you should do.
16. Access to your information
16.1 You may request a copy of the personal information we hold about you. Email [email protected] with “Privacy: access request” in the subject line.
16.2 We will ask you to verify your identity.
16.3 We respond within 30 days, providing the information in a usable form: usually a common machine-readable file, or plain readable text.
16.4 There is no charge for making a request. We may charge a reasonable cost-based fee for providing access where a request is large or complex. We will state the amount before doing the work, and you may withdraw the request.
16.5 Where we refuse, we will do so in writing, give reasons, and explain how to complain. The grounds for refusal are those the law of your region allows.
16.6 If your information sits in an operator’s workspace, that operator can usually answer you faster, because they know why they hold it, so asking them first is the quickest route. But you do not have to. We hold the information and the obligation is ours (clause 1.2). A request made to us is handled by us, on the timeframes above, and we will not refuse it on the ground that the information belongs to an operator.
17. Correction
17.1 You may ask us to correct personal information that is inaccurate, out of date, incomplete, irrelevant or misleading. Email [email protected] with “Privacy: correction request”.
17.2 We respond within 30 days, at no charge.
17.3 Where we have disclosed the information to a third party and you ask us to, we will take reasonable steps to notify them of the correction.
17.4 Where we refuse to correct something, we will give reasons in writing and, on request, attach a statement of your view to the record.
17.5 Evidence records are corrected by adding a version, not by overwriting, see clause 12.3. We will say so when we do it.
18. Complaints
18.1 Email [email protected] with “Privacy complaint” in the subject line, setting out what happened and the outcome you seek.
18.2 We acknowledge within 5 business days and respond substantively within 30 days.
18.3 If you are not satisfied, you may complain to the privacy regulator for your region, identified in the Part 2 module. Complaining costs you nothing and does not affect your account.
19. Cookies and the website
19.1 We do not use a session cookie. Your signed-in session is held in your browser’s own local storage, not in a cookie we set.
19.2 We do not use advertising cookies, tracking cookies or third-party analytics anywhere in the product.
19.3 Cloudflare Turnstile, the check that a signup or a sign-in is not automated, sets what it requires to do that, on the signup and sign-in pages only.
19.4 Clearing your browser’s storage for our site signs you out.
20. Children
W3ME is a business tool. It is not for anyone under 18, and we do not knowingly collect information about children.
21. Changes to this policy
21.1 This document carries its own version number and date, at the top.
21.2 Where we change something material, a new provider, a new use, a change to retention, we notify operators by email and in the product at least 30 days before it takes effect.
21.3 Every published version remains available.
PART 2: REGION MODULES
A region module states the privacy law, the regulator, the breach-notification scheme and the data location for one region. A new region is added by adding a module here and a Schedule to the Master Agreement. Part 1 does not change.
Region module: Australia
Applies to: workspaces with a recorded country of Australia.
Entity
W3ME Pty Ltd (ABN 35 683 322 803)
Privacy law
Privacy Act 1988 (Cth) and the Australian Privacy Principles
Regulator
Office of the Australian Information Commissioner (OAIC)
Regulator contact
oaic.gov.au · 1300 363 992 · GPO Box 5218, Sydney NSW 2001
Breach notification
Notifiable Data Breaches scheme, Part IIIC of the Privacy Act 1988 (Cth)
Data location
Australia: Amazon Web Services’ Sydney region, with a backup replica in its Melbourne region. A last-resort copy of database backups, encrypted with keys held by W3ME before it leaves Australia, is held in the United States, for disaster recovery only (clause 10.2a)
Electronic messaging
Spam Act 2003 (Cth)
Business identifier
Australian Business Number (ABN)
Automated decisions
Disclosure requirement effective 10 December 2026: answered by section 6A
Record retention
Schedule AU clause 4B
Mapping. Part 1 is written to the Australian Privacy Principles. For reference:
APP
Part 1 section
APP 1: open and transparent management
1
APP 2: anonymity and pseudonymity
2
APP 3: collection of solicited information
3
APP 4: unsolicited information
4
APP 5: notification of collection
5
APP 6: use and disclosure
6, 6A, 8
APP 7: direct marketing
7
APP 8: cross-border disclosure
9, 10
APP 9: government related identifiers
11
APP 10: quality
12
APP 11: security and destruction
13, 14
APP 12: access
16
APP 13: correction
17
Automated decisions. The requirement to disclose computer-generated decision-making, which takes effect 10 December 2026 as an addition to the policy-content obligations in APP 1, is answered by section 6A.
Contact
Write to the W3ME entity for your region, identified in the module above.
Australia: W3ME Pty Ltd · ABN 35 683 322 803
Email: [email protected] (mark it “Privacy”)
Post: to our registered office, addressed to the Privacy Contact.