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.

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).
• Sub-processors — the third-party service providers we use to operate the platform. The current sub-processor list (function, jurisdiction, contract basis) follows:

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). We do not disclose your personal information to overseas recipients for the purpose of running the platform itself.

Certain secondary recipients listed in §4 (Stripe, Resend, Apple, Vercel, Twilio) 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.

Observability sub-processors (Sentry, PostHog) are not active at pilot. If they are re-introduced post-launch, this section and §4 will be updated before that deployment ships (per the CLAUDE.md Compliance Drift Guard rule 4).

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 Appendix B).

Operational posture. At launch, requests go via a manual operational runbook. The runbook is internal-facing; access requests follow docs/source/runbook-dsar-manual.md (APP 12) and correction requests follow docs/source/runbook-correction-manual.md (APP 13). 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.