Security Policy

1How to report a security issue

If you have found a security problem in Reason Education — a way into an account, a way to see another school's data, an exposed file, anything of that kind — tell us. We would rather hear it from you than from a school.

Security reports and fault reports share an address on purpose. A school that notices “something looks wrong” should not have to decide first whether it is a bug or a breach — that is our judgement to make, not theirs. Anything in that inbox that could be a security matter is treated as one until it is shown not to be.

If we get it wrong

• If we miss an acknowledgement, escalate. Every channel has a named alternate who is a different person from its owner, so there is always somebody else to ask.
• If you are not satisfied with an outcome, ask in writing for a review by the other officer — not the person who made the decision. Answered within 10 business days (Terms clause 21.2).
• If you are still not satisfied, go outside us. Privacy: the OAIC, and for a Victorian government school the OVIC. Child safety: the Commission for Children and Young People, and Victoria Police. Online safety: the eSafety Commissioner. We will not ask you to exhaust our process first, and we will not treat going to a regulator as a breach of any agreement.

2What this policy covers, and what governs

This policy covers the security of the Reason Education Staff Portal, the Student App, the hosting they run on, and the systems entity name — to be confirmed (ACN acn — to be confirmed, ABN abn — to be confirmed), trading as Reason Education, uses to operate and support them.

Non-production

Our non-production hosting is a labelled test environment only. It carries synthetic data — invented schools, invented students, invented staff. No school or student data is ever placed on it, no production backup is ever restored into it, and it is never described as production or as “current hosting”.

Keeping this accurate

This policy is version-controlled and dated. It is reviewed:

• at least annually, on the next review date shown at the top of this page; and
• whenever a control described here changes — including a change of role holder, of sub-processor, of hosting region, of sign-in method, or of the AI model in use, and after any security or privacy incident.

A review that finds no change still gets a dated entry, because “we looked and it was still true” is the part an assessor cannot otherwise verify.

• v1.0 26 August 2026 First issue.

3Who is accountable, and what they can stop

Security in a small company fails in a predictable way: everybody assumes somebody is watching. So each of the three roles below is held by a named individual, in writing, in a signed appointment. We name the roles here rather than the people, so a change of founder does not date this page; the signed Order Form names them.

What can be stopped, and by whom

The AI Accountability Owner may, at any time and without the agreement of the person who develops the AI: halt a release, including one already staged; halt a change to the pinned model or prompt version; stop every model call outright; suspend a school's processing or a specific data flow; or require an incident to be opened.

The standing item

• A monthly security and privacy item — 30 minutes, every founder, chaired by the Security Officer, on a fixed agenda: incidents and near misses, open vulnerabilities and patch status, access changes, privacy matters, AI oversight, and open actions with an owner and a date.
• Minuted the same day into one running file. A month with nothing to report is recorded as a month with nothing to report — a gap in the file means the meeting did not happen, not that it was quiet, and that distinction is the whole value of keeping it.
• Anything that meets the definition of an incident goes to both officers the same day, never to the next monthly item. The monthly item is for pattern, never for first notification.
• The security and supply-chain risk register is reviewed quarterly, and on any incident, any new vendor and any change of hosting. A new sub-processor cannot be introduced until it has a row in that register — the register is the gate on choosing a vendor, not a record of vendors already chosen.
• Administrative credentials are used only for administrative tasks. The person holding them also holds a separate non-privileged account for everything else — email, documents, day-to-day work — so the account reading external mail is never the account that administers the database.

4The law and the standards we are held to

Each obligation below is named with what it actually requires of us. A list of statute names with no consequence attached is decoration.

Privacy Act 1988 (Cth) and the Australian Privacy Principles

We collect only what the product needs, use it only for the purpose it was collected for — there is no secondary use, no analytics, no advertising, and a contractual no-training term with the model provider — and we keep it secure by the controls on this page. The Privacy Policy is the APP 1 statement of all of it, including that the model provider is in the United States.

The Notifiable Data Breaches scheme

Where we suspect on reasonable grounds that an eligible data breach may have occurred, we complete an assessment within 30 days and, if the breach is eligible, we notify the Commissioner and the affected individuals as soon as practicable. Because the individuals are children in a school's care, the affected school is told the same day we form the suspicion — before the assessment concludes and without waiting to know how bad it is. The mechanics are in section 17.

