What Is Penetration Testing? How Pen Tests Fit Into SOC 2, ISO 27001, and PCI DSS Compliance
Penetration testing — commonly called a pen test — is a controlled, authorized simulated cyberattack against your systems, networks, or applications, performed by qualified security professionals to identify exploitable vulnerabilities before real attackers do. Unlike automated vulnerability scans that only flag known weaknesses, penetration testing involves skilled testers actively attempting to exploit vulnerabilities, chain findings together, and demonstrate what an attacker could actually achieve — data exfiltration, privilege escalation, lateral movement, or full system compromise. It is one of the most important security validation controls in any compliance program, and it is explicitly required or strongly expected by SOC 2, ISO 27001, PCI DSS, HIPAA, and HITRUST.
TL;DR — Key Takeaways
- Penetration testing is a simulated attack conducted by authorized security professionals to find and exploit real vulnerabilities in your environment
- It goes beyond automated scanning — pen testers think like attackers, chaining vulnerabilities together to demonstrate real-world impact
- The main types are: network penetration testing (external and internal), web application testing, API testing, social engineering, and physical penetration testing
- PCI DSS explicitly requires annual penetration testing and retesting after significant changes; SOC 2 and ISO 27001 strongly expect it as evidence of a mature security program
- Pen test reports must include: scope, methodology, findings with severity ratings, evidence of exploitation, and remediation recommendations
- Most compliance frameworks expect pen tests to be performed at least annually, with retesting after significant infrastructure or application changes
- Remediation of critical and high-severity findings — and evidence that you remediated them — is what auditors actually care about
How Penetration Testing Differs From Vulnerability Scanning
This distinction matters for compliance — because auditors treat them as different controls.
| Vulnerability Scanning | Penetration Testing | |
|---|---|---|
| What it does | Automated tool scans for known vulnerabilities using a database of signatures | Skilled tester actively attempts to exploit vulnerabilities and simulate real attack paths |
| Depth | Surface-level identification; high false positive rate | Deep exploitation; validates whether vulnerabilities are actually exploitable |
| Approach | Automated; runs without human judgment | Manual and tool-assisted; requires expert judgment, creativity, and lateral thinking |
| Output | List of CVEs and misconfigurations with severity ratings | Narrative report showing attack paths, exploitation proof, business impact, and remediation steps |
| Compliance role | Required quarterly or continuously by most frameworks | Required annually by most frameworks; supplements but does not replace scanning |
| Cost | $500–$5,000 per scan (often included in security tooling) | $5,000–$100,000+ depending on scope and complexity |
Both are required for compliance. Vulnerability scanning is your ongoing detection mechanism. Penetration testing is your periodic validation that your defenses actually work against a skilled attacker.
Types of Penetration Testing
External Network Penetration Testing
Testers simulate an outside attacker targeting your internet-facing infrastructure: public IP addresses, firewalls, VPN endpoints, DNS servers, mail servers, and cloud-hosted services. The goal is to determine whether an external attacker can breach your perimeter and gain access to internal systems.
What testers look for: Misconfigured firewalls, exposed management interfaces, unpatched services, weak VPN configurations, cloud storage misconfigurations (open S3 buckets, publicly accessible databases), exposed credentials in public repositories.
Internal Network Penetration Testing
Testers simulate an attacker who has already gained a foothold inside the network — either through a compromised employee workstation, a phishing attack, or physical access. The focus is on lateral movement: can the attacker escalate privileges, move between network segments, and reach sensitive data or critical systems?
What testers look for: Weak Active Directory configurations, credential reuse, unpatched internal systems, insufficient network segmentation, privilege escalation paths, access to sensitive databases or file shares without proper authorization.
Web Application Penetration Testing
Testers target your web applications — customer portals, admin panels, APIs, and public-facing web services — looking for vulnerabilities that could allow data theft, unauthorized access, or system compromise. This is typically the highest-value pen test for SaaS companies.
What testers look for: OWASP Top 10 vulnerabilities (SQL injection, cross-site scripting, broken authentication, insecure direct object references), business logic flaws, session management weaknesses, API authentication and authorization bypasses, file upload vulnerabilities, server-side request forgery.
API Penetration Testing
With the proliferation of API-first architectures, dedicated API testing has become critical. Testers examine REST, GraphQL, and SOAP APIs for authentication weaknesses, broken access controls, injection vulnerabilities, rate limiting issues, and data exposure through verbose error messages or over-permissive responses.
Social Engineering Testing
Testers simulate phishing campaigns, vishing (voice phishing), pretexting, and other human-targeted attacks to evaluate whether employees can be manipulated into revealing credentials, granting access, or executing malicious actions. Social engineering tests evaluate your human security layer — which is often the weakest link.
Common methods: Simulated spear-phishing emails with credential harvesting pages, phone-based social engineering targeting help desk or IT support, USB drop attacks, physical tailgating attempts.
Physical Penetration Testing
Testers attempt to gain unauthorized physical access to facilities — data centers, offices, server rooms — by bypassing physical access controls. This is less common for cloud-native SaaS companies but relevant for organizations with on-premises infrastructure or data center colocations.
What Compliance Frameworks Require for Penetration Testing
This is where pen testing moves from security best practice to compliance obligation.
PCI DSS — Explicit Requirement
PCI DSS has the most specific penetration testing requirements of any major compliance framework.
Requirement 11.4 mandates:
- Annual penetration testing of the cardholder data environment (CDE) — both external and internal
- Testing must follow a recognized methodology (NIST SP 800-115, OWASP, PTES, or equivalent)
- Tests must cover the network layer and application layer
- Retesting is required after any significant infrastructure or application change
- Segmentation testing — if you use network segmentation to reduce your CDE scope, penetration testing must validate that the segmentation controls are effective (every 6 months for service providers)
- Critical and high-severity findings must be remediated and retested
PCI DSS 4.0 additions: Internal penetration tests can now be performed by qualified internal resources (not just external firms), provided the testers are organizationally independent from the environment being tested. The customized approach also allows alternative testing methodologies if they meet the security objective.
SOC 2 — Strongly Expected
SOC 2 does not have a single control that says "you must conduct a penetration test." However, penetration testing is strongly expected as evidence supporting multiple Trust Service Criteria:
- CC4.1 — The entity selects, develops, and performs ongoing and/or separate evaluations to ascertain whether the components of internal control are present and functioning
- CC7.1 — The entity uses detection and monitoring procedures to identify changes to configurations that result in the introduction of new vulnerabilities, and susceptibilities to newly discovered vulnerabilities
In practice, nearly every SOC 2 auditor will ask for your most recent penetration test report. Its absence is a red flag — not a technical audit failure, but a signal that your security validation program is immature. Most SOC 2 audit firms list annual penetration testing as a recommended control, and many will issue an observation or management letter comment if no pen test has been performed.
What SOC 2 auditors expect to see:
- Annual pen test report from a qualified firm
- Evidence that findings were remediated
- Management response to the pen test report
- Retesting or follow-up validation for critical findings
ISO 27001 — Required Through Annex A Controls
ISO 27001:2022 addresses penetration testing through several Annex A controls:
- Annex A 8.8 — Management of technical vulnerabilities: requires the organization to evaluate technical vulnerabilities and take appropriate measures; penetration testing is a standard method for this evaluation
- Annex A 5.35/5.36 — Independent review of information security and compliance with policies and standards: pen testing provides independent validation that security controls are effective
- Annex A 8.34 — Protection of information systems during audit testing: governs how penetration tests should be planned and controlled
ISO 27001 auditors expect to see penetration testing as part of your vulnerability management process. While the standard does not prescribe a specific frequency, annual testing is the accepted industry norm, and certification body auditors will typically ask for the most recent report during Stage 2 audits.
HIPAA — Implied Through the Security Rule
HIPAA does not explicitly use the words "penetration testing" in the Security Rule. However, the required implementation specification for Technical Evaluation (§164.308(a)(8)) requires covered entities to perform periodic technical and non-technical evaluations of their security controls — and penetration testing is the most widely accepted method for fulfilling this requirement. HHS guidance and the NIST HIPAA Security Toolkit both reference penetration testing as an expected practice.
HITRUST CSF — Explicit Requirement
HITRUST CSF includes explicit penetration testing requirements. Organizations pursuing HITRUST r2 certification must demonstrate that they conduct regular penetration tests of their environment, including network and application layers, and that findings are remediated according to a defined process.
Pen Test Frequency: How Often Do You Need One?
| Framework | Minimum Frequency | Additional Triggers |
|---|---|---|
| PCI DSS | Annually; segmentation testing every 6 months for service providers | After significant infrastructure or application changes |
| SOC 2 | Annually (industry standard expectation) | After major architecture changes; before first audit |
| ISO 27001 | Annually (expected norm for vulnerability management) | Risk-driven; after significant changes to the ISMS scope |
| HIPAA | Annually (widely accepted interpretation) | After significant environmental changes |
| HITRUST | Annually | After significant changes |
Best practice: Annual comprehensive penetration tests, plus targeted retesting after significant changes (new application releases, infrastructure migrations, cloud provider changes, merger/acquisition integrations). High-maturity organizations run continuous or quarterly targeted pen tests on their most critical applications.
What a Compliant Pen Test Report Must Include
Auditors do not just want to know that a pen test happened. They want to evaluate the quality and completeness of the test and — most importantly — how you responded to the findings.
A compliance-grade penetration test report should include:
- Executive summary — High-level findings, overall risk rating, critical issues requiring immediate attention
- Scope definition — What was tested (IP ranges, applications, environments); what was explicitly excluded
- Methodology — The testing framework used (OWASP, PTES, NIST SP 800-115); whether testing was black box, gray box, or white box
- Detailed findings — Each vulnerability with: description, affected system, severity rating (Critical/High/Medium/Low/Informational), evidence of exploitation (screenshots, proof-of-concept), potential business impact
- Attack narratives — For significant findings, a step-by-step description of how the tester exploited the vulnerability and what they were able to access
- Remediation recommendations — Specific, actionable steps to fix each finding; prioritized by severity and business impact
- Retest results — If retesting was performed, results confirming that remediated findings are resolved
What auditors specifically look for in the report:
- Was the scope appropriate for the compliance requirement? (PCI DSS auditors will verify the CDE was in scope; SOC 2 auditors will look for coverage of systems in the system description)
- Were critical and high-severity findings remediated?
- Is there evidence of management review and response?
- Was the test performed by qualified individuals with organizational independence?
Remediation: Where Most Organizations Fall Short
Finding vulnerabilities is only half the value of a penetration test. The other half — and the part auditors scrutinize most — is what you did about the findings.
Remediation Best Practices
- Triage immediately: Critical and high-severity findings should be triaged within 48 hours of report delivery
- Assign ownership: Every finding needs a remediation owner with a target date
- Remediate by severity: Critical findings within 30 days; high findings within 60 days; medium findings within 90 days
- Retest critical findings: Have the pen testing firm validate that critical and high-severity remediations are effective
- Document everything: Maintain a remediation tracker that shows: finding, owner, target date, actual remediation date, retest result
- Report to management: Present pen test results and remediation status to leadership — this satisfies management review requirements for ISO 27001 and SOC 2
What Happens if You Cannot Remediate a Finding?
Some findings cannot be fixed immediately due to technical constraints, vendor dependencies, or business requirements. In these cases:
- Document a risk acceptance with business justification
- Implement compensating controls that reduce the risk (network segmentation, additional monitoring, access restrictions)
- Set a future remediation date and track progress
- Ensure the risk acceptance is approved by management — not just the security team
Auditors understand that not every finding can be remediated overnight. What they do not accept is findings with no response, no owner, and no plan.
Choosing a Penetration Testing Provider
Not all pen tests are created equal. A checkbox pen test from an unqualified provider produces a report that may satisfy a literal compliance requirement but provides no real security value.
What to look for in a pen testing firm:
| Criterion | Why It Matters |
|---|---|
| Certifications | OSCP, OSCE, GPEN, GXPN, CREST — these indicate testers with demonstrated hands-on skills |
| Methodology | Should follow OWASP, PTES, or NIST SP 800-115; ask for their methodology document |
| Report quality | Request a sample report before engaging; it should include detailed findings, evidence, and actionable remediation steps — not just scanner output |
| Retesting included | Confirm the engagement includes retesting of remediated findings |
| Scoping rigor | A good firm asks detailed questions about your environment before quoting; a firm that quotes without scoping is selling a commodity |
| Insurance | Professional liability and cyber insurance covering the testing engagement |
Red flags:
- Reports that are primarily automated scanner output with minimal manual validation
- Firms that do not ask about your compliance requirements during scoping
- No retesting included in the engagement
- Testers without recognized certifications
Common Misconceptions About Penetration Testing
Misconception 1: "Vulnerability scanning is the same as penetration testing." They serve different purposes. Scanning identifies potential vulnerabilities automatically. Penetration testing validates exploitability through skilled manual testing. Compliance frameworks treat them as separate controls — you need both.
Misconception 2: "We only need a pen test when an auditor asks for it." Waiting until audit season means you discover critical vulnerabilities under time pressure with no room for remediation. Pen tests should be scheduled proactively — at least annually and after significant changes — so findings are remediated before the audit window opens.
Misconception 3: "A pen test will break our production systems." Professional pen testing firms operate under strict rules of engagement that define what is in scope, what testing methods are permitted, and what hours testing will occur. Denial-of-service testing and other high-risk techniques are explicitly scoped and agreed upon in advance. Production outages from authorized pen tests are exceptionally rare.
Misconception 4: "Our cloud provider handles our pen testing." AWS, Azure, and GCP secure their infrastructure — not your configurations, applications, or data. The shared responsibility model means you are responsible for testing your own applications, access controls, and configurations deployed on cloud infrastructure.
Misconception 5: "One pen test covers all our compliance frameworks." A well-scoped pen test can serve multiple frameworks, but you must ensure the scope covers what each framework requires. PCI DSS requires CDE-specific testing with segmentation validation. SOC 2 expects coverage of systems in your system description. ISO 27001 expects testing aligned with your ISMS scope. One test can cover all three — but only if scoped correctly.
How QuickTrust Integrates Penetration Testing Into Your Compliance Program
Penetration testing is not a standalone activity — it is a control that feeds into your vulnerability management process, your risk assessment, and your audit evidence package. QuickTrust builds pen testing into your compliance program from day one:
What QuickTrust delivers for penetration testing:
- Scope definition — Define pen test scope aligned with your compliance requirements (CDE for PCI DSS, system description for SOC 2, ISMS scope for ISO 27001) so one engagement satisfies multiple frameworks
- Provider selection and coordination — Select a qualified pen testing firm with the right certifications and methodology for your environment; manage the engagement end-to-end
- Rules of engagement — Draft and negotiate testing rules including scope, methodology, timing, communication protocols, and escalation procedures
- Remediation management — Triage findings, assign ownership, track remediation to completion, and coordinate retesting with the pen test firm
- Evidence packaging — Prepare the pen test report, remediation tracker, management response, and retest results as a complete audit evidence package for SOC 2, ISO 27001, or PCI DSS auditors
- Continuous program management — Schedule annual pen tests, trigger retesting after significant changes, and maintain a rolling vulnerability management process that keeps you audit-ready year-round
Result: Penetration testing that actually improves your security posture and produces the evidence auditors require — managed as part of your complete compliance program.
Penetration Testing FAQ
How much does a penetration test cost?
Costs vary significantly by scope and complexity. A focused external network pen test for a small environment may cost $5,000–$15,000. A comprehensive engagement covering external network, internal network, and web applications for a mid-size SaaS company typically costs $20,000–$60,000. Large enterprise engagements with multiple applications, social engineering, and physical testing can exceed $100,000. The cost of not testing — a breach that exploits a vulnerability a pen test would have found — is orders of magnitude higher.
Can we do penetration testing in-house?
PCI DSS 4.0 allows internal pen testing if the testers are qualified and organizationally independent from the systems being tested. SOC 2 and ISO 27001 auditors generally prefer third-party testing because it provides stronger independent validation. If you do use internal resources, ensure they hold recognized certifications (OSCP, GPEN) and that their independence from the development and operations teams is documented.
What is the difference between black box, gray box, and white box testing?
Black box: Testers have no prior knowledge of the environment — simulating an external attacker. Gray box: Testers have limited information such as user credentials, network diagrams, or API documentation — simulating an attacker with some insider knowledge. White box: Testers have full access to source code, architecture documentation, and admin credentials — maximizing vulnerability discovery. For compliance purposes, gray box testing typically provides the best balance of realism and coverage.
Do we need to pen test every application?
Not necessarily every application, but every application within your compliance scope. For PCI DSS, all applications in the CDE must be tested. For SOC 2, applications described in your system description should be covered. For ISO 27001, applications within your ISMS scope. Prioritize customer-facing applications and any system that stores, processes, or transmits sensitive data.
What happens if the pen test finds a critical vulnerability?
A qualified pen testing firm will notify you immediately upon discovering a critical vulnerability — not wait until the final report. You should have an escalation process defined in your rules of engagement for critical findings discovered during testing. Remediate immediately, retest to confirm the fix, and document the entire timeline for your auditors.
Get Pen Testing Set Up as Part of Your Compliance Program
Penetration testing should not be a last-minute scramble before an audit. QuickTrust builds pen testing into your compliance program from the start — scoping it to satisfy SOC 2, ISO 27001, and PCI DSS requirements simultaneously, coordinating the engagement, managing remediation, and packaging the evidence your auditors need.
Get pen testing set up as part of your compliance program — talk to our team at trust.quickintell.com
Engineering-included. Audit-ready in 6-10 weeks. 100% audit pass rate.