What a senior team actually does between the kick-off call and the retest report, on the only part of your estate that anybody on the internet can reach without asking you first.
An external network penetration test answers one question: what could somebody with no account, no credentials and no help from inside your organisation do to you from the public internet today?
The scope is whatever responds on a routable address you own: perimeter firewalls and VPN concentrators, mail and DNS, the customer portal, the staging box that was meant to be temporary, the appliance a supplier asked for years ago. That set is your external attack surface, and it is usually larger than the inventory says.
The numbers have moved towards the perimeter. Verizon’s 2026 Data Breach Investigations Report puts 31% of breaches at the exploitation of a vulnerability, ahead of stolen credentials. ENISA, across 4,875 incidents recorded in the EU between 1 July 2024 and 30 June 2025, puts exploitation at 21.3% of initial access and notes that 64% of documented vulnerabilities use the network as their attack vector.
No packet leaves our side before the paperwork does. NIST SP 800-115 is blunt: in the planning phase “rules are identified, management approval is finalized and documented, and testing goals are set”, and “no actual testing occurs”. Agreed in writing first:
That document is the rules of engagement; NIST publishes a template in Appendix B. A supplier who cannot show you theirs before kick-off is telling you how the rest will run.
Reconnaissance is the phase clients underestimate and attackers never do. Its output is not a vulnerability list. It is an inventory: every name, address, certificate, service and third-party dependency that belongs to you and answers from outside.
Passive sources come first, because they touch nothing of yours: certificate transparency logs, passive DNS, WHOIS and netblock ownership, breach corpora for credentials tied to your domains. That work is OSINT, and NIST describes the external scenario the same way, with testers given no real information beyond the target ranges.
Active work follows: DNS enumeration, port and service identification, TLS inspection, virtual host discovery, fingerprinting. NIST notes that an external scan passes through your firewall and returns far less than the same scan run inside. What survives is what an attacker sees today.
The finding this phase produces most often is not a CVE. It is a host nobody remembers owning: shadow IT, an environment decommissioned in theory only, a subdomain pointing at a cloud resource an agency stopped paying for.
VPN concentrators, SSL gateways, file transfer appliances, firewalls with a management interface facing the wrong way. ENISA matched its incident data against MITRE ATT&CK and confirmed that attackers consistently exploit internet-facing applications (T1190); the vulnerabilities dominating its set are VPN appliances, mail and collaboration servers, with perimeter services “scanned and compromised within hours of disclosure”. Versions go against the CISA KEV catalogue, 1,655 entries on 27 July 2026, where an entry means exploitation observed rather than predicted.
A dangling CNAME pointing at a deprovisioned cloud resource allows a subdomain takeover: somebody registers the abandoned resource and serves their content from your name. Zone transfers, SPF, DKIM and DMARC alignment and registrar hygiene go in the same pass, since a domain an attacker can spoof is a weakness even when no host is vulnerable.
Anything speaking HTTP is tested against the OWASP Web Security Testing Guide, stable at version 4.2, whose cases carry public identifiers such as WSTG-INFO-02, so a finding maps to a published procedure, not to our opinion. Security Misconfiguration is A02 in the OWASP Top 10:2025, and on a perimeter that is what turns up: default credentials, exposed admin panels, verbose errors, debug endpoints.
Login forms and SSO endpoints are tested for username enumeration, absent lockout and rate limiting, and weak multi-factor enforcement. Where the rules allow it, low and slow password spraying runs against the credentials reconnaissance produced, at a rate that does not lock out your staff.
NIST puts the value of this phase in one sentence: “While vulnerability scanners check only for the possible existence of a vulnerability, the attack phase of a penetration test exploits the vulnerability to confirm its existence.”
A successful exploit is not the objective. Verified impact is. Each attempt records what was sent, what came back, and what an attacker would now hold: read access to a file, a session as another user, code execution, a credential that also works elsewhere.
Two rules keep the phase safe. Proof and nothing beyond it: no denial of service, no bulk extraction of personal data, the smallest demonstration that settles the question. And the loop back to discovery, which NIST draws explicitly, because what a foothold teaches you changes what you look for next.
Chained findings are where this test earns its budget line: two low-severity issues, unremarkable alone and serious together: a banner that names an internal host, and a forgotten service on that host which answers without asking who is calling.
NIST places reporting alongside the other three phases rather than after them. Logs run throughout, and anything critical is raised the day it is confirmed. What is delivered:
A CVSS base score says how bad a vulnerability could be, not how likely it is to be used against you. Three inputs work together: CVSS for severity, EPSS from FIRST for probability of exploitation in the wild, and exposure, because the same defect on an internet-facing host outranks the same defect behind three other controls. The public sector uses the same logic: CISA’s Binding Operational Directive 26-04, issued in June 2026 to supersede BOD 22-01, sets deadlines from four variables and asks first whether the asset is publicly exposed.
A finding is not closed because a ticket says it is. The retest turns a report into evidence, and it is the phase cheap engagements quietly leave out.
The original proof is rerun against the fixed asset and one of three outcomes recorded: resolved, partially resolved, or not resolved with the evidence still reproducing. Partial is the interesting one. It usually means a payload was blocked and the weakness left in place, which is the difference between a filter and a fix.
Retesting happens after your remediation window; on our engagements that is commonly four to eight weeks after delivery, and it produces an updated report with each closed finding marked and dated. That document, not the original, is what auditors and enterprise customers ask to see.
Nothing on that list is a credential or an architecture diagram. That is the point: the test starts from what a stranger can find out unaided.
Ranges, because the honest answer depends on a count nobody has until reconnaissance finishes. On our engagements, a small perimeter of a few dozen live hosts and a handful of web surfaces takes about a working week of testing. Several hundred addresses and a dozen applications is usually two to three weeks. A group with multiple brands, acquired subsidiaries and several cloud tenants runs longer.
What moves it: the size of the live surface, unknown until reconnaissance ends; how many distinct web applications sit on the perimeter, since each is an effort of its own; whether protective infrastructure stays in place; third-party approvals, which are calendar time; and whether the test is announced. Add about a week afterwards for reporting and quality review, and book the retest separately.
This is the section that should decide whether you buy this test or a different one, and the one most proposals omit.
And the limit on every penetration test, stated by NIST better than we would: “Testing does not provide a comprehensive evaluation of the security posture of an organization, and often has a narrow scope because of resource limitations”. An assessment is a snapshot; your perimeter changes on the next deployment. Test on a cycle.
If this is the answer you need, the service that produces it is external network penetration testing, and the sequence behind every engagement we run is set out in our pentesting methodology, end to end.
Every figure, quotation and framework reference above comes from one of these documents. The durations, the retest window and the deliverables are our own practice and are stated as such in the text.
The sequence of a real internal network penetration test: the starting point we agree, what a domain account becomes, what you get at the end, how long it takes and what the exercise deliberately does not cover.
The real sequence of a wireless penetration test, from the rules of engagement to the retest: what happens at each phase, what you need ready, how long it takes, and what this test deliberately does not cover.
The seven phases of an Asperis engagement, from scope and rules of engagement through to the retest, with the standard behind each one, the duration ranges we scope to, and a plain list of what a penetration test does not cover.
If any of this looks like a problem you are carrying, half an hour on a call scoping it with a senior pentester is worth more than reading another article.
Hablar con un pentester seniorPick a time that suits you. You tell us what you need and where you are, and we explain how we work and how we can help.
