Privacy Notice — [FILL: ONM Pty Ltd / registered trading name]

Effective: [FILL: ISO date — e.g. 2026-05-15] Version: 1.0 (DRAFT — pending lawyer review before publication) ABN: [FILL: ABN once registered] ACN: [FILL: ACN once registered] Registered office: [FILL: street address, suburb, state, postcode] Privacy contact: privacy@[FILL: domain] General contact: [FILL: support@domain or phone]

[LAWYER REVIEW] This notice is prepared by the engineering team as a structural draft mapped to the system's actual data flows. The legal phrasing in sections 3, 4, 6, and 8 must be reviewed by qualified Australian privacy counsel before publication. Replace every [FILL: ...] placeholder before going live. Do not publish while the version field still says "DRAFT".

1. Who we are

[FILL: ONM Pty Ltd], trading as Occupational Noise Manager ("ONM", "we", "us"), is an Australian company that provides a hearing-health management platform for Australian workplaces. We help employers and their occupational-health clinicians manage worker audiometric assessments, baseline (reference) audiograms, hearing-protection checks, and the supporting health-history information required to detect threshold shifts and meet workplace noise-management obligations.

This Privacy Notice explains how we collect, use, store, disclose, and protect personal information — including health information — collected through:

• the ONM dashboard used by your employer's authorised assessors and administrators;
• the ONM worker self-intake link (a short URL with a 4-character access code) used to capture your details before an in-person assessment;
• the worker assessment form used by the clinician at the time of your audiometric test; and
• direct correspondence with us at the contact addresses above.

ONM is bound by the Privacy Act 1988 (Cth) and the Australian Privacy Principles (APPs). This notice is given to you in fulfilment of APP 1 (open and transparent management of personal information) and APP 5 (notification of collection).

[LAWYER REVIEW] Confirm whether ONM's projected annual turnover requires APP coverage as an "APP entity", or whether coverage is via the health-service-provider carve-out in s 6D(4)(b) of the Act. The notice currently treats ONM as covered on both bases.

2. What information we collect

We collect two streams of information about workers: information your employer or treating clinician records about you in the dashboard, and information you provide directly through the worker self-intake link. The fields below match what the system actually stores.

(a) Information your employer or clinician records about you

Identifying and demographic information (workers table):

• Full name (full_name).
• Employee number (employee_number) — assigned by your employer, used to link assessments to the right worker within your employer's account.
• Date of birth (dob) — required for age-corrected threshold-shift calculations.
• Sex (sex) — required for audiometric reference-value comparisons (clinical standard).
• Site, department, and job title (site_id, department_id, department_job_id) — work-context fields used to scope reports and identify high-noise roles.

Health information collected at each assessment (assessments table and the linked assessment_answers records):

• Audiometric thresholds (left and right ear, at standard frequencies — audiometry_thresholds).
• Otoscopic examination findings (visual ear-canal / eardrum check by the assessor).
• Health-history responses (e.g. ear infections, ear surgery, exposure to ototoxic substances — health_history_answers).
• Tinnitus reported (tinnitus_reported).
• Recent noise exposure in the 16 hours before the test, and whether hearing protection was worn (recent_noise_exposure_16h).
• Hearing-protection inspection results — fit, comfort, condition, and assessor recommendations (hearing_protection_inspection).
• Equipment used for the test (audiometer model, serial, calibration date — captured as a snapshot in equipment_snapshot so the assessment can be defended even if the equipment record changes later).
• Assessment date, type (reference, monitoring, exit, etc.), result, referral disposition, and clinical notes.
• A signed consent record (consent_records) documenting the type of consent given (health assessment, data retention, etc.), the date given, and the consent template version in force at the time.

Reference (baseline) audiogram data (reference_audiograms table):

• Frequency-by-frequency thresholds for the worker's baseline.
• Source of the baseline (workplace baseline, prior employer, externally supplied audiologist record).
• Optional uploaded baseline document (e.g. a prior audiology report) stored in our reference-documents Storage bucket.
• Audiologist override flag and notes, where applicable.

Activity and audit information generated by use of the platform (worker_action_logs, assessment_comments, data_access_logs, session_audit_logs):

• Timestamps, user identifier, and action descriptions for changes made to your record.
• Who viewed which record and when (the audit log records access to support your APP 12 access-request rights and our APP 11 security obligations).
• Authentication events (login, logout, MFA enrolment, failed sign-in) for our authorised users — not for workers.