Privacy and Data Protection Act 2014 (Vic), and the VPDSS

Victorian government schools and the Department are Victorian public sector bodies. When they contract us, their protective data security obligations flow to us as a contracted service provider, and the Victorian Protective Data Security Standards are the yardstick our controls are measured against — not a framework we have chosen, one we inherit with the customer. Where a school's contract or its department's guidance imposes something stricter than this policy, the stricter obligation wins and the difference is recorded.

Victorian Child Safe Standards

We provide a service used by children. Standard 9 — that physical and online environments promote safety and minimise the opportunity for harm — is the one that bites on a product like ours. It is why the AI never talks to a child, why there is no student-facing free-text surface, why there is no messaging of any kind and no child-to-child visibility. Standards 6 and 7 are why child safety has a named owner and a published address, and why a child safety concern is handled as an incident rather than as support mail.

Standards our build is measured against

• OWASP Application Security Verification Standard, Level 1 — the acceptance bar a release is measured against, control by control. Level 1 is a floor, not a ceiling: several controls already sit at Level 2 and are not regressed to meet a lower bar.
• OWASP Web Security Testing Guide v4.2 — the test procedures. ASVS says what must be true; the WSTG says how to check it.
• The vendor and CIS benchmarks for each hosted component, and for every laptop that can reach a company system.
• The ACSC Information Security Manual hardening guidance and the Essential Eight, as the Australian overlay an assessor will read this against.

5Staff accounts, passwords and sessions

Staff accounts are created and administered by the school. A staff member sets their own password; we never see it and we never store it in a form that can be read back.

• Passwords are stored only as a bcrypt hash at cost 12, over a SHA-256 pre-hash so that a long passphrase is not silently truncated.
• A password must be at least 15 characters — or 12 where the account has a second factor enrolled. Length, not a symbol quota. There is no forced rotation and no password hint.
• Every new password is checked against the Have I Been Pwned corpus of known breached passwords. A password that appears in it cannot be set.
• Raising a minimum does not invalidate an existing password. The new floor applies the next time that person sets one. Forcing a reset pushes people towards a weaker password they can remember for a week, which is the opposite of the control.
• Account links are stored hashed and are single-use. An invitation lasts 7 days; a password reset link lasts 60 minutes. A used link is spent, and a reset never reveals the current password.
• Sign-in is rate-limited and counted on more than one dimension, so rotating addresses does not defeat the lockout.
• Changing a password ends every other session on that account — the half of that control most implementations leave out.
• One account, one person. Every view of a child's work is logged against the account that viewed it, so a shared account destroys the only record of who looked (Terms clause 8.1).
• A staff account with no successful sign-in for 12 months is disabled at 11 months with the school's administrator notified, and the school has 30 days to keep it before it is deleted (Terms clause 17.6).

Sessions

A staff portal open on a laptop in a staffroom is a real risk, and the timeouts are set for that room rather than for an office.

Account email — invitations, resets and notices — is processed in Australia, so a single-use recovery link stays onshore. A school tells us without delay if it suspects an account has been reached by someone who should not have it (Terms clause 8.6).

6Two-step verification, and losing it

The second factor is a TOTP code from an authenticator app, verified against the published test vectors of the standard it implements, with a replay guard so a code cannot be used twice. Where a staff member has enrolled one we hold their TOTP secret; where they have not, we hold nothing.

• Mandatory for school administrator and principal accounts, and it cannot be turned off — those accounts create and remove other accounts. It is enforced by role, not by a school setting, so a school cannot switch it off for exactly the accounts that most need it (Terms clause 8.2).
• Available to every other staff account.
• A school may require it for every account in its school, and we will enforce that setting.

• We hold no standing break-glass account. There is no elevated credential sitting in a drawer waiting to be used. Recovery is an action taken on one named account, not an account of its own.
• A recovery that turns out not to have been genuinely requested is treated as a serious security incident, not as an administrative mistake.

This matters more than it looks. An account-recovery process that hands back the account rather than the factor is a way in that bypasses both the password and the second factor at once, and it is the control most often quietly missing from a service that advertises two-step verification.

7Student sign-in, and printed cards

