Privacy & Security

How SilVR Pathways protects your participants' data — by design, not as an afterthought.

Download Full Overview (PDF)

Trust at a Glance

Minimal PII by Design

Only first name and last initial stored

Database-Level Isolation

Engine-enforced organisation data separation

40+ Audited Action Types

Comprehensive operation logging

Australian Data Storage

All participant data stored in Australia

Data Obfuscation on Deletion

Aggressive obfuscation across all data points

Privacy Act 1988 Aligned

Designed for Australian compliance

Minimal Personal Information

SilVR Pathways collects only the bare minimum personal information needed to create personalised VR plans. We store a participant's first name and last initial — nothing more. No full surnames, no home addresses, no Medicare numbers, and no medical diagnoses ever enter our system.

Even in the unlikely event of a data breach, a record of “Margaret M. who enjoys gardening and classical music” cannot be meaningfully linked to a specific individual without external context.

Technical details — what we store and what we don't

What we store:

First name — Used to personalise the VR plan and address the participant during sessions.
Last initial — A single uppercase letter (e.g., “M.”) to distinguish participants with the same first name.
Preferences and interests — Hobbies, favourite destinations, cultural background used by our AI engine to recommend relevant VR content.
Content avoidances — Safety-critical information (e.g., fear of heights) used by our filtering system to exclude unsuitable content.

What we explicitly do not store:

Full surnames or family names
Residential addresses or room numbers
Medicare, health insurance, or government ID numbers
Medical diagnoses, medications, or clinical notes
Photographs or biometric data
Next-of-kin or emergency contact details

Organisation Data Isolation

Every organisation's data is completely isolated from every other organisation. This isolation is enforced at the database engine layer — meaning it is physically impossible for one organisation to access another organisation's participants, plans, or session data, regardless of any application-level errors.

The security boundary exists at the infrastructure layer, independent of application code. Even a coding error cannot leak data across organisations.

Technical details — how database-level isolation works

Our database uses row-level security policies — rules enforced by the database engine itself, not by application code. Every query is automatically scoped to the authenticated organisation's data.

An organisation can only read, create, update, or delete their own participants.
Session data, VR plans, and analytics are all scoped to the originating organisation.
Cross-organisation queries are rejected by the database engine before they execute.

This is a fundamentally stronger isolation model than application-level filtering, where a coding error could expose data.

Secure Authentication

SilVR Pathways uses secure authentication mechanisms to protect access at every level. All credentials are cryptographically hashed before storage — they are never stored in plain text. Failed login attempts are rate-limited to prevent brute-force attacks, and every authentication event is recorded in the audit trail.

Technical details — authentication mechanisms

Cryptographic credential hashing — All credentials hashed using bcrypt with a cost factor of 12 (~250ms per hash), making brute-force attacks computationally infeasible. Hashing is one-way.
Rate limiting — Failed authentication attempts trigger progressive delays and temporary blocking to prevent automated attacks.
Secure sessions — Session tokens stored in HTTP-only, secure cookies that cannot be accessed by client-side scripts.
Instant revocation — Administrators can instantly deactivate an organisation, immediately revoking all access.
Full audit trail — Every login attempt, session creation, and authentication event is logged with timestamps, IP addresses, and device information.

Content Safety Filters

Our AI-powered recommendation system places participant safety above all else. Hard safety filters override any AI recommendation, ensuring participants are never shown content that could cause distress.

The guiding principle is simple: safety over recommendations. Hard filters cannot be overridden by the AI or by staff.

Technical details — three-stage safety pipeline

Content recommendations pass through a three-stage pipeline:

Hard Filters (Safety-Critical) — The participant's avoidance profile is parsed into structured safety filters. Any content matching these avoidances is immediately excluded, regardless of AI scoring.
Preference Scoring — Remaining content is scored against the participant's interests with weighted categories.
AI Final Selection — Our AI engine makes the final selection, ensuring diversity and generating human-readable reasoning.

Avoidance keywords use negative-keyword detection — “not afraid of heights” is correctly parsed as no filter needed. Every plan records the number of items excluded by safety filters for audit purposes.

Cryptographic Security

SilVR Pathways uses industry-standard cryptographic algorithms to protect sensitive data at rest and in transit. Credentials are never stored in plain text, authentication tokens are encrypted, and data integrity is verified using cryptographic signatures.

Technical details — algorithms and standards

AES-256-GCM Encryption — Symmetric encryption providing both confidentiality and integrity verification. The 256-bit key length is approved for protecting classified information by the Australian Signals Directorate.
bcrypt Credential Hashing (12 rounds) — One-way hashing making brute-force attacks computationally infeasible (~250ms per hash).
SHA-256 Integrity Verification — Tamper detection for authentication tokens and data payloads.
Schema Validation — All data validated against strict schemas at the boundary, preventing injection attacks.
HTTPS/TLS — All data in transit encrypted. No unencrypted connections accepted.

