Privacy Policy

OneForce Care is a product of Wondertree Studios Pty Ltd (ACN 699 886 498, ABN 82 699 886 498), a company registered in New South Wales with its registered office at Level 10, 387 George Street, Sydney NSW 2000, Australia. In this policy, “OneForce Care”, “we”, “us” and “our” refer to Wondertree Studios Pty Ltd.

This policy explains how we collect, hold, use and disclose personal information in accordance with the Privacy Act 1988 (Cth) and the Australian Privacy Principles (APPs). It applies to our marketing website and to the OneForce Care web and mobile platform (together, the “Service”). It works alongside our Terms of Service, Data Processing Addendum, Security, Data residency and Cookie Policy.

By using the Service, you acknowledge the handling of information described in this policy.

1. Who this policy covers

We deal with personal information about four broad groups of people:

• Website visitors and enquirers. People who browse our site, request a demo, or send us an enquiry.
• Provider staff. Employees and contractors of a Provider (defined below) who log in to the platform, including anyone who raises a support request or issue report from inside the product.
• Workers. Support workers, coordinators and other staff whose employment, compliance or rostering record a Provider holds in the platform, including those who use the OneForce Care Worker App.
• Participants. The people receiving supports, whose records a Provider manages in the platform, along with their nominees, guardians and emergency contacts.

This policy does not describe a Provider’s own privacy practices for information it collects or uses outside the Service; that is set out in the Provider’s own privacy policy. Our website and platform may contain links to external resources, such as NDIS Commission or OAIC guidance; we are not responsible for the privacy practices of sites we link to, and this policy does not apply to them.

2. Definitions

• “Service” means, together, the Website and the Platform.
• “Website” means our public marketing website.
• “Platform” means the OneForce Care web application and the OneForce Care Worker mobile app.
• “Provider” means the disability, aged-care or NDIS support organisation that holds a subscription to the Service.
• “Worker” means a support worker, coordinator or other staff member of a Provider whose employment, compliance or rostering record is held in the platform.
• “Participant” means an NDIS participant or other care recipient whose record is held in the platform by a Provider.
• “Worker Data” means personal information about a Worker that a Provider, its staff, or that Worker records in the platform. It includes identity and contact details, employment and engagement details, award classification and pay figures, compliance and screening records, availability and leave, shift assignments and clock-in and clock-out records, travel and location records captured while a shift is in progress, notes a Provider records about that Worker, and documents uploaded to that Worker’s record. Section 5.3 sets it out in detail.
• “Participant Data” means personal information about a Participant that a Provider or its staff record in the platform. It includes identity details, government identifiers, health-adjacent support information such as diagnosis, support needs and goals, plan and funding details, service agreements and consent records, progress and shift notes, incident records naming that Participant, contacts and representatives, and documents uploaded to that Participant’s record. Section 5.4 sets it out in detail.
• “Provider Data” means, together, Worker Data, Participant Data, and all other information a Provider, its staff or its Workers enter, upload or generate in the platform in the course of running the Provider’s operations, including rosters, timesheets, incident reports, tasks, invoices, claims and payroll figures.
• “Account Data” means information we collect directly about a Provider’s business and about the individuals who access the Service, for our own purposes as described in section 3.
• “Sensitive information” has the meaning given in the Privacy Act, and includes health information.
• “Subprocessor” means a service provider we engage to help us deliver the Service, which handles personal information in doing so.
• “OAIC” means the Office of the Australian Information Commissioner.

3. Our role, and the Provider’s role

The Service is built for Providers to run their own operations. Because of that, two different privacy relationships exist side by side.

