Invixo
Legal

Privacy Policy

What personal information Invixo actually collects, where it is kept, who else sees it, how long it stays, and what happens if it is ever breached.

Draft — not legal advice

This document has not been reviewed by a lawyer. It is a working draft written to be read and corrected, not to be relied on. Have an Australian privacy lawyer review it before it is published or referenced by any acceptance record. The placeholders marked LIKE THIS are facts only the business owner can supply.

A note on what was asked for, and what is written here

These documents were commissioned alongside terms that were to “take no responsibility for anything”. Written that way, they would be worse than useless in Australia. The Australian Consumer Law implies statutory guarantees that cannot be excluded by a contract term — section 64 of the ACL makes any term purporting to exclude, restrict or modify them void — and telling a customer they have no rights when the law says they do is itself a breach the ACCC pursues. A term a court strikes gives no protection at all. The Terms of Service therefore say the enforceable version of the same thing, which is genuinely strong.

The privacy half has its own version of that trap, and it is the reason section 12 of this policy makes a promise instead of dodging one. The Notifiable Data Breaches scheme is mandatory. A data breach likely to result in serious harm must be notified to the Office of the Australian Information Commissioner and to the people affected. No policy wording, no contract term and no customer agreement can disclaim that obligation — so this policy states plainly that we will notify, because the alternative is a policy that is misleading about the one thing a customer most wants to know.

Everything in the inventory below was read out of the source code rather than assumed. If the product starts collecting something new, this page is wrong until it is updated.

Version v1.0-draft
Last updated 22 August 2026
Status DRAFT — unreviewed
Applies to Invixo (all accounts)

1Who we are

Invixo is operated by [LEGAL ENTITY NAME] [ABN] of [REGISTERED ADDRESS], in Western Australia. In this policy, “we” and “us” mean that entity.

Privacy enquiries go to [PRIVACY CONTACT EMAIL].

2What this policy covers

This policy covers personal information we handle when you use Invixo — as an account holder, as a client invited to view a project, or as a person whose details appear inside a customer's project data.

We handle personal information in line with the Australian Privacy Principles in the Privacy Act 1988 (Cth) and with the Notifiable Data Breaches scheme in Part IIIC of that Act. [OWNER + LAWYER: confirm whether the Act binds this business by force of law, or whether we opt in] — either way, this policy is a commitment we intend to keep.

A distinction that matters here. Most of what customers upload is survey and design data, not personal information — a point cloud is not a person. But some of it is: names and signatures on permits, faces and locations in site photographs, the email address of a client you invite. Where a customer uploads personal information, that customer decides what is collected and why; we hold and process it on their behalf. Where we collect it directly — your account details, your activity log — we are the ones responsible.

3What we collect

This is the actual inventory, taken from the system itself rather than written from a template.

3.1 Your account

WhatDetail
NameThe display name on the account.
Email addressYour sign-in identity and where we contact you.
PasswordStored only as a scrypt hash with a per-account salt. We never store, log or email your password, and we cannot read it or tell you what it is.
Role and organisationYour permission level, and which organisations and projects you belong to.
Display preferencesPer-user interface settings — theme, panel choices and similar. Display only; nothing here grants access to anything.
Account statusWhether the account is active, and when it was created.

3.2 The activity log

Every state-changing request — anything that creates, updates or deletes something — writes one row to an append-only audit log, along with sign-ins and sign-outs. Each row records:

  • who — the actor's email address and role (or a marker such as (share guest) where there is no account);
  • what — the action (login, logout, create, update, delete), the HTTP method, the request path, and the resulting status code;
  • where — the project it belongs to, and the IP address the request came from;
  • when — the timestamp.

Health checks, event streams and the “who am I” call are deliberately left out, because logging them would bury the trail in noise. The log is visible to administrators of your organisation on the Activity page. It exists so a change to a project can be traced to an account — which is as much your protection as ours.

3.3 Project data you upload

Survey and design files, models, point clouds, drawings, documents, alignments and everything the platform derives from them. We also extract and store the text of document pages so that documents can be searched.

Most of this is not personal information. Some of it may be — a drawing title block with a person's name, a document containing contact details. We do not inspect it, index it for any purpose beyond your own search, or use it for anything except running the platform for you.

3.4 Site photographs

When a photograph is uploaded to a project we store the image, its filename, any caption, and a generated thumbnail. We also read two things out of the file's EXIF metadata, because the product uses them to place the photo on the map and on the timeline:

  • GPS latitude and longitude, converted to decimal degrees — this is what puts a pin on the map;
  • the original capture date and time.

Both are best-effort: a photo without GPS still uploads, just without a pin. A location can also be set by hand, and we record which of the two it came from. Be aware that a phone photograph usually carries the exact location where it was taken. If that matters for a particular site, strip the metadata before uploading, or set the location manually.

