GET /compliance & Why You Should Care

By David Honan in GET/technical, API Industry Trends Posted Mar 9, 2018

I’ve heard the phrase “compliance is hard” thrown around here lately at Cloud Elements and yes, it is hard - I think that we can all agree on that. In fact, that exact phrase was used quite often by the compliance team here as they described the process behind us recently becoming SOC 2 and ISO 27001 certified.

But wait, we also have a slack channel titled Compliance is fun. So which is it?

soc-logo_transparent.pngAs a former member of the Sales Engineering team, I was often asked by our prospects about compliance; which certifications do we already have and which we were pursuing. At first when these questions came up, my pulse would increase, my face would flush, and I’d feel my body temperature rise. And, admitting failure, I’d finally say, ”I’m not sure, I’ll look into it and get back to you.”

Not good.

Becoming compliant, whatever that meant, was however, fully underway at that time. It was being handled by the super smart propellerheads at Cloud Elements. While I had learned the appropriate buzz words from the various compliance all hands meetings and the slack channel, when I’d toss those out on the calls, our prospects would see right through it and want me to be more specific in my answers. 

What I found out in my research was that as you peel back the layers, compliance can be summarized so that it is easily understood and actually interesting. I also figured out that our co-founders had compliance in mind from the get-go when they architected our platform, knowing that we’d have to cross that bridge at some point in the future.

Smart, our co-founders were.  


So, why did Cloud Elements pursue SOC 2 Compliance and ISO 27001 Certification?

Our customers’ customers demand that they maintain ISO compliance. They take information security seriously given that, at the end of the day, it takes people's privacy into account.

Bottom line, they won’t use our service if we are not in compliance. Pretty good motivation, no matter how you slice it.

Compliance 101 

An Information Security Management System (or ISMS) is a comprehensive framework you establish in your company for managing risks, specifically… information security risks.

For ISO 27001, the ISMS is a top down approach to managing risks, which includes risks from people, processes and technology – it’s not just about IT security and not getting hacked.

The CEO establishes the program, under the guidance of a Chief Information Security Officer (CISO). A threat assessment is performed, and then risks are identified and dealt with under a risk management process. Top down. From there, you develop your controls and procedures to manage your risks. We do all this to protect the sensitive data of our customers.

SOC 2 and ISO 27001 are both part of an ISMS:

  • SOC 2 is about evaluating and auditing your process. Essentially, can you prove that you're doing the procedure you said you are doing?
  • For ISO, it is all about taking Information security seriously at every single level in the organization. ISO becomes part of your company’s DNA, and thinking in terms of risk mitigation is the name of the game.

GET /ISO27001

For ISO 27001, you start at the top (CEO) and you identify risks - that you either accept or you do risk remediation. One of the risks that you are likely to identify is that you need to identify the people responsible for the ISMS:

  • Need to have 3rd party auditor. We passed our audit, as of February 28th, we are ISO 27001 certified.
  • Need to have people responsible for ISMS. We hired Ed. Ed is awesome. Ed scared us all into following the rules.

When determining risks, you start with a risk assessment. From there you identify risks that you’ll either accept, or you’ll “treat” or mitigate. Once you’ve identified the risks and the plan for treating them, you produce policies and then lastly procedures for addressing the risks. And lastly, ISO requires that you measure that your information security program is effective. So all your policies and procedures need to be measurable from the get go. You have to show continuous improvement in your ISMS over time, in order to keep your ISO certification.

“What gets measured gets improved.” - someone wise

It's all very concrete in the end.

Remember, it's the top-down approach to establishing information security that makes it pervasive throughout the entire organization - the engineering team is not up front driving the compliance process.

GET /ISO27001/stages

ISO typically takes the form of a multi-stage audit. 

In the Stage 1 audit, which is “am I ready for an ISO audit”, the auditors come onsite and quiz you about your ISMS program. Any areas of concern are identified by the auditor. You need to address these before the auditors will come back out for the Stage 2 audit. In Stage 1 you need to show evidence that your program is a top down ISMS program.

