What does “compliance” mean for a software company, and when do in-house compliance processes become necessary?

I have also been responsible for compliance processes at the company where I have worked for about four years. I started this series because of the questions I have received about the subject recently. As someone without an audit background who has nevertheless gone through ISO 27001, SOC 2, and HIPAA audits, I thought it could be useful to create a body of knowledge.

What does “compliance” mean for a software company (especially a B2B SaaS company), and at what point does developing compliance processes within the company become necessary? Let’s start there.

Imagine a company with customers around the world that sells a software product; UserGuiding is exactly such a company. Even if you approached the subject with common sense and no technical knowledge, you would expect software that you buy and use at your company—and into which you may load both your own data and your customers’ data—to meet a certain standard. But how would you know? A software company on UserGuiding’s scale uses an average of 30–50 software services in its own business processes. Auditing every one of them is almost impossible, or at least let’s say it would be very expensive for us.

This is where “audit frameworks” are useful. A framework is a published set of criteria: it determines how controls are established and what an auditor examines. ISO/IEC 27001:2022 is a management-system standard, and certificates are issued by accredited bodies, not by ISO itself. PCI DSS applies to companies that handle card data, but it is enforced by card brands rather than by law. NIST’s Cybersecurity Framework 2.0 is voluntary. In other words, in addition to laws, there are frameworks you may choose to adopt “voluntarily” because market demand points you toward them.

One of the most common frameworks, SOC 2, is based on the AICPA’s Trust Services Criteria. It consists of five categories: security, availability, processing integrity, confidentiality, and privacy. Security is included in every report; the others are added depending on scope. The result is not a certificate, but a report in which a licensed auditor expresses an opinion. Type 1 examines the design of controls at a particular point in time. Type 2 examines whether the controls actually operated over a period and also includes the auditor’s tests. Especially if you provide a product to the US market, we could say that SOC 2 is practically mandatory.