CAP-PL ENS key terms

A written agreement that defines which systems, networks, and techniques a penetration test may target, plus timing and limits. Testing anything outside it is unauthorized, even if technically possible.

Operational constraints agreed before testing: allowed hours, prohibited techniques such as social engineering or denial of service, escalation contacts, and how findings are reported. They translate business expectations into concrete tester behavior.

A signed document, carried during testing, that proves the client's owners consented to the activity and names the tester. It is the first artifact shown if law enforcement or a network defender challenges the engagement.

Informal name for the authorization document a tester can produce mid-engagement to demonstrate permission. It should identify the client, the tester, the scope, and a contact who can confirm the engagement immediately.

The process of distinguishing tester traffic and activity from real attacker activity so defenders do not waste effort or escalate wrongly. It usually relies on shared source IP lists, test windows, and a named point of contact.

The client-side defender who knows the test is happening and coordinates with the tester. They confirm whether an alert came from testing, approve scope changes, and help stop the engagement if something breaks.

Any asset not explicitly listed in the scope, including third-party hosted services and production databases. Accidentally touching one is a reportable incident, not a minor slip, and should be disclosed immediately.

The limit between systems the client owns and systems a cloud or hosting provider controls. Testing provider infrastructure usually requires the provider's own permission, separate from the client's authorization.

An assessment where the tester receives no internal information such as credentials, source code, or architecture diagrams. It simulates an external attacker and often misses deep logic flaws that insiders could find faster.

An assessment where the tester has full information, including source code, credentials, and design documents. It finds more issues per hour but does not reflect what an unauthenticated attacker could realistically reach.

An assessment that gives the tester partial knowledge, such as a standard user account or a network diagram but not administrator access. It balances realism against efficiency and is common for internal network tests.

A testing scenario that starts with the tester already holding a foothold, such as a low-privilege account or a compromised workstation. It measures detection and lateral movement rather than initial perimeter defense.

A goal-oriented, stealthy engagement that emulates a real adversary against people, process, and technology over weeks. Success is measured by whether agreed objectives are reached without detection, not by the count of vulnerabilities.

A collaborative activity where offensive and defensive teams work together in real time, running an attack and tuning detections as it happens. The output is improved monitoring coverage rather than a standalone vulnerability list.

An engagement structured around concrete goals, such as reading a specific finance database or obtaining domain administrator rights. It focuses effort on business impact instead of enumerating every possible weakness.

A systematic scan and review that identifies and ranks known weaknesses without necessarily exploiting them. It produces a prioritized inventory, whereas a penetration test demonstrates whether weaknesses can actually be chained.

An authorized, simulated attack that exploits weaknesses to demonstrate real business impact, often chaining multiple issues. It differs from scanning by proving exploitability and documenting reproducible steps.

The step of manually confirming that a scanner finding is genuinely exploitable before reporting it. Unvalidated output wastes client remediation effort and damages the credibility of the whole report.

A minimal, safe demonstration that a vulnerability is real, such as a request and response pair or a screenshot of retrieved data. It should be reproducible by the client without further tester involvement.

The ordered instructions in a report that let a defender recreate a finding exactly, including prerequisites, payloads, and expected output. Clear steps turn a claim into something the client can verify and fix.

A sequence of linked weaknesses where each step enables the next, such as leaked credentials leading to a misconfiguration and then privilege escalation. Reporting the chain shows impact that individual findings hide.

Gaining rights beyond those initially granted, either vertically to administrator or root, or horizontally to another user's account. It is usually the pivot that turns a minor foothold into domain-wide compromise.

Moving from one compromised host to other systems using stolen credentials, trust relationships, or remote execution. It demonstrates how far an attacker could spread once inside the perimeter.

Any mechanism that lets an attacker retain access after reboots or credential changes, such as scheduled tasks, services, or added accounts. Testers document it to show detection gaps, then remove it during cleanup.

Removing tools, accounts, scheduled tasks, and configuration changes created during testing, and restoring original state. Skipping it leaves the client less secure than before the engagement and can void the authorization's intent.

The final phase where artifacts are removed, evidence is securely transferred, access is revoked, and a debrief is held. It confirms the client's environment is back to baseline and that report obligations are met.

A short narrative explaining what a finding would let a real attacker do to the business, in terms of data, money, or operations. It converts technical detail into language executives can prioritize.

A score combining likelihood and impact, often using a standard such as CVSS together with business context. The rating should reflect exploitability in the client's environment, not only the raw scanner score.

Specific, actionable advice on how to fix a finding, including configuration changes, patches, or compensating controls. Good guidance names the owner and a realistic verification method, not just a generic instruction to patch.

A follow-up engagement or check that verifies whether previously reported findings were actually fixed. It is scoped separately and should use the original reproduction steps to confirm the fix holds.

The opening section of a report written for non-technical leadership, covering overall posture, key risks, and strategic recommendations. It should stand alone and avoid jargon, payloads, and vulnerability identifiers.

Building and tuning monitoring rules so that specific attacker behaviors generate reliable alerts. In advisory work it often follows a test, using observed techniques to close gaps in logging and alerting.

Manual or tool-assisted inspection of application code to find flaws such as injection, unsafe deserialization, or broken access control. It complements dynamic testing by revealing issues that are hard to trigger at runtime.

A documented code-level weakness with the affected file, line, data flow, and a suggested fix. It must be specific enough that a developer can locate and correct the issue without asking the tester.

Work focused on guidance rather than exploitation, such as architecture review, control maturity assessment, or remediation planning. Deliverables are recommendations and roadmaps, not proof-of-concept exploits.

Terms describing how test data, including captured credentials and sensitive records, is stored, encrypted, transmitted, and destroyed. It limits the tester's liability and satisfies the client's regulatory obligations.

A limit that prevents accidental damage, such as avoiding destructive payloads, rate-limiting requests, or excluding fragile legacy systems. It must be agreed in advance because some exploits can crash production services.

The distinction between a technical severity score and how much the affected system matters to the business. A medium flaw on a payment gateway may outrank a critical flaw on an isolated lab host.