Key Findings:
- PCI DSS v4.0.1 makes external penetration testing a named annual obligation under Requirement 11.4.3, separate from the internal test under 11.4.2. Buying one does not satisfy the other, and this is the mistake we see most often.
- An external test starts with nothing: no account, no credential, no foothold. That constraint is the point, because it is the position a real attacker starts from.
- An external network penetration test is not a vulnerability scan and is not an ASV scan. We are not a PCI SSC Approved Scanning Vendor and we are not a Qualified Security Assessor.
- The external attack surface inventory is the part of the report we get asked about most, because it is the only section a buyer can compare against their own asset register.
An external network penetration test starts on the public internet with no access and no credentials, and answers one question: can someone get in. The target is your internet-facing perimeter, meaning public IP addresses and hostnames, exposed services and their versions, remote access endpoints such as VPN and mail, TLS configuration, and the firewall rules that are live rather than the ones on the diagram. PCI DSS v4.0.1 Requirement 11.4.3 requires external 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. It is a separate obligation from the internal test under Requirement 11.4.2, not an alternative to it. The evidence an assessor wants back is a scope statement, an external attack surface inventory, findings with reproduction steps, and a retest confirming the fixes.
Cybersecify is a founder-led penetration testing firm in Bengaluru. External network penetration testing is one of our ten pentest scopes. Most buyers arrive at it the same way: a compliance programme, an enterprise customer’s security review, or an investor’s diligence checklist asked for external network testing by name, and nothing they already bought covers it. This page is the buyer-side explanation of what the test is, what it covers, what it does not cover, and what we can and cannot claim about it.
What is an external network penetration test?
You have a web application pentest report. Your auditor, your payment processor or your largest customer asks for an external network penetration test, and the obvious question is why the report you already have does not count.
It does not count because a web application test scopes an application. An external network penetration test scopes a perimeter, and a perimeter is bigger than the applications you remember deploying. It includes the VPN concentrator, the mail server, the jump host somebody stood up for a migration in 2023, the staging environment that was supposed to be behind an IP allow list, and the management interface on an edge device that shipped with a web console enabled.
The tester starts where an attacker starts, with nothing. No account, no credential, no network access, no diagram. The first day of the engagement is spent working out what you actually have facing the internet, and that inventory is frequently the part of the report that surprises the client most.
The question the test answers is narrow and useful: can someone get in.
What is the difference between an external and internal network penetration test?
This is the distinction buyers get wrong most often, usually because a vendor sold them one and let them believe it covered both.
| External network pentest | Internal network pentest | |
|---|---|---|
| Starting position | Public internet, no access, no credentials | Inside the perimeter, standard user account |
| Question answered | Can someone get in? | Once someone is in, how far do they get? |
| Typical targets | Public IPs and hostnames, exposed services, VPN and remote access, mail, DMZ, firewall rules | Active Directory, file shares, internal databases, segmentation boundaries |
| Signature findings | Forgotten hosts, exposed admin interfaces, unpatched edge software, weak VPN authentication, subdomain takeover, permissive firewall rules | 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 |
They are complementary, not alternatives. A clean external result means a stranger with no starting advantage could not get through the perimeter during the testing window. It says nothing about what a phished employee credential reaches, and that is the scenario most incidents actually follow.
The reverse is also true. A clean internal result tells you a foothold does not spread far, and says nothing about how easily a foothold is obtained in the first place.
What is an internal network penetration test is the companion to this page and covers the internal side in the same detail, including Active Directory and segmentation testing.
What we have actually delivered in this shape: one engagement covering an external perimeter and remote access VPN assessment first, followed by an internal assumed-breach assessment, as a single piece of work with one report structure across both. That sequence is the natural one. You establish what an outsider can reach, then you assume the outsider succeeded and measure the blast radius. It is also the two-scope shape our Growth plan is built around.
What gets tested on an external network penetration test?
Here is the working list, in roughly the order the engagement runs.
External asset and hostname discovery. DNS records, certificate transparency logs and passive sources are used to build the internet-facing inventory, then each candidate is confirmed live and confirmed yours. Forgotten hosts surface here more than anywhere else in the engagement, and an asset you did not know you had is an asset nobody is patching.
Port and service enumeration. What is listening on every live external host, on both common and uncommon ports.
Service version fingerprinting and known vulnerability identification. What each reachable service is running and at which version, including the edge devices, VPN concentrators, mail servers and management consoles that were never intended to face the internet. A version banner is a lead, not a finding. It becomes a finding when the exposure is confirmed.
Remote access endpoint testing. VPN, RDP and SSH. Authentication behaviour, lockout policy, exposed management planes, and whether a portal that should serve staff only is serving the entire internet.
The mail perimeter. Relay behaviour, authentication, and SPF, DKIM and DMARC posture. A mail perimeter that permits spoofing of your own domain is a finding that costs you customer trust rather than customer data.
DNS configuration. Zone transfer attempts and subdomain takeover checks against records pointing at services you no longer control.
TLS configuration and certificate validity on every exposed service, including the ones nobody thinks of as a website.
Credential exposure and password spraying, against internet-facing login surfaces, run only where you have authorised it in writing and inside agreed rate limits. Credentials belonging to your staff that already sit in public breach corpora are checked as part of this. Spraying without a written authorisation and a rate limit is an availability risk to your own people, so it is a decision made at scoping, not mid-engagement.
Firewall rule and DMZ boundary validation. What the live rules permit, as opposed to what the network diagram says they permit. This runs throughout rather than as a single step, because every reachable service is evidence about a rule.
How is an external network penetration test different from a vulnerability scan?
Many buyers who ask for an external network penetration test have been quoted an automated external scan, and the two are priced differently for a reason.
A vulnerability scan matches what it observes against a signature database and returns a list of candidates. That is genuinely useful and most compliance programmes require it on its own cadence. It is not a penetration test.
Four differences decide what you get back:
- Confirmation. A scanner reports a version banner and infers a CVE. A tester establishes whether the service is reachable, whether the vulnerable code path is exposed in your configuration, and what using it actually achieves. Every item a scanner reports but a tester cannot exploit as deployed is a week of your engineering team’s time that nobody spends.
- Chaining. A scanner scores each item alone. The finding that matters is usually three medium items that combine: an information disclosure that names a valid username, a login surface with no lockout, and a reused password. Individually, three mediums. Together, entry.
- The categories a scanner cannot see. A forgotten staging host that resolves but appears in no asset register. A VPN portal that accepts unlimited authentication attempts. A firewall rule permitting far more than its documented purpose. Credentials for your staff already exposed in a public breach corpus. None of these have a CVE, so none of these appear in a signature match.
- False positive removal. A tester takes them out before the report reaches you, which is the difference between a findings list your team acts on and a PDF nobody opens twice.
Most compliance programmes require both, because they are different controls with different cadences rather than two names for the same thing. Manual pentest versus automated scanning covers the general argument, and vulnerability assessment versus penetration testing covers the terminology difference that causes most of the confusion in quotes.
Does PCI DSS require an external penetration test?
Yes, under its own requirement number, separate from the internal one.
PCI DSS v4.0.1 Requirement 11.4.3 covers external penetration testing at least once every 12 months and after any significant infrastructure or application upgrade or change, following the methodology defined under Requirement 11.4.1, performed by a qualified internal resource or qualified external third party, with organizational independence of the tester.
Requirement 11.4.2 places the same cadence on internal penetration testing.
These are two separate obligations. Meeting one does not meet the other. A buyer who commissioned an internal test last quarter and expects it to close 11.4.3 will find the gap during assessment rather than during procurement, and by then the calendar is against them.
Three further details catch buyers out:
The annual cadence is a floor, not the whole obligation. A new public IP range, a firewall migration, a new remote access product or a data centre move is a significant change, and the clock restarts.
The tester does not have to hold a PCI credential. The standard notes that the tester is not required to be a QSA or an ASV. It asks for a defined methodology, a qualified tester and organizational independence.
Organizational independence is the condition most in-house teams fail, not the qualification one. The person who configured the firewall cannot be the person who signs the test of that firewall.
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 is why one free retest is inside both of our pentest plans rather than quoted separately.
Are you a PCI SSC Approved Scanning Vendor or a Qualified Security Assessor?
No to both, and this page is where we say it loudest, because the Approved Scanning Vendor programme is also about the external perimeter. If a buyer is going to assume we hold a PCI credential, this is the page where the assumption forms.
We are not a PCI SSC Approved Scanning Vendor. PCI DSS separately requires quarterly external vulnerability scanning performed by an ASV, which is a different obligation from the annual penetration test under 11.4.3. We cannot perform those scans, and this service is not an ASV scan. If your programme needs one, you need an ASV alongside us.
We are not a Qualified Security Assessor. We cannot conduct your PCI DSS assessment and we cannot sign your Report on Compliance. That is a QSA’s role and we do not hold it.
What we can do is the penetration test itself, under the wording the standard actually uses: a qualified internal resource or qualified external third party, with organizational independence of the tester, which the standard notes does not require the tester to be a QSA or an ASV. Our lead tester holds OSCP, credential number OS-101-34173, verifiable with the issuer.
We say this at scoping too, before money changes hands, rather than letting a buyer discover the boundary when their assessor asks for something we never claimed to provide.
Which Indian regulations ask for external testing?
If you are a regulated entity in India rather than an entity handling card data, the driver is different and the DMZ wording is the part to read closely.
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.
The phrase that matters here is systems in the DMZ having a customer interface. The DMZ is the external test’s home ground, so for a regulated entity the external perimeter is named directly rather than reached by inference. Our RBI cybersecurity framework guide has the wider context for fintech buyers.
What evidence does an external network pentest produce for an auditor?
Five artefacts, and it is worth naming them because vendors differ on how many you receive.
A scope statement. The public IP addresses and hostnames tested, written so an assessor can compare coverage against your documented environment. A report that does not say what was in scope evidences nothing.
An external attack surface inventory. What was reachable from the internet at the time of testing. This is the section we field the most questions about, because it demonstrates the perimeter was enumerated rather than sampled, and because it is the only part of the report you can compare line by line against your own asset register.
Findings with CVSS v3.1 severity, reproduction steps and business impact. This is what evidences ISO 27001:2022 A.8.8, management of technical vulnerabilities. The test event itself supports A.8.29, security testing in development and acceptance.
Perimeter and DMZ boundary results. These speak to A.8.20, network security, and A.8.22, segregation of networks, which are the controls an ISO auditor reads when the subject is a perimeter rather than an application.
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 superseding v1.0, with per-finding retest status and fresh evidence of the fixed state, not a one-line email saying the issues are closed.
Against SOC 2, an external network test supports CC6.6, protection against external threats, and CC7.1, vulnerability detection. Penetration testing for SOC 2 covers what auditors do and do not accept in more detail, and how to read a VAPT report covers what to check in the document you receive.
One boundary we state everywhere and will state here: 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 we can and cannot do on an external network engagement
This page is where a buyer is most likely to assume more than we have claimed, so the boundaries are stated rather than implied.
What we can do:
- Test the internet-facing perimeter you own or are contractually authorised to test, from an unauthenticated position, and prove exploitability rather than infer it.
- Test remote access endpoints including VPN, RDP and SSH, and the mail and DNS perimeter.
- Run credential exposure checks and password spraying against internet-facing login surfaces, where you have authorised it in writing and inside agreed rate limits.
- Produce the report, control mapping and retest that a PCI DSS, SOC 2, ISO 27001 or RBI programme needs as testing evidence.
What we cannot do:
- We are not a PCI SSC Approved Scanning Vendor, so we cannot run the quarterly external vulnerability scans PCI DSS requires an ASV to perform, and this service is not an ASV scan.
- We are not a Qualified Security Assessor, so we cannot conduct your PCI DSS assessment or sign your Report on Compliance.
- 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 attestation. Who needs a CERT-In empanelled vendor explains when that requirement genuinely applies to you.
- We cannot test assets you do not own or cannot authorise. Cloud-hosted and provider-managed assets on your perimeter may carry the provider’s own testing rules, and those get resolved before the engagement rather than during it.
- An external test does not cover what happens after entry. That is the internal assumed-breach scope, and if you need both, say so at scoping so it is quoted as two scopes.
How is the scope of an external network pentest decided?
Scope inflation is the usual way an external engagement goes wrong, and the failure mode is specific: a perimeter is easier to underestimate than an application, because nobody has a complete list of it.
The scope for an external engagement is the set of public IP addresses and hostnames you name and authorise, agreed on a scoping call with both founders and written into the statement of work as addresses and names, not as a description. Additional ranges and separately managed perimeters are quoted as a custom proposal rather than compressed into a fixed tier.
Two things worth raising on that call:
- Assets you are not certain you own. Reconnaissance regularly turns up hosts that resolve to your brand but sit in a marketing agency’s account or a former vendor’s infrastructure. Those are excluded until ownership and authorisation are confirmed in writing, and they get reported to you as an observation rather than tested.
- Cloud and provider-managed assets. Your provider may have its own rules about testing infrastructure it operates. That gets settled before testing starts.
If you are still deciding which surfaces you need tested at all, how to scope your first pentest covers the general version of the decision.
What do you need from us before an external network pentest starts?
Four things, and the second one is the one that delays external engagements far more often than it delays internal ones.
- The exact public IP addresses and hostnames in scope, written as ranges and names rather than as a description of the environment.
- Written authorisation confirming you own or are contractually authorised to test every address on that list. A perimeter usually contains assets that sit with a hosting provider or a cloud vendor, and that permission chain takes longer to resolve than people expect.
- A named technical contact reachable during testing hours, who can confirm quickly whether something we are seeing is expected, and who can tell us when a defensive control has blocked us so we record it accurately rather than misread it.
- Your written position on two optional activities: password spraying against internet-facing login surfaces, and any testing that could affect availability.
Kickoff means access verified, not the statement of work signed. The 5 business days run from the point the scope is confirmed reachable and testing can begin, which protects you as much as us: nobody should be paying for testing days spent waiting on an authorisation email.
How often do you need an external network penetration test?
Annually is the floor, plus an event-driven trigger, and the event triggers carry more weight externally than internally because a perimeter changes faster than an internal estate.
PCI DSS v4.0.1 Requirement 11.4.3 asks for external 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.
Beyond the calendar, retest after any of these:
- A new public IP range, a data centre move, or a migration to a new hosting provider
- A new VPN or remote access product, or a change to how staff reach internal systems
- A firewall migration or a ruleset rewrite
- A newly exposed service, portal or administrative interface
- A merger or acquisition that brings someone else’s perimeter under your name
- The discovery of a live host nobody knew about, which usually means there are others
When to re-pentest covers the general version of this decision for application scopes.
How much does an external 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.
External and internal network testing together is two scopes, which is what the Growth plan is built for, and it is the combination that satisfies both PCI DSS Requirement 11.4.3 and Requirement 11.4.2 rather than one of them. 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. Plan your compliance calendar against the sequential number.
The size of the perimeter that fits inside one scope is agreed at scoping and written into the statement of work. A perimeter larger than one scope is quoted as a custom proposal, because we would rather tell you the estate needs a custom scope than sell you a five-day test that cannot cover it. For the wider market range on pentest pricing in India, see our pentest cost breakdown.
How we run external 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 techniques in terms your blue team already tracks.
The deliverable is a technical report with reproduction steps per finding, an external attack surface inventory of what is reachable from the internet, an executive summary for non-technical stakeholders, CVSS v3.1 severity scoring, perimeter and DMZ boundary results, and one free retest within one month of the v1.0 report delivered as a v2.0 report.
If your requirement is both sides of the perimeter, say so on the scoping call. External first, then internal assumed breach, as one engagement with one report structure, is the sequence we have run and the one we recommend.
External network pentest service | Internal network pentest service | See a sample report | View pricing | Book a 30-minute scoping call
Corrections
- 2026-09-04: Added the entity class to the quoted RBI paragraph numbers. 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.