Penetration Testing Services
Network, Application & Cloud Penetration Testing for Compliance, Risk Reduction & Security Validation
Penetration testing is the deliberate, controlled simulation of a real-world cyberattack against an organization’s systems, applications, and infrastructure — conducted by qualified testers whose objective is to find and exploit vulnerabilities before malicious actors do. It is not a vulnerability scan. It is not an automated tool report. It is an active attempt by skilled human testers to gain unauthorized access, escalate privileges, move laterally, and demonstrate the real-world impact of the vulnerabilities they find — producing evidence that automated tools cannot generate and that compliance auditors, enterprise clients, and cyber insurance underwriters increasingly require as proof that an organization’s security controls actually work under adversarial conditions.
The compliance landscape for penetration testing has shifted materially in the past 18 months. PCI DSS 4.0 — which became the only active version of the Payment Card Industry Data Security Standard in March 2025, replacing version 3.2.1 — explicitly requires annual external and internal penetration testing under Section 11.4 for all entities that store, process, or transmit cardholder data, plus additional testing after significant infrastructure changes and biannual segmentation testing for service providers. The proposed HIPAA Security Rule update on OCR’s regulatory agenda for May 2026 would, for the first time, explicitly mandate annual penetration testing for all covered entities and business associates handling electronic protected health information — the first explicit pen testing requirement in HIPAA’s history. The NYDFS Cybersecurity Regulation (23 NYCRR Part 500) already requires annual penetration testing for covered New York financial services and insurance companies. CMMC full implementation is required by October 2026, with Level 3 assessments effectively requiring penetration-type exercises and adversary emulation. And across the SOC 2, ISO 27001, and enterprise procurement landscapes, security auditors and enterprise buyers are increasingly treating penetration testing evidence as an expected demonstration of security program effectiveness — not an optional enhancement.
Lionhive provides network penetration testing, web application and API penetration testing, cloud infrastructure penetration testing, social engineering assessments, and red team exercises for organizations across financial services, healthcare, technology, legal, manufacturing, and government sectors — scoped to satisfy specific compliance framework requirements and structured to produce findings that organizations can act on, not reports that get filed and forgotten.
A vulnerability scan tells you what weaknesses exist. A penetration test tells you what those weaknesses actually enable — what an attacker could do with them, in what sequence, reaching what systems and data. An organization whose security program is validated only by automated scanning has validated only that its systems have known weaknesses. It has not validated that those weaknesses are unexploitable, that compensating controls actually compensate, or that its detection and response capabilities would identify an active attacker. Those are the questions that penetration testing answers.
Vulnerability Scanning vs. Penetration Testing — The Distinction That Determines Compliance
The most consequential misunderstanding in security program management is the conflation of vulnerability scanning with penetration testing. They are categorically different activities with different outputs, different use cases, and — critically — different compliance standing. Submitting vulnerability scan results when a compliance framework requires a penetration test is one of the most common compliance gaps that auditors and QSAs encounter, and it is a gap that fails audits rather than satisfying them.
Vulnerability scanning is an automated process in which a tool queries systems for known vulnerabilities — checking software versions against vulnerability databases, identifying open ports and services, flagging missing patches, and cataloguing configurations that match known weakness signatures. Vulnerability scanners operate primarily by recognition: they identify patterns that match their databases of known issues. They do not attempt to exploit vulnerabilities. They do not chain multiple weaknesses together to demonstrate what an attacker could actually accomplish. They cannot identify vulnerabilities that require human creativity, contextual understanding, or the kind of multi-step exploitation sequences that characterize real attacks. PCI DSS requires quarterly vulnerability scans in addition to annual penetration tests — specifically because these are separate requirements that address different questions. Organizations that conduct quarterly scans but no penetration testing are meeting one requirement and failing another.
Penetration testing is an active, human-led process in which qualified testers attempt to exploit vulnerabilities — individually and in combination — to demonstrate real-world attack paths and their consequences. A penetration tester who finds a misconfigured server doesn’t stop at cataloguing the misconfiguration. They attempt to exploit it, escalate from it, use it to reach adjacent systems, and document the chain of access they achieved. The output is not a list of known vulnerabilities matched against a database. It is a narrative of what an attacker could actually do in the organization’s specific environment, supported by evidence of exploitation — screenshots, access logs, extracted data samples — that demonstrates impact rather than theoretical risk. This is what compliance frameworks require when they mandate penetration testing, and it is what auditors examine when they review penetration test reports for evidence of adequate security validation.
Testing Approaches — Black Box, White Box & Grey Box
Penetration testing engagements are structured around the level of information provided to testers before testing begins — a variable that substantially affects both what the test is designed to find and how efficiently it finds it.
Black box testing simulates the perspective of an external attacker who has no prior knowledge of the target environment — no network diagrams, no system documentation, no credentials, no internal architecture information. The tester begins from the position of a motivated adversary whose starting point is publicly available information about the organization. Black box testing produces the most realistic simulation of an external attack and is most useful for validating perimeter defenses, external attack surface exposure, and the effectiveness of security controls against an adversary who hasn’t been given a head start. It is also the least time-efficient approach for comprehensive security validation, because significant tester time is consumed by reconnaissance that internal security teams already know the answers to.
White box testing provides testers with full information about the target environment — network diagrams, system architecture documentation, source code for applications under test, configuration details, and sometimes credentials. White box testing allows testers to conduct the most thorough examination of a system’s security in the least time, because reconnaissance overhead is eliminated and testers can focus immediately on the specific logic and configuration that creates vulnerability. It is most useful for code-level application security assessments, detailed infrastructure reviews, and situations where comprehensive coverage is more important than adversarial realism.
Grey box testing — the most common approach for compliance-driven penetration testing — provides testers with partial information that simulates the perspective of a threat actor who has gained some initial access or information about the target environment. Testers typically receive network scope information, application credentials for one or more access levels, and basic architecture documentation, but conduct their exploitation without detailed internal knowledge. Grey box testing balances the adversarial realism of black box testing with the efficiency of white box testing, and produces findings that reflect both external attack paths and internal lateral movement scenarios — the most commercially relevant threat model for most organizations.
Types of Penetration Testing Lionhive Provides
Network Infrastructure Penetration Testing — The foundational engagement for most compliance frameworks. External network penetration testing targets internet-facing systems — firewalls, VPN gateways, web servers, email infrastructure, remote access portals, and any other system accessible from the public internet — to identify exploitable vulnerabilities that an external attacker could use to gain unauthorized access to internal systems or data. Internal network penetration testing starts from the position of an attacker who has already reached the internal network — through a successful phishing attack, a compromised vendor, or physical access — and maps the lateral movement paths available to them. Privilege escalation, Active Directory attacks, credential harvesting, and domain compromise are primary internal testing objectives. For PCI DSS compliance, network testing must cover the complete cardholder data environment perimeter and all systems that could affect CDE security. For HIPAA compliance under the proposed Security Rule update, network testing must cover all systems storing or transmitting ePHI.
Web Application Penetration Testing — Application-layer testing that examines web applications for vulnerabilities in their logic, configuration, and implementation — the category of vulnerabilities that network-layer testing cannot reach. Lionhive’s web application testing methodology is structured around the OWASP Web Security Testing Guide and covers the OWASP Top 10 vulnerability classes — injection attacks (SQL, command, LDAP), broken authentication and session management, cross-site scripting (XSS), broken access control, security misconfiguration, cryptographic failures, insecure deserialization, and the server-side request forgery and security logging failures that more sophisticated application attacks exploit. PCI DSS 4.0 Section 11.4 explicitly requires application-layer testing against the vulnerabilities listed in PCI DSS Section 6.2.4 for all applications in scope. For organizations developing custom software in environments handling cardholder data or ePHI, annual application penetration testing is both a compliance requirement and the security validation that confirms application security testing during development has been effective.
API Penetration Testing — Modern application architectures expose business logic through APIs whose security posture is independent of the web application interface security. REST and GraphQL APIs that lack proper authentication controls, rate limiting, input validation, and authorization checks create attack surfaces that web application scanning and network testing both miss. Lionhive’s API testing covers the OWASP API Security Top 10 — broken object level authorization, authentication failures, excessive data exposure, lack of resource and rate limiting, function level authorization failures, mass assignment vulnerabilities, and security misconfiguration specific to API implementations. For SaaS and cloud platform providers seeking SOC 2 Type II attestation, API security testing produces the evidence artifacts that SOC 2 auditors increasingly expect as demonstration of security criterion effectiveness for organizations whose service delivery is API-mediated.
Cloud Infrastructure Penetration Testing — Cloud environments create security exposure that traditional network and application testing methodologies don’t fully address — misconfigurations in IAM policies, storage bucket permissions, network security group rules, container orchestration security, and the serverless function attack surfaces that are specific to cloud-native architectures. Lionhive conducts cloud penetration testing across AWS, Azure, and Google Cloud — evaluating identity and access management configurations, storage permissions, network security, compute environment hardening, container and Kubernetes security, secrets management, and the cloud-specific attack paths (metadata service exploitation, SSRF to instance metadata, privilege escalation through misconfigured IAM roles) that sophisticated attackers target in cloud environments. Cloud penetration testing is conducted within the testing permissions and rules of engagement defined by each cloud provider — AWS, Azure, and GCP each have specific acceptable use policies for security testing that Lionhive follows in every engagement.
Social Engineering & Phishing Simulations — Technical vulnerabilities are not the only path into an organization’s systems — and in many documented breaches, they are not even the primary one. Business email compromise, credential phishing, and pretexting attacks that manipulate employees into taking actions they wouldn’t otherwise take represent the threat model that technical penetration testing cannot evaluate. Lionhive conducts phishing simulation campaigns that measure employee susceptibility to credential harvesting, malicious attachment delivery, and pretexting scenarios — producing metrics on click rates, credential submission rates, and reporting rates that benchmark awareness training effectiveness and identify the specific employee populations and communication patterns that create social engineering exposure. For organizations whose security training programs claim to have reduced phishing risk, phishing simulation testing validates whether those claims reflect actual behavior change.
Red Team Exercises — Red team exercises are extended, covert engagements in which a dedicated team of testers operates with the objectives and operational security practices of a sophisticated threat actor — attempting to achieve specific mission objectives (access a particular system, exfiltrate a defined data set, persist in the environment undetected) while evading detection by the organization’s security team. Unlike penetration tests — which are typically known to the IT and security leadership who coordinate the engagement — red team exercises are often conducted without the knowledge of the security operations team, testing not just the technical controls but the detection capability, incident response effectiveness, and the human judgment of the security team responding to real alerts about a real (but authorized) adversary. Red team exercises are appropriate for organizations whose penetration testing program has matured to the point where annual penetration tests consistently return findings that are remediated and the organization needs a higher-fidelity adversarial validation of its defensive posture.
Compliance Framework Requirements — What Each Framework Mandates
PCI DSS 4.0 (Section 11.4) — The most prescriptive major compliance framework for penetration testing, and since March 2025 the only active version. Requires: annual external penetration test of the internet-facing perimeter and internet-accessible systems that interact with or could affect the cardholder data environment; annual internal penetration test from inside the network; penetration testing after any significant infrastructure or application changes; documented methodology that covers industry-standard penetration testing operations, the full CDE perimeter, documented internal and external testing results, and application-layer testing identifying the specific vulnerability classes listed in PCI DSS 6.2.4; and biannual segmentation testing for service providers to validate that network segmentation controls isolating the CDE from out-of-scope systems actually hold under attack. Testers must be organizationally independent of the systems being tested — either an independent internal security team or an external penetration testing provider.
Proposed HIPAA Security Rule (NPRM, target finalization May 2026) — Would mandate annual penetration testing for all covered entities and business associates handling ePHI — the first explicit penetration testing requirement in HIPAA’s history. Under the proposed rule, annual penetration testing would be required in addition to the existing risk analysis requirement and the proposed annual compliance audit. Organizations preparing for the May 2026 finalization should initiate penetration testing programs now to have testing history and remediation evidence in place when the compliance deadline arrives.
SOC 2 — Does not explicitly require penetration testing, but SOC 2 auditors increasingly expect evidence of periodic penetration testing to support several of the Common Criteria — particularly CC7 (Systems Operations) and CC9 (Risk Mitigation). Organizations that include penetration testing in their security programs produce stronger SOC 2 evidence packages and experience fewer auditor questions about the completeness of their security validation program. Penetration test reports that map findings to the relevant Trust Services Criteria — and document remediation — provide auditors with the assurance evidence that automated scanning alone cannot supply.
NYDFS 23 NYCRR Part 500 — New York’s cybersecurity regulation for financial services and insurance companies explicitly requires annual penetration testing as part of the risk assessment and testing program. The NYDFS regulation also requires bi-annual vulnerability assessments. Organizations covered by NYDFS Part 500 must maintain testing records and remediation evidence available for DFS examination.
CMMC 2.0 — Level 2 addresses vulnerability scanning and security assessments through NIST SP 800-171 controls CA-2 and RA-5; penetration testing may be required when custom software is in use. Level 3, with full CMMC implementation required by October 2026, includes control requirements that effectively mandate penetration-type exercises and adversary emulation as part of the higher-assurance assessment process. Defense contractors preparing for Level 3 assessment should initiate penetration testing programs before the assessment rather than after.
ISO 27001 — Annex A Control 8.8 (Management of technical vulnerabilities) and Control 8.29 (Security testing in development and acceptance) both address the need for technical security testing. ISO 27001 certification bodies increasingly expect evidence of penetration testing as part of the technical security testing program, particularly for organizations handling sensitive data or operating critical systems.
The Penetration Test Report — What It Must Contain
The penetration test report is the primary compliance artifact from a testing engagement — the document that QSAs, auditors, enterprise security teams, cyber insurance underwriters, and executive leadership will examine to assess the engagement’s quality, comprehensiveness, and the organization’s response to findings. A penetration test report that does not contain the right components is not useful for compliance purposes regardless of the quality of the testing that produced it.
Lionhive’s penetration test reports contain every component that compliance frameworks and sophisticated buyers require:
Executive Summary — A non-technical summary of the engagement scope, overall risk posture assessment, critical and high severity findings, and the most significant business risk implications of identified vulnerabilities. Written for executive and board-level audiences whose responsibility is understanding organizational risk, not evaluating technical exploitation techniques.
Methodology and Scope Documentation — A detailed description of the testing methodology applied, the systems and applications in scope, the testing period, the approach (black/white/grey box), the tools used, and any constraints or limitations that affected the engagement. PCI DSS 4.0 requires documented methodology as a compliance deliverable — this section provides it.
Findings with CVSS Scoring — Each identified vulnerability documented with its Common Vulnerability Scoring System (CVSS) score, severity classification (Critical/High/Medium/Low/Informational), technical description, affected systems, and the specific exploitation technique or attack chain that demonstrated the vulnerability’s exploitability. Findings that were not exploitable are documented separately from those that were successfully exploited — a distinction that matters both for risk prioritization and for compliance evidence.
Evidence of Exploitation — Screenshots, command output, proof-of-concept code execution results, and other technical evidence demonstrating that identified vulnerabilities were successfully exploited and what access or impact was achieved. This is the content that distinguishes a penetration test report from a vulnerability scan report — automated tools cannot produce evidence of exploitation because they do not exploit vulnerabilities.
Remediation Recommendations — Specific, actionable remediation guidance for each finding, prioritized by severity and practical implementation feasibility. Recommendations that reference the specific configuration changes, patch versions, code corrections, or architectural modifications that address each finding rather than generic guidance that leaves remediation teams without a clear implementation path.
Compliance Mapping — Where applicable, each finding is mapped to the relevant compliance framework control or requirement — PCI DSS Section 11.4, HIPAA Security Rule implementation specification, SOC 2 Trust Services Criterion, NIST CSF 2.0 subcategory — that the finding’s remediation addresses. Compliance mapping allows the findings and their remediation to be tracked directly to the compliance requirements that drove the testing engagement.
Retesting Results — A retesting engagement following remediation produces a formal report confirming that identified vulnerabilities were successfully addressed — providing QSAs and auditors with evidence that the organization not only identified vulnerabilities but closed them. PCI DSS specifically requires documentation that exploitable vulnerabilities and security weaknesses have been corrected.
Testing Frequency — When and How Often to Test
The minimum penetration testing frequency for most compliance frameworks is annual — but annual testing is not always sufficient, and compliance minimums are not always aligned with actual risk management needs.
Annual penetration testing satisfies the baseline requirement of PCI DSS, NYDFS Part 500, the proposed HIPAA Security Rule update, most SOC 2 auditor expectations, and the ISO 27001 technical testing program expectation. It is the appropriate baseline for organizations whose environments are relatively stable and whose previous testing has returned manageable findings that have been remediated.
Additional penetration testing is required or strongly recommended after significant changes. PCI DSS 4.0 Section 11.4 explicitly requires penetration testing after any significant infrastructure or application changes to the cardholder data environment. The same principle applies broadly — a significant network architecture change, a major cloud migration, a new customer-facing application, or a significant code deployment to an existing application creates new attack surface that the previous annual test did not evaluate and that vulnerability scanning alone will not adequately assess. Lionhive recommends engagement-scoped penetration tests following significant changes as a standard risk management practice, independent of compliance framework requirements.
More frequent penetration testing — semi-annual for organizations in high-value target sectors (financial services, healthcare, technology), quarterly for organizations with very rapid development cycles or extremely sensitive data — reflects the actual threat environment that many organizations face rather than the compliance minimum. The average cost of a healthcare data breach has reached $10.93 million per incident. For organizations in sectors where breach costs reach this scale, the cost of penetration testing conducted more frequently than annually is a small fraction of the average breach cost it is designed to prevent.
After Testing — Remediation, Retesting & the Security Program
A penetration test report that produces findings and is then filed unaddressed has not improved the organization’s security posture — it has documented the organization’s vulnerabilities for anyone who reads the report without reducing the risk those vulnerabilities represent. The value of penetration testing is realized through remediation, and remediation requires both a prioritized plan and the technical implementation capability to execute it.
Lionhive provides remediation support as an integrated component of penetration testing engagements — connecting the findings in the test report to Lionhive’s managed IT and cybersecurity engineering capability that can implement the specific configuration changes, architectural corrections, patch deployments, and access control modifications that each finding requires. For organizations whose in-house IT team has the capacity to implement remediation independently, Lionhive provides technical guidance and remediation verification. For organizations that need the remediation implemented rather than just specified, Lionhive’s engineering team executes it. Formal retesting following remediation — producing a documented confirmation that critical and high findings have been successfully addressed — provides the QSA and auditor evidence artifact that closes the compliance loop on each testing cycle.
📞 Schedule Your Penetration Test
Whether you are conducting your first penetration test in response to a PCI DSS requirement, preparing for a SOC 2 Type II audit, building a testing program ahead of the proposed HIPAA Security Rule’s compliance deadline, or seeking a more rigorous adversarial validation of a mature security program through a red team exercise — Lionhive provides the testing methodology, report quality, and remediation support that produces defensible compliance evidence and actionable security improvements. To discuss scope, timing, and compliance framework requirements for your penetration testing engagement, contact us directly or book a strategy session.
👉 Book a Penetration Testing Consultation
📞 +1 469 364 9010
Part of Lionhive’s Cybersecurity & Compliance practice — see also Vulnerability Management, SOC 2 Type II, HIPAA, NIST CSF 2.0, and Managed SOC.