The IT director receives a question from procurement that sounds harmless: “how many IP addresses do we put in the request for proposal for the pentest?”. The answer seems simple — just open the spreadsheet with the public addresses. The trouble is that the spreadsheet was created three years ago, before the mail migration to the cloud, before two marketing projects bought their own domains, and before the production department connected a remote access panel to its controllers. The spreadsheet is not lying. It is merely older than reality.
This text is not a comparison of the external and the internal perspective — that is a separate topic, covered in our article on external and internal infrastructure penetration testing. What interests us here is one path from beginning to end: what to do before the test so that it means something; what happens during it; and what to do with the result afterwards so that the report does not end up in a drawer. The reference point for the flow is NIST SP 800-115, because that is the document most serious offers on the market cite — so it is worth knowing what it actually says.
What is external infrastructure penetration testing, and what is it not?
External infrastructure penetration testing is a controlled attempt to get into an organisation from the perspective of someone who has access only to the internet and has received no credentials from you. What gets tested is what can be seen from outside: public IP addresses, web services, VPN gateways, mail servers, admin panels, API interfaces, cloud resources attached to your domains.
The single most important distinction in the whole subject concerns the difference between a scan and a test. NIST SP 800-115 puts it 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” (NIST SP 800-115, Technical Guide to Information Security Testing and Assessment, Karen Scarfone et al., September 2008, section 5.2.1). A scanner produces a list of hypotheses. A penetration test checks which of them are true, and shows where they lead.
That difference has a procurement consequence that is easy to forget when comparing offers. A service that ends with an exported scanner report is a scanning service — regardless of what it was called in the contract. A service that includes an attack phase costs more, takes longer, and requires you to sign rules of engagement, because someone will genuinely be trying to get into your infrastructure.
What is a test not? It is not a compliance audit — it does not answer the question of whether you meet the requirements of Directive (EU) 2022/2555 (NIS2) or Regulation (EU) 2022/2554 (DORA). It can supply the technical evidence those regimes rely on — DORA covers testing in Chapter IV (Articles 24–27), and advanced TLPT testing in Articles 26–27 — but on its own it is not a compliance assessment. Nor is it red teaming: a red team has an objective and avoids detection, while an external pentest has a scope and aims for coverage.
Summary box — three sentences worth remembering from this section
- A scan says “there is probably a hole here”; a test says “I went in this way, and here is what I saw”.
- What is being tested is a point of view, not a technology — external means “no credentials, from the internet”.
- Regulatory compliance makes use of the test result, but it is not the subject of the test.
Why does the list of externally exposed assets always turn out longer than assumed?
Because it is created somewhere other than where the exposure is created. The spreadsheet of public addresses is maintained by the network team, while new entry points are added by marketing, by the product department, by a project team and by an external integrator — each of them legitimately, within their own process, without an entry in the spreadsheet. The discrepancy does not come from negligence; it comes from the fact that an inventory is a document while an external surface is a state.
Three mechanisms account for most of the difference in mid-sized organisations. The first is subdomains pointing at resources that no longer exist — the DNS record outlived the service it pointed to. The OWASP Web Security Testing Guide has a dedicated test scenario for this case, 4.2.10 Test for Subdomain Takeover (WSTG v4.2, released 3 December 2020). The second is admin panels exposed “temporarily” — WSTG describes hunting for them in scenario 4.2.5 Enumerate Infrastructure and Application Admin Interfaces. The third is cloud resources attached to a corporate domain outside the IT process, that is, scenario 4.2.11 Test Cloud Storage.
What all three have in common is that nobody deliberately hid them. They came into being as the solution to a specific problem, they worked, and then they stopped being anyone’s property. An attacker does not have to guess at them — searching public registries and certificates is enough.
The practical consequence is inconvenient for the procurement process: the scope of the test cannot be only what you wrote into the request for proposal, because then the test will merely confirm your own picture of the infrastructure. A well-constructed order contains a separately priced surface discovery phase, after which the scope is closed jointly — and only then signed.
How do you inventory the external surface before the test?
You start the inventory with data that is public anyway, and you finish it by agreeing ownership of every asset found. The order matters: first collect, then assign an owner, and only at the end decide what enters the scope.
NIST SP 800-115 lists specific sources for the discovery phase: DNS interrogation, WHOIS queries, employee information gathered from the organisation’s web and directory servers, and banner grabbing to establish version numbers (section 5.2.1). To these add certificate transparency logs, which in practice expose subdomains more effectively than any wordlist, plus the address ranges assigned to your autonomous system numbers and to the cloud providers you use.
The output of this step should not be a list of addresses. It should be a table in which every row has four columns: the asset, how it was found, the business owner, and the scope decision. The “how it was found” column is the one most often skipped, and it is the one that later lets you repeat the inventory and compare the result — without it, the next discovery starts from zero.
Here is a fragment of such a table in a shape you can hand to a supplier without explanation. The rows are deliberately chosen to show four different outcomes:
| Asset | How it was found | Business owner | Scope decision |
|---|---|---|---|
| VPN gateway, public address from our own range | network inventory, confirmed by a port scan | infrastructure team | in scope, full test |
| Campaign subdomain from two years ago | certificate transparency log | marketing department | in scope, candidate for decommissioning before the test |
| SaaS HR portal under a corporate subdomain | DNS CNAME record | HR department, infrastructure at the provider | out of scope without the provider’s consent, recorded in the report |
| Remote access panel for production controllers | service scan on a non-standard port | no owner established | decision held, escalation before the test starts |
The fourth row is the most important in this set and the most frequently encountered. An asset that nobody submitted for scope and whose owner cannot be established within a day should not enter the test automatically — but it should not disappear from the document either. The right response is escalation with a deadline: either an owner and a decision appear before the test begins, or the asset is cut off from the internet for the duration of the test and returns to the conversation afterwards.
Record separately the assets whose owner you could not establish. In practice that is the most valuable part of the result. An asset with no owner has nobody to approve its patching, nobody to notice its failure, and nobody to report its compromise. If the inventory produced not a single such entry, in most cases that means the discovery was too shallow, not that the housekeeping is exemplary.
Summary box — the minimum set of inputs to an inventory
- domains and subdomains (certificate transparency logs, historical DNS records),
- address ranges, your own and those at cloud providers,
- services and their versions (service banner, response headers),
- accounts and identities visible from outside (self-service portals, directories),
- assets inherited together with an entity you acquired or merged with.
What belongs in the scope, and what deliberately falls outside it?
The scope should cover everything an attacker would regard as yours, and what should fall outside it is whatever you are not legally or contractually permitted to test. That single sentence settles most scope disputes, but it has two places where it hurts in practice.
The first is assets held at third-party providers. The SaaS HR portal is visible under your subdomain, users log in to it with a corporate account, and from an attacker’s perspective it is your surface. The contract with the provider, however, usually forbids testing their infrastructure without consent. The solution is not to pretend the problem does not exist, but either a three-way scope agreement or an explicit statement in the report: the asset belongs to the surface, it was not tested, here is why.
The second is dependencies that only surface mid-engagement. The tester establishes that your VPN gateway authenticates users against a directory maintained by an integrator who is not in scope. The rules of engagement must anticipate that situation in advance: who takes the decision to extend, within what time, and in what form. Without that clause the test either stops at the boundary or crosses it — and both are bad.
It is also worth writing out explicitly what the test does not cover, even where it seems obvious. Social engineering against employees, denial-of-service testing, physical entry to the building and attempts against production control systems are four areas that have to be named, because their default treatment differs between suppliers. The buyer usually assumes they fall outside the scope; some methodologies assume the opposite.
How do you set rules of engagement so the test does not stop production?
Rules of engagement are the document that turns the business’s consent into an operational instruction. NIST SP 800-115 places them in the planning phase and states the purpose without ornament: „In the planning phase, rules are identified, management approval is finalized and documented, and testing goals are set (…) No actual testing occurs in this phase” (section 5.2.1). The clause about no testing occurring in this phase matters more than it looks — it marks the moment before which no packet has any business heading towards your infrastructure.
Good rules of engagement answer six questions. Who knows about the test, and who must not know? In what time windows are load-bearing activities permitted? Which actions are prohibited unconditionally — modifying production data, exfiltrating real personal data, making persistent configuration changes? By what route and within what time does the tester report a critical finding before the test ends? Who on the client side has the right to halt activity with a single phone call? What does the exit procedure look like — removal of tools, test accounts and artefacts.
This set is not a market invention. NIST SP 800-115 formulates five questions in section 6.5 that an assessment plan must answer: its scope, the party holding authorisation to run it, its logistics, the handling of sensitive data, and the response owed when an incident occurs. The last question is the one that appears least often in contracts and settles the most — because an incident during a test happens more often than intuition suggests, and it is usually not the tester’s doing.
Two provisions from the same section deserve to be carried into practice verbatim. The first is an exclusion list given by name and address. NIST recommends that the plan name specific systems that must not be examined — at minimum by IP address, and preferably by system name as well. The phrase “we exclude critical systems” is not an exclusion list; it is an invitation to argue about what counts as critical, conducted after the incident. The second is written consent from the owner of someone else’s network: if part of your systems sits at a provider, the owner of that network usually has to approve the assessment plan in writing. For external infrastructure this is not an edge case but the rule — most organisations today have at least one significant asset outside their own network.
NIST also recommends describing in the plan not only what is allowed, but the level of detail of the permitted activities: if password cracking is in scope, the plan should state where the tester will obtain the material to crack. Prohibited activities should be listed precisely enough that no second reading of them is possible — the document gives file creation and modification as its example. That is the same level of precision a good service contract demands, and for the same reason.
The question of who does not know about the test deserves particular attention. If the monitoring team was not informed, the test result also includes a picture of your detection — and that is value you cannot buy separately. If they were informed, the test runs more calmly but loses that dimension. Both decisions are valid; only the one taken by accident is wrong.
The question of sensitive data is tied to an element often treated as a formality, yet it is the only mechanism that settles disputes: the tester’s activity log. NIST describes it in section 7.4.1 and gives the minimum set of fields — date and time, the tester’s name, the identifier of the system the activity was run from, the identifier of the target system, the tool used, the command executed and a comment. The justification is purely practical: the log lets the organisation distinguish the tester’s actions from those of a real adversary, and it protects the tester from being blamed for an outage they did not cause. If a service goes down during a test, the question “was that the tester?” will arrive within minutes — and either the log answers it, or an investigation begins.
The last obligation concerns what happens to the data after the test. The material gathered along the way — network architecture, security configurations, the list of confirmed vulnerabilities — is more valuable to an attacker than the report itself. NIST assigns responsibility for storing it securely to the assessor and states the consequence of improper release outright: damage to the organisation’s reputation and an increased likelihood of exploitation. The rules of engagement should therefore contain a deadline and a method for destroying the working material — and a statement of what the supplier may retain, and for how long.
The element that most often falls out of the document, and should be in it: the date and scope of the retest. Settled at the rules-of-engagement stage, it costs one line. Settled after the report has been accepted, it requires a new procurement route, a new budget and usually slips by a quarter.
What does the test flow look like under NIST SP 800-115?
NIST divides a penetration test into four phases and shows them in Figure 5-1: planning, discovery, attack and reporting (section 5.2.1 of the September 2008 document). The layout of that figure carries two pieces of information that are easy to miss on a quick reading.
The first: reporting is not the final stage but runs in parallel with the other three. NIST says so explicitly — „The reporting phase occurs simultaneously with the other three phases of the penetration test”. The assessment plan, that is the rules of engagement themselves, is produced in the planning phase; written logs are kept and periodic reports made during discovery and attack; the final report is a summary, not the only deliverable.
The second: there is a feedback loop between attack and discovery. Every successful exploitation of a vulnerability opens a new area that has to be explored afresh. The document describes this as „additional discovery” and devotes a separate Figure 5-2 to it. The practical consequence for scheduling is that the duration of a test cannot be derived from the number of IP addresses — the first successful entry may double the area to be examined.
The discovery phase itself has two parts according to NIST. The first is information gathering and scanning, including the identification of ports and services, which the document covers in section 4.2. The second is vulnerability analysis: comparing the discovered services, applications and operating systems against vulnerability databases — automatically by a scanner, or manually, against public databases — the National Vulnerability Database among them. NIST notes that the manual process catches new or obscure vulnerabilities that a scanner may not have in its database, but is much slower.
One more pointer from section 5.2.2 is worth recording, because it matters when planning a larger testing programme: „If both internal and external testing is to be performed, the external testing usually occurs first”. The order is not accidental — an external test establishes a realistic starting point for an internal one.
What happens in the attack phase, and why does the loop go back to discovery?
In the attack phase the tester verifies previously identified vulnerabilities by attempting to exploit them. NIST describes the moment without drama: a successful exploit does not necessarily grant maximum access straight away — often it merely yields more knowledge about the network, or changes the state of its security. If it allows privilege escalation, further analysis is needed to establish the true level of risk: what information can be read, changed or removed.
The document lists the vulnerability categories most often exploited in penetration tests: misconfigurations (with insecure default settings singled out), kernel flaws, buffer overflows, insufficient input validation, symbolic links, file descriptor attacks, race conditions, and incorrect file and directory permissions. The first item on that list is the most productive one on an external surface — and simultaneously the cheapest to fix.
The feedback loop is what distinguishes a test from a series of independent attempts. A tester who has gained access to a single server does not stop there — from that position they explore further resources that were not visible from the internet. NIST states this outright, recommending that testing and analysis be conducted across multiple systems to establish the level of access an adversary could obtain.
For an external surface it is worth pausing on that first item, misconfigurations with their highlighted default settings. A service exposed to the outside is rarely vulnerable because the vendor made an error in the code — far more often because it was launched in an example configuration and never left it. An admin panel reachable from any address, a management interface on an alternative port with no source restriction, a service account with the password from the deployment documentation. Fixing findings of this kind requires neither a maintenance window nor the vendor’s consent, so they should sit ahead of patches that require a service restart in the remediation queue.
From the buyer’s perspective this has one consequence worth writing into the contract: the number of test days is an assumption, not a guarantee of coverage. An honest offer states what happens if the discovery loop turns out deeper than assumed — whether the scope is narrowed or the budget extended, and who takes that decision.
How do you read the report: what does a finding mapped to MITRE ATT&CK mean?
Mapping a finding to ATT&CK means assigning it a place in a catalogue of techniques that real adversaries use in real campaigns — and with that, the finding stops being an abstract vulnerability number and becomes a named path in. It is the simplest way to summarise a technical report for the board without losing precision.
Two tactics matter for an external surface. Reconnaissance (identifier TA0043 in the Enterprise matrix, 12 techniques, catalogue state of 25 April 2025) covers the activity that precedes entry: active scanning (T1595), gathering information about the victim’s infrastructure, about its identities and about its personnel. Initial Access (TA0001, 11 techniques, same catalogue state) covers the entry itself, and its techniques read like the table of contents of a typical external test report: exploiting a public-facing application (T1190), external remote services (T1133), valid accounts (T1078) and a trusted relationship with a third party (T1199).
The last of these deserves attention here, because it falls out of scope most often. If an integrator holds standing access to your network, then your external surface includes theirs too — and a report that fails to record this describes less than half the picture.
Mapping has one further use that turns out to be more valuable in practice than the report itself: it lets you turn a list of findings into a single sentence about the path. Instead of “seven high-priority vulnerabilities were found”, the board gets: “discovery revealed a forgotten subdomain, through it a public-facing application was exploited (T1190), and the credentials obtained (T1078) opened access to a system that was not in the inventory”. A sentence like that can be remembered, quoted at a board meeting and translated into a budget decision — a list of vulnerabilities delivers none of those three things.
When reading the report it is worth separating two classes of finding that tend to get mixed together. The first is findings confirmed by entry — the tester actually got in and documented the reproduction steps. The second is findings identified but unverified — the vulnerability was recognised during discovery, and exploiting it was either out of scope or too risky for production. Both classes are valuable, but only the first proves anything about the actual state. A report that does not separate them makes it harder for the operations team to set an order — and a team that cannot set one will start with the easiest item, not the most important.
What does mapping not give you? It does not give priority. Technique T1190 describes a way in, not how urgently a particular instance of a particular application needs patching. Priority arises from other inputs, and that is the subject of the next section.
Why is CVSS not enough to set the fix order?
Because CVSS describes the properties of a vulnerability, while a remediation queue needs an answer to the question of what is actually happening. A highly scored vulnerability nobody is exploiting and a medium-scored vulnerability being exploited right now sit in the opposite order in a CVSS ranking than they do in reality.
The first corrective is the CISA KEV catalog. An entry requires three criteria to be met at once: the vulnerability has an assigned CVE identifier, there is reliable evidence of its active exploitation in the wild, and there is a clear remediation action — for example a vendor-supplied update. CISA also stresses what active exploitation is not: scanning, security research on an exploit, and publicly available Proof-of-Concept code. Public availability of a PoC is not a condition of entry into the catalog and does not on its own prove that anyone has exploited the vulnerability. These criteria, originally introduced by directive BOD 22-01, were carried forward into directive BOD 26-04 Prioritizing Security Updates Based on Risk, of 10 June 2026.
The second corrective is EPSS, published by FIRST. It is a data-driven model estimating the probability that exploitation activity will be observed for a given vulnerability within the next 30 days. The result is a number from 0 to 1, updated daily. Alongside the probability FIRST publishes a percentile, that is the vulnerability’s position relative to all scored ones — and explains why both numbers are needed: the distribution of scores is heavily skewed towards zero, so the 95th percentile currently begins at a probability of roughly 0.10 (10%), against a base rate of exploitation on the order of 2–3%.
The most important caveat, however, comes from FIRST itself and reads as follows: „EPSS is not a complete risk score. EPSS does not measure how much damage successful exploitation would cause, or whether it affects your environment”. In other words, EPSS knows nothing about your environment, about compensating controls, or about what a given service means to you. That context has to be supplied by the buyer — and that is precisely the part of the work you cannot purchase along with the report.
How do you combine exposure, KEV and EPSS into a single remediation queue?
Through an explicit decision matrix agreed before the report is accepted, not after. The table below is a working tool: you pick the row by the state of the finding, and the “action” column is what enters the task tracker. Three inputs — a confirmed entry from the test, presence in the KEV catalog and the EPSS value — are enough to order a typical external test report without negotiating each item separately.
| State of the finding | External signal | Priority | Action and deadline |
|---|---|---|---|
| Entry into the environment confirmed in the attack phase | any | P0 | Fix outside the normal release cycle; emergency window; narrow retest after the fix |
| Vulnerability on a publicly exposed asset, present in the KEV catalog | KEV: yes | P1 | Vendor patch or removal of the service from the internet; the deadline from directive BOD 26-04 as a reference point |
| Vulnerability on a public asset, high EPSS, outside KEV | EPSS ≥ 0.10 | P1 | Next planned maintenance window; monitor the EPSS value until fixed |
| Vulnerability on a public asset, low EPSS, no KEV entry | EPSS < 0.10 | P2 | Normal patching cycle; decision revisited if the asset enters KEV |
| Asset with no established owner | — | P1 | Assign an owner or decommission the asset; remediation cannot be planned without a recipient |
| Asset in the surface, excluded from the test scope | — | P2 | Three-way agreement with the provider, or a conscious acceptance of risk with a review date |
Two rows of this table need a comment, because they have no counterpart in a typical report. The “asset with no established owner” row does not describe a vulnerability — it describes the absence of anyone to remediate it, which is why it lands high. The final row guards against the most common way of losing sight of risk: an asset excluded from scope disappears from the report and with it from the organisation’s memory.
The 0.10 threshold in the “external signal” column is not a universal value — it is a starting point worth calibrating against your own capacity to deploy fixes. If your operations team closes a dozen or so items a month, a threshold set too low will produce a queue nobody will work through, and an unworked queue is worse than no queue, because it creates the illusion of being in control.
What should happen after the test, and when should you order a retest?
Three things should happen after the test, in this order: every finding assigned to an owner with a deadline, remediation up to the agreed priority threshold, and only then a retest. Reversing that order — ordering a retest on a date fixed in advance, regardless of remediation progress — produces a second report that largely repeats the first.
The retest should be narrow. It checks two things: whether the remediated finding has genuinely gone, and whether the fix opened a new path. The second point tends to be skipped, and it is real — disabling an old protocol is sometimes compensated by enabling a workaround, and a workaround rarely passes through the same security review as the target solution.
The greatest loss of value across the whole cycle happens not in the retest, though, but between accepting the report and the first fix. We have described that mechanism separately in our text on the remediation gap, so one practical remark suffices here: if the findings from the report did not land in the same task tracker where the operations team runs its daily work, they will not be fixed — regardless of how good the report is and how serious the supplier.
As for the frequency of further tests: the calendar is the weakest possible trigger. An architecture change, exposing a new service externally, acquiring another entity and a significant change in the operations team all alter the surface more than the passage of twelve months. That thread is developed further in our article on triggers instead of a calendar.
Summary box — the definition of completed remediation worth writing into the rules of engagement
A finding is closed when: (1) the cause has been removed, not masked; (2) the change is persisted in the reference configuration, so it survives rebuilding the asset; (3) the owner has confirmed it in writing; (4) a retest has confirmed the absence of the finding and of any new path. Missing any of these points means the finding is being remediated — not that it has been remediated.
How do you judge whether an offer for an external pentest is serious?
By what the offer says about the uncomfortable things. Declaring conformity with a methodology is cheap — listing the names NIST, OWASP and PTES is enough. A serious offer is recognisable by the fact that it settles the situations in which something goes differently than assumed.
Five questions that in practice differentiate offers the most:
- Is the surface discovery phase priced separately, and is the scope closed after it? An offer that accepts your list of addresses without reservation is selling you confirmation of your own picture of the infrastructure.
- What happens when the tester finds an asset outside the scope that is evidently yours? The answer should name a decision-maker and a response time, not a general willingness to talk.
- What is the route for reporting a critical finding mid-test? If the only deliverable is a final report, a critical finding from day one waits for you until the engagement ends.
- Does the report include reproduction evidence — and if so, in what form? A finding without reproduction steps is an opinion to the operations team, not a task.
- Is a retest included, and on what terms? The answer “to be agreed” means in practice a separate procurement process several months later.
Finally, a matter that fits into none of the questions above and yet decides the value of the whole undertaking. An external test is bought in order to learn something you did not know — which means a good result is sometimes inconvenient. If an organisation enters a test assuming the report is meant to confirm a good state of cybersecurity, it will get a report confirming a good state, because the scope will be chosen accordingly. The money will be spent, the risk will stay where it was.
If you want to go through this cycle with a team that closes the scope after discovery rather than before it, take a look at our external IT infrastructure penetration testing service — it describes the flow, the deliverables and the retest terms.
