A SOC 2 report tells a customer that an auditor reviewed your controls against a set of criteria and found them in place over a period of time. That is useful. It is not the same thing as being secure. We say this plainly because we watch companies treat the report as the goal, ship it to procurement, and assume the security question is now closed. It is not closed. SOC 2 sets a baseline of process and documentation. Attackers do not read your report. They probe your external surface, your APIs, your identity layer, and your cloud configuration, and none of those are guaranteed to be hard targets just because you passed an audit.
The point of this post is to draw the line cleanly. SOC 2 is the floor. It proves you have controls and that you operate them. Real security is the work you do on top of that floor, against a real adversary, on the assets that actually matter. We do both kinds of work, and the gap between them is where most breaches at audited companies happen. If you lead security or engineering at a regulated company, you should know exactly where your SOC 2 program stops protecting you and where active testing has to start. Our GRC practice runs the audit-readiness side, and our offensive teams run the side that finds what the audit never checks.
What SOC 2 actually attests to
SOC 2 is an attestation framework from the AICPA built on the Trust Services Criteria. Every report covers Security, which is the common criteria set, and a company can add Availability, Processing Integrity, Confidentiality, and Privacy depending on what it offers customers. A Type I report describes whether controls are designed appropriately at a single point in time. A Type II report tests whether those controls operated effectively across a window, usually three to twelve months. The auditor samples evidence, interviews staff, and issues an opinion. That opinion is about your control environment, not about whether a skilled attacker can get into your systems.
This distinction matters because the criteria are written at the level of governance and process. SOC 2 asks whether you have a vulnerability management program. It does not ask whether the specific authentication flow on your customer portal can be bypassed. It asks whether you restrict logical access. It does not ask whether an over-permissioned service account in your cloud account lets an attacker pivot from a single compromised function to your production database. The audit confirms the machinery exists. It does not confirm the machinery wins against pressure.
The gap between a clean report and a hard target
We have seen clean Type II reports sitting next to live findings that would end a company. The report was honest. The controls existed. The problem is that controls described on paper and controls tested under attack are two different states. A firewall rule set can be reviewed and approved while still leaving an administrative interface exposed to the internet. A code review policy can be followed while injection flaws ship to production because no one tested the running application. The audit reads the policy. The attacker reads the response from your server.
- SOC 2 confirms you have a vulnerability management process, but it does not run an authenticated penetration test that finds the chained flaws an automated scan misses.
- SOC 2 confirms you control access, but it does not check whether your identity provider configuration allows token replay, session fixation, or privilege escalation through a misconfigured role.
- SOC 2 confirms you monitor your environment, but it does not validate whether your detection actually fires when an attacker behaves like the techniques in MITRE ATT&CK rather than like a noisy scanner.
- SOC 2 confirms you manage your vendors, but it does not test whether a compromised third-party integration gives an attacker a path into your data.
- SOC 2 confirms you encrypt data, but it does not verify that the encryption is applied everywhere it should be, including backups, logs, and inter-service traffic.
An auditor confirms that a control is in place. An attacker tests whether it holds under real conditions.
Why regulated buyers stopped accepting the report alone
Procurement teams used to collect a SOC 2 report and move on. That is changing, and the regulatory pressure is the reason. The NIS2 Directive, formally Directive (EU) 2022/2555, puts personal accountability on management for cybersecurity risk measures and requires that essential and important entities manage risk across their supply chains. DORA, Regulation (EU) 2022/2554, has been in force since January 2025 and requires financial entities to run threat-led penetration testing and to manage information and communication technology risk continuously, not annually. A SOC 2 report does not satisfy either of these on its own. They expect demonstrated testing against real threats, and they expect it to be ongoing.
So sophisticated buyers now ask harder questions. They want to see your penetration test reports, not just your audit opinion. They want to know your remediation timelines. They want to know whether you tested the specific product they are buying. We help clients answer those questions honestly, and we wrote separate guides on NIS2 and DORA because the obligations differ and the testing requirements are explicit. If your security story ends at SOC 2, you will lose deals to companies whose story continues past it.
What real testing adds on top of the audit
The work that turns a control environment into a hard target is adversarial and technical. It is performed by people who try to break in, document exactly how they did it, and tell you what to fix. This is the difference between a penetration test and an automated scan. A scanner reports known signatures. A tester chains a low-severity information leak to an authentication weakness to a privilege escalation and walks out with your data. The audit never sees that chain because the audit was never trying to build it.
- Offensive testing finds the exploitable paths through your application, network, and cloud, and our offensive security work reports them with reproduction steps rather than severity labels alone.
- Application security testing maps your web and API surface against the OWASP Top 10 and the OWASP API Security Top 10, which our AppSec practice treats as a starting checklist rather than a finish line.
- Cloud and identity review checks the configuration that breaches actually exploit, including the quiet IAM risk that audits rarely surface because it lives in policy documents, not in interviews.
- Threat detection and response validation confirms your monitoring sees real attacker behavior, which is the gap our TDR practice closes by testing signal against the noise.
- External attack surface management tracks what you expose to the internet over time, because the surface that passed the audit in March is not the surface you run in September.
How the two programs fit together in practice
We run SOC 2 readiness and active testing as one program because they reinforce each other when sequenced correctly. The audit defines what you are supposed to do. The testing proves whether it holds. When a penetration test finds a flaw that your SOC 2 controls were supposed to prevent, you have learned something the audit could never tell you, which is that the control exists but does not work. That feedback loop is the entire value. A control that survives an audit but fails a test is a false sense of security, and false security is worse than known weakness because you stop watching it.
In a typical engagement we scope the audit boundary, map the assets that matter, and then run testing against those same assets so the results speak directly to the controls under review. The audit gives the testing a frame. The testing gives the audit teeth. We described the readiness side in our SOC 2 readiness guide, and the comparison work in SOC 2 versus ISO 27001 and SOC 1 versus SOC 2, because choosing the right attestation is its own decision before any testing begins.
The process we use to close the gap
Closing the gap between a report and a hard target follows a sequence. We do not start with a scanner and a checklist. We start by understanding what an attacker would want and how they would get it, then we test that path, then we fix it, then we test again. The order matters because remediation without re-testing is a guess.
- We scope against the assets that carry real risk, which means the systems that hold regulated data and the surfaces that face the internet, not an arbitrary IP range.
- We test those assets the way an attacker would, combining manual exploitation with tooling, and we document the full chain so your engineers can reproduce every finding.
- We rank findings by exploitability and business impact rather than by a raw severity score, because a medium-rated flaw on a critical asset often outranks a high-rated flaw on something isolated.
- We hand over remediation guidance written for engineers, with specific fixes rather than generic advice, so the work goes into a sprint instead of a backlog graveyard.
- We re-test after remediation to confirm the fix works and did not open a new path, and we keep the external surface under watch because it changes constantly.
Where SOC 2 maps to other frameworks
SOC 2 does not exist alone, and most regulated companies carry more than one obligation. ISO/IEC 27001:2022 defines a management system with 93 Annex A controls across four themes, organizational, people, physical, and technological. There is meaningful overlap between SOC 2 controls and ISO 27001 controls, which means readiness work for one reduces effort for the other. We track that overlap so clients do not pay twice for the same evidence. The ISO 27001 certification guide and our ISO 27001 compliance page lay out how the two fit.
For companies building AI products, the picture widens again. The EU AI Act adds obligations for certain systems, and securing language model applications introduces failure modes that no traditional audit anticipates, such as prompt injection that is genuinely exploitable rather than theoretical. Our AI security practice tests these systems directly, because a SOC 2 report on an AI product says nothing about whether the model can be manipulated into leaking data or executing unintended actions. Frameworks describe the shape of the obligation. They do not test the implementation, and that is consistent across every standard we work with.
Common mistakes that pass the audit and lose the breach
The failures we find most often are not exotic. They are ordinary gaps that an audit was never structured to catch, because the audit checks for the presence of a control and not the strength of its implementation under attack.
- Treating an annual penetration test as a compliance checkbox, scoping it narrowly to pass, and never testing the systems that actually carry the most risk.
- Accepting an automated scan in place of manual testing, which our breakdown of PTaaS versus pentest versus scanning shows leaves whole classes of flaws undiscovered.
- Assuming the audit period is the security posture, when the external attack surface and cloud configuration drift continuously between audits.
- Skipping API testing because the web application was reviewed, even though APIs now carry most of the sensitive traffic and follow a separate OWASP top ten for good reason.
- Closing findings without re-testing, so a remediation that did not actually work sits marked as resolved until an attacker proves otherwise.
Cost and effort, stated honestly
SOC 2 readiness and audit have a known cost structure, driven by the number of controls, the maturity of your existing processes, and the audit window. Penetration testing cost is driven by scope, depth, and the skill required, and we wrote a full breakdown in our penetration testing cost guide. The honest framing is that the audit is the smaller, more predictable expense, and the testing is where the real defensive value lives. Companies that invert this, spending heavily on audit theatre and minimally on testing, end up with a clean report and a soft target. That is the worst position to be in because it costs money and buys confidence without buying security.
The right budget treats the audit as overhead and the testing as the investment that protects revenue and reputation. A breach at a regulated company costs far more than any testing program, and under NIS2 and DORA it now carries personal management accountability. Spending to pass an audit while underspending on the testing that prevents incidents is a false economy that the regulations are specifically designed to punish.
If you hold a SOC 2 report and want to know how hard your systems actually are, the next step is to test the assets that matter and tie the results back to your controls. Our GRC practice runs the readiness and audit side, and our testing teams run the adversarial side that the audit never reaches. The two together turn a clean report into a defensible posture. Book a scoping call and we will map where your SOC 2 program stops and where real testing needs to begin.