The Provider is responsible for Provider Data. As the organisation that collects information about its Participants and Workers (directly, or through referrals and enrolment processes) and decides what to record, the Provider is responsible for having a lawful basis to collect that information and for obtaining any consents needed, including for sensitive information. We process Provider Data only on the Provider’s documented instructions, as its engaged service provider, to deliver the Service. Those instructions are the Provider’s use of the Service’s features, its configuration choices, and any written instruction it gives us. We do not use Provider Data for our own independent purposes, other than: keeping the Service secure and investigating misuse; providing support at the Provider’s request; meeting our legal obligations; and improving the Service using de-identified or aggregated data that does not identify any individual. Our Data Processing Addendum sets out these obligations as contractual terms, including subprocessor change notice, security assistance, breach assistance, audit rights, and return or deletion of data at the end of a subscription.

We are responsible for Account Data. We collect Account Data directly, for our own purposes, so we are the accountable entity for it in the ordinary way. Account Data includes information about a Provider’s business (organisation name, ABN, billing contact) and about individuals who use the Service directly (name, work email, login and security history).

If you are a Participant or Worker and want to know how your information is handled, your first point of contact is the Provider whose platform record you are in, since they control that record and your relationship is with them, not with us. Section 28 explains how to reach us if that does not resolve your query, and section 23 explains what we can and cannot do with a record we hold on a Provider’s behalf.

Internal access for support and operations. OneForce Care operates a separate, platform-owner administration area used to manage Provider workspaces (for example, creating and updating Provider accounts, tracking onboarding, and assisting with account-level issues such as resetting a Provider owner’s multi-factor authentication). Access to this area is limited to authorised OneForce Care staff, is used only to operate, support and secure the Service, and is not a means for us to use Provider Data for any purpose the Provider has not instructed. Actions taken in that area are recorded in the platform’s audit log.

4. Why we are bound by the Privacy Act

We want to be straightforward about the basis on which we handle personal information, because it matters to a Provider assessing us.

Wondertree Studios Pty Ltd is a small business. Depending on our annual turnover in a given year, we may fall below the small business operator threshold in section 6D of the Privacy Act, which would mean the Act did not apply to us of its own force by reason of turnover alone. We do not rely on that. We handle personal information as though we are an APP entity in every case, we are contractually bound to comply with the Privacy Act and the APPs under our agreement with each Provider, and where the Act does apply to us of its own force we comply with it as a matter of law. We also comply with the Notifiable Data Breaches scheme (Part IIIC of the Privacy Act) as described in section 24 and, contractually, in the Data Processing Addendum.

Practically, this means a Provider can hold us to the APPs, to this policy, and to the Data Processing Addendum, and can escalate a complaint to us and then to the OAIC as described in section 25. If our status under the Act changes, we will update this section rather than quietly relying on an exemption.

5. Information we collect

The kinds of personal information we hold depend on your relationship with us, ranging from a website enquiry to a detailed Worker or Participant record. The categories below cover the Service as a whole; no single person’s record will contain all of it. Where a category is Provider Data, the Provider decides what is recorded and we hold it on the Provider’s behalf.

5.1 Account and enquiry information

When you request a demo, contact us, or a Provider signs up, we collect names, work emails, phone numbers, organisation names, ABNs, job titles, team size, any preferred demonstration time, and the content of any message sent to us. When a Provider account is created we also collect billing and subscription details. Our website’s enquiry forms carry a short collection notice at the point of collection, and this policy is the full notice for that collection.

5.2 Provider staff information

For people who log in to the platform, we hold name, email, phone, assigned role and permissions, multi-factor authentication status, and sign-in and sign-out history (the account, the IP address the request came from, and a timestamp), recorded for account security purposes.

5.3 Worker Data

Providers use the platform to record information about their Workers, including:

