First: the rule with these kinds of certifications is simple: don't do them until you have customer deals contingent on them. You should be able to weigh the costs of certification against hard, certain revenue. Depending on your customer base, you may get pushed into certification soon, or you might be able to push it off surprisingly far. If you can do that, you should.
Second: in North America, SOC2 is much more common than ISO 27001. 27001 is more common with gigantic companies than with startups. By way of example: Datadog just announced its 27001 last year, a few months after they went public. That they were able to scale their business to that point without 27001 certification --- and look closely at what Datadog's business is, and who their customers are! --- should tell you something about which certification you're likely to want first.
So for the rest of this comment I'm going to assume your company has no certification, and that you can get away with SOC2.
Third: while you will run into NA customers that want SOC2, there's a loose norm of purchases contingent on achieving a Type 1. That is to say: you can probably plan on deferring SOC2 until you have a contingent P.O. in hand, and do it then without losing that deal. You know your customers better than I do, but I spent a bunch of years doing this work for startups and don't think I ever told anyone to SOC2 preemptively.
Fourth: a real risk with rushing certification is that it can warp your security engineering and business processes. SOC2 is particularly amorphous, and SOC2 auditors are a weird bunch (people with strong opinions about which security tools you should be running that don't know the difference between an IP address and a domain name are people whose influence on your IT and engineering you should limit). You want a security team in place before you start chugging away at SOC2, so that your security team can be the primary influence on what engineering you do to support SOC2 (a competent security team will win any shootout with any major-label auditor).
Fifth: For most companies, you'll be 25-35 engineers before you contemplate a full-time security person, which gives you an idea of the normal lifecycle point at which you might start seriously consider certifying.
I wrote a blog post for my last company about some things to know about SOC2 and early-stage companies:
This ^ is my favourite writeup on the question of how you implement SOC2. I wish I had read that before we started - after going through the Type 1 and Type 2 process, we've ended up with the same conclusions. I've lost count of the number of times I've recommended that.
Our experience (global b2b customers, heavily skewed to NA) is that SOC2 Type 2 is the most frequently requested/expected standard, and if you have that, not having ISO is very rarely a dealbreaker. Neither makes the security questionnaires go away; they continue to be mandatory, require expert input, and are a significant drain on time. However, having SOC2 and/or ISO does mean that you've already thought of the answers to the questions and you'll have a defensible position, backed up by a track record of independent audits, when your particular approach doesn't meet the "gold" standard implied by the questionnaire. (Edit: typo)
> First: the rule with these kinds of certifications is simple: don't do them until you have customer deals contingent on them.
Getting an ISO 27001 certification can take months of effort, and not all deals can be stretched this far without significant repercussions.
Just a data point, I lead the certification project at my current company and it took us 8 months (~65 people in total, of which 3 full-time in IT): the auditors were a little hesitant at first because the system wasn't "battle-tested" as much as they'd liked.
Right. The short answer to the question this post asks is: "if you're a North America startup, do not get ISO 27001, and be wary of any advisor that says you should do so without a 7 figure purchase order closed and contingent on it."
SOC2 is a little bit trickier, but not much trickier: the strategy is the same: wait until you have to, and then get it to close the deal.
Second: in North America, SOC2 is much more common than ISO 27001. 27001 is more common with gigantic companies than with startups. By way of example: Datadog just announced its 27001 last year, a few months after they went public. That they were able to scale their business to that point without 27001 certification --- and look closely at what Datadog's business is, and who their customers are! --- should tell you something about which certification you're likely to want first.
So for the rest of this comment I'm going to assume your company has no certification, and that you can get away with SOC2.
Third: while you will run into NA customers that want SOC2, there's a loose norm of purchases contingent on achieving a Type 1. That is to say: you can probably plan on deferring SOC2 until you have a contingent P.O. in hand, and do it then without losing that deal. You know your customers better than I do, but I spent a bunch of years doing this work for startups and don't think I ever told anyone to SOC2 preemptively.
Fourth: a real risk with rushing certification is that it can warp your security engineering and business processes. SOC2 is particularly amorphous, and SOC2 auditors are a weird bunch (people with strong opinions about which security tools you should be running that don't know the difference between an IP address and a domain name are people whose influence on your IT and engineering you should limit). You want a security team in place before you start chugging away at SOC2, so that your security team can be the primary influence on what engineering you do to support SOC2 (a competent security team will win any shootout with any major-label auditor).
Fifth: For most companies, you'll be 25-35 engineers before you contemplate a full-time security person, which gives you an idea of the normal lifecycle point at which you might start seriously consider certifying.
I wrote a blog post for my last company about some things to know about SOC2 and early-stage companies:
https://latacora.micro.blog/2020/03/12/the-soc-starting.html