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, our Data Processing Addendum and our Data residency page, and it is the maintained version of the security summary in Annex B of the Addendum.
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. The last section says plainly what we do not have yet, because a security page that only lists strengths is not a security page.
Data hosting and isolation
Customer Data, including participant and worker records, documents and backups, is stored and processed in Sydney, Australia. See Data residency for where each part of the Service runs and for the short list of functions that involve sending limited data overseas.
Each provider organisation’s data is separated from every other organisation’s, and that separation is enforced at more than one layer rather than relying on application code alone. The platform is designed so that a request made in the context of one provider cannot read or write another provider’s records, even if a mistake were made in application logic. This isolation is applied consistently across the records the platform holds, including participant records, worker records, shifts and rosters, shift notes, incidents, tasks, documents, and payroll and invoicing data.
New tables and features are brought under the same isolation rules as part of building them, rather than being connected first and secured afterwards.
Authentication
Sign-in requires an email address and password. Passwords are never stored in plain text; they are kept only in salted, hashed form. Password reset and email change flows send a single-use link to the registered address, and a password change generates a security notification to the account holder.
Multi-factor authentication (MFA) is supported using standard authenticator apps that generate time-based one-time codes (TOTP). That is the only second factor we support today: we do not offer SMS codes, email codes, or hardware security keys. Users can enrol an authenticator from their account settings, and both enrolment and removal are recorded in the audit log described below.
MFA enforcement is configurable per role. A provider owner can require multi-factor authentication for specific roles in their workspace: owner, admin, provider employee, and support worker. The owner is the exception to the per-role switch: once enforcement is on for any role, the owner is required to use it too. 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, and must enrol before regaining access. The support worker setting is honoured by the Worker App, since support workers do not use the web platform. Changing an enforcement setting ends existing sessions for the affected users, so the new requirement takes effect immediately rather than at the next natural sign-out.
Wondertree’s own platform-level staff accounts, used to access the internal administration area, are subject to the same authenticator requirement where we enable it for our own team.
Sign-in and sign-out events are recorded with the account, the IP address the request came from, and a timestamp, so unusual activity can be reviewed. We do not record a device identifier and we do not resolve the IP address to a location. Sensitive actions such as sign-in, account creation and invitations are rate limited.
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. A change to an individual’s access level is recorded in the audit log. Changes to a role’s own permission matrix are not currently recorded there, and we say so rather than let it be assumed.
Each account is for one individual. Shared logins are prohibited by our Acceptable Use Policy, because they destroy the value of the audit trail for everyone, including the provider relying on it in an audit.
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, our document storage and our backups is encrypted by our infrastructure providers.
Documents are never served from a public URL. A download is authorised per request and issued as a short-lived, single-purpose link that expires within minutes, so a link that leaks after the fact does not become a permanent door.
Handling integration credentials
Where the platform integrates with a third-party service on your behalf, for example connecting a Xero organisation for invoicing and payroll export, 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.
Electronic signing
Documents sent for signature are handled by a signing workflow that runs on infrastructure we operate in Australia. Signing data, including the document content and the signatory’s name and email address, stays in Australia.
Each signing event is recorded in the platform’s audit log: that a document was sent for signature, how many signatories it went to, when it was completed, and whether the request was cancelled. Those entries are appended and cannot be edited through the application. When signing completes, the executed copy, carrying the signing certificate page produced by the signing workflow, is stored in your document register and emailed to each signatory, and the superseded draft is removed. Section 8 of our Terms of Service sets out the legal framing, including what we do and do not verify.
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. The acting user’s identity is resolved server-side from their profile rather than from anything the browser sends, so an audit entry cannot be attributed to someone else by a manipulated request. Applications in the browser cannot write to the audit log directly; entries are written server-side.
Logged events include MFA changes, password changes, changes to participant and worker records, consent and service-agreement events, document upload, download and deletion, signing events, shift and roster changes, changes to recorded clock times, travel review, task and incident updates, referral and directory changes, changes to an individual’s access level, report exports, and financial actions such as adjustments, invoice generation and export, claim preparation and recorded payments. Sign-in and sign-out history is kept separately, as described under Authentication above, and is not part of the audit log.
What the audit log does not do. For most actions it records which field changed, not a copy of its contents. It will tell you that a participant’s plan dates were edited, by whom, and when; it will not show you the previous dates. A small number of actions do carry values: some record the value the field was set to, and a few, such as an edited clock-in or clock-out time or a change of business name, record the value before and after. We would rather say that here than let a provider discover it during an investigation.
Providers can read the audit trail on a participant or worker record and on a shift assignment, and can export the audit trail to CSV from the reporting area. The export carries the time, the action, the record, the acting user and the affected record’s type and identifier; the per-action detail described above stays in the in-app view.
Backups and recovery
We take regular, automated backups of the database so data can be recovered after data loss or a technical failure, and the production database is covered by point-in-time recovery. Backups are held in Australia, in the same region as the live database, and are covered by the same access controls as live data; they are not more widely accessible. We will not move backups offshore without updating this page and following the subprocessor change process in our Data Processing Addendum.
Backups exist so we can operate the Service reliably. They are not a customer-facing archive and they are not a substitute for your own exports. Section 11 of the Terms of Service explains how to get your data out, and the Early Access Terms explain why you should do it regularly.
Deleting data
Deletion and archiving are different things, and the platform is explicit about which one it is doing.
- Archiving a participant or worker hides the record from everyday use while keeping the underlying history, because a provider usually still needs it for its own record-keeping.
- Deleting a document removes the stored file and its register entry together. A register entry never outlives the file it points at, and a stored file is never left behind after its entry is removed.
- Residual copies of deleted data in encrypted backups are purged within 35 days.
- Short-lived operational records are purged automatically on a rolling basis, including rate-limiting and invitation-throttling records after 7 days and the offline-queue ledger the Worker App uses after 90 days.
- Travel location trails recorded against a travel leg are cleared after 90 days, while the distance, time and route summary needed for billing are kept.
At the end of a subscription, the export window and deletion timeline in Section 20.4 of the Terms and clause 13 of the Data Processing Addendum apply.
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 becoming an exception.
Changes reach production through an automated pipeline that runs type checks, linting, contract tests and unit and component tests before anything is released. A change that fails the gate does not ship. Database changes are applied as versioned migrations, in the same order, to a test environment first and production second.
Our people
Access to production systems containing Customer Data is limited to Wondertree personnel and contractors who need it to build, support, secure or operate the platform. Access is granted on a need-to-know basis, is reviewed when a person’s role changes, and is removed promptly when their engagement ends.
Before we grant a person that access, they are bound by written confidentiality obligations that survive the end of their engagement, are briefed on their obligations and on the sensitivity of the information the platform holds, and complete background verification appropriate to their role, which for roles with standing access to participant records includes a national police check.
We are not an NDIS provider and do not deliver NDIS supports, so the NDIS Code of Conduct does not apply to us of its own force. We nevertheless require personnel with access to participant information to act consistently with its principles about privacy, dignity, respect and the prompt reporting of concerns. Where we engage a contractor or subprocessor, we remain responsible to the provider for their handling of Customer Data as if it were our own. Clause 6 of our Data Processing Addendum makes these commitments contractual.
Actions taken by our staff in the internal administration area are recorded in the audit log in the same way as a provider’s own actions.
Incident response
If something goes wrong, our order of work is: contain it, understand it, tell the people who need to know, then fix the cause.
We maintain processes to detect, assess and respond to security and data incidents, and we keep an internal record of each suspected or confirmed incident, our assessment, and the steps taken in response. Where we suspect an eligible data breach, we complete a reasonable and expeditious assessment within the 30 days section 26WH of the Privacy Act 1988 (Cth) allows, and usually much sooner.
Where the affected data is Customer Data held on behalf of a provider, we will notify that provider without undue delay and within 72 hours of confirming an eligible data breach affecting their data, tell them what we know even if the picture is incomplete, and give them what they reasonably need for their own Notifiable Data Breaches assessment and any NDIS Commission reporting. We will consult the provider before notifying their participants or workers, and will not notify those individuals unilaterally except where the law requires it or a delay would create a serious risk to someone’s safety.
Where an eligible data breach is likely to result in serious harm and we must notify in our own right, we will notify affected individuals and the Office of the Australian Information Commissioner (OAIC) in accordance with the Notifiable Data Breaches scheme. Section 24 of our Privacy Policy and clause 8 of our Data Processing Addendum set out the full commitment.
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. We will not pursue legal action against someone who reports a vulnerability to us in good faith and within these limits.
What we do not have yet
Being specific about the gaps is more useful to a provider than a page of reassurances.
- No third-party certification. We do not hold ISO 27001, SOC 2, or an equivalent.
- No independent penetration test. We have not commissioned one. We will publish that we have when we do.
- No paid bug bounty. Responsible disclosure only, as described above.
- No 24/7 on-call. Support and incident response run during Sydney business hours, with best efforts outside them. Section 15 of the Terms is the commitment.
- No uptime guarantee during early access. We do not offer a service level agreement while your account is in early access, and we say so rather than implying one.
- Access reviews are manual. As the team grows we will move to formal, scheduled access reviews and least-privilege tooling rather than the lightweight process a team of this size runs today.
Contact
Security questions, a vulnerability to report, or a security questionnaire to complete? Email hello@oneforce.com.au.