Datafold is SOC 2 compliant - What it means for you

In my first meeting immediately after I joined the Datafold team full-time, the CEO and co-founder Gleb discussed security certifications with me. He put me in charge of pursuing Service Organization Control (SOC 2) compliance and made it clear how this could serve as an indicator for Datafold’s security efforts and keeping our data, and customers’ data, secure.

Companies were trusting us with their most sensitive information, and the data of their own users, and our certifications should reflect how seriously Datafold takes that responsibility. The goal was to demonstrate to our clients, through collaboration with an independent third party, that our security measures are in line with the unique parameters of today’s security requirements and expectations.

What is SOC 2?

Created by the American Institute of CPAs (AICPA), SOC reports are a security audit and attestation. The audits evaluate the security controls an organization uses when processing user data and determines if those protocols are sufficient to protect that data. Essentially, companies and customers need to know that data is safe in another organization’s hands.

A SOC 2 compliant organization passes audits to show it has all the appropriate procedures in place to ensure the security, confidentiality, and integrity of user data.

What is SOC 2 Type 1 vs Type 2?

As of publishing this blog, Datafold is SOC 2 Type 1 compliant. Type 1 is based on a snapshot in time, auditing security practices at a given moment. Type 2 reviews those policies and controls over a longer period of time. Obviously, this means that SOC 2 Type 2 compliance takes more time to achieve, but the actual policies or levels of controls can remain the same. In general, both types can use audits against five key criteria, although not all companies need to be assessed across all five:

1. Security: Is the system protected against unauthorized access? Controls should prevent system abuse, data theft, and improper disclosure.
2. Availability: Can users access the system as expected? Processes and tools should monitor network performance and incident response.
3. Processing Integrity: Can the system process data completely and accurately and deliver it in a timely manner? The organization must monitor data processing with active quality assurance protocols.
4. Confidentiality: Is confidential user information protected from unauthorized access and disclosure? Network firewalls, data encryption, and access controls should be established and maintained.
5. Privacy: Is all personally identifiable information (PII) collected and processed in a way that prevents unauthorized access? PII should be collected, used, retained, disclosed, and destroyed according to commitments in the privacy notice and according to generally accepted principles issued by the AICPA.
   

Why SOC 2 now? How does this help our customers or partners?

SOC 2 is one of the most reputable audit reports that you can get and an important certification milestone for a startup like Datafold.

Our SOC 2 report is helpful for our partners and customers. It proves that even though we are accessing an organization’s data warehouse, we have controls in place to ensure security and compliance. It also signals to anyone considering Datafold that we take these policies seriously - it’s not enough to simply write down a policy and then ignore it, the only way to pass the SOC 2 audit is to show proof that you are following the controls and protocols that you put in place.

When considering vendors in the data space, most companies need to evaluate the impact of business continuity. Depending on that assessment, a vendor may be considered low, medium, or high risk. SOC 2 can reduce the risk level during an evaluation, making it easier for our champions at organizations to bring in Datafold or expand its use. Interested customers can also request the SOC2 report (under an NDA) so that the details of our controls and the audit can be reviewed.

Lessons I learned from the SOC 2 journey

When I started working on revising our policies, it was hard to know what needed to be included. Without a clear guideline of the kind of security needed, with delineations of what you should have versus what you need to have, it can be a tricky perspective for an engineer. 

Gleb introduced me to a tool called Vanta, which was helpful in providing context, checklists, and also automated tests. However, even though the tool was very helpful in the execution, without the specific context of what an audit was going to be reviewing, I wasn’t completely clear on what was needed for each policy. I thought everything was important and considered the whole range of security controls as vital to our success with the SOC 2 audit.

The process and requirements became much easier when I started working backward from the content of the final report. When I understood the outcomes, it allowed me to reason about what was needed and relevant. 

It all became even clearer when I reached the stage that included working with an actual auditor. This specific auditor starts with a design session, which includes a Document Request List of what the security should be. This included mapping each control from the SOC 2 framework that applies to the selected trust services criteria in a spreadsheet to our policies and measures that had to be in place. 

Once you have the requirements laid out this way, the flow becomes less abstract and much less daunting. After this session, I was able to revise and complement our policies in a week, but also in such a way that they fully aligned with the controls that would be checked in the eventual audit.

At its core, you need controls to satisfy a requirement. To show that you have the controls, you make them into policies. Then you need a document or screenshot as evidence that the policy is in place and used, which you can track on the Document Request List. Once you understand what the controls are above, you can look at the current policies or otherwise suggested templates to determine which policies you’ll need, and it all makes a lot more sense.

One of the best lessons that I learned was that as long as the control is effective to satisfy the requirement, you work with the auditor to make sure that it is an exact union with the design that you built together. If your policy is stricter than the design, you might end up with a mismatch. This would impact how the auditor tests your controls and policies - ultimately, it’s not always the best approach to make every policy as strict as possible, but rather to make sure that it matches your overall security design, which is in turn related to business risk. We ended up doing a full risk assessment for that purpose, ticking off a box in the audit that requires annual assessments to take place and creating a dozen of issues on our bug tracking system that would lead to better security and more auditable controls.  

Eventually, everything was in place, with all policies revised and made more mature. It was time for the audit’s fieldwork phase, which lasted two weeks.

Even though we were doing an intercontinental, remote audit, the process was relatively straightforward. I would prepare for the audit’s observation sessions by ensuring I already had a few tabs open and logged in to systems that were going to be audited. Then it was simply a matter of sharing my screen, showing our processes, and answering any questions or clarifying any elements, where the auditor simply takes screenshots of the process.

Again, it was helpful to work closely with the auditor. For example, if they ask if only a given number of people have access to the root account, you’ll need to demonstrate that only those people have access. How can you prove a negative, that other people don’t have access? By working with the auditor, we were able to find ways for them to evaluate our controls and make them auditable. 

How Datafold continues to ensure security and compliance

Now that we are experienced with our SOC 2 audit, we plan to pursue the longer-term report. While the SOC 2 Type 2 requirements are similar to Type 1, they do require more time and we have to demonstrate that we follow our own documented procedures. For example, a Type 1 report will check that you have a policy in place to conduct performance reviews. By the time you do a Type 2 report, the auditors will expect to see records of those performance reviews. 

This poses a bit of an extra challenge. Sometimes measures are already in place, but those measures may not be auditable because they don’t leave much of an audit trail. So in many cases, you end up redesigning procedures and activities in such a way that a clear audit trail becomes visible, simplifying the fieldwork of the auditor and making the process itself more transparent and traceable from your own end too.

Security and compliance are ongoing projects that I will continue to oversee until we hire a security officer. This means annually upgrading our evolving policies and ensuring that we have a culture of proactive security. As the company grows, we will continue to invest in security training and oversight to maintain the highest standards and protocols. 
We will also investigate any future certifications depending on how our partnerships progress. If your leadership team has any questions about our security and compliance, or you’d like to see our SOC 2 report, you can feel free to contact us.

‍