3.5 Client invitations

When you invite a client to view a project read-only, we store the email address you invited, a label you choose for them, who created the invitation, any expiry, a hash of the single-use set-up link, the scrypt hash of the password the client sets for themselves, the time of their last sign-in, and an identifier for their one live session. The raw invitation token is never stored — only its SHA-256 hash — so a database read cannot hand out a working link.

You choose who to invite. We do not add those addresses to any list, and we do not contact them for any purpose other than delivering the invitation you asked us to send.

3.6 Permits

The permit system records the people involved in hazardous work: typed names, drawn signature images, roles, dates and comments, together with a snapshot of the exact declaration wording each person signed. Some signers have no account at all, in which case the typed name and the drawn signature are the whole attribution. This is a safety and compliance record, which is why section 7 treats it differently from everything else.

3.7 Support correspondence

If you write to us for support, we keep the message and our reply, including anything you choose to attach.

4Why we collect it

  • To run the platform — to sign you in, show you your projects, process imports and compute the outputs you asked for.
  • To keep it secure and accountable — the activity log lets a change be traced to an account, and lets an intrusion be investigated.
  • To support you — to diagnose a problem you have reported.
  • To meet legal obligations — where a law requires us to keep or produce something.

We do not use your personal information for any other purpose without asking you first.

5What we do not do

We do not sell your personal information or your project data. Not to anyone, not in aggregate, not de-identified.

We do not run third-party analytics, advertising, tracking or profiling in this product — there is no analytics script in the application. We do not send marketing email off the back of a client invitation. We do not use your project data to train anything.

6Where it is stored

Invixo runs on hosted infrastructure operated by [HOSTING PROVIDER] in [HOSTING LOCATION / REGION]. Within it:

  • account details, the activity log, permits and project metadata are held in a PostgreSQL database;
  • uploaded files, derived products, photographs and thumbnails are held in an S3-compatible object store;
  • a queue holds jobs in flight while imports and computations run.

Backups. We take an hourly copy of the database and keep the most recent 72 of them — about three days of history — and periodic full backups of which the most recent three are kept. Backups exist so that we can restore the service after a failure. They are held in the same infrastructure as the platform [OWNER: confirm, and state where any off-site copy lives].

Because backups roll, information you delete may persist in a backup for a short period after it is gone from the live system. It is overwritten as the backups cycle.

7How long we keep it

WhatHow long
Account detailsFor as long as the account exists, then [RETENTION PERIOD] after it is closed.
Project dataFor as long as your agreement runs, plus the export window in the Terms, clause 15.
Deleted datasetsHeld in a bin that empties itself after a set period, because a re-importable file is replaceable.
The activity logKept indefinitely. It is an append-only record and there is no automatic purge — a trail with holes in it is not a trail. [OWNER + LAWYER: set a retention period, or record the decision to keep it indefinitely]
PermitsNever automatically purged. A permit says who was allowed to do hazardous work, when, and who signed for it, and it may be needed years later for an incident investigation or an audit. Deleting one in the product only hides it.
Client invitationsUntil revoked or the account is closed.
BackupsAbout three days of hourly database copies; the three most recent full backups.
Support correspondence[RETENTION PERIOD]

Where we no longer need personal information and no law requires us to keep it, we delete it or de-identify it.

8Who else sees it

Inside your organisation, who can see what is decided by the roles and project permissions your administrators set. A client invited to view a project sees that one project, read-only, and nothing else.

Outside, we use a small number of sub-processors. These are the only third parties that receive anything:

WhoWhat they receive, and why
Mapbox
(map provider)
Map views load basemap tiles, terrain and fonts directly from Mapbox in your browser. Mapbox therefore receives your IP address and the map area you are looking at, under its own privacy policy. It does not receive your uploaded project data — that is drawn on top, from our servers, in your browser.
Email relay
[EMAIL PROVIDER NAME]
Outgoing mail — client invitations, and plans you choose to email — is sent through an SMTP relay. It receives the recipient's email address, the subject and body, and any attachment you asked us to send.
Hosting provider
[HOSTING PROVIDER]
Operates the servers and storage the platform runs on, and can therefore hold the data at rest.
Public code CDNs
(jsDelivr, unpkg)
Some of the mapping and PDF libraries the interface uses are fetched from public code distribution networks. Those services see your IP address and which file was requested. They receive no account details and no project data.

We also disclose personal information where we are required or authorised by law to do so, and where it is necessary to protect someone's safety or to enforce our rights. If we are ever compelled to hand over your data, we will tell you where the law lets us.

If we are ever bought or merged, your information may transfer with the business — and it would remain subject to a policy at least as protective as this one.

9Overseas disclosure

