SOC 2 and ISO 27001 Readiness for Indian IT Firms (2026)

Back to Insights

To prepare for SOC 2 in India, decide which report your customers need (Type 1 or Type 2) and which Trust Services Criteria categories are in scope, then run a gap assessment, fix the gaps and collect evidence that your controls work before a CPA firm examines them. Plan that work alongside Indian obligations, in particular the CERT-In directions of 28 April 2022 and the Digital Personal Data Protection Act, 2023.

Why Indian IT Firms Are Asked for SOC 2 and ISO 27001

If you sell software, managed services or outsourced IT to overseas customers, a security questionnaire usually arrives before the contract. Sooner or later it asks for a SOC 2 report or an ISO/IEC 27001 certificate. The customer wants independent proof that you protect their data, not just your word.

The AICPA (American Institute of CPAs) publishes the SOC 2 guide, and its Assurance Services Executive Committee established the Trust Services Criteria. In that guide to SOC 2 examinations it notes that customers and business partners often request a SOC 2 report from the service organization.

Customers also often ask for ISO/IEC 27001 certification, which relates to a structured information security management system. This guide explains what each one is, how they differ, and how to prepare for both without wasting effort. It is written for founders, CTOs and compliance leads at Indian IT firms. It is general information, not legal or audit advice.

What SOC 2 Is, in Plain English

SOC stands for System and Organization Controls. The AICPA describes SOC as a suite of service offerings that CPAs may provide. SOC 2 is the member of that suite that deals with security and related topics.

A SOC 2 examination is measured against the Trust Services Criteria. These are control criteria set by the AICPA's Assurance Services Executive Committee. The AICPA states that they are used to evaluate and report on controls over the security, availability, processing integrity, confidentiality, or privacy of information and systems. In plain English (our summary, not the AICPA's wording), the five areas cover the following:

• Security: protecting information and systems against unauthorised access and misuse.
• Availability: keeping the system available for operation and use as committed.
• Processing integrity: processing that is complete, valid, accurate and timely.
• Confidentiality: protecting information designated as confidential.
• Privacy: handling personal information in line with your commitments.

Who performs the examination matters. The AICPA guide is written for CPAs in public practice who perform SOC 2 and SOC 3 examinations. A February 2026 article in the Journal of Accountancy puts it plainly: SOC reports are examinations performed by CPAs, and because most of the new tool providers are not CPA firms, they cannot attest. In practice, this means a software tool can help you get ready, but only a CPA firm can issue the report.

The output is a report, not a certificate. The report describes your system and contains the auditor's opinion. The Journal of Accountancy notes that use of a SOC 2 report is generally restricted, so expect to share it with customers under controlled terms rather than publish it. A SOC 3 report covers the same areas but is a general-use report that can be shared publicly.

SOC 2 Type 1 vs Type 2

The Journal of Accountancy explains that SOC 2, like SOC 1, comes as a Type 1 or Type 2 report. In its description, a Type 1 report focuses on the description of the service organization's system and on the suitability of the design of its controls as of a specified date. A Type 2 report contains the same opinions plus an opinion on the operating effectiveness of the controls throughout a specified period. A SOC 2 report also includes a description of the auditor's tests of controls and their results.

Put simply, Type 1 asks "are the right controls in place today?" and Type 2 asks "did they operate effectively throughout the period?" If a customer needs assurance that your controls worked over time, a Type 1 report will not answer that question, so check what each customer asks for. A Type 1 report can be a useful first step while you build a track record.

What ISO/IEC 27001 Is, in Plain English

ISO/IEC 27001 is an ISO/IEC standard. The current edition, ISO/IEC 27001:2022, was published on 25 October 2022 as edition 3.0. Its official abstract says it specifies the requirements for establishing, implementing, maintaining and continually improving an information security management system (ISMS) within the context of the organization. It also includes requirements for the assessment and treatment of information security risks tailored to the needs of the organization.

In plain terms (our summary), an ISMS is the management side of security: the policies, roles, risk decisions, reviews and improvement cycle that keep security working over time. The abstract's emphasis on risk assessment and treatment means you need to understand your risks and decide how to treat them.