• Identity and contact details: name, date of birth (where recorded), address, phone and email.
• Employment details: employment basis and category, role title, ABN (for contracted workers), agreed weekly hours, and default work location or transport arrangements.
• Award classification and pay figures: SCHADS Award code, classification level, pay point, employment stream, and any hourly-rate override; recorded shift times, clock-in and clock-out data, and the payroll figures generated from them (hours, allowances and pay items) that a Provider uses to run its own payroll or push to its accounting system.
• Compliance and screening records: NDIS Worker Screening clearance identifier and status, Working with Children Check number, qualifications, and high-intensity support skills, used to track a Worker’s eligibility to deliver particular supports.
• Availability and leave: recurring availability, unavailability and leave periods a Worker or Provider records.
• Rostering and location data: shift assignments; where a Provider enables travel capture, the route and distance of a travel leg recorded during a shift; and, where a Provider enables the on-site clock-in check, a location reading taken at the moment a Worker clocks in, used to confirm the Worker is at the shift’s starting address. Location is not tracked continuously and is not recorded outside these events.
• Mobile app data: for Workers using the OneForce Care Worker app, a device push-notification token used to deliver shift and roster notifications.
• Notes and documents: notes a Provider records on a Worker’s file, and documents uploaded to it (for example, a certificate or clearance).

Some of this information is sensitive information. Where a Provider records details of a Worker’s screening outcome, or health information relevant to fitness for duty, we handle it under section 11.

5.4 Participant Data (includes sensitive information)

Providers use the platform to record information about the Participants they support, including:

• Identity details: name, date of birth, gender, pronouns, preferred language, and, where volunteered, ethnicity and Aboriginal or Torres Strait Islander status.
• Government identifiers: NDIS number, and, where recorded, Medicare number and Centrelink reference number.
• Health-adjacent support information, which is sensitive information under APP 3.3: primary diagnosis, support needs, risks, preferences and goals recorded in service agreements and support plans, and notes made by support workers in the course of delivering a shift.
• NDIS plan and funding details: plan management arrangement, plan dates, funding categories, budgets and support items, and support coordinator contact details, where a Provider records them.
• Emergency and representative contacts: contact details for a guardian, nominee, plan manager, support coordinator or emergency contact, where recorded.
• Consents: the consents a Provider records for a Participant, including the date, scope and signatory.
• Signed documents: service agreements, consent forms and other documents generated and signed through our electronic-signature workflow, and the completed signed copy of each.
• Financial records: invoices, claims, payments and adjustments relating to supports delivered to that Participant.

5.5 Incident reports

The platform includes an incident-reporting feature Providers use to log workplace and NDIS-reportable incidents. An incident report can include the date, time and location of the incident, a description of what happened, the Participants and Workers involved, witnesses, immediate actions taken, evidence uploaded, and, where applicable, whether the incident is reportable to the NDIS Commission and its reportable category and deadline. Incident reports can therefore contain sensitive information about a person’s health or about alleged conduct, and we treat them accordingly.

5.6 Support and issue reports

The platform includes an in-product help and issue board. When a Provider’s user reports an issue or asks a question through it, we record the reporter’s name and email address, the Provider they belong to, the category and details they write, and any file they attach. People sometimes attach screenshots that include Participant or Worker information, so we treat issue reports as capable of containing personal information and handle them accordingly. Section 15 explains where issue reports are stored.

5.7 Technical and log information

We collect limited technical information from anyone using our website or platform, such as IP address, browser and device type, request timestamps and basic server logs, to operate, secure and troubleshoot the Service. The platform records an audit log of significant actions, described in section 18 and on our Security page. See our Cookie Policy for the specific browser and device storage the Website and Platform use.

6. How we notify you of collection

Where practical, we tell you what we collect and why at or before the time of collection, for example through a short notice on our enquiry and demo-request forms and a link to this policy. This policy is the APP 5 collection notice for information we collect directly, namely Account Data, website enquiries and support or issue reports.

Because a Provider directly manages its own onboarding, consent and enrolment processes for Participants and Workers, the Provider is best placed to give those individuals APP 5 collection notices at the point it collects their information, and it is responsible for doing so. The platform gives a Provider tools to help, including consent records against a Participant’s file and service agreements sent for electronic signature, but those tools do not discharge the Provider’s obligation to give a collection notice in its own name.

