Internal Network Penetration Testing for PCI DSS 11.4.2

One scope is one Active Directory domain, up to 256 live hosts and up to 3 segmentation boundaries. Larger estates and multi-forest environments are quoted as a custom scoping proposal rather than squeezed into a fixed scope, because the enumeration and attack-path work grows with the estate rather than staying flat. If you are not sure how many live hosts you actually have, tell us what you know and both founders will size it with you before you buy anything. There is no charge for that conversation.

One internal network scope is INR 74,999 plus taxes under the Essentials Plan, tested over 6 business days from kickoff to the v1.0 report. Pairing it with an external network test, which is the combination most compliance programmes actually ask for, is two scopes at INR 1,79,999 plus taxes under the Compliance Plan over 12 business days, and that plan adds SOC 2 and ISO 27001 control mapping per finding plus a signed Letter of Attestation. Business days are Monday to Friday. A scope is 6 business days. Both plans include founder-led consulting hours and one full retest within one month of the v1.0 report.

In most Windows estates Active Directory is the control plane, so the interesting question is not whether one host is vulnerable but whether a normal user account can be walked into domain-wide control. That is why the work centres on attack paths rather than a host-by-host vulnerability list: delegation misconfiguration, service account privileges, credential material left in memory or on shares, relay opportunities where signing is not enforced, and nested group membership nobody has audited. A finding that a single workstation is missing a patch is worth far less to you than a documented path from a standard account to Domain Admin.

PCI DSS v4.0.1 requirement 11.4.2 requires internal penetration testing at least once every 12 months and after any significant infrastructure or application change. It is a separate obligation from requirement 11.4.3, which covers external penetration testing, so meeting one does not meet the other. Requirements 11.4.5 and 11.4.6 add segmentation testing on their own cadence where segmentation is used to reduce scope. The tester must be a qualified internal resource or a qualified external third party with organizational independence, and the standard notes the tester is not required to be a QSA or an ASV. Cybersecify is neither a QSA nor an ASV, so we can perform the testing but cannot conduct your assessment or sign your Report on Compliance.

A technical report with reproduction steps for every finding, CVSS severity, business impact in plain language, and remediation guidance, plus a two-page executive summary. On the Compliance Plan each finding is mapped to the control it evidences: ISO 27001:2022 A.8.8 management of technical vulnerabilities and A.8.29 security testing in development and acceptance, and SOC 2 CC7.1 vulnerability detection and monitoring. A pentest report does not evidence A.8.25 secure development life cycle, which is evidenced by your development process rather than by a test, and we do not claim it. The retest produces a v2.0 report showing which findings were verified fixed, which is what an auditor usually wants to see rather than a list of open items.

For your own assurance, yes, and internal testing is useful. For most compliance programmes, no. PCI DSS requires organizational independence of the tester, and SOC 2 CC7.1 evidence is weaker when the people who built and run the network are the same people attesting that it holds. The practical problem is also one of perspective: an internal team tests the network it designed, against the threat model it already has in its head. The independence requirement exists because that blind spot is predictable.

Cybersecify performs internal network penetration testing, and it is bought most often by companies running a Windows Active Directory estate, by merchants and service providers carrying a PCI DSS Requirement 11.4.2 obligation, and by RBI-regulated entities whose auditors ask for internal testing by name. That is a different buyer from the SaaS startup most of our other pages are written for, and it is worth saying plainly: if your whole estate is cloud-hosted with no corporate domain, an internal network test is usually the wrong engagement and a cloud pentest is the right one. Both founders are hands-on on every engagement, the lead tester is OSCP-certified, and we are neither a QSA nor an ASV, so we can perform the testing your standard requires but cannot conduct your assessment or sign your Report on Compliance.