Privacy Policy

01Who we are

Anchorlog Pty Ltd (ACN 698 324 006, ABN 32 698 324 006 — a proprietary company limited by shares registered in New South Wales, Australia, commenced 22 May 2026), referred to in this policy as "Anchorlog", "we", "us", or "our", operates the Anchorlog platform.

When you use our platform — whether you are a worker completing an induction or signing on to a site, a site administrator managing inductions, or a subcontracting company associated with a worker — we are the APP entity responsible under the Privacy Act 1988 (Cth) for the personal information we collect through the platform.

We act on the basis of our own purposes as described in §3 as well as to fulfil the agreements we have with our customers (the site operators).

Our customers may have their own privacy notices that apply to their own handling of your information outside our platform; this policy describes our handling.

Questions about what information is held about you, or how to access or correct it, can be directed to us at privacy@anchorlog.com.au, or to the site administrator who invited you, who we will cooperate with in responding.

We are an APP entity under the Privacy Act 1988 (Cth) and are bound by the Australian Privacy Principles (APPs). This policy explains how we manage personal information under APP 1.

02What personal information we collect

We collect personal information directly from workers (via induction, sign-on, sign-off), from site administrators (our customers who invite workers), and automatically from devices accessing the platform.

About your emergency contact.

When you complete an induction you may be asked to provide the name, phone number, and relationship of an emergency contact — for example, a spouse, a parent, or a trusted friend.

This is personal information about a third party that you are giving us, and we use it only for the purpose of reaching that person in an emergency during your attendance at a site.

We do not contact this person for any other purpose.

If your emergency contact becomes aware that we hold their information and wishes to access or correct it, or to have their information removed from your record, they can contact us using the details in §9 / §1.

We will verify their identity proportionately and take reasonable steps to respond.

Please consider letting the person you nominate know that you have provided their details, so they can make an informed decision about the nomination.

Where an operator's custom form collects categories beyond those listed, the operator's own privacy notices apply to that collection; we act in relation to that information as described in §1 (see Appendix A).

03Why we collect it

Primary purposes:

• Operate the induction, sign-on, sign-off flows — e.g. verify a worker has completed the required induction before signing on.
• Maintain a WHS record of who was on site, when, holding which credentials, under which induction.
• Provide site administrators with dashboards, reports, and exports to meet their WHS obligations.
• Contact workers with induction-completion confirmations, credential-expiry reminders, and operational messages.
• Contact site administrators about their account, subscription, and platform usage.
• Verify the identity of the person completing induction (photo ID check by the site operator).

Secondary purposes (permitted under APP 6):

• Platform improvement — aggregated usage-pattern analysis; de-identified or aggregated data preferred where practicable.
• Legal, regulatory, contractual obligations — lawful requests from a WHS regulator, a court, or an Anchorlog customer whose contract specifies audit support.
• Security-incident and suspected-misuse investigation.

We do not use personal information for marketing to workers. Marketing (if any) goes only to site administrators or operator contacts who have opted in.

04Who we share it with

We share your information with:

• Site operators and administrators — the people running induction, sign-on, and site safety at the sites you are inducted for.
• Subcontracting companies — the company you are working under on site, if you are engaged by a subcontractor.
• Australian WHS regulators — when required by law (for example, SafeWork NSW under the WHS Act 2011).
• Observability (error monitoring): when part of the platform fails on our servers, a report of that failure is sent to Sentry, our error-monitoring sub-processor, so we can fix it. Its collection of request contents, cookies, headers, IP addresses and user details is switched off.
• Sub-processors — the third-party service providers we use to operate the platform. The current sub-processor list (function, jurisdiction, contract basis) follows:

Translation of induction content. If you choose to read a site induction in a language other than English, the induction text written by your site operator — section headings, safety information and question labels — is sent to our translation sub-processor so it can be shown in your language. Your own answers are not sent, and neither is your name, your contact details, your photo, your signature or any document you upload. Translations are produced once per published version of an induction and reused, so the same text is not sent again for each worker. Machine translation is provided to help you understand; the English version remains the official one.

We do not sell your information and we do not use it for marketing.

05How we store it and where

Your personal information is stored on Supabase infrastructure in Sydney, Australia (AWS ap-southeast-2). Some of the services we use to run the platform are global services, and the limited information we share with each of them may be handled on infrastructure outside Australia. Every one of them is named in §4, so you can see who they are and what they do.

Certain secondary recipients listed in §4 (Stripe, Resend, Apple, Google, Vercel, Twilio, Microsoft, Sentry) are global services whose handling of the limited information we share with them may involve infrastructure outside Australia; we disclose them explicitly so you can make an informed decision. Induction-content translation is processed in Microsoft's Australian region (australiaeast), with the service's control plane in the United States — the same shape as the Twilio row in §4.

Sentry stores error reports in the United States; its account settings are held in the United States. PostHog is not in use.

Access inside Supabase is controlled by our Row-Level Security (RLS) model (§6).

06How we keep it secure

