GET /Compliance and Why You Should Care
GET /Compliance and Why You Should Care
Here's a comprehensive look at a few standards you should be aware of, like ISO27001, and some important lessons learned from a company that's been through the process.
Join the DZone community and get the full member experience.Join For Free
Your API is not enough. Learn why (and how) leading SaaS providers are turning their products into platforms with API integration in the ebook, Build Platforms, Not Products from Cloud Elements.
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?
As 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."
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 buzzwords 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.
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.
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."
— S omeone 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.
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.
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?
- Everyone was motivated
- Our customers required it
- 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.
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.
The 2018 State of API Integration Report
Last year, the State of API Integration Report was our first inaugural research report that sought to sort through the proliferation of APIs setting the benchmark for our research on API integration. This year’s report builds on observations from 2017, with the help of over 400 API enthusiasts who took the State of API Integration Survey at the end of last year.
With over 60% of the respondents agreeing that API Integration is critical to their business strategy, our report focused in on four key trends:
- When building a platform strategy, how can you drive new revenue opportunities or deliver value through API integration?
- By understanding drivers of adoption, you can change how developers and end-users consume APIs and integration services.
- The strategic shift of integration has widely been driven by enterprise applications, like Enterprise Resource Planning (ERP).
- An evolution of B2B integration has organizations evolving the way they share and synchronize data with partners.
With expert contributions and insights from:
- Ross Garrett, VP of Marketing at Cloud Elements
- Kin Lane, The API Evangelist
- Isabelle Mauny, co-founder and CTO of 42Crunch
- Mark Boyd, API Industry Analyst and Founder of Platformable
The comprehensive research covers sections including a breakdown of the data, trends, common API business models, and event-driven integration. Download it here to receive the report directly to your inbox.
Published at DZone with permission of David Honan , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.