SafetyIQ Privacy & Retention Policy

This document is the authoritative reference for how SafetyIQ handles personal information under the Australian Privacy Act 1988 and the Australian Privacy Principles (APPs), the Notifiable Data Breaches (NDB) scheme (Privacy Act Part IIIC), and the Work Health and Safety Act 2011 record-keeping obligations.

The document is written for two audiences:

1. The customer's Privacy Officer or General Counsel reviewing SafetyIQ before purchase.
2. A regulator or auditor investigating an incident.

1. Controller / Processor Relationship

SafetyIQ is installed, operated, and controlled by the customer. SafetyIQ (the publisher) does not receive, see, process, or store any customer data unless the customer explicitly grants a Remote Support token (core/support.py) and voluntarily uploads a diagnostic report.

• Data controller: the customer organisation (the PCBU).
• Data processor: same — SafetyIQ runs on-premises.
• Third-party sub-processors: Cloudflare, Inc. — when the customer opts in to the mobile tunnel feature (Step 4 of the setup wizard or the "Mobile connection" tab in the admin console). Cloudflare operates the tunnel that carries traffic between worker phones and the customer's SafetyIQ desktop. See §12 below for exactly what Cloudflare can see and what it cannot. Other opt-in integrations (e.g. AI features, when enabled in future releases) are disclosed individually.

Because SafetyIQ does not ship data off-site, the customer retains full control of where the data lives (their own disk) and who can access it (their own RBAC + filesystem permissions).

2. Personal Information Collected

2.1 Workers / users

2.2 Record content

Safety records (Take 5, incidents, near misses, hazard observations, SWMS, etc.) are free-text plus structured fields filled in by workers. These may include:

• Names of other workers involved
• Injury descriptions, medical treatment, body parts
• Photos of incidents or hazards
• GPS coordinates of the submission
• Digital signatures
• Witness statements

2.3 Telemetry / audit

2.4 What is NOT collected

• Biometrics (fingerprints, face, voice recognition). Signatures are captured as PNG images, not biometric templates.
• Location history outside submissions. GPS is only recorded for specific fields in a record payload, never passively tracked.
• Third-party cookies — SafetyIQ is a self-contained application, not a website embedding ad networks.
• Children's data — the workforce management context means all users are expected to be adults in an employment relationship.

3. Lawful Basis for Collection (APP 3)

On first mobile launch, workers see an APP 5 notice explaining what is collected, why, and how to withdraw consent (revoke the relevant flag in their profile; HSEQ advisor action required for compliance reasons).

4. Retention Per Data Class

Defaults align with the longest applicable obligation. Customer may extend (never shorten below statutory minimum) via retention config.

Sitting alongside these is APP 11.2: once data is no longer needed for any purpose for which it was collected, it must be destroyed OR de-identified. Retention jobs (P4.2) implement this automatically — with an audited two-step soft-delete → grace-period → hard-delete flow so accidental deletion is recoverable.

5. Access, Correction, and DSAR (APP 12 + APP 13)

5.1 Access request procedure

A worker (or their representative) may request access to all personal information SafetyIQ holds about them. The HSEQ advisor or WHS Admin fulfils the request via:

Admin Console → Users → [worker] → Export my data (DSAR)

(Endpoint: GET /api/privacy/export-user/{user_id}, planned for P4.3.)

The endpoint returns a ZIP file containing every record where the worker appears as creator, assignee, witness, or signatory, plus their profile, sessions, training records, and audit log entries.

The organisation must respond within 30 days under APP 12.5.

5.2 Correction request procedure

A worker may request correction of their own profile fields (display_name, email, phone). For record content, correction flows through the existing record-update mechanism — records are versioned (not overwritten), preserving the original version in the hash chain.

5.3 Refusal

The organisation may refuse to act on an access or correction request on the narrow grounds listed in APP 12.3 / 13.3 (legal privilege, threat to safety, existing proceedings). Refusals must be in writing and explain the reason (APP 12.9).

6. Security Safeguards (APP 11)

See docs/security.md for the full summary. In brief:

• Passwords hashed with argon2id (~250 ms per hash).
• Sessions via HttpOnly cookies, 12h idle / 24h absolute timeout.
• Role-based access control, deny-by-default; docs/rbac-matrix.md.
• CSRF double-submit cookie, strict CSP, rate limiting, request-size caps.
• WAL-mode SQLite with daily signed chain-head exports and daily AES-256-GCM-encrypted backups.
• Audit log is append-only (SQLite triggers); records are hash-chained.
• Account lockout after 10 failed logins in 15 min.
• TLS in LAN mode with self-signed CA exportable for IT deployment.

