Blog

Compliance Demystified, Part 1

Is your Healthcare or Life Sciences company starting its compliance journey? Get a clear view of process that’s both opaque and essential with Loka’s veteran Head of Compliance.

Compliance Demystified, Part 1

Listen to this article:

0:00
0:00

In a tech-biz world that prizes autonomy and innovates at warp speed, privacy and security compliance regulations are as welcome as a convict’s ball and chain. But compliance provides the public with necessary safeguards and corporate accountability. And like gravity, it’s not just a good idea, it’s the law. 

Loka has made compliance one of our core competencies. Where others see roadblocks to expedience and tangles of external oversight, we see opportunities to help our clients streamline and differentiate. The team that brings compliant solutions for our customers comprises experienced Biz Dev leads, DevOps engineers, backend engineers, risk-assessment specialists and information security specialists. 

In other words, Loka’s development team works hand in hand with our compliance team. On both sides of the equation, our compliance experts can bring companies from standstill to success with fewer headaches. Every touchpoint is handled under one roof, no handoff necessary. These efficiencies lead to faster launches. 

Conducting Loka’s compliance orchestra is Daniela Medarska Tasevska, Head of Compliance. In nearly six years at the company, she has combined her early work as a translator with her experience in tech, adding up to a unique ability: She can speak to the three different compliance stakeholders–-the client, the engineering team and the external auditors—in the language each understands best. Her fluency in this realm is mind-boggling, really. 

Daniela’s team has shepherded several healthtech and life science clients through the compliance journey. In 2023 they worked with a major healthcare client—we’re anonymizing the company for the sake of privacy—to establish HIPAA and SOC2 compliance for their new cancer care technology. In Part 1 of our conversation, Daniela pulls back the curtain on Loka’s work with this client. It’s rare to get a deep look at this rather opaque practice, and her perspective and insight are crucial for healthtech founders, CEOs and engineers alike. Dig in. 

Jonathan: Tell me about Loka’s relationship to this particular client. How did it begin and what services did Loka provide them?

Daniela: Their cancer care platform includes one website application for clinicians, one for administrators, one mobile application for patients and one for clinicians as well. They all operate within the healthcare industry, so by default, they need to be compliant first with HIPAA and then SOC2.

Both HIPAA and SOC2 are standards established to verify safety, security, confidentiality, privacy, availability and information integrity. HIPAA pertains specifically to medical information for individuals and institutions while SOC2 applies to confidential information that needs to be protected. SOC2 is more tangible–there are third-party organizations that companies can hire to conduct an assessment and evaluation of their controls and provide a report that the controls are functioning and then map them to SOC2 criteria. 

The client considered compliance from the very beginning of the product development cycle. Which is smart, because companies that say it’s too expensive and put it off until later learn that if you wait to consider compliance, you’ll have to make a bunch of changes and at that point it’s far more complicated and even more expensive. But even then it’s still feasible. And we can—and do—arrive and contribute at any stage. 

So from the beginning we set up the controls that pertain to compliance—and there are a lot of aspects to compliance, to put it mildly. How change management is handled, including termination and change of access. Risk management. Security controls testing and remediation. Backups and disaster recovery. Data handling and retention policies. Different risk management and security controls for data that’s shared with external parties for debugging purposes or for logging purposes. How the database is connected and so on and so on. 

This entire bundle of controls must be set so that they can pass a third-party audit report. This set of compliance standards comprises the criteria for trusting this company, so a potential customer party can trust the company and its software. They can be assured that when they input patient data into the software and track and monitor patients, that [our client] is handling the data in a safe and secure manner. 

Jonathan: How long does that process take?

Daniela: The entire development process for this client, from planning to production to first customers, was just less than two years. But the reports with third-party auditors began in July of 2023, about four months before launch.

Companies heading toward an adverse opinion will often pull out of the report altogether and go back and retool their systems and re-do their audit. 

I was engaged on compliance for this client full time. My role was part of the statement of work. They included me as they would include the developer to manage compliance issues, handling policies and procedures, work instructions, risk assessments, designing technical controls. We completed the assessment by August and then we had the audit field work at the end of September, and then we did the initial release to the production environment, even though there were no actual users. But we needed to prepare the environment so that the auditors could see that the controls are in place.