We take reasonable steps (APP 11.1) to protect personal information from misuse, interference, loss, and unauthorised access, modification, or disclosure.

What we do not claim.

We do not claim our records are cryptographically tamper-proof or that we can provide a mathematical proof of record integrity.

"Append-only" means the database rejects UPDATE and DELETE against the log table under normal operation.

Positive cryptographic integrity proofs (hash-chain or similar) are on our roadmap, not in place today.

Customers whose use case requires such a proof should contact us for current posture detail.

07How you can access or correct your information

Under the APPs you can request access (APP 12) and correction (APP 13) of the personal information we hold about you.

To make a request: email privacy@anchorlog.com.au.

How we respond.

Within a reasonable time (typically 30 days), we acknowledge, verify your identity proportionately to the sensitivity of the information, and then either (1) provide the information, (2) make the correction, or (3) explain in writing why we cannot and how to complain about that decision.

Who can ask. Workers, via the site administrator who invited them or directly to Anchorlog. Emergency contacts (see the emergency-contact note in §2).

Operational posture. At launch, requests are handled by our staff under a written internal procedure: one for access requests (APP 12) and one for correction requests (APP 13). Each procedure sets out how we verify who is asking, find the information we hold about you, and respond within the time above. A structured admin-initiated data-subject-export flow and a worker-facing correction flow are on our roadmap (planned at WS-PUB-05); we will update this section when they ship.

08How long we keep your information

We retain personal information only for as long as we need it for the purposes in §3, or as required by Australian law. APP 11.2 requires us to take reasonable steps to destroy or de-identify personal information once it is no longer needed.

Current retention posture per category:

• Induction records (completion evidence, SWMS acknowledgement, signature): retained while the worker has active induction status at any site operator using Anchorlog, plus 7 years after last active status — basis: supports customer WHS compliance obligations (F-002 §3 primary purpose), aligns with Fair Work s 535 floor for worker-employees, matches industry convergence (Safety Champion publishes 7 years; sector norm).
• Sign-on/sign-off records: retained while the site is active on Anchorlog, plus 7 years after site closure — basis: evidentiary pair with induction records (see above).
• Credential records (licences, tickets, qualifications): retained while worker has active induction; credentials supporting expired status are deleted within 3 months unless linked to an induction record still within its retention window.
• Identity-document images (photo ID: driver licence or passport, front and back): retained while the site (project) the induction belongs to is active on Anchorlog; deleted within 3 months after that site is archived — basis: identity verification is performed at induction and the verified fact remains in the induction record, so the image itself is not needed beyond a post-project buffer. (Enforcement prerequisites — a site archived_at timestamp and a purge job — are tracked in the engineering backlog; until they ship, enforcement follows the operational-runbook posture below. Counsel flag: see §5 Q4 on sites that are never archived.)
• Account records (builder administrators, subcontractor administrators): retained while account is active, plus 90 days after account closure (for standard account data); billing and contractual records retained for 7 years per Corporations Act s 286 / ITAA s 262A.
• Technical logs and audit_log records: retained per the integrity policy in §6 — append-only under normal operation.
• Marketing or communication records: retained while the communication relationship is active, plus 12 months after last contact (for contact records); opt-out markers retained indefinitely to comply with Spam Act 2003.

If a regulatory investigation or litigation is known to affect specific records, retention for those records pauses until the matter is resolved.

Retention enforcement is currently handled through operational runbooks. We are progressively adding code-enforced retention and will update this section as those controls ship.

We take reasonable steps to destroy or de-identify personal information once no longer needed, consistent with APP 11.2. Full retention detail is available on request.

09How to complain

If you believe we have breached the APPs or any registered APP code binding us, you can complain.

How.

Email privacy@anchorlog.com.au.

Please describe what happened, when, what personal information was involved, and the outcome you are seeking.

How we handle your complaint.

We acknowledge receipt within 7 days, investigate, and provide a written response within 30 days — or explain any delay with an updated timeframe.

If you are not satisfied with our response, you may refer the complaint to the Office of the Australian Information Commissioner (OAIC):

Alternative formats.

You can request this privacy policy in an alternative form (printable PDF, screen-reader-friendly version, etc.) by contacting us at the address above. This discharges APP 1.6.

10Updates to this policy

We update this policy when there is (a) a material change to how we collect, hold, use, or disclose personal information, (b) a change to our regulatory posture, or (c) an underlying platform architecture change that affects §§1–9.

On every update we change the "last updated" date at the top of the published policy and — where the change is material — add a row to the changelog in Appendix C.

"Last updated" convention (F-012 remediation).

The "last updated" date is set automatically to the date the change is deployed.

The content source-of-truth lives in this repository; a change to that source in a pull request becomes "last updated" on merge.

The previous policy carried a manually-maintained stamp that had drifted across releases — this convention prevents that drift.

Availability (APP 1.5 / APP 1.6).

The policy is available free of charge at /privacy, linked from the marketing footer and — after WS-EXT-C6 — from the worker-facing public footer (F-011).

Alternative formats are available on request (see §9).

Brand voice pass pending — legal substance is fixed.