September 10, 2026
Mastering IDOR: Finding Broken Access Control Behind Predictable IDs and UUIDs
Mastering IDOR: Finding Broken Access Control Behind Predictable IDs and UUIDs
Salman Khan
New Update: Our new blog is updated.
Free download
Fiza Nadeem is an SEO content writer at ioSENTRIX with 2.5+ years of experience in content writing, copywriting, and SEO.
SOC 2 penetration testing is an authorized, simulated attack on the systems inside your SOC 2 audit scope, run to give your auditor evidence that the security controls you describe actually work. The AICPA Trust Services Criteria never use the words "you must run a penetration test." They do name penetration testing as an example of the evaluations management uses to check its controls, and they do expect vulnerability scanning on a periodic basis and after significant changes. In practice, that is why most SOC 2 auditors ask for a pentest report. This guide explains exactly what SOC 2 requires, which criteria are involved, how Type 1 and Type 2 differ, how often to test, and what the auditor wants to see in the report.
No, not literally. SOC 2 does not contain a criterion that mandates a penetration test. What it contains is criterion CC4.1, which requires the entity to perform ongoing and/or separate evaluations to ascertain whether the components of internal control are present and functioning, with a point of focus stating that management uses a variety of evaluations "including penetration testing, independent certification made against established specifications (for example, ISO certifications), and internal audit assessments." It also contains CC7.1, whose point of focus says the entity "conducts vulnerability scans designed to identify potential vulnerabilities or misconfigurations on a periodic basis and after any significant change in the environment."
Two details matter. First, points of focus are guidance, not requirements: the Trust Services Criteria state that using the criteria "does not require an assessment of whether each point of focus is addressed." Second, the criteria themselves are mandatory, and an auditor must form an opinion on whether your controls are designed and operating effectively. A penetration test is the most direct evidence that they are. That is the gap between "not required" and "expected," and it is where most confusion about SOC 2 penetration testing requirements comes from. Our shorter explainer, Is penetration testing required for SOC 2 compliance?, covers the same question in brief.
SOC 2 penetration testing is a penetration test scoped to the system described in a SOC 2 report, performed by qualified testers against the applications, APIs, cloud infrastructure and networks that process customer data, and documented so that the findings, remediation and retest can be presented to a SOC 2 auditor as evidence for the Security criteria. It is not a different technique from any other penetration test. What makes it "SOC 2" is the scope, the timing relative to the audit period, and the deliverable.
SOC 2 itself is an AICPA attestation: a CPA firm performs an examination of controls at a service organization relevant to security, availability, processing integrity, confidentiality or privacy and issues a report that customers and business partners use to evaluate the service. The Security category is the common criteria and is included in every SOC 2 report; the other four categories are optional and add criteria on top. For the basics, see our glossary entry on SOC 2 and our comparison of SOC 2 vs ISO 27001.
Three Common Criteria are where a penetration test earns its place in a SOC 2 evidence file: CC3.2 (risk assessment), CC4.1 (monitoring activities) and CC7.1 (system operations). A pentest report can support all three at once, which is why auditors ask for it even though no single criterion demands it.
CC3.2 requires the entity to identify and analyze risks to its objectives. Its point of focus expects the organization to identify its information assets, assess their criticality, identify threats from intentional and unintentional acts, and identify the vulnerabilities of those assets. A penetration test is a concrete, evidenced way to identify vulnerabilities in the assets that matter.
CC4.1 is the criterion that names penetration testing outright. The evaluations management uses to confirm controls are present and functioning are expected to include penetration testing alongside independent certifications and internal audit. If your control matrix says "annual third-party penetration test," this is the criterion it maps to.
CC7.1 requires detection and monitoring procedures that identify configuration changes introducing new vulnerabilities and susceptibility to newly discovered ones. Its points of focus cover configuration standards, infrastructure and software monitoring, change detection, detecting unknown or unauthorized components, and periodic vulnerability scans. Scans and penetration tests are different activities, and the criterion expects scanning; a pentest strengthens the evidence but does not replace a scanning program. Our post on vulnerability assessment vs penetration testing explains the line.
A SOC 2 Type 1 report covers the design of controls at a point in time, while a Type 2 report covers design and operating effectiveness over a review period, so a penetration test carries far more weight in a Type 2 examination. For Type 1, a pentest is optional evidence that a control such as "we test our applications" was designed and implemented by the report date. For Type 2, the auditor needs to see that the control operated during the period, which means a test performed inside the window, findings tracked to closure, and a retest or remediation evidence.
The review period for a Type 2 report typically runs from three months, common for a first report, to twelve months for recurring reports. If your period is twelve months and your control says "annual penetration test," the test must fall inside those twelve months, not the year before. Companies that time this wrong end up with an exception in the report or a scramble to squeeze a test in before the period ends. Our write-up on helping a HealthTech SaaS achieve SOC 2 with zero critical findings is one example of getting the sequence right.
At least once per audit period, and after any significant change to the systems in scope. SOC 2 sets no fixed interval, but the CC7.1 language of "periodic basis and after any significant change" is the standard auditors apply, and since recurring Type 2 periods are typically twelve months, an annual penetration test has become the working norm. A major release, a new cloud environment, a migration or an acquisition inside the period should trigger a targeted retest of what changed.
Annual testing is the floor, not the goal. A test in month one says nothing about the code shipped in month nine. Teams under SOC 2 increasingly pair an annual full-scope test with continuous penetration testing of new features, which produces a steady stream of dated evidence rather than a single report the auditor has to trust for a year.
The auditor wants a report that lets them tie a control statement to dated, independent evidence: who tested what, when, how, what they found, how severe it was, and proof that the serious findings were fixed. Auditors sample evidence; they do not re-perform the test. So the report has to stand on its own.
A report that satisfies most auditors includes a scope section listing the applications, APIs, IP ranges and cloud accounts tested and mapping them to the system description; test dates that fall inside the review period; the methodology and standards followed, such as the OWASP Web Security Testing Guide for web applications; findings rated by severity with reproduction steps and evidence; and a remediation section or a separate retest letter confirming which findings were closed and when. Auditors also want to see the tester was independent of the team that built the system, which is why an internal-only test is a harder sell than a third-party one. Our guide to penetration testing for compliance covers the deliverables in more detail.
A SOC 2 pentest should cover every system that stores, processes or transmits the customer data described in your system description, tested from the positions a realistic attacker would hold. For most SaaS companies that means the customer-facing web application and its APIs, the cloud infrastructure it runs on, any mobile app, and the external network perimeter. If the platform includes AI features, prompt handling and model access belong in scope too; see our guide to AI penetration testing services for what that adds.
Testing is usually gray box: the tester gets standard user accounts in at least two roles so that authorization flaws between tenants and privilege levels can be tested, which is where many of the most serious SaaS findings live. Our guide to web application penetration testing covers what that layer involves. Be wary of a proposal that tests one login page with a scanner and calls it SOC 2 penetration testing; a check-the-box test produces a report, not assurance.
No. A Type 1 report evaluates whether controls are suitably designed and implemented as of a date, so the auditor can often accept a policy, a signed engagement or a scheduled test as evidence that the control exists. Most companies still run a test before Type 1 because the same test then serves as evidence for the Type 2 period that usually follows, provided it falls inside that period.
No law requires SOC 2. It is a voluntary attestation that customers, especially enterprise buyers in the United States, ask for before trusting a vendor with their data. Once a customer contract or security questionnaire requires it, it becomes mandatory for you in practice, and the penetration test is usually the first piece of technical evidence they ask about.
Engage an independent penetration testing firm, scope the test to the systems in your SOC 2 system description, run it inside your review period, fix the high and critical findings, and ask for a retest confirmation. Hand the auditor the final report, the remediation tracker and the retest letter. If you use a compliance automation platform, upload the same documents as evidence against CC4.1 and CC7.1.
Not explicitly. The criteria do not say who performs the test. In practice, auditors give more weight to a test performed by someone independent of the team that built and operates the system, and enterprise customers reviewing your report tend to expect a third-party tester's name on it.
A scanning program is what CC7.1 explicitly expects, so you need one regardless. A scan alone is a weak answer to CC4.1, which asks whether controls are actually functioning; a scanner reports missing patches and misconfigurations but cannot chain a logic flaw into a cross-tenant data read. Most auditors will accept scans as part of the evidence and still ask for a penetration test.
ioSENTRIX is a CREST-accredited penetration testing firm, ISO/IEC 27001 certified and SOC 2 Type 2 attested, so we have been on both sides of this evidence request. We are not a SOC 2 auditor and do not issue reports; what we deliver is the penetration test your auditor asks for, scoped to your system description, run inside your review period, with findings mapped to the Common Criteria and a retest letter when the fixes are in. See our SOC 2 compliance solutions and penetration testing services. We do not tell your auditor a control exists; we show them what it stopped.
If your review period is already running and the test is not yet scheduled, talk to us this week rather than next quarter.
