Over the course of two webinars, we broke down the foundational concepts of Datica’s evolved thinking of healthcare compliance on the public cloud. A handful of Daticans also presented at regional events sharing the same concepts. Combined, this is a summation of how healthcare developers should be thinking about compliance in the future.
First, understand compliance
The first webinar held on September 26th, titled “What Really Is Compliance?”, walked through the key concepts to understanding compliance in totality. Many of the ideas were pulled from Chapter 2 of our new book, which is available as a free PDF.
The webinar really is a crash course of everything you need to know to be on your way to becoming a compliance expert. But if we had to summarize the most prominent theme, it is the general confusion between Privacy, Security, and Compliance.
These three vocabulary terms are very, very different. A consistent mistake or misunderstanding we see is the assumption they are similar or, even worse, the same thing.
To highlight the differences, let’s turn to an Academy entry written by Travis breaking down the Maturity Model.
Regulated companies have rules to follow, like HIPAA Rule § 164.312. They use frameworks like HITRUST CSF to catalog controls mapped to the rules. Each control is then assessed on a scale of 1-5.
- Policies — You need to write down how you will control for the rule before you can do anything.
- Procedures — Defines the way the policy will be carried out.
- Implementation — Actually doing the procedure.
- Measurement — Understand how the implementation is performing.
- Management — Improve steps 1-4.
Policies and Procedures are the definitions of Privacy.
Implementation is the definition of Security.
Measurement and Management are the definitions of Compliance.
Basically, companies define what they will do, then they do it, then they verify that they are doing it appropriately. Compliance is verification.
Too often, we talk to companies who are doing good by doing security best practices, but they are unaware that those are just implementations that are security for the sake of security.
Regulated companies must have a program in place for Privacy, Security, and Compliance.
Check out the webinar for more discussion.
Second, understand we are in a post-cloud world
In the second webinar titled “How to build your own 3C program”, we delve into discussion abstraction, and what that means for compliance.
Essentially, most developers on top of public clouds like AWS, Azure, and Google Cloud, are selecting to use managed services provided by the cloud companies themselves. Setting up Postgres ourselves onto a VM isn’t fun, so it’s better to simply click a button and spin up a managed database like RDS, Cosmos DB, or GCP Cloud SQL.
In this post-cloud world, though, compliance is tricky. How developers map controls to managed service configuration is hard to understand.
Then put it together to form a program
Solving that problem is the idea Datica is putting forth called Complete Cloud Compliance. By “Complete”, we mean a program that can fully map a cloud environment to a control framework. This concept, we believe, is the key to healthcare developers getting a handle on their compliance obligations.
To start, a 3C program should inventory it’s “breadth”, meaning all the different pieces of technology it uses. In AWS terms, this means RDS is very different from S3 or from EKS.
After the roster is complete, then the program should enumerate all controls relevant to each respective technology piece. Yes, each one must go through the same mapping procedure.
Once mapped out, then the program keeps tabs as frequently as possible (e.g. daily) if that respective piece of technology, i.e. a managed database, is meeting all the controls necessary.
We will be continuously discussing what an ideal 3C program looks like. To learn more, sign up to be notified when our book is publicly available, which will be sold at cost and not for profit.