Penetration Testing Methods Best Practices

01Purpose and scope

This manual supports the course Penetration Testing Methods. It describes how authorized security testers plan, run, and report tests against networks, web applications, and internal systems, and it works as a field reference rather than a replacement for formal training or supervised practice.
The scope covers the common phases of an engagement: pre-engagement agreement, reconnaissance, vulnerability identification, exploitation within agreed limits, post-exploitation review, cleanup, and reporting with retesting. It does not teach exploit development, malware analysis, or physical access and social engineering work against staff, since those need separate authorization, staffing, and controls.
Penetration testing becomes unauthorized access the moment it happens without written permission, so every activity in this manual assumes a signed agreement exists. Guidance here does not replace qualified professional judgment, approved internal procedures, or the legal authorization required by the employer or client. Where rules depend on jurisdiction, check current statutes and the authoritative source in your region before testing begins.

02Core principles

Authorization comes first. A statement of work and rules of engagement define which systems may be touched, when, by whom, and with which techniques. A tester who has a strong technical reason to probe a host that is not listed still needs to stop and ask before sending traffic.
Method guides the work, and tools produce evidence. Named frameworks such as the Penetration Testing Execution Standard, the OWASP Web Security Testing Guide, and NIST Special Publication 800-115 give structure to phases and coverage. Tools such as Nmap, Burp Suite, and Metasploit gather data and run checks, but they do not decide what matters to the business.
Use the least impact that proves the point. A proof of exploitation should show that a weakness is real without destroying data, exhausting resources, or leaving persistent changes. Read-only evidence is usually preferred, such as a directory listing with file names only or a token value redacted in the report.
Every finding should be reproducible. A peer should be able to repeat the steps from your notes, which means recording commands, request samples, responses, and timestamps as the work happens rather than reconstructing them later.

03Planning and preparation

Start with the client's objectives. Ask what they want to learn: whether the perimeter holds, whether a customer portal leaks data between accounts, or whether an internal network segment can be reached after a credential phishing event. The objectives shape scope, depth, and the balance between automated scanning and manual analysis.
Define targets precisely. Record IP ranges, domain names, application URLs, cloud accounts, and third party hosted components. Third party assets usually need their own permission from the provider or must be excluded, and that exclusion should be written into the scope.
Agree on rules of engagement. These cover testing windows, source addresses, prohibited techniques such as denial of service, credential handling, data retention, emergency contacts, and what happens if a critical flaw or a live compromise is discovered. Name one contact who can stop testing within minutes, and confirm that person is reachable during the test window.
Prepare the working environment. Use a dedicated test laptop or virtual machine, encrypted storage for evidence, a notes template with fields for time, target, action, and result, and a secure method for moving data. Confirm that tool versions and vulnerability data are current and that scan rate limits fit the fragility of the target.

04Recommended workflow

1
: Confirm authorization, scope, and contacts in writing before any traffic leaves your network. Hold a kickoff call and compare the target list against the statement of work line by line, because a single mismatched address range causes most early disputes.
2
: Perform passive reconnaissance using public sources such as DNS records, certificate transparency logs, job postings, public code repositories, and archived web pages. Label each result with its source so the report can show how each fact was obtained.
3
: Map the active attack surface with controlled scanning. Use conservative timing settings, log every host touched, and reduce the rate or pause if a target shows slow responses, error spikes, or monitoring alerts from the client.
4
: Identify vulnerabilities by combining scanner output with manual validation. Treat scanner results as leads rather than findings, and discard any result you cannot confirm through a direct request, version check, or configuration review.
5
: Exploit confirmed weaknesses only as far as the rules allow. Choose the least disruptive path, record the exact request or command and its output, and capture proof that avoids sensitive records, such as a count of accessible rows rather than the rows themselves.
6
: Assess impact and pivot only within agreed boundaries. Document the privilege level reached, the data classes accessible, the business processes affected, and whether lateral movement was permitted by the rules of engagement.
7
: Clean up after yourself. Remove test accounts, uploaded files, scheduled tasks, modified registry keys, and any planted web shells, then record each removal with a timestamp and verify it by checking the system again.
8
: Prepare a draft report and brief the client on critical findings within the agreed notification window, before the full report is final. The verbal briefing lets the client start containment while the written report is still being polished.

05Quality checks, risk controls and compliance

Peer review each finding for reproducibility, accuracy of severity, and clarity of wording. A common scoring starting point is the Common Vulnerability Scoring System, but the score should then be adjusted for business context and compensating controls, and the adjustment should be stated openly so the client can challenge it.
Control operational risk through logging and separation. Keep a timestamped log of every action, use identifiable source addresses and user agents so defenders can separate test traffic from real attacks, and keep a stop procedure that every team member has read. Coordinate with the client's security operations team when possible, since an unannounced test can trigger a real incident response.
Data handling deserves the same care as the test itself. Store evidence encrypted, limit access to the engagement team, avoid copying personal records into notes, and destroy copies on the schedule written into the agreement. Credential material found during testing should be reported and rotated rather than reused.
Compliance depends on the client's sector and location. Payment card data, health records, and financial information can bring contractual, regulatory, or notification duties. Confirm obligations with the client's legal or compliance team and check current official guidance rather than relying on memory.
Trade-offs are unavoidable. Deeper testing finds more issues but raises the chance of disruption, while fully automated scanning is fast yet misses logic flaws such as broken authorization in multi-step workflows. A penetration test is also a point in time sample, and a clean result does not prove the system is secure.

