Privacy Policy

Version 0.3 · for the GapCheck portal and worker app

Draft 0.3, 6 October 2026. Written to match what the software does today. Not yet reviewed by a lawyer. Version 0.3 · 6 October 2026

Gap Check (a sole trader business) ABN 24 289 004 542 ("GapCheck", "we", "us") makes software for NDIS providers: a portal for the provider's office and an app for its support workers. The software keeps training records, rosters, shift notes, charts and the claim files a provider sends to the NDIA. This policy says what personal information we hold, why, who can see it, and what you can do about it.

We are a small Australian business. We follow the Australian Privacy Principles in the Privacy Act 1988 (Cth) for everything described here.

Three kinds of people

• Our customers. Providers, and the staff who sign in to the portal for them. We decide what we collect about them, and this policy covers it.
• Our customers' workers. The support workers a provider employs. Their employer enters them, assigns their training, rosters their shifts and sets their pay rates. We hold this on the employer's behalf. The employer decides what goes in and how long it stays. If you are a worker with a question about your record, ask your employer first; we will help them answer.
• Our customers' participants. The people the provider supports. The provider enters them and its workers write about them. We hold this on the provider's behalf too. The provider is the one who owes the participant a privacy notice; we hold the records so the provider can meet its own record-keeping and claiming obligations.

What we hold

About a provider's staff

Name, email address (which is also the sign-in), a password stored only as a scrypt hash we cannot read, the account's role (administrator, coordinator or assessor), appearance settings, whether they opted in to a Monday summary email, and the times they sign in.

About a provider's workers, entered by the provider

• name, the identifier the provider chooses, job role, and work email if the provider enters one;
• training: courses assigned, due dates, every assessment attempt (the questions asked, the answers given, score, pass or fail, date) and any competency sign-off with the assessor's name and the assessor's note;
• credentials the provider records, such as an NDIS Worker Screening Check, first aid, a police check or a driver's licence: the kind, its number and expiry;
• documents the provider uploads against a worker (PDF, PNG or JPEG, up to 5 MB), such as a scanned certificate;
• rostering: shifts and every change to them with who made it and, for an override of a training block, the coordinator's written reason; offers the worker claimed; usual weekly availability, time off with its kind (leave, sick, unavailable, training) and a reason if the provider writes one, and when a worker called in sick for a shift;
• pay: the hourly rates the provider enters for the worker, including evening, night, weekend and public-holiday bands, and the hours the provider approves;
• clock in and clock out times for each shift, and, only if the provider has switched it on, the phone's location (latitude, longitude and accuracy) at the moment of clocking in or out — see "Location" below;
• announcements the provider posts and whether and when the worker read each one on the app.

About a provider's participants, entered by the provider or written by its workers

• an identifier the provider chooses and a short label (the form asks for initials, not a full name), plan dates, how the plan is managed, the plan funding amount if the provider enters it, and the participant's NDIS number if the provider enters it (needed for claims);
• if the participant is plan-managed, the plan manager's name and email as the provider records them;
• which shifts were rostered for the participant, with which worker and which support item, travel recorded against a shift, agreed support hours, and which workers usually support them;
• progress notes a worker writes and signs at the end of a shift about the support given and how the person responded;
• chart entries a worker confirms from a note: bowel (opened or not, and type), food (meal, amount, texture), fluid (amount and drink), activities;
• medicine records, where we have switched the feature on for the provider: the provider's list of the participant's medicines as written on the label, and a worker's record that a medicine was given, refused or not given, with a reason; and a provider's setting to flag when no bowel opening has been recorded for a number of days;
• incidents the provider records, including incidents it treats as internal and not reportable: the category, which worker and participant were involved, when it happened, a summary, the immediate actions, and follow-up entries. An incident record can describe what a worker did or is said to have done.

Progress notes, chart entries, medicine records, incident records and a "sick" marker against a worker are health information, which the Privacy Act treats as sensitive. We hold them only on the provider's instruction and only to run the features the provider uses.

What we ask providers not to enter. The software has no field for a participant's full name, date of birth, address, care plan or behaviour support plan, and it refuses document uploads against a participant, so a restrictive-practice authorisation or a behaviour support plan cannot be stored here. (An incident record can say that a restrictive practice was used; that is a record of an event, not the authorisation.) We ask providers to keep those details out of free-text notes too. A note that names other people is the provider's responsibility under its own privacy obligations.