(b) Information you provide directly via the worker self-intake link

When your employer sends you a self-intake link (the /intake/<slug> page) with a 4-character access code, you may be asked to provide (worker_intake_submissions table):

• First name and last name.
• Date of birth.
• Sex.
• Personal email address (optional — used only if your employer has asked us to email you a copy of your assessment summary).
• Mobile number (optional — used for assessment-related contact only).
• Employee number (optional, if your employer wants you to confirm it).
• Site, department, and job-title selections (drawn from your employer's pre-defined list).
• Answers to the health-history questions configured by your employer's clinical template.
• A typed or drawn signature, captured as a PNG image attached to your consent record. Today this image is held inside our database alongside your consent record (column signature_png of worker_intake_submissions); we plan to migrate it to a dedicated, access-controlled file-storage bucket in our hosting region as part of the Phase K4 review-UI rollout. The migration does not change who can see the signature or how long we keep it; it improves operational hygiene by storing the binary outside the relational record.
• The version of the consent text you accepted, the time you accepted it, and the IP address and device user-agent of the device you submitted from (recorded for fraud-prevention purposes only, retained for 90 days, and never used for marketing or profiling — see section 5).

You will only see the intake form after entering a valid access code given to you by your employer or the on-site assessor. The access code does not, on its own, identify you to us.

[LAWYER REVIEW] Confirm whether the IP address captured at intake submission must itself be disclosed in this list under APP 5, given it is collected for security purposes and not used clinically. The current draft discloses it explicitly along with its 90-day retention window.

3. Why we collect it (purposes)

We collect personal information for the following purposes:

• Compliance with workplace hearing-health obligations. Your employer is required by Australian Work Health and Safety law to manage workers' exposure to noise and to keep records of audiometric testing where workers are frequently required to use personal hearing protection (see, in particular, Work Health and Safety Regulation 2011 (Cth) reg 58 and reg 50, and the equivalent state and territory provisions). ONM is the recordkeeping system used by your employer to meet those obligations. Reg 58 imposes a 30-year minimum retention period for audiometric test records.
• Threshold-shift detection. Comparing your current audiogram against your reference (baseline) audiogram is the clinical method for detecting work-related hearing change. Without dates of birth, sex, baseline thresholds, and noise-exposure context, we cannot run that comparison reliably.
• Health surveillance reporting to your employer. Your employer (through their authorised users) is given access to a defined subset of your data so they can act on referral recommendations, schedule retesting, and meet their reporting obligations. Your full clinical record is available to the treating clinician, not to general administrative users.
• Service operation and audit. We log who accesses your record and when so that we can respond to APP 12 access requests, investigate incidents, and meet our APP 11 security obligations.
• Aggregated, de-identified analytics for service improvement (for example, distribution of result categories across all of our customers). De-identified means the data cannot reasonably be re-associated with you or any other identifiable individual.

We do not use your information for advertising, marketing-list building, profile-selling, profile-renting, or training of third-party machine-learning models.

[LAWYER REVIEW] Confirm citations to WHS Regulation 2011 (Cth) reg 58 / reg 50 against the latest consolidated version, and confirm equivalent state references (Qld, NSW, Vic, etc.) for clients in those jurisdictions.

4. How we use and disclose your information

Disclosure inside the platform

• To your employer's authorised users (administrators and assessors named on your employer's ONM account): a scoped subset of your record sufficient for them to manage scheduling, referrals, and follow-up. Row-level security in the database prevents users from one employer accessing data belonging to another.
• To your treating clinician: the full record relevant to the assessment they are performing on you, including your prior reference audiogram, prior assessments, and health history.

Disclosure outside the platform

