It started quietly on a Thursday evening. A mid-sized private hospital, known for its efficient outpatient services, reported nothing unusual. Systems were running, patients were being attended to, and bills were being issued. But somewhere outside the hospital walls, a compressed file named “clients full 2024.zip” was uploaded to a hidden marketplace. Inside it were over 38,000 patient records, names, diagnoses, HIV status, billing histories, phone numbers, and next of kin priced modestly, paid for in cryptocurrency, and downloaded within hours. The hospital discovered the breach three weeks later, not through its systems but through a patient.
How the breach actually happened
Imagine you are sitting with me in a dim IT room. Across from us is a slightly nervous systems administrator, young, sharp, and overworked. He manages everything from the electronic medical records system to printer troubleshooting. He did not hack anything, but connected convenience to exposure.
Here is what we found. First, remote access without boundaries. The hospital used a basic remote desktop setup to allow off-site access to the medical records system, no VPN, no IP restrictions, just a username and password. Second, weak authentication discipline. Password reuse was common, one set of credentials worked across billing, EMR, and email systems. Third, exposed database backups. Automated backups were stored on a network-attached storage device, accessible internally without encryption no segmentation. Fourth, no monitoring of outbound traffic, and large data transfers could leave the network without triggering alerts.
I asked the Summit Consulting’s iShield360 security team to simulate this. “Assume you are an outsider. What is the simplest way in?” Within 20 minutes, they identified three entry points without advanced tools, but just using simple logic.
The moment of compromise
The breach did not begin with code, but a message. Suspect 1, a tall, well-dressed individual who understood hospital workflows, sent a phishing email disguised as a supplier invoice update that looked ordinary, with familiar language and correct logos. The recipient, a records officer with limited technical awareness, clicked the attachment.
Here is what happened next. First, credential harvesting. The attachment led to a fake login page identical to the hospital’s email portal, where credentials were entered and captured. Second, lateral access. With those credentials, the attacker accessed the email system, and then reused the same credentials to log into the EMR system. Third, privilege escalation by observation. Instead of forcing access, the attacker studied internal email threads to identify higher-privileged users and reset pathways. Fourth, silent data staging. Over several days, database backups were copied in small segments to avoid detection. We reconstructed the timeline. The attacker was inside the system for 11 days. The hospital lacked real-time threat intelligence. Even once inside, there were no warning signs of breach.
How the data left the hospital
Because the exit path is always simpler than expected, this phase is the most worrying.
Suspect 2, a slightly overweight network technician at a third-party vendor, had occasional access to the hospital’s network for maintenance. We found that, first, there was no strict vendor access control. Shared credentials were used for multiple technicians, the file compression tools were installed on the server without restriction, the outbound traffic was not filtered, data could be transferred through common ports without inspection, and data exfiltration was disguised as routine backup synchronization.
I asked the leadership team, ” Can you tell me, right now, if someone exported your entire patient database yesterday?” No one could answer with certainty. That silence is your exposure.
How it was finally noticed
Not by a firewall or an intrusion detection system, but by a patient! This is telling. Waiting for the victim to notify you of a breach is a lackadaisical security posture, to say the least. A cautious middle-aged individual, received a call referencing a medical condition he had only discussed with his doctor. The caller attempted to sell him a specialized treatment package. That detail; too precise and private, triggered suspicion.
Internal escalation was slow. The complaint was initially treated as a scam, not a breach. Then multiple similar complaints emerged over a week. An internal audit review noticed unusual login patterns and access at odd hours from unfamiliar IP addresses, and a forensic review revealed large data movements from the backup server. By then, the data had already been sold.
The investigation: reconstructing the breach
We approached it as a legal and forensic exercise, not just what happened, but what can be proven.
First, log preservation. Many logs had already been overwritten so we had to reconstruct events using partial data timestamps, access trails, and system artifacts.
Second, we had device correlation where we matched login sessions to specific devices and IP addresses, identifying anomalies in geography and timing.
Third, email forensics. The phishing email was traced through header analysis, revealing routing paths and spoofed domains.
Fourth, chain of custody. Every piece of evidence was documented carefully to withstand scrutiny in court. Let me be clear, if you cannot prove it, it did not happen. That is the standard.
Legal reality: where institutions get exposed
Now we move into the territory most executives avoid. The law does not care about your intentions, but your duty. Under Uganda’s Data Protection and Privacy Act, 2019, a data controller must ensure appropriate security safeguards for personal data. Health data is classified as sensitive personal data. The threshold is higher.
From recent High Court reasoning in data-related disputes, even where names are anonymized, the ability to re-identify individuals through combined data points creates liability. Courts have emphasized the obligation to implement proactive, not reactive, controls.
Failure to secure data is not excused by lack of expertise, you are expected to know or to seek expertise. Outsourcing does not transfer responsibility. If a vendor causes the breach, you remain accountable. Delayed reporting increases exposure. The longer you take to act, the more damage and liability you accumulate. Inadequate documentation weakens your defence. If you cannot demonstrate what controls existed, you are assumed not to have them.
In one recent judgment, the court focused not on the sophistication of the attack, but on the simplicity of the controls that were missing. That is where cases are won or lost.
What most hospitals are not seeing
Because the real risk is not the breach you see, it is the one you do not recognize. You must understand that medical data has long-term value. Unlike credit card data, it does not expire. It can be used for years, for fraud, blackmail, and discrimination. Insiders are often the bridge, not always malicious, sometimes careless, or pressured. Small anomalies matter. A single unusual login, repeated IP. These are early signals your systems are telling a story every day, you are simply not listening.
We simulated with the hospital team, planted a controlled anomaly, and an unusual data export. It went unnoticed for 48 hours. That is not a system failure but a culture failure. The breach was contained, access points were closed, credentials reset, and systems hardened. The data was gone. Once data enters that marketplace, you do not retrieve it but manage consequences. The hospital faced regulatory scrutiny, reputational damage, and potential civil claims. The deeper issue remained they had built a system for efficiency, not for resilience.
What you must do next
If you are running a hospital today, you are not just a healthcare provider but also a data custodian of the most intimate information a human being can share. Act like it. Start by conducting a full data mapping exercise. Know exactly what data you hold, where it sits, and who can access it. Then, implement strict access controls, no shared credentials, no unnecessary privileges, and encrypt sensitive data at rest and in transit, not as an option but as a baseline. Monitor continuously, not weekly reviews, but real-time visibility into unusual activity. Also train your staff relentlessly. Not once a year but continuously, with practical simulations.
An exercise for you:
Tomorrow morning, send a simulated phishing email to your staff. Do not warn them. Measure who clicks, then train them because technology does not fail first, people do. There is a quiet assumption in many institutions that they are too small to be targeted, which is wrong. You are not being targeted because you are big, it is because you are accessible.
And in the world of digital forensics and AI, the question is never whether a breach will happen. It is whether you will see it early enough to matter.
Copyright Institute of Forensics & ICT Security, 2026. All rights reserved.
