KernelCare: On Becoming SOC 2 ® Compliant

At KernelCare, we’ve known about SOC 2 for some time. We’ve had customers tell us that our Linux kernel live patching product helped them with their compliance certification efforts. Although KernelCare doesn’t handle customer data, we thought we should follow the good example set by our SOC 2-certified customers and become compliant. We would get to know our customers’ use-cases better, and improve as a company.

So, I’m excited, and a little nervous, to share with you the start of our own SOC 2 compliance journey. I will share more as we progress.

A Quick Introduction to SOC 2

Data security is important. Service customers want to know their data is safe; service providers want to prove there is nothing to fear. We’ve all seen quality labels on physical products. Badges of quality for virtual products and services are less common and less visible. Of those, SOC 2 is the one that stands out.

A SOC 2 certification report comes from an audit of a company’s procedures, systems, and data management policies and controls. It’s a certification program held by US-based big-data firms. Clients of their ecosystems have got it too, as the trend works its way down the cloud services food chain. A SOC 2 certificate is a public declaration to customers, telling them that:

• their data is secure and private;
• the systems processing it are available;
• the system maintains the integrity and confidentiality of their data.

The emphasised words are the five categories of a set of Trust Services Criteria, principles that underpin a SOC 2 report. These groupings let an auditor’s client choose which elements of an audit they want to commit to. This flexibility and pragmatism is part of SOC 2’s success and its appeal to online service providers.

Being an Auditor

Becoming SOC 2 compliant means making technical and cultural changes, and reviewing and changing them continually, if necessary, to stay compliant. To illustrate how much commitment is involved, our compliance officer told me about his background and experiences.

Dmytro Pigul began his career as an internal auditor at the Kiev office of Raiffeisen, a Vienna-based international bank. He spent two years performing operational audits before moving to UK-based GlaxoSmithKline where he had his first taste of full compliance auditing. Since then, he has done training, big data analysis, and anti-corruption investigations and financial forensics. Now in his 10th year as an auditor, Dmytro uses his experience to run KernelCare’s SOC 2 compliance program. Here’s a short Q&A I had with him.

Aleksandra Mitroshkina: What are the main steps in a SOC 2 audit?

Dmytro Pigul: There’s a lot of them so it’s best if I summarize them as Scope, Scan, Change, and Check.

Scope means kicking off with meetings with the C-suite, understanding why they want SOC 2, and to make sure there is ‘buy-in’ to the idea. We decide what Trust Service Criteria to focus on, and which departments and systems are applicable. Because KernelCare is part of CloudLinux Inc., the management decided to include two other products as well. Part of the scoping exercise is to identify stakeholders: who knows what and what their role is. These people are my touch points throughout the audit. By the end of the scoping phase, I have a list of deliverables, documents that set out the audit’s agenda and scope, and help track its progress.

Next is Scan. This is where checklists, such as those based on the COSO or COBIT frameworks, are invaluable. Checklists are a methodical way to keep track of an audit’s numerous considerations, in organization and management, communications, and risk management. And there is the monitoring of controls, for logical and physical access, system operations, and change management.

The next phase is Change, discovering what to change and how to do it. Change is a consequence of compliance. Few organizations are compliant straight away; most must change to be so. For example, in KernelCare, a third of the IT controls were ineffective. So we’ve made changes, improvements that would otherwise have gone unnoticed or had low priority.

Lastly is the Check phase. This is the real heart of auditing, a verification of changes, a validation of controls, making sure all controls are present and effective.

Auditing for SOC 2 Compliance:

1. Define the Scope, set goals, identify stakeholders.
2. Scan the organization: analyze and document it.
3. Change or create controls that work.
4. Check controls are present and effective.

AM: How long will it take us to get SOC 2?

DP: Every company is different. For KernelCare, we began in May this year and are aiming for SOC 2 Type 1 by the end of October. A Type 1 report is a snapshot of compliance, only valid for a point in time. A Type 2 report covers a period and I expect us to get that a year from now.

AM: What happens after we get it?

DP: Getting a SOC 2 Type 2 report is just the beginning of regular annual check-ups. Getting certified is not a one-off activity. To stay certified, you must be regularly audited.

AM: To finish off, what personality trait is most important in your job?

DP: Without a doubt, diplomacy. As an auditor, I’m an invader of people’s worlds and their entrenched ways of doing things. That makes staff defensive and resistant to change. I do my best to show how compliance can be a means of self-improvement, and that it doesn’t only benefit companies and their customers. A close second is organizational skills. Auditing is complicated. There are various aspects to consider, different levels to understand. I work with all parts of the company, from the front line to the C-suite.

KernelCare’s automated Linux kernel patching service helps enterprises with their SOC 2 compliance efforts, resolving the inherent tension between the security and availability Trust Service Criteria.

Embarking on our own compliance program helps us understand that even small contributions can significantly lessen the burden of compliance.