Children do not create accounts, are not asked to agree to anything, and are never asked to remember a password.

• A student signs in by scanning a signed, single-use QR token printed on a card generated in the Staff Portal. The token authenticates once and is then spent.
• There are no student PINs. From launch, no reusable student credential is stored anywhere in a form that can be read back — the earlier design used a printed PIN and it is removed before any school or student data exists.
• Where a school cannot scan, the teacher issues a short-lived one-time code at the moment of sign-in. It is stored hashed, expires quickly, and works once.
• Reprinting a card always invalidates the previous token. There is never a state in which two live cards exist for one student.
• Repeated failed attempts against a student number are rate-limited, so a card cannot be guessed at by volume.

There is also no messaging of any kind in the Student App. A student cannot send a message to anyone and no one can send one to a student. That removes a whole category of risk rather than monitoring it, and it is a design decision, not a feature we have not reached. A child's route to an adult is their teacher, in the room.

8What we log, and for how long

The audit log is the control that makes every other control checkable. It is written to on every state change, and on every read of a child's work.

• The application reaches the database as a least-privilege user that cannot update or delete an audit row. From the application's side the log is append-only.
• A school may ask us for the audit entries relating to its own students, and we will provide them.

9Segregation between schools

There is no cross-school discovery. There is no search, directory or discovery feature that lets a user in one school find, view or discover a user or any personal information from another school.

• No data sharing between customers
• No cross-school analytics, benchmarking or league table
• No transfer feature that moves a student record between schools

The two applications run against one database, so the boundary between schools is a property of the pair rather than of either one. It is tested as a pair, and it is in scope for the independent penetration test in section 16.

Attempting to reach another school's data, or to probe or bypass the service's controls, is prohibited use under Terms clause 9.1. Where there is a real risk to student data we may suspend an account or a school immediately, and we will tell the school the same day and say why (Terms clauses 9.3 and 30.1).

10Encryption, and where the data lives

Data is encrypted in transit and at rest. Production runs on Microsoft Azure App Service and Azure Database for MySQL Flexible Server in Australia Southeast (Melbourne), with images of handwritten working out in blob storage in the same region. Inbound traffic is HTTPS only, enforced at the platform rather than in application code, and the database is reached over a private path rather than across the internet.

Who can reach production

• Production access is held by the founders only, all in Australia. There are no employees, no contractors and no offshore support arrangement with access to school or student data.
• Adding anyone outside Australia who could read unencrypted school data — our own staff, a contractor or a support provider — is a notifiable change with a written notice period of its own, in section 13.
• Production data is never copied anywhere else — not into the test environment, not onto a laptop. When a school reports a problem we cannot reproduce, we reproduce it with synthetic fixtures or we investigate in place under the audit log. We do not take a copy.
• Every administrative credential is unique, generated in a password vault, and protected by a second factor. Nothing lives in source, in a configuration file or in a chat message.

11Backups, recovery and deletion

Backups are encrypted, held in Australia, and retained for 100 days before they expire. That number is the honest arithmetic behind every deletion promise we make: on a weekly cadence, a 90-day retention can leave the oldest surviving copy at 84 days the day before a new one lands, which is under the three-month floor a school is entitled to expect. One hundred days guarantees a backup at least three months old exists at every moment.

• The backup is restored and verified at least annually, and once before any school or student data exists. A backup that has never been restored is a hope, not a control — and a restore regime whose first attempt happens during an outage is not a regime.
• Every copy carries a checksum computed when it is written and re-verified quarterly. Silent corruption in a compressed archive is undetectable without it.
• Backups are never restored into the test environment or onto a laptop.
• Backups are ordinary compressed SQL text and standard image formats — no proprietary backup container. A copy readable only by the product that wrote it is a copy you cannot read after you leave that product.
• The backup job reports both a failure and a run that did not happen at all. A job that errors tells you something; a job that quietly stopped being scheduled tells you nothing, which is why the missing-run alarm matters more than the failure alarm.

If something goes down

• If the model provider is unavailable, the service keeps working. AI Analysis is not on the critical path — marking is deterministic code and curriculum judgements are teacher decisions. Analysis is switched off and everything else carries on.
• A failover to our Sydney recovery target is a move between Australian regions, not a change of country. Every school is still told it happened, because a school's own reporting may need it.
• Recovery does not depend on any one person being reachable, and the person who performs a restore is not the person who verifies it.
• Our recovery point and recovery time targets, and the fact that they are measured in business hours, are set out in the school agreement in writing. We do not publish an availability figure — see section 19.

