Website security for Australian schools
It collects enrolment enquiries, takes payments, and publishes photographs of children. It is also, at most schools, the only significant system with nobody assigned to patch it.
School websites are commissioned as marketing projects and then quietly become data systems. Enrolment enquiries arrive through them. Fees and excursion payments are taken through them. Family contact details, student names and photographs sit on them. And when the build is finished, the agency's engagement ends and the site starts ageing.
Almost every school we assess has the same gap: the website is outside the scope of managed IT services for schools because the marketing budget bought it and the IT budget did not. Nobody is wrong. It is a procurement artefact. But it leaves the most publicly exposed system you own with no patching owner, no monitoring and no backup you have tested.
The ownership gap, stated plainly
Ask three questions at your next leadership meeting.
- Who applies security updates to the website, and how often?
- If it were defaced or taken offline on a Sunday, who would we call?
- Where does an enrolment enquiry go after somebody presses submit?
In our experience the answers are, in order: the agency probably does, we would email the agency on Monday, and into somebody's inbox. None of those are unreasonable. They are just not controls, and the site is holding the personal information of children and their families.
What the site is actually collecting
Worth writing down, because it is usually more than anyone remembers commissioning.
- Enrolment enquiries and applications — student name, date of birth, current school, parent contact details, and sometimes information about learning needs or health, which is sensitive information.
- Payments — fees, uniform, excursions, fundraising. Even where a third-party gateway processes the card, your page is what the family trusts.
- Event and consent forms — often built with whatever form plugin was available, storing submissions in the site's own database indefinitely.
- Employment applications — including working with children check numbers, which is one of the more sensitive things a school holds.
- Newsletters and mailing lists — usually a third-party service, usually connected with an API key nobody has rotated.
- Photographs and student work — covered below, and the item most likely to cause a complaint.
If any of that is stored in the website's own database rather than passed straight through to a system you actually manage, the website is now part of your education data protection obligations whether it was scoped that way or not.
Six failures we find, in order of frequency
1. An unpatched content management system
Usually WordPress, though the platform is not the point. The core is often current because it updates itself; the plugins and theme are not. Abandoned plugins — no update in two years, author unreachable — are the usual entry point, and there are typically four or five on a school site.
The fix is unglamorous: an inventory of what is installed, removal of what is not used, a monthly update window, and a staging copy so an update that breaks the site is discovered before Monday.
2. Form submissions stored in the site database
Every enquiry, every consent form, every job application, retained forever in a database on a public web server, frequently readable by any account with content-editing rights. Nobody decided this. It is the default behaviour of the plugin.
Route submissions to the system that should own them — the SIS, the HR system, a monitored mailbox — and set a retention period on what remains.
3. Shared and stale administrator logins
One “admin” account, the password in a shared document, still working for the communications officer who left in 2023 and for two people at the agency who built the site. Individual accounts, MFA where the platform supports it, and an account review each time somebody leaves.
4. No tested backup
The host takes snapshots, probably. Nobody has restored one. A school website is small enough that a full restore test takes under an hour, which makes never having done one difficult to justify.
5. Third-party scripts nobody inventoried
Analytics, chat widgets, video embeds, social feeds, font services, a heat-mapping trial from 2022. Each one executes code in your visitors' browsers with your school's name in the address bar, and each one is a supply chain you did not assess. Remove what is not earning its place and record what remains.
6. A privacy policy that does not describe the website
Written for the school, not the site, and typically silent on the analytics, the mailing list, the payment processor and the form retention. It is also where the transparency obligations most often go unmet — including, from December 2026, the requirement to disclose substantially automated decision-making that significantly affects individuals, which is worth checking against any enrolment or eligibility screening you run.
Photographs of students deserve their own paragraph
Consent is usually collected at enrolment, then never revisited, and it is rarely mapped to the individual images actually published. Two practical positions we would suggest.
First, treat withdrawal of consent as an operational process rather than a policy statement. If a family withdraws consent today, someone has to be able to find and remove the photographs — which requires knowing where they are. A site with fifteen years of news posts and no tagging cannot do this.
Second, strip location metadata on upload. Images taken on a phone can carry GPS coordinates, and a gallery of a primary school event is not the place for them. Most platforms can be configured to do this automatically; almost none do it by default.
Related, and moving: the OAIC is required to register a Children's Online Privacy Code by 10 December 2026. It binds online service providers rather than schools directly, but its drafting reaches services primarily concerned with children's activities — including platforms that share student photographs with parents. Expect the settings and defaults in your communication tools to change, and expect families to ask better questions.
The domain matters more than the site
The website is one thing sitting on your domain name. The domain itself is what people trust, and it is worth more to an attacker than the pages.
- SPF, DKIM and DMARC. Without an enforcing DMARC policy, anyone can send email that appears to come from your school. Parents receiving a convincing fee invoice from an address ending in your domain is a specific, repeatedly-used attack, and the defence is a DNS record.
- Registrar control. Who holds the domain registration, is it in the school's name, is registrar lock enabled, and is the renewal on a card that has not expired. Domains lapse more often than people think, generally over a holiday period.
- Certificates and subdomains. An automated renewal that has been failing silently, and the subdomains left behind by old projects — the 2019 musical, the capital campaign — still resolving to hosting nobody owns.
None of this is expensive. All of it needs somebody to be responsible for it, which brings us back to the ownership gap.
Accessibility belongs in the same conversation
Not security, but the same root cause and the same owner. Australian organisations providing information to the public have obligations under the Disability Discrimination Act, and the practical standard is WCAG 2.2 Level AA. For a school this is not abstract: enrolment information, newsletters and payment forms need to work for a parent using a screen reader or navigating by keyboard.
The common failures are text over photographs at insufficient contrast, PDF newsletters that are scanned images, form fields without labels, and video without captions. All are fixable, and all get harder the longer the site runs unattended. Our own accessibility statement sets out the standard we hold ourselves to.
Who should own the website
Our position is straightforward: the school's IT provider should own the platform, and the agency should own the design and the content. That means patching, backups, certificates, DNS, administrative accounts and monitoring sit inside the same managed IT support arrangement as everything else, with the same reporting and the same accountability.
Splitting it the other way — agency owns everything, IT sees none of it — is how a school ends up finding out about a defacement from a parent. It is also how an enrolment enquiry containing a child's health information sits in a plugin database for six years.
If your current arrangement leaves the website outside scope, that is worth raising at the next contract review. It is usually a small addition to the fee, and it closes the one gap that is visible from the internet.
Questions
Our website is hosted by the agency that built it. Is that a problem?
Not inherently, and plenty of agencies host well. What matters is whether the responsibilities are written down: who patches, on what cadence, who holds administrative access, what the backup and restore commitment is, and what happens out of hours.
If the hosting arrangement is a line item on an invoice with no service description behind it, you do not have a hosting agreement — you have a server.
Does a school website need a web application firewall?
It is worth having, and modern content delivery platforms include one cheaply. But it is second-order. A current CMS, no abandoned plugins, individual administrator accounts with MFA, and a tested backup remove considerably more risk, and a firewall in front of an unpatched site is a filter over a hole.
What about the separate portals — parent, alumni, enrolment?
Same questions, higher stakes, because those hold records rather than brochureware. Each should be on the register of systems holding student data, with a named owner, a renewal date and a note on whether the product has been assessed under Safer Technologies 4 Schools.
We set out how to build that register in the nine controls schools should expect.
How quickly can these be fixed?
DNS and email authentication records are a day's work. Administrator account cleanup and a plugin inventory are a week. Form routing and retention take longer because they need a decision about where the data should go instead, which is a school decision rather than a technical one.
Accessibility remediation is the long pole, and it is best folded into the next redesign rather than retrofitted.
Bring the website inside the fence
Very few providers will take the school website. We do — patching, DNS, certificates and administrative access managed and reported alongside everything else, by one accountable provider.
- Platform patched on a cadence. CMS, plugins and theme inventoried, with a staging copy so a bad update is found before Monday.
- Forms routed and retained properly. Enquiries into the system that should own them, with a retention period on whatever stays.
- The domain, defended. Enforcing DMARC so nobody invoices your parents from your own domain, plus registrar lock and certificate renewal.
- Administrative access reviewed. Individual accounts with MFA, and the agency’s access on the same register as everyone else’s.
- Backups you have restored. A school site is small enough to test properly, which makes never testing it hard to justify.
- Accessibility taken seriously. WCAG 2.2 Level AA is the standard we hold our own site to. We will hold yours to it too.
Bring the website inside the fence
Patching, backups, DNS, certificates and administrative access managed alongside the rest of your environment, reported the same way, with one provider accountable for all of it.