Of course, you will be living in a kicked anthill for days. The trick is to make sure that all the scurrying around is not just mindless motion, but actually protects the organization by:
- Meeting legal responsibilities,
- Protecting the organization’s reputation to the extent possible,
- Immediately stopping intrusions and mitigating the damages,
- Finding out how the breach occurred,
- Repairing the vulnerabilities, and,
- Making sure your risk assessment, security plans, and operating procedures reflect any necessary changes.
Meeting Legal Responsibilities
The Health Insurance Portability and Accountability Act (HIPAA) breach notification rule essentially requires entities that have had a breach to inform the Department of Health and Human Services (HHS), the affected individuals, and in some cases, the media, within 60 days. There are exceptions, but these are best handled by lawyers. Since there are stiff penalties for not reporting security breaches that should have been reported, but no penalties for reporting security breaches that did not need to be reported, it’s best to err on the side of caution.
Protecting the Organization’s Reputation To The Extent Possible
It is unfortunately not true that there is no such thing as bad publicity. Your organization’s reputation is going to take at least a small hit. Perhaps the worst example possible is the behavior of Experian, a credit reporting service, in response to its massive data breach. They failed to report it, they did not notify affected individuals, they dribbled out information, repeatedly contradicted the information they dribbled out, and immediately tried to monetize the breach by selling protective services to those affected. Everything that could have been done wrong in the early phase was done wrong. Apply the Golden Rule here. Look at things from the perspective of those whose data has been exposed. What would they want to be done? Figure that out, and at least pledge to do that much.
Immediately Stopping Intrusions and Mitigating the Damages
The first step is to get the affected devices off the network and isolated, so they can no longer serve as points of entry. The next step is to check the system and audit logs to identify the source of the penetration. Thirdly, it’s important to force an immediate password change for everyone, if passwords are still being used. Of course, if the source of the breach is the medical director’s smartphone, which was left in an Uber, the only way this data can be remotely deleted is for companies using a Mobile Device Management plan.
Finding Out How The Breach Occurred
In some cases (see above), the source of the data breach will be glaringly obvious. In others, it may be very hard to find. Your own IT staff may be too close to the problem to see it. In those cases, bringing in a computer forensics firm may be useful or even essential. Determining the root cause of the breach, once the details are known, requires thinking through policies and procedures. You’ll need the skills of a good detective, combined with those of an excellent IT specialist.
As illustrated above, there is always a tradeoff between ease of access and security of access. Does everyone really need remote access to patient records at all times, using devices that can be lost or stolen? Depending on the organization and how it delivers services, the answer may be yes or no. But if it is “no,” serious consideration should be given to limiting remote access. Of course, if you’re working with a managed IT services provider, they can set you up with a Mobile Device Management plan so that any lost or stolen devices can be remotely wiped of all data.
Repairing The Vulnerabilities
Once the source of the breach and the root cause have been identified, the vulnerabilities need to be repaired. The issue of 24/7 remote access from stealable devices is one example. Use of cloud services is another. Having data in the cloud is wonderful. Having unprotected data in the cloud is not. Several recent breaches have occurred because, even though access to the cloud from an organization’s network was protected, the server in the cloud itself was totally open – no password in place. Granted, this defies imagination, but it has happened more than once.
If something like this has occurred, every policy and procedure that relates to the root cause needs to be looked at. This has to be done slowly and carefully; it is not an exercise to be carried out in panic mode. In most cases, this type of error will not occur if you’re working with a managed IT services provider. They have too many checks and balances in place to allow such a glaring mistake.
It most often happens to companies who employ poorly trained in-house IT staff who spend all day playing games and talking with friends on social media. Again, though this scenario is shocking, it is occurring across the nation with more frequency. Don’t let your CEO find out the hard way that his in-house IT people actually don’t have much network and computer experience. Their last job was serving up hamburgers at a local fast-food chain.
Making Sure Your Risk Assessment, Security Plans, And Operating Procedures Reflect Any Necessary Changes
Having a credible, annually updated risk assessment is part of the HIPAA Security Rule. A breach presents an opportunity here. If it occurred, your risk assessment either did not identify it or did not prioritize it; your security plan did not encompass it; your operating procedures ignored it, or some combination of the above occurred. The breach gives you a chance to rethink the security assessment, the security plan, and your operating procedures. Take advantage of it.
A data breach is painful, but it is also an opportunity for health care organizations to assess their security approaches and make improvements. Never waste a crisis. If you have onsite IT staff members, they may need more thorough training in security protocols. In fact, this is probably a good time to ask a local managed IT services provider to come out and hold security awareness classes for your entire workforce.