Is SOC 2 a certification?

No, and the distinction has practical consequences. SOC 2 is an attestation engagement performed by a licensed CPA firm under AICPA standards, and the output is a report containing the auditor opinion, your description of your system and controls, and for a Type 2 the tests performed and their results. There is no certificate, no certification body and no accreditation scheme in the way ISO 27001 has one. It also means there is no pass or fail: an auditor can issue a report containing exceptions, and that report is what you hand to prospects. Companies coming from an ISO background frequently misunderstand this and are surprised that a control failure ends up documented rather than simply blocking issuance.

How long does SOC 2 take?

Remediation plus the observation window, and the window dominates. Getting controls designed and gaps closed is typically a matter of weeks to a few months depending on where you start. Then a Type 2 window runs commonly three to twelve months and cannot be shortened, because the point is that the controls genuinely operated for that period. Three months is the shortest window most auditors will accept and some enterprise buyers prefer to see a longer one. If a deal is blocked now, the usual path is a Type 1 to unblock it with a Type 2 window starting immediately, and we would rather set that expectation early than have you discover the timeline after committing to a customer date.

Why do you not publish what SOC 2 costs?

Because the number that matters most is not ours. A SOC 2 programme has two separate costs: the readiness and remediation work, and the CPA firm audit fee, which is set by the firm based on your scope, headcount, criteria in scope and the complexity of your systems. We do not control the second and it is frequently the larger. On top of that, readiness effort varies enormously with what already exists, and a company with mature engineering practice may need very little while a company with shared credentials and no offboarding process needs a great deal. Any published figure would be a marketing anchor rather than an estimate, so we scope first and tell you what it involves.

Which Trust Services Criteria should we include?

Security is mandatory. Beyond that, include what your buyers ask about and nothing else, because each additional criterion adds controls, evidence and audit effort permanently, not just once. For most Indian B2B SaaS the answer is Security alone, or Security with Confidentiality. Add Availability if you publish an uptime commitment or have availability terms in contracts. Add Processing Integrity if correctness of calculation is your product, which is common in payments, payroll and billing. Add Privacy only if customers are specifically asking about personal data handling, and note that it overlaps substantially with DPDP work you may already have ahead. The best evidence for this decision is the questionnaires already in your inbox.

What do auditors most commonly find?

Offboarding, consistently. Access that was not removed on the day somebody left, or was removed from the main identity provider but not from a SaaS tool nobody had on the list. Second is access reviews: a quarterly review that happened in three quarters out of four, and the auditor samples the fourth. Third is change management, usually a production change that went out without the approval the control description says it requires, often during an incident. All three are process rather than technology, all three are unglamorous, and all three are what the report will say if they slip. Technical controls fail comparatively rarely because they are enforced by systems rather than by people remembering.

Do we need a compliance automation platform?

Not necessarily, and we are careful about recommending one. These platforms genuinely help by pulling evidence automatically from your identity provider, cloud accounts and ticketing, which removes the monthly discipline problem that causes most exceptions. They also carry a recurring cost, take real effort to configure properly, and can create a false sense that compliance is handled when the underlying process is still broken. For a company with a small estate and good engineering hygiene, evidence collection wired into existing tooling works fine. For a company with many systems, several cloud accounts and a growing team, a platform usually pays for itself. We give you a straight answer for your situation rather than a default.

We are a small team. Is SOC 2 realistic for us?

Yes, and small teams often do better than mid-sized ones because the estate is simpler and everybody knows what is happening. The specific difficulty is segregation of duties, since criteria expect the person making a change not to be the sole approver, and in a five person engineering team that is genuinely hard. Auditors accept compensating controls here, such as documented peer review with evidence, or approval by a technical founder, provided the control is described honestly and operates. What does not work is claiming a segregation you do not have. Describe the compensating control and it is normally accepted.

Does SOC 2 satisfy the DPDP Act?

No. SOC 2 Security maps well onto the reasonable security safeguards Rule 6 of the DPDP Rules expects, and the evidence discipline transfers directly, so a SOC 2 organisation is meaningfully ahead. But SOC 2 says nothing about the obligations that make DPDP work: itemised notice, purpose-scoped consent, withdrawal, purpose-limited erasure, data principal rights inside ninety days, and breach notification to the Data Protection Board on the seventy two hour clock. Even the Privacy criterion, if you include it, is about honouring your own stated notice rather than about meeting an Indian statutory standard. Treat them as overlapping programmes and reuse the evidence, not as one discharging the other.