From the mobile app

• the training a worker completes;
• when they clock in and out, and the phone's location at that moment if the provider has switched location on;
• the notes they sign, the chart rows and medicine records they confirm, and the shift offers they claim;
• which announcements they have read.

The app turns a dictated note into text on the phone. The recording is not sent to us or to anyone else. The app does not read contacts or photos, and does not use the camera.

What stays on the phone. So the app works without signal, it keeps a copy of the worker's shifts (with the participant labels and, where the feature is on, the participant's medicine list), offers, announcements, hours and pay estimates, unsent notes and drafts, and the queue of notes, chart rows and clock events (with location, if on) it has sent or is waiting to send. The worker's answer about the tax-free threshold stays on the phone, and the tax estimate is worked out there; we never see either. Signing out removes all of it and the device's key. If a provider removes a phone's access, the app clears its copies the next time it talks to us and keeps only unsent notes and results until the worker signs in again.

Trying the demo

The app has a "Try the demo" button. It signs you in as a made-up worker at a made-up provider, on our live service. Everyone who tries the demo is the same made-up worker, so anything you type there — a note, a chart row, a clock-in — can be seen by the next person who tries it and by us. Do not put anything real in the demo. The demo never records location, and demo access expires after a day.

Location

Location is off unless a provider switches on "ask for location on clock" in its account settings. When it is on, the app asks the phone's operating system for permission and, if the worker allows it, sends the phone's position at the moment of clocking in or out, and at no other time. The worker can decline, and the clock-in still works; the record then says location was declined. The provider's staff can see the position on the shift page and open it in a map. A clock-in position can show where a participant lives: the provider decides whether to use this feature and owes its workers and participants an explanation of it.

Automatically

• ordinary web server logs, which record the network address and browser of each request and are kept for 90 days;
• the product audit log: for every change made in the portal, who made it, when, what changed, and the network address it came from. We keep the network address on an audit row for 90 days and then remove it; the rest of the row stays while the provider's account is active, because it is part of the evidence of who changed the register;
• failed sign-in attempts, kept briefly to slow down password guessing.

Why we hold it

• to run the service: deliver courses, mark assessments, keep the training register current, roster shifts, hold signed notes and charts against shifts, record incidents, work out pay estimates from the rates the provider entered, send the reminders the provider asked for, and build the claim files and invoices the provider sends;
• to keep the service secure and to investigate misuse;
• to improve the service using de-identified, aggregated information as described next.

De-identified use. Today we use personal information for nothing but running the service. If we ever want to use de-identified, aggregated information about assessment results — for example, how workers across providers do on one question — to improve our courses and marking, we will say so in this policy first, remove names, emails, identifiers and free-text answers before any use, and never use progress notes, chart entries, medicine records, incident records, locations or pay for it.

We do not sell personal information. We do not use it for advertising or to profile individuals.

Who else sees it

• BinaryLane, which hosts our server in Sydney, Australia.
• Zoho Mail (Australia), which delivers our email: training links and reminders to workers and the provider's contact, password resets, roster change notices to workers (only if the provider switches them on; they name the shift times and the participant's label), and a Monday summary to administrators who opt in (it names participants by label under "funding to watch"). Emails carry no assessment answers, notes, charts, pay or locations.
• An onshore backup. A nightly copy of the database, checked whole before it is kept, is pulled to a machine we control in Australia and kept for 30 days; our host also keeps two days of server snapshots in Sydney. The database is kept out of any overseas backup.
• Google, only if a staff member clicks "Map" on a clock-in position: that opens Google Maps in their browser with the coordinates. Our server does not contact Google.
• Apple and Google distribute the app through their stores. No personal information from the service goes to them.
• The NDIA and plan managers receive the claim files and invoices the provider itself downloads and sends. We do not send them.

Nobody else. We disclose personal information only where the law requires or authorises it. If we are compelled to hand over a provider's data we will tell the provider unless the law forbids it.

Our own access. Our staff can see provider data only to support and maintain the service, and only when there is a reason to. A support request is the usual reason.