12The AI boundary, treated as a security control

The AI is the largest deliberate hole in an otherwise closed system: it is the one place school data leaves Australia. So we treat the boundary around it as a security control and test it like one. The full description is in the Responsible AI Policy, Privacy Policy section 7 and Terms clause 13.

• The payload is assembled from an allow-list — built up from named fields, never produced by stripping identifiers out of a full record. A field added to our database next year is not sent by default.
• One answer per request. The image of the working out, the question, the answer, whether our own code marked it correct, and the year level as a band (“middle primary”), never as a year number.
• No identifier crosses — not a name, not our student number, not a database id, and not a pseudonymous token, because a pseudonymous token would make every request for one child linkable to every other.
• The provider is contractually barred from training on school data, and the request is made with retention disabled on the provider's side. That written term is in place before the first production call is made.
• The AI never decides a mark, and never talks to a child. There is no chatbot, tutor or hint of any kind.
• Model and prompt versions are pinned in source. We never point at “latest”, and a change to the model or a material change to the prompt carries 14 days' written notice (Terms clause 15).
• One other call reaches the same provider: setting up a school's own workspace sends the school's name and nothing else. No student data, no staff data, no addresses. It is named here because it is a real outbound call and it is not covered by the description above.

Names on the page — four controls

1. Design — the canvas has no name field, no header region and no title page. Nothing invites a name.
2. Instruction — a hint on the canvas the child sees, and a matching note to the teacher.
3. Pre-send scan — every piece of text in the payload is checked against the roster of the class actually sitting the paper. A hit means the page is not sent; it goes to teacher-only review and is logged.
4. Post-call scan — the model's response is checked against the same roster. A hit means the response is quarantined before it is stored, so the name is never written into our database.

A school may turn AI Analysis off entirely, in writing, and keep every other part of the service — we action it within 2 business days, and marking, results, curriculum judgements and growth history all keep working, because marking is arithmetic (Terms clause 13.7).

13Sub-processors, and notice before anything moves

Four third parties can hold or receive school data. They are named, with what they receive and where, and every one of them is bound in writing. There is no fifth.

• Every sub-processor is bound in writing to the purpose, the scope and the scale of the data it receives, to the security controls it must operate, to our ownership terms, and to the breach notification obligation in section 17.
• No sub-processor receives school or staff data before that written breach-notification obligation is in place. Not as a first step, not as a trial.
• A new vendor cannot be engaged until it has a row in our supply-chain risk register, and the sub-processor list is reviewed six-monthly and immediately on any change.

Notice before anything moves

The notice names the country, the provider, what data is affected, what changes about the legal regime that reaches it, and why. A school that objects may terminate the affected part of the service, or the whole agreement, before the change takes effect, with a pro-rata refund — or, for an AI hosting change, simply turn AI Analysis off and keep the rest. Questions about a notice are answered within 5 business days, and a full export is available at no cost before the change takes effect. Where a provider forces a change on us with less notice than we owe a school, we tell every affected school within 2 business days of learning of it, and say plainly that we could not meet our own lead time and why (Terms clause 12).

14The people who can reach the data

Nobody from this company is ever in a room with a child. It would be easy to conclude that screening does not apply to us. It does, for one reason: a person here can open the production database and read a photograph of a page a nine-year-old wrote. That is unsupervised access to a child's own words, held on behalf of a school that is accountable to the parent.

Screening, before access

• A Nationally Coordinated Criminal History Check for every founder, and for every contractor or associate with any access to school or student data or to a system that serves it.
• A Victorian Working With Children Check, employee category — not the volunteer category, which does not cover paid engagement — for everyone holding access to a system containing student data.
• A card is not verification. Each check is verified online against the issuing service and the card number, expiry and result are recorded. A photograph of a card or an application receipt proves nothing.
• The company is listed as an organisation on each holder's check, so we are told if a card is suspended or revoked rather than finding out at renewal. Cards are renewed every five years, applied for 90 days before expiry, and a change of status is reported to us within 2 business days.
• A disclosable outcome is not automatically disqualifying. Relevance to the role is assessed in writing, with the person, and the assessment is reviewed by a second person who is not its subject.
• Somebody with no access to any system holding school or student data — a designer working from invented examples, say — is not screened, and the decision and its reason are recorded rather than left implied.