Data Deletion & Obfuscation

When a participant is removed from SilVR Pathways, we aggressively obfuscate all personal information across every data point in the system. Names are replaced with placeholder text, all personal fields are cleared, AI-generated text is scrubbed of any identifying information, and stored PDF documents are permanently destroyed. Only the anonymised record shell and audit trail are retained for compliance.

Deletion is irreversible. All personally identifiable information is permanently removed across every data point. Only anonymised record shells and the audit trail are retained for regulatory compliance.

Technical details — the obfuscation protocol

Participant Record:

First name replaced with “Deleted”, last initial with “X” (resulting in “Deleted X.”)
All avoidance content cleared
Every personal data field (preferences, interests, cultural information, and all other flexible fields) set to null

AI-Generated Plans:

All occurrences of the participant's name replaced with generic placeholder text
Possessive forms similarly replaced
AI reasoning text scrubbed using case-insensitive matching to catch all variations

PDF Documents:

All stored PDF documents permanently destroyed (hard delete — irrecoverable)

What is retained (for compliance only):

Anonymised record shell (“Deleted X.” with no personal data) for referential integrity
Audit trail — record of actions taken, required for regulatory compliance
Aggregate statistical data containing no personally identifiable information

Archive vs Delete:

Archive — Record hidden from active views; all data preserved and restorable.
Delete — Full obfuscation protocol executed across all data points; irreversible.

Comprehensive Audit Trail

Every sensitive action in SilVR Pathways is automatically logged to a tamper-resistant audit trail. With over 40 tracked action types, the audit system captures who did what, when, and from where — providing full accountability for compliance and incident investigation.

Technical details — what is captured and action categories

Each audit entry captures:

Precise timestamp (UTC storage, AEST/AEDT display)
Action type (one of 40+ categorised types)
Resource type and ID
User identifier
Originating IP address (proxy-aware resolution)
Browser/device user agent

Action categories include:

Participant Operations

View, create, update, archive, delete, bulk operations, import

Plan Operations

View, generate, download PDF, export, feedback, batch generation

Authentication Events

Session Operations

Start, end, notes, view, export

Admin Operations

Organisation management, content sync, user management

Report & Subscriptions

Generate, download, manage subscriptions

The audit system is non-blocking — if a log write fails, the primary operation proceeds normally. Security through observability, without compromising availability.

Data Storage & Processing

All SilVR Pathways data — including participant information, VR plans, session records, and audit logs — is stored on Australian-hosted infrastructure. Some processing, such as AI-powered recommendations, may involve overseas services, but only minimal, non-identifying data is sent for processing.

Technical details — storage and processing locations

Database storage — All participant data stored in Australian data centres. Stored data never leaves Australia.
Application hosting — Australian infrastructure.
AI processing — Our AI engine, used to generate personalised VR plans, may process data on infrastructure located outside Australia. However, only minimal information is sent: first name, last initial, and lifestyle preferences. No full names, addresses, medical data, or other sensitive information is ever sent to external services.
Content delivery — VR content metadata served from Australian infrastructure. VR content files are managed on the organisation's headset devices.

Regulatory Alignment

SilVR Pathways is designed to support compliance with the Australian Privacy Act 1988, the Australian Privacy Principles (APPs), and the Aged Care Quality Standards. While compliance is ultimately the responsibility of each provider, our platform's architecture makes meeting these requirements straightforward.

Technical details — APP mapping and Aged Care Quality Standards

Australian Privacy Act 1988 & APPs:

Principle	How SilVR Pathways Supports It
APP 1 — Open & transparent management	This document, clear data practices, audit trail
APP 3 — Collection of solicited personal information	Minimal PII collection — only what's necessary for VR personalisation
APP 6 — Use or disclosure	Data used solely for VR plan generation; organisation isolation prevents cross-disclosure
APP 8 — Cross-border disclosure	Data stored in Australia; only minimal, non-identifying data may be processed overseas for AI recommendations
APP 11 — Security	AES-256-GCM encryption, bcrypt hashing, database-level isolation, audit trail
APP 12 — Access to personal information	Staff can view all participant data; plans downloadable as PDFs
APP 13 — Correction	Participant profiles fully editable by authorised staff

Aged Care Quality Standard 8 — Organisational Governance:

Information governance — Comprehensive audit trail evidences responsible data handling
Risk management — Safety-first content filtering protects participants
Privacy protection — Minimal PII and database-level isolation
Continuous improvement — Session feedback and analytics support evidence-based quality improvement

For more information about our privacy and security practices, contact us at hello@silvradventures.com.au