Penetration Testing Communication Exercises

A Rules of Engagement document formally authorises a penetration test and defines its boundaries. Standard language includes "the scope of this engagement is limited to the following IP ranges," "out-of-scope systems must not be tested under any circumstances," "testing is authorised between the hours of [X] and [Y]," and "the tester must cease all activity and notify the client immediately upon discovery of a live incident." The RoE is a legal document and its language must be precise — ambiguity about scope can lead to unauthorised access claims.

CVSS (Common Vulnerability Scoring System) assigns a numerical score from 0 to 10 to a vulnerability. When communicating scores, penetration testers use language like "this vulnerability scores 9.8 (Critical) on the CVSS v3.1 scale," "the high attack complexity reduces the score from Critical to High," and "the confidentiality impact is rated High because an attacker could exfiltrate all user credentials." For executives, scores are translated to business risk: "a CVSS 9.8 means this is trivially exploitable from the internet with no authentication required."

An executive summary uses non-technical language to convey overall risk posture. Standard phrases include "the assessment identified X critical, Y high, Z medium, and W low-severity findings," "the organisation's external attack surface presents significant risk to customer data," and "key findings include unauthenticated remote code execution and a lack of network segmentation." The executive summary avoids jargon and connects findings to business impact: "exploitation of the critical finding could result in full compromise of the production environment and regulatory penalties under GDPR."

Vulnerability severity levels are typically classified as Critical, High, Medium, Low, and Informational. Each level uses defined language in reports: Critical means "immediate remediation required — exploitation is likely imminent," High means "remediate within 30 days," Medium means "remediate within 90 days," and Low/Informational items are addressed in the next scheduled maintenance window. The classification considers factors like exploitability, attack vector (Network/Adjacent/Local/Physical), privileges required, and potential business impact.

A vulnerability disclosure statement communicates the existence of a vulnerability to the affected vendor or public, following responsible disclosure principles. Language includes "we identified this vulnerability on [date] during authorised security testing," "the vendor was notified on [date] and given 90 days to remediate before public disclosure," "a CVE identifier (CVE-YYYY-NNNNN) has been assigned," and "users are advised to apply the patch immediately." Coordinated Vulnerability Disclosure (CVD) language balances transparency with responsibility to protect users while giving vendors time to remediate.

Scoping language includes "what assets are included in scope?", "are there any systems that are explicitly out of scope?", "is social engineering within the scope of this engagement?", "will this be a black-box, grey-box, or white-box test?", "what is the target environment — production, staging, or both?", and "are there any third-party dependencies we should be aware of?" A scoping call or statement of work uses this vocabulary to ensure both parties share a common understanding before testing begins, preventing disputes about what was and was not authorised.

A technical finding follows a standard structure: title, severity, CVSS score, description, affected systems, evidence (screenshots, request/response logs), proof of concept, business impact, and remediation recommendation. Language examples: "The application fails to validate user-supplied input in the username parameter, allowing an attacker to inject SQL commands (CWE-89)." Evidence sections use phrases like "the following HTTP request demonstrates the vulnerability" and "the server responded with database error output, confirming the injection." Recommendations use imperative language: "Implement parameterised queries for all database interactions."

A vulnerability is a weakness in a system — for example, "the application uses an outdated version of OpenSSL containing a known memory corruption vulnerability." An exploit is the mechanism used to leverage that vulnerability — "the tester used a public exploit (Metasploit module ms17-010) to achieve remote code execution." Pentest reports use both terms precisely: identifying vulnerabilities is the assessment output, while exploitation demonstrates impact. The phrase "proof of concept (PoC) exploit" refers to code demonstrating exploitability without causing damage, distinct from a fully weaponised exploit.

Remediation tracking vocabulary includes "open," "in remediation," "remediated — pending verification," and "accepted risk." In follow-up engagements, pentesters use phrases like "the critical finding from the original assessment has been successfully remediated," "the patch was applied but the underlying misconfiguration persists," and "we verified remediation by retesting the original proof of concept — the attack is no longer successful." Remediation guidance uses language like "apply vendor patch KB5004945," "enforce TLS 1.2 or above," and "disable directory listing on all web server virtual hosts."

Attack surface refers to all the points where an attacker could attempt to enter or extract data from an environment. In security assessments, testers discuss it with phrases like "the external attack surface includes 14 publicly accessible hosts," "reducing the attack surface by disabling unused services," and "the attack surface expanded significantly after the cloud migration." Related vocabulary includes "attack vector" (the path used — network, physical, social), "exposure" (the degree to which a system is visible to attackers), and "attack surface reduction" as a defensive strategy. Mapping the attack surface is typically the first phase of a penetration test.