Industries Served and Compliance Standards We Support

PCI-DSS, HIPAA, and SOC 2 are the compliance frameworks most frequently supported by penetration testing engagements, each requiring evidence that security controls are effective against real-world attack techniques. These three standards cover different sectors and different data types, but they share one demand: proof that a system has been tested by someone trying to break it, not just scanned by a tool looking for known flaws.

The frameworks are not interchangeable and they are not mutually exclusive. A healthcare SaaS platform that processes card payments for patient billing may need to satisfy all three at once, and the pentesting engagement has to be scoped to meet the strictest overlapping requirement rather than running three separate, duplicated tests.

PCI-DSS is the most prescriptive of the three: it names penetration testing directly and sets a fixed annual cycle, scoped tightly to the CDE. SOC 2 never uses the word "pentest" in its criteria, but auditors expect it as the practical way to evidence that monitoring and detection controls (CC7.2, CC7.3) actually work. HIPAA's Security Rule asks for periodic technical evaluation without naming a method, which is why penetration testing has become the accepted way to demonstrate that technical safeguards hold up under attack rather than just on paper.

Industries We Serve and the Standards That Apply to Them

The standard that applies to an organisation is determined by the data it handles, not its size or sector label. A retailer taking card payments online falls under PCI-DSS regardless of turnover, while a two-person health tech startup handling patient records can face the same HIPAA scrutiny as a large hospital trust.

These pairings overlap in practice more often than they diverge. A fintech payment processor commonly needs PCI-DSS alongside SOC 2 because its enterprise customers demand a Trust Services report on top of card network requirements. A health tech SaaS vendor often needs HIPAA for its US clients and SOC 2 for everyone else. UK organisations should also weigh ICO expectations under UK GDPR, FCA rules where financial services apply, and NCSC guidance for public sector and critical national infrastructure work, alongside whichever of the three core standards applies.

The same standard tests differently depending on the industry it sits in. A pentest supporting PCI-DSS for a payment processor has to prioritise API security and transaction flow integrity, because that is where card data actually moves. A pentest supporting HIPAA for a hospital system has to account for EHR complexity and the web of third-party integrations that typically surround clinical software, because that is where PHI is most often exposed. Applying the same generic scope to both would satisfy neither auditor.

What Each Compliance Standard Requires from Your Pentest

Each standard sets a different bar for what counts as sufficient evidence, and knowing that bar is what separates a useful proposal from a generic one.

What the Report Must Include

Across all three standards, the report itself needs to include:

• An executive summary for non-technical stakeholders
• A clear methodology section
• Findings with severity ratings
• Evidence that vulnerabilities were actually exploited, not just flagged
• Remediation guidance
• A compliance mapping section tying findings back to the specific requirement they affect

What auditors increasingly want to see is not just that a test happened, but that findings were remediated and then verified through a retest. A findings list without a documented retest cycle is the difference between passing an audit and struggling to defend one when challenged.

Vulnerability Scans vs. Penetration Tests: What Each Standard Expects

A vulnerability scan is an automated process that checks systems against a database of known weaknesses and produces a list of potential issues; a penetration test combines automated tooling with manual technique to determine whether those issues are actually exploitable and what the resulting business impact would be.

Confusing the two is the single most common compliance mistake organisations make, and it is the fastest way to fail an audit that expected the latter.

PCI-DSS is explicit that both are required and neither substitutes for the other: quarterly scans under Requirement 11.4.2 and an annual pentest under 11.4.1.

SOC 2 and HIPAA do not name scans versus tests directly, but a scan alone will not satisfy an auditor looking for evidence of control effectiveness, because a scan cannot show what an attacker could actually achieve.

If the current testing programme consists only of scans, that is the gap in the compliance posture, not a supplementary activity to build on later.

How Our Compliance-Led Pentesting Engagements Work

A compliance-grade engagement is structured around evidence production at every stage, not just a technical exercise that gets written up afterwards. The stages below map each milestone to the compliance output it generates.

