Network Penetration Testing: What Testers Do, Inside and Out

Updated: October 2026

A penetration test is the one time someone breaks into your network and hands you a written apology afterwards. It's worth a lot more when you know what the testers will do, what the report should look like, and what to fix once it lands. Here's how network penetration testing works from the inside, whether you run IT for one company or book tests for your clients.

What Is Network Penetration Testing?

Network penetration testing is an authorised, simulated attack on your network, carried out by testers who try to get in, move around and reach valuable systems the way a real attacker would. The goal is to prove which weaknesses can be exploited and how far they lead, not just list what might be wrong.

That last part is the difference from a vulnerability scan. A scanner reports that a service looks outdated. A tester uses it, lands on the box, and shows you the next three steps an attacker would take from there. If you're choosing a provider or checking whether a compliance framework demands a test, our guide to penetration testing services covers the buying side.

Internal vs External Network Penetration Testing

The two tests start from different places and answer different questions.

External tests get the attention, but internal tests usually tell the more uncomfortable story. Attackers don't need a perimeter hole if one user clicks the wrong link, so the internal test measures what happens after that click.

RedLens InfoSec walks through the same split in this short explainer, including why a mature program runs both.

What Testers Do, Step by Step

NIST's testing guide, SP 800-115, splits a penetration test into four phases. The names vary between firms, but the shape holds.

1. Planning. Scope, rules and goals get agreed and signed. In NIST's words, "No actual testing occurs in this phase."
2. Discovery. Testers map hosts, open ports and running services, then compare what they find against known vulnerabilities.
3. Attack. They try to exploit what they found. Each foothold usually loops back into more discovery, because a new position reveals new targets.
4. Reporting. It runs alongside everything else: logs during the test, a full report at the end.

The attack phase is where network tests earn their fee. An exploit on one machine is rarely the finding that matters. What matters is lateral movement: the cached admin password on that machine, the service account with too many rights, the flat network that lets the tester reach the backup server. Good testers chain those small things into a path and document every step.

What a Useful Report Contains

A good network penetration test report has an executive summary, the attack narrative, the findings, and the fixes. The narrative is the part to read first. It shows how one weakness led to the next, which is the only way to see which single fix breaks the whole chain.

The findings list should rank issues by what they led to, not by how they score in isolation. A report where the path to domain admin sits on page 47, behind forty pages of missing security headers, has the order wrong. Each finding needs evidence, the affected systems, a plain fix and a way to confirm the fix worked.

Practitioners argue about this in the thread below. The people receiving reports say the narrative helps them understand their own infrastructure. The people writing them say it cuts the questions in the debrief.

How Often to Test, and When Not To Yet

Once a year, plus after any significant change, is the common baseline. It's also what PCI DSS requires for both internal and external tests, as our framework breakdown shows. A new site, a firewall replacement, a cloud migration or a merger all count as significant.

There's also a case for waiting. If the basics are missing (no MFA, shared admin passwords, unpatched servers), a tester will walk straight in and the report will tell you what you already knew. In this r/msp thread, one reply says that when a client asks for a pentest without the fundamentals in place, the money is better spent fixing those first.

A pentest measures how well your defences hold. It works best once there's something to measure.

How to Prepare Without Skewing the Result

Preparation keeps the test safe and the results true to your environment, without handing the testers a shortcut.

Start with the rules of engagement. NIST's guide includes a template in Appendix B, and a good provider will bring their own. It should name the targets, the exclusions, the testing window, who to call if something breaks, and what the testers may and may not do. Anything not in the document is out of scope.

Then protect the business. Take fresh backups or snapshots of critical systems, agree a change freeze for the test window so results aren't muddied by unrelated changes, and tell your SOC or MDR provider when testing starts. Don't switch off your defences or whitelist the testers' tools unless the scope says so. A test run with the alarms off tells you nothing about the alarms.

Give the testers an accurate asset list, too. Scoping from a spreadsheet that's two years out of date means systems get missed. OpenFrame pulls live device inventory from the endpoints through osquery, which is one way to hand over a list that matches reality.

What to Fix First

Fix the findings that sit on the attack path, in the order they appear in it. The first link is usually credentials: weak or reused passwords, which our post on the most common passwords covers. The second is usually privilege, meaning accounts with more rights than their job needs.

Tightening roles cuts the lateral movement that turns a foothold into a breach. Our guide to role-based access control shows how to scope admin rights in Entra and your RMM. Patch the specific services the testers exploited, then ask for a retest of every critical and high finding before you call it closed.

The report is where the work starts. A retest that shows the chain is broken is the result you're paying for.

Book the Test You Can Act On

Network penetration testing shows you the path an attacker would take, from the internet or from one compromised laptop. Scope it carefully, prepare without switching off your defences, read the narrative first, and fix the chain in order.

To turn a one-off test into ongoing coverage, our roundup of vulnerability management software is the next read.