When a SaaS vendor sends over their SOC 2 Type II report during enterprise procurement, a specific signal is being sent: we have had an independent auditor review our security controls, and we passed. The report is real. The auditor is real. The opinion expressed in it is genuine.
What is less clear what rarely gets discussed plainly in either the procurement conversation or the broader discourse around compliance is exactly what SOC 2 examines and what it does not. The framework covers certain categories of control with real rigor. It explicitly excludes others. And the controls it is most silent on are frequently the ones that determine whether an attacker with a valid account and a modified API request can access data they should not see.
This is not a criticism of SOC 2 as a framework. It is a useful standard that has improved the baseline security posture of thousands of organizations that went through the process of achieving it. The problem is not the framework itself but the organizational and market behavior that treats SOC 2 certification as a comprehensive security attestation when it is a more narrowly scoped instrument than that reading implies.
Understanding the scope precisely, not approximately is useful both for organizations building toward SOC 2 and for organizations evaluating vendors who hold it.
What SOC 2 Is and Where It Comes From
SOC 2 is a reporting framework developed by the American Institute of Certified Public Accountants. It specifies how service organizations should design and operate controls related to security, availability, processing integrity, confidentiality, and privacy. A SOC 2 audit produces a report that expresses an independent opinion on whether those controls were designed appropriately and, in the case of Type II, whether they operated effectively over a defined observation period.
The Trust Services Criteria the control requirements that SOC 2 auditors evaluate against cover five categories, called Trust Services Categories: Security (required for all SOC 2 reports), Availability, Processing Integrity, Confidentiality, and Privacy. Most SOC 2 engagements include only Security and one or two others depending on the organization's service and customer requirements.
The Security category the Common Criteria is where most of the controls that people associate with application security live. It covers logical access, change management, risk assessment, monitoring, and incident response. It is the category that most closely approximates what a technically oriented person might think of as "security controls."
Understanding what Common Criteria actually specifies at the level of what an auditor examines is where the scope of SOC 2 becomes concrete.
What SOC 2 Actually Audits
The Common Criteria are organized around nine control environment areas, ranging from control environment and communication to risk assessment and monitoring. Within each area, the criteria specify logical requirements controls that should exist without specifying precise technical implementations.
The controls that SOC 2 audits are assessing in a typical engagement:
Logical access provisioning and deprovisioning. The organization has a documented process for granting and revoking access to systems and data. Access is granted based on job function and the principle of least privilege. Access is revoked when employees leave or change roles. The auditor reviews the process documentation, samples access grant and revocation events, and verifies that the process was followed for sampled events.
Authentication controls. The organization enforces authentication requirements for access to systems containing in-scope data. Multi-factor authentication is enabled for systems with elevated risk. The auditor verifies that MFA is configured on relevant systems and samples evidence of MFA enrollment.
Change management. The organization has a process for managing changes to production systems. Code changes go through review before deployment. The auditor samples change records and verifies that the process steps were followed.
Risk assessment. The organization conducts periodic risk assessments to identify threats to the confidentiality, integrity, and availability of data. The auditor reviews risk assessment documentation and confirms the process was performed.
Incident response. The organization has an incident response plan and has tested it. The auditor reviews the plan and evidence of testing or actual incident response events.
Vendor management. The organization assesses the security posture of vendors that process in-scope data on its behalf. The auditor reviews vendor assessment documentation.
Monitoring. The organization monitors systems for anomalous activity and reviews logs. The auditor reviews monitoring configurations and log review evidence.
These controls are real and they matter. An organization that has implemented them thoughtfully has better security hygiene than one that has not. A vendor that has maintained these controls effectively over a twelve-month observation period has demonstrated operational discipline that is worth knowing about.
What SOC 2 Does Not Test
Here is where the gap between the compliance report and the application security question becomes concrete.
SOC 2 does not test whether your application has authorization vulnerabilities.
The Common Criteria require that access controls be implemented and that access be provisioned according to a documented process. They do not require an assessor to exercise your API endpoints and verify that authenticated user A cannot access user B's data. The authorization logic in your application code the part that determines, at the database query level, whether the person making a request is permitted to see the records being returned is outside the scope of what a SOC 2 auditor evaluates.
An application with a BOLA (Broken Object Level Authorization) vulnerability in every API endpoint that returns user-specific data can receive a clean SOC 2 opinion. The SOC 2 controls were in place: access was provisioned correctly, MFA was enabled, changes went through review. The authorization gap exists in the application logic, and application logic testing is not what SOC 2 covers.
SOC 2 does not test input validation, injection vulnerabilities, or business logic flaws.
The change management process ensures that code changes were reviewed. It does not ensure that the review caught SQL injection vulnerabilities, that input validation is applied server-side consistently, or that multi-step workflows cannot be bypassed by calling API endpoints out of order. These are application security concerns. SOC 2 audits process, not technical correctness of the output of that process.
SOC 2 does not test the security of the application's authentication implementation.
The Common Criteria require that authentication controls exist. They do not require a penetration test of the authentication flow to verify that it resists brute force, account enumeration, session fixation, token replay, or credential stuffing. The MFA that SOC 2 verified is enabled at the administrative level. The session token lifecycle, the password reset flow, and the OAuth implementation that handle actual user authentication are not tested by the SOC 2 engagement.
SOC 2 does not test the security of API endpoints and data access patterns.
An auditor reviewing change management evidence will verify that the API endpoint that was added in the most recent deployment went through the change review process. They will not send a request to that endpoint with modified parameters to see whether it leaks data from accounts other than the authenticated user's.
SOC 2 Type I versus Type II is a distinction that matters more than it appears.
Type I is an assessment of whether controls are suitably designed at a point in time. Type II covers whether controls operated effectively over an observation period typically six to twelve months. A Type I report is weaker assurance than Type II because it is point-in-time with no operational evidence. Some organizations display SOC 2 compliance badges based on Type I reports. The distinction is material and worth asking about specifically in vendor due diligence.
The Specific Language Auditors Use and What It Means
SOC 2 reports contain an auditor opinion expressed in specific, precise language. Reading that language carefully reveals exactly what is and is not being attested.
The opinion in a SOC 2 Type II report states that, in the auditor's opinion, the controls were "suitably designed to provide reasonable assurance" that the Trust Services Criteria were met, and that the controls "operated effectively" during the observation period.
Three phrases in that sentence carry more meaning than they appear to:
"Suitably designed" means the controls, as designed on paper and in configuration, are appropriate for the stated criteria. It does not mean they are complete, that they cover all possible attack vectors, or that there are no gaps between the designed controls and the actual security of the system.
"Reasonable assurance" is a term of art in auditing. It explicitly acknowledges that absolute assurance is not the standard being applied. Reasonable assurance means the auditor is satisfied that the controls are likely to work as intended in normal circumstances. It leaves room for controls to fail in ways that are not covered by the design.
"Operated effectively" means that the controls functioned as designed during the observation period that the processes were followed, that the configurations were maintained, that the evidence supports the conclusion that the controls were not merely designed but actually used. It does not mean the controls detected all security incidents, that no vulnerabilities existed in the application, or that no unauthorized access occurred.
How the Market Has Responded and Where That Response Falls Short
The market has developed several supplementary frameworks and practices in response to the acknowledged limitations of SOC 2. These are worth understanding because they represent genuine attempts to address specific gaps and because understanding what they do address helps clarify what remains unaddressed.
Penetration testing requirements in SOC 2 engagements. Many auditors now require evidence of penetration testing as part of the Common Criteria for change management and risk assessment. This is a meaningful addition. A penetration test exercising the application with attacker intent is closer to what is needed to assess application security than a review of change management documentation. The limitations, as discussed in the previous post in this series, are about cadence a point-in-time test that may be months old does not provide current coverage for an application that ships weekly.
SOC 2 Plus. Some audit firms offer additional criteria beyond the standard Trust Services Criteria covering cloud security frameworks, HIPAA controls, or additional technical controls. These extensions increase the scope of what is assessed but operate within the same audit methodology: evidence-based attestation of controls rather than technical testing of the running application.
Third-party security questionnaires. Enterprise procurement processes supplement SOC 2 with vendor security questionnaires that probe specific controls not covered by the standard framework. These questionnaires ask about application security testing, vulnerability management programs, API security practices, and other areas. They add coverage but rely on self-reported answers, which are subject to the same limitations as any self-assessment.
None of these supplements fully close the gap between SOC 2 as a process attestation framework and application security testing as a technical validation activity. They are improvements, not solutions.
Reading a SOC 2 Report as an Informed Buyer
For organizations evaluating vendors, the SOC 2 report is a useful starting point rather than an ending point. Reading it as an informed buyer means asking questions that the report structure invites but does not answer.
What is the observation period? A twelve-month Type II observation period is stronger evidence than a six-month period. A very recent start date may indicate that the organization is newer to formal controls. The period matters because controls that have operated effectively for a longer duration are more likely to represent genuine organizational practice rather than controls activated for the audit window.
What are the disclosed exceptions? SOC 2 reports disclose exceptions instances where controls did not operate as designed during the observation period. Exceptions are not automatically disqualifying, but they reveal where controls failed and whether the organization's response was adequate. An absence of exceptions in a large, complex organization should prompt a question about how thoroughly the auditor sampled zero exceptions in twelve months of complex operations can reflect excellent controls or a narrow sample.
What is in scope? The report specifies which systems, services, and data types are in scope. Infrastructure or services that are out of scope are not covered by the opinion, regardless of their security relevance. A vendor whose core product is in scope but whose data ingestion pipeline is not has a report that does not cover an architecturally important component.
What is not there? The most useful reading of a SOC 2 report is often the list of things the report does not address. Application-level vulnerability testing, API security assessments, and authorization control validation are not in the standard report. If those controls matter for your use case and for applications that handle sensitive data, they almost always do the absence of coverage is the information worth acting on.
What Honest SOC 2 Conversations Look Like
The most mature vendors and the most sophisticated buyers have learned to have honest conversations about what SOC 2 covers and what it does not.
On the vendor side, that means not using SOC 2 as a conversation-stopper in response to security questions. A customer asking about API authorization controls or input validation practices is asking about something the SOC 2 report does not address, and responding with "we're SOC 2 Type II certified" answers a different question. Organizations that use their SOC 2 report to deflect technical security questions rather than to supplement them are signaling something about how they think about security that is worth noting.
On the buyer side, it means asking questions that the SOC 2 report does not answer: what application security testing do you perform and at what cadence, how do you validate that authorization controls work correctly across your API surface, what is your process when an application vulnerability is discovered post-deployment. These questions probe the gap between compliance attestation and application security reality.
Closing: The Certificate and the Application Are Different Things
SOC 2 certification attests that an organization has implemented and operated a defined set of operational controls. That attestation is meaningful. An organization that has never thought systematically about access provisioning, change management, and incident response benefits from going through the process. The discipline of documenting and operating controls consistently has genuine security value.
What it does not attest is that the organization's application is free of exploitable vulnerabilities, that its API endpoints correctly enforce authorization, that its authentication implementation resists the attack patterns that practitioners actually use, or that its business logic cannot be subverted by requests that circumvent the UI.
These gaps do not exist because SOC 2 is poorly designed. They exist because SOC 2 is designed to audit organizational processes and controls at an institutional level, not to perform technical security testing of specific application implementations. Those are different activities serving different purposes. The confusion arises from using the output of the first to answer questions that only the second can address.
A vendor with a SOC 2 Type II report and a continuous application security testing program is telling you two different things: that their organizational controls have been independently verified, and that their running application is being actively tested for the vulnerabilities that organizational controls do not prevent. Both statements matter. The first without the second leaves a gap that the certificate does not acknowledge and that attackers are not obligated to respect.
The certificate is not theater. The mistake is treating it as the whole performance.
Axeploit addresses the gap that SOC 2 does not cover not by reviewing policies or sampling access logs, but by testing the running application the way an attacker would. It exercises API endpoints with attacker intent, validates authorization controls across real user workflows, and surfaces the vulnerabilities in application logic that compliance frameworks are not designed to find. For organizations that are SOC 2 certified and want to know what the certification left unverified, it provides the answer.
