> For the complete documentation index, see [llms.txt](https://reaper.gitbook.io/my-penetration-test-guide/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://reaper.gitbook.io/my-penetration-test-guide/getting-started/publish-your-docs.md).

# Introduction to Penetration Testing

Penetration testing is an authorized security assessment that identifies, validates, and explains real security weaknesses.

The goal is not only to find vulnerabilities.

The goal is to understand what an attacker could realistically do, how far the issue can go, and what the organization should fix first.

Penetration testing usually includes:

* Reconnaissance.
* Enumeration.
* Vulnerability discovery.
* Manual validation.
* Controlled exploitation.
* Evidence collection.
* Risk explanation.
* Remediation guidance.
* Reporting.

A penetration test must always be approved, scoped, and documented before technical testing starts.

***

Organizations use penetration testing to understand their real exposure.

A scanner may show a list of vulnerabilities, but a penetration test answers more practical questions:

1. Can the weakness actually be exploited?
2. What access can an attacker gain?
3. Can the issue be chained with other weaknesses?
4. What data, system, or business process is affected?
5. How serious is the impact?
6. How should the issue be fixed?

This makes penetration testing different from simply running tools.

The tester must understand the target, validate the results, and explain the risk clearly.

***

## Penetration Testing vs Vulnerability Assessment vs Red Teaming

These activities are related, but they are not the same.

<table><thead><tr><th width="131">Area</th><th>Vulnerability Assessment</th><th>Penetration Testing</th><th>Red Teaming</th></tr></thead><tbody><tr><td>Main Goal</td><td>Identify weaknesses</td><td>Validate exploitability and impact</td><td>Test detection and response</td></tr><tr><td>Approach</td><td>Mostly scanning and review</td><td>Manual testing with controlled exploitation</td><td>Adversary simulation</td></tr><tr><td>Depth</td><td>Broad but usually shallow</td><td>Focused and deeper</td><td>Objective-driven and stealthier</td></tr><tr><td>Exploitation</td><td>Limited or not performed</td><td>Performed when authorized</td><td>Performed as part of attack simulation</td></tr><tr><td>Output</td><td>Vulnerability list</td><td>Confirmed findings with evidence</td><td>Assessment of security operations and resilience</td></tr><tr><td>Best Used For</td><td>Baseline security and compliance</td><td>Proving real technical risk</td><td>Testing people, process, and technology together</td></tr></tbody></table>

A vulnerability assessment may say that a system is vulnerable.

A penetration test proves whether the issue is exploitable and what the attacker can achieve.

A red team assessment goes further by testing whether the organization can detect, investigate, and respond to realistic attack activity.

***

## Professional Testing Mindset

A penetration tester should think in terms of evidence, validation, and impact.

The tester should be able to separate:

* **Observation**
  * Something noticed during testing.
* **Suspicion**
  * Something that may indicate a weakness.
* **Confirmed Finding**
  * A weakness that has been validated with evidence.
* **Impact**
  * What the weakness allows an attacker to do.
* **Risk**
  * The likelihood and impact of the issue in the real environment.

Do not report assumptions as confirmed findings.

Do not treat scanner output as proof.

Do not exploit something only because it is possible.

The goal is to prove risk safely and clearly.

***

## Evidence-Driven Testing

Evidence is what makes a finding defensible.

Useful evidence may include:

* Target IP address, hostname, URL, or endpoint.
* User account or role used during testing.
* Request and response.
* Command and output.
* Screenshot.
* Timestamp.
* Affected object or record.
* Proof of access.
* Clear reproduction steps.
* Cleanup notes.

Evidence should prove the issue without exposing unnecessary sensitive data.

When sensitive information appears, mask or minimize it according to the Rules of Engagement.

***

## Mistakes to Avoid

Common mistakes at the beginning of penetration testing include:

* Starting technical testing before scope is clear.
* Running tools without understanding the output.
* Reporting scanner results without validation.
* Confusing vulnerability assessment with penetration testing.
* Ignoring failed attempts.
* Not capturing evidence from the beginning.
* Using intrusive techniques without approval.
* Testing systems that are not clearly in scope.
* Writing findings without explaining real impact.
* Forgetting cleanup after testing.

A professional test is not judged by how many tools were used.

It is judged by the quality of validation, evidence, impact explanation, and remediation guidance.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://reaper.gitbook.io/my-penetration-test-guide/getting-started/publish-your-docs.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.