CompTIA PenTest+ (PT0-003): Engagement Management

Table of Contents
Click Here to Return To the CompTIA PenTest+ Course Page
Engagement Management is 13% of the CompTIA PenTest+ (PT0-003) exam. This module covers how you scope, authorize, communicate, and report a penetration test. Skipping the paperwork is how testers end up in legal trouble, so master this domain first.
Every paid penetration test starts before you run a single scan. You agree on what you will test, what you will not touch, who you call when something breaks, and how you hand over findings. Get this wrong and a “successful” test becomes a lawsuit or a production outage. Get it right and the client trusts your results enough to act on them.
Pre-engagement Activities
Pre-engagement work turns a vague request like “test our network” into a signed, bounded, legal piece of work. You define scope, set rules of engagement (RoE), pick target selection criteria, and choose the assessment types the client needs.
Scope lists exactly what is in play. You write it with the client’s regulations, frameworks, and standards in mind. A bank in scope for PCI DSS has different requirements than a hospital bound by HIPAA. Scope creep is the most common way an engagement goes over budget, so you write it down and you hold the line.
Rules of engagement define how you test once the targets are set. A solid RoE document answers these questions:
- Exclusions - which hosts, subnets, or business hours are off-limits
- Test cases - which techniques you are allowed to use, for example whether denial-of-service or social engineering is permitted
- Escalation path - who you call when you find a critical flaw or break something
- Testing window - the start and end dates and the hours you operate
Target selection describes the assets with precise notation so there is no confusion about boundaries.
| Notation | Example | Meaning |
|---|---|---|
| CIDR range | 10.0.0.0/24 | 256 addresses from 10.0.0.0 to 10.0.0.255 |
| IP address | 192.168.1.50 | A single host |
| Domain | example.com | A registered domain and its in-scope subdomains |
| URL | https://app.example.com/login | A specific web application endpoint |
Assessment types match the client’s risk. You scope web, network, mobile, cloud, API, application, and wireless tests differently because each needs different tools, access, and time.
Responsibility, Legal, and Ethics
You never test a system without written authorization. The authorization letter, sometimes called a “get out of jail free” letter, names the systems, the dates, and the people who approved the work. You carry it during physical or on-site testing so you can prove you are authorized if someone stops you.
The shared responsibility model decides who is liable for what, and it matters most in cloud engagements. A client cannot authorize you to attack infrastructure they do not own.
| Party | Owns | Penetration test impact |
|---|---|---|
| Hosting provider | Physical data center, hypervisor, managed services | You usually need the provider’s permission to test their layer |
| Customer | Operating systems, applications, data, configuration | The client can authorize testing of these |
| Penetration tester | The test methodology and conduct | You stay inside scope and follow the RoE |
| Third party | A SaaS or supplier the client integrates | You need separate written authorization |
Legal and ethical considerations also include mandatory reporting. If you find evidence of an active breach, child exploitation material, or another illegal act, you may be legally required to report it. Account for the risk to the penetration tester too. Physical testing and social engineering carry personal and legal risk, so define how you respond if you are detained or confronted.
Collaboration and Frameworks
A penetration test is a team activity. You run peer review so a second tester checks your findings before they reach the client. You keep stakeholder alignment so the client knows what is happening. You follow the escalation path for critical issues, and you use secure distribution so the final report, which is a roadmap of every weakness, never leaks in plaintext email.
You ground your methodology in established testing frameworks so your work is repeatable and defensible.
| Framework | Focus |
|---|---|
| OSSTMM | Open Source Security Testing Methodology Manual, a metrics-driven test approach |
| CREST | A certification and accreditation body with structured testing standards |
| PTES | Penetration Testing Execution Standard, seven phases from pre-engagement to reporting |
| MITRE ATT&CK | A knowledge base of real adversary tactics and techniques |
| OWASP Top 10 | The most critical web application risks |
| OWASP MASVS | The Mobile Application Security Verification Standard |
| Purdue model | A reference architecture for segmenting OT and ICS networks |
You apply threat modeling to decide where to focus your effort. Each model scores or structures risk differently.
- STRIDE - categorizes threats as Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege
- DREAD - rates risk by Damage, Reproducibility, Exploitability, Affected users, and Discoverability
- OCTAVE - an organizational, asset-driven risk assessment method
Reporting and Remediation
The report is the product the client pays for. A weak report wastes a strong test. Build it from these components:
- Executive summary - a non-technical overview for leadership that states business risk and bottom-line findings
- Methodology - the frameworks, tools, and scope you used, so the test is reproducible
- Detailed findings - each vulnerability with severity, evidence, and affected assets
- Attack narrative - the story of how you chained findings into real compromise
- Recommendations - prioritized, actionable fixes
You document test limitations, assumptions, and quality control so the reader understands what the test did and did not cover. Then you recommend remediation through layered controls:
| Control type | Example |
|---|---|
| Technical | Patch a vulnerable service, enforce MFA, segment the network |
| Administrative | Update the password policy, run security awareness training |
| Operational | Add log monitoring, define an incident response runbook |
| Physical | Install badge readers, add cameras at server room doors |
You rank findings by business risk, not by how clever the exploit was. A medium-severity flaw on an internet-facing payment server outranks a critical flaw on an isolated lab box.
Next Steps
With the engagement scoped, authorized, and documented, move to Reconnaissance and Enumeration to gather intelligence on your targets, then advance to Vulnerability Discovery and Analysis to find weaknesses. The largest domain, Attacks and Exploits , puts those findings to work, and Post-exploitation and Lateral Movement shows what an attacker does after the first foothold. Return to the CompTIA PenTest+ Course for the full path, and review tips for passing CompTIA exams before test day.