Jonathan: Who’s the third-party auditor?

Daniela: It's a private company that is authorized to conduct SOC2 audits, and in this case they conducted HIPAA controls mapping as well. Public entities in the US usually don't conduct voluntary audits. You might get audited if an incident occurs, like a data breach and investigate how it happened. Or they can select companies randomly. But in order to receive a voluntary report, it has to be a private third party company that's authorized to issue this type of SOC2 report and map it to HIPAA criteria as well.

This particular client chose Moss Adams, but there are many companies that do compliance audits, including the Big Four accounting firms: Ernst & Young, Deloitte, PricewaterhouseCoopers and KPMG. Moss Adams is smaller and their main area of focus is independent audits like SOC2 and also SOC1 for publicly traded financial institutions. Loka has often also worked with A-Lign and other audit firms. 

Jonathan: Is the result of that audit a pass/fail, or is there a grading system? Will they report on the problems or inconsistencies that they see, and does Loka get to see the entire report? 

Daniela: It’s a very inclusive report based on the controls that are selected that fall under the criteria they test to determine if they’ve been properly designed and implemented. And then they report “exceptions noted” or “no exceptions noted,” and that's all visible in the report. 

Along with that, there are three grades. The best one you can get is an unmodified opinion, which means that the controls that are selected are appropriate and they function as intended. 

Then there’s a modified opinion. If they find something serious—change management and administrator access are the biggest ones—and if those were found as nonfunctioning in the criteria they're testing they would have a modified opinion. 

An adverse opinion is where they can’t conclude anything because the submitting company hasn’t provided the auditors with any evidence of what they’re requesting. Nobody wants to get an adverse opinion.

Jonathan: And even if you meet the designated criteria and achieve positive grades, this process isn’t necessarily complete. It’s ongoing for the life of the company or the product. 

Daniela: Exactly. Standard practice for SOC2 is first you do Type 1. So as the compliance manager for my company, I know where we’re strong and where we’re not and march towards having all the controls we need for the Type 1, by the defined as-of date. After Type 1 is done, the next day the Type 2 period starts, and it goes on for a minimum of three months, six months or a year. Most companies opt for a year-long period because nobody wants to be audited every three months or six months. 

Then within Type 2 periods, say it’s from January 1 to December 31, the auditors come in and basically select whatever evidence they need to see.

Say we do daily backups, and we have alarms for failed backups. They're going to ask for evidence randomly, say from June 15 to September 12, to see that the backup was actually completed.

And if it failed, you have to then show that the alarm was triggered and that you remediated it. 

Or let’s talk about changes to production. This is the biggest issue, typically—the controls around every change to production have to be approved and appropriate. Then they say for this release to production we need to see what went into production from the system. There has to be system evidence that it was from GitHub or from JIRA. Then I look into how it was approved. Did the developer commit the code before it was approved by a code owner? Can we bypass this control? And the auditor asks for the related ticket or a change. I give them all the evidence that it was tested, that it passed, if there was a bug that the bug was reported so it’s remediated for the next release. And so on. 

The change management process is part of every single compliance you can get. It's not negotiable. Even with the FDA, you have to track how control changes were managed in the software, as part of the system design process

Jonathan: By change management are we talking about regulating access to information between outgoing and incoming employees? And also any changes to the production chain, suppliers or anyone else that has access to private information? This seems like the primary trouble area for compliance.

Daniela: Right. The rationale behind change management to the production system that is used by customers is to ensure that you're not introducing something before it was evaluated in a staging environment. It’s been assessed for risk and impact, for how we would inform the client, the customers that the change happens, so they know how they're using the system. 

Stay tuned for Part 2, which will address Daniela’s big-picture theories and strategies around compliance work. 

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.

Loka's syndication policy

Free and Easy

Put simply, we encourage free syndication. If you’re interested in sharing, posting or Tweeting our full articles, or even just a snippet, just reach out to medium@loka.com. We also ask that you attribute Loka, Inc. as the original source. And if you post on the web, please link back to the original content on Loka.com. Pretty straight forward stuff. And a good deal, right? Free content for a link back.

If you want to collaborate on something or have another idea for content, just email me. We’d love to join forces!