Compliance Demystified, Part 2

For healthtech companies, data privacy and security compliance is a crucial part of doing business, viewed among engineers and entrepreneurs with equal parts disdain and confusion. Given its complexity and its necessity, Loka has built out a compliance team to help fledgling startups and funded companies alike navigate HIPAA, SOC2 and other regulations expertly and efficiently. 

In Part 1 of this series, we met Daniela Medarska Tasevska, Loka’s Head of Compliance, who’s worked with Loka’s Healthcare and Life Sciences clients for almost six years, ensuring that the ongoing, complicated process of compliance stays on track, technically and logistically. In Part 2 Daniela explains the big-picture theories and strategies she applies to her work—and how she can put them to work for you. 

‍Jonathan: It seems like the tech world gives compliance the side-eye. Why is that? 

Daniela: I think most people don't like it because it slows them down. Usually developers are like, “Oh, I can't commit. Somebody needs to look at my code; I have to wait for approval before I release it to production.” Or “I can't get the access I need to go through the process.” So it does slow people down. Compliance requires discipline—you’re dealing with third-party risk management via system design controls and data retention policies. That’s why it’s mostly about following best practices and procedures derived from applicable regulatory standards, but in a structured and traceable manner.

But I find that compliance is very important. The rationale behind it is that you're making sure to not adversely affect your customers, your users. You’re the protector of their data through the processes you apply throughout development.

Also, I've learned how to balance between being the complete gatekeeper and then also understanding the developer’s perspective. You have to be creative. If something does go wrong, how do we mitigate it and how do we document what went wrong? And how do we actually make it right? 

Jonathan: You and the team seem to genuinely embrace the whole process of compliance. 

‍Daniela: It's a very rewarding feeling for us, because when you get a third party audit report, it's not a small thing. Especially for clients with whom we start from scratch. One major client didn't have anyone on the inside who could guide them through the requirements and how things needed to be done. Sometimes we work in a mixed team, where the client has their own team and then we would come in and we collaborate.

For instance, one of our early clients had a legal general counsel on staff who took care of the HR and legal issues, and I was working mostly on the dev side, with a head of DevOps. 

‍Jonathan: That sounds like a lot of pressure.

‍Daniela: Yeah! And then sitting in front of auditors is a process of its own, attesting to controls on the software development side. But then they also had to interview people at the client company, because within the company, the company must assign specific people to own specific controls. That’s also part of compliance—you need to designate who is responsible for which control, to make sure it’s designed and implemented. And the auditors interviewed these control owners as well. 

‍Jonathan: What is that conversation like with the auditors? Is it friendly? Is it contentious? 

‍Daniela: They try to find weaknesses. You need to be ready for them. You need to explain things to them very clearly, so they understand the system. You have to compensate for whatever controls you don't have with a complimentary control. Basically you need to convince them that you’re doing things in accordance with the established policies, procedures and best practices. 

‍Jonathan:  What has changed in the field since you started in 2019?

‍Daniela: I wouldn't say much has changed in the field, because the controls have always been there. But now with more and more cloud adoption, auditors are also more prepared to audit cloud environments versus the physical infrastructures or on-site infrastructures and servers that came before. My early experience required a lot more effort to explain why some controls are not as applicable to a cloud system as they would be to a physical infrastructure system. 

‍Jonathan: How is Loka poised to move forward with compliance management for future clients? 

‍Daniela: First off, we have a three-person compliance department in place. It’s me, plus an Advanced Compliance Specialist who focuses on audit readiness and develops procedures to enhance organizational compliance and operational, and a Senior Compliance Specialist who advises on strategies to enhance security and compliance through proactive governance and risk-based approaches.

Then we look at the foundation of each audit, which is hazard analysis or risk-management analysis. The core is evaluating your risks and implementing the controls. Some controls are mandatory, but some controls are risk-based. For example, if you have physical infrastructure—physical servers—you have to keep a log on who enters the building or who has access to this specific server room and how that access is managed. But if you have a cloud infrastructure, you don't necessarily have to have that control of logging every staff member  or every visitor to your office because you don't have anything physical in the office. You need to focus on the cloud environment and how you manage that.

Risk management is also for third-parties, so you have to document and evaluate every single third-party company you incorporate into the software. For example, Microsoft Azure is a third party. Your company is leveraging the cloud infrastructure. Same with AWS. People think they’re fine just by working with these companies, but you actually have to go and read through their third-party reports, see what you're using from them, make an evaluation document and have it approved. You have to assess if they qualify for exceptions when the auditors evaluate them. You're leveraging a cloud infrastructure, without the physical servers, and you don't necessarily need controls on your physical offices in terms of server room access. Azure or AWS actually hosts the data in physical data centers. And then they need to have all those controls that apply to data centers.

If something goes wrong with AWS or Microsoft Azure, which actually can and does happen, you need to show that you have actually evaluated them and measured the impact, then you accept the risk by using them as a third party.

‍Jonathan: Can you give an example? 

‍Daniela: A while back we were getting error logging or registrations that weren't working. It was because the length requirement of the tokens that we leveraged from a cloud solution was changed without any sort of documentation that was publicly referenceable, like release notes describing the changes in the system so that users are aware so they can adapt them to their own system. And we are their users.

I told our developers about this change, and they were joking that I make them do too much—provide release notes, make sure that other users of the platform we're developing are aware of what's changing in the code and the functionality. This provider didn't do any of this stuff in this specific case, and it had a huge impact. Which is why we should go the extra mile! We need to put in a lot of work when we're evaluating our vendors for the application. Even if we select one of the bigger clouds and put our trust in them, it’s a shared responsibility, and we should carefully evaluate cloud vendors for the specific use case of the product.

Once I explained my reasoning to the dev team, they got it. Even though I’m an intermediary between the devs, the auditors and the client, they understand that we need to function as a unified team. We do that more and more with each new project we take on, and that’s the main reason we’re so efficient in the compliance process.  

‍Jonathan: That seems like an important lesson to learn. 

‍Daniela: Yeah! I learned that the auditors actually want you to dive deep into the big vendors because they know that startups use AWS or Azure and just don’t worry about it. But you have to be careful. You have to evaluate the cloud provider properly for your use case and see what you can use, how you can remediate things that are not available as plug-and-play. Maybe you can develop something of your own. For example, if this service doesn’t provide long-term backups out of the box and you're using it for a healthcare application, you need to come up with your own custom backup solution.

 Even when you sign up for cloud services and they say they’re HIPAA or SOC2 compliant, it's always a shared-responsibility model. That's a big thing in the cloud world. They’ll let you configure but you have to do it yourself. You know, it's not there by default. That’s where our expertise in the field becomes so important. 

‍Read Part 1, in which Daniela went into meticulous detail around the compliance process for a major healthtech client.

‍If you or your company is ready to engage with Loka’s compliance experts and/or need a proven team to build the next great healthtech innovation, get in touch with emily@loka.com