Chapter 1: Engagement Management
CertCrack.com has just hired a penetration testing team for the first time, and the person running the project is
nervous about one thing above all else: the testers will be attacking the company's own systems on purpose.
That nervousness is healthy, and it is exactly what engagement management exists to address. Before anyone
runs a single scan, the engagement must answer a set of questions in writing: what is being tested, what is off
limits, who authorized it, what the testers are allowed to do, who to call when something goes wrong, and what
the company will receive at the end. A penetration test without those answers is not a test. It is an unauthorized
attack with good intentions, and the exam treats it that way. This chapter builds the judgment to plan, authorize,
run, and report a test that is legal, safe, and useful, from the first scoping call to the retest that proves the fixes
worked.
1. Engagement types: what the tester knows before starting
Every engagement starts with a decision about how much the tester is told in advance. That decision shapes
everything that follows: how realistic the test is, how fast it goes, and what kinds of weaknesses it is likely to find.
The three types differ only in the tester's starting knowledge, but the exam loves to test whether you can match
the type to the scenario, so learn them as a spectrum, not as three unrelated labels.
Penetration test. An authorized, simulated attack against an organization's systems, carried out to find
exploitable weaknesses and to show their real business impact, under agreed rules and within an agreed
scope.
1.1 Black-box testing
In a black-box test, the tester starts with nothing but the target's name, much like an outside attacker would.
CertCrack.com might hand over only its public domain name and say, in effect, find your own way in. The tester
then does the same reconnaissance a real attacker does: mapping public-facing systems, harvesting employee
names from public sources, probing the website, and looking for an exposed service or a forgotten subdomain.
The value of this approach is realism. It tests the organization's detection and response against an attacker who
truly knows nothing, and it answers the question leadership actually worries about: could someone from the
internet get in?
The price of that realism is time and coverage. A black-box tester spends a large share of the engagement on
reconnaissance, and may never reach internal systems at all, which means deep internal weaknesses can go
untested. Black-box testing also tends to find the same shallow issues again and again if the organization
already has decent perimeter defenses. When a scenario describes a tester starting with no credentials, no
documentation, and no internal access, the answer is black-box, and the exam will often pair it with the
trade-off: most realistic, least coverage.
Black-box testing. A penetration test in which the tester starts with no prior knowledge of the target's
internals, no credentials, and no documentation, simulating an external attacker.
1.2 Gray-box testing
Gray-box testing gives the tester partial knowledge: typically a standard user account, an architecture diagram,
or a list of the applications in scope, but not source code or administrator credentials. CertCrack.com might
provide a normal employee account for its customer portal and a network diagram showing which systems
matter most, then ask the tester to see how far that starting position can be pushed. This is the most common
engagement type in practice, because it mirrors the most common real threat: an attacker who has phished one
account, or a malicious insider with ordinary access, trying to escalate from there.
Gray-box testing is efficient. The tester skips the long external reconnaissance phase and spends the
engagement on the interesting question: what can an authenticated user do that they should not be able to do?
Privilege escalation, broken access control, and business-logic flaws live here, and a gray-box test finds them
faster than a black-box test ever would. The trade-off is that it tests less of the external attack path, since the
tester never had to break in from the outside. When a scenario gives the tester a user account or partial
documentation, the answer is gray-box, and the exam often frames it as the balance between realism and
coverage.
Gray-box testing. A penetration test in which the tester starts with partial knowledge of the target, such as a
standard user account or an architecture diagram, but not full internals or administrator access.
1.3 White-box testing
In a white-box test, the tester gets everything: source code, system configurations, network diagrams, and
administrator credentials. CertCrack.com might hand over the source code of its customer portal and full access
to its staging environment, then ask the tester to find every weakness, including ones no outsider would ever
stumble across. This is the fastest route to thorough coverage, because the tester can read the code, trace data
flows, and test every function directly instead of guessing at behavior from the outside.
The trade-off runs in the other direction. A white-box test does not simulate a realistic attacker, since no real
attacker starts with the source code, and it can create a false sense of completeness: the test covered the code it
was given, which may not match what is actually running in production. White-box testing is the right choice
when the goal is maximum coverage in minimum time, for example before a major release or after a security
overhaul, and the exam often pairs it with code review and configuration review as companion activities. When a
scenario hands the tester source code and admin credentials, the answer is white-box.
White-box testing. A penetration test in which the tester starts with full knowledge of the target, including
source code, configurations, and administrator credentials, for maximum coverage.
1.4 Choosing the right type
The choice is driven by the goal, not by habit. If CertCrack.com wants to know whether an internet attacker can
break in, black-box fits. If it wants to know what a compromised employee account can do, gray-box fits. If it
wants the most complete list of weaknesses before launch, white-box fits. Budget and time matter too:
black-box engagements take longer to reach the same depth, and white-box engagements need the client to
prepare and share materials. A good scoping conversation names the goal first and lets the type follow from it,
rather than picking a type and hoping it answers the right question.
Figure 1: Comparison of black-box, gray-box, and white-box testing by tester knowledge, realism, and coverage (illustrated)
The exam tests engagement types with scenario clues, not definitions. No credentials and no documents
means black-box. A user account or a diagram means gray-box. Source code and admin access means
white-box. Read the scenario for what the tester was given, and the type answers itself.
Answer: Gray-box testing, because the tester starts with partial knowledge (an account and a diagram) but not
full internals.
2. Planning and scoping an engagement
Planning is where most engagements are won or lost. A well-scoped test runs smoothly because everyone
agreed, in writing, on what will happen. A poorly scoped test produces arguments mid-engagement, missed
targets, and findings the client disputes. The planning phase has one job: turn a vague request like "test our
security" into a precise, agreed plan.
Figure 2: Penetration test lifecycle from planning and authorization through testing, reporting, and retest (illustrated)
2.1 Scoping, step by step
Scoping is a procedure, and it should be worked through in order:
1. Define the goal in one sentence. What decision will this test inform? Examples include launching a new
application safely, satisfying a compliance requirement, or measuring whether last year's fixes held.
2. List the targets. Name every system, application, network range, domain, and cloud tenant in scope, with
addresses or identifiers, not vague descriptions.
3. List the exclusions. Name what is out of scope just as precisely, including production databases,
third-party services, and safety-critical systems.
4. Agree the methods. State which techniques are allowed: automated scanning, manual exploitation,
credentialed testing, social engineering, physical testing, or some subset of these.
5. Set the testing windows. Agree the dates and hours when testing may happen, and whether testing is
allowed during business hours.
6. Agree the deliverables. Name the report format, the audience, the delivery date, and whether a retest is
included.
7. Confirm the resources. Confirm the testers, the client contacts, and the emergency contacts are available
for the whole window, and that authorization is signed before testing starts.
Each step removes a future argument. A goal that is never stated cannot be measured. A target that is never
named cannot be defended as in scope. An exclusion that is never written down will be tested by someone who
assumed it was included.
Scope is a safety boundary, not a suggestion. Testing outside scope is not thoroughness. It is unauthorized
activity, and it can damage systems, break laws, and destroy the client's trust in the test.
2.2 Targets, assets, and exclusions
Targets come in more forms than servers. An engagement can cover web applications, mobile applications,
application programming interfaces, network infrastructure, wireless networks, cloud environments, and
people, through social engineering, as well as physical premises. Each target type needs its own scoping care.
An application programming interface needs its endpoints and authentication methods listed. A cloud tenant
needs the account identifiers and a note on what the cloud provider permits, since providers have their own
testing policies. Social engineering needs the pretexts and the target groups agreed, and usually excludes
executives' personal accounts and any tactic that could cause real harm or panic.
Exclusions deserve the same precision as inclusions. Common exclusions include denial-of-service testing
against production, destructive exploits, altering or deleting production data, testing third-party services the
client does not control, and any system whose failure could endanger people. When a tester discovers a system
that appears connected to an in-scope target but is not listed, the correct move is to note it and ask, not to pivot
into it. That discipline is what separates a professional test from an incident.
2.3 Timing, windows, and resources
Timing is a safety decision as much as a scheduling one. Testing during business hours means client staff are
available to respond if something breaks, but it also means test traffic competes with real users and a mistake
has a visible audience. Testing overnight or on weekends reduces user impact but leaves fewer people available
to help if a system goes down. Neither choice is always right. The right choice is the one the client makes
deliberately, with eyes open, and writes into the rules of engagement.
Time-boxing matters too. An engagement that runs long without results loses the client's attention, and an
engagement that is too short for its scope produces a thin report. The scope, the window, and the team size
must fit together: a large scope in a short window with one tester is a plan for shallow coverage, and the honest
move is to narrow the scope or extend the window before testing starts, not to quietly skip targets during the
test.
Scoping questions on the exam almost always hinge on one thing: what is written down. If a target, method, or
window is not in the agreed scope, it does not happen, no matter who asks for it mid-test or how harmless it
looks.
3. Rules of engagement
The rules of engagement document is the engagement's constitution. It is the single written agreement that
says what the testers may do, what they may not do, and what happens when something unexpected occurs.
Every tester on the team should be able to explain it without looking it up, and the client should have signed it
before testing begins. When a dispute arises mid-engagement, and disputes do arise, the rules of engagement
are what everyone turns to.
3.1 What a rules-of-engagement document contains
A complete rules-of-engagement document covers the scope and targets from the scoping phase, the testing
windows, the permitted methods, and the prohibited actions, plus the operational details that keep a test safe.
Those details include the emergency contacts on both sides, the deconfliction procedure, the communication
plan and reporting cadence, how test data and evidence will be handled, the conditions under which testing
stops, and the deliverables and their dates. If any of these are missing, the gap will be discovered at the worst
possible moment, usually during an incident.
Data handling deserves special attention because testers collect sensitive material by design: credentials,
internal documents, and sometimes personal data. The rules should state what may be collected, where it will
be stored, how it will be encrypted, who may see it, and when it will be destroyed. A tester who captures a real
customer database "for evidence" and stores it on an unencrypted laptop has created a second incident on top
of the test.
Rules of engagement. The written agreement between the testing team and the client that defines the scope,
targets, methods, prohibited actions, testing windows, contacts, and procedures for a penetration test.
3.2 Prohibited actions and safety limits
Prohibited actions exist because some techniques carry risks no finding is worth. Denial-of-service testing
against production systems is the classic example: proving a system can be knocked offline by knocking it offline
helps no one and can cost the client real revenue. Destructive exploits, deleting or altering production data, and
ransomware simulations on live systems belong in the same category. Social engineering has its own limits:
impersonating law enforcement, threatening staff, or targeting individuals in ways that cause genuine distress
crosses from testing into harm, and a professional engagement excludes those tactics in writing.
Safety limits also cover what happens when a tester finds something fragile. If an exploit crashes a service, the
tester stops, reports it immediately, and does not repeat the exploit to "confirm" the crash. If a tester gains
access to data far more sensitive than expected, such as real payment card data or medical records, the tester
stops, protects the data, and notifies the client contact at once rather than exploring further. The finding is
already proven. Further exploration only increases the damage.
3.3 Emergency contacts and deconfliction
Deconfliction is the procedure for telling authorized testing apart from a real attack. The client's security team
watches the same alarms the testers trigger, and without deconfliction, a routine scan becomes a full incident
response, with staff woken, systems isolated, and, in the worst case, law enforcement called. A good
deconfliction plan names a contact on each side, an out-of-band communication channel such as a phone
number rather than the monitored email system, and a code word or phrase the tester can use to confirm that
the activity is authorized. When the security team calls about suspicious scanning, the tester gives the code
word, the client contact confirms the test, and both sides stand down and log the event.
The reverse situation matters just as much. If a real attack is detected during the testing window, the test
pauses. The testers tell the client contact what they were doing at the time, so the defenders can separate test
traffic from attacker traffic, and the client's incident response takes priority. Continuing to test during a live
incident contaminates the evidence, confuses the response, and can make the testers look like participants in
the attack.
Deconfliction. The agreed procedure for confirming that detected activity is authorized testing rather than a
real attack, using designated contacts, an out-of-band channel, and usually a code word.
Using only a text editor on your own computer, draft a rules-of-engagement checklist for a fictional lab
engagement against systems you own. Include scope, targets, testing window, permitted and prohibited
actions, emergency contacts, a deconfliction code word, and data handling rules. Then read it back and ask
yourself: if a teammate followed only this document, would they know exactly what to do and what never to
do? If the answer is no, your checklist has a gap, and finding it here is the whole point of the exercise.
Deconfliction questions usually describe a security team reacting to test traffic. The correct answer is almost
always the agreed contact and code word, not stopping the engagement, denying involvement, or escalating
to management.
Answer: Use the agreed deconfliction contact and code word to confirm the activity is authorized testing, so
the security team can stand down and log the event.
4. Authorization: the permission that makes testing legal
Authorization is the line between a penetration test and a crime. Everything else in this chapter supports it, and
nothing replaces it. A tester who cannot produce a valid, current, written authorization for the exact targets and
methods in use should not be testing, no matter who asked them to start or how urgent the work seems.
4.1 What makes authorization valid
Valid authorization has five properties, and the exam tests all of them. It is written, not verbal, because verbal
permission cannot be proven later and memories differ under pressure. It is signed by someone with authority
over the assets, which means the system owner or an executive with that authority, not merely a friendly
manager or a developer who likes the idea. It is specific, naming the targets, the methods, and the testing
window, rather than a vague blessing to "test our security." It is current, covering the dates when testing
actually happens, not a letter from last year. And it covers third parties where they are involved: if the target
runs on a cloud provider or a hosting company, the provider's testing policy must permit the work, or the
provider's own permission must be obtained, because the client cannot authorize testing of infrastructure it
does not own.
Written authorization. A signed, dated document from a person with authority over the target assets that
permits specific testing methods against specific targets during a specific window.
Authorization comes before testing, always, without exception. A tester who starts scanning while the letter is
still being signed is testing without authorization, and no later signature fixes that.
4.2 The authorization letter
A solid authorization letter reads like a short contract, not a friendly email. It names the parties, the client and
the testing team, and it names the targets with enough precision that no one has to guess: domains, network
ranges, application names, and cloud account identifiers. It states the permitted methods and the prohibited
actions, the testing window with dates and hours, and the emergency contacts. It addresses data handling,
liability, and confidentiality in plain terms, and it carries signatures from both sides. The letter is then stored
securely by both parties, because it is the document the tester produces if anyone, including law enforcement or
a cloud provider, asks why this traffic is hitting their systems.
Keep the letter with the test at all times during the engagement. Testers working from a client site or a shared
workspace should be able to produce it within minutes. A tester who cannot show authorization when
challenged will be treated as an attacker, and rightly so.
4.3 Scope creep and how to handle it
Scope creep is the slow, friendly expansion of a test beyond what was agreed. It rarely arrives as a demand. It
arrives as a casual request: while you are here, could you also look at the payroll system, or this one extra
server, or the new application we just launched? Each request sounds small, and each one is a test of the tester's
discipline, because the new target has no written authorization, no agreed window, and no emergency contact.
Handle scope creep with a fixed procedure, every time:
1. Stop and do not test the new target. No preliminary scan, no quick look, no exception for something that
looks harmless.
2. Document the request: who asked, what target, what methods, and when.
3. Verify authority. Confirm the requester is someone who can authorize the new target, not just someone
with an opinion about it.
4. Get a written amendment. The scope change goes into the rules of engagement and the authorization
letter, signed, before testing resumes.
5. Check the window and the budget. Confirm the new work fits the agreed dates and effort, or agree the
change formally.
6. Resume testing only on the amended scope, and log the change in the final report so the scope history is
transparent.
If the requester cannot provide written authorization, the answer is no, delivered politely and documented.
Refusing an unauthorized request is not poor customer service. It is the service.
Figure 3: Decision flow when a target outside scope is requested mid-engagement (illustrated)
Scope creep. The gradual expansion of a penetration test beyond its agreed scope, targets, methods, or
window, usually through informal mid-engagement requests.
The exam's scope-creep trap is the verbal "go ahead." A manager saying "just test it, I will sort the paperwork
later" is not authorization. The correct answer is always to stop and get the change in writing first.
Answer: Do not test the payroll server. Document the request and get a signed written amendment to the
scope and authorization before touching the new target.
5. Legal and ethical compliance
A penetration tester works in a legal minefield by design: the same actions that are a job with authorization are
crimes without it. The exam does not expect legal expertise, and nothing in this section is legal advice, since
laws vary by jurisdiction and change over time. It expects the tester to know the major legal frameworks, to
recognize when an activity crosses a legal line, and to stop and ask before crossing it.
5.1 Computer crime law basics
In the United States, the Computer Fraud and Abuse Act makes unauthorized access to computer systems a
federal offense, with both criminal penalties and civil liability. Authorization is the defense: a tester acting within
a valid written authorization is not accessing systems "without authorization," while a tester who strays outside
scope may be, even if their intentions were good. Other countries have equivalent laws, such as the Computer
Misuse Act in the United Kingdom, and a tester working across borders must respect the law of every
jurisdiction where the systems and the data sit, not just the law at home. The practical rule is simple: if the
authorization does not clearly cover an action, do not take it, and if the legal picture is unclear, raise it with the
client and legal counsel before proceeding.
Ethics run alongside the law. A professional tester does not use client access for personal gain, does not keep
copies of client data, does not disclose findings to anyone outside the agreed audience, and does not test
systems for fun after the engagement ends. The industry's trust model depends on testers behaving like invited
guests with a job to do, not like attackers who happen to have a letter.
5.2 Privacy and data protection
Testing touches personal data constantly: employee names in directory listings, customer records in application
responses, and email addresses in intercepted traffic. The European Union's General Data Protection Regulation
applies to the personal data of people in the EU no matter where the tester sits, and its core demands are
minimization and purpose: collect only the personal data the test genuinely needs, use it only for the test,
protect it, and delete it when the test ends. A tester who downloads a full customer database to prove a finding
that a single redacted record would have proven has violated that principle and created a data-protection
incident.
Wiretapping and interception law adds a second privacy boundary. Intercepting communications, which
includes capturing network traffic containing other people's messages, generally requires consent or legal
authority, and the rules vary sharply: some jurisdictions require only one party's consent, others require every
party's consent. Social engineering carries its own privacy and fraud risks: impersonating a real person to obtain
credentials or data can cross from testing into fraud or identity misuse, which is why pretexts and target groups
belong in the rules of engagement, agreed in advance, rather than improvised during the test.
5.3 Industry rules: PCI DSS and others
Industry frameworks add obligations on top of the law, and the exam tests the best-known one: the Payment
Card Industry Data Security Standard, which governs any organization that stores, processes, or transmits
cardholder data. PCI DSS requires penetration testing at least annually and after significant changes to the
environment, and it requires testing of segmentation controls that separate the cardholder data environment
from everything else. A test of a payment system therefore has a defined scope, the cardholder data
environment and its boundaries, and a defined sensitivity: the tester must never use, expose, or retain real
cardholder data, working with test data instead. Similar sector rules exist elsewhere, such as healthcare and
financial regulation, and the pattern is the same: the framework tells the tester what must be tested, how often,
and what must never be mishandled.
Framework questions usually hinge on scope and handling, not on memorizing clause numbers. PCI DSS
means the cardholder data environment is in scope, testing is regular, and real card data is never used as test
material.
5.4 When you find a live intrusion
Sooner or later, a tester finds something that is not a test finding at all: signs that a real attacker is already
inside, or has already been inside, the client's systems. This is the moment the engagement changes character,
and the correct response is disciplined and immediate. Stop testing the affected vector so the test does not
contaminate evidence or alert the attacker. Preserve what you found without altering it: do not delete attacker
artifacts, do not "clean up" to be helpful, and do not continue exploiting the same weakness to see how far it
goes. Notify the client's designated contact immediately, through the agreed channel, and do not wait for the
final report. Then follow the client's incident response plan and step back: the incident response team owns the
incident, and the testers support it by explaining what they touched and when, so defenders can separate test
activity from attacker activity.
Reporting obligations follow from the incident, not from the test. Breach notification laws, sector regulators, and
contractual duties may require the client to notify affected people or authorities within defined windows, and
those decisions belong to the client with legal counsel, not to the tester. The tester's duty is to report promptly
and completely to the client, to preserve evidence, and to keep the finding confidential outside the agreed
audience. One exception overrides confidentiality: if the tester discovers evidence of imminent harm to people
or of serious crime that must be reported, the tester escalates through the client and, where the law requires it,
to the appropriate authorities. A test finding never justifies silence about a live threat.
Test like an adversary, behave like a professional. The tester simulates attacker techniques but never adopts
attacker ethics: no personal gain, no unnecessary damage, no disclosure outside the agreed audience, and no
silence about a live threat.
Answer: Stop testing that vector, preserve the evidence without altering it, and notify the client's designated
contact immediately, rather than continuing to exploit the server or waiting for the final report.
6. Communication during the engagement
A penetration test is a communication exercise as much as a technical one. The client is paying for
understanding, not just for findings, and understanding only arrives if the right people hear the right
information at the right time. Testers who communicate well are trusted with harder engagements. Testers who
go silent for three weeks and then deliver a shocking report are not invited back.
6.1 Stakeholders and the communication plan
An engagement has several audiences, and each needs something different. The sponsor, usually an executive,
needs the business picture and the decisions required. The technical contact needs the practical detail to fix
things and to keep the test safe. The security operations team needs to know what test traffic to expect and how
deconfliction works. Legal and compliance need to know about authorization, data handling, and any regulatory
implications. The communication plan, agreed at kickoff, names each audience, the channel for reaching them,
and the cadence: a kickoff meeting, regular status updates during testing, immediate notification for critical
findings, and a closing meeting to present the report. All of it travels over agreed, encrypted channels, because
status updates themselves can reveal that a system is vulnerable.
Status updates should be honest about progress and problems. If testing is behind schedule, if a target is
unreachable, or if a finding is more serious than expected, the client should hear it during the engagement, not
discover it in the final report. Surprises in a final report damage trust, even when the findings are accurate.
6.2 Peer review and quality checks
Before any finding reaches the client, another tester should review it. Peer review checks that the finding is
reproducible, that the evidence actually supports the claim, that the severity reflects the real risk rather than the
excitement of the discovery, and that the write-up is clear and free of errors. It catches the classic
embarrassments of the profession: the "critical" finding that was actually a test artifact, the vulnerability
reported against the wrong host, and the proof-of-concept that only worked because the tester was already
authenticated as an administrator.
Peer review also protects the tester. A finding that survives a skeptical colleague will survive a skeptical client,
and a severity rating that a second tester agrees with is far easier to defend in the closing meeting. Build review
time into the schedule rather than treating it as a luxury. A report delivered a day late but accurate beats a
report delivered on time but wrong.
6.3 Escalation paths and risk articulation
Escalation paths answer a simple question: when something serious happens, who hears about it, how fast, and
through which channel? A critical finding, a crashed production service, or a live intrusion each needs a named
person and a time frame, minutes or hours rather than days, and the path should be written into the rules of
engagement. Escalation also runs upward in severity: the technical contact first, then the sponsor, then legal
and executive leadership as the impact grows. A tester who cannot escalate a critical finding because no path
was agreed will watch a serious weakness sit unaddressed until the report lands, which may be weeks too late.
Risk articulation is the skill of explaining a finding so that a non-technical decision-maker can act on it. It
connects three things: how likely exploitation is, how much damage it would cause, and what is at stake in
business terms. A vulnerability in an internet-facing system holding customer data, with public exploit code
available, is a different conversation from the same vulnerability in an isolated internal tool with no sensitive
data, and the report must say so. Rating everything critical destroys credibility faster than almost any other
mistake, because the client learns to ignore the ratings, including the ones that matter.
Critical findings are never saved for the final report. The exam rewards immediate notification through the
agreed escalation path, and it punishes the tester who waits, even when the finding is documented perfectly
later.
Communication is part of the test, not decoration around it. A finding the client never hears in time, or never
understands well enough to fix, has the same practical value as a finding never made.
7. Penetration test reports
The report is the product the client actually buys. The testing itself is invisible once it ends; the report is what
gets read, budgeted against, and audited. A great test with a poor report wastes the engagement, while a clear
report turns technical findings into funded fixes. Writing it well is therefore a core penetration testing skill, not
an administrative chore.
7.1 Writing the report, step by step
Work through report writing in order, and do not skip the validation steps:
1. Gather the evidence. Collect every finding's notes, screenshots, tool output, and reproduction steps while
the test is still fresh, and discard anything that cannot be tied to a specific target.
2. Validate each finding. Reproduce it where possible, confirm it is not a test artifact or a false positive, and
have a second tester peer-review it.
3. Rate the risk. Assign each finding a severity based on exploitability, exposure, and business impact, using
a standard scoring input such as CVSS as one input among several, not as the verdict.
4. Draft the technical findings. Write each finding with its title, severity, affected asset, description, evidence,
reproduction steps, impact, and remediation.
5. Draft the executive summary. Summarize the overall posture, the top risks, and the priority actions in
business language, without exploit code or jargon.
6. Peer-review the full draft. Have a colleague check facts, severities, language, and consistency between the
summary and the technical detail.
7. Deliver securely and present it. Send the report through the agreed encrypted channel to the agreed
audience, then walk the client through it in a closing meeting.
8. Agree the retest. Confirm the window and scope for verifying fixes, and record it in writing.
7.2 Executive summary
The executive summary is written for people who will never read the technical section: executives, board
members, and budget holders. It answers four questions in plain language: how secure is the organization
overall, what are the most serious risks, what should be fixed first, and what happens if nothing changes. It
names the top three to five findings in business terms, for example that customer account data could be
exposed, rather than naming the vulnerability class and moving on. It contains no exploit code, no tool output,
and no jargon that requires a glossary, because every unexplained term is a reason for an executive to stop
reading.
Tone matters as much as content. An executive summary that declares everything a catastrophe will be
discounted, and one that declares everything fine will be ignored when the next incident arrives. The honest
summary distinguishes the serious from the routine, credits the defenses that worked, and gives leadership a
defensible order of work. That balance is what makes the summary trusted, and trust is what gets fixes funded.
Figure 4: How one finding is presented differently to executives and technical teams (illustrated)
7.3 Technical findings and risk ratings
The technical section is written for the people who will fix the findings, and it must give them everything they
need without requiring them to ask follow-up questions. Each finding carries a clear title, a severity rating, and
the affected asset with enough precision to locate it. The description explains the weakness in plain technical
language. The evidence shows it: redacted tool output, a screenshot, or a request and response that
demonstrates the flaw without exposing real sensitive data. Reproduction steps let the client's team confirm the
finding themselves. The impact section explains what an attacker could actually do with it, and the remediation
section says exactly how to fix it, with references to vendor guidance or standards where they exist.
Risk ratings use a simple scale, typically critical, high, medium, and low, sometimes with an informational level
for observations that are not vulnerabilities. A standard scoring system such as CVSS provides a useful input: it
scores a vulnerability's intrinsic severity from its attack vector, complexity, privileges required, and impact. But
CVSS alone does not set the rating. A high CVSS score on an isolated system with no sensitive data and no
network path may be a medium finding in context, while a moderate score on an internet-facing system holding
customer records, with public exploit code available, may be critical. The exam tests exactly that judgment:
severity is an input, context is the verdict.
Risk rating. A severity level assigned to a finding, typically critical, high, medium, or low, reflecting
exploitability, exposure, and business impact together, not a single score alone.
7.4 Remediation recommendations and retest
Recommendations must be specific enough to act on. "Improve input validation" is advice, not remediation.
"Encode all user-supplied output in the customer portal's comment function, deploy the fix to staging, and verify
with the reproduction steps in finding 3" is remediation, because a developer can start work from it without
asking what was meant. Prioritize recommendations by risk, and separate quick wins, fixes achievable in days
with low effort, from strategic changes such as architecture rework or platform migration that need planning
and budget. Assigning an owner and a target date to each recommendation, agreed with the client, turns the
report from a document into a plan.
Retest closes the loop. Within an agreed window after remediation, the tester verifies the reported findings and
only those findings, confirming each fix and reporting any that failed or introduced new problems. The retest
report is short: what was fixed, what was not, and what residual risk remains. A finding that cannot be verified
as fixed stays open, and the report says so plainly rather than quietly dropping it. An engagement without a
retest leaves the client guessing whether the money spent on fixes actually worked, which is why retest is
agreed during scoping, not requested as an afterthought.
Retest. A follow-up verification, within an agreed window, that checks whether reported findings have been
remediated, covering only those findings and reporting any residual risk.
7.5 Handling, retention, and distribution
A penetration test report is one of the most sensitive documents an organization holds, because it maps the
organization's weaknesses in detail. Handling rules protect it accordingly. The report travels only through
encrypted channels to the named audience, never by ordinary email or shared links. It is stored encrypted, with
access limited to people who need it, and every copy is accounted for, including the tester's own working copies.
Distribution beyond the agreed audience requires the client's permission, and the tester never uses report
contents in marketing material, conference talks, or portfolio examples without explicit written consent and
thorough anonymization.
Retention follows the contract and the client's policy. Reports are typically kept for a defined period, often one to
three years, for audit and compliance purposes, and then securely destroyed, including backups and working
notes. Keeping a report forever "just in case" creates a permanent target for attackers and a permanent liability
for the client. Destroying it on schedule, with a record of destruction, is the professional finish to an
engagement.
Take this sample finding and write an executive summary paragraph for it, in no more than 150 words, using
no technical jargon and no exploit code: during a lab engagement on systems you own, a tester found that the
customer portal's login page allowed unlimited password guesses, and a weak password on a test account was
guessed in under an hour, giving access to that account's order history. A good summary states the business
risk (account takeover of customer accounts), the scale (any account with a weak password), and the first fix
(limit login attempts and require stronger authentication) in language a non-technical executive can act on.
Report questions usually hinge on audience. Executives get business risk and priorities, technical teams get
evidence and reproduction steps, and mixing the two up, exploit code in the summary or vague advice in the
technical section, is the classic wrong answer.
Answer: The executive summary is written for non-technical leadership, so it should state business risk and
priority actions in plain language. Exploit code and raw output belong in the technical findings section.
Chapter check
1. CertCrack.com hires a tester and provides only its public domain name, with no credentials, documentation,
or internal access. Which engagement type is this?
A. White-box testing
B. Gray-box testing
C. Black-box testing
D. Vulnerability scanning
2. Mid-engagement, a CertCrack.com manager asks the tester to also examine a payroll server that is not in the
signed scope, saying the paperwork can follow later. What should the tester do?
A. Test the server, since the client asked for it
B. Stop, document the request, and get a signed written amendment before touching the new target
C. Test the server quietly and mention it in the final report
D. Refuse the request and end the engagement immediately
3. A tester is asked to start an engagement using an authorization letter signed fourteen months ago, whose
testing window has expired, although the scope is unchanged. What should the tester do?
A. Proceed, because the scope is unchanged
B. Get verbal confirmation from the client's manager
C. Test only low-risk targets until the paperwork arrives
D. Obtain a new, current written authorization before testing
4. During a CertCrack.com engagement, a tester finds webshell files and unfamiliar administrator accounts on a
server, indicating a real attacker is already present. What is the tester's first move?
A. Stop testing that vector, preserve the evidence, and notify the client's designated contact immediately
B. Continue exploiting the server to map the attacker's full access
C. Delete the attacker artifacts to clean up the server
D. Wait and include the discovery in the final report
5. A tester accidentally captures personal data of customers in the European Union in a log file during a test.
What is the best handling?
A. Keep the full log file as evidence for the report
B. Share the log file with the whole testing team for analysis
C. Minimize the data, delete what is not needed, notify the client contact, and handle it under the agreed
data rules
D. Publish the log file in the report appendix as evidence
6. What should the executive summary of a penetration test report contain?
A. Full exploit code for each finding
B. Every finding with raw scanner output
C. Packet captures for the top findings
D. Business risk, the top findings, and priority actions in plain language
7. During a testing window, CertCrack.com's security team calls about suspicious scanning from an unfamiliar
address, and the tester recognizes the activity as their own scan. What should the tester do first?
A. Use the agreed deconfliction contact and code word to confirm the activity is authorized testing
B. Stop the engagement and leave the client site
C. Deny any involvement in the scanning
D. Increase the scan speed to finish before the team reacts
8. After remediation, the client asks for a retest of a penetration test engagement. What should the retest cover?
A. A full new penetration test of every system in the organization
B. Verification of only the reported findings within the agreed window, reporting any residual risk
C. Only the critical findings, with the rest dropped silently
D. No retest is needed once the client states the fixes are done
Answer key: 1. C - 2. B - 3. D - 4. A - 5. C - 6. D - 7. A - 8. B
Engagement Toolkit: Scoping the Tools Before They Run
The main chapter covered authorization, scope, and the rules of engagement. This short toolkit section covers the part engagements get wrong most often in practice: the tools themselves are part of the scope. A technique that is not named — or not clearly permitted — in the signed rules of engagement is out of bounds, however harmless it looks, and several tool families in the later chapters are intrusive enough that they must be agreed in writing before they are switched on.
Tool authorization. Tool authorization. The rules of engagement should name the classes of tooling the client accepts: phishing platforms (Gophish, SET, Evilginx), rogue wireless equipment (WiFi-Pumpkin), cloud exploitation frameworks (Pacu), and self-propagating simulators (Infection Monkey). Each one touches people, production systems, or third parties in ways a port scan never does — which is why "we scanned you last year" is never a substitute for this year's written permission.
Verbal approval is not scope. Scenario questions love the moment a client contact says "go ahead and test the cloud too" in a hallway. The correct answer is always the same: stop, get the scope amendment in writing, then test. Tools such as Pacu run with stolen or granted cloud keys and can change real account state — the paperwork is part of the technique.
Scope before tooling. Question. Mid-engagement, a tester wants to add a Gophish phishing wave; the signed RoE covers network testing only and is silent on social engineering. May the wave be sent? Answer: No. Silence is not consent. Phishing people is a distinct technique class with its own risks and approvals; it needs a written amendment naming it before any email is sent.
The remaining toolkit sections sit inside the chapters where the tools are used: reconnaissance in Chapter 2, discovery in Chapter 3, attacks in Chapter 4, and post-exploitation in Chapter 5, with a full Tool Index at the end of the book.
Want the full CompTIA PenTest+ (PT0-003) package?
This guide is free to read. Get the full PT0-003 practice exam — 750 questions plus 10 PBQs — with the complete PDF and online access.
Get PT0-003 Full Access — $10