Ethical penetration testing: permission, scope, methodology, legal practice labs, bug bounties and report writing

A penetration test is an authorised, simulated attack that shows an organisation how a real attacker could get in, so they can fix it first. The difference between a pentester and a criminal is permission, a defined scope, and a report that helps the client.

Types of security testing

Step 1: pre-engagement (never skip this)

Before touching anything, get in writing:

• Authorisation signed by someone who actually has the authority to approve testing of those systems (the system owner, not a junior staff member). Cloud and hosting providers may have their own testing policies too.
• Scope: exact domains, IP ranges, apps and accounts in scope, and what is out of scope.
• Rules of engagement: testing dates and times, allowed techniques (is social engineering allowed? denial of service is usually forbidden), how to handle sensitive data found, emergency contacts, and what happens if you find signs of a real attacker.
• A contract or statement of work covering confidentiality and liability.

Lab: check a target against the agreed scope (run it)

Professionals double-check every target before testing. Python's ipaddress module makes this easy:

import ipaddress

in_scope = [ipaddress.ip_network("192.0.2.0/28"), ipaddress.ip_network("198.51.100.10/32")]
out_of_scope = [ipaddress.ip_network("192.0.2.5/32")]   # client's payment server, excluded

def allowed(target):
    ip = ipaddress.ip_address(target)
    if any(ip in net for net in out_of_scope):
        return "NO - explicitly out of scope"
    if any(ip in net for net in in_scope):
        return "yes - in scope"
    return "NO - not listed in scope"

for t in ["192.0.2.3", "192.0.2.5", "192.0.2.20", "198.51.100.10"]:
    print(f"{t:15} {allowed(t)}")

192.0.2.20 is outside the /28 range (which covers .0 to .15), and .5 is excluded, so both must not be touched, even if they look interesting.

Step 2 onwards: the methodology

Recognised frameworks include the PTES (Penetration Testing Execution Standard), the OWASP Web Security Testing Guide and NIST SP 800-115.

Writing the report

The report is the product the client pays for. Include:

• Executive summary: plain language for managers: overall risk, top issues, key recommendations.
• Scope and methodology: what was tested, when and how.
• Findings: for each one: title, severity (e.g. CVSS), affected systems, description, evidence (screenshots), business impact, and step-by-step remediation.
• Positive findings: good controls you noticed.
• Appendices: tools used, detailed output.

Example finding title: "High: Admin login page accessible from the internet without MFA, allowing password-guessing attacks. Fix: restrict access by IP or VPN and enforce MFA."

Legal places to practise

Bug bounties

Platforms such as HackerOne, Bugcrowd and Intigriti host programmes where companies invite testing.

• Read each programme's policy: scope, banned techniques, safe-harbour terms.
• Test only listed assets, use your own test accounts, never access other users' data.
• Expect duplicates and rejections at first; most beginners learn on labs for months before their first valid bug.
• A programme's permission covers only what its policy says; a company without a programme has not invited testing.

Summary

• Permission, scope and rules of engagement come before any testing.
• Methodology: reconnaissance, scanning, vulnerability analysis, exploitation, post-exploitation, reporting, clean-up.
• The report, with clear impact and fixes, is the real deliverable.
• Practise only on legal platforms and your own lab; follow bug bounty policies exactly.