Two points from the abstract matter for readiness. First, the requirements are generic and are intended to apply to all organizations, regardless of type, size or nature. Second, excluding any of the requirements in Clauses 4 to 10 is not acceptable when an organization claims conformity.

Two companion standards help. ISO/IEC 27002:2022 provides a reference set of generic information security controls with implementation guidance, for use within an ISMS based on ISO/IEC 27001. ISO/IEC 27006-1:2024 sets requirements for the bodies that audit and certify an ISMS, in addition to the requirements in ISO/IEC 17021-1. In other words, your certificate comes from a certification body that is itself held to a published standard.

SOC 2 vs ISO 27001: Side-by-Side Comparison

The table below compares the two on the points that matter most when planning readiness. It deliberately gives no fixed durations, because timing depends on the drivers listed in the last row.

Which Should You Do First?

Start with what your customers and target markets ask for. Read the last ten security questionnaires and contracts you received. If they ask for a SOC 2 report, plan SOC 2. If they ask for an ISO/IEC 27001 certificate, plan ISO first. If they accept either, choose the one your largest prospects name most often.

Doing both is often practical, because the underlying work overlaps. Controls such as access reviews, change management, vulnerability management, vendor reviews, incident response and security training can usually be mapped to both. Build one control set and one evidence library, then map it to the Trust Services Criteria and to the ISO/IEC 27001 requirements. That avoids running two separate compliance programs.

A neutral framework can help you structure that single program. The NIST Cybersecurity Framework (CSF) 2.0 offers a taxonomy of high-level cybersecurity outcomes that can be used by any organization regardless of its size, sector or maturity. Its six Functions are Govern, Identify, Protect, Detect, Respond and Recover. NIST states that the CSF does not prescribe how outcomes should be achieved, which makes it a useful common language rather than a third audit.

Readiness Steps: A Practical Sequence

The steps below apply to both SOC 2 and ISO/IEC 27001. The order matters, because each step depends on the one before it.

1. Confirm the driver. Write down which customers or markets need the report or certificate, and which type. This keeps scope and budget tied to a real need.
2. Define the scope. List the products or services, systems, cloud accounts, offices, teams and key vendors that are in scope. For SOC 2, choose which of the five Trust Services Criteria areas to include. Include only the areas your customers actually rely on.
3. Assign ownership. Name an executive sponsor and an owner for each control area. NIST CSF 2.0 places this under Govern: the cybersecurity risk management strategy, expectations and policy are established, communicated and monitored.
4. Assess risk. Identify the threats to the in-scope systems and data, rate them, and decide how to treat each one. ISO/IEC 27001 includes requirements for risk assessment and treatment, and a documented risk process also helps you explain your SOC 2 control choices.
5. Run a gap assessment. Compare what you do today with the Trust Services Criteria and the ISO/IEC 27001 requirements. Record each gap with an owner and a target date.
6. Write the policies you actually follow. Keep them short and specific. A policy that nobody follows is a finding waiting to happen.
7. Fix the gaps. Typical work includes multifactor authentication, joiner-mover-leaver processes, logging and monitoring, backups and restore tests, vulnerability scanning, secure change management and vendor reviews.
8. Build evidence habits. Decide where each piece of evidence lives, who produces it and how often. Automate collection where you can.
9. Test yourself. Run an internal review or mock audit against your own control list, then fix what it finds before the real audit.
10. Select the auditor. For SOC 2, engage a CPA firm. For ISO/IEC 27001, engage a certification body. Agree the scope, the report type and, for Type 2, the period.
11. Operate, then get examined. For a Type 2 report, controls must run throughout the chosen period. For ISO/IEC 27001, the ISMS should be established, implemented and maintained, with continual improvement under way, before the certification audit.

What Evidence Auditors Typically Ask For

Auditors test evidence, not intentions. The list below shows the kinds of evidence a readiness program should produce. Exact requests vary by auditor and scope.