1. Scoping. The compliance boundary is defined first: which systems hold cardholder data, ePHI, or in-scope SOC 2 infrastructure, backed by asset inventories and network diagrams. Output: a documented scope agreement that an auditor can cross-reference against the compliance boundary.
2. Pre-engagement documentation gathering. Previous scan reports, prior pentest findings, and system architecture are reviewed before testing starts. Output: a test plan that avoids duplicating work already covered by existing scans.
3. Testing. External, internal, and application-layer testing is carried out as required by the applicable standard, whether that is a PCI network test focused on the CDE or a HIPAA-relevant web application test covering ePHI-handling systems. Output: interim findings as issues are identified.
4. Reporting. Findings are written up with severity ratings, exploitation evidence, and business impact, then cross-referenced against the specific requirement or criterion they affect. Output: the final report with compliance mapping.
5. Remediation support. Guidance is provided on fixing each finding, prioritised by severity and exploitability rather than a flat list. Output: a remediation roadmap the internal team can action.
6. Retesting and verification. Fixed issues are retested to confirm the vulnerability no longer exists. Output: a retest certificate or verification statement auditors can rely on as closure evidence.

Timelines vary with scope and complexity, but a standard single-application or single-network engagement typically runs two to four weeks from scoping to final report, with more complex, multi-system environments taking longer.

Organisations needing PCI-DSS coverage for their cardholder data environment are typically pointed toward a dedicated PCI network testing engagement, while those with HIPAA obligations around patient-facing applications are usually better served by a HIPAA penetration testing engagement scoped specifically to ePHI-handling systems, and SaaS providers pursuing a Trust Services report are typically routed to a dedicated SOC 2 penetration testing engagement covering the full in-scope system.

The report structure itself is built to serve two readers at once: the security team needs the technical findings, and the auditor needs the compliance mapping, without either side having to translate or reformat the other's version.

What You Receive: Building Your Compliance Evidence Package

The tangible output of a compliance-led engagement is an evidence package, not just a test result, and knowing what is in it before signing off is what lets internal stakeholders and external auditors both sign off with confidence.

• Penetration test report, including an executive summary for management and technical appendices for engineering teams
• Compliance mapping document, cross-referencing each finding to the specific PCI-DSS requirement, SOC 2 TSC criterion, or HIPAA Security Rule safeguard it affects
• Remediation roadmap, with fixes prioritised by severity and exploitability rather than listed alphabetically or by discovery order
• Retest verification report, confirming which findings were fixed and closed
• Letter of engagement and scope confirmation, documenting exactly what was and was not tested

The compliance mapping document is often the most time-saving deliverable in the package, because it does the translation work an internal compliance team would otherwise have to do manually, line by line, before an audit.

Sensitive material generated during the engagement, including network diagrams, credentials, and findings, is handled under NDA and stored securely throughout and after the test.

Audit support typically includes availability to answer auditor questions and clarify report content during the evidence review period, though no engagement can guarantee an audit outcome, since that ultimately depends on how thoroughly findings are remediated.

How to Evaluate a Compliance-Focused Pentest Proposal

A proposal is worth engaging with if it references your specific compliance standard by requirement number, not just the word "security." Generic proposals that talk about "security testing" without naming PCI 11.4.1, SOC 2 CC7.2, or the relevant HIPAA safeguard are a signal the provider is not scoping for compliance evidence at all.

Key Questions to Ask Any Provider

• How do you map findings to my specific compliance standard?
• Do you have direct experience in my industry and its typical data types?
• What does the report include: executive summary, compliance mapping, remediation guidance?
• Is a retest cycle included, or is it a separate cost?
• What is the testing methodology, and what is the manual-versus-automated mix?
• Do you provide support during the auditor's evidence review period?
• What certifications do the testers hold, such as CREST or OSCP?

Red Flags in a Proposal

Red flags include scopes that never mention the specific standard by name, no clear list of evidence deliverables, no remediation support built into the engagement, no retest offering, and testers without recognised industry certifications.

One practical check that most buyers overlook: ask the provider to share a redacted sample report before signing anything. A compliance-focused provider will produce one readily, and it will show immediately whether findings are mapped to standards and whether the structure is built for auditor consumption rather than just an internal read.

Frequently Asked Questions