In December 2025, the University of Sydney disclosed a cyber incident that offers a clear warning to organisations of all sizes: non‑production systems are not low‑risk systems.
As like many the breach did not originate in a live student hack or HR platform. Instead, these attackers accessed an online IT code library used for software development, where historical data extracts had been retained for testing purposes. These files contained historical personal information relating to staff, affiliates, alumni and students. Some of this sensitive data dating back more than a decade. The repository was compromised, data was accessed and downloaded all before the issue was detected and contained.
Although this particular incident involved a large institution, the underlying failure mode is common in small and mid‑sized businesses (SMBs). Development and test environments quietly accumulating real data, often left and forgotten. Regularly operate outside the same governance and scrutiny as production systems.
What happened (high‑level)
As per the University’s incident notification – unauthorised access was detected in one of its online code libraries in mid December 2025. The platform was intended for code storage and development, but it also contained historical data files used during earlier development and testing work. These real datasets contained personal information associated with current and former staff and affiliates, as well as alumni and students from earlier periods.
Once alerted, the University took immediate containment steps. They blocked access to the repository, purged all the identified datasets, commenced an investigation, notified relevant authorities and began notifying all the affected individuals. The public report confirms the breach was limited to the development repository and that there was no evidence of disclosure that the data had been published or misused.
Why this matters for Sydney SMBs
Our “She be right mate” attitude for smaller organisations to mentally downgrade the risk of development systems: “It’s not production.” is common amongst us all. However, the University of Sydney breach shows why that assumption is dangerous.
From a risk perspective, dev/test environments often have three compounding weaknesses:
- Real data without real controls
Historical exports are copied into repositories for testing, file shares or test databases “temporarily added” and never removed. Over time, these datasets become invisible or forgotten to data owners and compliance processes. Yet they remain fully accessible if the system is compromised or future exploits of the underlying system found. - Broader access by design
Development platforms typically prioritise collaboration, speed and cost restraints. Access is granted to multiple developers, contractors or external partners, typically with fewer restrictions than production systems. If credentials are weak, compromised or permissions are misconfigured, attackers will soon be along and can move quickly. - Lower monitoring and audit coverage
Security logging, alerting and review processes are only installed and focused on production environments. Non‑production platforms may not receive the same level of monitoring, allowing unauthorised access to persist long enough for data exfiltration.
The result is a familiar pattern: the data you least remember becomes the data you lose first.
“Non‑production” does not mean “non‑sensitive”
One of the clearest lessons from this cyber security incident is that data classification must follow the data, not the environment.
In this case, the exposed data was described as historical extracts used for testing at the time the code was developed. Unfortunately, even though the data was not current, it still included names, contact details and other personal information that can be reused for Email phishing, social media exploitation, impersonation or identity‑based fraud years later, this was emphasised by multiple security commentators notes in their analysis of the breach.
For SMBs, the takeaway is simple:
If personal or sensitive data exists anywhere in your environment, it must be governed everywhere.
Practical controls SMBs must apply now
The University’s experience maps directly to practical and achievable controls that SMBs can implement without the enterprise scale budgets.
1. Data minimisation in dev and test environments
With AI deeply set in our new environments, there is no excuse for development and testing environments to have “live” data sets. AI can quickly produce synthetic, anonymised or tokenised data for this purpose. If real data is temporarily required, it needs to be approved, documented and time‑limited, with explicit destruction once testing is complete. Retained “just in case” datasets are a liability.
2. Clear governance over what data is allowed in dev
Many organisations have multiple policies covering privacy, rules and security of production systems but no explicit rules, privacy or security for non‑production environments. Define what data types are permitted in dev/test repositories and enforce those rules through code reviews, repository scanning and scheduled periodic audits.
3. Strong access control and least privilege
Development platforms are not to be exempt from access reviews. Limit access to only those who genuinely need it, remove stale accounts promptly and ensure authentication controls are consistent with the sensitivity of the data that could be exposed. Multi Factor Authentication (MFA) and data encryption should be the minimal standard of any internet facing application or application with ANY sensitive data.
4. Secrets and repository hygiene
Code libraries should not double as data stores. Perform regular scans for embedded data files, credentials and secrets to identify risks before attackers do. Historical artefacts must be proactively cleaned, not passively forgotten.
5. Treat all dev systems as breach capable systems
Incident response planning should assume that non‑production platforms will be compromised. Logging, alerting and response playbooks should include all your development environments, not just polished, core business systems.
The Broader Lesson
The University of Sydney breach was not about a sophisticated zero‑day attack on a critical system. It was about legacy data left, in the wrong place, for too long, under the wrong assumptions.
For Sydney SMBs, this is both a warning and an opportunity to act. The controls needed to reduce this risk – data minimisation, access discipline and governance clarity – are well understood and achievable.
What is required is a mindset shift: development and test environments are part of your attack surface, and they deserve the same attention as production.
Ignoring them does not make them safer. It just makes the surprise more likely. Stop hoarding old platforms, test environment and legacy systems, remove, destroy or turn them off today.