• Governance records: approved policies, an organisation chart with security roles, management review minutes and risk committee notes.
• Risk records: the risk assessment, the risk treatment decisions and their owners.
• System description: for SOC 2, management's description of the system, which the AICPA guide says is evaluated using its 2018 description criteria.
• Access evidence: user lists, access review sign-offs, onboarding and offboarding tickets, and multifactor authentication settings.
• Change evidence: change tickets, code review approvals and deployment logs.
• Operations evidence: vulnerability scan reports, patch records, backup and restore test results, and monitoring alerts with follow-up.
• Incident evidence: the incident response plan, incident tickets, post-incident reviews and records of any regulatory reports.
• People evidence: background check records where lawful, security awareness training completion and signed acceptable use policies.
• Vendor evidence: a vendor inventory, risk ratings, contracts with security clauses and copies of vendors' own SOC 2 reports or certificates.

India-Specific Obligations to Build In

Alongside customer requirements, Indian law adds its own obligations. A readiness program in India should build them into the same controls, so one process satisfies the auditor and the regulator.

CERT-In Directions of 28 April 2022

CERT-In, the Indian Computer Emergency Response Team, issued directions dated 28 April 2022 under section 70B(6) of the Information Technology Act, 2000. They apply to service providers, intermediaries, data centres, body corporate and Government organisations. Key requirements include:

• 6-hour reporting: cyber incidents of the types listed in Annexure I must be reported to CERT-In within 6 hours of noticing such incidents or being brought to notice about such incidents. The list includes unauthorised access, data breaches, data leaks, ransomware and attacks on cloud systems.
• Log retention: logs of all ICT systems must be enabled and maintained securely for a rolling period of 180 days within Indian jurisdiction.
• Time synchronisation: ICT system clocks must be synchronised with the NTP servers of the National Informatics Centre (NIC) or National Physical Laboratory (NPL), or servers traceable to them. Entities with ICT infrastructure spanning multiple geographies may also use another accurate and standard time source, but it must not deviate from NIC and NPL.
• Point of Contact: each entity must designate a Point of Contact to interface with CERT-In.

These map cleanly onto controls you need anyway. Add CERT-In reporting to the incident response plan and its escalation clock. Set log retention and storage location in your logging standard. Add NTP configuration to your system build baseline. An auditor will then see one incident process, not two.

Digital Personal Data Protection Act, 2023

The Digital Personal Data Protection (DPDP) Act, 2023 received the assent of the President on 11 August 2023. The government notified the DPDP Rules, 2025 in November 2025, and the Press Information Bureau states that the Rules introduce an eighteen-month period for phased compliance.

Your role under the Act decides your duties. A Data Fiduciary is a person who determines the purpose and means of processing personal data. A Data Processor processes personal data on behalf of a Data Fiduciary. Once in force, section 8 requires the Data Fiduciary to protect personal data, including data processed on its behalf by a Data Processor, by taking reasonable security safeguards to prevent personal data breach. In the event of a breach, it must give the Data Protection Board and each affected Data Principal intimation of the breach, in such form and manner as may be prescribed. A Data Fiduciary may engage a Data Processor only under a valid contract.

Section 1(2) of the Act states that it comes into force on dates the Central Government notifies, and that different dates may be appointed for different provisions. We could not verify from a primary source which provisions are in force on the date of writing (23 October 2026), so check the current Gazette notifications before relying on any date. The penalties are significant once they apply. The Schedule to the Act sets penalties that may extend to two hundred and fifty crore rupees for failing to take reasonable security safeguards, and to two hundred crore rupees for failing to notify the Board or affected Data Principals of a breach.

If you process data for overseas clients, one exemption deserves attention. Section 17(1)(d) covers personal data of Data Principals not within the territory of India, processed under a contract with a person outside India by a person based in India. For that processing, Chapter II (except section 8(1) and section 8(5)), Chapter III and section 16 do not apply. Section 8(5) is the reasonable security safeguards duty. Whether the exemption fits your work depends on your contracts and data flows, so take legal advice before relying on it.