7. Breach Notification (Part IIIC — NDB Scheme)

7.1 What is an eligible data breach

An eligible data breach occurs when:

1. There is unauthorised access to, or unauthorised disclosure of, or loss of, personal information held by SafetyIQ, AND
2. A reasonable person would conclude that the access, disclosure, or loss is likely to result in serious harm to any of the affected individuals.

Serious harm includes physical, psychological, emotional, financial, or reputational harm.

7.2 Response procedure

On suspicion of a breach:

Hour 0 — Contain. - WHS Admin revokes all active sessions (Admin Console → Sessions → Revoke all) and rotates the signing key only if compromise is confirmed (delete integrity_signing_key from schema_meta). - Disconnect the affected machine from the network if the attack appears to be in progress.

Hours 0–4 — Preserve evidence. - Take an immediate encrypted backup (Admin Console → Backup → Create backup with passphrase). Copy offsite. - Pull the audit log: GET /api/audit?since=... for the relevant window. - Re-verify all chains (Admin → Integrity → Re-verify all chains) to determine if records were tampered.

Hours 4–72 — Assess. - Identify what personal information was involved, who is affected, and whether serious harm is likely. - Privacy Officer documents findings.

By day 30 — Notify if eligible. - Notify the Office of the Australian Information Commissioner (OAIC) via their online form. - Notify affected individuals directly, describing the kinds of information involved, the circumstances of the breach, and recommended steps (password change, monitoring for misuse).

The obligation to notify sits with the customer organisation (the data controller), not SafetyIQ. SafetyIQ provides the tools to meet the obligation; it does not replace the obligation.

7.3 Exceptions

• If remedial action is taken quickly enough that serious harm is no longer likely, notification is not required (s 26WF).
• Certain law-enforcement and health situations have carve-outs (s 26WK onwards).

8. Data Subject Rights Outside Australia

For organisations with workers based outside Australia (e.g. NZ, Fiji projects), additional obligations may apply:

• NZ Privacy Act 2020 broadly aligns with APPs; NZ Privacy Commissioner notification threshold is "serious harm" (similar to NDB).
• GDPR applies only if the organisation is "offering goods or services" to EU data subjects — rare in the Australian construction segment. If applicable, the customer should layer additional controls (DPIA, DPA with SafetyIQ, DPO designation).
• US HIPAA is not applicable — SafetyIQ does not handle US-covered health information.

9. Cloudflare Tunnel — what's seen and what isn't

The mobile-tunnel feature uses a Cloudflare Tunnel to let workers' phones reach the customer's SafetyIQ desktop over the internet. Cloudflare is only invoked when the customer opts in (Step 4 of the setup wizard, or the Mobile Connection admin page). Turning the feature off tears the tunnel down and removes the DNS record.

What Cloudflare can see while the tunnel is active:

• The fact that a tunnel exists and the hostname it uses (e.g. sfty-7xq94f.tunnel.whsiq.com).
• Connection metadata — source IPs, TLS SNI, timestamps, approximate byte counts per request.
• The TLS-terminated traffic at the Cloudflare edge, for the duration of the request — Cloudflare transparently re-encrypts the request on the way to the SafetyIQ desktop.

What Cloudflare cannot see:

• The SafetyIQ SQLite database itself — it stays on the customer's desktop.
• Long-term plaintext traffic storage — Cloudflare does not retain request bodies by default, and SafetyIQ does not enable any Cloudflare feature that would change that (no Workers KV caching of customer data, no Cache API, no Stream).
• Any traffic when the customer has disabled the tunnel feature.

The SafetyIQ publisher operates the Cloudflare account that owns the tunnels but does not have any access to customer data flowing through them; the TLS keys between the worker's phone and the customer's SafetyIQ instance are end-to-end from the browser's perspective (Cloudflare's edge is the TLS terminator from the public side, with re-encrypted HTTPS to the customer's localhost).

To disable the feature entirely: Admin Console → Mobile connection → Disconnect tunnel. Cloudflare tunnel + DNS record are removed within seconds.

10. Contacts

11. Change Log for this Document