PCI DSS Penetration Testing

Yes. Requirement 11.4 of PCI DSS v4.0 calls for external penetration testing under 11.4.3 and internal penetration testing under 11.4.2, both at least once every 12 months and again after any significant infrastructure or application change, so a test that covers only the perimeter does not satisfy the requirement on its own. The two look at different things: the external test meets your internet-facing cardholder data environment the way an attacker on the internet does, while the internal test starts from an assumed foothold inside your network and goes after the routes that reach card data from a compromised adjacent system, which is where the damaging findings usually are. We scope both from your actual card-data flows rather than a hostname list, run them by hand rather than leaning on a scanner, and map each finding to the requirement it evidences so your assessor can accept the report. Where segmentation is claimed, segmentation testing is a third, separate obligation covered below.

Yes, and for most payment estates it is the test that pays for itself. Requirements 11.4.5 and 11.4.6 require that, where segmentation is used to isolate the cardholder data environment from other networks, those controls are tested at least every 12 months, and at least every six months for service providers. The test is an attempt to cross from an out-of-scope network into the CDE: if the segmentation holds, the out-of-scope networks stay out of scope, and your assessment, and the cost and effort behind it, stays small. If it does not hold, systems you assumed were irrelevant are suddenly in scope, which is exactly the surprise you want to find before an assessor does. We attempt the crossing from the networks your design says should be unable to reach the CDE, document what we could and could not reach, and give you evidence that either confirms your scope or shows precisely where the segmentation needs work before your assessment.

The formal PCI DSS outcome, a Report on Compliance for a Level 1 entity or a Self-Assessment Questionnaire for the others, is produced against your assessment by a Qualified Security Assessor or, for an SAQ, attested by you; SecureRoot is not a QSA and does not sign either, and anyone telling you a penetration test alone makes you PCI compliant is overselling it. What Requirement 11.4 needs from a penetration test is a specific deliverable: external and internal testing plus segmentation testing, against a documented industry methodology, with exploitable findings corrected and retested. That deliverable is what we produce, written so your QSA can rely on it rather than re-do it. If you do not yet have a QSA we will say so plainly and focus on getting the testing and remediation to the state an assessment expects; if you only need the 11.4 evidence to hand to an assessor you already work with, that is the engagement. Either way the report is built for the assessor who reads it.

The baseline is at least once every 12 months for both external and internal penetration testing, under Requirements 11.4.3 and 11.4.2, and again after any significant change to the infrastructure or applications in or connected to the cardholder data environment, which is the clause teams forget between annual cycles. A major release, a new payment integration, a move to a different cloud region or a re-architecture of the network can all count as a significant change and reset the clock. Segmentation testing runs at least every 12 months and, if you are a service provider, at least every six months under 11.4.6. The practical way to plan is to run the clock from your last test and book the next one at least a quarter before your assessment window, so there is room to fix and retest exploitable findings rather than compress remediation. On the scoping call we help you place the test in your assessment calendar so the evidence is current when the assessor asks for it.

The cardholder data environment and everything connected to it, which is narrower than the whole company but usually wider than teams first assume. In scope are the systems that store, process or transmit card data, plus any system that can connect to or affect the security of those systems, which is why connected administration, logging, authentication and shared services often get pulled in. Segmentation is the lever that controls this: effective, tested segmentation keeps out-of-scope networks out of scope, while segmentation that fails on test drags them in. The first job on the scoping call is therefore to map the card-data flows and the segmentation honestly, because testing the wrong boundary produces a report an assessor will not accept. We scope the test to match the assessment, not to a convenient subset, and where we think your scope is larger than it needs to be we will point to where better segmentation would shrink it rather than quietly bill for the extra surface.

Most engagements run two to four weeks of testing depending on the size of the cardholder data environment and whether segmentation testing is in scope, plus a retest window once exploitable findings are fixed. The indicative range for the underlying web application, API or network tests is the band on our penetration-testing services, with the retest included; where a PCI engagement lands depends on how many external and internal targets are in the CDE, how many segmentation boundaries need testing, and whether a significant change means a mid-year retest as well as the annual test. Those are ranges, not quotes: the number of in-scope systems and segmentation boundaries moves the figure far more than a rate card does. You receive a fixed price in writing after the scoping call, held for the scope we agreed, and our guide to penetration testing cost in India, linked below, explains the drivers. A service provider testing segmentation every six months should budget for two cycles a year.

PCI DSS does not require CERT-In empanelment; the two are different regimes, and conflating them is a common mistake. PCI DSS is a global card-industry standard whose assessments are performed by Qualified Security Assessors; CERT-In empanelment is an Indian scheme that matters where a regulator or a tender specifically requires the formal VAPT report to be signed by an empanelled auditor, which is a separate requirement from a PCI assessment. To be clear about our own position: SecureRoot is not a CERT-In empanelled auditing organisation and not a QSA. What we are is the team that does the hands-on penetration testing and segmentation testing Requirement 11.4 depends on, and produces evidence an assessor accepts. Where your situation genuinely needs an empanelled signature or a QSA, that is a different party and we tell you which one on the scoping call rather than after the work, so you are never surprised about who can sign what.