Can our report cover our Indian entity and our US entity?

Yes, if you scope it that way, and this comes up constantly with Indian companies that have a Delaware parent and an Indian delivery entity. The report describes a system, and the system can span entities, locations and teams. What matters is that the description is accurate and the controls genuinely operate consistently across everything in scope, which is the harder part when hiring practice, offboarding process and physical security differ between the two. We usually recommend harmonising the process before the window rather than describing two different ways of doing the same thing and hoping the sample is kind.

Can you do this remotely? We are not in Hyderabad.

Yes, and almost all of it is remote by nature. Readiness assessment, control design, remediation on cloud estates, evidence tooling and auditor liaison are all delivered over screen share and shared documents, and CPA firms themselves conduct most SOC 2 fieldwork remotely. Physical security controls are the only element where a site visit adds much, and for most software companies that portion is small. We are based in Gachibowli, Hyderabad and work with organisations across India. Initial enquiries get a reply within 4 business hours.

SOC 2 readiness, India

SOC 2 is not a certification you pass. It is an auditor describing, in writing, whether your controls actually worked.

There is no SOC 2 certificate and no certification body. A licensed CPA firm examines your controls against the AICPA Trust Services Criteria and issues a report containing their opinion, your control descriptions and, for a Type 2, the test results including anything that failed. That last part is what makes SOC 2 different: exceptions appear in the report your customers read. Preparation is about making sure the controls genuinely operated, not about assembling documents.

Book a SOC 2 readiness assessment See what readiness involves

SOC 2 Type 2 readiness preparation for Indian technology companies

Type 2What enterprise buyers ask for
SecurityAlways in scope, others optional
Observation windowSets your real timeline
A reportNot a certificate

What readiness actually involves

Seven things that decide whether the report comes back clean.

Most Indian companies pursuing SOC 2 are doing it because deals are blocked. That creates pressure to move fast, and moving fast is exactly what produces a report with exceptions in it. These are the pieces that determine the outcome, roughly in the order they matter.

Scope: which criteria, and which systems

Security is the common criteria and is always included. Availability, processing integrity, confidentiality and privacy are optional and each one adds controls, evidence and audit effort. The instinct is to include everything so the report looks comprehensive. The better move is to include what your customers actually ask about, which for most Indian SaaS is Security alone, or Security with Confidentiality and Availability. We scope against the questionnaires you are already receiving rather than against a hypothetical buyer.

Type 1 or Type 2, and the window that follows

Type 1 attests that controls were suitably designed at a point in time. Type 2 attests that they operated effectively across an observation window, commonly three to twelve months. Enterprise procurement generally wants Type 2, and the window is the part nobody can compress: the controls have to genuinely run for that period. A common and sensible path is Type 1 first to unblock a deal, with Type 2 following on a window that starts immediately.

Control design against the Trust Services Criteria

The criteria describe outcomes rather than prescribing implementations, which is why two companies can both satisfy them very differently. You define the controls, and the auditor tests what you defined. That freedom is an advantage and a trap: controls written more ambitiously than your organisation can sustain become exceptions when the auditor tests them. We write control descriptions that match what you will actually do every month.

Evidence that accumulates rather than gets assembled

For a Type 2 the auditor samples across the whole window, so evidence has to exist for the period, not be produced at the end. Access reviews with dates and approvers, onboarding and offboarding tickets, change approvals, vulnerability scans and their remediation, incident records, backup restore tests, security training completions, vendor reviews. Retrofitting these after the window has run is the single most common reason a first Type 2 comes back with exceptions.

The technical controls, mostly on what you own

Access control with least privilege and MFA, logging and monitoring with alerting, encryption in transit and at rest, vulnerability management, change management with segregation of duties, and backup with tested restore. On a Microsoft or cloud-native estate a large share of this is configuration on entitlements already held. We check licensing before recommending purchases, and most readiness engagements need no new security product.

The people and process controls that fail most

Auditors reliably find their exceptions in the human half rather than the technical one. Offboarding that did not remove access on the day, access reviews that were skipped for a quarter, background checks not performed, security training with incomplete attendance, a risk assessment done once at the start of the window and never revisited. These are unglamorous and they are what the report will say if they slip.

