Network Penetration Testing Checklist: 2026 Complete Guide

A network penetration test is only as good as its preparation. The most common reasons tests fail to surface critical vulnerabilities — or waste budget on irrelevant areas — come down to poor scoping, missing assets, and undefined rules of engagement. This checklist covers everything you need before, during, and after a network penetration test to get maximum value from the engagement.

Network Penetration Testing Checklist: Pre-Engagement

Scope Definition

  • ☐ Define in-scope IP ranges and CIDR blocks (include all subnets you want tested)
  • ☐ Define out-of-scope systems explicitly (production databases, third-party SaaS, payment processors)
  • ☐ Identify critical systems that require extra care during testing (production databases, high-availability services)
  • ☐ Confirm whether the test covers external-facing IPs, internal network, or both
  • ☐ Decide testing approach: black box (no knowledge), grey box (network diagram + credentials), or white box (full documentation)
  • ☐ Clarify if Active Directory / domain environment is in scope
  • ☐ Specify whether cloud-connected systems (AWS VPCs, Azure VNets) are in scope
  • ☐ Confirm whether wireless networks are in scope (requires on-site testing)

Rules of Engagement

  • ☐ Agree testing window (business hours only, out-of-hours, 24/7)
  • ☐ Define escalation contacts if critical findings are discovered during testing
  • ☐ Define out-of-hours emergency contact for both client and testing team
  • ☐ Agree on destructive testing boundaries (e.g., no DoS attacks on production)
  • ☐ Confirm whether password cracking against captured hashes is permitted
  • ☐ Agree on lateral movement boundaries (can testers pivot through all network segments?)
  • ☐ Specify whether data exfiltration simulation is in scope (often requires explicit written permission)
  • ☐ Confirm authorisation chain — who in the organisation has authority to authorise the test

Documentation and Legal

  • ☐ Signed scope of work / statement of work with IP ranges explicitly listed
  • ☐ Signed rules of engagement document
  • ☐ NDA in place
  • ☐ Authorisation letter prepared (required if testing IPs hosted on third-party infrastructure such as AWS, Azure, or a hosting provider)
  • ☐ Cloud provider notification (AWS, Azure, and GCP require advance notification for penetration testing of their infrastructure — check their testing policies)
  • ☐ Confirm tester hold professional indemnity insurance and verify coverage level

Technical Preparation

  • ☐ Provide network topology diagram (grey/white box only)
  • ☐ Whitelist testing team IP addresses in firewall/IDS/IPS (prevents false-positive blocking during testing)
  • ☐ Configure monitoring to log but not block test traffic (allows you to assess detection capability)
  • ☐ Provide VPN access if internal network testing is conducted remotely
  • ☐ Create test accounts with appropriate privilege levels if required
  • ☐ Notify your hosting provider or ISP if testing will generate high traffic volumes
  • ☐ Suspend automated blocking rules that would terminate test sessions (coordinate with SOC/SIEM team)

Network Penetration Testing Checklist: What Testers Will Check

A thorough network penetration test follows a structured methodology. Here’s what should be covered in a complete engagement:

Reconnaissance and Discovery

  • ☐ Port scanning and service enumeration (TCP/UDP)
  • ☐ OS fingerprinting and version detection
  • ☐ Service banner grabbing
  • ☐ DNS enumeration (zone transfers, subdomain discovery)
  • ☐ SNMP enumeration
  • ☐ SMB enumeration (shares, users, policies)
  • ☐ LDAP enumeration (Active Directory structure)
  • ☐ NetBIOS and NBT-NS enumeration

Vulnerability Identification

  • ☐ Authenticated and unauthenticated vulnerability scanning
  • ☐ Manual verification of scanner findings (eliminate false positives)
  • ☐ Check for unpatched CVEs on in-scope systems
  • ☐ Assess default credentials on network devices, services, and management interfaces
  • ☐ Check for weak TLS configurations (outdated protocols, weak cipher suites)
  • ☐ Review exposed management interfaces (RDP, SSH, Telnet, VNC, web admin panels)
  • ☐ Review firewall rules and network ACLs for overly permissive rules

