Penetration Testing for SOC 2: What Indian SaaS Companies Need Before Their Audit
Does SOC 2 need a penetration test? What the Trust Services Criteria say, what auditors expect from Indian SaaS companies, and a 90-day plan before your audit.
Penetration Testing for SOC 2: What Indian SaaS Companies Need Before Their Audit
Does SOC 2 need a penetration test? What the Trust Services Criteria say, what auditors expect from Indian SaaS companies, and a 90-day plan before your audit.
SOC 2 does not strictly require a penetration test. The AICPA's Trust Services Criteria mention penetration testing only once, as an example of an evaluation under criterion CC4.1. In practice, though, most SOC 2 auditors and enterprise customers expect a recent, independent pentest as evidence that your security controls actually work.
So the real question for an Indian SaaS company is not "do we need one?" It is "what kind of test will our auditor accept, and when should we run it?"
Why Indian SaaS companies end up here
The story is usually the same. A Bengaluru or Pune SaaS team lands its first large enterprise prospect. The security questionnaire arrives, and one line says "Please share your SOC 2 Type 2 report and latest penetration test summary."
SOC 2 is an attestation report issued by an independent CPA firm. It is not a certificate, and there is no government body in India that issues it. Your customer asks for it because it is the common language enterprise security teams use to judge vendors. That makes it a sales requirement as much as a security one.
Five myths about SOC 2 and pentesting
“SOC 2 makes pentesting mandatory.”
It does not. Penetration testing appears in one point of focus under CC4.1, listed alongside other evaluation types such as vulnerability scans and security assessments. Points of focus are guidance, not hard rules. But the criterion itself, CC4.1, asks you to evaluate whether your controls are working, and a pentest is the evidence most auditors expect for that.
“Our pentest also covers vulnerability scanning.”
This is the most common gap. Criterion CC7.1 is about detecting new vulnerabilities, and its point of focus describes vulnerability scans run periodically and after significant changes. A once-a-year pentest gives you CC4.1 evidence, but your auditor will usually still ask for scan results under CC7.1. Plan for both.
“Any pentest report will do.”
Auditors look for independence, a clear scope, risk-rated findings and proof that you fixed them. A scanner export with a new cover page is unlikely to satisfy a careful auditor.
“We can test after the audit starts.”
For a Type 2 report, the auditor checks how your controls operated over a period of time. If the pentest happens late, or critical findings are still open, that shows up in the report.
“SOC 2 makes us compliant with Indian law.”
SOC 2 is a voluntary attestation framework. It does not replace your obligations under Indian laws and rules, such as the DPDP Act or the CERT-In Directions, and it does not replace any sector regulator's requirements.
Type 1 or Type 2: when the pentest matters most
A SOC 2 Type 1 report looks at whether your controls are designed properly at a single point in time. A Type 2 report checks whether they actually worked over an observation period, often several months.
For Type 1, a pentest close to the report date shows your design holds up. For Type 2, timing matters more. Run the pentest early in or just before the observation period, fix what it finds, retest, and keep evidence of each step. Teams that ship often should also show that new releases get tested, not only the system as it looked on one day. Continuous pentesting gives you that trail through the year.
What the auditor actually wants to see in your report
Before you accept a pentest report, check that it has these six things:
Matches your SOC 2 system description: the product, APIs, cloud environment and admin panels.
Clear testing methods, standards followed, and exact execution dates.
Identifies who tested with proof they are independent of your engineering team.
Each finding documented with a severity rating (CVSS) and proof-of-concept impact.
Verified remediation status proving that high and critical findings were resolved.
A concise executive overview suitable for non-technical auditors and customer security leads.
SecurityLit's VAPT methodology includes a compliance mapping step that aligns findings with SOC 2 Trust Services Criteria, covering Security, Availability and Confidentiality, and provides audit-ready evidence with remediation guidance. Reports include an executive summary for leadership and technical detail for engineers.
Do not forget the systems your auditor will ask about
Indian SaaS teams often test only the product and forget the tools that run the company. SOC 2 access controls cover more than your app. Your email and identity setup, file sharing and admin accounts are part of the picture.
If your company runs on Google Workspace, a Google Workspace configuration review checks sharing settings, admin roles and login protection. The same applies to Microsoft 365 users with our Office 365 security assessment.
What a SOC 2 pentest scope looks like for a SaaS product
Most Indian SaaS products are multi-tenant, which means many customers share the same application and database. That makes tenant isolation the first thing an enterprise buyer worries about, and the first thing a good pentest should prove.
A typical SOC 2 scope for a B2B SaaS product covers:
- Tenant isolation: can a user in Company A read, change or export Company B's data by changing an ID or a header?
- Roles inside one tenant: can a normal user reach admin settings, billing or user management?
- Login and SSO: password reset, session handling, and any SAML or OAuth sign-in your enterprise customers use
- Public APIs and webhooks: that customers or partners connect to
- Cloud hosting accounts: the AWS or Azure accounts hosting production, including storage permissions and exposed services
- Internal admin or support panels: that your own staff use to manage customer instances
Write this scope down and make sure it matches the system description in your SOC 2 report. A mismatch is one of the easiest things for an auditor to question.
A 90-day pentest plan before your SOC 2 audit
This is a practical example. Adjust the dates to your auditor's timeline.
Gap check
Compare your current controls with the Trust Services Criteria in scope. A compliance pre-assessment shows what is missing before you spend on the audit. compliance pre-assessment
Set up scanning
Start regular vulnerability scans so you have CC7.1 evidence building up over time across applications and infrastructure.
Penetration test
Test the product, APIs, cloud and admin interfaces in your SOC 2 scope. Grey box testing with real test accounts usually covers more of a SaaS app in the same time, because testers do not spend days just getting in.
Fix and retest
Close critical and high findings first. Retest to prove the fixes work. SecurityLit includes post-assessment support for remediation guidance.
Package the evidence
Collect the report, retest results, scan history and remediation tickets in one folder for your auditor.
If no one in your team owns security policies yet, a virtual CISO (vCISO) can set up the policies and risk management process SOC 2 expects.
Frequently Asked Questions
Is penetration testing required for SOC 2?
Not strictly. The Trust Services Criteria name penetration testing only as an example under CC4.1. Most auditors and enterprise customers still expect an independent pentest as evidence that your controls work.
How often should a SaaS company pentest for SOC 2?
The criteria do not set a frequency. Most companies test at least once a year and after significant changes to their product or infrastructure. Your auditor and customer contracts may ask for more.
Is a vulnerability scan enough for SOC 2?
Usually not on its own. Scans support CC7.1, and a pentest supports CC4.1. Most auditors want to see both.
Can an Indian security firm do the pentest for a SOC 2 audit?
Yes. SOC 2 does not require the pentest to be done by a firm in a particular country. The auditor cares that the tester is qualified and independent. The SOC 2 report itself must be issued by a licensed CPA firm.
Does SOC 2 replace ISO 27001 for Indian customers?
No. They are different frameworks. Some Indian and global buyers ask for ISO 27001, some for SOC 2, and some for both. A single pentest can often provide evidence for both if the scope covers each.
Preparing for a SOC 2 audit?
Book a free scoping call with SecurityLit or get an instant estimate for your SaaS application and APIs.
SOC 2 does not strictly require a penetration test. The AICPA's Trust Services Criteria mention penetration testing only once, as an example of an evaluation under criterion CC4.1. In practice, though, most SOC 2 auditors and enterprise customers expect a recent, independent pentest as evidence that your security controls actually work.
So the real question for an Indian SaaS company is not "do we need one?" It is "what kind of test will our auditor accept, and when should we run it?"
Why Indian SaaS companies end up here
The story is usually the same. A Bengaluru or Pune SaaS team lands its first large enterprise prospect. The security questionnaire arrives, and one line says "Please share your SOC 2 Type 2 report and latest penetration test summary."
SOC 2 is an attestation report issued by an independent CPA firm. It is not a certificate, and there is no government body in India that issues it. Your customer asks for it because it is the common language enterprise security teams use to judge vendors. That makes it a sales requirement as much as a security one.
Five myths about SOC 2 and pentesting
“SOC 2 makes pentesting mandatory.”
It does not. Penetration testing appears in one point of focus under CC4.1, listed alongside other evaluation types such as vulnerability scans and security assessments. Points of focus are guidance, not hard rules. But the criterion itself, CC4.1, asks you to evaluate whether your controls are working, and a pentest is the evidence most auditors expect for that.
“Our pentest also covers vulnerability scanning.”
This is the most common gap. Criterion CC7.1 is about detecting new vulnerabilities, and its point of focus describes vulnerability scans run periodically and after significant changes. A once-a-year pentest gives you CC4.1 evidence, but your auditor will usually still ask for scan results under CC7.1. Plan for both.
“Any pentest report will do.”
Auditors look for independence, a clear scope, risk-rated findings and proof that you fixed them. A scanner export with a new cover page is unlikely to satisfy a careful auditor.
“We can test after the audit starts.”
For a Type 2 report, the auditor checks how your controls operated over a period of time. If the pentest happens late, or critical findings are still open, that shows up in the report.
“SOC 2 makes us compliant with Indian law.”
SOC 2 is a voluntary attestation framework. It does not replace your obligations under Indian laws and rules, such as the DPDP Act or the CERT-In Directions, and it does not replace any sector regulator's requirements.
Type 1 or Type 2: when the pentest matters most
A SOC 2 Type 1 report looks at whether your controls are designed properly at a single point in time. A Type 2 report checks whether they actually worked over an observation period, often several months.
For Type 1, a pentest close to the report date shows your design holds up. For Type 2, timing matters more. Run the pentest early in or just before the observation period, fix what it finds, retest, and keep evidence of each step. Teams that ship often should also show that new releases get tested, not only the system as it looked on one day. Continuous pentesting gives you that trail through the year.
What the auditor actually wants to see in your report
Before you accept a pentest report, check that it has these six things:
Matches your SOC 2 system description: the product, APIs, cloud environment and admin panels.
Clear testing methods, standards followed, and exact execution dates.
Identifies who tested with proof they are independent of your engineering team.
Each finding documented with a severity rating (CVSS) and proof-of-concept impact.
Verified remediation status proving that high and critical findings were resolved.
A concise executive overview suitable for non-technical auditors and customer security leads.
SecurityLit's VAPT methodology includes a compliance mapping step that aligns findings with SOC 2 Trust Services Criteria, covering Security, Availability and Confidentiality, and provides audit-ready evidence with remediation guidance. Reports include an executive summary for leadership and technical detail for engineers.
Do not forget the systems your auditor will ask about
Indian SaaS teams often test only the product and forget the tools that run the company. SOC 2 access controls cover more than your app. Your email and identity setup, file sharing and admin accounts are part of the picture.
If your company runs on Google Workspace, a Google Workspace configuration review checks sharing settings, admin roles and login protection. The same applies to Microsoft 365 users with our Office 365 security assessment.
What a SOC 2 pentest scope looks like for a SaaS product
Most Indian SaaS products are multi-tenant, which means many customers share the same application and database. That makes tenant isolation the first thing an enterprise buyer worries about, and the first thing a good pentest should prove.
A typical SOC 2 scope for a B2B SaaS product covers:
- Tenant isolation: can a user in Company A read, change or export Company B's data by changing an ID or a header?
- Roles inside one tenant: can a normal user reach admin settings, billing or user management?
- Login and SSO: password reset, session handling, and any SAML or OAuth sign-in your enterprise customers use
- Public APIs and webhooks: that customers or partners connect to
- Cloud hosting accounts: the AWS or Azure accounts hosting production, including storage permissions and exposed services
- Internal admin or support panels: that your own staff use to manage customer instances
Write this scope down and make sure it matches the system description in your SOC 2 report. A mismatch is one of the easiest things for an auditor to question.
A 90-day pentest plan before your SOC 2 audit
This is a practical example. Adjust the dates to your auditor's timeline.
Gap check
Compare your current controls with the Trust Services Criteria in scope. A compliance pre-assessment shows what is missing before you spend on the audit. compliance pre-assessment
Set up scanning
Start regular vulnerability scans so you have CC7.1 evidence building up over time across applications and infrastructure.
Penetration test
Test the product, APIs, cloud and admin interfaces in your SOC 2 scope. Grey box testing with real test accounts usually covers more of a SaaS app in the same time, because testers do not spend days just getting in.
Fix and retest
Close critical and high findings first. Retest to prove the fixes work. SecurityLit includes post-assessment support for remediation guidance.
Package the evidence
Collect the report, retest results, scan history and remediation tickets in one folder for your auditor.
If no one in your team owns security policies yet, a virtual CISO (vCISO) can set up the policies and risk management process SOC 2 expects.
Frequently Asked Questions
Is penetration testing required for SOC 2?
Not strictly. The Trust Services Criteria name penetration testing only as an example under CC4.1. Most auditors and enterprise customers still expect an independent pentest as evidence that your controls work.
How often should a SaaS company pentest for SOC 2?
The criteria do not set a frequency. Most companies test at least once a year and after significant changes to their product or infrastructure. Your auditor and customer contracts may ask for more.
Is a vulnerability scan enough for SOC 2?
Usually not on its own. Scans support CC7.1, and a pentest supports CC4.1. Most auditors want to see both.
Can an Indian security firm do the pentest for a SOC 2 audit?
Yes. SOC 2 does not require the pentest to be done by a firm in a particular country. The auditor cares that the tester is qualified and independent. The SOC 2 report itself must be issued by a licensed CPA firm.
Does SOC 2 replace ISO 27001 for Indian customers?
No. They are different frameworks. Some Indian and global buyers ask for ISO 27001, some for SOC 2, and some for both. A single pentest can often provide evidence for both if the scope covers each.
Preparing for a SOC 2 audit?
Book a free scoping call with SecurityLit or get an instant estimate for your SaaS application and APIs.