Training, before the first sign-in

• Security, privacy, online safety and AI awareness training is delivered before access to any system is granted — not on the first day, before the first sign-in — and annually after that.
• Also within 30 days of a material change to the AI design, the hosting environment, the sub-processor list or a relevant law, and within 30 days of any incident, targeted at what caused it.
• Anyone with administrative access takes the privileged module as well. There is no exempt group, and the founders are the group most likely to exempt themselves, so they are named individually in the register.
• Delivery is recorded with a date, against a named person, by somebody other than the person trained. Attendance alone is not evidence of anything.

What everyone here has to do

• A second factor on every system, without exception, including systems that hold no student data. An attacker does not need the database if they have the domain registrar.
• A password vault, unique credentials, nothing reused, and nothing in a document or a chat message.
• Full-disk encryption on every device, automatic screen lock at 15 minutes, and operating system and browser kept on supported versions.
• No school or student data on the test environment, ever, and no production data on a laptop.
• No one acts on an emailed request to change a payment detail or a DNS record without confirming it through a second channel. Phishing, not an exploit, is the realistic threat to a company this size.
• Report anything odd the same day, to either officer. Reporting something that turns out to be nothing has never been held against anyone here and never will be. The failure mode we are guarding against is silence.

A contractor accepts these obligations in writing before any access is granted. Access is granted the day work starts and revoked the day it ends. A breach of this policy by a contractor ends the engagement, and access is revoked the same day.

15How we build, and how a change reaches a school

We are a small team, so the controls that survive are the ones a process holds in place rather than the ones a person is supposed to remember.

Three environments, kept apart

• Development is our own workstations, working against synthetic data. No production credential is ever present on one.
• Test is a labelled test environment carrying synthetic data. No school or student data is ever placed on it. Being a test environment does not make it unprotected — it is behind authentication and it is patched — but a compromise there is not a data breach, and we will never describe one as though it were.
• Production is the only environment that ever holds school or student data. Separate databases, separate credentials, separate storage, no shared secret, and no path from a lower environment to a higher one. A credential that works in two environments has merged them, whatever the diagram says.

How a change reaches a school

• Everything is a change — application code, database schema, configuration, infrastructure, a vendored library, a sub-processor, and the AI model version or the prompt. Each one carries a change record with a stated reason, a category, a security and privacy impact assessment, a named approver and a written rollback plan. A schema change has a reverse migration that has been run, not merely written.
• The person who wrote a change does not approve its own security assessment, and a second person reads the diff. Where an emergency genuinely leaves nobody else available, that is recorded as a deviation on the change record and reviewed within five working days.
• Nobody edits a file on a server. Not through a file manager, not over SFTP, not “just this once to fix the typo”. A server-side edit is a change nobody can review, nobody can roll back, and the next deployment silently reverts.
• Test and production receive built artefacts from a tagged release, never edits, so what passed testing is what runs. Installer and upgrade tools are not part of what ships to production. A hotfix is the same path run quickly, not an exception to it.
• The source is private, permanently. It contains the shape of the data model and the exact implementation of every control; publishing it hands an attacker the map.
• An emergency change exists so a real incident is not delayed by paperwork — it moves the paperwork after the fix, it does not remove any of it. If we reach for it more than twice in a quarter, that is a signal the ordinary path is too slow and the procedure gets reviewed rather than bypassed again.

What the automated suites actually cover

Eleven automated test suites run before every release. They cover the AI boundary — that no identifier can reach a model payload, that exactly one function may build one, and that the output contract and the frozen taxonomy hold; cryptographic behaviour, against the published test vectors of the standards concerned; the privacy guardrails — the name scan, the release gate that keeps model output away from children, the provenance rule, and a corpus of prompt-injection attempts replayed against our own guards; and the measurement engine.

16Finding and fixing weaknesses

A control nobody checks is a wish. This section is how a weakness gets found, and how fast it gets closed.

The bar a release is accepted against