Auditor selection and management

The report is only as credible as the firm signing it, and your enterprise customers will notice who did. We help you select a CPA firm appropriate to your size and sector, prepare the control matrix and evidence package in the form auditors expect, act as the technical interface during fieldwork, and work through requests so your engineers are not answering the same question five ways. We are not a CPA firm and cannot issue the report.

Mapping to what comes next

SOC 2 evidence overlaps heavily with ISO 27001, with DPDP Rule 6 safeguards, and with the customer security questionnaires that probably started this. We record the mapping while building so the same access review serves several purposes. Companies that treat each framework as a separate programme end up running the same control three times and evidencing it three ways.

The five criteria

What each Trust Services Criterion covers, and whether you need it.

Security is mandatory. The other four are choices, and each one you add extends the control set, the evidence burden and the audit. Choose against what your buyers ask for, not against completeness.

	Criterion	What it covers
Security (common criteria)	Protection against unauthorised access, disclosure and damage. Access control, change management, risk assessment, monitoring, incident response, vendor management.	Always. It is not optional and it is the bulk of the work.
Availability	The system is available for operation and use as committed. Capacity, backup and recovery, incident handling, environmental protections.	You publish an uptime commitment or have availability terms in customer contracts.
Confidentiality	Information designated confidential is protected as committed. Classification, encryption, access restriction and defined disposal.	Customers entrust you with data they consider commercially sensitive, which is most B2B SaaS.
Processing integrity	Processing is complete, valid, accurate, timely and authorised. Input validation, error handling, output reconciliation.	You process transactions or calculations where correctness is the product, such as payments, payroll or billing.
Privacy	Personal information is collected, used, retained, disclosed and disposed of per your notice and criteria.	You process significant volumes of personal data and customers ask about it. Overlaps with DPDP work.

Why bring us in

The gap is usually operational, not technical.

We assess before the window starts

The highest-value moment in a SOC 2 programme is before the observation window opens, because that is the last point at which a gap costs you effort rather than an exception in the report. We run readiness first, honestly, and we would rather tell you to delay the window by a month than watch a control fail in testing.

Microsoft Partner, so the technical half is mostly configuration

Access control, MFA, logging, encryption, device compliance and vulnerability management map onto Entra, Intune, Defender and Purview, which most Indian companies already hold through their licensing. We check entitlements before proposing tooling, and the majority of readiness work turns out to be process and evidence rather than product.

We build evidence collection into how you already work

Evidence that requires somebody to remember a monthly task will eventually not happen, and the auditor samples the month it did not. We wire collection into the systems your team already uses, tickets, pipelines, identity, so the artefact is a by-product of the work rather than an additional chore.

We tell you when SOC 2 is the wrong first move

SOC 2 is the right answer when American enterprise buyers are blocking deals. It is frequently the wrong first move for a company selling into Indian enterprise, Europe or government, where ISO 27001 is what appears in the RFP. We will point you at the comparison and say so, including when that means a smaller engagement for us.

Who needs this

What is driving SOC 2, by situation.

Indian SaaS selling to US enterprise

The dominant case. SOC 2 has become a procurement gate rather than a differentiator, and the deals it blocks are usually well advanced by the time anybody discovers the requirement.

Companies losing deals at security review

The pattern is recognisable: months of good conversations, then a questionnaire from the customer security team and a request for a SOC 2 report. Readiness is urgent, which is exactly when shortcuts get taken.

Fintech and payments

Frequently needing Processing Integrity alongside Security, because correctness of calculation is the product. Often also carrying sectoral obligations that overlap substantially with the control set.

Infrastructure and API businesses

Availability tends to be in scope because uptime commitments are in the contracts. Capacity management and tested recovery become audit subjects rather than internal concerns.

BPO and managed service providers

Handling client data under master services agreements that increasingly name SOC 2 with a date. Scope conversations centre on which delivery centres and which client environments sit inside the boundary.

Companies renewing an existing report

Year two is usually easier and it is not automatic. Estates drift, teams change, and a control that operated cleanly last window can quietly stop. We are often brought in after a renewal came back with exceptions the first report did not have.

Where exceptions come from

The six controls that fail in testing, and what to do before the window.

Auditors find their exceptions in remarkably consistent places, and almost never in the technical controls, because those are enforced by systems rather than by people remembering. These are the six we check hardest during readiness, in the order they cause trouble.

