The detail that caught my attention in the reporting about St James’ Anglican School was how far back the information reportedly went. More than a decade.
Unauthorised access to a school's systems is serious enough. Finding that the information involved may reach back to families who left years ago adds another uncomfortable question. Why was so much historical information still available to take?
That needs a careful answer. Schools have reasons to retain records, including obligations that may outlast a student's enrolment. The age of a record does not establish that keeping it was wrong.
But for anyone responsible for customer information, it is a useful question to bring home.
What Has Actually Been Disclosed
In its incident update dated 14 September, St James’ Anglican School in Alkimos, Western Australia, says it identified unauthorised access to its computer systems. It says it acted immediately to contain the incident, secured its systems and is conducting a cybersecurity audit.
The school confirms that personal information relating to members of its community was involved. It says families have been notified and given protective advice, and that reporting to relevant authorities has commenced, including reporting to the Office of the Australian Information Commissioner within the required timeframe. Its investigation remains ongoing.
The historical detail comes from media reporting. PerthNow's NewsWire report of 15 September, citing The West Australian, describes copied information concerning current and former students enrolled since 2015. The categories reported include contact details, bank account details, medical records and student photographs.
Those details should not be read as confirmation that every category was accessed for every person. The school's public update, checked on 17 September, does not provide that breakdown or explain the method of entry. Nor does the reporting establish that particular records were kept beyond a legitimate retention period.
The wider lesson does not depend on making those claims.
Data Retention Is Part of Your Attack Surface
When I talk about reducing attack surface, the conversation usually starts with servers, applications, plugins, APIs, user accounts and exposed services. Which things can someone reach, and which ones still need to exist?
My Exchange and technical-debt article approached that through old systems nobody wants to touch. Retained information adds another dimension: the data attack surface.
An old customer record is not itself a software vulnerability. Keeping it does, however, change what someone could obtain if they get access. That makes retention part of the security discussion, rather than an administrative job to deal with when the disk fills up.
Imagine the same compromise against two otherwise identical customer databases. One contains a year of necessary information. The other contains fifteen years of customer histories, attachments and abandoned enquiries.
The initial access could be identical. The consequences could be very different. More former customers may be involved, more sensitive material may be exposed, and the business may have a much larger job working out who needs to be contacted. That is the blast radius: how far the damage from one compromise can extend.
The useful question for a business owner is fairly plain.
If this system were stolen tonight, how many years of customer information would be inside it?
“I'm not sure” is a reason to look. It is quite possible that nobody has checked since the system was installed.
Data minimisation asks whether you need to collect information in the first place. Retention asks how long you keep it once the legitimate purpose has passed. They are related decisions, but collecting something for a perfectly reasonable purpose does not settle its future indefinitely.
An enquiry needed a reply. A passport scan needed checking. A spreadsheet helped move customers into a new system. Each had a job. Someone still needs to decide when that job is finished.
One Website Enquiry Can Leave Several Copies
Consider a fairly ordinary business website. A visitor completes a contact form. The plugin saves the submission in the CMS database, emails a copy to the office and sends the details to a CRM. The website database is then backed up overnight.
One enquiry now exists in several places, before anyone exports a spreadsheet.
Five years later, the visitor never became a customer, but their message may still be sitting in the form plugin, a shared mailbox and the CRM. Rebuilding the visible website does not necessarily remove any of it. An abandoned WordPress database on the old hosting account can retain the same information again.
This is something I want understood when working on a website. Does the form need to store submissions? If it does, for how long? If email or the CRM is the working record, what purpose does the additional website copy serve?
Newsletter forms, account registrations and booking integrations deserve the same attention. Storage settings should be chosen deliberately. A plugin default is a fairly weak explanation for keeping someone's personal information for years.
Away from the website, the pattern is familiar: former customers retained indefinitely in a CRM, old support tickets with sensitive attachments, and exports left in a shared folder after a migration. The software may be maintained perfectly well while its contents quietly accumulate.
I would start with one of those systems and follow a sample record through it. Ask whoever uses it which copies they actually need, then check that answer against the records the business is required to keep. You can learn quite a lot before buying any new software.
Required Retention Needs a Reason and an End Point
Deleting everything old would be a poor response. Tax, employment, contractual and regulatory requirements can mean some records need to survive for specified periods. Relevant evidence may also need preserving during a dispute or investigation.
The OAIC's current APP 11 guidance connects security with retention. For entities covered by the Australian Privacy Principles, it requires reasonable steps to destroy or de-identify personal information no longer needed for a permitted purpose. Exceptions include Commonwealth records and information required to be retained under Australian law or a court or tribunal order.
That is not a universal deletion deadline. The applicable obligations and purpose need checking for the particular organisation and records. This is a security discussion, not legal advice; get the relevant advice before setting disposal periods where obligations are unclear.
For a small business, a useful retention rule names the records, the reason for keeping them, when the period starts, who is responsible and what happens when it ends. “Keep everything, just in case” leaves all of that unanswered.
Records that must remain also need sensible access restrictions. A former employee's required payroll records do not need to be available to everyone using the office file share. That connects directly with the least-privilege question in the SA Health article: who has a reason to open this particular information?
Cheap storage makes indefinite retention easy. It does not make it necessary.
The Backup Still Counts
Deleting a record from the live application may leave copies in backups, mailbox archives, exported databases, cloud snapshots or an old laptop. A retention policy needs to follow the information into those places too.
The OAIC's APP 11 guidance explicitly includes archived and backup copies in the destruction or de-identification obligation. Its guide to securing personal information also asks organisations to review backup retention and whether destruction is possible.
In practice, I would want the provider to explain when backup copies expire, who can access them and what happens if an older backup is restored. Otherwise, information removed from the live system can quietly return. Where individual deletion is technically constrained, document the limitation and agree an appropriate approach rather than assuming the copy no longer matters.
Recovery still needs to work. The aim is a deliberate lifecycle for live records, archives, backups and exports, with protection while each copy exists. Deleting useful investigation logs indiscriminately would create a different problem, as the Mathspace incident-response article explains.
The Same Question Applies at Home
A private household may have no formal retention process at all. Years of passport scans, tax documents, property records, medical correspondence and financial statements can accumulate across email, cloud storage and old device backups. Shared folders may still be accessible to former advisers or assistants.
Is this information still needed, and who still has access to it?
That question belongs in Solway Web Consulting's personalised cybersecurity consulting for private clients and high-net-worth individuals in Sydney. Required financial and legal records need appropriate care; a duplicate identity scan left in a travel folder after a completed trip deserves its own decision.
For a business, I would begin with the oldest customer record in one everyday system. Find out why it is there, which copies exist and who can reach them. Then give someone responsibility for deciding what stays and what can go.
If nobody can explain why a record is still there, “the storage was available” should not end the conversation.
Tags: security, small-business, private-client, australia