Reference
Penetration Testing Glossary: 60 Terms Defined
Plain, quotable definitions of the terms people meet in penetration test scopes, reports, retests and schemes, grouped so you can point a client at the one they asked about.
Penetration testing carries a lot of vocabulary, and much of it is used loosely. The definitions below are the ones that matter in a scope, a report, a retest or an accreditation, written to be short enough to quote to a client. They are grouped by where you meet them, so you can send someone straight to the right set.
Engagement and scope
The terms that decide what is tested, when, and with whose permission, before any testing starts.
| Term | Meaning |
|---|---|
| Penetration test | An authorised, goal-directed assessment that attempts to find and safely demonstrate security weaknesses in a defined set of systems, so they can be fixed before a real attacker reaches them. |
| Scope | The exact set of systems, applications, addresses and activities a test is permitted to cover. Anything not named is out of scope and must not be touched. |
| Rules of engagement | The operational agreement for how a test is run: testing windows, permitted and prohibited actions, contacts, escalation and the conditions that stop testing. See the rules of engagement guide. |
| Statement of work | The document that defines what will be delivered: scope, approach, timing, deliverables, assumptions and commercial terms. It is the agreement the engagement is measured against. |
| Authorisation letter | A signed statement from someone able to give it, confirming the client permits the named testing of the named systems. In the UK it is what keeps testing on the right side of the Computer Misuse Act. |
| Engagement letter | A short agreement appointing the firm for a piece of work, often alongside or in place of a fuller statement of work for a small engagement. |
| Scoping questionnaire | The set of questions a client answers so the firm can size and plan the work: counts, technologies, environments, access and constraints. |
| Scope creep | The gradual expansion of what is tested beyond what was agreed, without a matching change to time or terms. It is managed by writing changes down rather than absorbing them. |
| Testing window | The agreed dates and times during which active testing may take place, sometimes restricted to out-of-hours for production systems. |
| Stop condition | A pre-agreed trigger that pauses or halts testing, such as evidence of a prior compromise, a system becoming unstable, or a critical finding that must be reported at once. |
| Phase | A distinct block of an engagement with its own type, scope, test days and checklist, such as an external phase followed by an internal one. |
| Lead tester | The person accountable for an engagement's delivery and for the conduct of testing, usually the client's main point of contact during the work. |
| Kick-off call | The call at the start of an engagement that confirms scope, access, contacts and timing before testing begins. |
| Debrief | The call after testing where the firm walks the client through what was found and what matters most, ahead of or alongside the written report. |
Testing approaches
How much the tester is told and what posture they take. These describe method, not quality: a good test can run under any of them.
| Term | Meaning |
|---|---|
| Black box | Testing with no prior knowledge of the target beyond what is in scope, approximating an external attacker starting from nothing. |
| Grey box | Testing with some information or a standard user account, which spends less time on reconnaissance and more on depth. The usual choice for most engagements. |
| White box | Testing with full information, such as documentation, configurations or source, for the most thorough coverage in the time available. |
| Assumed breach | Testing that starts from the position of an attacker who already has a foothold, such as a standard account or a workstation, to see how far that goes. |
| Red team | An objective-led exercise that tests detection and response as much as technical weakness, usually broad in scope and quiet by design. |
| Blue team | The defenders: the people and systems responsible for detecting and responding to attacks. |
| Purple team | Red and blue working together, so detections are improved in real time as the attacker demonstrates each technique. |
| External test | An assessment of internet-facing systems from outside the network perimeter. |
| Internal test | An assessment from inside the network, often modelling a compromised device or a malicious insider, where Active Directory weaknesses tend to surface. |
| Configuration review | A structured check of a system's settings against a hardening standard, which complements a test rather than replacing it. |
| Vulnerability assessment | A broad identification of known weaknesses using automated tools and review, without the manual exploitation and chaining that define a penetration test. |
| Social engineering | Testing that targets people rather than systems, such as phishing, to assess human and procedural defences. It is only ever done with explicit authorisation. |
| Authenticated testing | Testing performed while logged in with supplied credentials, to reach the functionality and flaws that only appear behind a login. |
Findings and severity
The vocabulary of what you found and how serious it is. Precision here is what keeps a report from turning into an argument about numbers.
| Term | Meaning |
|---|---|
| Finding | A single reported issue: a weakness, where it is, what it allows, how serious it is, and how to fix it. |
| Vulnerability | A weakness in a system that an attacker can use to act against the system's security. A finding usually documents one. |
| CVSS | The Common Vulnerability Scoring System, maintained by FIRST, which produces a 0 to 10 score for a weakness from a set of metrics. Firms rate in version 3.1 or 4.0. |
| CVSS vector | The string of metric values a CVSS score is calculated from, such as the attack vector and the impacts. The score must always match the vector, with worked examples here. |
| CVSS-BTE | CVSS 4.0's nomenclature for a score that uses all three metric groups: Base, Threat and Environmental. Base only is CVSS-B, and most reports publish the base score. |
| Severity | A finding's rating on a fixed scale, usually critical, high, medium, low and informational, derived from a score and the firm's own severity levels. |
| Risk | The business consequence of a weakness in a particular environment, combining severity with exposure and value. Severity is a property of the finding; risk depends on the client. |
| Likelihood and impact | The two axes most risk ratings combine: how probable exploitation is, and how bad the result would be. |
| False positive | A reported issue that is not actually a weakness. Manual verification exists to keep these out of a report. |
| False negative | A real weakness that testing missed. Depth, coverage and good checklists are how a firm keeps these rare. |
| CWE | The Common Weakness Enumeration, a catalogue of software weakness types, used to classify the underlying cause of a finding. |
| CVE | A Common Vulnerabilities and Exposures identifier, a public reference for a specific known flaw in a specific product. |
| Evidence | The proof that a finding is real and exploitable, such as captured output or a reproduction, kept so a reviewer or client can verify it. |
| OWASP Top 10 | An awareness list of the most critical web application risks, revised periodically, used to group findings for a reader rather than as a test plan. |
Reporting and QA
The document and the checks it passes through before a client sees it.
| Term | Meaning |
|---|---|
| Report | The deliverable that records what was tested, what was found, how serious each finding is and how to fix it, written for both technical and non-technical readers. |
| Executive summary | The part of the report written for decision-makers: the overall picture, the themes and what to do first, in plain terms. Often the only part that reaches a board. |
| Methodology | The section that states how the test was run, what standards it followed and what the scope and limitations were, so the result can be understood and repeated. |
| Technical finding | The detailed write-up of a single issue, with its description, evidence, severity, affected assets and remediation. |
| Reproduction steps | The record of how a finding was demonstrated, at the level a competent reader needs to confirm it, kept proportionate and safe. |
| Business impact | The sentence or paragraph that translates a technical weakness into a consequence the client's business cares about. |
| QA review | The quality check a report passes before delivery, where a reviewer comments, suggests or applies changes, and either returns it to the tester or approves it. |
| Peer review | Review of one tester's work by another, to catch errors, weak scoring and unclear writing before a client does. |
| Redaction | Removing or masking sensitive detail, such as captured credentials, from a report before it is shared more widely. |
| Sign-off | The point at which a report is approved as fit to deliver, by whoever the firm makes accountable for quality. |
Delivery, remediation and retest
What happens once the report exists: how it reaches the client, how fixes are tracked, and how they are verified.
| Term | Meaning |
|---|---|
| Delivery | The act of releasing a report and its findings to the client, ideally through a controlled channel rather than an email attachment that cannot be recalled or tracked. |
| Client portal | A secure area where a client sees what has been released to them, downloads reports, tracks remediation and requests retests. A white-labelled portal carries the firm's brand, not the platform's. |
| Remediation | The work of fixing a finding, and the advice in the report that tells the client what to change, in terms the person fixing it can act on. |
| Retest | A focused re-assessment that checks whether reported findings have been fixed, ending each in a clear state. It verifies the underlying weakness, not just that the original proof no longer works. |
| Retest states | The outcome a retest assigns each finding, typically fixed, partially fixed or open, defined before testing so the result is not ambiguous. |
| Remediation timeline | The time a client is expected to take to fix a finding, usually set by severity and sometimes required by a standard or regulation. |
| Residual risk | The risk that remains after remediation and any compensating controls, which a client knowingly carries. |
| Risk acceptance | A client's documented decision to live with a finding rather than fix it, with the reasoning and the approver recorded. |
| Compensating control | A measure that reduces the risk of a weakness without removing the weakness itself, such as restricting access to a system that cannot yet be patched. |
| Attestation letter | A short, signed statement that a named engagement was carried out and summarising its outcome, produced for a client to show an auditor or their own customers. |
| PTaaS | Penetration testing as a service: testing delivered as an ongoing, subscription-style relationship with continuous visibility and retests, rather than one report a year. More in PTaaS for testing firms. |
| White-labelling | Delivering the portal, reports and communications under the firm's own brand and domain, so a client deals with the firm and never sees the underlying platform. |
Schemes and standards
The accreditations, methodologies and regulations that shape how UK and EU firms test and report. Definitions here are kept general; the detail of each belongs to its own source.
| Term | Meaning |
|---|---|
| CREST | An international accreditation body for technical security. CREST accredits member companies against a standard and certifies individuals, and many buyers treat it as a baseline. |
| CHECK | The NCSC scheme under which approved companies test systems important to UK government. CHECK work must be led by suitably qualified and cleared people. |
| NCSC | The UK National Cyber Security Centre, which runs CHECK and publishes much of the guidance UK firms follow. |
| FIRST | The Forum of Incident Response and Security Teams, which maintains CVSS among other standards. |
| OWASP WSTG | The OWASP Web Security Testing Guide, a detailed methodology of web application tests, often used as the backbone of a web testing checklist. |
| MASVS | The OWASP Mobile Application Security Verification Standard, the reference used to structure mobile application testing. |
| TLPT | Threat-led penetration testing: testing driven by realistic threat intelligence about a specific organisation, used in the most demanding regulatory schemes. |
| TIBER-EU | A European framework for threat-led red team testing of financial entities, run with regulators and threat intelligence. |
| CBEST | The Bank of England's framework for intelligence-led testing of the UK's most significant financial institutions. |
| DORA | The EU Digital Operational Resilience Act, which sets testing and resilience obligations on financial entities, including threat-led testing for the most significant ones. |
| PCI DSS | The Payment Card Industry Data Security Standard, which requires regular penetration testing of systems in scope for cardholder data. |
| ISO 27001 | An international standard for an information security management system, where testing supports the controls an organisation claims. |
| Cyber Essentials | A UK government-backed scheme of baseline security controls, with a Plus variant that includes hands-on verification. |
| Computer Misuse Act | The UK law that makes unauthorised access to computer systems an offence, which is why written authorisation is the foundation of any UK test. This is not legal advice; have your own terms reviewed by a solicitor. |
Penetration testing severity levelsHow a score becomes a rating your whole team applies the same way.Read the guide CVSS 4.0 examplesFull vectors and reasoning for fifteen common findings.Read the guide The whole engagement in one placeScoped phases, scored findings, QA and a branded portal, in Pental.Read the guide
See the Terms in Context
Pental runs the whole engagement, from scoped phases and scored findings to QA and a client portal for delivery, retests and remediation, so the terms below map onto real screens.
Also Worth Reading
Reference
How to Write a Penetration Test Report, Step by Step
The process from first note to delivery: set the report up before testing, write findings as you confirm them, score severity with reasons, write the summary last, and QA everything before it leaves.
ReferencePenetration Testing Severity Levels and Risk Rating Matrix
Critical, high, medium, low and informational defined in one table and mapped to CVSS 4.0, with a likelihood and impact matrix for findings CVSS does not fit, and the habits that keep testers consistent.
ReferenceCVSS 4.0 Examples: 15 Common Pentest Findings Scored
Fifteen findings you raise in almost every test, each scored in CVSS 4.0 with a full vector and the reasoning behind it, set beside its 3.1 score so you can see exactly where the two versions part company.
Setup guide
Prefer to watch it?
The whole setup recorded, with chapters you can jump to: registering, your own domain, your own database in any of three places, your own mail server, branding, the first sign-in, updating the database on Supabase Cloud, and moving the database if you change your mind.
- 0:00 · Registering, signing in, and the free trial
- 0:51 · Your name and your firm’s name
- 0:57 · Custom domain
- +6 more