Some fields on our sign-up, enquiry and platform forms are mandatory, marked as such at the point of entry. If you do not provide that information, we, or the Provider, may not be able to respond to your enquiry, create or maintain your account, or provide the specific feature that field supports (for example, a Worker’s award classification is needed to calculate that Worker’s pay).

7. Where information comes from

We collect information:

• Directly from you, when you fill in a form, send an enquiry, report an issue, or enter information as a Provider, Worker or Participant using the platform.
• From Workers, through self-service profile fields and the mobile app (for example, a clock-in location reading, a travel route, a progress note, or a push token).
• From Providers, on behalf of Participants, where a Provider enters or uploads Participant information as part of managing that Participant’s supports.
• Automatically, through the ordinary operation of the Service (device, browser and usage information; login and audit events).
• From public registries, such as the Australian Business Register, when a Provider signs up and we verify the ABN it provides.
• From third parties a Provider engages, such as the outcome of an NDIS Worker Screening check that a Provider enters into a Worker’s record.
• From a connected accounting system, where a Provider connects its own Xero organisation and data flows back, such as the payment status of an invoice.
• From your device, through the local storage described in our Cookie Policy, such as your saved display theme and session.

Unsolicited information (APP 4). We do not seek information we have not asked for. If we receive personal information we did not solicit and could not have collected under APP 3, we destroy or de-identify it as soon as practicable, provided it is lawful and reasonable to do so. In practice this most often arises when someone attaches more than we need to a support request.

8. Anonymity and pseudonymity

Where it is lawful and practicable, you can deal with us without identifying yourself, for example when browsing our public website or making a general enquiry. In most cases, however, it is not practicable for us to deal with you anonymously or under a pseudonym: the Service is an account-based platform used to manage real rostering, service-delivery, compliance and payroll records, so a Provider, Worker or Participant record must be tied to an identifiable person for the Service to work and for a Provider to meet its own NDIS obligations.

9. Why we collect, hold, use and disclose information

We collect, hold, use and disclose personal information to:

• provide, operate and support the platform and mobile app for Providers, including rostering, service delivery, claiming and payroll-figure generation;
• generate, send for signature, store and deliver service agreements and consent documents;
• operate incident logging and the NDIS-reportable incident workflow;
• send transactional notifications, such as shift changes, reminders, signing requests and security alerts;
• confirm, where a Provider enables it, that a Worker is at the shift’s starting address at clock-in, and record travel for billing and reimbursement;
• manage Provider accounts, billing and our customer relationship;
• respond to enquiries, support requests and issue reports, and provide demonstrations of the Service;
• keep the Service secure, detect and investigate misuse, and maintain audit logs;
• comply with our legal and regulatory obligations, including tax, corporate and privacy obligations; and
• respond to access, correction and other requests made under this policy.

We do not sell personal information, and we do not use Participant or Worker information for advertising or marketing, whether ours or anyone else’s. We do not use Provider Data to train, benchmark or improve products for the benefit of other customers.

Product improvement. We may analyse de-identified, aggregated usage information, for example which features are used most, or how long an incident report takes to complete, to improve the Service. We do not publish or disclose aggregated information in any form that could reasonably identify a Provider, Participant or Worker, and once information is genuinely de-identified it is no longer personal information.

10. Direct marketing

We may use the contact details of a website enquirer or a Provider’s billing or admin contact to tell them about OneForce Care features, updates or events, consistent with APP 7 and the Spam Act 2003 (Cth). Every marketing message includes a clear way to opt out, and we will stop within a reasonable time of you asking, at no cost to you. On request we will tell you where we obtained your contact details. We do not send direct marketing using Participant or Worker information, and we do not disclose personal information to any other organisation for their own direct marketing purposes. Transactional messages that a Provider’s use of the Service generates, such as a shift notification, a signing request or a security alert, are not marketing and cannot be opted out of without changing the underlying setting in the platform or with the Provider.

11. Sensitive information

