HealthCare IT Startups are sexy. There’s literally hundreds of companies entering the space, lots of investment capital, and a general consensus that the time is ripe for disruption. Not all of these new entrants are operating at the same level, and before you decide to give their new product or service a swing, you may want to review my checklist, artfully entitled, “The top eight questions to ask a startup about compliance and data security”.
Do you make use of business associates? Who are they, and what’s their pedigree?
My mother always told me, “you are as good as the company you keep”, and it’s likely that any startup you’re evaluating stores or manipulates patient data using somebody else’s services. Make sure you know who these people are, and whether they have adequate security and agreements for the use that they are providing.
Have you ever been victim of, or been involved any litigation relating to a breach or data security incident?
This is a hard question to start a relationship with, but it’s a question you need to ask, and get a response to, in writing. By definition breaches involve 500 or more patients, whereas incidents may be as simple as sending one patient out to the wrong recipient. Ask for specifics on all such situations, and review the response carefully.
Explain your approach to encryption.
Encryption at rest is the minimum federal standard, and while it does prevent stealing entire harddrives, it does little to prevent someone using a system admin account to dump the database to file in cleartext. Ask if key protected health information can be encrypted at application level, and if not, ask what additional safeguards are in place.
Who’s in charge of Privacy and Security?
Organizations under HIPAA must have a Chief Privacy Officer, and a HIPAA security officer in place. Ask for the work history of these individuals, and make sure they have an appropriate background and/or credentials for the role they are performing. Also, ensure that your CPO has reporting relationships to both the CEO and the board to ensure there is some measure of independence in play.
Are there dedicated security personnel?
Having a CPO and security officer is a great start, but to be effective they need a team of people watching the environment each day. It doesn’t have to be a large team. In fact, if continuous security monitoring is in place, then a few key people, who are looking for anomalies the software might miss, is enough to get the job done. Human intelligence is still more flexible than machines, and our ability to recognize patterns of abnormal behaviour makes all the difference.
Is there a security training program?
The vast majority of breaches occur because people don’t follow basic security practices. A well defined, continuous, security program can do a lot to patch the holes, and will at the very least ensure that staff are thinking about data security. Programs can be informal or formal, just make sure there is a documented history that proves the training actually happens.
Do you carry cyber security insurance? How much?
Breaches, like motor vehicle accidents, don’t just happen to the poorly prepared. Anthem, for example, did a pretty decent job of securing their environment, but were let down by a couple of smaller issues. Make sure anyone handling patient data on your behalf has a robust cyber security insurance posture. That way you won’t be left in the lurch.
What’s your RTO and RPO?
If you’re not in IT, RTO and RPO are probably foreign acronyms that sound really hard. They’re actually pretty easy in practice.
RTO stands for Recovery Time Objective – the amount of time it will take to return to normal operations in the event of a disaster or other disrupting event. An RTO of one day can mean that there will be no service for one day in the event of a disaster or disruption.
RPO stands for Recovery Point Objective – the amount of time to restore data to the state it was in before a disaster or data loss even occurred. If the RPO is 15 minutes, you may need to re-enter 15 minutes worth of transactions in the event of a failure.
Ideally you want the RPO and RTO to be very small numbers, but the amount you’re willing to pay, and the downtime you’re able to sustain before your customers complain, will dictate what’s possible. Not all systems need zero downtime in practice.
This list is by no means exhaustive, but it’s a great start to evaluating the security posture of a third party, and will quickly separate the wheat from the chaff.