Are you tasked with helping with a SOC 2 audit? Are there auditors around you speaking accounting jargon? Are you wondering what the point of all of it is?

This is the post for you.

---

The essence of compliance is this: A lot of people both inside and outside any given company have a vested interest in making sure the internal systems and processes don’t suck.

• We want to minimize chances for errors.
• We want to prevent fraud.
• We want to protect customers from data and identity theft.
• We want to make sure people and the organizations they work for are upholding the law.
• We want to make sure the partners and suppliers we rely on are operating according to specific standards.
• Hell, sometimes there are geopolitical considerations to not running bad software.

That is by no means exhaustive, but gives you a flavor of the pain points people are solving for. In short, there is wide interest in making sure organizations are aligned with industry best practices.

SOC reports are one of numerous compliance frameworks that engineering teams are likely to encounter in the process of certifying their systems follow good practices.

SOC it to me

System and Organizational Controls (SOC) reports are provided by third-party auditors. Their goal is to certify that the companies they audit have appropriate controls in place around their data and infrastructure, including security, access, and privacy controls.

SOC reports are not legally required by any regulator, but instead tend to be requirements for doing business with certain classes of customers.

There are multiple types of SOC reports, which vary based on their intended audience.

At a high level:

SOC 1 reports are for companies with systems that directly impact their clients’ financial statements. Auditors will test both IT and business process controls, and the scope of the audit is not negotiated.

SOC 2 reports are SOC reports that most engineering teams probably encounter.

SOC 2 reports vary from company to company because they are tailored to be relevant to the company’s operations. While there are specific criteria that every organization must meet to obtain a SOC 2 report, the governing accounting body in the U.S. does not issue an official SOC 2 compliance checklist.

The method by which each organization satisfies the criteria is situational, and defining the relevant criteria is up to the company and their auditor.

Once scope is negotiated, SOC 2 reports provide concerned parties information about an organization’s controls around security, availability, processing integrity, confidentiality, and privacy.

SOC 3 reports are similar to SOC 2 reports, but are shorter form and not restricted in their use (and therefore can be used for marketing purposes about a vendor’s security posture.) Comparatively few companies find SOC 3 reports to be necessary compared to SOC 2.

SOC for Cybersecurity reports – despite using the word ‘cybersecurity’– are in fact real things. In practice, most companies just get a SOC 2 because the difference between general information security and ‘cybersecurity’ is increasingly interchangeable. To have good information security to pass the SOC 2 by default requires good cybersecurity.

I can’t believe I just had to use the word cybersecurity five times…

It gets worse

It turns out that developers aren’t the only people who struggle with naming things. In addition to the above categories of SOC reports, there also are two different depth levels (called “attestation options”) for each report. These have helpfully been named ‘Type 1’ and ‘Type 2′.

Which means you get reports classified as “SOC 1 Type 2”, “SOC 2 Type 2”, etc.

The difference between Type 1 and 2 reports is the degree to which the auditor tests the effectiveness of the system. A Type 1 report offers the auditors’ opinion about the design of the controls within a system at a given point in time. A Type 2 report goes beyond that to test the effectiveness of the controls over a period of time (generally 6 or 12 months.)

An example would be the difference between an auditor reviewing that you have a change management process in place vs. the auditor going back and sampling changes from the past year to ensure the process was actually followed. What is the plan vs. how well is the plan executed?

A Type 2 report is more robust than a Type 1 report.

---

It may seem like the final SOC reports are full of jargon and weasel words, and that’s because they are. Auditors are not here to provide guarantees that there are no issues with the systems. Everything in these reports is very carefully worded to communicate that the auditors tested for a certain set of controls and they make no assurances about the overall state of the system. While having these controls in place should help mitigate risk it will never eliminate it.

I hope this high level translation to audit-speak helps take some of the pain out of your next SOC review process. As always, throw any questions in the comments. I am always happy to provide hot takes on boring stuff.

As always, please remember:

• I’m not a CPA.
• None of this constitutes financial advice.
• Be nice to your internal audit team, because they can for sure explain all of this better than I can. 🙂

Related posts:

My colleague James Governor wrote an excellent piece talking about the potential role GitOps could play in compliance.

The opportunity to use Git-based workflows for compliance purposes is currently underappreciated, but there is a growing understanding in the industry that it’s a significant opportunity. One of the biggest challenges in any compliance project is understanding who did what, and when. With a GitOps-based approach you naturally track system changes, but also know who made them.

Have you ever felt utterly out of your element when meeting with your counterparts in the finance or accounting department? If you find yourself lost when discussing financials, here’s a quick primer on some of the key concepts you should be familiar with at a high level. Five Minute Finance