Key takeaways
- An infrastructure pentest is not a vulnerability scan: a scanner lists known flaws, a tester chains a weak service, a reused password and a flat network into real access.
- The first decision is external, internal or both. External answers what the internet can reach; internal answers what someone already inside can reach next.
- Price tracks live hosts, the depth of testing and whether identity systems like Active Directory are in scope, not the raw size of your address space.
- Giving the tester credentials and a starting foothold buys more findings per day than making them earn the perimeter first.
- Leave marginal scope out of the first engagement rather than spreading a fixed budget too thin to test anything properly.
What an infrastructure pentest actually buys
An infrastructure penetration test looks at the network layer that sits under your applications: the hosts, the services they expose, the accounts that log into them and the trust between them. That is a different question from application testing, which stays inside one system, and a different question again from a vulnerability scan. A scanner enumerates versions and matches them to known flaws. A tester takes a weak service, a password reused from another box and a network with no internal segmentation, and turns them into access that no single scanner finding would predict. The chaining is the value, and it is why penetration testing is manual work and priced as such.
The engagement has two halves, and they answer different questions. The external half asks what an attacker reaches from the internet with no help from you. The internal half asks what someone who already has a foothold can reach from there: a phished laptop, a rogue contractor, a device on the guest network. Our article on LLMNR poisoning to an SMB relay walks through one internal chain of exactly that kind. What you are buying is the choice between those two halves, and how far each one is allowed to go.
External, internal, or both
An external infrastructure test starts where a real attacker starts, at your public address ranges, and works only with what the internet exposes: the mail gateway, the VPN concentrator, the marketing site, a forgotten staging box someone left listening. It answers the question a board asks: can somebody reach us from outside, and how far in does that first reach take them? It is usually the smaller of the two engagements, because the perimeter is smaller than the network behind it.
An internal test starts from a foothold on the network, which is the position most breaches reach before they do damage. Rather than spend days re-earning that foothold from outside, most buyers grant it: a standard user account, a laptop on the corporate segment, or a fuller assumed breach start. From there the tester goes after identity, shared services and the flat trust that lets one machine talk to another it never needed to. If you only buy one half, buy the one that matches the worry you have, and read the scope of an infrastructure penetration test as two products that happen to share a method.
Two choices set the four ways an infrastructure test can be scoped: where the tester starts, and whether you hand them an account.
Where the test starts
Internal, unauthenticated
A foothold with no account. Tests what a rogue device on the network reaches.
Internal, credentialed
A standard user account. The most findings per tester day.
External, black box
The real attacker view of your perimeter.
External, authenticated
Logins given for exposed portals and the VPN.
Access granted
What sets the scope, and the price
Three things move the price of an infrastructure test, and the size of your address space is not one of them. The first is the count of live, responding hosts. An unused range costs a scan, while a live host costs attention, so ten thousand addresses with two hundred live hosts is a two-hundred-host job. The second is depth: a broad, mostly automated pass across a large estate is a different quote from manual exploitation and post-exploitation on a focused set of targets. Say which you want. A proposal priced for one and delivered as the other is how buyers end up feeling short-changed.
The third is whether identity is in scope. An internal network with Active Directory behaves as one trust system rather than a set of hosts. Testing that system, its delegation, its service accounts and its paths to domain admin, is where an internal test earns its keep. Segmentation testing is a separate axis again. Proving that the card-holder network cannot reach the corporate one is a specific objective with a specific effort attached. Standards such as the NIST SP 800-115 technical testing guide describe the method, but they do not price it. Your scope does.
Count live hosts
Responding hosts, not the size of the range
Pick external or internal
Where the tester is allowed to start
Decide on credentials
None, a user account, or a full foothold
Name the objective
Domain admin, segmentation, or a data store
Breadth, depth, and what a scan cannot buy you
Much of an infrastructure test's value sits in the gap between what an automated scan delivers and what it does not. A credentialed vulnerability scan is fast, cheap and repeatable, and you should run one regardless. It will not tell you that three low findings combine into domain compromise, and it will not distinguish a critical it can reach from a critical behind a firewall it cannot. That judgement is the manual work you are paying a tester for.
The table below sets the two apart on the points buyers decide on. Neither replaces the other. Run scanning continuously and buy testing periodically. Then use the test to check whether your scanning and monitoring saw any of it, which is the question a red team engagement asks at a larger scale.
| Dimension | Credentialed scan | Infrastructure pentest |
|---|---|---|
| Cadence | Continuous, automated | Periodic, manual |
| Chains findings | No | Yes, the main point |
| Confirms exploitability | Rarely | Every reported finding |
| Cost | Low, per scan | Higher, per engagement |
What to leave out of the first engagement
A fixed budget spread across everything tests nothing to a useful depth. It is better to name a smaller scope and test it properly than to buy a shallow sweep of the whole estate. Leave the marginal ranges out. Leave out the systems hosted by third parties that you cannot authorise, and get that authorisation before the next engagement rather than skipping the test. If cloud infrastructure is a large part of your estate, treat it as its own scope with its own method, not a footnote on a network test.
Say what you want to learn, and let that set the scope rather than the other way around. If the worry is a phished laptop reaching the crown jewels, buy the credentialed internal test and skip the external one this round. If you want to know whether your defenders would notice any of it, that is purple teaming or a red team, not a louder infrastructure test. Scoping down is how you buy an answer you can act on. Saving money is beside the point.
Buying an infrastructure test under UAE rules
In the UAE, the reason to buy an infrastructure test is often written into a rule you already answer to. Banks and finance firms sit under the Central Bank of the UAE, whose information security requirements expect regular technical testing of the systems that hold customer data. See the Central Bank of the UAE for the current framework. Federally, the UAE Information Assurance Regulation published through the TDRA sets baseline controls that assume testing of internal and external infrastructure, and it applies well beyond the capital. The UAE Information Assurance Regulation is the document to read against your own estate.
The two emirates differ in who asks and how. In Dubai, government entities and the suppliers who connect to them answer to the Dubai Electronic Security Center, whose DESC standards flow down through procurement. A vendor to a Dubai authority may be asked to show a recent infrastructure test as a condition of the contract. In Abu Dhabi, healthcare providers fall under ADHICS, which names penetration testing among its controls. A firm licensed in a Dubai free zone and selling into both emirates should scope the test to satisfy the strictest regulator it touches, not the nearest one. Keep the report and its retest record, since that is the evidence an examiner in either emirate will ask to see.
Frequently asked questions
What is an infrastructure penetration test?
It is a manual security test of the network layer under your applications: the hosts, the services they run, the accounts that log into them and the trust between them. A tester chains weaknesses that a scanner reports only in isolation, showing how a small flaw becomes real access. It covers the external perimeter, the internal network, or both.
How does an external infrastructure pentest differ from an internal one?
An external test starts at your public addresses and works only with what the internet exposes, answering whether an attacker can get in from outside. An internal test starts from a foothold on the network and measures how far someone already inside can reach. Most damage in real breaches happens after that first foothold, which is why many buyers prioritise the internal test.
How is an infrastructure pentest priced?
Price tracks the number of live, responding hosts, the depth of testing you want, and whether identity systems like Active Directory are in scope. The raw size of your address space matters little, since unused addresses cost only a scan. A broad automated pass and focused manual exploitation are different quotes, so state which you are buying.
Do I need to give the testers credentials?
For an internal test, granting a standard user account or a starting foothold usually buys more findings per day than making the tester earn the perimeter first. It reflects the position most attackers reach anyway. For an external test you can stay black box, or provide logins for exposed portals and the VPN if you want those covered.
Is an infrastructure pentest the same as a vulnerability scan?
No. A scan lists known flaws by matching software versions against a database, and you should run one continuously. A pentest confirms which flaws are truly reachable and chains several into access a scan would never connect. Run scanning for coverage and buy testing for judgement.
How many addresses can be tested, and does the count set the price?
The count that matters is live, responding hosts, not the size of the range. A large block with few active hosts is a small job. Give the tester your ranges and let them confirm what is live during scoping so the quote reflects reality.
Will the test disrupt production?
A well run infrastructure test avoids denial of service and destructive actions by default, and any intrusive step is agreed in advance. You set the testing window and the rules of engagement before it starts. Tell the tester which systems are fragile so they can handle them with care or leave them out.
How often should we run one?
At least annually, and again after a material change to the network such as a new site, a merger, or a move to new infrastructure. Continuous scanning fills the gaps between tests. Regulated entities in the UAE often have a testing cadence set for them by their sector rules.
