ISO 27001 vs SOC 2: Which Does Your Business Need?

A prospect once forwarded us their vendor security questionnaire with a note that read, in full: we have SOC 2, do we still need ISO 27001? Their US customers were happy. Their new German buyer had gone quiet after asking for a certificate number they could verify. That silence is the whole story. SOC 2 and ISO 27001 are not two names for the same thing, and picking the wrong one first can cost you a deal cycle you will not get back.

Both frameworks prove you take information security seriously. But they were born in different places, produce different documents, are judged by different audiences, and expire on different clocks. Confuse them and you either over-spend on a badge nobody in your market asked for, or you turn up to a tender with the wrong paperwork. This is the practitioner view: what each one actually is, what the audit room actually feels like, what it costs in real rupees, and how to choose.

Start with origin, because it explains everything downstream. ISO/IEC 27001 is an international standard published by the International Organization for Standardization and the International Electrotechnical Commission. It is prescriptive about one thing: you must build and run an Information Security Management System, an ISMS, which is a documented, living set of policies, risk assessments, controls and reviews. You get certified against the standard by an accredited certification body.

SOC 2 is not a certification and not a standard in that sense. It is an attestation report produced under the AICPA, the American Institute of Certified Public Accountants, using their SSAE 18 attestation standard. A licensed CPA firm examines your controls against the Trust Services Criteria, the five categories being Security, Availability, Processing Integrity, Confidentiality and Privacy, and writes an opinion. You do not pass or fail in a binary sense. The auditor forms an opinion, and you hand the report to customers under NDA.

So one gives you a certificate the world can verify. The other gives you a detailed private report your buyer's security team reads line by line. That difference shapes who asks for which.

If you go the SOC 2 route, you will meet a fork that trips up first-timers. A SOC 2 Type I report tests whether your controls are designed correctly at a single point in time. It is a snapshot. A SOC 2 Type II report tests whether those controls actually operated effectively over a period, usually three to twelve months. Type II is what serious buyers want, because design without operation proves nothing.

Here is where teams burn a quarter. They rush a Type I to close one deal, then discover the enterprise buyer they really wanted has a procurement rule that only accepts Type II covering at least six months. Now the observation window has to run, and the calendar cannot be compressed. If your buyers are mid-market to enterprise, plan for Type II from day one and treat Type I only as a stopgap you can show while the window runs.

ISO 27001 has no such fork, but it has its own cadence. You get certified once, then live through annual surveillance audits in years two and three, then a full recertification in year three. The certificate stays valid across the cycle only if you keep passing surveillance. Miss a surveillance audit and the certificate can be suspended, which is worse in a tender than never having had one, because now there is a gap to explain.

Picture a Bengaluru SaaS company, forty people, selling to European retailers. Their German prospect asks for ISO 27001. The founders assume it is a document exercise: write some policies, get a stamp. Then the Stage 1 audit happens.

Stage 1 is a documentation review. The auditor reads the ISMS scope, the risk assessment, the Statement of Applicability, and the mandatory clauses. This is where reality lands. The auditor asks to see the risk treatment plan and finds a spreadsheet that was written last Tuesday, with every risk rated medium and every treatment set to accept. He asks who signed off the residual risk. Nobody. He asks for the internal audit report required by clause 9.2 and the management review minutes required by clause 9.3. They do not exist yet, because the ISMS has only been running for two weeks and you cannot audit or review something that has no history.

That is the moment the calendar truth hits. An ISMS needs to run long enough to generate evidence of itself. You need at least one internal audit cycle, one management review, and a few months of records showing the controls in Annex A are actually operating. The certificate is not the hard part. Producing three months of honest operational evidence before the Stage 2 audit is the hard part. The same logic applies to SOC 2 Type II: the observation window exists precisely so the auditor can watch your controls work, not just read that they exist.

For ISO 27001, the certificate is earned against the mandatory management clauses 4 to 10, and the controls live in Annex A. The 2022 revision reorganised Annex A into 93 controls across four themes: Organisational, People, Physical and Technological. You do not have to implement all 93. You justify inclusions and exclusions in the Statement of Applicability, and the auditor challenges your exclusions.

For SOC 2, the Security category, often called the Common Criteria, is mandatory. The other four are optional and you scope them in based on what you promise customers. If your contracts commit to uptime, add Availability. If you handle personal data, Privacy and Confidentiality earn their place. The auditor tests each in-scope criterion against your stated controls and, in a Type II, samples evidence across the whole window: access reviews, change tickets, incident records, backup restore tests.

Ballpark figures for an Indian small-to-mid company, splitting external audit fees from the internal effort and tooling that quietly dominates the total. Treat these as ranges, not quotes, because scope, headcount, number of locations and cloud footprint move them significantly.

Two honest observations. First, SOC 2 tends to run more expensive in India because the report must be signed by a CPA firm and the good ones charge in dollars. Second, the line that surprises founders is internal effort, not the audit fee. The evidence does not collect itself. Someone senior has to own access reviews, chase change tickets, and keep the risk register alive between audits.

Neither ISO 27001 nor SOC 2 makes you compliant with Indian law. This is the misconception we correct most often. If you process personal data of people in India, the Digital Personal Data Protection Act 2023, the DPDP Act, applies regardless of any badge on your website. ISO 27001 helps you evidence the security safeguards a Data Fiduciary is expected to maintain, and mapping your ISMS controls to DPDP obligations saves duplicated work, but the certificate is not a defence on its own.

Layer in sectoral rules. If you serve regulated financial entities, your buyer may be governed by the RBI, SEBI or IRDAI, and their outsourcing and IT governance directions push specific expectations onto you as a service provider. Any organisation operating in India is also within scope of the CERT-In directions of April 2022, which mandate reporting of specified cyber incidents within six hours and retention of logs for 180 days. ISO 27001 gives you the incident-management scaffolding for that, but you still have to configure the six-hour reporting workflow and the log retention explicitly. A SOC 2 report written for a US audience will not mention CERT-In at all.

Stop thinking about the framework and think about who signs the cheque. Your buyers and your markets decide this, not your CTO's preference. Run the question through where your revenue comes from and where it is going next.

The good news for anyone facing both: the overlap is large. The Trust Services Criteria and ISO 27001 Annex A share most of the same underlying controls, access management, change control, monitoring, incident response, vendor risk. If you build a proper ISMS first, roughly seventy to eighty per cent of the evidence a SOC 2 auditor wants is already sitting in your ISMS. Sequencing ISO 27001 first, then adding SOC 2, is usually cheaper than the reverse, because ISO forces the management system that SOC 2 assumes you already have.

Whichever way you go, do not book the external audit until these are genuinely true. Booking early to hit a date is the single most common reason first audits slip.

The company that had SOC 2 and lost the deal did not have a security problem. They had a proof problem. Their controls were fine. They simply held the wrong document for the market they were trying to enter. They ran ISO 27001 on top of the SOC 2 foundation they already had, reused most of the evidence, closed the deal the next cycle, and now lead tenders with a certificate number European buyers can verify in seconds.

Choose by buyer, sequence for reuse, and never book the audit before the evidence exists. If you want a second pair of eyes on scope, sequencing and the India-specific obligations that neither framework covers on its own, our CERT-In empanelled auditors do this hands-on with growing Indian companies every week and can tell you plainly which one you need first.