Privacy & Data Protection Framework
This document is the central privacy reference for RABS. It defines the data protection principles, classification rules, and handling requirements that apply across all subsystems. Individual systems (location tracking, facial recognition, email, etc.) have their own implementation details in their respective docs -- this document ties them together under a single governance framework.
1. Governing Legislation
RABS operates under Australian law. The key instruments are:
| Legislation | Relevance |
|---|---|
| Privacy Act 1988 (Cth) | Primary federal privacy law; establishes the APPs |
| Australian Privacy Principles (APPs) | 13 principles governing collection, use, disclosure, storage, and access |
| NDIS Practice Standards | Additional obligations for disability service providers |
| Surveillance Devices Act (WA) | Governs CCTV and recording at WA premises |
| Disability Services Act 1993 (WA) | State-level protections for participants |
Key Principle
Collect the minimum data necessary, hold it for the shortest time possible, restrict access to the fewest people required, and delete it as soon as the purpose is fulfilled.
2. Data Classification
All data in RABS falls into one of four sensitivity levels:
| Level | Label | Description | Examples |
|---|---|---|---|
| 1 | Public | No access control required | Company name, office address, public announcements |
| 2 | Internal | Requires authentication | Staff rosters, meeting notes, general Discord messages |
| 3 | Confidential | Requires authentication + role restriction | HR records, performance reviews, incident reports, payroll |
| 4 | Sensitive / Biometric | Requires explicit consent + strict access + audit trail | Face embeddings, location GPS trails, health information, participant records |
Classification Rules
- Default to the highest applicable level. If unsure, classify as Confidential.
- Biometric data is always Level 4. Face embeddings, voiceprints, fingerprints -- regardless of how they are stored or processed.
- Aggregated/anonymised data drops one level. A headcount derived from facial recognition is Level 2 (Internal), not Level 4, because no individual is identifiable.
- Derived data inherits the source level. A report generated from participant records remains Level 3 (Confidential).
3. The Anonymisation Hierarchy
When designing features that process personal data, always start from the top of this hierarchy and only move down when the higher level genuinely cannot satisfy the requirement:
| Priority | Approach | Example |
|---|---|---|
| 1 (best) | Don't collect at all | If you don't need location, don't request it |
| 2 | Count only | "4 people arrived at HQ" instead of naming them |
| 3 | Type only | "A staff member entered" instead of identifying who |
| 4 | Pseudonymised | Internal ID reference without name displayed |
| 5 | Identified | "Brett arrived at HQ at 9:15" -- only when operationally required |
This hierarchy applies across all subsystems:
- Safe Arrival (CCTV): Default to headcount. Resolve to identity only for evacuation checklists or explicit management request.
- Location tracking: GPS trails are Level 4 during collection but can be aggregated to Level 2 heatmaps after retention period.
- Gallery tagging: Face tags are Level 4 but a photo with faces blurred/untagged drops to Level 2.
- Email analysis: Sender metadata is Level 2; email body content with personal information is Level 3.
4. Consent Requirements
What Requires Explicit Consent
| Data Type | Consent Required | Who Consents | How |
|---|---|---|---|
| Biometric (face embeddings) | Yes -- written/recorded | Staff: themselves. Participants: self or guardian | Opt-in form before adding to bookface library |
| GPS location tracking | Yes -- at employment/enrolment | Staff: employment agreement. Participants: via trackers with guardian consent | System enforces via login challenge |
| CCTV recording | Implied by signage + policy | All persons on premises | Visible signage at all camera locations |
| Email content analysis | Yes -- at account setup | Staff: mailbox owner | Acknowledged during email account configuration |
| Discord message capture | Implied by server membership | Staff: Discord server rules | Knowledge base sync and media grabber documented in onboarding |
Right to Withdraw
- Any person can request removal from the bookface library at any time. Deleting their folder removes all reference embeddings immediately.
- Staff can request GPS tracking pause (with management approval and operational constraints).
- Participants (or guardians) can request exclusion from facial recognition -- the system will detect but never match their face.
5. Data Handling by Subsystem
Location Tracking
Full doc: Location Data
| Aspect | Rule |
|---|---|
| Collection trigger | GPS: during rostered shifts (support staff) or while logged in (admin/manager) |
| Storage | geo_events table with lat/lng/timestamp |
| Retention | Detailed trails: 30-90 days. Then aggregate to daily summary. |
| Access | Excursion staff and managers only |
| Deletion | Automatic after retention period via scheduled job |
Facial Recognition (Bookface)
Full doc: Bookface -- Facial Recognition & Safe Arrival
| Aspect | Rule |
|---|---|
| Processing | Entirely local -- GPU on server, no cloud APIs, no data leaves the LAN |
| Reference photos | Stored in bookface folders on NAS. Deletable on request. |
| Embeddings | Stored in metadata JSONB. Cannot be reversed to images. |
| CCTV frames | Deleted immediately after processing. Never retained. |
| Match results | Stored as person_id reference only. No face crops saved. |
| Access | Management only for identified results. Headcounts available to team leaders. |
Discord Media Capture
Full doc: Gallery & Media System
| Aspect | Rule |
|---|---|
| Scope | All non-private, non-excluded Discord channels |
| Private channels | hr-confidential, incident-reports, performance-reviews, disciplinary, complaints, payroll -- never captured |
| Storage | Photos and videos on NAS, metadata in media.discord_media |
| Retention | Indefinite (media is an organisational asset) |
| Access | Authenticated users only via admin dashboard |
Email
Full doc: Admin Email Integration
| Aspect | Rule |
|---|---|
| Storage | Email bodies cached locally. Attachments fetched on demand, expire after 7 days. |
| AI analysis | Reggie analyses emails for routing and context. Content never sent to external services without the mailbox owner's knowledge. |
| Access | Mailbox owner + explicitly shared users only |
| Secrets | IMAP/SMTP credentials encrypted at rest. Never logged. |
6. Data Retention Schedule
| Data Type | Active Retention | Archive | Permanent Delete |
|---|---|---|---|
| GPS location trails | 30-90 days | Aggregated daily summary kept 2 years | Raw trails purged after 90 days |
| CCTV frames | 0 (immediate delete after processing) | N/A | Immediate |
| Face embeddings (gallery) | While photo exists | N/A | Deleted with photo or on request |
| Face embeddings (bookface reference) | While person is active | N/A | Deleted when person leaves org or withdraws consent |
| Safe Arrival logs | 12 months | Aggregated attendance stats kept indefinitely | Individual records purged after 12 months |
| Discord media files | Indefinite | N/A | Manual deletion only |
| Email cache | 7 days (attachments), indefinite (metadata) | N/A | Attachment cache auto-purges |
| HR records | Duration of employment + 7 years | Archived after separation | Purged after statutory period |
| Audit logs | 2 years | Compressed archive | Purged after 2 years |
7. Access Control Matrix
| Data | Admin | Exec | Senior Mgmt | Management | Team Leader | Support Staff | Participant |
|---|---|---|---|---|---|---|---|
| Own GPS location | Yes | Yes | Yes | Yes | Yes | Yes (during shift) | N/A |
| Others' GPS location | Yes | Yes | Yes | Excursion only | Excursion only | No | No |
| Gallery (all photos) | Yes | Yes | Yes | Yes | View only | View only | No |
| Gallery (face tags) | Yes | Yes | Yes | Yes | No | No | No |
| Safe Arrival (names) | Yes | Yes | Yes | Yes | No | No | No |
| Safe Arrival (counts) | Yes | Yes | Yes | Yes | Yes | No | No |
| Super heart voting | Configured per user in app settings | ||||||
| HR records | Yes | Yes | Yes | Own team | No | Own only | No |
| Email content | Mailbox owner + shared access list | ||||||
| Audit logs | Yes | Yes | No | No | No | No | No |
8. Technical Safeguards
At Rest
- Database: PostgreSQL with role-based access. Sensitive columns in dedicated schemas (
media,hr). - Files: NAS with SMB authentication. No anonymous access.
- Backups: Encrypted. Retention follows the same schedule as source data.
In Transit
- All API traffic over HTTPS (TLS 1.2+).
- Internal LAN traffic between server and NAS is within a private network segment.
- No biometric data ever transmitted to external services.
In Processing
- Facial recognition runs on local GPU. No cloud inference.
- CCTV frames exist in memory only during processing, never written to disk.
- Email AI analysis uses configured LLM providers with data processing agreements in place.
Logging & Audit
- All access to Level 3+ data should be logged (who accessed what, when).
- Failed access attempts logged with IP and user ID.
- Logs themselves are Level 2 (Internal) and follow 2-year retention.
9. Incident Response
If a data breach or privacy incident is suspected:
- Contain -- isolate the affected system/account immediately.
- Assess -- determine what data was exposed, to whom, and for how long.
- Notify -- if the breach involves personal information and is likely to cause serious harm, notify the OAIC (Office of the Australian Information Commissioner) within 30 days and affected individuals as soon as practicable.
- Remediate -- fix the vulnerability, revoke compromised credentials, and update access controls.
- Document -- record the incident, response actions, and lessons learned in the audit log.
Biometric-Specific Response
If face embeddings or reference photos are compromised:
- Immediately regenerate all affected embeddings from source photos (embeddings are deterministic, so new model version = new embeddings).
- If source photos were compromised, notify affected individuals and offer removal from the bookface library.
- Face embeddings alone cannot reconstruct a face image, but combined with other data they could aid identification -- treat as Level 4 breach.
10. Privacy Impact Assessments
A Privacy Impact Assessment (PIA) must be conducted before deploying any new feature that:
- Collects new categories of personal information
- Introduces biometric processing
- Changes how existing personal data is used or shared
- Integrates with a new third-party service that receives personal data
Completed/Required PIAs
| Feature | PIA Status | Notes |
|---|---|---|
| Location tracking (GPS) | Required before production | Covered in location data doc |
| Bookface facial recognition | Required before Phase 3 | Covered in bookface doc |
| Safe Arrival (CCTV) | Required before Phase 3B | Extends bookface PIA |
| Discord media capture | Low risk (public channel content) | Informal review sufficient |
| Email AI analysis | Required | Depends on LLM provider DPA |
| TOKENWATCH (API monitoring) | Not required (no personal data) | Operational data only |
11. Related Documents
- Location Data -- GPS tracking policy, collection rules, enforcement, and database schema
- Gallery & Media System -- Discord media capture, heart voting, gallery UI
- Bookface -- Facial Recognition & Safe Arrival -- Face recognition models, CCTV integration, Safe Arrival system
- CCTV Implementation -- Camera infrastructure and streaming
- Admin Email Integration -- Email handling and AI analysis