Offboarding that did not happen on the day

The single most common exception. Somebody left, the identity provider account was disabled a few days later, or was disabled promptly while access to a SaaS tool outside the identity provider persisted for weeks. The auditor samples leavers and checks dates.

Trigger offboarding from the HR event, not from somebody remembering
Maintain a list of every system granting access outside your identity provider
Keep the ticket as evidence, with timestamps, for every leaver in the window

An access review that skipped a quarter

Quarterly reviews performed in three quarters out of four, and the auditor samples the fourth. This is a discipline failure rather than a capability failure, and it is why we wire the review to a recurring calendar obligation with a named owner rather than to good intentions.

Name an owner and a deputy, because the owner will be on leave one quarter
Record who reviewed, what they saw, and what changed as a result
A review with no removals in a growing company invites a follow-up question

A production change without the approval you described

Usually during an incident, when the process is bypassed for good operational reasons and never retro-documented. Your control description says changes are approved; the auditor finds one that was not, and the exception is written.

Write an emergency change path into the control description from the start
Retro-approve emergency changes within a defined window and record it
Do not describe a stricter process than you will follow under pressure

Backups that were never restored

A backup job succeeding is not evidence that data can be recovered, and auditors increasingly ask for a restore test rather than a backup report. Companies that have never restored discover the gap during fieldwork, which is the wrong moment.

Restore something real to an isolated location and time it
Record who performed it, what was restored and how long it took
Repeat at a defined interval across the observation window

A risk assessment done once and never revisited

The criteria expect risk assessment to be an ongoing activity. A register created at the start of the window and untouched for nine months tells the auditor it was produced for the audit rather than used by the business.

Revisit at a defined cadence and after significant change
Record decisions, including risks you consciously accepted
Tie new risks to the incidents and near misses you actually had

Security training with incomplete coverage

Training exists, it was delivered, and a handful of people never completed it, usually recent joiners or somebody who was on leave that week. The auditor asks for completion records across the window and the percentage is what gets tested, not the fact that a programme exists.

Track completion by person, and chase the tail rather than reporting an average
Include contractors and anybody else with access to systems in scope
New joiners need it within a defined period of starting, and that gets sampled

Logging that does not cover the window

A retention period shorter than the observation window means the auditor cannot test the early months, and neither could you if something had happened then. This is quietly common because default retention on cloud tenants is frequently well under a year.

Set retention to at least the observation window before it starts
For Indian entities, align this with CERT-In and DPDP expectations at the same time
Confirm alerting exists, since logs nobody watches answer only half the question

Vendor assessments nobody performed

You are asked to do to your subprocessors what your customers are doing to you. Companies frequently have a vendor management policy and no evidence of a single assessment, which is a documented gap rather than an omission.

Maintain a current subprocessor list with what each one can access
Assess proportionately, a critical processor deserves more than a logging tool
Collect their SOC 2 or ISO certificate where they have one and record the review

The two reports

Type 1 against Type 2, and which one unblocks your deal.

Both are legitimate and they answer different questions. The mistake is assuming Type 1 will satisfy a buyer who asked for Type 2, which is a conversation better had before the audit than after.

Feature	Dimension	Type 1
What it attests	Controls were suitably designed	Controls operated effectively over time
Point of view	A single date	An observation window
Evidence needed	Design documentation and configuration	Operating evidence across the whole window
Time to obtain	Shortest path, once controls exist	Controls plus the full window, which cannot be compressed
What enterprise procurement wants	Sometimes accepted as an interim	The usual requirement
Risk of exceptions	Lower, design is easier to get right	Higher, because operation is tested
Typical use	Unblock a deal now, with Type 2 committed	The report you renew annually
Renewal	Not usually renewed on its own	Annually, with a rolling window

Exceptions go in the report, and your customers read it.

This is the structural difference between SOC 2 and a certification. There is no pass or fail. If the auditor tests a control and finds it did not operate as described, that exception is written into the report along with management response, and the report is what you hand to prospects. A report with several exceptions can be worse commercially than having no report yet, because it documents the gaps in a form your competitors do not have to produce. That is the argument for a readiness assessment before the window starts rather than optimism.

The auditor samples across the whole observation window, not just the end of it
Offboarding and access reviews are where exceptions most commonly appear
A control you cannot sustain monthly should not be in your control description
Fixing a gap before the window starts costs far less than explaining it in the report