06Collaboration and documentation

Define roles at the start. The engagement lead owns scope and sign off, testers perform the work, the client technical contact provides access and answers questions, the business owner accepts risk, and an escalation contact stays reachable during testing. Scope changes should be requested in writing and approved before work continues.
Document as you go. Keep a running timeline, a finding register with unique identifiers, and a list of every asset touched. Notes written at the end of a long day tend to be incomplete, and gaps in evidence weaken the report when the client disputes a finding.
A typical report includes an executive summary, scope and method, findings with evidence and remediation advice, an appendix of raw tool output, and a retest section. Write each finding so a developer can fix it without calling the tester, naming the affected component, the root cause, and a specific fix.
Share results through approved channels only. Full exploit details should not travel over unencrypted email, and the client should be asked how they want sensitive attachments delivered before the final report is sent.

07Measures and continuous improvement

Useful indicators include the count of findings by severity, the time from discovery to client notification, the share of findings confirmed manually, the retest closure rate, and the number of repeat findings across engagements. Read counts carefully, because a high total may reflect a broad scope rather than weak security.
Run a short retrospective after each engagement. Ask what slowed the team down, which tools produced the most noise, where scope questions arose, and which report sections took longer than expected. Feed the answers into your templates, rules of engagement checklist, and tool configuration notes.
Track skill growth through peer review, shadowing on live work, and internal lab exercises rather than through certificates alone. Record which techniques each tester has performed under supervision and which they have performed independently.

08Common mistakes and how to prevent them

Starting without signed authorization, or with an outdated target list, is the most serious error. Confirm scope on the day of testing as well as before the engagement, since infrastructure changes often happen between the agreement and the test window.
Reporting raw scanner output as findings inflates the report and erodes client trust. Validate each item manually, and move unconfirmed results into an appendix labeled as unverified if they are worth mentioning at all.
Running intrusive exploits against fragile production systems without a rollback plan. Agree on a test window, a maintenance contact, and a backup verification step before any exploit that could alter state is attempted.
Leaving artifacts behind, such as test accounts, web shells, or disabled security settings. Start a cleanup list at the beginning of the engagement and update it as each change is made, not at the end.
Storing client credentials in plain text on a laptop. Use an encrypted vault, delete sensitive samples once the report is accepted, and record the deletion.

09Practical checklist

Written authorization, scope list, and rules of engagement signed before any testing begins
Emergency contacts and stop procedure confirmed with the client in writing
Test source addresses, timing windows, and prohibited techniques recorded
Tools updated and evidence storage encrypted before the first scan
Passive and active activity logged with timestamps and source labels
Every finding validated through a manual check before it enters the report
Exploitation limited to the least disruptive proof agreed in the rules
Cleanup list completed, each removal verified, and the list filed with the evidence
Critical issues briefed to the client within the agreed notification window
Report peer reviewed, sensitive attachments delivered through an approved channel, and retest scheduled

★Learning sources

Micro Degree: Penetration Testing Methods
Micro Degree: Data Analytics Applications
Micro Degree: Azure Cloud Fundamentals
Micro Degree: Google Cloud Platform Basics

?Frequently asked questions

Do I need a signed agreement if the client verbally asked me to test their site?

Yes, a verbal request is not enough to protect you or the client. Get a signed statement of work and rules of engagement that list the exact targets, dates, and permitted techniques before any traffic is sent. If the client's legal or security team cannot provide that paperwork, treat the work as not authorized.

How much exploitation is appropriate in a penetration test?

Enough to prove that a weakness leads to real impact, and no more than the rules of engagement allow. Many engagements stop at proof such as a harmless file name listing or a count of accessible records. Anything that changes data, takes down a service, or moves into systems outside scope should be cleared with the escalation contact first.

Which framework should I follow for my first engagement?

Start with a recognized framework such as the Penetration Testing Execution Standard or the OWASP Web Security Testing Guide, depending on whether the target is network infrastructure or a web application. NIST Special Publication 800-115 is useful for documenting the test process. Adapt the framework to the client's rules and your organization's procedures rather than following it blindly.

What should I do if I find evidence of a live compromise during testing?

Stop the affected test activity and notify the escalation contact immediately using the method agreed in the rules of engagement. Preserve the evidence you already have without further exploration, since continued access can destroy forensic value and may cross legal lines. Follow the client's incident response guidance and your organization's procedures, and seek qualified legal advice where required.