• Sub-processors that operate the underlying infrastructure on our behalf. The current list is maintained at docs/SUB_PROCESSORS.md and summarised here:
  • Supabase — database, authentication, file storage, and serverless functions, hosted in AWS Sydney (ap-southeast-2).
  • Cloudflare — static hosting and DNS for the dashboard and intake site. Cloudflare sees TLS-terminated request metadata only; no health information is stored at Cloudflare.
  • GitHub — source-code repository (no production data).
  • Xero — invoicing and bookkeeping (your employer's billing details only; no worker health data).
  • Google Workspace — business email and calendaring (no worker health data is stored or processed in Google Workspace).
• Regulators, courts, and law-enforcement bodies where we are required by law to do so (for example, in response to a valid subpoena, search warrant, or notice issued under the Privacy Act). We will challenge requests we consider overbroad or unlawful.
• Your nominated GP or specialist with your explicit consent (consent type DATA_SHARING_GP in our consent records). Disclosure does not occur without that consent.
• A potential acquirer of our business, under confidentiality obligations and only to the extent necessary for the transaction; if an acquisition completes, the acquirer takes on the same obligations under this notice unless and until you are notified of a change.

What we do not do

We do not disclose your information for marketing purposes (ours or anyone else's). We do not sell, rent, or lease personal information. We do not transfer health information outside Australia in the steady-state operation of the service (see section 5).

Cross-border disclosure (APP 8)

In the steady state, your personal information is stored and processed in Australia (Sydney) by Supabase. Where one of our sub-processors temporarily processes information outside Australia (for example, brief edge processing by Cloudflare for static-asset delivery, or business-systems metadata in Google Workspace), it is metadata only and does not include your health information. Should we ever need to enable cross-border processing of health information, we will update this notice and seek your consent before doing so.

[LAWYER REVIEW] Confirm whether the GitHub disclosure (source code only, no PHI) needs to be listed in this section at all under APP 5/APP 8, or whether listing it in docs/SUB_PROCESSORS.md alone is sufficient.

5. How we store and secure your information

• Data residency. Your worker, assessment, consent, audit, equipment, and intake records are stored in Supabase Postgres in Sydney (ap-southeast-2). Region verification is documented in docs/REGION_VERIFICATION.md.
• Encryption. All connections to the platform use TLS in transit. Data at rest is encrypted by the underlying cloud provider (AWS-managed keys via Supabase).
• Tenant isolation. Postgres row-level security policies enforce that each employer can only see its own workers, assessments, and audit logs. Policies are reviewed at every schema change.
• Access control. Authorised users authenticate with email and password; users in administrative and clinical roles are required to enrol in multi-factor authentication. Unused accounts are disabled. We follow least-privilege principles.
• Audit logging. Every access to a worker record and every authentication event is recorded in immutable audit logs. Site-administrators can produce an access report for any worker on request.
• Standards alignment. Our control set is aligned to ISO/IEC 27001:2022 Annex A. The current state of each control is tracked in our internal audit-finding tracker.
• Retention. We retain audiometric records for a minimum of 30 years, in line with WHS Regulation 2011 (Cth) reg 58. We retain access logs for a shorter period (currently 7 years) consistent with reasonable audit-trail retention under APP 11.2. After the retention period expires, records are de-identified or removed by the automated retention job (process_expired_records). Retention bases are recorded per row in the retention_basis column.
• Short-retention metadata. A small set of fields collected for fraud prevention and security review — specifically the submitter IP address and device user-agent captured when an intake form is submitted (worker_intake_submissions.submit_ip and submit_user_agent) — are retained for only 90 days under APP 11.2 (data minimisation). After that window the values are NULL'd by the automated job process_expired_intake_ips; the parent intake record itself remains for the 30-year clinical-retention period.

[LAWYER REVIEW] Confirm whether to publish the specific retention durations or to use a more conservative formulation ("for the period required by WHS legislation in your jurisdiction, currently 30 years"). Confirm separately whether the 90-day fraud-prevention window is documented at an appropriate level of detail for APP 5; it is also encoded in data_retention_policies keyed worker_intake_submission_ip.

6. Your rights (APP 12 and APP 13)

You have the following rights in relation to the personal information we hold about you. Most of these are exercised through your employer's nominated administrator, because they are the entity that engaged us to manage your records on their behalf; we will support your employer in fulfilling each request.

• Access (APP 12). You may request a copy of the personal information we hold about you. We will respond within a reasonable period (we aim for 30 days). There is no charge for a standard request; substantial requests may incur a reasonable cost-recovery fee, which we will tell you about before proceeding.
• Correction (APP 13). You may request correction of any inaccurate, out-of-date, incomplete, irrelevant, or misleading personal information. Demographic corrections (name, date of birth, contact details) are made directly. Clinical corrections are made by the treating clinician and recorded as an amendment, not a deletion, so the audit trail remains intact.
• Withdrawal of consent. You may withdraw your consent to ongoing collection. Withdrawal is recorded against your consent record (consent_records.status = 'WITHDRAWN') and triggers our retention-review workflow (withdraw_consent RPC). Note: withdrawing consent does not automatically delete records that we are required by law to retain (see section 5 — WHS reg 58 imposes a 30-year retention obligation regardless of consent state). Withdrawn records are flagged so they are not used for any new purpose.
• Anonymity and pseudonymity (APP 2). Where it is lawful and practicable, you may interact with us anonymously or under a pseudonym. In practice, the assessment service is not deliverable anonymously: we cannot link an audiometric test to a baseline, or comply with WHS recordkeeping, without identifying you.
• Complaints. If you believe we have mishandled your personal information, please contact us first at privacy@[FILL: domain]. If you are not satisfied with our response, you may lodge a complaint with the Office of the Australian Information Commissioner (OAIC) at https://www.oaic.gov.au or by phone on 1300 363 992.

To make a request under this section, email privacy@[FILL: domain] with enough information to identify you and the records in question (typically: full name, employer, and approximate date of any relevant assessment). We may need to verify your identity before acting on a request.

[LAWYER REVIEW] Confirm the access-request response timeframe (currently stated as "we aim for 30 days") against current OAIC guidance and against any commitments in docs/CLIENT_PILOT_AGREEMENT_TEMPLATE.md.

7. Sub-processors

Our current sub-processors, the data each one handles, and the hosting region for each are listed in docs/SUB_PROCESSORS.md. We update that document before adding a new sub-processor and we notify our customers (your employer) of material changes. Where a change to the sub-processor list materially affects what is in this notice, we will update this notice as well.

8. Data breaches (Notifiable Data Breaches scheme)

ONM is required by Part IIIC of the Privacy Act 1988 to assess data breaches and notify affected individuals and the OAIC where a breach is "likely to result in serious harm". Our internal response plan, including timelines and decision criteria, is documented in docs/NDB_PLAN.md. In summary:

• We aim to detect, contain, and assess any suspected breach within 72 hours of awareness.
• Where a breach is determined to be eligible for notification, we will notify the OAIC and affected individuals as soon as practicable, and in any event within 30 days of the awareness date.
• Notifications will describe what happened, what information was involved, what we have done, and what affected individuals can do to protect themselves.

[LAWYER REVIEW] Confirm the 72-hour internal-assessment target against operational reality once an incident-response runbook is in place; the statutory benchmark is "as soon as practicable", with a 30-day outer limit.

9. Changes to this notice

We will update this notice as our practices, our sub-processors, or the law evolves. When we publish a new version we will:

• increment the Version field above and update the Effective date;
• post a notice on the dashboard and on the intake landing page for at least 30 days; and
• where the change is material (for example, a new category of data collected, a new disclosure recipient, a change in country of storage), notify your employer's nominated administrator directly.

The current version is always available at [FILL: production /privacy URL once Week 6 SEC-1.8 ships the route] and at docs/PRIVACY_NOTICE.md in our published documentation.

10. How to contact us

Appendix A — APP cross-reference

This appendix maps each section of this notice to the Australian Privacy Principle it primarily addresses. It is provided for transparency and is not part of the binding notice itself.

Appendix B — Document control (internal — strip before publication)

• Source-of-truth path: docs/PRIVACY_NOTICE.md
• Master plan task: Week 5, SEC-1.7 (privacy notice rewrite); Week 6, SEC-1.8 (collection-notice review on intake page); Week 6 (publish at /privacy route).
• Related documents: docs/SUB_PROCESSORS.md, docs/REGION_VERIFICATION.md, docs/NDB_PLAN.md, docs/SECURITY_QUESTIONNAIRE_RESPONSE.md, docs/CLIENT_PILOT_AGREEMENT_TEMPLATE.md.
• Outstanding [FILL] placeholders: company legal name, ABN, ACN, registered office, privacy / security / support email addresses, effective date, production /privacy URL.
• Outstanding [LAWYER REVIEW] flags: sections 1, 2(b), 3, 4, 5, 6, 8 — see inline annotations.
• Pre-publication checklist:
  1. Replace every [FILL: ...] placeholder.
  2. Resolve every [LAWYER REVIEW] flag with counsel and remove the inline annotation.
  3. Set the Version field to 1.0 (drop the "DRAFT" qualifier).
  4. Set the Effective field to the publication date.
  5. Strip Appendix B before publishing the public-facing version.