Day 30 — I got this!

I don’t know what I’m doing.

Life of a startup founder

I can always tell what kind of day I had by the number of tabs open in my browser and the state of my desk. Well…here they are:

Eek.

I started out today hoping to make a big dent in my HIPAA administrative controls but instead spent most of the day going in circles as I tried to figure out exactly what I needed to do.

Today’s Problem to Solve: Vendor Management

When I started today’s HIPAA activities, I was actually excited. I’ve been making good progress on our data privacy controls and I figured knocking vendor management off the list would be an easy but good chunk of work.

Unfortunately I was right on only 1 of those.

Why It Matters

To establish good data security, we need good security practices for any data we store, transmit, or process. This is done through our technical controls (e.g., our AWS configuration, encrypting data, etc.).

But good data security is about more than just our own internal technical controls — because 3rd parties handle data on our behalf, we also need to make sure they are following good security practices (and get proof).

Who Exactly is a Vendor?

This simple question sent me down several rabbit holes. At first, I figured any 3rd party tool that we use should be included. But then as the list grew, I figured I only needed software that stored high-risk data like AWS. But after thinking through it more, I took the more conservative approach and went back to the all-vendor approach since each one brings its own unique risks if there was a data breach.

Here are a few examples:

• AWS: Manage our back-end services. Huge risk since they’ll be storing lots of PHI.
• Typeform: Used to collect basic contact information. Not as high-risk as AWS, but still store customer contact information, so we need to be sure its secure.
• Google: Store tons of our internal documents through Drive, plus email. Definitely a high-risk and we’ll need a BAA with them.
• Dropbox: See Google, just no PHI so no BAA.
• Github: Store all of our source code. While they’re not storing PHI, definitely a key vendor with some risk.
• LastPass: All of our system passwords. Definitely a high risk vendor.
• …

What I learned

These are all pretty well-established companies, so I actually thought this exercise wouldn’t be too bad. Of course all of them have established good security controls and of course they’ll share the proof with us.

It’s good to have goals.

As part of our vendor evaluation, I need to:

1. classify the risk for each vendor
2. get signed agreements
3. get proof of ISO:27001 / SOC 2 Type 2 reports (just for high-risk vendors, probably?)

While most likely all of them have good data security practices, finding evidence isn’t so easy:

• Each vendor has their own process for sharing their data security practices. AWS is quite public while Dropbox is quite hidden.
• Some vendors like Hubspot make it quite easy to show proof of compliance, while others charge you a fee for the privilege to this proof (Dropbox, Typeform, Github).
• When it’s all said and done, this is all about risk management. Each vendor brings its own category of risk, and so I need to define a procedure that allows me to evaluate each with this in mind. All these vendors may have a low likelihood of a data breach, but the potential impact varies by vendor depending on the data they store.

Where I landed

I ended up listing out all my potential vendors and laying out the type of data they store. From there, I generate a risk score (the more sensitive the data they store, the higher the potential impact and thus risk level).

From there, I need to dig into each individually to find evidence of good data security practices. Here’s what I have waiting for me tomorrow:

My in-progress vendor assessment

What’s Next?

I’ve started rounding the curve toward “I got this”.

Until tomorrow.