ISO 27001 vs SOC 2: Which One Does Your Business Actually Need?
The real difference between ISO 27001 and SOC 2 — who asks for which, what you actually receive at the end, why the two overlap far more than vendors admit, and how to avoid certifying the wrong thing.
Almost nobody pursues a security certification because they woke up wanting one. They pursue it because a customer, an investor or a procurement portal has made it a condition of doing business — and that is genuinely good news, because it means the right answer is knowable rather than a matter of taste.
Ask who is demanding it and what exactly they wrote. The answer is usually in an email from a procurement team, and it settles the question faster than any consultant can.
| ISO 27001 | SOC 2 | |
|---|---|---|
| Origin | International standard (ISO/IEC) | US auditing framework (AICPA) |
| What you receive | A certificate | An audit report you send to customers |
| Assessed by | An accredited certification body | A licensed CPA firm |
| Core question | Do you operate a working ISMS? | Are your controls designed and operating effectively? |
| Most demanded by | Enterprise, government, EU and global buyers | US buyers, especially of SaaS |
| Shareable with customers | Yes — the certificate is public-facing | Yes — but the report is confidential, usually under NDA |
| Type I vs Type II | Not applicable | Type I is a point in time; Type II covers a period |
| Recurring obligation | Annual surveillance, recertify every three years | Typically an annual report to stay current |
| Scope is chosen by you | Yes | Yes — you select which Trust Services Criteria apply |
The distinction that actually matters
ISO 27001 certifies a system. It asks whether you operate an Information Security Management System — whether you identify risks, decide what to do about them, do it, check that it worked, and improve. The certificate says: this organisation runs a functioning management system for security.
SOC 2 reports on controls. A CPA firm examines the controls you claim to have and issues an opinion on whether they were designed appropriately and — in a Type II — whether they actually operated over a period, typically several months to a year. The output is not a certificate but a report, often long, which you hand to a customer under NDA.
That difference in output explains most of the confusion. One is a badge you can display. The other is a document you send to a buyer who asked for it.
Who asks for which
Geography and buyer type decide this far more often than anything about your technology. If you sell software to United States companies, SOC 2 is what their procurement and vendor-risk teams will ask for by name, and offering ISO 27001 instead will produce a polite request for SOC 2.
If you sell to enterprises, governments, financial institutions or European buyers, ISO 27001 is the more widely recognised currency. In the Kenyan market specifically, ISO 27001 is what we see written into tenders and enterprise vendor questionnaires; SOC 2 turns up when a client's customer base is American.
If both apply to you, they are not mutually exclusive, and the second one costs far less than the first.
They overlap more than anyone selling them admits
Access control, change management, encryption, vendor risk, incident response, logging and monitoring, onboarding and offboarding — the substance underneath both frameworks is largely the same set of security practices, because there is only one sensible way to run a secure organisation.
Doing one and then the other is therefore dramatically cheaper than doing two things from scratch. The evidence you gathered, the policies you wrote, the controls you implemented and the discipline of collecting proof that they operate — most of it carries across. The second framework is substantially an exercise in remapping what you already have and filling genuine gaps.
So if you can reasonably foresee needing both, sequence them deliberately rather than treating them as unrelated projects two years apart.
The mistake that costs the most
Certifying the wrong thing, thoroughly. We have watched organisations spend a year and a substantial budget achieving a certification that the customer who triggered the whole exercise did not actually require — because nobody went back and read the email.
Before you commit, do this: find the specific requirement. Which customer, which contract clause, which procurement portal, which exact words. Sometimes the answer is that a completed security questionnaire would have closed the deal. Sometimes it is that they want SOC 2 Type II and you were about to buy ISO 27001. Sometimes it is that the requirement was aspirational and nobody will check.
That conversation costs you an afternoon. Getting it wrong costs a year.
A note on who is allowed to certify you
For ISO 27001, the body that certifies you must be independent of whoever implemented your management system. Accreditation rules require that separation — which is why we implement and prepare organisations for certification, and an accredited certification body issues the certificate. Any firm offering to do both should give you pause, because the resulting certificate is worth less than the paper it is printed on.
SOC 2 is analogous: the report must be issued by a licensed CPA firm, not by the consultancy that helped you build the controls. The separation is the point of the exercise in both cases.
Key takeaways
- The right answer is usually written in your customer's procurement email — go and read it.
- US SaaS buyers ask for SOC 2. Enterprise, government and European buyers ask for ISO 27001.
- ISO 27001 gives you a certificate; SOC 2 gives you a report you share under NDA.
- The underlying security work overlaps heavily, so doing the second is far cheaper than the first.
- Whoever implements cannot also certify — that independence is the whole point.
Frequently asked questions
Can we do both ISO 27001 and SOC 2?
Yes, and organisations selling into both European and American markets often do. Because the underlying controls overlap substantially, the second framework costs considerably less than the first — much of the evidence, policy and control work carries directly across. If you expect to need both, plan the sequence deliberately rather than running two disconnected projects.
Is SOC 2 recognised in Kenya?
It is recognised, but it is not usually what Kenyan buyers ask for. In our experience ISO 27001 is the standard written into local tenders and enterprise vendor questionnaires. SOC 2 becomes relevant when your customers — or your customers' customers — are United States companies, which is common for Kenyan SaaS firms selling abroad.
What is the difference between SOC 2 Type I and Type II?
Type I asks whether your controls are appropriately designed at a single point in time. Type II asks whether they actually operated effectively across a period, typically several months to a year. Type II is meaningfully harder, and it is what serious buyers ask for, because it demonstrates the controls work in practice rather than merely existing on the day the auditor visited.
Which is faster to achieve?
It depends almost entirely on where you are starting, not on the framework. That said, a SOC 2 Type II requires an observation window — the auditor must watch your controls operate over a period — so there is an irreducible waiting element you cannot compress by working harder. ISO 27001 has no equivalent mandatory observation window, though it does require that your management system has genuinely been operating, including an internal audit and a management review.