Why your company might NOT need a SOC 2 report

Just to clear up any confusion...

Googling “why your company needs a SOC 2” reveals an array of blog posts from vendors purporting to answer that question.

Upon reading them, and if you aren’t deeply familiar with with the System and Organization Controls (SOC) 2 report, you might tend to believe that your organization also should have one.

It might, but this isn’t always the case. Thus I wrote this post to explain why you might decide to not pursue a SOC 2 attestation.

I won’t try to explain SOC 2 in depth in this post, but would instead refer you to the excellent library of content on the topic over at Fractional CISO (disclosure: my company StackAware, has a referral agreement with them).

In one sentence though, SOC 2 is a type of report governed by the American Institute of Certified Public Accountants (AICPA), which involves external auditors attesting to an organization’s controls related to the “Trust Services Criteria” (TSC) of security (mandatory) as well as availability, processing integrity, confidentiality, and privacy (optional).

SOC 2 has become something of the de facto cybersecurity standard for Software, Platform, and Infrastructure -as-a-Service (-aaS) companies selling business-to-business (B2B) in North America. Many questions might spring to your mind upon learning this (e.g. why is a professional accounting organization in charge of a major cybersecurity standard?).

But I’m going to focus this post on why organizations might not need a SOC 2 rather than answering them.

Since there is no law requiring an organization to pursue a SOC 2 attestation, it’s important to view acquiring one as ultimately a business decision, just as whether to implement any other cybersecurity measure should also be. And, in many cases, it doesn’t make sense or might even be impossible to get one. I have often encountered customers demanding a SOC 2 report - and companies scrambling fruitlessly to obtain one - in these types of situation.

I am writing this post to help such hapless organizations in explaining why they might not need such a report.

An important clarification before proceeding: I am in no way saying that cybersecurity is not important in the below situations, but specifically that SOC 2 is not the most appropriate way to evaluate it. Such situations generally involve organizations in one of the below categories:

Non-aaS software companies

This is probably the biggest group of folks not needing SOC 2. If you develop software but do not have any responsibility for running it, the audit process would do little for you and your potential customers.

This is primarily because the confidentiality, integrity, and availability of the customer’s data is less dependent on the vendor than if the latter were hosting the information.

SOC 2 is not an especially technical audit and focuses on the internal policies and governance of the software provider. Much of the below is thus of less interest to customers of non-aaS software, such as:

• Whether or not the board of directors is independent from management

• How employees are terminated

• Whether the company can recover its (internal, not customer) data in a given timeline

Far more of interest to those operating non-aaS software would be the nature of the vendor’s secure software development lifecycle (SDLC). This would include details on:

• static, dynamic, and software composition analysis tools used;

• the nature (and existence) of peer code reviews;

• patching cadences; and

• vulnerability disclosure and notification procedures.

SOC 2 does not touch heavily on these things, making it less useful in evaluating organizations that do not operate the software they produce.

For those organizations that allow customers to choose either -aaS or customer-managed options, it would certainly make sense to pursue a SOC 2 attestation for the former. If a customer asks for a report for the latter, you can respond that it is possible to operate your software in a SOC 2-compliant manner (evidenced by the existence of the report you have for you -aaS offering) but that the report itself does not apply to software as run by the customer.

-aaS vendors selling primarily to the federal government

In the framework sprawl that characterizes the modern cybersecurity landscape, you’ll likely be unsurprised to know that the federal government doesn’t especially care about SOC 2. It has its own standard for -aaS providers: FedRAMP. Based on the NIST 800-53 set of controls, FedRAMP is the primary security gatekeeping mechanism for companies selling to federal departments and agencies.

Thus, if this is your main market, pursuing a SOC 2 attestation wouldn’t make much sense. While some of the work completed as part of the audit process might be re-usable, FedRAMP is extremely documentation heavy and will require substantial additional work.

With that said, it would be tough get to the point where it would make business sense to focus on the government as your primary customer base without already having a profitable commercial offering. This is because FedRAMP can cost organizations hundreds of thousands of dollars, so the only situations where going straight to FedRAMP might be viable is if you have venture capital funding at your disposal or a thriving non-aaS government software business and are looking to move into -aaS.

SOC 2 might also not be a great investment for those organizations who sell primarily to state governments, due to the increasing proliferation of StateRAMP standards. While much remains up in the air with respect the requirements of various jurisdictions and their reciprocity with FedRAMP’s, it doesn’t seem to me that SOC 2 would be especially helpful here.

If you sell -aaS to both the public and private sectors, then unfortunately you are probably going to just need to comply with basically every security standard under the sun, like Palantir.

Pure Business-to-Consumer (B2C) -aaS companies

In general, -aaS companies selling directly to individual consumers don’t need a SOC 2 report. That is because individual consumers aren’t sophisticated (or interested) enough to read such a report and don’t base their buying decisions on its existence or contents.

I have heard anecdotally (although never seen it myself) that some B2C companies get evaluated on the privacy TSC in order to bolster their bona fides with privacy-focused consumers. This strikes me as a strange approach because I doubt the average person, even one who is privacy conscious, knows what the SOC 2 TSC are or cares. And this person would probably be confused to learn that the evaluation process involves an accounting firm.

With that said, there are many organizations that sell both B2C and B2B, making a SOC 2 report an important requirement for customers of the latter channel.

Companies whose target market is primarily outside North America

Since the first letter of the AICPA stands for “American,” it’s important to understand the geographical limitations of the SOC 2 standard. Outside of the United States and Canada, software customers looking to vet their suppliers are more heavily focused on the ISO/IEC 27001 standard.

More prescriptive and narrowly focused than SOC 2, ISO 27001 has some overlap but requires its own certification process. While SOC 2 certainly won’t hurt you when competing outside of North America, it won’t especially help you that much.

Very early-stage startups

Finally, it is important to consider that the entire SOC 2 audit process can cost tens of thousands of dollars. This doesn’t even include the time spent by your team internally to meet the standards and document this fact.

Thus, for companies that are very early in their lives, pursuing a SOC 2 attestation can be a major distraction and be cripplingly expensive.

Furthermore, if customers are only willing to buy from companies that can provide SOC 2 reports they will likely miss out on up-and-comers who have a strong offering but are still in the early days of their development. All of business (and life) is about risk-reward tradeoffs (and SOC 2 by no means insulates you from vendor cybersecurity risk).

Thus I would recommend avoid using the presence or absence of a SOC 2 report as a binary criterion for evaluating a potential vendor.

Conclusion

My hope with this post is to help companies in the above categories who are struggling to explain to their customers why they don’t have a SOC 2 report (and why it doesn’t even make sense for them to get one). Having had to answer such questions many times in the past, I thought it made sense to write everything down and share it with folks who have found themselves in the same situation.

I’m sure there are other situations where a SOC 2 report might not make sense as a company goal, so please feel free to share them in the comments section.

Update (24 December 2022): Based on some excellent feedback I got via LinkedIn comment threads on this post, I added the sections on ISO 27001 and early-stage startups. Thanks to everyone who contributed!