Privacy statement
Version dated 30 September 2026. This is the privacy statement for Kindra, the software made by Salix Limited. It is written for an early learning service to adopt: under the Privacy Act 2020 the service is the agency that holds a family’s information, and it puts its own name and privacy officer on its copy.
To ask for information to be deleted, see Deleting your information. For help with the software, see Support.
Status: template, for a centre to adopt and adapt. Not legal advice.
There is a distinction in this document that has to be got right before the wording matters.
Who is responsible for this information
Under the Privacy Act 2020, the agency that collects personal information carries the obligations. When a family gives a centre their child's allergies, the agency is the centre. Salix Limited, a New Zealand registered company (NZBN 9429053674067), runs the software the centre uses to hold it, and is called Salix for short from here on.
The company is named rather than the product because a family reading this should be able to identify who holds their child's records and, if it came to it, who the services agreement is with. Naming only a trading name would leave both unanswerable.
Section 11 of the Privacy Act 2020 is the provision that does this. It is headed Personal information treated as being held by another agency in certain circumstances, and it says that where one agency holds information for or on behalf of another, as a representative or agent or for safe custody or processing, the information is treated as held by the principal and not by the agent. So the centre remains the agency answerable to a family and to the Privacy Commissioner, and Salix's obligations run through the services agreement rather than directly to the family.
Section 11 has a condition, and it is the one that constrains how Salix may behave. The information is treated as held by the agent as well as the principal if the agent uses or discloses it for its own purposes. Salix holding a centre's records is not the company's information to learn from: using them to build a product feature, to train a model, or to publish a statistic would make Salix an agency holding that information in its own right, with obligations running directly to the family. That is why this document can say what the software collects and where it goes, and cannot offer a benefit derived from anyone's records.
This needs to be written into the services agreement explicitly, because a default nobody wrote down is an argument later. The clause is drafted in services-agreement-privacy-clause.md and waits on signature.
So this file is a template. A centre adopting it must put its own name on it, name its own privacy officer, and take responsibility for it. What Salix can state definitively is the second half of this document: what the software actually collects, where it goes, and who can see it. That part is derived from the schema, not drafted.
What the software collects
Everything below is a column that exists today. Nothing is aspirational.
Corrected 2026-09-24: this list has fallen behind the software and is not complete. The software also holds the following, which the sections below do not yet describe: a child's home address; a record that a document proving a child's identity was sighted, and by whom, but never the document's number; the names of visitors signed in at the centre; census details about staff (gender, age band, ethnicity, iwi and qualifications), which only the owner, the manager and the staff member themselves can see; and, for a home-based service, the address of each home where care is given.
About a child
| What | Why it is held | Who can see it |
|---|---|---|
| Name, preferred name, date of birth | Identity, and the ratio calculation needs an age | Staff at that centre; the child's own whānau |
| Gender, ethnicities, iwi, first language | Ministry funding returns ask for these | Staff at that centre; the child's own whānau |
| National Student Number (NSN) | Identifies the child in Ministry systems | Staff at that centre; the child's own whānau |
| Enrolment dates, days, funded hours, 20 Hours ECE | Funding, and the roll | Staff at that centre; the child's own whānau |
| Allergies, medical conditions, dietary requirements, severity, response plan | Keeping a child safe and alive | Staff at that centre; the child's own whānau |
| Medication authorities: medicine, dose, route, instructions, who authorised it | Giving medicine lawfully | Staff at that centre; the child's own whānau |
| Sign-in and sign-out times | Ratios, funding, and knowing who is in the building | Staff at that centre; the child's own whānau |
| Photos and videos, where consent has been given | The learning journal, and notices | Staff, and the audience the consent covers |
| Consent decisions, and who gave each one | So consent is a record, not a memory | Staff at that centre; the child's own whānau |
About whānau
Full name, relationship to the child, email, phone, address, whether they may collect the child, and whether they are an emergency contact.
Custody and court orders
Where a centre records a custody arrangement, it holds the detail entered and a court order reference. Visible to staff only, and never to any parent, including the parent it concerns. That is deliberate: a screen that shows one parent what has been recorded about the other is a screen that turns a centre into a party to a dispute.
About staff
Name, role, and the compliance records the centre is required to hold: first aid, police vetting, safety checks, practising certificates, child protection training, each with its reference, dates, and who sighted the original document.
A staff member can always read their own records. That is not a courtesy: the Act gives a right of access to information about oneself, and building a system where an educator cannot see their own police vetting result would be building a system that denies it.
About somebody applying for a job
Added 2026-08-06, when the careers page on the public website stopped being a mailto link.
Since 2026-08-27 the careers page asks applicants to email the centre again, and no form on the public website collects these fields. The software can still hold an application, and what follows describes how it treats one.
Name and email, and optionally a phone number, the sort of role wanted, an earliest start date, whether the applicant says they hold a current New Zealand practising certificate, and whatever they choose to write about themselves.
Four things about this collection are deliberate and worth stating plainly, because it was, until 25 September 2026 (corrected 2026-09-25), one of only two places, the other being the enrolment enquiry below, in this product where somebody who is not a member of the centre could write to the database (2026-09-25: no form on the public website uses either path now. A change withdrawing the public's access to both has been applied to the development and test databases (corrected 2026-09-25) and, on 2026-09-25, to the production database (corrected 2026-09-25), so the public can no longer write to the database through either):
- The certificate question is the applicant's own statement and is not treated as evidence. The screen says so where it is displayed. Evidence is a sighted document in the staff records, and a practising certificate is checked before anybody starts, not from a web form.
- Nothing is asked that belongs to a safety check. No date of birth, no address, no criminal-record question. A safety check is required before a children's worker starts; answering any of it into an unauthenticated public form would be a disclosure made before anybody had even decided to read the application.
- CVs are not stored by the software. They still go to the careers mailbox, so the centre holds them the way it always has. A CV carries an address, an employment history and referees' names and phone numbers (third parties who agreed to nothing), and storing it needs a retention rule and a deletion path that do not exist yet.
- Only the centre's owner and manager can see an application. Not educators, even at the same centre. Enforced by Postgres, and asserted by the isolation suite rather than claimed here.
Deletion, unusually, is available. The centre can destroy an application outright, and the audit log records that a deletion happened while keeping no copy of the row. That is asserted in the test suite, so "we removed your application" is a checkable statement rather than a reassuring one. This is not a change to the position below: the Act still gives no general right to erasure. It is the centre choosing not to keep the employment history of somebody it did not employ, which is the retention principle rather than an erasure right.
About somebody making an enrolment enquiry
Since 2026-09-25 no form on the public website sends enquiries to the software. The website is not connected to the software yet, so its enquiry form emails the centre's own enrolment mailbox and nothing from it is stored in the database. That email is the only copy. It is held in the centre's mailbox, can be read by anyone the centre gives access to that mailbox, and is kept for as long as the centre's own mail practice keeps it: no rule in the software reaches it. The software can still hold an enquiry, and what follows describes how it treats one.
Corrected 2026-09-25: an enquiry held by the software. Until 2026-09-25 these came from the public website's enquiry form, which asks the same questions but now sends the answers only by email, where the "Who can see it" column below does not apply. It requires your name, your email, which centre you are asking about, roughly when you would like to start, and how you heard about us. Your phone number, which days you would like, and anything you want to write are all up to you.
About the child it asks three things, every one of them optional:
| What | Why it is held | Who can see it |
|---|---|---|
| Your child's first name | So the centre can talk about your child by name when it rings you back | The centre's owner and manager |
| Your child's date of birth | Which room, when your child would move up, and where they sit on a waiting list | The centre's owner and manager |
| A tick for "my child is not born yet" | Families often join the waiting list before the birth | The centre's owner and manager |
It also asks how you heard about the centre, from a short list. That one is required, and it is about you rather than your child.
Four things about this are deliberate, and this was, until 25 September 2026 (corrected 2026-09-25), one of only two places where somebody who is not a member of the centre could write to the database (2026-09-25: the database function behind it has no caller now, and the public's access to it is withdrawn on the development and test databases (corrected 2026-09-25) and, since 2026-09-25, on the production database (corrected 2026-09-25)):
- Every question about your child is optional. An enquiry that names no child and gives no date is a complete enquiry, and the centre will ring you back the same way. The database columns are nullable, not just the form, and the test suite asserts that so it cannot quietly become required.
- There is no surname field. The centre asked for a first name, on the basis that it is what they use when they ring you.
- What it will never ask is anything belonging to an enrolment record: no address, no National Student Number, no ethnicity or iwi, no allergies, no medical or health information, no question about custody or guardianship. Those are collected once your child is enrolled, after you have met the centre. The test suite checks the (corrected 2026-09-25) enquiry database function, which the website's form no longer calls, for every one of those and fails if any appears.
- Only the centre's owner and manager can see an enquiry. Not educators.
Deletion is available here, and for the same reason it is on job applications: this table was written by strangers until 2026-09-25 and accumulated (corrected 2026-09-25) messages about named children, and not keeping what is no longer needed is what the retention principle is about. Note that New Zealand law gives you a right to see and to correct what is held about you, but no general right to have it erased. The centre deleting an old enquiry is the centre following its retention rules, not you exercising a right of erasure.
Changed on 2026-09-14. Until that date this form asked no child's name and no date of birth at all. It is recorded here rather than silently updated because a privacy statement that quietly grows is one nobody can check.
Changed on 2026-09-25. From that date the public website's enquiry form writes nothing to the software and only emails the centre, because the website is not connected to the software yet. Corrected 2026-09-25: the enquiries it had already written were exported for the centre and deleted from the software that day. The centre had already received each of them by email. Copies remain in the software's daily backups taken before the deletion until those backups expire, expected in early October 2026.
Technical
An email address and password for anybody with a login. A device token for anybody who turns on notifications. A log of who changed what and when, recording the names of the fields that changed and never their contents, so the log itself holds no information about any child.
What the software does not collect
- No payment card details. There is no payment processing.
- No analytics, no advertising identifiers, no tracking of any kind. There is no third-party analytics script in either app.
- Corrected 2026-09-24: no location data from any device, and no GPS. At a centre, a sign-in records a time, not a place. At a home-based service a sign-in can also record which home the care was given in, because the Ministry requires that home's address on every attendance record. The address is held once, in a list of the service's homes that only its staff can see, not on the attendance record a family reads.
- No biometrics.
- No contact list, calendar or photo library access beyond the photo a user chooses to attach.
Where it is held
In a Postgres database and file storage operated by Supabase, in Sydney, Australia (ap-southeast-2). The web application that reads it runs on Railway, in Southeast Asia. Both are confirmed from the deployment rather than assumed: the Supabase region was read from the provider's own project record on 2026-09-02, and the Railway region from its dashboard.
Two regions matter and they are not the same: Supabase holds the records at rest, Railway processes them in transit.
Neither is in New Zealand. Your children's records are stored in Australia. The Privacy Act permits that (IPP 12 requires comparable safeguards, not domestic hosting), but a centre should be told plainly rather than left to discover it, and a centre adopting this template should satisfy itself that the arrangement is one it accepts.
This paragraph was a blank until 2026-09-02, and said so: "the Supabase region still has to be filled in before a centre adopts this template… A New Zealand centre should know whether its children's records sit in Sydney, Singapore or Oregon." It is Sydney. The answer was one API call away for the whole time the question stood open, which is worth recording as its own small lesson.
Error reports go to Sentry when something breaks. Those reports are scrubbed before they leave: email addresses, phone numbers, dates of birth and any database value quoted inside an error message are removed. That scrubbing has its own tests, because a bug in it does not produce a wrong screen. It sends a child's medical information to a third party.
Emails from the software are sent by Resend, a company outside New Zealand, from noreply@kindra.co.nz. They are invitations to staff and parents, password reset emails, reminders to your centre's owners and managers about returns that are due, and any problem report someone at your centre sends us. Each email goes only to the person it is for. To deliver it, Resend receives the address and the email itself, which can include the person's name and your centre's name; a problem report contains whatever its writer put in it. The reminders contain no child's or family's details. Resend handles these emails in the United States.
If your centre's parents reach the parent portal through your own website's address, that traffic passes through Cloudflare, a company outside New Zealand, which runs that address for your website. Cloudflare carries everything a parent sends and receives in the portal on the way to and from the software, including their sign-in, and does not store the records. The staff console does not pass through Cloudflare.
A daily backup copy of uploaded photographs and files is held by Cloudflare, in its R2 storage service, separately from the main system, so that they can be recovered if the main storage is lost. We ask Cloudflare to keep this copy in the Oceania region, but Cloudflare does not guarantee where it is held, so it may be held outside Australia. A photograph or file deleted from the software stays in this copy for seven days and is deleted from it within about a day after that.
Written summaries, if your centre turns them on
This is off unless somebody at your centre has switched it on, in Settings. While it is off, nothing described here happens and nothing leaves for this purpose.
With it on, this product can send totals and dates to Anthropic, a company outside New Zealand, and get back a paragraph you can put in a report: how many breaches there were in a month, how much is overdue and for how long, which days next week are short.
What is sent is numbers and dates that this product calculated. No child's name, date of birth, National Student Number or health information is ever sent, and neither is any staff member's or family member's. That is not a promise about care taken: the code that builds what gets sent can only carry numbers, and it refuses to run rather than send anything else. Like the error-report scrubbing above, it has its own tests, and those tests are checked by deliberately breaking the rule and confirming they notice.
Anything written this way is a draft for a person to check. It is never a finding about your centre's compliance, and nothing in the evidence binder comes from it unless somebody has read it and put it there.
If your centre would rather not use it, leave it off. Nothing else in the product changes.
Who can see what
Separation is enforced by the database, not by the application. Every table carries row-level security, and there are two boundaries:
- Between centres. A person at one centre cannot read another centre's records, even where the same person works at both. A dedicated isolation suite re-tests this on every change to the product, including that a write across the boundary is refused, not just a read. It is the largest suite we run and it runs as its own gate, separate from the ordinary tests, because a failure here means something different from a failing feature.
- Between families inside one centre. A parent sees their own children and nobody else's. This is keyed on the guardianship record, so it survives a role change.
Photographs have a third gate. A photo of a child whose whānau have not consented is refused when it is uploaded. Should consent be withdrawn later, the photo becomes unreadable rather than merely hidden: the link the browser needs can no longer be issued.
Your rights
- To see what is held about you or your child. Ask the centre. The Act gives you this right and the centre must respond.
- To ask for a correction. Also a right. Where the centre disagrees, you may ask for a statement of your view to be attached to the record.
On deletion: New Zealand law does not give a general right to have information erased. That is European law and it does not apply here. What the Act does require is that information is not kept longer than it is needed. See retention for how long that is and why.
If something goes wrong
A privacy breach that is likely to cause serious harm must be notified to the Office of the Privacy Commissioner and to the people affected. The centre is the agency that notifies; Salix's obligation is to tell the centre immediately and to help establish what happened. The steps, and the timeframes, are in breach-response.
Who to contact
- The centre's privacy officer: every agency must have one. Name and contact details go here when a centre adopts this template.
- Salix, for anything about the software itself: vakkas@salixtech.co.nz
- The Office of the Privacy Commissioner, if a complaint is not resolved: privacy.org.nz
Template last updated 2026-09-30 (punctuation only: every em dash rewritten for the public page, no wording changed; before that 2026-09-28 ('Where it is held' names the daily backup copy of files held by Cloudflare R2, drafted in privacy-notice-and-storage-copy-drafts.md §2). Before that 2026-09-27 ('Where it is held' names Resend, which sends the software's emails from the United States, and Cloudflare, whose proxy carries the parent portal where parents reach it through the centre's own website; wording approved by the owner that day). Before that 2026-09-25, last (Salix's contact is now its own address, on the owner's decision: the director's address on the Pearl of the Islands Foundation's domain is for informal help to the Foundation and is not a Salix address; PRIV-18). Before that on 2026-09-25 (the enquiries the website had written were deleted from the software, with copies left in its daily backups until early October; the public's access to the two write functions is withdrawn on the test database and then on production, so the two places where a non-member could write to the database are described in the past tense). Earlier on 2026-09-25: the public website's enquiry form no longer writes to the software; it emails the centre. Previously 2026-09-24 (the list of what is collected marked incomplete, the careers page, the second public write path and home-based locations corrected), and before that 2026-09-17. A centre adopting it should date its own version and review it whenever what the software collects changes, because the tables above are generated from the schema by hand and will drift if nobody looks.