Stage 2 is the audit proper. You’ll need to show detailed evidence of every single part of the ISMS program, and you’ll need to prove you do (and measure) all the things you say you do as part of your ISMS system. If you pass your Stage 2 audit, you get your ISO 27001 certification. 

Yay! Congratulations, you’re halfway there… wait, what?

Stage 3 audits occur every 12 months during the life of your ISO 27001 certification. ISO is like a puppy – it’s for life.

Each 12 months over a three year period, one-third of your ISMS system will be thoroughly audited. Even after you get your ISO certification, you’ll need to keep proving (by measuring) over and over again that you’re doing the things you said you’re doing.

Five months.

That is unheard of, but that is what the certification team accomplished here. We started on September 6th, 2017 and were ISO 27001 stage 2 audit complete and certificate issued on February 28th, 2018. 

How’d we do it?

  1. Everyone was motivated
  2. Our customers required it
  3. We were built to be compliant out of the gate

Wait, Compliant out of the gate? What?

Cloud Elements’ API integration platform is 100% REST API based. You just use REST API calls to do what you need to do, that’s it. No need to store our customer’s data under normal circumstances - and it is encrypted in flight via HTTPS.

That has been a mandate from the day that Cloud Elements was formed and it still is today. We go out of our way not to store data - and it can be quite difficult to meet that mandate sometimes. However, that mandate is what made it relatively easy for us to comply because the company was built in a way that made it compliant out of the gate.

There are exceptions, like with our bulk APIs, events, and formula retries given that there's no way to do those things without temporarily storing data. When we do need to store it, we do it in an ISO 27001 compliant way and it is auto-deleted.

Compliance 102

If you have customers that are located in the European Union, there are privacy regulations that are coming out that are, frankly, something the world has never seen before. They are essentially the institutionalized right for privacy for your own data that is required by governments. There's no such right anywhere else in the world. It is termed GDPR, General Data Privacy Regulation and the enforcement date begins 25 May 2018 - at which time those organizations in non-compliance may face heavy fines. GDPR tells you how to handle Personally Identifiable Information, aka PII.

In addition to GDPR, there is the Health Insurance Portability and Accountability Act of 1996, or HIPAA. Within HIPAA, there's this concept of a Covered Entity, which covers things like a Hospital or an Insurance Carrier, as well as various vendors that are referred as Business Associates. In all cases, those who handle Electronic Patient Health Information, or ePHI, need to have an unbroken chain of custody via agreements, where all parties that touch the data in any way are compliant. 

HITRUST is the act that tells you how to enforce HIPAA, which essentially is how you handle Electronic Protected Health Information (ePHI) which refers to any protected health information (PHI) that is covered under HIPAA.

Compliance is hard.




High water mark

We basically set what people in the security industry refer to as the “high water mark” across multiple compliance frameworks. This means we looked at all the compliance frameworks we wanted to achieve (ISO, SOC2, GDPR, PCI, HIPAA, HITRUST) and made sure that we implemented the strictest requirements across all of them.

We chose the hard road.

While this all sounds a bit hairy, and it is, it actually turns out that once you comply with ISO and HIPAA, you're pretty darn close to the others. At Cloud Elements, we don't want our customers to every worry about data coming through our systems, so we set ourselves up to handle electronic patient health information (ePHI) for HIPAA/Hitrust, personally identifiable information (PII) with GDPR for our European customers, and PCI as well for handling financial transactions. We used our ISO 27001 program to establish these goals.

Compliance is fun. 


A note about architecture

You can't bolt compliance in at the end.

Think about every single architecture decision you make. If you think that compliance is going to be something you want in the future, it's much easier to say “Let's pick this technology over that other one because at least we know that one's going to be compliant in the future”. Versus picking a tech stack because you like more, without ever thinking about compliance. It takes you 30 seconds more to be like, “Hey is this going to be compliant if I wanted to be HIPAA down the track?”

Jason, VP of Product 

It's very easy to make decisions in a way that will future-proof yourself, it's very hard to go back and change decisions you made on compliance because you might end up having to rewrite portions of your application.

Compliance is awesome.