The engagement

Five stages, and the window sits in the middle.

1
Scope against the questionnaires you are actually getting
Which criteria, which systems, which entities, and Type 1 or Type 2 first. We look at the security questionnaires and contract clauses driving the requirement, because those tell you what the buyer will accept far more reliably than a generic best practice answer will.
2
Readiness assessment against the Trust Services Criteria
An honest gap analysis before the window opens, covering both control design and whether the organisation can sustain the control monthly. Output is a remediation plan with owners, and a recommended window start date that is realistic rather than optimistic.
3
Remediate, and write control descriptions you can live with
Technical gaps configured, process gaps designed into how the team already works, and control descriptions written to match what will actually happen. This is where we push back on ambitious wording, because the auditor tests the description you gave them.
4
Run the window with evidence accumulating
The controls operate and the evidence builds. We check in through the window rather than at the end, because a missed access review found in month two is a correction and the same miss found in month nine is an exception.
5
Audit fieldwork and report
Evidence package assembled in the form the auditor expects, technical interface during fieldwork so your engineers are not repeatedly interrupted, and support through any findings. Then the renewal cycle, which is where most of the long-term value of doing it properly shows up.

Questions we get asked

SOC 2, answered plainly.

Around this decision.

SOC 2 vs ISO 27001

Which your buyers actually want, what each proves, and why the answer usually follows the geography of your pipeline.

Learn more

Security questionnaire response

The problem SOC 2 is often bought to solve, and how to handle the questionnaires arriving before the report exists.

Learn more

ISO 27001 implementation

The management system route, which is what Indian enterprise, European and government buyers usually name instead.

Learn more

Next step

Find the gaps before the window opens.

The cheapest moment to fix a control is before the observation period starts, because after that a gap is an exception in the report your customers read. Tell us what your buyers are asking for and we will tell you honestly where you stand. Remote-first from Hyderabad, serving all of India.

Book a SOC 2 readiness assessment Compare SOC 2 and ISO 27001

Related Services

Explore more solutions that work great with this service

SOC 2 is not a certification you pass. It is an auditor describing, in writing, whether your controls actually worked.

Seven things that decide whether the report comes back clean.

Scope: which criteria, and which systems

Type 1 or Type 2, and the window that follows

Control design against the Trust Services Criteria

Evidence that accumulates rather than gets assembled

The technical controls, mostly on what you own

The people and process controls that fail most

Auditor selection and management

Mapping to what comes next

What each Trust Services Criterion covers, and whether you need it.

The gap is usually operational, not technical.

We assess before the window starts

Microsoft Partner, so the technical half is mostly configuration

We build evidence collection into how you already work

We tell you when SOC 2 is the wrong first move

What is driving SOC 2, by situation.

Indian SaaS selling to US enterprise

Companies losing deals at security review

Fintech and payments

Infrastructure and API businesses

BPO and managed service providers

Companies renewing an existing report

The six controls that fail in testing, and what to do before the window.

Offboarding that did not happen on the day

An access review that skipped a quarter

A production change without the approval you described

Backups that were never restored

A risk assessment done once and never revisited

Security training with incomplete coverage

Logging that does not cover the window

Vendor assessments nobody performed

Type 1 against Type 2, and which one unblocks your deal.

Exceptions go in the report, and your customers read it.

Five stages, and the window sits in the middle.

Scope against the questionnaires you are actually getting

Readiness assessment against the Trust Services Criteria

Remediate, and write control descriptions you can live with

Run the window with evidence accumulating

Audit fieldwork and report

SOC 2, answered plainly.

Is SOC 2 a certification?

How long does SOC 2 take?

Why do you not publish what SOC 2 costs?

Which Trust Services Criteria should we include?

What do auditors most commonly find?

Do we need a compliance automation platform?

We are a small team. Is SOC 2 realistic for us?

Does SOC 2 satisfy the DPDP Act?

Can our report cover our Indian entity and our US entity?

Can you do this remotely? We are not in Hyderabad.

Around this decision.

SOC 2 vs ISO 27001

Security questionnaire response

ISO 27001 implementation

Find the gaps before the window opens.

Related Services

ISO 27001 Implementation

Security Questionnaire Response

Audit Readiness Assessment

Microsoft 365 Security Audit