# Onboarding PDF — Privacy & Legal Analysis **Prepared:** 2026-02-21 12:45 AEDT **Author:** Harper (Finance/Legal) **Request:** Rivet (from Michael) — branded onboarding PDF, privacy implications **Status:** COMPLETE — Sent to Rivet --- ## 1. The Concept Worker enters sensitive info into RateRight → system generates a branded PDF → PDF saves to WORKER'S phone → RateRight does NOT store the data. **Data involved:** - Bank details (BSB, account number) - Next of kin (name, contact) - Superannuation fund & member number - White card number - Tickets/licences (e.g., EWP, rigging, dogman) - Driver's licence **This is highly sensitive personal information.** Bank details, super numbers, and next of kin are the kind of data that, if breached, causes real harm (identity theft, financial fraud). --- ## 2. The Big Question: Does RateRight "Collect" This Data? ### Privacy Act Definition of "Collect" Per OAIC (APP 3, s6(1)): An entity **"collects"** personal information **"only if the entity collects the personal information for inclusion in a record or generally available publication."** "Collect" includes gathering, acquiring, or obtaining personal information from any source and by any means. In practice, **all personal information held by an entity is generally treated as information collected by the entity.** ### The Critical Architecture Decision **Option A: Server-Side PDF Generation (data touches RateRight servers)** - Worker enters data → sent to RateRight server → server generates PDF → PDF sent to worker → server deletes data - **PROBLEM:** RateRight HAS collected the data. Even if deleted immediately, it was "gathered" and "acquired" for inclusion in a record (the PDF). The Privacy Act obligations apply IN FULL during the entire processing window. - This is still "collection" under APP 3, even if transient. - If the server is breached during processing, it's a data breach involving bank details and super numbers. **Option B: Client-Side PDF Generation (data NEVER leaves the phone) ← STRONGLY RECOMMENDED** - Worker enters data into a form in their browser/app - JavaScript generates the PDF entirely on the device (using jsPDF, pdf-lib, or similar) - Data never leaves the worker's phone — no server request, no API call - PDF saves directly to the device - **RateRight never "collects" the data** because it never receives, acquires, or gathers it - RateRight provides the TOOL (the form + PDF template), not the DATA PROCESSING **Option B is the correct approach.** It eliminates almost all privacy risk. --- ## 3. Privacy Act Position — Small Business Exemption RateRight has <$3M annual turnover → **small business exemption applies** (s 6D Privacy Act). **BUT** there's an exception that would REMOVE the exemption: if RateRight **"trades in personal information"** — i.e., collects or discloses personal information for a benefit, service, or advantage. ### Does RateRight trade in personal information? - RateRight collects worker profiles (name, skills, location, white card) to match with contractors - A contractor pays $50 → receives worker contact details → that's disclosure of personal information for a benefit (the $50 fee) - **This likely constitutes "trading in personal information"** under the OAIC definition - Therefore RateRight is **probably NOT exempt** from the Privacy Act despite being under $3M turnover ### What this means: RateRight should operate AS IF the Privacy Act applies in full. The small business exemption is unreliable for a marketplace that shares worker details with paying contractors. This makes the client-side PDF approach even more important — don't create additional collection points for sensitive data. --- ## 4. Data Handling Obligations (Even If We Don't Store) ### If Server-Side (Option A — NOT recommended): Even during transient processing, RateRight would need to comply with: | APP | Obligation | What It Means | |-----|-----------|---------------| | APP 1 | Open & transparent management | Privacy policy must cover this data handling | | APP 3 | Collection only if reasonably necessary | Must justify collecting bank/super details — is it our function? | | APP 5 | Notification at collection | Must tell worker what data is collected, why, who it's disclosed to | | APP 6 | Use/disclosure limitations | Can only use for the stated purpose (PDF generation) | | APP 8 | Cross-border disclosure | If any server is overseas, additional obligations | | APP 11 | Security of personal information | Must protect data during processing — encryption, access controls | | APP 13 | Correction rights | Individual can request correction | **Notifiable Data Breaches scheme:** If RateRight is an APP entity (see trading analysis above), any breach of this data during processing must be reported to OAIC within 30 days if it could cause serious harm. Bank details + super numbers = serious harm threshold easily met. ### If Client-Side (Option B — RECOMMENDED): | Obligation | Status | Why | |-----------|--------|-----| | Privacy Act collection rules | **Does not apply** | Data never reaches RateRight | | Notifiable Data Breach | **Does not apply** | No data to breach on our end | | APP 11 security | **Does not apply** | We don't hold the data | | Privacy policy update | **Still needed** | Must explain the tool exists and how it works | | Disclaimer | **Needed** | Must clarify data stays on device | --- ## 5. Legal Issues to Address ### 5.1 Even Client-Side Has Legal Considerations **a) The form itself is RateRight's product.** If the PDF template has errors (wrong field labels, missing fields that cause worker to omit critical safety info), there's potential liability. Not privacy liability — product liability / negligence. **b) RateRight branding on the PDF.** This creates an implied endorsement. If a worker hands a RateRight-branded PDF to a dodgy contractor and something goes wrong, RateRight's name is on the document. Need a clear disclaimer ON THE PDF itself. **c) Worker reliance.** Workers may rely on the PDF as their "official" onboarding document. If it's incomplete or doesn't meet a specific contractor's requirements, RateRight shouldn't be liable for that gap. **d) Accuracy of information.** RateRight can't verify the data (white card number, licence validity). The PDF should state the information is self-reported and unverified. ### 5.2 What About the White Card / Licence Numbers? These are government-issued identifiers. No additional licensing is needed to include them in a self-generated PDF. The worker owns this information and can share it however they choose. RateRight is just providing a convenient format. ### 5.3 Next of Kin — Special Consideration Next of kin details involve a THIRD PARTY's personal information (the nominated person). Under APP 3.6, personal information should generally be collected directly from the individual it's about. However: - This is standard practice in employment/construction onboarding - The worker is providing it voluntarily for their own safety - If client-side, RateRight never "collects" it anyway - **Recommended:** Add a note on the PDF: "By providing next of kin details, you confirm you have their consent to share this information for emergency contact purposes." --- ## 6. Required Disclaimers ### On the PDF Generation Page (in-app/web): > **Privacy Notice — Onboarding PDF Generator** > > This tool generates a personal onboarding document on your device. Your information is processed entirely on your phone/browser and is **never sent to or stored on RateRight's servers.** > > RateRight does not collect, store, or have access to the information you enter into this form. The generated PDF is saved only to your device. > > You are responsible for the accuracy of the information you provide and for sharing the PDF only with parties you trust. RateRight does not verify the information contained in this document. ### On the PDF Itself (footer/header): > **IMPORTANT:** This document was generated using the RateRight Onboarding Tool. The information contained herein is self-reported by the worker and has not been independently verified by RateRight Pty Ltd (ABN 62 841 523 907). RateRight does not store this information and accepts no liability for its accuracy or completeness. This document does not constitute an employment contract or guarantee of engagement. ### Next of Kin Consent Line (on the form): > By entering next of kin details, you confirm you have obtained their consent to share their contact information for emergency purposes. --- ## 7. Recommendations Summary | Decision | Recommendation | Risk if Ignored | |----------|---------------|-----------------| | **Architecture** | CLIENT-SIDE ONLY — data never touches our servers | Full Privacy Act obligations, NDB risk, breach exposure | | **Privacy policy update** | Add section explaining the PDF tool | OAIC transparency requirement (APP 1) | | **Disclaimer on PDF** | Self-reported, unverified, no employment guarantee | Implied endorsement liability | | **Disclaimer on form page** | Data stays on device, not stored by RateRight | User confusion about data handling | | **Next of kin consent** | Worker confirms third-party consent | APP 3.6 third-party collection issue | | **PDF branding** | Keep it — great for brand awareness — but include the disclaimer | Liability without disclaimer | | **Field validation** | Don't validate bank/super numbers server-side | Server-side validation = data touching servers = collection | | **Analytics** | Do NOT log which fields workers fill in | Metadata about sensitive data is still sensitive | --- ## 8. Technical Notes for Builder If this goes to Builder for implementation: 1. **Use jsPDF, pdf-lib, or pdfmake** — pure client-side JavaScript PDF generation 2. **No API calls** during PDF creation — form data must never leave the browser/app 3. **No analytics/logging** of form field contents or completion patterns 4. **CSP headers** should prevent form data from being sent to any external endpoint 5. **No autosave/draft** functionality that might cache data to a server 6. **Service worker:** Be careful — service workers could cache form data. Disable caching for this page. 7. **If using a webview in a native app:** Ensure no server-side rendering of the form data --- ## 9. Competitive Angle This is actually a **brilliant feature** for differentiation: - Construction workers hate filling out the same onboarding paperwork for every new job - A portable, branded, professional PDF they carry on their phone = massive time saver - "Fill it once, use it everywhere" is a genuine value proposition - It builds RateRight brand loyalty with workers (the free side of the marketplace) - Privacy-first approach ("we never see your bank details") builds trust Worth flagging to Herald as a marketing angle: "Your details stay on YOUR phone." --- ## 10. Bottom Line for Michael **Great idea. One critical rule: build it CLIENT-SIDE ONLY.** If the data never touches our servers, we dodge almost every privacy obligation. If it does touch our servers — even for a millisecond — we're into Privacy Act territory with notification obligations, security requirements, and breach reporting risk. The branded PDF is smart marketing, genuinely useful for workers, and legally clean IF built correctly. Three disclaimers needed (form page, PDF footer, next of kin consent) — all straightforward. No blockers. Green light with the client-side architecture. --- *Sources: OAIC APP Guidelines (Ch 3, Ch B), Privacy Act 1988 s6(1) definition of "collect", OAIC trading in personal information guidance, Dundas Lawyers marketplace T&Cs guide*