Password Length: More than Just a Question of Compliance
Password length requirements are a key part of password security, but, with PCI, NIST, OWASP, and CIS offering different recommendations, what length is best?
Real skill leaves evidence. Your PCI report is full of it: where the CDE broke under a real attack, and proof the fix holds.
Real lateral movement from out-of-scope networks toward the CDE. We prove your segmentation works, not that it looks right on a network map.
Documented methodology, exploitation evidence, prioritized remediation, and retesting your security team and QSA can stand behind.
Hands-on testing of gateways, tokenization, carts, and integrations. The systems that move card data, not just the network perimeter.
| PCI area | Description | How Raxis supports it |
|---|---|---|
| 11.4.1 | Maintain a penetration testing methodology | Documented rules of engagement, scope, approach, tools, exclusions, and evidence, aligned with the standards above. |
| 11.4.2 | Internal penetration testing | Manual exploitation across in-scope internal CDE networks and systems. |
| 11.4.3 | External penetration testing | Internet-facing testing against CDE-connected assets, exposed services, and attack paths. |
| 11.4.4 | Remediation and retesting | Findings include fix guidance, and retesting verifies corrective actions. |
| 11.4.5 | Segmentation testing where segmentation is used to reduce scope | Attempts to bypass segmentation and validate CDE isolation from out-of-scope networks. |
| 11.4.6 | Service provider segmentation testing every six months | Six-month segmentation testing for service providers, validating CDE isolation. |
| 11.4.7 | Multi-tenant service provider support for customer external testing | Support for customer external penetration testing under 11.4.3 and 11.4.4. |
Qualified means demonstrable penetration testing experience and credentials your QSA will recognize. Raxis testers hold certifications including OSCP, OSWE, OSCE, OSEP, GPEN, and CISSP, and every PCI engagement is led by a senior U.S.-based tester. See our team certifications for the full list.
Independence is where internal teams usually fall short. Even a capable in-house security team often manages or influences the controls under test, which a QSA can flag. A third-party test removes the question entirely and gives your QSA evidence with no asterisk on it.
PCI DSS does not require your penetration test to come from a QSA or an ASV. Those designations apply to assessors and scanning vendors, not pen testers. What Requirement 11.4 does require is that the tester be qualified and organizationally independent from the team that manages the systems being tested. Your network admin cannot pentest their own firewall rules.
Quarterly internal and external scans (11.3.1 and 11.3.2) sit alongside pen testing. We validate which scan findings an attacker can actually exploit, so you fix what matters first.
PCI v4.0.1 targets e-skimming and Magecart-style attacks on payment pages. We test the client-side scripts, redirects, and third-party JavaScript that put cardholder data at risk in the browser.
Public-facing apps and APIs in the payment path must be evaluated annually and after significant change. Our web app and API testing surfaces the logic flaws and authorization gaps scanners walk past.
Internal and external penetration testing at least annually, plus after any significant change to the environment. Segmentation testing at least annually where segmentation reduces scope.
Same annual internal and external testing, but segmentation testing every six months and after any change to segmentation controls.
New infrastructure, a major app release, network re-architecture, or moving the CDE all trigger a fresh test regardless of when the last one ran.
| SAQ Type | Who Uses It | Pentesting Required |
|---|---|---|
| SAQ A | E-commerce fully outsourced to a validated third party; no card data touches your systems | None. But 11.6.1 payment page monitoring and 6.4.3 script controls now apply |
| SAQ A-EP | E-commerce sites that don’t store card data but affect transaction security | External pen test (11.4.3), plus segmentation testing (11.4.5) where segmentation is used |
| SAQ B / B-IP | Imprint machines or standalone dial-out / IP-connected terminals | No internal or external pen test. B-IP: segmentation testing (11.4.5) where segmentation reduces scope |
| SAQ C | POS or payment application systems connected to the internet; no electronic storage | No internal or external pen test. Segmentation testing (11.4.5) where segmentation reduces scope |
| SAQ C-VT | Web-based virtual terminals, one transaction at a time | None |
| SAQ P2PE | Validated point-to-point encryption solution only | None |
| SAQ D (Merchant) | Everyone else, including anyone storing cardholder data electronically | Full 11.4: internal (11.4.2), external (11.4.3), remediation retesting (11.4.4), annual segmentation testing (11.4.5) |
| SAQ D (Service Provider) | Service providers eligible for self-assessment | Full 11.4, with segmentation testing every six months (11.4.6) and multi-tenant support obligations (11.4.7) |
| ROC (Level 1) | Merchants over 6M transactions/year and service providers assessed by a QSA | Full 11.4, same as SAQ D for your entity type |
Scans are useful. They are not manual exploitation, business logic testing, or attack-path validation. You can tell when it’s real, and so can a QSA.
If segmentation reduces your scope, it has to hold under attack. We run real paths from out-of-scope networks toward the CDE and document what gets through.
Gateways, tokenization, carts, client-side JavaScript, APIs, redirects, and third-party integrations all shape PCI risk. We test the whole flow.
A ticket marked “fixed” does not prove the risk is gone. We retest corrective actions and document what changed.
Firewall, ACL, VLAN, and routing misconfigurations that let out-of-scope systems talk to the CDE. The exact paths 11.4.5 exists to catch.
Broken authentication, IDOR, injection, and weak session handling in the APIs and gateways moving card data.
Low-privilege accounts climbing to admin through patch gaps, weak RBAC, and configuration flaws once inside the boundary.
Non-essential services running on CDE-connected hosts that hand an attacker a foothold.
Third-party scripts and tag managers on payment pages that can be abused to lift card data straight from the browser.
The tester on your scope call is the one breaking into the CDE. And the one retesting your fix.
Senior testers validate attack paths by hand. Several ran retail cybersecurity before Raxis, so they test the way someone who has defended these systems would attack them.
We test whether your CDE boundary holds under real lateral movement, not whether it passes a config review.
We have pulled cardholder data, intercepted live transactions, and gained administrator access at Fortune 500 retailers.
Every report includes scope, methodology, evidence, impact, remediation, and retest status, written by the engineer who did the work. Built for a QSA to review and accept.
Reports and evidence land in Raxis One, with Trust Center documentation for controls, SOC 2 status, insurance, and data handling.
Raxis Attack PTaaS delivers continuous, AI-assisted PCI testing with real-time results and unlimited retesting, so you are not flying blind for 11 months between engagements.
Live system count, the size of in-scope apps and APIs, and how much sits inside the CDE versus connected to it.
The number of distinct segmentation methods and out-of-scope zones we test paths from. More boundaries, more validation.
Black box, grey box, or white box. Deeper access means deeper coverage and more tester hours.
Wireless, social engineering, payment app testing, and physical testing layered onto the core PCI scope.
Written by the Raxis engineers who run these tests, from real engagements and research.
Password length requirements are a key part of password security, but, with PCI, NIST, OWASP, and CIS offering different recommendations, what length is best?
Scoping your penetration test (especially your first one) can be daunting. Our team is always happy to help, and Brad Herring gives you a head start here.
Brad Herring continues our three-part “Choosing a Penetration Testing Company” series with a look at the factors to consider when choosing the best vendor.
Yes. Requirement 11.4 covers your testing methodology, internal and external testing, remediation validation, and segmentation testing where segmentation reduces PCI scope.
The pentesting requirements moved from 11.3 to 11.4 and became more prescriptive. The methodology must now be defined, documented, and implemented per 11.4.1, including retention of results and remediation records for at least 12 months. Internal vulnerability scans must now be authenticated (11.3.1.2). New requirements 6.4.3 and 11.6.1 target payment page scripts and e-skimming, and 11.4.7 adds obligations for multi-tenant service providers to support customer external testing. If your last pentest report references 11.3, it was written against a retired standard.
Merchants test internally and externally at least annually and after significant changes, with segmentation testing at least annually where used. Service providers test segmentation every six months.
Most PCI engagements run from roughly $8,000 for a tight CDE to $100,000 or more for large, multi-segment environments. Scope, segmentation complexity, test type, and add-ons set your number. We give you a fixed quote before testing starts.
Most PCI penetration tests run one to three weeks of active testing, depending on the size of the CDE, the number of segmentation boundaries, and how many applications and APIs are in scope. A segmentation-only test for a service provider is usually days, not weeks. Plan backwards from your QSA assessment date and leave room for remediation and retesting, which is its own pass.
No. Scanning falls under 11.3 and pen testing under 11.4. Both are required, and they do different jobs. A scan lists what might be wrong. A pentest proves what an attacker can actually do with it.
Yes. When segmentation isolates the CDE, we test whether out-of-scope systems can reach or affect in-scope CDE systems, the way 11.4.5 requires.
Yes. We test payment apps, APIs, e-commerce workflows, authentication, authorization, business logic, and the integrations that shape cardholder data risk.
Yes. Reports include scope, methodology, evidence, findings, severity, remediation guidance, and retest status, so your QSA can see exactly what was tested and validated.
PCI expects results and remediation records held for at least 12 months. Your full history and retest evidence stay in Raxis One for as long as you need them.
No. We work inside strict contractual boundaries with clear rules of engagement. The goal is to expose vulnerabilities without downtime, data loss, or interruption to live transactions.
No. QSA and ASV designations apply to compliance assessors and scanning vendors, not penetration testers. PCI DSS 11.4 requires a qualified tester who is organizationally independent of the systems under test. That can be a third party like Raxis or, in theory, an independent internal team, though in-house teams often fail the independence requirement because they manage the controls being tested. Raxis testers hold OSCP, OSWE, OSCE, OSEP, GPEN, and CISSP certifications.