Penetration Test Types and Rules of Engagement

CompTIA Security+ SY0-701

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

Current Exam Facts and How Security+ Tests Judgment Domain Weighting and an 8-12 Week Study Plan Practice Questions, PBQs, and the Missed-Question Notebook

2 Domain 1: General Security Concepts (12%)

CIA and Non-Repudiation Control Types and Categories with Scenario Classification Security Principles: Least Privilege, Defense in Depth, Secure by Design, and Zero Trust Change Management and Business Impact

3 Domain 1: Identity, Trust, and Cryptography Basics

AAA and IAM Concepts Authentication Factors and MFA Traps Authorization Models: RBAC, ABAC, MAC, DAC, and Least Privilege Cryptography, Hashes, Signatures, PKI, and Certificate Decision Rules

4 Domain 2: Threat Actors, Vectors, and Social Engineering

Threat Actors and Motivations Attack Vectors and Attack Surface Social Engineering Types and Clues Supply Chain and Insider Threat Scenarios

5 Domain 2: Threats, Vulnerabilities, and Mitigations - Attacks

Malware Behaviors and Indicators Credential and Password Attacks Network and Wireless Attacks Application, API, and Cloud Attacks with Mitigation Mapping

6 Domain 2: Threats, Vulnerabilities, and Mitigations - Vulnerabilities

Vulnerability Types and Misconfiguration Vulnerability Scanning and Prioritization Secure Coding and Application Mitigations Remediation, Compensating Controls, and Risk-Based Decisions

7 Domain 3: Security Architecture - Secure Architecture Models

Architecture Models and Trust Boundaries Cloud Shared Responsibility and Service Models Zero Trust, SASE, and SSE Concepts Secure Design Review Scenarios

8 Domain 3: Security Architecture - Network Security Architecture

Segmentation, VLANs, DMZ, and Microsegmentation Firewalls, WAF, IDS, IPS, and Proxies VPN, Remote Access, and NAC Wireless Security and Enterprise Network Design

9 Domain 3 Part C: Data Protection and Resilience

Data Classification and Handling Encryption at Rest, in Transit, in Use, and Key Management DLP, Privacy, and the Data Lifecycle Backups, RTO, RPO, BCP, DR, and Resilience

10 Domain 4 Part A: Secure Operations for Hosts, Cloud, Mobile, and IoT

Endpoint and Server Hardening Cloud, Container, and Virtualization Operations Mobile, BYOD, and MDM Embedded, IoT, OT, and Physical Device Security

11 IAM Operations and Access Control

Provisioning, Deprovisioning, and Access Reviews PAM, JIT, JEA, and Service Accounts Federation, SSO, SAML, OIDC, and OAuth Account Attacks and IAM Monitoring

12 Logging, Monitoring, and Detection

Log Sources and Telemetry SIEM Correlation and Alert Triage SOAR, Playbooks, and Automation Detection Use Cases and False-Positive Handling

13 Incident Response

IR Phases and Roles Containment, Eradication, and Recovery Decisions Communication, Escalation, Legal, and Regulatory Considerations Post-Incident Lessons Learned and Metrics

14 Digital Forensics and Investigation

Evidence Handling and Chain of Custody Disk, Memory, Network, and Log Artifacts Order of Volatility and Acquisition Choices Forensic Reporting and Anti-Forensics Traps

15 Vulnerability, Patch, Asset, and Automation Operations

Asset Inventory and Data Classification in Ops Vulnerability Lifecycle and CVSS/Risk Priority Patch, Change, and Configuration Management Automation, Orchestration, SCAP, and Security Tooling

16 Governance, Policies, and Risk Management

Governance Documents: Policy, Standard, Procedure, and Baseline Risk Register and Risk Treatment Quantitative/Qualitative Risk and BIA Exceptions, Acceptance, Ownership, and Reporting

17 Third-Party Risk, Compliance, and Privacy

Vendor Risk Lifecycle and Agreements Due Diligence, Questionnaires, and Monitoring Privacy Concepts and Data Rights Compliance Reporting and Consequences

18 Audits, Penetration Testing, and Awareness

Internal and External Audits and Evidence Penetration Test Types and Rules of Engagement Security Awareness, Training, and Phishing Metrics Personnel and Physical Security Program Controls

19 Final Review and PBQ Labs

PBQ Workflow and Timing Ports, Protocols, and Acronyms High-Yield Tables Firewall, IAM, Log, and Risk PBQ Mini-Labs Final 7-Day Review Plan Mixed Exam Strategy and Missed-Question Remediation

Penetration Test Types and Rules of Engagement

Key Takeaways Explain This Topic AI

A penetration test validates exploitable risk under written authorization; it may chain findings and prove business impact, unlike a vulnerability scan that only identifies and rates weaknesses.

Black-box (unknown), gray-box (partial), and white-box (full knowledge) differ by how much information testers receive before the engagement.

Rules of engagement (ROE) define scope, timing, allowed/prohibited techniques, safety limits, contacts, and reporting expectations in writing.

Testing without written authorization can constitute unauthorized access and create legal, operational, and safety risk.