Some Provider Data is sensitive information, including health-adjacent support information and, in incident reports, information about alleged conduct. We only ever handle this information because a Provider has recorded it in the platform under its own lawful basis and consents (see section 3); we do not independently decide to collect it, and we do not use it for any purpose other than providing the Service to that Provider.

Sensitive information is subject to the same access controls, isolation between Providers, encryption and audit logging as the rest of Provider Data, and we apply the additional safeguards described on our Security page. Access by our own personnel to a Provider’s records is limited to what is needed to operate, support or secure the Service, and is logged.

12. Government identifiers

Participant records can include government identifiers, namely NDIS numbers and, where recorded, Medicare and Centrelink reference numbers. Worker records can include a Worker Screening clearance identifier and a Working with Children Check number.

Consistent with APP 9, we do not adopt an NDIS number, Medicare number, Centrelink reference number or other government-related identifier as our own identifier for an individual, and we do not use or disclose these identifiers except: to deliver the Service on the Provider’s instructions (for example, including an NDIS number on a claim or invoice); where the individual has consented; where required or authorised by law; or where reasonably necessary to prevent or investigate unlawful activity.

13. Children’s information

The Service is designed for use by adults, namely Provider staff and Workers. Some Participants supported through the platform are children; where that is the case, the Provider is responsible for the lawful basis and parental or guardian consent for collecting that child’s information, in the same way it is responsible for any other Participant Data (see section 3). Where a Provider records a nominee, guardian or parent against a child’s record, we treat that contact information as Participant Data.

We do not knowingly collect personal information directly from children through our marketing website. Some records relating to children must be kept longer than the ordinary retention period under other laws, and section 21 explains how retention works.

14. Decisions the Service does not make for you

The Service produces calculations and prompts, but it does not make automated decisions with legal or similarly significant effects about a Participant or a Worker. It suggests, calculates and flags; a person at the Provider decides. For example:

• pay figures and award interpretations are calculated for a Provider to review before it pays anyone;
• compliance and availability checks warn or prevent an assignment inside the Provider’s own roster, but a Provider configures those rules and decides how to act on them;
• claim and invoice lines are prepared for a Provider to review before lodging; and
• incident categorisation and reporting deadlines are prompts, not a substitute for the Provider’s own assessment.

We do not use personal information for profiling, scoring or behavioural analysis, and we do not use Provider Data to train machine-learning models.

15. Who we disclose information to

We do not disclose personal information except as needed to run the Service, comply with the law, or as set out below. We choose Subprocessors based on their security practices, their contractual commitments to protect personal information, and, where relevant, whether they can host or process data in Australia. We give each Subprocessor only the information it needs for its function, and none of them may use personal information for their own purposes.

We also make outbound requests to public reference sources, such as published award rate data, that carry no personal information at all.

We may also disclose information:

• to our own professional advisers, such as our accountants, auditors and lawyers, bound by confidentiality obligations, where reasonably necessary for them to advise us;
• to a prospective or actual buyer and its advisers, if we are involved in a merger, acquisition or sale of some or all of our business or assets, subject to appropriate confidentiality protections, and with the incoming entity bound to handle information consistently with this policy;
• where required or authorised by law, such as in response to a lawful request from a regulator or law-enforcement body, or to establish or defend a legal claim; or
• with your consent.

Where we receive a legally binding request for a Provider’s data, we will, unless prohibited by law, tell the Provider before we disclose anything, so it has the opportunity to respond to the request itself.

16. Changes to our Subprocessors

The categories above are the complete set we use to deliver the Service today. We keep a current list of the specific Subprocessors behind each category, and we will give it to a Provider on request via hello@oneforce.com.au so the Provider can run its own APP 8 assessment.

Before we add a new Subprocessor, or replace one, that will handle Provider Data, we will give Providers at least 30 days’ notice by email to the account contact and by updating this page. A Provider may object on reasonable data-protection grounds within that period, and we will work with the Provider in good faith to resolve the objection, which may include offering a different configuration. If we cannot resolve it, the Provider may terminate the affected part of its subscription without penalty and without paying fees for any period after termination. This commitment is set out in full in our Data Processing Addendum.

