Alicante’s Recovery Began With Shutdown
The University of Alicante’s 6 July statement described suspected ransomware detected on 2 July. Responders stopped shared services, including UACloud, remote access and electronic administration. The university reported essential-service restoration within 24 hours, unaffected enrolment and no evidence of leaked or compromised sensitive data. Those were its findings at the time, not an independent forensic conclusion.
Retrospective coverage: first published 14 October 2026 with an 8 July dateline. The later source-date updates below were added on 14 October. The illustration depicts the recovery sequence, not the initial state.
Update: 9 July service restoration
In its 9 July update, Alicante said most essential services had returned, prioritised by academic and administrative need. It credited containment with preventing propagation, encryption and sensitive-data access. Restored services remained under reinforced monitoring; secondary recovery work was continuing.
Update: 23 July recovery assessment
The 23 July account put recovery, including work nearing completion, at about 95% of services. It did not establish that all of that 95% was already operational. The university placed the intrusion on one of three nodes hosting about 80 virtual servers, affecting 20 applications or configurations, but not user data. Applications were isolated, analysed and monitored before restoration.
The university attributed the attack to an organised international group; it did not name one. The public accounts did not establish an initial access method or a specific ransom demand.
Restore the work that matters, not just the machines
An institution’s recovery plan should start with the tasks people must complete. A server inventory cannot decide whether enrolment, teaching, payroll or statutory administration comes first. That decision needs business owners and a dependency map that responders can use under pressure.
For each critical workflow, record its required applications, identities, storage and communications. Test what happens when a shared component is isolated. An alternative route is only useful if the people who need it can find it and use it safely.
A restored service still needs an acceptance test
- Keep the restoration decision separate from the decision to reconnect a service.
- State which checks the recovery team must pass before normal access returns.
- Record known limitations and the person responsible for unresolved work.
- Give users a clear distinction between precautionary downtime and confirmed impact.
- Measure whether the important workflow works, rather than whether its virtual machine merely starts.
The practical lesson is not that another institution should copy every shutdown decision. It is to make the dependencies, service priorities and acceptance evidence explicit before an emergency forces that work into a hurried conversation.
