Matillion’s Journey to SOC2

At Matillion, we are customer obsessed and always do business with integrity. This means that in our business, Information Security is a top priority. We are cognizant of the fact that security is not the sole responsibility of a single team, and work together to ensure that security is applied throughout the whole lifecycle of a product, and through every function of our business.

Why SOC2?

One of the best ways we could show our customers that we take security seriously and hold ourselves accountable to those that do business with us was to ensure we had all the necessary certifications. In 2020, we sought the globally recognized, externally audited security certification: SOC2.  A SOC2 type II goes beyond other Information Security Certifications and allows us to build a bespoke set of controls that fit our unique business needs, rather than dogmatically applying a set of standardized controls.

SOC2 Type I and SOC2 Type II

If you haven’t done a security audit before, SOC2 can be confusing. There are essentially two levels of SOC2 certification: a Type I audit is an external assessment of the design of your controls; a Type II audit affirms that the controls have been fastidiously applied over a period of 6 months. 

Building up to audit

Gaining SOC2 can be a difficult task, the flexibility that SOC2 allows in designing controls means that organizations can take a bespoke approach, but this also means that significant grey matter needs to be applied to security system design. SOC2 has a number of criteria that an organization must consider and a well-designed security ecosystem will have multiple controls in place for criteria. This defense-in-depth approach means that even if one control area fails, another control will notice the failure and quickly course correct.

SOC in a box

As SOC2 gains traction as a de facto security standard, there are numerous suppliers offering SOC2 automation platforms. These platforms give you the ability to plug into various SaaS providers and provide 24/7 assurance of security controls. Many of these platforms also allow an auditor to give a rapid assessment of your controls, reducing complexity and time taken during an audit period.

We did use one of these platforms at the start of our journey, to make some rapid headway with our suitable tasks, but found that the platforms could not meet our specific demands and control designs. So we decided to shift to a more methodical approach. While these platforms certainly have their place, we had a talented internal team who wanted to build a truly risk-centric approach to our controls.

A moving landscape

SOC2 often sits in the inbox of the CISO within an organization and did so in our case. But in reality, it is a transformation of organization-wide processes in areas such as finance, legal, people operations, and technology. This meant cross-collaboration in delivering SOC2 was key and this large undertaking could not be successful as an isolated security project.

To ensure alignment, SOC2 was explained to the business in January 2020 at our Super All Hands event where we laid out the alignment between this project and our company goals.  As we designed the control set, we collaborated with the owners within the relevant core functions (People operations, legal, finance, engineering, product, IT) to ensure they were consulted and informed during every step of this process. Once our control design was complete and in effect we were able to call in the auditors for our audit. 

The audit

To prepare for the audit, we wanted to first ensure that our controls were operating effectively. We conducted a dry run of the audit, taking samples of all relevant controls and assuring them internally. Any areas of concern were addressed and policies and processes changed to ensure control failures were not repeated.

We agreed on an audit timeline with key stakeholders and created a folder structure on Google Drive to give our auditors the ability to see the evidence for each control. The controls can be classified in a few different ways. For us, it was useful to look at the volatility of the evidence. For example, the evidence to show that a yearly risk assessment happens is a lot less volatile than evidence showing we document and approve production changes. 

For the non-volatile controls, we uploaded evidence in the form of screenshots or URLs that could be reviewed by our audit partners. This reduced any friction during the audit period and allowed for asynchronous review.

The more volatile controls required a process of population sampling. Our auditors requested populations; for example, for all changes that occurred within a given period of time, they would then choose a sample of these to test for compliance. Whilst we still kept a Google Drive folder structure for the evidence associated with these controls, we scheduled calls with the control owners to show evidence over video conferencing.

Post-audit

With the audit in our rearview mirror, we cleared a major hurdle but still had more to do before officially announcing our SOC2 Type II certification. First, we needed to complete what is known as Section 3, a key part of the SOC2 report that gives the organizational description of the system under assessment. It is a plain-language description of the People, Data, Infrastructure, Technology, and Controls that make up the system. It also lists the sub-service organizations and user entity controls that must be applied to keep a system secure; another collaborative effort across all of our control-owning teams.

Things to keep in mind 

Conducting security through compliance can often mean a heavy transformative lift with little in the way of risk reduction. We certainly did not want a checkbox approach to security, which goes against our company’s core values. We believed a strong security posture, built upon best practices and frameworks would result in compliance with international standards.

Security is a team effort

SOC2 is not an InfoSec project, but a project in business process transformation. Despite many of the controls related to SOC2 being InfoSec related – Vulnerability Scanning, AntiVirus, Authentication, etc – there are some controls that require individual action and many controls that are part of wider business processes and transformation. Running SOC2 as an InfoSec project would create a silo, and without alignment against company goals, risks alienating other functions who may not understand the journey toward certification.

Designing and applying new controls within an organization should not be underestimated; it is not as simple as dropping in a new requirement, onboarding a new tool or creating a point in time document is not enough. Controls need to be built in collaboration with other teams, and their subsequent effects understood by all.

SOC2 is an ongoing journey

Evidence collection should be round the clock to provide peace of mind. You should not approach an audit with a fraction of doubt in your mind that your evidence is in check. Furthermore, this should not be obtained solely by pre-audit. If this is the case, you are too late and your controls are ineffective. An assurance program that assesses controls 24/7 should be put in place to allow you to course-correct as — and when —  a control is no longer working efficiently. Some of this can be done through automation, others from ‘dip-check’ testing on a monthly basis.

SOC2 implementation is an amendment to the way we operate and a change in our culture, not a point in time exercise. Often there is a misunderstanding with certifications such as SO2 that compliance is a one-off activity, and that as soon as the audit is complete, former practices can be resumed. In order to truly comply with SOC2 in the best spirit, new processes and procedures that were implemented during the compliance program must be adhered to. If for whatever reason processes cannot be followed, then these must be identified and communicated to the InfoSec team so that a solution can be found.