Within a provider. The provider's administrators and coordinators can see everything the provider holds. An assessor can see the training register, credentials and the training and credential items on the "needs attention" page, but not notes, charts, medicines or incidents. A worker, on the app, sees only their own shifts, notes, pay estimates and training. Every query is scoped to one provider; one provider cannot see another's data.

What leaves the service, by the provider's choice

The provider's staff can download:

• the training register and audit log as CSV;
• a pay-run CSV with each worker's approved hours, base rate and estimated pay; a timesheet CSV; a finance CSV;
• a credentials CSV with each worker's credential numbers;
• the NDIA claim file with participants' NDIS numbers, and plan-manager invoices showing a participant's full NDIS number;
• a printable notes pack for one participant with the full signed notes;
• an export of all the provider's records as CSV files plus the uploaded documents: workers, pay rates, availability, participants, shifts, offers, notes, charts, medicine records, incidents, clock events with positions, credentials, claim files, announcements, settings and the audit log. Not in it: passwords, keys and sessions.

Those files are the provider's. Where they go after download is the provider's decision and responsibility.

A worker can also choose to make one of their own completion records public as a link, to show an auditor; nothing about a worker is public unless they do this. The only things public without sign-in are course videos, the app itself, a provider's logo, and an invite page showing the invited worker's display name and provider.

Where it is held

On one server in Sydney, Australia, with a nightly copy to a machine we control in Australia. Email goes through Zoho Mail's Australian service. Nothing is stored overseas.

Security

Passwords are hashed with scrypt. Session cookies and device keys are stored only as digests, so a stolen copy of the database cannot be used to sign in. All traffic is encrypted in transit. Repeated failed sign-ins are slowed down by account and by network address. Every database query is limited to the provider making it. The app keeps its device key in the phone's secure store, and the Android app is excluded from cloud backup. A signed note, a chart entry, an incident record and a clock event are never edited or deleted.

Some of what we hold would cause real harm if it leaked: notes and charts about a participant's health, medicine records, incident records, NDIS numbers, pay rates, and clock-in positions that can show where someone lives. We treat all of it as sensitive.

No system is perfectly secure and we will not claim otherwise.

Data breaches

If we become aware of a breach that is likely to result in serious harm, we will assess it promptly and tell the affected providers what happened, so they can tell their workers and participants, whom only they can identify. We will notify the Office of the Australian Information Commissioner and the affected people where the Notifiable Data Breaches scheme requires that of us, and help the provider meet its own obligations under the scheme.

How long we keep it

While a provider's account is open, we keep its records so the register, the notes and the claim evidence stay complete. That includes notes, charts, medicine and incident records, uploaded documents, and clock events with their positions. Records are not deleted when a worker or participant leaves; the provider archives them, and they stay in the provider's export.

Shorter periods: network addresses on audit rows and in server logs, 90 days; sign-in sessions, 14 days; password-reset links, 60 minutes; failed sign-in records, 7 days; the rows staged while a CSV of workers or participants is being imported, 30 minutes; demo access, one day.

When a provider closes its account we give it the export described above and then delete its records, including its audit log, from the live system within [NUMBER] days, and from backups within a further [NUMBER] days as backups age out. The record that a provider accepted these terms is kept permanently.

We do not set retention periods for a provider. Its own obligations decide how long it must keep training, claim, incident and complaint records.

Access and correction

Provider staff: you can see, correct and export your organisation's records in the portal. A signed note cannot be edited; a worker corrects it by signing a new note that supersedes it. Chart entries, incident records and clock events cannot be edited or removed by anyone; if one is wrong, record the correction in a note or an incident entry, and tell us if it must be struck out.

Workers: ask your employer. Your record is theirs and they can correct it. If you cannot get an answer, contact us at hello@gapcheck.net and we will help.

Participants: ask the provider that supports you. We hold only the label and identifier your provider chose, so we cannot find your records from your name. If you contact us, we will help you put the request to your provider.

Complaints

Write to hello@gapcheck.net. We will acknowledge within [NUMBER] business days and respond within [NUMBER] days. If you are not satisfied you can complain to the Office of the Australian Information Commissioner at oaic.gov.au.

Changes

We post changes here with a new version number and date. For a change that matters, we tell account holders by email before it takes effect, and the portal asks them to accept the new version.

Contact: Gap Check, Shop 2/290 Boundary Street, Spring Hill QLD 4000, hello@gapcheck.net