Internal Network Penetration Testing

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 Startup Pentest plan, tested over 5 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 Growth Pentest plan over 10 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. Each additional scope adds 5 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 Growth 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.