Network penetration testing is a controlled attack against your network infrastructure, carried out by security engineers who try to break in the way a real attacker would. We map your environment, find weaknesses in systems, services, and configurations, exploit the ones that matter, and show you exactly how far an intruder could get. The point is not to produce a list of theoretical flaws. The point is to prove what an attacker can actually do inside your network, and to give you a clear, ranked path to fixing it before someone hostile finds the same gaps.
For regulated mid-market and enterprise companies, this matters because your network is where business risk concentrates. Domain controllers, file servers, databases, backup systems, and management interfaces all live there. A single weak credential or an unpatched service can let an attacker move from one foothold to full control of your environment. Regulators know this too. Frameworks such as NIS2, DORA, ISO/IEC 27001, and SOC 2 expect you to test your defenses with real adversarial techniques, not just run a scanner and file the report. This guide explains what network penetration testing is, how we run it, what you receive, and how it connects to the obligations you already carry. Our offensive security service is built around exactly this work.
What network penetration testing actually is
A network penetration test is a time-boxed, authorized engagement where engineers attempt to compromise your network and the systems attached to it. We work from a defined scope and rules of engagement, then use the same tools and tradecraft as criminal groups and state actors. We probe for exposed services, weak authentication, missing patches, flawed segmentation, and misconfigurations. When we find something exploitable, we use it, then we use that access to reach the next target. The output is evidence of real impact, not a hypothetical risk score.
This is different from a vulnerability scan. A scanner tells you a port is open or a version is old. A penetration test tells you whether that finding leads anywhere. We chain small issues together into a full attack path, because that is how real breaches happen. One low-severity information leak plus one reused password can equal domain administrator. A scanner will never connect those dots for you. If you want the deeper distinction between the two, we cover it in pentest versus scan and in PTaaS versus pentest versus automated scanning.
External versus internal network testing
Network penetration testing splits into two main perspectives, and serious programs cover both. An external test attacks your internet-facing systems from outside, the way an opportunistic attacker would. An internal test simulates an attacker who already has a foothold inside, whether from a phishing click, a compromised laptop, or a malicious insider. The two answer different questions, and a gap in either one can sink you.
- External network testing targets your public IP ranges, exposed web servers, VPN gateways, mail servers, and any service reachable from the internet, and it measures how hard it is to gain an initial foothold.
- Internal network testing assumes the attacker is already inside and focuses on lateral movement, privilege escalation, and reaching high-value systems such as domain controllers and databases.
- External testing pairs naturally with continuous discovery work, which we describe in external attack surface management, because you cannot test assets you do not know exist.
- Internal testing exposes the flat networks, shared local administrator passwords, and over-permissioned accounts that turn a single compromised host into a full breach.
- Most regulated firms need both perspectives on a regular cadence, because attackers rarely stop at the perimeter and neither should your testing.
Black box, grey box, and white box approaches
How much we know going in changes what the test reveals. Each approach has a purpose, and the right choice depends on what question you are trying to answer and how much time and budget you have.
- Black box testing gives us no internal knowledge, so we discover everything from scratch, which models an external attacker well but spends time on reconnaissance you may already understand.
- Grey box testing gives us limited information such as a standard user account or a network diagram, which lets us spend the engagement on exploitation rather than discovery, and it usually gives the best value for the effort.
- White box testing gives us full documentation, source where relevant, and architecture details, which produces the most complete coverage and suits compliance-driven assessments where thoroughness matters more than realism.
- Grey box is the default we recommend for most internal tests because it reflects the realistic case of an attacker who has already phished one employee.
- The approach should be chosen during scoping, not assumed, since the wrong choice wastes days of engineer time on the wrong activity.
How we run a network penetration test, step by step
Our methodology follows a structured sequence that mirrors how real intrusions unfold. We align our techniques to recognized references such as MITRE ATT&CK so that what we test maps to what attackers actually do in the field. The phases below are not rigid stages we rush through. We loop back constantly as new access opens new targets.
- Scoping and rules of engagement, where we agree on targets, timing, exclusions, escalation contacts, and what counts as success, all in writing before any testing begins.
- Reconnaissance and discovery, where we enumerate live hosts, open ports, running services, and software versions to build an accurate map of the attack surface.
- Vulnerability identification, where we combine automated tooling with manual analysis to separate real, exploitable weaknesses from scanner noise.
- Exploitation, where we attempt to compromise identified weaknesses and gain access to systems, capturing evidence at every step.
- Post-exploitation and lateral movement, where we escalate privileges, harvest credentials, and pivot toward high-value assets to measure true blast radius.
- Reporting and retesting, where we document findings, rank them by real risk, walk your team through them, and verify fixes once you have remediated.
A clean scan report confirms the absence of known vulnerabilities. A penetration test establishes whether the system can still be compromised in ways a scanner cannot detect.
What you actually receive
The deliverable is where many tests fall apart. A good report serves two audiences at once. Executives need to understand business risk and make budget decisions. Engineers need enough technical detail to reproduce and fix every issue. We write for both, and we never hand over raw scanner output with a logo on the cover. If you are evaluating vendors on this point, how to choose a penetration testing company covers what to demand.
- An executive summary that states what we achieved, what the business impact is, and where the systemic weaknesses lie, written in plain language a board can act on.
- A ranked findings list ordered by real exploitability and impact, not by a raw severity number that ignores your environment.
- Full reproduction steps for every finding, including the commands, tools, and conditions needed, so your engineers can confirm and fix each one.
- Attack path narratives that show how we chained individual issues into full compromise, because the chain is usually more dangerous than any single link.
- Clear, specific remediation guidance for each issue, with the difference between a quick fix and the underlying root cause spelled out.
- A retest to verify that your fixes actually closed the gaps, which is the part that turns a report into measurable risk reduction.
Where network testing fits among other assessments
Network penetration testing is one part of a broader testing program, and it is important to understand its boundaries. It covers infrastructure, but it does not deeply exercise application logic, APIs, or cloud configuration. Those need their own dedicated work. Treating a network test as if it covers everything is a common and dangerous mistake.
- Network testing covers servers, services, segmentation, and the protocols that hold your infrastructure together, and it is the right tool for that layer.
- Web and mobile application testing exercises business logic and the OWASP Top 10, which a network test only touches at the surface, and we cover the depth of it in our web application penetration testing guide.
- API security testing follows the OWASP API Security Top 10 and finds flaws that network scans miss entirely, as we explain in API security testing.
- Cloud security assessment reviews identity, configuration, and entitlements in AWS, Azure, or Google Cloud, which behave nothing like a traditional network, and we go deep on it in cloud security assessment.
- A mature program combines all of these, often under one offensive engagement, which is why our offensive security service and application security service are designed to run together.
How often you should test
There is no single correct frequency, but there are clear minimums. Most regulated organizations should run a full network penetration test at least once a year, and again after any significant change. A point-in-time test is a snapshot, and networks change constantly, so the gap between tests is where new risk accumulates.
- Test at least annually as a baseline, which most frameworks and auditors expect as a floor rather than a ceiling.
- Test after major infrastructure changes such as a new data center, a cloud migration, or a merger, because new architecture brings new attack paths.
- Test after significant security incidents to confirm that the root cause is closed and that no other path leads to the same outcome.
- Pair periodic deep tests with continuous monitoring so you are not blind between engagements, which is the role of managed detection and response.
- Increase frequency for systems that handle regulated data or money, since the cost of a breach there dwarfs the cost of an extra test.
Common mistakes and red flags
We see the same failures repeatedly, both in how tests are bought and in how they are run. Knowing these patterns helps you spend your budget on testing that actually reduces risk rather than testing that just produces a document for the audit file.
- Buying a scan and calling it a penetration test, which produces a long list of findings with no proof that any of them lead to real compromise.
- Scoping the test so narrowly that the most exposed systems are excluded, which means the report looks clean while the real risk goes untested.
- Accepting a report with no reproduction steps or no retest, which leaves your engineers unable to verify fixes and leaves you guessing whether risk was reduced.
- Treating the annual test as a compliance checkbox rather than a security exercise, which we argue against directly in why SOC 2 is not security.
- Ignoring credential reuse and flat network design, which are the two issues that most often turn a minor foothold into a full domain compromise.
- Hiring on price alone without checking methodology or reporting quality, a trap we break down in choosing a penetration testing company.
What it costs and what drives the effort
Pricing follows scope and complexity, not a fixed menu. The honest answer is that a credible network penetration test is priced by the number of days a skilled engineer needs, and that depends on the size of your environment and the depth of testing you want. We break down the full economics in penetration testing cost, but a few drivers matter most.
- The number of live hosts and IP ranges in scope, since every additional system adds discovery and testing time.
- Whether the test is external, internal, or both, because each perspective is effectively a separate engagement with its own setup.
- The chosen approach, since black box reconnaissance consumes days that grey box access removes from the bill.
- The depth of post-exploitation you want, since proving full domain compromise takes longer than confirming initial access.
- Whether a retest is included, which we consider mandatory rather than optional, and which a serious quote will always cover.
How network testing maps to compliance
Regulated firms rarely test purely for security. They test because frameworks require evidence of adversarial assessment, and because auditors and regulators ask for it directly. Network penetration testing produces exactly the kind of independent, technical proof these frameworks expect, and it feeds the wider work our governance and compliance team does.
- The NIS2 Directive (EU) 2022/2555 requires essential and important entities to manage risk and test the effectiveness of their measures, and we explain the obligations in NIS2 explained.
- DORA Regulation (EU) 2022/2554, in force since January 2025, requires financial entities to run regular threat-led testing of their ICT systems, which we map out in the DORA compliance checklist and contrast in NIS2 versus DORA.
- ISO/IEC 27001:2022, with its 93 Annex A controls across four themes, expects technical vulnerability management and regular testing as part of a working management system, as covered in our ISO 27001 certification guide.
- SOC 2 Trust Services Criteria call for monitoring and evaluation of controls, and a network test provides direct evidence for the security criterion, as we discuss in SOC 2 readiness.
- Mapping a single test to multiple frameworks at once reduces duplicated effort, which is the practical value of treating compliance and security as one program rather than two.
Network penetration testing is the most direct way to learn what an attacker can do inside your environment before one tries. Done well, it gives you proof of real risk, a ranked path to fixing it, and the independent evidence your regulators and auditors expect. Done badly, it is a scan with a cover page. We run it the first way. If you want a test scoped to your environment and your compliance obligations, read more about our network penetration testing service or book a scoping call and we will walk you through what a useful engagement looks like for your network.