Both applications are assessed control by control against OWASP ASVS Level 1, using the OWASP Web Security Testing Guide v4.2 procedures. A release is accepted against that matrix or it is not accepted. The matrix carries a verdict, a piece of evidence and a date on every row — including the rows that are not satisfied — and it is available to a school on request. Any new security control ships with a test that fails when the control is removed; that is the rule that stops the matrix decaying into a document about the past.

Finding things

• An automated vulnerability scan of both applications on every deployment, and a monthly authenticated full scan against the test environment. The full scan never runs against production carrying school data — an authenticated active scan writes data and trips rate limits by design, which is exactly what the test environment exists for.
• A monthly posture assessment of the hosting configuration against the platform's own security benchmark. Every new finding is fixed or recorded as an accepted exception with a reason.
• Weekly automated discovery of everything we run and everything we expose, diffed against the previous week. The point of a diff is that it finds the thing nobody meant to publish. Endpoints are checked quarterly.
• Dependency and source-code scanning on every push, and a monthly check of the two third-party JavaScript files we serve ourselves against their upstream projects and the public advisory database.
• And a person telling us — a school, a teacher, a researcher. That route is section 1 and it is not a lesser one.

Fixing them

• Three things escalate a finding whatever its nominal rating: it touches student data or a child-facing page, it crosses the boundary between two schools, or a working exploit exists.
• Nothing has a window longer than one month. Anything past its window is escalated to the Privacy Officer and named individually at the monthly item, with a reason.
• A scanner finding is a hypothesis until it is confirmed against the actual code or configuration. False positives are recorded as such, with the reason, so the same alert is not re-litigated every month.
• Impact is judged as what happens to a child's data, a school's boundary, or availability during an assessment — not as a severity score alone. The score is recorded because it is comparable; it is not the decision.
• Where a mitigation would cost more than the risk it removes, the risk is accepted in writing, by name, with a review date — never silently, and never by one officer alone where personal information is involved.

Staying current

• Every patch arrives through a channel that authenticates it — the vendor's signed update channel, the platform's own maintenance, or a download from the vendor's release page checked against their published checksum. Nothing is installed from a mirror, a search result or a bundled installer.
• Applied is verified, not assumed. After every patch we record the component, the version now reported, the date and how it was checked. An unverified patch is an unpatched component with a note attached.
• Rollback is arranged before the patch, not after. If nobody can state the rollback, the change is not approved.
• Versions are compared against our asset register monthly. A component that has moved backwards — because an older build was redeployed, or an auto-update was switched off — is investigated as an incident.
• Nothing runs later than six months before its end-of-support date. A migration off an approaching end-of-life version is planned as a change, with a date, not left to the deadline.

17If a breach occurs

The first notification is “here is what we know now”. It says what we found, when, what we think is affected, what we have already done and what we are doing next — and where an answer is not yet known it says not yet known rather than waiting for it. Splitting the obligation this way is what makes 24 hours a real number rather than an aspirational one: a short factual message can be written by whoever is available, in twenty minutes. A message that had to wait for a finished investigation could not be. Any of us may send that first notification — it is not reserved to one person, and the assessment of whether a breach is notifiable to the regulator runs on its own 30-day clock and never blocks the school being told.

The complete notification contains all seven of these. A notification missing any of them is not complete, and the incident stays open:

• What happened, in plain language, without jargon or hedging
• When it occurred, or the window if the exact time is not established
• When we discovered it, and how
• Which individuals are affected — by student number and class, or stated as the affected run or cohort where the individual list is still being established
• What information was involved — the actual fields and records, not a category label
• What we have done — containment, remediation, and whether it is still happening
• What the school should do, including any action only the school can take

We then update the school at least every 48 hours until the matter is contained, and give a written closing report within 10 business days of containment.

The school decides what it tells parents, students and its department, and when. We will not contact a school's parents or students about a breach without the school's written instruction, and we will give the school whatever information and drafting help it asks for. Where the Notifiable Data Breaches scheme applies we support the school's assessment and make our own notification where the obligation is ours.

Where there is a real risk to student data we may also suspend an account or a school immediately, tell the school the same day and say why, and restore access as soon as the risk is dealt with.

18What the school is responsible for

Several of the controls above only work if the school holds up its end, and they are the ones nearest the classroom. These are obligations in the Terms of Service, not suggestions.