17. Overseas disclosure

Where we can, we keep Provider Data onshore. The platform’s application hosting, database, authentication, document storage, electronic signing and transactional email sending all take place in Australia. The exceptions, where limited personal information is handled outside Australia, are named in the table in section 15 and are:

• the mobile push-notification relay, which may process push tokens and notification content outside Australia;
• the address-lookup service, which processes the characters typed and the address selected on its own overseas infrastructure;
• the geocoding service, which converts a shift’s starting address to coordinates on its own overseas infrastructure;
• the mapping and route-distance service, which measures a travel leg from its start and end coordinates on its own overseas infrastructure;
• Xero, which hosts each Provider’s connected organisation on its own infrastructure, in whichever region Xero uses for that organisation; and
• our enquiry and issue-tracking system, which may store website enquiry data and in-product issue reports outside Australia.

Transactional email is sent from Australian infrastructure, but once a message leaves us it travels to the recipient’s own mail server, which we do not control and which may be located anywhere. That is inherent to email, not a choice we make about where to host.

For each overseas flow we send only the minimum information needed for the relevant function, and we take reasonable steps consistent with APP 8 to satisfy ourselves that the recipient handles personal information in a manner consistent with the APPs, including through the provider’s own terms, published security practices and data-protection commitments. The platform’s database, document storage and backups are not routed through any of them. See our Data residency page for a fuller explanation, and section 28 if you would like more information about a particular disclosure.

18. Security

We apply layered technical and organisational safeguards to Provider Data, including strict separation between Provider organisations enforced at more than one layer, encryption in transit (TLS/HTTPS) and at rest, multi-factor authentication that a Provider can require for its own roles, role-based access control with independent read, create, edit and delete permissions per area, rate limiting on sensitive actions, audit logging of significant actions, and a separate record of sign-in and sign-out events. Access to production systems is limited to authorised personnel on a least-privilege basis, and we keep the software and infrastructure the Service runs on maintained and patched.

The audit log records who acted, in which Provider workspace, what action was taken, which record it affected and when. For most actions it records the name of the field changed rather than a copy of its contents; for a small number of actions it also records the value the field was set to, and for a few (such as an edited clock-in or clock-out time, or a change of business name) it records the value before and after. Providers can read the audit trail on a participant or worker record and export it.

Full detail is on our Security page. No method of transmission or storage is completely secure, and we cannot guarantee absolute security, but we work continuously to reduce risk and to respond quickly if something goes wrong (see section 24).

19. Our people

Access to production systems containing Provider Data is limited to Wondertree personnel and contractors who need it to build, support, secure or operate the Service.

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 under this policy 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. 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.

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 acts and omissions in handling personal information as if they were our own.

20. Quality of information

We rely on Providers, Workers and account holders to give us accurate, complete and up-to-date information, since a Provider is closest to its own Participants and Workers and best placed to keep those records current. Consistent with APP 10, we take reasonable steps within our control to support this: validation on data entry, verifying a Provider’s ABN against the Australian Business Register at sign-up, flagging expiring compliance documents, and giving Providers and their staff the ability to correct records themselves at any time through the platform, rather than only through a request to us. If you believe information we hold is inaccurate, see section 23.

21. How long we keep information

We keep personal information only for as long as needed for the purposes in section 9, to meet our legal obligations, or for as long as a Provider instructs us to retain data on its behalf. Once information is no longer needed for any of those purposes, we securely delete or de-identify it.

