SOLUTIONS · PENETRATION TESTING
Penetration Testing Services
Network, Application, Wireless, Cloud, Social Engineering and Physical
A vulnerability scan tells you what might be exploitable. A penetration test tells you what an attacker actually reached, and how. That difference is now written into the frameworks: PCI DSS v4.0.1 names penetration testing in requirement text, mandates a documented methodology, requires organizational independence from the systems tested, and will not accept a scanner export with a cover page. Elevate Consult has delivered over 500 penetration tests, built to satisfy the framework that drives the requirement and to tell your team something they did not already know.
2026 UPDATE
What the frameworks now require
PCI DSS moved penetration testing from 11.3 to 11.4 and made it prescriptive
Requirement 11.4.1 requires a defined, documented and implemented methodology. 11.4.2 and 11.4.3 require internal and external testing at least every 12 months and after any significant infrastructure or application change. 11.4.4 requires exploitable findings to be corrected and retested, which is the biggest operational change: a QSA now asks for evidence the fix was confirmed, not a remediation plan.
Scanning no longer substitutes, and internal scans must be authenticated
Quarterly ASV scanning sits at 11.3.2 and does not satisfy 11.4. Separately, internal vulnerability scans must now be authenticated under 11.3.1.2. Unauthenticated black box scanning of internal networks is no longer sufficient.
Other frameworks set their own cadence
The GLBA Safeguards Rule requires annual penetration testing and semi-annual vulnerability assessments for covered non-bank financial institutions. DORA requires threat-led penetration testing every three years for entities identified as in scope. Each carries its own trigger, and running one test to satisfy several requires scoping it that way from the start.
Segmentation testing has its own clock
Where segmentation reduces PCI scope, 11.4.5 requires testing it at least every 12 months. Service providers move to every six months under 11.4.6, plus after any change to segmentation controls. Multi-tenant service providers additionally have to support customer external testing under 11.4.7.
The tester needs independence, not a QSA badge
PCI DSS requires organizational independence from the systems being tested. The tester can be an internal resource, provided they are not responsible for managing the environment they test, and is explicitly not required to hold a QSA or ASV credential. That distinction saves organizations money and is widely misunderstood.
WHAT IT IS
Controlled exploitation, not automated discovery
Penetration testing is a systematic simulation of real-world attack, conducted under written authorization, to uncover vulnerabilities in systems, networks, applications and the people and processes around them. Unlike a vulnerability scan, it includes actively exploiting weaknesses to the degree agreed with the organization, which is what demonstrates actual impact rather than theoretical risk.
The practical difference shows up in the report. A scan produces a list of findings with severity ratings assigned by a tool. A test produces a path: this entry point, then this credential, then this system, then this data. The second one is what changes a remediation priority
WHY IT MATTERS
Four reasons, and only one of them is compliance
Compliance drives most engagements, but it is the least interesting reason to run one. The test is worth commissioning when an organization cannot answer what an attacker would reach and how long it would take to notice.
PCI DSS v4.0.1
Explicitly mandated
Internal and external testing at least every 12 months and after significant change (11.4.2, 11.4.3). Exploitable findings corrected and retested (11.4.4). Segmentation testing annually (11.4.5) or every six months for service providers (11.4.6). Documented methodology required (11.4.1). Records retained at least 12 months.
DORA
Mandated for entities in scope
Threat-led penetration testing every three years for financial entities identified as required, alongside the annual testing of ICT tools and systems.
ISO 27001 and SOC 2
Expected, not named
Neither names penetration testing in requirement text. ISO 27001 Annex A covers technical vulnerability management and security testing; SOC 2 auditors commonly expect a test as evidence of monitoring effectiveness. Treat it as expected evidence rather than a stated mandate.
GLBA FTC Safeguards Rule
Explicitly mandated
Annual penetration testing and semi-annual vulnerability assessments for covered non-bank financial institutions, or continuous monitoring achieving comparable outcomes. Among the most frequently missed obligations in the Rule.
FedRAMP and GovRAMP
Required in the authorization package
Penetration testing forms part of the security assessment supporting authorization and the continuous monitoring cycle that follows.
GDPR
Effectiveness testing, not pen testing specifically
Article 32 requires a process for regularly testing, assessing and evaluating the effectiveness of technical and organizational measures. It does not mandate penetration testing by name, and material claiming otherwise overstates the requirement.
WHAT WE REVIEW
Six attack surfaces, one custom test plan
Elevate works directly with the client to build a test plan for the specific environment and the depth of testing required, rather than applying a fixed package.
Internal and external network penetration testing
External testing covers the exposed perimeter and systems reachable from public infrastructure. Internal testing covers movement from inside the environment and from trusted and untrusted internal networks toward sensitive systems. PCI DSS treats these as separate requirements for a reason: they answer different questions.
Social engineering and phishing campaigns
Pretexting, phishing and physical social engineering scoped against how the organization actually operates. The finding is rarely that someone clicked. It is what the click reached and how long it went unnoticed.
Cloud security assessments
Azure, AWS and GCP configuration, identity and access, privilege escalation paths and exposed services. Cloud testing is a configuration review with exploitation attached rather than a network test pointed at a different address range.
Web application and API security testing
Application logic, authentication and authorization, injection, business logic abuse and API-specific weaknesses, aligned to the OWASP Testing Guide and API Security Top 10. APIs are where application testing most often stops short, because they are not in the browser.
Wireless security assessments
Rogue access points, weak segmentation between guest and corporate networks, and the wireless path into environments that were hardened everywhere else.
Physical security penetration testing
Perimeter, access control, surveillance, guard procedures and the human processes around them, under signed authorization naming locations, permitted techniques and stop conditions. Environments with public access by design produce findings a corporate office does not.
ENGAGEMENT PHASES
How the work runs
WHO THIS IS FOR
Roles Elevate works with on this standard
GET STARTED
Ready to find out what an attacker would actually reach?
Elevate Consult builds the test plan around your environment and the frameworks driving the requirement, tests across the surfaces that matter, and delivers findings with the exploitation path, the evidence and the retesting that assessors now expect.
FAQ
Common Questions
How is penetration testing different from vulnerability scanning?
A scan uses automated tools to identify potential weaknesses and assigns severity from a database. A penetration test exploits those weaknesses to establish actual risk and impact, and surfaces issues scanners miss or misclassify entirely, including business logic flaws and chained weaknesses that are individually low severity. Under PCI DSS the two are separate requirements: scanning sits at 11.3 and penetration testing at 11.4, and one does not satisfy the other.
How often does PCI DSS require penetration testing?
Internal and external testing at least once every 12 months and after any significant infrastructure or application upgrade or change, under Requirements 11.4.2 and 11.4.3. Where segmentation is used to reduce scope, segmentation testing is required at least every 12 months under 11.4.5, and at least every six months for service providers under 11.4.6 plus after any change to segmentation controls.
Does our penetration tester need to be a QSA?
No. PCI DSS explicitly does not require the tester to hold a QSA or ASV credential. What it does require is organizational independence: the tester can be an internal resource provided they are not responsible for managing the environment being tested, or a qualified external third party. Assuming a QSA is required is a common and expensive misunderstanding.
Does GDPR require penetration testing?
Not by name. Article 32 requires a process for regularly testing, assessing and evaluating the effectiveness of technical and organizational measures for ensuring security of processing. Penetration testing is a well-recognized way to satisfy that, but the regulation does not mandate it specifically, and material presenting it as a GDPR requirement overstates the obligation.
What testing does the GLBA Safeguards Rule require?
Covered non-bank financial institutions must conduct annual penetration testing and semi-annual vulnerability assessments, or implement continuous monitoring that achieves comparable outcomes. It is one of the most concrete obligations in the Rule and one of the most consistently absent when a programme is reviewed.
Can one test satisfy several frameworks?
Often, but only if it is scoped that way from the start. The frameworks differ on cadence, on what must be in scope, on tester independence and on what the report has to contain. A test scoped for one framework and later presented for another usually fails on scope or on evidence format rather than on the testing itself. Establishing every applicable requirement before the test plan is written is what makes reuse possible.