• Keep the user list current, remove access when a staff member leaves, and do not share accounts (clause 8.1).
• Handle printed sign-in cards as credentials, and tell us if a batch is lost or exposed so we can revoke the tokens (clause 8.5).
• Tell us without delay if an account may have been reached by someone who should not have it (clause 8.6).
• Do not enter health information, protection orders, custody arrangements, behavioural or wellbeing notes, government identifiers, or financial details. The service is not designed to hold them and is not assessed to hold them (clause 22.2).
• Instruct students not to write their names or other identifying details on the working out canvas. This is control 2 in section 12, and it is the cheapest and most effective of the four (clause 22.3).
• Provide and maintain the devices and the network the service runs on, and their security and antivirus protection (clause 22.5).
• Nominate in writing the person authorised to give us instructions about the school's data, and a named contact for incidents. We will not act on an instruction from a parent or any other third party (clause 10.5).
• Do not probe, scan, load-test or attempt to break the service without our written agreement in advance — report a weakness instead — do not extract data in bulk or automate the interface, and do not copy a child's work or a report into a general-purpose AI tool (clause 9.1).

19What we do not claim

This is the section a tender response usually leaves out. We are a small, founder-run company that has not yet been through the assessments a larger vendor can point at, and a school should weigh that alongside everything above rather than discover it later.

• We hold no security certification. We are not ISO/IEC 27001 certified, we have not completed a SOC 2 audit, and we have no IRAP assessment to give you. Our hosting provider holds those for its own platform; a provider's certificate is not ours to claim, and we do not present it as though it were.
• We make no assessment-status claim of any kind — including under any schools cyber security assessment scheme — until a full assessment has actually been completed. A submitted questionnaire is not a status.
• We have no independent penetration test report to cite yet. One is a condition of go-live rather than a nice-to-have — we previously graded it optional and that was wrong. When there is a report we will say who did it and when, and we will never describe an internal review as one.
• Our eleven automated test suites are not security testing. They test the AI boundary, cryptography, the privacy guardrails and the measurement engine. No response of ours will imply that they answer a question about injection, authorisation or rate limiting — see section 16 for what does.
• The person holding the Security Officer role holds no formal security certification. What supports the appointment is direct daily control of every system and authorship of the controls themselves. The gap is closed by the Essential Eight self-assessment, the ASD small business checklist, and independent testing before go-live — not waved away.
• We publish no uptime figure and offer no contractual uptime. We aim to keep the service available in school hours and plan maintenance outside them where we can. We will not publish a figure until we can meet it (Terms clause 26.2).
• We do not offer 24/7 support, we do not run an on-call rota, and we do not run a security operations centre. The urgent number is answered outside hours for security and child safety matters, and everything else runs to business hours (Terms clause 21.3). The honest residual is that a call late on a weekend may take longer to reach a person than one on a school day, and our recovery targets are measured in business hours for the same reason.
• We do not run a bug bounty and cannot pay for a security report.
• We publish no accuracy figure for the AI until there is a stated evaluation set, method, date and model version behind it. Any figure quoted to you without all four is not ours (Terms clause 4.5).
• We do not claim that nothing leaves Australian jurisdiction, because it would not be true. One payload goes to the United States, and it is named in section 10. We also do not claim the AI runs in Melbourne. It does not.
• We will never say the AI can never see a name. See section 12.
• We do not represent that we are endorsed by, affiliated with or accredited by any department of education, curriculum authority or assessment scheme, unless we say so in writing and name the scheme (Terms clause 29.2).

20Contact us, and when this policy changes

Officer roles are named rather than people, so a change of founder does not date this page. The signed Order Form names them.

Every one of these addresses is monitored by at least two of us, so that no report can sit unread because one person is away. An address nobody watches is worse than no address at all.

When this policy changes

• We notify every account holder at least 14 days before a change takes effect, with a plain summary of what changed and why. Schools are told at the same time as their staff.
• A change that reduces a protection the Terms of Service give a school takes effect only at renewal, on at least 60 days' written notice, and the school may decline it and terminate instead (Terms clause 3.4).
• A change of hosting country, of the country the AI model is served from, or of a sub-processor is notified under the periods in section 13 — not as a policy update.