OneForce Care is built and operated by Wondertree Studios Pty Ltd (ACN 699 886 498, ABN 82 699 886 498) of Level 10, 387 George Street, Sydney NSW 2000, Australia (“Wondertree”, “we”, “us”, “our”). The platform holds sensitive information about NDIS participants and support workers, so we describe our security practices honestly and specifically here rather than in vague marketing terms. This page works alongside our Privacy Policy and Data residency page.
We do not currently hold ISO 27001, SOC 2, or an equivalent third-party security certification. We are a small, growing team and our controls are commensurate with that stage. This page describes what is actually in place today, and we will keep it current as our controls mature.
Data hosting and isolation
Customer Data, including participant and worker records, is stored and processed in the Sydney, Australia (ap-southeast-2) region. See Data residency for more on where data lives.
Each provider organisation’s data is strictly isolated from every other organisation’s, and that isolation is enforced at multiple layers rather than relying on application code alone, so a request made in the context of one provider cannot read or write another provider’s records even if application logic were bypassed. This isolation is applied consistently across all the records the platform holds, including participant records, worker records, shifts and rosters, shift notes, incidents, documents, and payroll and invoicing data.
Authentication
Sign-in requires an email address and password. Passwords are never stored in plain text; they are kept only in salted, hashed form.
Multi-factor authentication (MFA) is supported using standard authenticator apps. Users can enrol an authenticator from their account settings, and enrolment and removal of an authenticator are recorded in the audit log described below.
MFA enforcement is configurable per role. A provider owner can require two-factor authentication for specific roles within their workspace, independently of other roles: owner, admin, and provider employee. When a role is required to use MFA and a member of that role has not enrolled, they are prompted to set up an authenticator before they can continue using the web application, and must re-authenticate and enrol before regaining access. Support workers, who use the Worker App rather than the web platform, have MFA enforced separately in the mobile app. Wondertree’s own platform-level staff accounts can similarly be required to use MFA to access the internal admin area.
Authorisation and access control
Once signed in, what a user can see and do is governed by role-based permissions, evaluated per screen and per action. Each provider workspace has a permission matrix covering areas such as participants, workers, scheduling, tasks, incidents, referrals, directory, documents, payroll, invoicing, payments, reports and settings, with independent read, create, edit and delete permissions for each area. A provider owner or admin configures which roles can perform which actions; support workers using the Worker App only ever see the shifts, tasks and records assigned to them.
These permissions are enforced in the application, and the data isolation described above is enforced independently at a lower layer, so access control does not rely on a single layer holding.
Encryption
Connections to the web platform and Worker App are served over HTTPS, and all traffic to and from the platform, including calls to our backend services, is encrypted in transit using TLS. Data at rest in our database and backups is encrypted by our infrastructure provider.
Handling third-party credentials (Xero and e-signing)
Where the platform integrates with a third-party service on your behalf, for example connecting a Xero organisation for invoicing and payroll export, or sending documents through our electronic-signature service, integration credentials are held server-side with tightly restricted access and are never available to browser sessions:
- The credentials for a connected integration are stored server-side; no browser session, including yours, can ever read them.
- The web application only ever reads a connection status (for example, that a Xero organisation is connected, and its name), never the credentials themselves.
- Where an integration uses tokens that expire, they are refreshed automatically ahead of expiry so a stale credential is never reused.
- Disconnecting an integration is available at any time from within the platform and revokes our ability to use the stored credentials.
Audit logging
The platform maintains an audit log of significant actions, recording the acting user, the provider workspace, the action taken, the affected record, and a timestamp. Logged events include, among others, sign-ins and MFA changes (enrolment and removal), password changes, changes to participant and worker records, shift and roster changes, incident report updates, and financial actions such as adjustments, invoice generation and export, and recorded payments. Audit records support accountability and help us and, where relevant, a provider investigate unexpected changes.
Backups
We take regular, automated backups of the database, stored within Australia, so that data can be recovered in the event of data loss or a technical failure. Backups are covered by the same access controls as the live database; they are not more widely accessible.
Keeping software current
We keep the platform’s dependencies and underlying infrastructure patched and up to date, and we monitor for known vulnerabilities in the libraries we rely on. Access and permission checks are reviewed when new features are added, so that new data is brought under the same isolation and access controls rather than being an exception.
Our people
Access to production data and infrastructure is limited to Wondertree personnel who need it to build, support or operate the platform, and is governed by confidentiality obligations. As our team grows, we will expand our internal access controls (such as formal access reviews and least-privilege tooling) to match.
Reporting a vulnerability
If you believe you have found a security vulnerability in the OneForce Care platform, website, or Worker App, please email hello@oneforce.com.au with:
- a description of the issue and the steps to reproduce it;
- the URL, endpoint, or screen affected; and
- any evidence (screenshots, requests, logs) that helps us understand and reproduce it.
Please act in good faith: do not access, modify or exfiltrate data that is not yours, do not run automated scanning tools that could degrade the Service for other users, and give us a reasonable opportunity to investigate and remediate an issue before any public disclosure. We do not currently operate a paid bug bounty program, but we will acknowledge your report, keep you informed of our progress, and credit you if you would like us to once a fix is in place.
If a data breach occurs
We maintain processes to detect, assess and respond to security and data incidents. Where an eligible data breach is likely to result in serious harm to an individual, we will notify affected individuals and the Office of the Australian Information Commissioner (OAIC) in accordance with the Notifiable Data Breaches scheme under the Privacy Act 1988 (Cth). Where the affected data is Customer Data held on behalf of a provider, we will also notify the relevant provider promptly so they can meet their own obligations, including any applicable NDIS Commission reporting requirements.
Contact
Security questions or a vulnerability to report? Email hello@oneforce.com.au.