Last updated · 4 September 2026
Plain-language summary of where your data is stored, who handles it, how we use AI, and what you can ask us to do with it.
Structa processes and stores customer data in Australia: the systems of record, file storage, AI processing, address geocoding, travel routing and transactional email all run onshore. The narrow exceptions — SMS where enabled, push-notification routing, and short-lived edge/operational handling — are named below. Specifically:
This is an architecture and configuration statement about the systems of record and processing locations, not an independent third-party attestation; the narrow offshore surfaces are disclosed in the table below. Customers with stricter isolation requirements should contact us before signing.
The platform stores the data you and your team enter:
We do not request or store payment card data. A job may contain vulnerability, health or support information where an insurer or repairer records it to safely serve the customer; that information is treated as sensitive and access-controlled.
Visiting our public website is different: it collects no account or claim data, and what it does record — website analytics, coarse usage events, and anything you send us through a contact or waiting-list form — is set out under “Our website” below.
We process the data above to deliver the Structa service to you: run the workflow, generate quotes and invoices, surface SLA breaches, and produce assessment reports. We do not sell your data and we do not rent it.
There are three things we do with your data, and only three. We run the service you pay for, including the AI features you switch on. We measure how the platform performs — including whether its suggestions were accepted, corrected or dismissed — and use that to improve it. We train damage-recognition models on your data only if an admin in your organisation opts in. Each is set out below.
1. Running the service, including AI features. Optional AI features send the job, assessment, policy, correspondence, document, photo, or voice context needed for the requested action to the AI service. Only the part of your organisation’s data the requested feature needs is sent — an excerpt assembled for that one request, always scoped to your organisation, never another organisation’s data. That inference runs in Australia — chat, agent reasoning and claim-photo vision on AWS Bedrock (Sydney and Melbourne); text embeddings and speech-to-text transcription of voice notes on Microsoft Azure Australia East. Your data is hosted and stored in Australia too. Before any text leaves for a provider, we strip personal identifiers — both the identifiers we already hold (names, contact details, addresses, and claim/policy/job references) and identifiers we detect by pattern in free text (emails, phone numbers, addresses, government identifiers, and payment details) — as a second layer of protection, even though inference is now in Australia. Images and audio are the exception: they are not de-identified and are sent under a disclosed control your organisation can turn off (a voice recording’s transcript text is still stripped). We do not represent that AI inputs are de-identified or anonymised.
2. Improving the platform. We measure how Structa is used and how well it performs, and use what we learn to make it better. Two kinds of signal, and we are precise about the difference:
Nothing in this second use crosses between organisations, and nothing in it trains a model. The only use of your data that does either is the model-improvement opt-in below.
3. Training models — only if you opt in. Ordinary feature use does not authorise us, or our providers, to reuse your data for model training. Our AI providers are contractually committed not to train on API data by default, and we enable no opt-in that would change that. There is exactly one exception, and it is off until an admin in your organisation turns it on: model improvement, below.
Structa can learn from the damage your assessors confirm on site, so the platform gets better at recognising and measuring damage. This is off for every organisation until an admin turns it on, and an admin can turn it off again at any time. What follows is exactly what it involves.
Your control. Model improvement is off by default for every organisation. Only an admin in your organisation can turn it on, under Settings → Model improvement, and only an admin can turn it off. While it is off, none of your organisation’s data is read for this purpose.
What we use while it is on. The damage photos your team has already captured as claim evidence, together with the label information the workflow produces about them: where damage was marked in the photo, the damage type your assessor confirmed, and the extent or quantity they measured. We also use records of photos your team reviewed and marked as showing no damage, because those teach the models what not to flag. We do not use policyholder names or contact details, claim or policy references, correspondence or financial data for this purpose.
What we use it for. Training and evaluating Structa’s own damage-recognition and measurement models — nothing else. We do not sell or rent this data, we do not use it for advertising, and access is limited to the people building and testing those models.
We pool it — only across organisations that have opted in. Data from organisations that have turned model improvement on may be combined into a single training set. Data from an organisation that has not turned it on is never included.
Turning it off — plainly. Turning it off stops your organisation’s data being included in any future training set. It does not undo training that has already happened: a model already built using your data stays as it is, and we do not retrain earlier models to remove a contribution. We keep a record of which organisations’ data each model version was trained on.
Photos of homes. The label information is about the damage and the property, not about a person. But damage photos are taken in and around real homes, so they can incidentally show personal belongings, the inside of someone’s home, and anyone who happens to be in frame. We treat them as personal information for that reason, under the same access controls as the rest of your claim evidence.
Deletion. If your organisation leaves Structa and we delete its data, that data is gone from all future training sets as well — the same deletion described under “Retention & deletion” below. Models already trained are covered by the paragraph above.
We use AI to assist people, not to replace their judgement. To be clear about how automated processing is involved in decisions that affect a policyholder:
This section is provided now in anticipation of the automated-decision transparency requirements added by the Privacy and Other Legislation Amendment Act 2024, which commence on 10 December 2026.
To understand how the platform is used and to improve it, the application can emit first-party usage analytics — which pages and features are visited, and how often. The implemented event shape is operational telemetry, not content: route templates (for example /jobs/:id), opaque actor and organisation identifiers, timing, and status. Source controls and tests exclude request bodies, policyholder fields, photos, and message content from that event shape.
This section covers our public website — structatech.com.au and structatech.co.nz — rather than the Structa platform. You don’t need an account to visit it, and we don’t ask you to identify yourself.
Aggregate web analytics. The site uses Cloudflare Web Analytics, which does not use cookies and does not track people across sites. It reports aggregate figures only: page views, referrers, country, device and browser type, and page performance.
First-party usage events. The site also records, on Cloudflare infrastructure, coarse events about how pages are used — page and section views, time on page, how long each section stays on screen, clicks on calls to action, form starts and submissions, video plays, how far through a video is watched, and scroll depth. Each event carries the country and city-level location of the visitor, a coarse device class and browser family, the referring site’s hostname and, for a visit that arrived through a tracking link we sent or published, the name of the organisation or channel the link was issued for (a design-partner invitation, say, or our LinkedIn page). Where a link we publish carries a short campaign tag in its address, that tag is recorded too. IP addresses, full user-agent strings and email addresses are not stored in this data. We use it to understand interest in Structa and to improve the site, and it is retained in aggregate form for up to 90 days. We run no advertising or cross-site tracking scripts.
One first-party cookie. Every visit sets a single first-party cookie: a random identifier, kept for about 13 months, so we can tell how many different people are reading, what they came back to, and which of them arrived through the same link. If you open the site through a tracking link — one we sent to your organisation, or one we published, for example on our LinkedIn page — two more are set: one that keeps that link’s attribution for up to a week, and a marker lasting a few seconds that records whether a visit arrived through the link. They hold no name, email or other detail about you, they are never shared with anyone else or used for advertising, and they are not read by any third party. There are no other cookies.
Putting a name to that cookie. Two moments connect that random identifier to real details, and both are things you choose to do. The discovery form stores what you submit the way any enquiry does — and also records it against the random identifier, if your browser carries one. The demo library — the longer demo recordings — opens when you leave a work email, recorded the same way. That second part matters, so we say it plainly: from that moment the browser’s earlier activity on the site — the sections it read, the videos it watched — is no longer anonymous to us; it is linked to the details you gave us. Nothing else on the site asks for your details, and we use them only to respond and follow up.
Contact and waiting-list forms. The details you submit — name, work email, company, role and message — are stored by Structa on Cloudflare (Australian-region where available), go to our founders, and are also recorded in Structa’s customer relationship management system, Attio. Attio’s servers may be located outside Australia, so sending us a form involves disclosing those contact details to a service provider located outside Australia, which handles them under its own privacy terms. We use them only to respond to you and to manage the relationship. We do not sell them, and we do not use them for unrelated marketing.
We use a small number of vendors to operate the service. Some are configured to store your data in Australia; others process it overseas. The table lists each vendor, where it handles the data, and why — the cross-border disclosure contemplated by Australian Privacy Principle 8. It describes the functions and data flows currently implemented or configured; supplier contract and production evidence is tracked separately.
| Vendor | Where it handles data | Purpose |
|---|---|---|
| Amazon Web Services (Sydney) | Australia — Sydney and Melbourne; AWS Inc. (US) may access for support | Photo/document attachments and the operational log archive; AI inference (chat, agent reasoning and claim-photo vision); and address routing/travel-time on Structa's own servers |
| Microsoft Azure (Australia East) | Australia — Australia East, assessed to IRAP PROTECTED | AI inference — text embeddings for coverage grounding and speech-to-text transcription of voice notes, processed in-region |
| Neon (Postgres) | Australia — Sydney configured; Neon/Databricks (US) may access for support | Primary claim, quote, invoice, assessment, messaging, audit and session records, and the Australian-government (G-NAF) address data used for geocoding |
| Amazon SES (Sydney) | Australia — Sydney (send path, delivery metadata and bounce/complaint events) | Transactional and customer email delivery |
| Cloudflare | Global edge | In-flight encrypted request handling, DNS, TLS, and short-lived TTL-bound caches at the global edge; the systems of record stay in Sydney |
| Twilio | United States (predominantly; DPF/SCCs) | Triage SMS — phone numbers and message content, when your organisation enables it |
| Apple (APNs) | United States / global (Apple) | Push notification routing — opaque device tokens and minimal notification metadata only, never claim file content |
| Attio (CRM) | Outside Australia — Attio's own servers, under its own privacy terms | Website enquiry and waiting-list contact details only (name, work email, company, role and message), so we can respond and manage the relationship — never claim, policyholder or other platform data |
Australian residency covers the systems of record, file storage, all AI processing (AWS Bedrock Sydney/Melbourne and Microsoft Azure Australia East, including speech-to-text), address geocoding and travel routing, and transactional email (Amazon SES Sydney). The narrow offshore surface — Twilio SMS where enabled, Apple’s push service, Cloudflare’s global edge, and Attio for website enquiries — means phone numbers, device tokens, in-flight request data, or the contact details you send us through a website form may be handled outside Australia. Where AI processes text, identifiers are stripped first as a second layer, but we do not represent that AI inputs are de-identified. Customers requiring advance-change notice should include it in their contract.
Where you connect Structa to a third-party service under your own account — for example your own Xero organisation for accounts-receivable sync — that provider handles the data under your agreement with it, not as a Structa sub-processor.
Insurer platform connections. If your organisation asks us to connect Structa to an insurer claims platform you already work in (such as ENData or in4mo), Structa exchanges claim data with that platform on your behalf using access authorised for your claims — credentials you provide, or access the platform operator provisions for your organisation. Claim allocations, notes and documents we receive become your data in the Sydney systems of record, handled like anything you enter directly; we send back only what your configuration directs (vendor notes, status updates, documents and invoices for your own claims), and outbound writes stay off until you enable them. Connection credentials are stored encrypted in Sydney, and our bridge processing runs on Structa-operated infrastructure in Australia. The platform itself handles data under your (or your insurer’s) agreement with it, not as a Structa sub-processor. No connection exists until your organisation asks for one.
Your systems of record — claims, quotes, invoices, messages, attachments — are retained in the Sydney database and object storage for as long as your organisation uses Structa. Our default claim-record retention is the duration of your engagement plus seven years from job completion, or longer where required by law or your insurer contract. On a verified request, we return or delete your organisation’s data within 30 days using our whole-organisation deletion tool, and backup copies are purged within 90 days as those backups age out. We verify the requester’s authority and scope, agree the applicable deletion plan, and explain any data that must be retained. Automated per-claim disposal and production deletion attestations remain work in progress.
Data handled offshore is subject to each provider’s own retention window, which we do not control — for example, AI providers retain limited abuse-monitoring or trust-and-safety records for their own stated periods even though we do not train on your data. These windows are documented in our supplier assurance material and available on request. Automated per-claim disposal, production deletion attestations, and verified backup or object-version expiry remain work in progress. Some data may be retained where required by law, including financial records related to invoicing.
Under the Australian Privacy Act and the Australian Privacy Principles, you can:
Most of these requests are best handled by your Structa account admin (so they can update or remove the relevant data directly). If you can’t reach your admin, or your request relates to data we hold about you outside the platform, contact us at the address below.
If you think we’ve mishandled your personal information, tell us. Email privacy@structatech.com.au with the details. We acknowledge complaints within five business days, investigate, and aim to give you a written response within 30 days — if we need longer, we’ll tell you why and when to expect a reply.
If you’re not satisfied with our response, you can escalate to the Office of the Australian Information Commissioner (OAIC), the independent regulator for privacy in Australia — online at oaic.gov.au or by phone on 1300 363 992.
If a security incident is likely to result in serious harm to any individual, we’ll notify the affected customer(s) and the Office of the Australian Information Commissioner (OAIC) as required by the Notifiable Data Breaches scheme.
For privacy questions, data requests, or sub-processor change notifications, email us. We’ll respond within seven business days.
For anything else — including a question about our website or an enquiry you sent us through it — hello@structatech.com.au.