Reports must pair technical evidence and reproduction steps with severity, business impact, and remediation guidance, then verify fixes with a retest.

Last updated: June 2026

Pen Test vs Vulnerability Scan

A penetration test is an authorized, goal-oriented attempt to identify and validate exploitable weaknesses. It differs from a vulnerability scan , which only discovers and rates weaknesses without exploiting them. A pen test may chain several low findings into a high-impact compromise, test whether defenders detect the activity, and demonstrate concrete business impact. The objective is controlled proof, never uncontrolled disruption.

Security+ expects you to know the standard phases: planning/ROE , reconnaissance (passive open-source intelligence vs active scanning), scanning/enumeration , exploitation/gaining access , post-exploitation (lateral movement, privilege escalation, persistence), and reporting/cleanup . Cleanup matters legally and operationally: testers must remove any planted accounts, tools, shells, and persistence mechanisms so the engagement does not leave the environment more vulnerable than it found it.

Closely related but distinct exercises also appear on the exam. A red team simulates an adversary covertly over a longer campaign and is often goal-driven ("reach the customer database"). A blue team defends and detects. A purple team is a collaborative exercise where attackers and defenders share information in real time to improve detection. A bug bounty crowdsources external researchers under a published policy. Knowing which exercise fits a goal — covert adversary emulation versus broad coverage versus continuous external testing — is a common scenario question.

Knowledge and Environment Types

Type Tester knowledge Use case

Black-box (unknown) Little or no internal knowledge Simulate an external attacker; most realistic, least efficient

• Gray-box (partial) Some detail — a standard account or architecture summary Balance realism and coverage
• White-box (known) Full source, diagrams, credentials, configs Deepest coverage, fastest, least realistic
• Internal Starts inside the network or with internal access Validate lateral movement and segmentation
• External Targets internet-facing assets Validate perimeter and exposed services
• Web application Application logic and data handling Test authn, authz, input, session security
• Wireless Wi-Fi networks Test encryption, rogue APs, segmentation

Reconnaissance splits into passive (WHOIS, public records, social media, certificate transparency logs — no packets to the target) and active (port scans, banner grabbing, service fingerprinting — detectable on the target). Black-box tests rely heavily on recon to build a picture of the attack surface; white-box tests skip much of it because the information is provided up front.

The trade-off is realism versus efficiency: black-box best simulates a real outsider but spends budget rediscovering facts a white-box tester already has, while white-box maximizes coverage of the actual codebase and configuration at the cost of attacker realism. Gray-box is the common compromise, mirroring an attacker who already phished one standard user account.

Rules of Engagement

Rules of engagement (ROE) set the boundaries that protect the organization, testers, customers, and production systems. Supporting agreements you should recognize include the statement of work (SOW) , master service agreement (MSA) , and non-disclosure agreement (NDA) . Common ROE elements:

Written authorization and the approving authority.

In-scope and explicitly out-of-scope systems and IP ranges.

Testing dates, time windows, and blackout periods.

Allowed and prohibited techniques.

Social engineering and phishing permissions or restrictions.

Data handling for captured credentials and files.

Safety limits for denial-of-service, destructive actions, and persistence.

Emergency contacts and a stop-test ("abort") procedure.

Evidence, report format, and remediation-meeting expectations.

The ROE should also define a deconfliction process so that real attacks during the test window are not mistaken for the testers, and vice versa. A get-out-of-jail-letter (signed authorization the tester carries) protects on-site personnel performing physical social engineering. Without these agreements, attempting access can violate computer-misuse and trespass laws regardless of intent.

Scenario

A regional bank hires a firm to assess its online loan portal. The ROE permits authentication, authorization, input-validation, and session testing, plus controlled exploitation in staging . Production is limited to non-destructive validation during a weekend window. Denial-of-service, customer-account modification, and persistence are prohibited, and testers must call the security operations bridge before each window.

During testing the team finds that an authenticated user can change a numeric account parameter and view another applicant's income document — an insecure direct object reference / broken object-level authorization. The report includes the affected endpoint, proof using test accounts, business impact, reproduction steps, log timestamps, and remediation to enforce object-level authorization checks server-side.

Reporting, Retesting, and Common Traps

A useful report includes an executive summary, scope and methodology, per-finding severity and business impact, technical evidence and reproduction steps, the exploitation chain, affected assets, remediation recommendations, and retest results after fixes. Severity often uses CVSS (Common Vulnerability Scoring System) scores mapped to business context — a critical CVSS finding on an isolated lab box may rate lower in business terms than a medium finding on an internet-facing payment system.

The executive summary is written for non-technical leadership and focuses on risk and required investment, while the technical body gives engineers enough detail to reproduce and fix each issue. After remediation, the retest (sometimes called validation testing) confirms the fix actually closed the issue rather than merely hiding the symptom, and closes the engagement loop.

Running tests without written authorization.

Performing destructive production actions without approval.

Confusing a vulnerability scan with a penetration test.

Reporting jargon with no business impact.

Omitting data-handling rules for captured secrets.

Letting scope creep happen informally mid-engagement.