Key Findings:
- PCI DSS v4.0.1 makes internal penetration testing a named annual obligation under Requirement 11.4.2, separate from the external test under 11.4.3, with retest verification required under 11.4.4.
- In a Windows estate the internal test is largely an Active Directory test. Kerberoasting, AS-REP roasting, delegation abuse, NTLM relay and local administrator password reuse are the findings that chain into domain compromise.
- Network segmentation testing is its own requirement with its own clock: at least every 12 months under PCI DSS Requirement 11.4.5, and at least every six months for service providers under 11.4.6.
- The deliverable an assessor uses is the attack path narrative plus the retest report, not the raw findings list.
An internal network penetration test starts from a position inside your network perimeter and answers one question: if an attacker already has a foothold, how far can they get and how fast. It is a separate exercise from an external test, and most compliance standards treat it that way. 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 upgrade or change, by a qualified internal resource or qualified external third party with organizational independence. In a Windows environment the test is mostly an Active Directory test, because Active Directory is the authorization layer that decides how far a single compromised account travels. The evidence an assessor wants back is a scope statement, findings with reproduction steps, an attack path narrative, and a retest confirming the fixes.
Cybersecify is a founder-led penetration testing firm in Bengaluru. Internal network penetration testing is one of our ten pentest scopes, and it is the one buyers understand least before they buy, usually because they arrive at it through a compliance requirement rather than through a security review. This page is the buyer-side explanation: what the test is, what triggers the requirement, what it produces, and what it does not cover.
What is an internal network penetration test?
You have a web application pentest report. Your auditor or your payment processor asks for an internal penetration test as well, and the obvious question is why the first one does not count.
It does not count because the two tests start in different places. An external pentest starts on the public internet with no credentials. An internal network penetration test starts from a position inside your network perimeter and answers one question: if an attacker already has a foothold, how far can they get and how fast.
The tester begins with the access a compromised laptop or a contractor VPN account would give. From there the work is enumeration, credential attacks, lateral movement and privilege escalation. Which hosts are reachable. Which file shares are readable by any domain user. Which service accounts have weak passwords. Which machines trust which other machines. Whether the finance VLAN can reach the production database VLAN even though a diagram says it cannot.
This is called an assumed-breach position, and it is not a pessimistic assumption. It is the ordinary starting point of a real incident: a phished credential, a stolen laptop, a third-party maintenance connection, or an unpatched service on a machine nobody owns any more.
How is an internal network pentest different from an external pentest?
| External pentest | Internal network pentest | |
|---|---|---|
| Starting position | Public internet, no credentials | Inside the perimeter, standard user account |
| Question answered | What can a stranger reach? | How far does one compromised account travel? |
| Typical targets | Edge devices, exposed services, public web apps | Domain controllers, file shares, internal databases, management interfaces |
| Signature findings | Exposed admin panels, unpatched edge software, subdomain takeover | Kerberoasting, NTLM relay, delegation abuse, credential reuse, flat network |
| Compliance home | PCI DSS Requirement 11.4.3 | PCI DSS Requirement 11.4.2 |
| What a clean result proves | The front door is locked | One compromised laptop does not reach production |
A clean external test tells you the front door is locked. It says nothing about whether one compromised laptop reaches your production database. That second question is the one that decides how bad an incident becomes, and it is why PCI DSS names the two tests as separate requirements rather than as alternatives.
If you are still deciding which surfaces you need tested at all, how to scope your first pentest covers the general scoping decision.
Does PCI DSS require an internal penetration test?
Yes, and the wording is specific enough to quote at a vendor.
PCI DSS v4.0.1 Requirement 11.4.2 states that internal penetration testing is performed at least once every 12 months and after any significant infrastructure or application upgrade or change, in accordance with the entity’s defined methodology under Requirement 11.4.1, by a qualified internal resource or qualified external third party, with organizational independence of the tester.
Three details in that sentence catch buyers out:
“At least once every 12 months and after any significant change.” The annual cadence is a floor, not the whole obligation. A domain migration, a new site, a cloud landing zone, or a merger that joins two directories is a significant change, and the clock restarts.
“By a qualified internal resource or qualified external third party.” The standard does not require a QSA or an ASV to run the test. It requires a defined methodology and a qualified tester.
“Organizational independence of the tester exists.” This is the condition most in-house teams fail. The person who built and runs the systems cannot be the person who signs the test of those systems.
Requirement 11.4.3 imposes the same cadence on external penetration testing. Requirement 11.4.4 then requires that exploitable vulnerabilities and security weaknesses found during testing are corrected and that testing is repeated to verify the corrections. That last one is why a retest is part of the compliance deliverable rather than a nice extra, and why we include one free retest in both pentest plans rather than quoting it separately.
Why does Active Directory decide the outcome of an internal network pentest?
Because in a Windows estate Active Directory is the authorization layer for almost everything, so compromising it compromises the rest by design rather than by accident.
Nearly every finding that turns an internal test from a list of patch gaps into a full domain compromise is an Active Directory finding:
- Kerberoasting. Any authenticated domain user can request a service ticket for an account with a service principal name, then crack it offline. A service account with a password set in 2019 and never rotated is a straight line to whatever that account can do.
- AS-REP roasting. Accounts with Kerberos pre-authentication disabled hand out a crackable blob to anyone who asks, with no credentials required beyond knowing the username.
- Unconstrained and constrained delegation abuse. A host configured to impersonate users to other services is a host that, once compromised, impersonates the users who touch it.
- NTLM relay and credential replay. Where SMB signing is off, an authentication attempt can be relayed to another machine and used there. This is a configuration default rather than a vulnerability with a CVE, which is why scanners rarely lead with it.
- Local administrator password reuse. One local administrator password shared across the workstation fleet turns a single compromised machine into the whole fleet.
- Over-permissive file shares. A share readable by any domain user containing a deployment script with a plaintext credential in it is a finding we see more often than any of the above.
Individually these read as configuration notes. Chained, they are a path from one ordinary user account to Domain Admin, and the chain is the finding. That is why our internal reports carry an attack path narrative alongside the findings table: the narrative is the part your engineering team acts on, because it shows which single fix breaks the chain.
The same reasoning is why an automated scanner is a poor substitute here. A scanner reports SMB signing as a medium-severity configuration item. It does not walk the relay to a domain controller and tell you what that got. Manual pentest versus automated scanning covers the general version of this argument.
What is network segmentation testing and is it a separate requirement?
Segmentation testing checks whether the network boundaries you have documented actually block traffic in practice. The tester sits in one zone and attempts to reach services in another that should be unreachable, then reports what got through.
It is a separate requirement under PCI DSS, with its own clock:
- Requirement 11.4.5: where segmentation is used to isolate the cardholder data environment from other networks, penetration testing is performed on those segmentation controls at least once every 12 months and after any changes to segmentation controls or methods.
- Requirement 11.4.6: for service providers, that becomes at least once every six months.
So a merchant and a service provider with identical networks have different testing calendars. Check which one you are before you set the cadence, because getting this wrong is a scheduling failure that shows up as a gap at assessment time rather than as a finding.
Practically, segmentation results are reported as their own section. An assessor reads them separately from the general findings, and burying a segmentation result inside a list of patch findings makes their job harder and yours slower.
Which Indian regulations ask for internal testing?
If you are a regulated entity in India rather than a merchant handling card data, the driver is different.
RBI’s Cybersecurity, Technology: Risk, Resilience and Assurance Framework Directions, 2026 were issued on 31 July 2026 and took effect immediately upon issuance. For critical information systems and those in the DMZ having a customer interface, they require vulnerability assessment at least once in every six months and penetration testing at least once in 12 months (paragraph 151), conducted by appropriately trained and independent information security experts or auditors (paragraph 155). For non-critical systems, RBI directs a risk-based approach to requirement and periodicity rather than a fixed cadence.
The Directions are issued separately per entity class, so the applicable instrument depends on how you are regulated. The Commercial Banks version is RBI/DoS/2026-27/410, with parallel versions for NBFCs, Urban Co-operative Banks, Payments Banks, Small Finance Banks, All India Financial Institutions and Credit Information Companies. Paragraphs 151 and 155 above are numbered as they appear in the Commercial Banks instrument, so cite the corresponding paragraph in your own entity class rather than these numbers.
Two things follow for a SaaS company selling into this sector. First, the DMZ scoping language means the systems that face a customer are explicitly named, so the internal side of your estate is not automatically out of frame. Second, paragraph 155’s independence wording is the clause that decides whether an in-house team can satisfy the requirement at all. Our RBI cybersecurity framework guide has the wider context for fintech buyers.
What evidence does an internal network pentest produce for an auditor?
Four things, and they are worth naming because vendors differ on how many of them you get.
A scope statement. The ranges, domain and boundaries tested, written so an assessor can compare the coverage against your documented environment. A report that does not say what was in scope evidences nothing.
Findings with severity, reproduction steps and business impact. This is the part that evidences ISO 27001:2022 A.8.8, management of technical vulnerabilities. A findings register with severities and a dated remediation trail is the strongest claim a test report makes. The test event itself supports A.8.29, security testing in development and acceptance.
An attack path narrative. How the findings chained. This is not an auditor requirement, but it is the section that gets the findings fixed, and a fixed finding is what the retest needs.
A retest report. PCI DSS Requirement 11.4.4 asks that exploitable vulnerabilities are corrected and that testing is repeated to verify the corrections. Our retest is delivered as a v2.0 report that supersedes v1.0, with per-finding retest status and fresh evidence of the fixed state, rather than a one-line email saying the issues are closed.
Against SOC 2, an internal network test supports CC7.1 (Vulnerability Detection) and CC4.1 (Ongoing and/or Separate Evaluations), because an independent third-party test is a separate evaluation of your controls. Penetration testing for SOC 2 covers what auditors do and do not accept in more detail.
One thing to be clear about, since we say it everywhere else: a pentest report evidences A.8.8 and A.8.29. It does not evidence A.8.25, secure development life cycle, which is evidenced by process rather than by a test result. A vendor telling you otherwise is padding a control mapping.
What does one scope mean for an internal network pentest?
Scope inflation is the usual way an internal engagement goes wrong, so here is our unit, stated plainly.
One scope is one Active Directory domain, up to 256 live hosts (a single /24), and up to 3 segmentation boundaries.
That covers a normal single-site or single-VPC estate. It does not cover a second domain, a second site with its own address space, a fourth segmentation boundary, or a host count materially above 256. Those make it a larger engagement, and a larger estate is quoted as a custom proposal rather than compressed into a fixed tier.
We would rather tell you the estate needs a custom scope than sell you a five-day test that cannot cover it. Scoping is a call with both founders, and the ranges go into the statement of work as ranges, not as a description.
Does an internal network pentest have to be done on site?
No, and most of ours are not.
The usual arrangement is a remote assumed-breach position: a VPN account with the access an ordinary employee would have, a jump host you provide, or a small virtual machine we stand up inside the network for the duration of the engagement.
On-site is worth doing when the thing you want tested is physical. Whether an unmanaged device plugged into a conference room port reaches the server VLAN is a question you cannot answer over a VPN. It is also the answer when your own policy will not permit remote access into the environment.
Decide this at scoping rather than mid-engagement. The access method changes what can be tested, and both sides should agree on it in writing before the start date.
What does a tester need from you before an internal network pentest starts?
Five things, and gathering them is usually the slowest part of the whole engagement.
- The IP ranges in scope, written as ranges rather than as a description of the environment.
- The Active Directory domain name and one standard low-privilege domain user account. Assumed breach means starting where a phished employee starts, not with an administrator account.
- A working access method: VPN credentials, a jump host, or agreement for us to deploy a virtual machine.
- A named technical contact reachable during testing hours who can quickly confirm whether something we are seeing is expected.
- A written out-of-scope statement, including any fragile legacy system that must not be touched.
Sorting this out before the start date is the difference between five business days of testing and five business days of waiting for a VPN account. It is the single biggest predictor of whether an internal engagement lands well.
How often do you need an internal network penetration test?
Annually is the floor that most standards converge on, plus an event-driven trigger.
PCI DSS v4.0.1 Requirement 11.4.2 asks for internal penetration testing at least once every 12 months and after any significant infrastructure or application upgrade or change. RBI’s 2026 Directions ask for penetration testing at least once in 12 months and vulnerability assessment at least once in every six months for critical information systems and those in the DMZ having a customer interface, with a risk-based cadence for non-critical systems.
Beyond the calendar, retest after any of these:
- A domain migration, or a merger that joins two directories
- A new site, a new VPN, or a new cloud landing zone connected to the estate
- A change to segmentation controls or firewall rulesets between zones
- A jump in headcount that changed who holds local administrator rights
- An incident, however small, that showed an attacker reaching further than expected
When to re-pentest covers the general version of this decision for application scopes.
Can our own IT team do the internal penetration test?
Sometimes for PCI DSS, rarely for anyone else.
PCI DSS v4.0.1 Requirement 11.4.2 permits a qualified internal resource, but it also requires organizational independence of the tester. In practice that means the person testing cannot be the person who built and runs the systems under test. Most in-house teams fail the independence condition rather than the qualification one.
SOC 2 auditors generally expect an independent third party. RBI’s 2026 Directions ask for appropriately trained and independent information security experts or auditors at paragraph 155 of the Commercial Banks version.
There is also a practical problem separate from the compliance one. Your own team knows the intended design, and an internal test is mostly about finding the gap between the intended design and the actual configuration. A tester who does not already know the answer looks harder, and looks in places the design says are not worth looking.
How much does an internal network penetration test cost?
Our published pentest pricing does not change by scope type:
- Startup Pentest, INR 74,999: one scope, 5 business days, one free retest within one month of the v1.0 report.
- Growth Pentest, INR 1,79,999: two scopes, 10 business days, one free retest, plus SOC 2 and ISO 27001 evidence mapping.
If you are buying an internal network test alongside an external or web application test, that is two scopes, which is what the Growth plan is built for. Each additional scope adds 5 business days, so three scopes is 15 business days and four is 20. Scopes run sequentially by default. Parallel testing is available on request and is never guaranteed, because it depends on who is free that week.
Estates larger than one domain and 256 hosts are quoted as a custom proposal. For the wider market range on pentest pricing in India, see our pentest cost breakdown.
How we run internal network engagements
Rathnakara (OSCP, M.Sc Cyber Security) leads the testing. Both founders are on every engagement. The methodology baseline is PTES and NIST SP 800-115, with MITRE ATT&CK used to describe the techniques in terms your blue team already tracks.
The deliverable is a technical report with reproduction steps per finding, an attack path narrative, an executive summary, CVSS v3.1 severity scoring, segmentation results reported separately where segmentation is in scope, and one free retest within one month of the v1.0 report delivered as a v2.0 report.
Two things we are not: we are not CERT-In empanelled, and we are not ourselves ISO 27001 or SOC 2 certified. We deliver the testing evidence and the control mapping. A separate accredited certification body or licensed CPA firm issues the certificate or the attestation.
Internal network pentest service | See a sample report | View pricing | How to read a VAPT report | Book a 30-minute scoping call
Corrections
- 2026-09-04: Added the entity class to the quoted RBI paragraph numbers, in both places they appear. Paragraphs 151 and 155 were read in the Commercial Banks instrument (RBI/DoS/2026-27/410) only, and the post stated them as though they held across every entity class. The Directions are issued in seven per-entity-class versions and the other six were not opened, so an NBFC or Urban Co-operative Bank reader is now told to cite the paragraph in its own version.