• Provider Data, while the subscription is active. We hold it for as long as the Provider’s account is active and the Provider instructs us to hold it. A Provider decides what to archive, correct or remove within its own workspace.
• Deletion on instruction. When a Provider deletes a record or a document, we remove it from live systems. A deleted document is removed from storage at the same time as its register entry. Residual copies in encrypted backups are purged within 35 days of the deletion.
• Archiving. Archiving a Participant or Worker in the platform hides the record from everyday use but does not delete it, because a Provider usually needs the underlying history for its own record-keeping. Archiving and deleting are different actions, and the platform says which one it is doing.
• Provider Data, after termination. We make Customer Data available for export for 30 days after termination or expiry, after which we delete or de-identify it, except where we must retain it to meet our own legal obligations. Section 22 explains what to do before that window closes, and Section 20.4 of the Terms of Service sets it out as a contractual term.
• Account Data. Kept for as long as the relevant account is active, plus a reasonable period afterwards for legal, accounting and dispute-resolution purposes.
• Website enquiries and issue reports. Kept for as long as reasonably needed to respond and for a limited period afterwards for our own records, unless you ask us to delete them sooner.
• Security and audit records. Audit events and sign-in records are retained for the life of the Provider’s account, because their value is that they cannot be quietly trimmed. Short-lived operational records, such as rate-limiting and invite-throttling records, are purged automatically on a rolling basis, and location trails recorded against a travel leg are cleared after 90 days while the distance and time remain.

Our retention is not your record-keeping. NDIS providers are generally required to keep records for at least 7 years, and other laws can require longer, including for records relating to children. Holding a record in OneForce Care does not discharge that obligation, and our retention periods are not designed to. If your account ends, we will not be holding your archive for you: the 30-day export window closes, and after it we delete. Export the records you are required to keep, keep them somewhere you control, and treat the platform as the working system rather than the vault. Sections 4.6 and 11.6 of the Terms of Service and Section 2 of the Early Access Terms say the same thing from the other direction.

22. Getting your data out

A Provider can export its own data from the platform at any time during its subscription, at no charge:

• Tabular records export as machine-readable CSV from the reporting area, covering participants, workers, directory contacts, shifts, tasks, incidents, referrals, cancellations, the document register, service agreements, plan budgets, invoice readiness, invoice batches, payments, and the audit trail. Column selection, filters and sorting are available before export.
• Invoices download as PDF, and NDIA bulk payment requests download as CSV in the format the claiming portal expects.
• Payroll figures download as CSV, by summary and by category.
• Documents and signed agreements download individually from the record they belong to.

If the self-service tools do not cover something you need, ask us. On written request we will produce a complete export of your Customer Data, tabular records as CSV and stored documents as their original files, within 10 Business Days, at no charge, once during your subscription term and once on exit. We will tell you what is included before we start, so the completeness of what you receive is never a surprise.

23. Accessing and correcting your information

Under APPs 12 and 13, you can ask to access personal information we hold about you, and ask us to correct it if it is inaccurate, out of date, incomplete, irrelevant or misleading.

• If you are a website enquirer or a Provider’s own account holder, contact us using the details in section 28. We will verify your identity first, and we aim to respond within 30 days.
• If you are a Participant or Worker, please contact the Provider whose platform you are recorded in first. They control that record, know the context it was collected in, and are best placed to action a correction. Most correction requests are resolved in minutes by the Provider, because they can edit the record directly and we cannot do so on their behalf without their instruction.
• If you cannot resolve your request with the Provider, or you do not know which Provider holds your record, contact us. We will assist consistently with our obligations as the Provider’s service provider: we will confirm whether we hold information on that Provider’s behalf, pass the request to the Provider, ask them to respond, and tell you what we have done. Where the Provider does not respond in a reasonable time, we will tell you so you can take the matter further, including with the OAIC.

We will not charge you for making a request or for us giving access. We may decline a request in the limited circumstances the Privacy Act allows, for example where giving access would have an unreasonable impact on another person’s privacy, where the request is frivolous or vexatious, or where giving access would be unlawful. If we decline, we will tell you why in writing and explain how to complain.

If we correct information and it has already been disclosed to someone else, we will, if you ask, take reasonable steps to notify that recipient of the correction, unless it is impracticable or unlawful to do so.

24. If a data breach occurs

