What Penetration Testing Is and Why It Differs from Vulnerability Scanning
Penetration testing is the process of simulating a real attack against an organization's own systems to determine whether an attacker could gain access, and if so, how far they could go. Unlike vulnerability scanning — which identifies potential weaknesses without exploiting them — penetration testing performs actual exploitation. The tester attempts the same techniques an attacker would use: buffer overflows, password brute-force attacks, social engineering, database injection, credential reuse, and lateral movement through the internal network. If the tester can do it, a real attacker can too.
This is why penetration testing carries operational risk that vulnerability scanning does not. The same buffer overflow that demonstrates a privilege escalation vulnerability can also crash the operating system. The same credential-guessing campaign that finds a weak password can also lock out legitimate users. Penetration testing is valuable precisely because it reflects the real impact of real attacks — but that fidelity requires careful preparation to ensure that testing activity does not cause uncontrolled harm to production systems. That preparation is the rules of engagement.
Rules of Engagement — The Formal Document That Defines Everything
Before any penetration testing begins, the rules of engagement must be established and documented. This is a formal written agreement that defines the scope, constraints, and procedures of the engagement. It exists to protect both the testing team (who need legal authorization to perform what would otherwise be illegal activity) and the organization (who need assurance that critical systems will not be disrupted). Every element of the rules of engagement is negotiated and agreed upon before the first probe is launched.
Type and timing of testing. The rules of engagement specify what kinds of tests are permitted: external testing from the internet, internal testing from inside the network, physical testing (attempting to breach physical security controls such as badge readers and door locks), or social engineering (phishing, pretexting). They also specify when testing is permitted — many organizations restrict penetration testing to off-hours (after 6:00 PM, weekends) to reduce the risk of disrupting business operations during the workday.
Scope: in-scope and out-of-scope systems. The rules of engagement must explicitly define which systems may be tested. In-scope systems are typically defined by IP address ranges, domain names, or application names. Out-of-scope systems are explicitly excluded — often because they are production-critical, belong to third parties, or are shared infrastructure whose disruption would affect parties outside the engagement. A penetration tester who touches an out-of-scope system, even accidentally, has violated the rules of engagement and potentially committed unauthorized access.
Emergency contacts and sensitive data handling. The rules of engagement must list emergency contact information for the testing team and the organization's key personnel, so that either party can halt testing immediately if something goes wrong — a critical system becomes unstable, a real security incident occurs during the test window, or the organization needs to pause for operational reasons. If the testing team discovers sensitive data — credentials, PII, financial records — during the engagement, the rules of engagement define exactly how that data must be handled, stored, and eventually destroyed. Sensitive data discovered during a pen test is real sensitive data; its mishandling is a real liability.
Why Rules of Engagement Exist — The Legal and Operational Reality
Without rules of engagement, a penetration tester performing their job is legally indistinguishable from an attacker. The technical activity is identical: probing systems for vulnerabilities, attempting unauthorized access, extracting data. The difference is authorization, and authorization is only as solid as the documentation that establishes it. A verbal agreement is not sufficient. A general statement that "we'd like you to test our security" is not sufficient. The rules of engagement must be specific, written, and signed by authorized representatives of the organization before any testing begins.
Operationally, rules of engagement ensure that the testing team knows exactly which systems they may attack, which techniques are permitted, and what to do when something unexpected happens. A well-defined engagement prevents the common failure modes of penetration testing: taking down a production system that was intended to be out of scope; discovering that the "test" environment shares backend services with production; causing a real security incident that the organization's SOC initially treats as an actual attack (requiring coordination between the testing team and the organization's security operations to prevent an unnecessary incident response). The rules of engagement are the mechanism that keeps authorized testing from becoming an unauthorized incident.
Phase 1: Initial Exploitation — Getting the First Foothold
Initial exploitation is the first phase: the tester attempts to breach the perimeter and establish the first foothold inside the target environment. This is typically the most technically challenging phase because organizations concentrate their security investment at the boundary — firewalls, intrusion detection, email filtering, endpoint protection. The tester must find a weakness in that perimeter protection: a vulnerable internet-facing service, an exploitable application, a successful phishing email that delivers a payload, a weak credential that grants VPN access, or a physical entry through an unsecured door or social engineering of reception staff.
The techniques available to the tester during initial exploitation span from highly technical (exploiting a buffer overflow in a network service) to entirely non-technical (calling an employee and convincing them to reveal their password). Database injection, password brute force against exposed login pages, exploitation of unpatched remote services, and phishing campaigns are all common initial exploitation vectors. The key outcome of this phase is access — a shell, a session, or a position inside the network from which subsequent phases can proceed. If the tester cannot achieve initial exploitation, the engagement ends here with a report that the perimeter security is holding.
Phase 2: Lateral Movement — Expanding Access Inside the Network
Once the tester has a foothold, they begin lateral movement: using the initial access point to reach additional systems within the internal network. This phase exploits a fundamental reality of most organizational networks: the internal network is significantly less protected than the perimeter. Firewalls and detection systems focus on external traffic; traffic between internal systems is often trusted implicitly. An attacker inside the network can frequently reach servers, databases, and workstations that are completely inaccessible from the internet.
Lateral movement techniques include: stealing credentials from the compromised system's memory (using tools like Mimikatz against Windows systems); pass-the-hash attacks reusing captured password hashes; exploiting shared folders and network drives accessible without additional authentication; leveraging remote management tools (RDP, WinRM, SSH) with stolen credentials; and exploiting vulnerable services that are only accessible from inside the network. The tester maps the network progressively, identifying high-value targets: domain controllers, database servers, backup systems, and systems holding sensitive data.
Lateral movement is the phase that most starkly demonstrates the inadequacy of perimeter-only security. An organization that stops an attacker at the perimeter has won. An organization whose perimeter is breached and whose internal network allows free lateral movement has lost access to everything once the first system is compromised. Segmentation, least-privilege access controls, and internal monitoring are the defenses that limit lateral movement; their absence is what the tester exposes.
Phase 3: Persistence — Ensuring a Way Back In
After gaining access to valuable systems, an attacker — and a penetration tester simulating one — establishes persistence: mechanisms that ensure continued access to the environment even if the original vulnerability is patched, the original session is terminated, or the initial access point is discovered and closed.
Common persistence techniques demonstrated during penetration tests include: creating unauthorized administrative accounts on compromised systems; adding backdoor credentials to existing accounts; modifying default passwords that the organization failed to change; installing software that automatically reconnects to attacker-controlled infrastructure (a remote access trojan or a scheduled task that reaches out to a command-and-control server); and modifying startup services so that the backdoor survives reboots. The diversity of persistence mechanisms reflects the attacker's strategy: if any single access path is detected and removed, the remaining paths continue to provide access.
From a defensive perspective, this phase tests whether the organization can detect unauthorized changes to its systems. Account creation, service modification, and new startup entries are all events that generate logs — if those logs are being monitored and alerted on, the persistence mechanisms will be detected. If they are not, the organization has given an attacker a durable position in the network that survives patching.
Phase 4: The Pivot — Using Compromise to Reach the Unreachable
Pivoting uses a compromised system as a proxy or relay to reach other systems that would otherwise be inaccessible. The pivoting system sits in a network position that the attacker cannot access directly — it may be on an isolated internal segment, behind an additional firewall, or on a network that has no direct routing to the internet. By routing attack traffic through the compromised intermediary, the tester can reach systems that were architecturally designed to be unreachable from the attacker's position.
A typical pivot scenario: a tester compromises an internet-facing web server. That web server sits in a DMZ with limited routing to the internal corporate network. But the web server has a database connection to an internal database server — a connection required for the application to function. The tester routes their database exploitation attempts through the compromised web server, reaching the database server via the legitimate connection path. From the database server, additional lateral movement and further pivots reach the internal domain controller. A single compromised public-facing system has provided a path to the organization's core identity infrastructure.
The pivot demonstrates why network segmentation must be genuinely restrictive, not merely conceptual. If the web server's database connection allows arbitrary queries rather than only the queries needed for the application, it becomes a pivot path. If the database server has excessive network access to other internal systems, the pivot extends further. Every trust relationship and network permission that is not strictly necessary becomes a potential pivot path for an attacker who has breached the first layer.
Why Vulnerability Remediation Takes Time
When a security researcher discovers a vulnerability in a software product, the instinct might be to publish the finding immediately — to warn users as quickly as possible. The problem is that publishing the vulnerability before a fix is available tells attackers exactly what to exploit, while giving defenders nothing to defend with. Patches are not instant. Fixing a software vulnerability requires: identifying the root cause in the codebase, developing and testing a fix that closes the vulnerability without introducing new bugs or regressions, building the fix into a new software version, testing that version across supported configurations, and distributing the patched version to every user. This process takes weeks to months. During that entire window, if the vulnerability is public, it is being actively exploited against unpatched systems.
Responsible disclosure programs exist to manage this window: keeping the vulnerability private while the fix is developed, then publishing both the vulnerability details and the patch simultaneously, so users can protect themselves immediately upon learning of the risk.
Bug Bounty Programs — Incentivizing Responsible Research
Bug bounty programs are formal programs run by software vendors and organizations that offer financial rewards to security researchers who discover and responsibly disclose vulnerabilities. The premise is straightforward: there are more security researchers in the world than any single organization could employ internally; by paying external researchers for valid findings, the organization taps a global talent pool that continuously tests its products at scale.
To receive a bug bounty payment, researchers must: find a valid vulnerability within the defined scope of the program; document it clearly, including steps to reproduce, proof of concept demonstrating the impact, and an assessment of severity; report it privately to the vendor through the defined submission channel; and refrain from exploiting the vulnerability beyond what is necessary to demonstrate its existence, disclosing it to third parties, or publishing it before the vendor has had time to develop a fix. In exchange, the vendor investigates the submission, develops a patch, and pays the bounty when the vulnerability is confirmed. Major technology companies — Google, Microsoft, Meta, Apple — run active bug bounty programs that have paid researchers millions of dollars and significantly improved the security of widely used products.
The Controlled Information Release Process
Responsible disclosure follows a defined sequence that the Security+ exam tests directly. The four steps in order:
Step 1 — Researcher reports the vulnerability privately. The researcher contacts the vendor or organization directly, through a security disclosure contact or bug bounty platform, and provides the vulnerability details under confidentiality. No public disclosure occurs at this point.
Step 2 — Manufacturer investigates and creates a fix. The vendor's security team reproduces the issue, identifies the root cause, and develops a patch. The researcher may be consulted for additional clarification. A timeline for the fix is often communicated to the researcher. The standard expectation in the industry is that the vendor will have a patch ready within 90 days of the initial report — a window that most major vendors use as a coordination deadline.
Step 3 — The vulnerability is announced publicly alongside the fix. Once the patch is ready and distributed, the vendor publishes a security advisory describing the vulnerability. A CVE (Common Vulnerabilities and Exposures) identifier is assigned. The researcher is typically credited for the discovery. Users can now apply the patch, knowing what it fixes.
This coordinated process protects the users who run the vulnerable software — they can patch before attackers learn the details. It protects the vendor — they can fix the issue before being publicly exposed. And it protects the researcher — they receive credit and, in bug bounty programs, compensation, without legal jeopardy from having reported a security issue.