Active Directory and Windows Environments

  • ☐ Kerberoasting (service account ticket extraction)
  • ☐ AS-REP Roasting (accounts without Kerberos pre-authentication)
  • ☐ Pass-the-Hash / Pass-the-Ticket attacks
  • ☐ BloodHound / SharpHound AD attack path analysis
  • ☐ DCSync attack potential assessment
  • ☐ Domain trust relationship mapping and abuse potential
  • ☐ GPO and ACL misconfigurations (WriteDACL, GenericAll, GenericWrite)
  • ☐ Unconstrained and constrained Kerberos delegation misconfigurations
  • ☐ NTLM relay attack opportunities (LLMNR/NBT-NS poisoning)
  • ☐ Local administrator password reuse across workstations
  • ☐ Password policy assessment (minimum length, complexity, lockout)

Network Segmentation and Lateral Movement

  • ☐ Verify network segmentation controls between sensitive zones
  • ☐ Attempt lateral movement from initial foothold to higher-value systems
  • ☐ Test VLAN hopping potential
  • ☐ Assess jump box / bastion host security
  • ☐ Review inter-VLAN routing rules

Post-Exploitation (Agreed Scope)

  • ☐ Privilege escalation to SYSTEM / root on compromised hosts
  • ☐ Domain controller compromise (if in scope)
  • ☐ Credential harvesting (SAM, NTDS.dit, cached credentials)
  • ☐ Sensitive data discovery (defined by client — PII locations, financial data, IP)
  • ☐ Persistence mechanism testing (registry autorun keys, scheduled tasks, service creation)

Internal Penetration Testing Checklist: Post-Engagement

Receiving the Report

  • ☐ Verify all agreed scope items are covered in the report
  • ☐ Check that findings are categorised by severity (Critical, High, Medium, Low, Informational)
  • ☐ Confirm CVSS v3.1 scores are provided for vulnerability findings
  • ☐ Verify reproduction steps are included for each finding
  • ☐ Confirm remediation guidance is specific (not just “patch the system”)
  • ☐ Request raw findings export (CSV/XML) if needed for vulnerability management import

Remediation Planning

  • ☐ Triage Critical and High findings immediately — assign owners and deadlines
  • ☐ Cross-reference findings against existing vulnerability management backlog
  • ☐ Escalate any Critical findings to senior leadership / board with context
  • ☐ Create remediation tickets in your tracking system for all findings
  • ☐ Plan a retest window within 30–60 days of initial testing

Retest and Verification

  • ☐ Address all Critical and High findings before retest
  • ☐ Document remediation evidence for each finding (patch notes, configuration changes, code commits)
  • ☐ Retest confirms fix effectiveness — not just that the vulnerable service was taken offline
  • ☐ Obtain letter of attestation or retest report for compliance submission

Common Network Penetration Testing Mistakes to Avoid

  1. Whitelisting test traffic in production IDS/IPS — If you suppress all alerts during testing, you won’t learn whether your detection capability would catch a real attacker. A better approach: log but don’t block test traffic, then review detection coverage as part of the engagement findings.
  2. Excluding “critical” systems from scope — Systems excluded from testing because they “can’t be touched” are often the highest-risk systems on the network. Work with your vendor to agree safe testing procedures for these systems rather than excluding them.
  3. Not involving the remediation team at scoping — The team who will fix findings should be part of the scoping conversation. They’ll flag practical constraints that affect prioritisation and prevent findings that can’t actually be remediated.
  4. Treating the test report as the end goal — The report is worthless if nothing gets fixed. Allocate remediation budget and engineering time before the test, not after.
  5. Annual testing without continuous monitoring — A yearly penetration test gives you a snapshot of security posture on one day of the year. Complement it with attack surface monitoring to maintain visibility between tests.

Ready for Your Network Penetration Test?

EJN Labs conducts CREST-certified network penetration tests for organisations across the UK. Our methodology covers all the areas in this checklist. If you’re preparing for a test or evaluating vendors, we’re happy to answer scoping questions with no obligation.

Leave a Reply

Your email address will not be published. Required fields are marked *