Ask HN: Is the ISO 27001 certification worth it?
ISO 27001 (https://en.wikipedia.org/wiki/ISO/IEC_27001) certifies that information security is properly managed at a company or organisation. But the process of obtaining it is costly and time-consuming so I wanted to ask people who have experience with it: is it worth it?
If you're a company doing B2B sales, how often do prospective customers ask about the certificate? Does it ever make or break a deal? When did you decide that it's time to get it done?
Thanks!
103 comments
[ 4.7 ms ] story [ 145 ms ] threadIt can take a long time to complete an audit, especially that first one. You’re going to need to show a lengthy paper trail of policies and documented compliance.
I think it can bring good discipline to an organization when embraced, but that is often not how it gets done. And in some organizations the discipline is stifling. You’ll want to pay attention to how it is impacting teams.
A previous company I worked for used Process Street for procedure completion and tracking, but I always wondered if all auditors would be OK with such a flexible system.
The certification burden increases in proportion to the level of PII you are storing. The burden was much higher for government or med/bio contracts (FedRAMP/HIPPA, etc.). It's also worth it to mention that we had whole teams dedicated to working through RFPs/RFCs as they can get VERY time consuming.
Bottom line is that if you are going to work with the big fish, you will probably need this level of certification to show them you are serious.
My advice to you is gradually improve your infosec posture and policies etc but rather than kicking off the certification, wait until a customer asks you for it during vendor due dilligence, then say "we're working towards it" and immediately after the meeting commission one of the outside firms who do the evaluation for you.
The evaluation process takes a while and in my experience customers are understanding about that especially given b2b sales aren't exactly quick normally.
Oftentimes, companies from the USA will prefer SOC2 Type2 instead of ISO. So in my experience it is best to check with the market.
Regarding B2C companies, in my experience you'd like to get an ISO certification to reduce pressure from some governing body. For example, I was in a company were we did ISO-37001 because in our country that is a HUGE risk, and our market was attracting a lot of attention from government and regulators. Having an ISO gave us a "checkmark" in their eyes.
Your time and focus is an extremely precious resource especially early on in a startup's lifetime.
A fair few large customers require it and won't bother talking to you if you don't have it, so if you can otherwise do the sale there's a good reason to get it.
Your real problem as a small vendor is deciding when this is necessary, because you might be getting customers just fine when you're small and dealing with people who care about actual security, not paper security. At some point you are gonna have to pull a few people out to get all this paperwork done. I spent last summer doing a whole pile of "Information Security" policies for a friend I was helping. Luckily there are consultants who can get you most of the way there.
For a small company (less than twenty employees) it really is a lot of work. It brings some benefits in that it forces you to have your documentation and certain processes in order, but man… getting audited drains you. It depends a lot on the auditor you get, but from all the stuff I do for my job, this yearly event feels like the biggest waste of time. It's just that without it we would be out of business.
Once your software becomes an ossified cash cow, moving it to RedHat makes more sense.
I disagree with this sentiment. As a small firm who has undergone multiple security audits/certifications, I have found that the controls we added were generally practical and did improve our security.
I would disagree, as we had a very good security program and when we went through ISO 27001, I would have to say that it ended up measurably better.
But if you don't have a security culture, then it will be theater. Dangerously so.
Certainly if the organization is not interested in security, they could fake their way through the certification with meaningless compliance and not actually achieve security.
But if your company does take security seriously, the certifications do help you get organized.
Sometimes it is just helpful when enforcing a good procedure across an organization to be able to tell a sales manager that they can't just email passwords around because we are SOC2, instead of trying to convince them from principle. It can elevate it above the level of company policy from which some people feel exempt. Now you can just threaten them that if they cause an exception on next year's SOC2 report it might scare away the big sale.
You could also start the process and ask your certifying consultant to give you a certificate saying it's in progress which is also good in many cases but follow through to complete it.
It's also a yearly audit and a continuous process to maintain it though.
It doesn't help that SOC2 auditors are basically wrong about a lot of stuff, so that if you're getting certified before you have a sane security practice in place, your security engineering will get dragged into weird, unproductive places.
soc2 forced us to yubikeys everywhere; getting serious about knowing, auditing, and controlling access; etc. There def were useless bits (contingency plans? If an earthquake hits sfo bad we're screwed, you're screwed, etc)). But on the whole, I think it made us a more secure company.
Lots of it is basically best practices. Have, test, and document db backups. Have, test, and document a network diagram. Audit employee offboarding. Don't let all employees trivially touch prod. Put admin tools behind a vpn. Automate approvals and deploys (we did it all with aws tooling) so that you can audit deploy -> git sha -> [PR approval in github, ticket in jira]
Lots of this is probably dependent on your auditor though.
Also, it's a slow lead time to get, and the upper midmarket / lower enterprise demand it.
edit: bluntly, it also gave me some justification to slide things through when junior eng complained they couldn't touch the prod db.
I understand what you're trying to say: the threat of a SOC2 information gathering process scared your engineering team into taking 2FA seriously. Your team was able to use it as a forcing function. Not to put too fine a point on it: your team is dysfunctional and has a poorly-communicating and unpersuasive security practice.†
That's the problem you needed to fix. There will be things you very seriously need to get rolled out after Yubikeys, and you won't have another $70,000 Big5 audit to wave around to get it done. Meanwhile: people who don't want to endure that audit can get Yubikeys deployed without bothering with the SOC2 part.
An important thing not enough people understand about SOC2 is that the profile of controls that you use (where controls are things like "logs we monitor" and "onboarding processes" and "2FA mechanisms") are self-determined. Auditors have a set of very high-level goals --- much higher level than "services need 2FA SSO --- and you get to pick what controls you map to them. You get to pick what SOC2 makes you deploy, and the auditors ostensibly just keep you honest.
I would be surprised if anything close to 50% of reliably SOC2 -Type-2'd shops had any hardware 2FA at all.
† Almost everyone does!
You can use spreadsheet-based recordkeeping to satisfy very much of SOC2 as long as the processes are followed consistently.
Perhaps it would make sense to at least know and understand the certifications as early as possible, and grow with it in mind. It makes it a lot easier to get certified when times come, or even to explain clients why it wouldn't be required in some cases ("we can already guarantee you this and that, if that's the part you're worrying about")
It depends on what kind of clients you have, if you are working with customers in regulated industries, then I believe it's worth it.
Bolstering the recommendation is the fact that the proliferation of supply chain attacks recently is adding pressure for companies to perform more thorough diligence on their vendors. The certification helps check all the boxes.
There is a time management component to this. If you're still in a deal without a 27001 certification, the security questions don't go away. Instead, you get sent a security question set to answer. These question sets can be huge - our record is about 300 - 400 questions. And once you've answered those, you're not done - then you go into discussions with their cybersecurity about your answers.
Once you're in the loop with a number of large deals, this becomes a huge time sink.
And no, you can't give this to an intern, or just search-and-answer most questions, because every company formulates their questions and requirements differently and it takes some knowledge to figure out what they mean and want.
And at times the discussions afterwards are even worse. I've had InfoSec-guys tell me they're concerned because I cannot give them the specific details on the physical security of an AWS datacenter because these are not available.
As much work as getting and maintaining an ISO27001 certification is, there is a point after which it'll save you time and nerves.
My experience has been that companies regularly close deals by committing to get a Type 1, for what it's worth.
In our case, the customer profile is from lower midmarket to Fortune 50.
You probably can close deals (depending customer, obviously) by committing to a Type 1. We did that at the beginning, but it exposes you to a lot more interactions with the security team. While you rarely see deals fail for security reasons, I've had it happen. So my experience is the less interaction you have with them, the better off you are. And a Type II plus the annual (or more than annual) pen tests make a lot of the questioning less intense.
btw (happy to disclose personally, but I keep my identity private on hn), you can get the audit done for a lot less than $70k if you use a smaller firm, and that never was a problem with our customers.
Anyways: the point I'm making is: a Type 2 probably doesn't do anything more to prepare you for 27001 (which you should not get) than a Type 1 does. The subject matter of the assessments are the same (in fact, the Type 1 essentially sets the playbook for the Type 2, which is something you should be careful about).
Pentest reports can definitely mitigate security objections. T What's funny is that none of these certifications meaningfully require them. All the more reason not to pay much attention to them until you have to.
You should think of SOC2 and ISO 27001 as exotic sales expenses, not as something your startup needs to engineer against.
Each potential client has a unique generally quite substantial list of security/tech questions in several spreadsheets. You answer each one as well as possible, and give details. This is definitely not an intern gig: at my fintech startup we had the CEO or Dir Eng or myself (DevOps) do it. Generally all of us took turns. They're pretty onerous.
Having done the work for the ISO-27001 helped. For that cert we'd already had to think about and document a ton of security related things. Potential clients were happy to take our internal docs (written for ISO) as details to their questions. If they actually read our docs or if it was just a checkbox requirement, that's a good question :)
If you're in a line of business where your customers have questionnaires, just plan on having someone whose job is to fill these things out.
However, having passed the certification process still save time.
So, you want to certify yourself as secure, yet you store data on other people's computers, and you don't know how they are protected?
Part of ISO27001 is proving that you’re supply chain is also ISO27001 compliant. So picking companies that are already certified makes that easy, because then the certification naturally recurses down your supply chain.
I do t think I know a single serious security professional that would raise an eye at using cloud resources. Quite the opposite, there is a fairly straightforward & repeatable process for securing cloud resources. Unlike on prem.
You can shut down deals that aren't outsourced by demanding more difficult stuff like viewing the manufacturing masks for the microcontrollers in the badge scanners. No not a generic mask for the CPU family or similar model of slightly different capacity, I mean the mask that was specifically used to make the specific chips in the individual badge scanners. You do audit that, don't you? Why can't I have the firmware to the chip in your usb keyboard, are you guys hiding something in there like a password grabber? Can you provide the source code of your on premises Cisco routers for our security review? Does Cisco know you can do that (LOL?)
Security is not a checkmark, its always been a spectrum, and if you want to torpedo a deal its always possible to crank up the demands until the other side quits. It may not be useful or provide a business advantage, but nothing is ever truly secure. Probably the AWS stuff is better than average, LOL.
I also wouldn't want deal with someone who tells me details that are not publicly available. If he tells me somebody else secrets, he will tell others my secrets.
There is no good answer to these questions except "this is not publicly available data".
That looks larger than all the other requirements.
For example, if anyone pays you through credit cards, PCI DSS is non-optional. Certain transactions of health information will require Hitrust. Without them, you won't be able to do business, and while they seem large (PCI DSS if you have another company handle the cards, is a very simple self-assessment.)
https://cloudsecurityalliance.org/artifacts/consensus-assess...
And this is certainly the truth:
> And no, you can't give this to an intern, or just search-and-answer most questions,
Ah, but the answer for major suppliers such as AWS and Azure, etc, is their own ISO 27001, SOC2, etc, certifications that you can defer that risk to.
But I'm sure it also depends what you're selling. We mostly sell marketing services and the risk is inherently low (we generally don't have access to any sensitive client data or systems).
Personally however I think that ISO and management systems solves a lot of the problems that most companies deals with, and it gives a structured way of setting goals and reaching them.
Secondly the certification is not the most important part. The certification proves that your management system works and that you are reaching your goals, but if your goals are shit then the certification rather proves that you are a shity company. In other words the certification in itself is not a quality badge.
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
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.
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.
1. No audits/certifications. Stay here until you're losing deals with big-ish companies to the point where it's worth investing $10-20k and ~200 hours into solving this.
2. SOC 2 Type 1. Takes about $10-20k/yr and 200 hours in my experience. If you use a platform like Drata it'll be a bit more money but less effort. This report satisfies a lot of security teams, and you have to get it once per year. The 2nd/3rd time is way less time investment than first. Stay here until you're losing deals over not having SOC 2 Type 2 / ISO27001.
3. SOC 2 Type 2. Takes about $15-30k/yr. If you've done SOC 2 Type 1 it should only take 80 hours or so to get. Again, platforms like Drata cost more but make this easier.
4. ISO27001. If SOC 2 Type 2 isn't enough for your big enterprise customers to buy, this is the next step. There's a lot of overlap between SOC 2 Type 2 and ISO27001, but ISO27001 definitely introduces some new controls. Drata can help with this as well, but pricing might go up to something more like $50k/yr for SOC 2 Type 2 + ISO27001.
If your company's very first sales will be enterprise deals, you may need to get SOC 2 Type 1/2 from the beginning. If you're starting out with SMB and eventually moving upstream, you could probably wait a few years before getting SOC 2 Type 1/2.
If a customer is asking "do you have ISO27001 certification?", saying "no" to that isn't (necessarily) damning. It might just mean they want you to fill out their security questionnaire. These can be time consuming, so you can even get around this by filling out a VSA Core once (standardized questionnaire) and trying to send them that instead of filling out each customer's custom questionnaire.
We work with companies doing B2B sales and looking for help with compliance certifications like ISO 27001 and SOC 2. Some folks come to us early but most come with a deal on the line — which is to say, this is a process you can start “just in time” if you must.
From what I’ve seen, saying “no I won’t go through your security review process” is an (obvious) dealbreaker, but there’s a lot of ways to get through that process: ISO cert, SOC 2, the promise to get either of those certs by your go-live/implementation date, security questionnaire hell, etc.
As mentioned previously, ISO is preferred by European companies; SOC 2 is more likely to be mandated by American companies, and you’re likely to get pretty far, even in Europe, on just a SOC 2. If I had to construct the situation that’s most likely to be deal-breaking, it’d be an old-school European company that’s operating off a rigid flow chart: “if no ISO 27001 cert, go back to start. Do not pass Go. Do not collect $200.”
A few folks have mentioned cost (dollar and organizational) — ymmv and/but the cost of obtaining ISO 27001 certification varies with the number of employees, say $10-20k for smaller companies. Implementing ISO 27001 and an ISMS can be blitzed by small teams in a few weeks but probably will take a couple of months to a year for larger organizations.
(And we’d love to help if you decide to pursue this at Vanta etc etc)
Also in the space:
- Drata
- Laika
- Tugboat
- Kintent
Thanks Christina and the Vanta team for making the SOC2 compliance process… digestible :)
Many customers will send you a huge questionnaire to understand your security posture, policies and procedures. You’ll quickly realise that these questionnaire are pretty much what an ISO27001 auditor will ask. So if you have ISO27001, then you can just copy and paste.
It’s much easier to become ISO27001 compliant early, before you have much built. It allows you to take cookie cutter policies and procedures from companies like Laika and apply them wholesale with only minor tweaks, and without the need to make technical changes, because there’s nothing to change. However the process is both expensive and time consuming, so make sure it’s something your customers will expect.
Finally, pay someone else to walk you through the process. I’ve used the company heylaika.com, it removes so much overhead and the need to read the standard in detail. Trying to go it alone will just be a huge waste of time and money, you’ll end up paying for expensive audits that you’ll fail. Getting external help in makes sure you’ll actual pass the audit before you pay an auditor.
Thus, a lot of times, to sign customers, you need to be secured, as an IT/Security department can easily shut down any SaaS project if it is not secure enough. Having a certification like ISO 27001 or a report like SOC2 can really be helpful, and is sometimes a necessity. So ask yourself "does our company needs a SOC2/ISO 27001 to sign customers? Is it a blocker for our business?". You never want to achieve compliance "just because", you need a business reason to do it.
We started building our security program (ISMS) based on ISO 27001 (which is a really good basis in my opinion), but decided to get a SOC2 report instead. We started with a SOC2 type I report, then a type II. I personally find that a SOC2 is much more flexible than an ISO 27001 certification.
We mainly deal with big European customers, and SOC2 and ISO 27001 are seen as equal; never had a problem there. Most customers don't even read the report to be honest; it's a check in a box.
Having a SOC2 report or ISO 27001 certification shows that you care about security, and it sets the tone from the start.
If you have an enterprise product, either you get the ISO cert, or give up some of your sales margin and leverage to be a "partner," to another vendor who does. e.g. If you are selling to a bank and you don't have it, it's likely the bank may ask a consultant from one of the big firms to "recommend," your product as part of an engagement, and the compliance risk nominally shifts onto them, which is super not-cheap. I'd start discussions with VaRs and consulting firms about partnering now in case you get a demand for it, just to be hedged.
However, as a security pro, I would almost never suggest it to a startup until they are much later stage, like B and C rounds, or above say, $20m ARR, and perhaps not even then. The reason for this is if you are still establishing PMF, ISO is an expensive distraction, same with FedRAMP. Pay for it out of profits only, or tack on the expense to a customer contract, as imo, it's a waste of precious runway.
Strategically, I think it's worth considering taking the revenue hit of partnering with a VaR or a big-N consulting firm early to grow your channel first, and who specializes in managing these dead weight regulatory burdens while you focus on building a product that grows fast enough that you can choose solve ISO yourself as an optimization problem later on when you are rolling in cash, and not as a strategic barrier. I'd venture that the lack of an ISO cert is not going to get in the way of an exit or early stage growth. It's an expense that I would punt to whoever acquires you. If you are acquiring companies, then maybe you're big enough to consider it.