Healthcare has been the most expensive industry for data breaches for fourteen consecutive years. Not one of the most expensive, but “the” most expensive industry when it comes to cyberattacks.
In 2025, the average healthcare breach cost reached $7.42 million. A number like that is nothing but scary, especially if you’re an SMB.
That is why organizations, which transmit data online and rely on cloud services, go for a reliable framework like SOC 2. Its security practices and rigorous audit provide confidence in a robust cybersecurity posture.
Probably the most reliable SOC 2 report is Type II. It tests your controls over a period of three to twelve months to prove that these controls do not just exist but work.
A SOC 2 Type II attestation check what was the control activity. Some sources say that usually a pentest adds a lot of value. It’s not mandated for SOC 2, but it’s the best way to test your controls.
Consider what happened to Catholic Health. Its business associate, Serviceaide, left an Elasticsearch database publicly accessible on the internet for around six weeks, exposing the PHI of 483,131 patients.
There was no sophisticated intrusion, just an authentication gap in the database’s API configuration that allowed unauthorized access to endpoints that should have been restricted.
That is precisely the gap a human tester probing your perimeter and API surface would find, and the kind of documentation a review never will.
This blog gives you a guide on how to maximize the value of your SOC 2 Type II report and why manual penetration testing in SOC 2 is the evidence auditors and enterprise buyers increasingly ask to see.
What Do the SOC 2 Type II Requirements for Healthcare Actually Cover?
SOC 2 is an attestation framework developed by the AICPA. It is not a law, and it is not a pass or fail certification. A licensed CPA firm examines your controls and issues an opinion.
That distinction matters in healthcare, where SOC 2 is often confused with HIPAA, (a federal law) and with HITRUST (a certifiable framework).
A SOC 2 report comes in two flavors. A Type I report evaluates whether your controls are suitably designed at a single point in time. A Type II report evaluates whether those controls actually operated effectively across a period, usually three to twelve months. For a healthtech vendor or a digital health platform selling into hospitals and payers, Type II is the report that buyers ask for.
To give a rundown of the framework, a SOC 2 Type II is built on the Trust Services Criteria. The Security category, known as the Common Criteria, is mandatory, while Availability, Processing Integrity, Confidentiality, and Privacy are added based on what you commit to.
Now you might think that penetration testing is never named as a line item in those criteria. But its fingerprints are all over them.
The SOC 2 control CC4.1 explicitly references penetration testing as one type of ongoing evaluation management should perform to confirm controls are present and working. CC7.1 works complementary to the above control and requires detection and monitoring procedures that identify new vulnerabilities and configuration changes that introduce them.
A pentest also speaks directly to controls CC6.1, which governs logical access, and CC9.1, which covers risk mitigation. For a Type II engagement specifically, the test must fall inside the observation window, because the auditor evaluating the evidence requires proof of the controls during the period.
But why does it matter so much? Let’s answer that.
Why Does Manual Penetration Matter in a Healthcare SOC 2 Type II Report?
A SOC 2 Type II report answers one question: did your controls operate effectively across the observation period? The word carrying the weight is “effectively.” An auditor is not grading whether a control exists. They are grading whether it works.
In the midst of this, a penetration test shows whether your controls actually stop someone from reaching the PHI. The SOC 2 attestation describes the control, and the pentest demonstrates it. The two thus work in tandem, making a strong case for the Type II report and the evidence behind it.
This is why auditors have a favorable opinion of pentest for SOC 2 Type II. A penetration test demonstrates that access controls, monitoring, and system defenses are functioning as intended, and it surfaces exploitable weaknesses before an attacker does. A scan or a generic report cannot show that.
Manual penetration testing in SOC 2 does not map to a single control. Rather, it supplies evidence across several criteria at once, from the ongoing evaluation CC4.1 expects to the vulnerability identification in CC7.1. Pentest is an independent engagement that is not just mapped to specific controls. This independence is part of what the auditor is measuring, and why A third-party test also carries more weight than internal ones.
There is a practical payoff healthcare teams feel directly. The goal of a SOC 2 Type II audit is to confirm that controls were designed, implemented, and operating effectively. Organizations that arrive without a pentest, or without documented remediation, tend to face friction and can struggle to earn a clean opinion from the auditor.
Running the test early, near the start of the observation window, lets you find exploitable issues before the auditor does, remediate them, and retest. You have to understand a working remediation plan is also part of the audit process. A pentest does not just add to the evidence package, but it also gives the auditor a favorable impression.
A SOC 2 Type II pentest also strengthens the risk assessment underneath everything else, too. Findings from your real environment replace hypothetical risk ratings with tested reality, which is the difference between a risk register an auditor trusts and one they question.
For any healthcare organization, earning the confidence of its clients and partners is the entire point of the document.
What Should a Healthcare SOC 2 Type II Penetration Test Cover?
Scope is the first thing an auditor checks. Your penetration test boundary must mirror the SOC 2 healthcare system description, covering every system that stores, processes, or transmits in-scope data.
For a healthcare organization, this includes applications, patient portals, the APIs behind them, supporting cloud infrastructure, internal networks, and the authentication systems that give access to PHI.
At minimum, a mature healthcare SOC 2 Type II penetration test should address four areas:
- External and perimeter testing:
These are what an attacker can reach and exploit from outside, with no prior access, such as internet-facing services and exposed endpoints. This also checks whether your perimeter is configured the way your control documentation claims.
- Web application and API testing:
The applications handling PHI are both the prime target and the prime source of exploitable findings. Manual pentesting covers API testing, business logic abuse, authentication weaknesses, and authorization bypass, which are the failures scanners miss most often.
- Internal network and lateral movement testing:
If you have an Active Directory misconfiguration or over-permissioned accounts that have not been reviewed since deployment, these are what an attacker would look for after an initial foothold:
- Cloud configuration review:
Most healthtech runs in the cloud, and misconfigured storage and access policies are a leading cause of PHI exposure, as Catholic Health demonstrated. Configuration is validated against the controls in your SOC 2 boundary, not assumed.
The report itself has to do more than list findings.
An audit-ready healthcare SOC 2 penetration test report states a defined scope and rules of engagement, names the methodology used (OWASP, PTES, or NIST SP 800-115), establishes the independence and credentials of the testers, rates findings with a recognized standard such as CVSS, and shows proof of exploitation rather than theoretical descriptions.
Critically, it maps each finding to the specific Trust Services Criterion it affects, and it includes a remediation log with retest evidence showing high and critical findings were closed and verified. Mapping is what turns a security document into a compliance document.
Here is how that evidence lines up against the criteria an auditor is reviewing:
Trust Services Criterion
What a Manual Pentesting Provides
Audit Risk Without It
CC4.1: Monitoring Activities
An independent evaluation that actively confirms controls are present and operating, the kind of assessment the criterion’s points of focus name directly. 6
Controls are documented as monitored but never independently exercised. Auditors increasingly treat this as a gap.
CC6.1: Logical Access
Real-world validation of whether access restrictions actually prevent unauthorized reach into systems holding PHI.
Access controls are asserted but unproven. An authorization flaw can sit undetected, as in the Catholic Health exposure.
CC7.1: System Operations
Identification of vulnerabilities and misconfigurations that automated monitoring routinely misses, with proof of exploitability.
A scan satisfies the letter of monitoring but cannot show whether a weakness is exploitable in practice.
CC9.1: Risk Mitigation
Evidence-based, prioritized findings that feed your risk assessment instead of hypothetical risk ratings.
Risk decisions rest on assumption rather than tested reality, weakening the whole risk-management narrative.
How Can KLEAP Help?
KLEAP’s penetration testing engagements are built around what your healthcare SOC 2 program actually needs, not generic findings.
Every engagement opens with a scoping conversation anchored to your SOC 2 system boundary, the criteria you have committed to, and where you sit in your audit cycle. That context shapes the testing scope, the evidence we prioritize, and how we structure the final report.
This is KLEAP’s concierge model applied to security testing. No rotating help desk and no automated checklist standing in for a tester. One expert who knows both healthcare and the framework stay with you until you have a report your auditor can rely on.
Our methodology is hands-on by design, because finding broken authorization and abused business logic requires a human reasoning like an attacker. Every finding is mapped to the Trust Services Criterion it affects, remediation guidance is specific enough to act on, and we support the retest cycle, so closed findings are verified, not just marked resolved.
For healthcare organizations approaching their first Type II, we coordinate the test with your readiness and gap-analysis work, so the evidence is ready inside the observation window. For those already in a reporting period, we scope engagements to what has changed in your environment since the last test, with evidence structured for the auditor reviewing your controls.
If you are preparing for a healthcare SOC 2 Type II report or maintaining an existing one, the right place to start is a conversation.