Some of the sub-processors above operate outside Australia. Mapbox is based in the United States, and the code distribution networks serve from wherever is nearest to you. Using the platform means basemap and library requests will leave Australia in the ordinary course.

Where our hosting or email provider stores or processes data overseas, we will say so here: [OWNER: confirm hosting and email regions, and list every country].

10How we protect it

  • Passwords are never stored in readable form — only as salted scrypt hashes, for both staff accounts and client viewer accounts.
  • Invitation tokens are stored hashed, never in clear. A leaked database copy cannot be used to redeem an invitation.
  • Sessions use a signed, HttpOnly cookie that scripts on the page cannot read, valid for up to 14 days. Client viewer accounts are limited to a single live session — a newer sign-in invalidates the older one.
  • Access is enforced on the server, not merely hidden in the interface, and is scoped per project. A client viewer is confined to the one project they were invited to.
  • The activity log is append-only, and the network address it records is taken from a header our own proxy controls rather than one a client can forge.
  • Backups are taken regularly and restores are rehearsed.

No system is perfectly secure, and we do not claim otherwise. If something does go wrong, section 12 says what happens.

11Access and correction

You can ask us what personal information we hold about you, ask for a copy of it, and ask us to correct it if it is wrong. Write to [PRIVACY CONTACT EMAIL].

We will respond within 30 days. We do not charge for making a request. If we refuse — which we would only do where the law allows, for example where releasing it would reveal someone else's personal information — we will tell you why in writing, and how to complain about it.

Much of it you can see and change yourself: your name and preferences in your account settings, and your organisation's activity log on the Activity page.

If the information you are asking about sits inside a customer's project data rather than in your own account, we will point you to the customer who controls it, because it is theirs to correct.

12Data breaches — we will tell you

If personal information we hold is lost, or accessed or disclosed without authorisation, and that is likely to result in serious harm, we will notify the Office of the Australian Information Commissioner and the people affected. This is the Notifiable Data Breaches scheme under Part IIIC of the Privacy Act 1988 (Cth). It is a legal obligation, it cannot be contracted out of, and we are not attempting to.

Our commitment, in plain terms: we will investigate as soon as we suspect a breach and complete that assessment within 30 days; if it is notifiable we will tell the Commissioner and the affected people as soon as practicable; and the notice will say what happened, what information was involved, and what you should do about it. If your customers' data is involved, we will tell you so you can meet your own obligations.

We would rather tell you about a breach that turns out to be minor than sit on one that turns out not to be.

13Complaints

If you think we have mishandled your personal information, tell us first at [PRIVACY CONTACT EMAIL]. We will acknowledge within 7 days and respond substantively within 30 days.

If you are not satisfied with our response, you can complain to the Office of the Australian Information Commissioneroaic.gov.au, 1300 363 992. You do not need our permission to do that, and complaining to us first does not cost you the right to.

14Cookies and browser storage

We use no advertising or tracking cookies. What the platform sets is:

  • a signed session cookie (HttpOnly) that keeps you signed in, and an equivalent for client viewer sessions;
  • a small readable marker telling the interface that a client viewer session is in progress;
  • browser local storage holding your theme choice, which organisation you are working in, and a hint that you are signed in. These stay in your browser; they are not sent to us as a record of you.

Clearing your browser storage signs you out and resets those preferences. It costs you nothing else.

15Changes to this policy

We will update this policy when what we do changes. The version string and date at the top change with it, so an acceptance record can point at a specific version. This is v1.0-draft, dated 22 August 2026. We will tell account holders about material changes before they take effect.

*Notes for the reviewing lawyer

Open questions this draft deliberately does not decide:

  • Whether the business is an APP entity by force of law (the small-business turnover threshold), or should opt in under s 6EA. This policy is written as though the APPs apply; if they do not yet, the commitment should be a deliberate choice rather than an accident.
  • Whether a separate data processing agreement is needed with customers, given that most personal information in the system is uploaded by them and controlled by them. Section 2 draws the line but does not paper it.
  • Retention periods: the activity log currently has no purge, and permits are deliberately never purged. Both need a written retention decision from the business rather than an implementation detail standing in for one.
  • Overseas disclosure under APP 8 — the accountability that attaches to Mapbox and to any overseas hosting or email provider, and whether the exceptions apply.
  • EXIF location in site photographs: whether an in-product warning at upload time is warranted, given a phone photo usually carries an exact position and the uploader may not be the person in frame.
  • Permit signatures: whether a drawn signature image plus a typed name from an unauthenticated signer needs its own collection notice at the point of signing.
  • Whether an APP 5 collection notice is needed at sign-up and at client invitation, separate from this policy.

Invixo — Privacy Policy · v1.0-draft · 22 August 2026 · DRAFT, not legal advice.
See also the Terms of Service and the Support page.