For readiness, the practical step is a data map. List which personal data you hold, whose it is, where it is, and whether you act as Data Fiduciary or Data Processor for each flow. The same map supports the SOC 2 privacy and confidentiality categories and the ISO/IEC 27001 risk assessment.

Common Readiness Failures

The failures below are common risks in readiness work. Each one is avoidable.

• Scope that is too wide or too vague. Including every system makes the project slow. Leaving out a system that handles customer data makes the report less useful. Scope to the services customers actually buy.
• Template policies nobody follows. Auditors compare policy with practice. A copied policy that promises quarterly access reviews creates a finding if reviews never happen.
• Evidence gaps during the Type 2 period. Auditors may report exceptions where controls did not operate as described during the period. Missed reviews, unsigned approvals and lost tickets are the usual cause.
• Treating the tool as the audit. Compliance platforms help with evidence collection, but they cannot attest. The Journal of Accountancy article cited above reports concern among practitioners that "fast and easy" may come at the expense of quality and objectivity.
• Ignoring vendors. Cloud providers, payroll processors and subcontractors are part of your system. Collect their reports, review them and track any controls they expect you to operate.
• No owner after the audit. SOC 2 Type 2 and ISO/IEC 27001 both depend on controls running continuously. Without named owners, controls decay after the first audit.
• Forgetting local law. An incident plan without CERT-In's 6-hour clock, or log retention outside India, leaves a gap that a SOC 2 or ISO/IEC 27001 audit may not test, but a regulator can.

What a Readiness Engagement Typically Involves

A readiness engagement is preparation work done before the auditor arrives. It is separate from the audit itself: the SOC 2 examination is performed by a CPA firm, and ISO/IEC 27001 certification is performed by a certification body.

In general terms, a readiness engagement covers scoping workshops, a gap assessment against the Trust Services Criteria and ISO/IEC 27001, a risk assessment, a prioritised remediation plan, policy drafting, help with technical controls such as logging, identity and vulnerability management, and an evidence plan. It often ends with a mock audit. Technical remediation can be a large part of the work, especially for security monitoring, incident response and data protection controls. Firms that are also redesigning their IT operating model may combine readiness with IT consulting on governance, processes and compliance obligations.

Frequently Asked Questions

Sources

• AICPA & CIMA, 2017 Trust Services Criteria (With Revised Points of Focus, 2022): who sets the criteria and the five areas they cover.
• AICPA & CIMA, SOC 2 Reporting on an Examination of Controls at a Service Organization (guide overview): CPAs in public practice perform SOC 2 examinations; customers and business partners often request SOC 2 reports; SOC 3 reports are general use.
• AICPA & CIMA, System and Organization Controls: SOC Suite of Services: SOC as a suite of service offerings CPAs may provide.
• Journal of Accountancy, Explaining the 3 faces of SOC (June 2016): Type 1 and Type 2 definitions, SOC 2 restricted use and SOC 3 general use.
• Journal of Accountancy, Promises of 'fast and easy' threaten SOC credibility (February 2026): SOC reports are examinations performed by CPAs; tool providers that are not CPA firms cannot attest.
• IEC Webstore, ISO/IEC 27001:2022: official abstract, publication date and edition.
• IEC Webstore, ISO/IEC 27002:2022: reference set of generic information security controls.
• IEC Webstore, ISO/IEC 27006-1:2024: requirements for bodies providing ISMS audit and certification.
• NIST CSWP 29, The NIST Cybersecurity Framework (CSF) 2.0 (February 26, 2024): the six Functions and the Govern Function definition.
• CERT-In, Directions under section 70B(6) of the IT Act, 2000, dated 28 April 2022: 6-hour reporting, Annexure I incident types, 180-day log retention, NTP synchronisation and Point of Contact.
• The Digital Personal Data Protection Act, 2023 (No. 22 of 2023), Gazette of India, as published by MeitY: definitions, section 8, section 17 and the Schedule of penalties.
• Press Information Bureau, DPDP Rules, 2025 Notified (November 17, 2025): notification date and the eighteen-month phased compliance period.