We maintain processes to detect, assess and respond to data incidents affecting personal information, and we keep an internal record of each suspected or confirmed incident, our assessment of it, and the steps taken in response, so we can demonstrate our handling to the OAIC or to an affected Provider if asked.

Assessment. If we suspect an eligible data breach may have occurred, we carry out a reasonable and expeditious assessment and complete it within 30 days of becoming aware of the grounds for suspicion, as required by section 26WH of the Privacy Act. In practice we aim to complete an assessment far sooner, and we do not wait for the assessment to finish before containing the incident.

Telling the Provider. Where the affected information is Provider Data, we will notify the affected Provider without undue delay and, in any event, within 72 hours of confirming an eligible data breach affecting that Provider’s data. If we cannot confirm the full picture within that time, we will notify what we know and update the Provider as the investigation progresses rather than staying silent until we have everything.

Our notification will include, to the extent known: what happened and when; the categories of personal information and the approximate number of individuals affected; the likely consequences; what we have done to contain and remediate it; and a contact point at Wondertree for follow-up.

Telling individuals. Where the affected information is Provider Data, the Provider is the organisation with the relationship to the individuals concerned. We will consult the Provider before notifying that Provider’s Participants or Workers, and we will not make a unilateral notification to them except where the law requires us to, or where a delay would create a serious risk to a person’s safety. This is not a way of avoiding notification: it is so a single, accurate message reaches the individual from the organisation they actually deal with.

Helping the Provider meet its own obligations. A Provider has its own assessment and notification duties, under the NDB scheme and potentially to the NDIS Quality and Safeguards Commission. We will give the Provider the information and assistance it reasonably needs to meet them, including the facts of the incident, the categories and volume of data affected, relevant log and audit extracts where we can provide them safely, and reasonable co-operation with the Provider’s own investigation and communications.

Our own notifications. Where an eligible data breach affects Account Data or otherwise requires us to notify, we will notify affected individuals and the OAIC as the Privacy Act requires.

These commitments also appear as binding terms in our Data Processing Addendum.

25. Making a complaint

If you have a concern about how we have handled personal information, please contact us first at hello@oneforce.com.au so we can try to resolve it directly. Please give us enough detail to investigate, including what happened, when, and what outcome you are looking for. We will acknowledge your complaint within 5 Business Days and aim to give you a substantive response within 30 days. If we need longer, we will tell you why and when to expect an answer.

If your complaint concerns a record a Provider holds in the platform, we will usually need to involve that Provider, since they control the record. We will tell you if that is the case.

If you are not satisfied with our response, or we have not responded within a reasonable time, you can complain to the Office of the Australian Information Commissioner. The OAIC generally expects you to have first given us a reasonable opportunity to respond.

• Website: oaic.gov.au
• Phone: 1300 363 992
• Post: GPO Box 5218, Sydney NSW 2001

Complaints about the conduct of an NDIS provider, as opposed to how we handle information, go to the NDIS Quality and Safeguards Commission on 1800 035 544 or at ndiscommission.gov.au.

26. Changes to this policy

We may update this policy from time to time as our practices, products or the law change. The “last updated” date at the top of this page shows when it last changed. Where a change is material, we will take reasonable steps to bring it to the attention of active Providers, for example by email to the account contact or an in-app notice, before it takes effect. Changes to our Subprocessors follow the notice process in section 16.

27. Quick reference: Australian Privacy Principles

For ease of reference, this table shows where each Australian Privacy Principle is primarily addressed in this policy.

Part IIIC of the Privacy Act, the Notifiable Data Breaches scheme, is addressed in section 24.

28. Contact us

Privacy questions, access and correction requests, and complaints all go to the same place, and a person reads every one of them.

Email hello@oneforce.com.au, or write to us at the address below.

Wondertree Studios Pty Ltd ACN 699 886 498 / ABN 82 699 886 498 Level 10, 387 George Street, Sydney NSW 2000, Australia