# What is penetration testing? Types, process, and best practices

_Penetration testing, or pen testing, is an authorized security assessment that uses simulated attacks to find and validate exploitable weaknesses in your systems. The goal is to understand how a compromise could happen, what access it would provide, and which defenses need improvement._

## What is penetration testing?

Penetration testing, or pen testing, is an authorized security assessment that uses simulated attacks to find and validate exploitable weaknesses in your systems. The goal is to understand how a compromise could happen, what access it would provide, and which defenses need improvement.

Finding a vulnerable package is a starting point. A pen test investigates whether you can reach the affected service, meet the conditions for exploitation, and use that access to reach something valuable, such as customer records or an administrative account.

Armed with the findings of a penetration test, teams assess access controls, segmentation, and application behavior, then define specific engineering work (like patching a service, fixing an authorization check, or restricting a role’s permissions).

## Why is penetration testing important?

[Verizon’s 2026 Data Breach Investigations Report](https://www.verizon.com/business/resources/executivebriefs/2026-dbir-executive-summary.pdf) found that vulnerability exploitation initiated 31% of the breaches in its dataset. Penetration testing helps you prioritize fixes based on demonstrated impact. For example, proving that a standard account can read another customer’s records makes the consequences of an access-control flaw clear.

Risks extend beyond unpatched components: [OWASP’s Web Security Testing Guide](https://owasp.github.io/www-project-web-security-testing-guide/) covers business-logic testing, including [limits on repeated actions](https://owasp.github.io/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/10-Business_Logic_Testing/05-Test_Number_of_Times_a_Function_Can_Be_Used_Limits). A checkout workflow that accepts the same discount twice illustrates why you need to test business rules, even when every component is secure.

When detection and response are in scope, compare the test timeline with application, identity, and cloud audit logs. Check whether your security operations center (SOC) received an alert, could investigate it, and took the expected containment action. Testing [defense in depth](https://www.wiz.io/academy/cloud-security/cloud-defense-in-depth) this way reveals gaps in logging, alerting, and response procedures.

## Penetration testing vs. vulnerability scanning

Vulnerability scanning identifies potential weaknesses across many assets. Penetration testing investigates selected weaknesses to establish whether you can exploit them and what the resulting access would allow. The table below compares their scope, methods, and results.

| Dimension | Vulnerability scanning | Penetration testing |
| --- | --- | --- |
| Purpose | To identify potential vulnerabilities | To validate exploitability and impact |
| Approach | Automated checks across many assets | Targeted investigation and controlled exploitation |
| Frequency | Recurring or continuous, based on tooling and scope | Scheduled engagements, and tests after significant changes |
| Deliverables | Findings, affected assets, and severity indicators | Evidence, attack paths, impact, and remediation guidance |

Together, scanning and pen testing turn broad visibility into focused investigation: Scans highlight potential weaknesses, and pen tests establish which attack paths work. Combining their findings in one remediation workflow helps your team prioritize demonstrated risks.

Validated attack paths can also inform red team exercises, which pursue broader business objectives while testing defenses and avoiding detection. Either approach, red teaming or pen testing, can assess detection and response, depending on your objectives.

## Types of penetration testing

The types of penetration testing map to three choices: what you test, how much information you provide, and where testing starts. Choose a combination based on your pen test’s goals.

### Testing scope: What will you assess?

- **Network testing: **Assess reachable services, network access controls, and segmentation. For example, verify whether access to an employee subnet could provide a route to production systems.
- **Web application testing:** Test authentication, sessions, authorization, and business workflows. Focus on whether you can perform actions or access information beyond your assigned privileges.
- [**API testing**](https://www.wiz.io/academy/api-security/what-is-api-testing)**:** Examine endpoint behavior and access boundaries between users or tenants. Confirm that each request enforces the caller’s permissions, including requests made outside the normal application interface.
- **Cloud testing: **Investigate exposed resources, workload identities, permissions, and trust relationships. Follow how access to one service could extend into storage, administrative functions, or another account.
- [**Social engineering**](https://www.wiz.io/academy/detection-and-response/social-engineering-attacks)** testing: **Assess human processes through explicitly authorized scenarios, such as simulated phishing or password-reset requests. Define who’s in scope and how you will handle sensitive information.

### Testing approach: What information will you provide?

[Black-box testing](https://www.wiz.io/academy/vulnerability-management/black-box-testing) starts with little internal information beyond the target scope. Gray-box testing uses limited context or access, such as documentation and a standard account. White-box testing provides source code, architecture, and configuration details. Choose the information model that gives you enough depth to answer your security questions.

### Starting position: Where does testing begin?

External testing begins outside your trusted environment, typically against internet-facing assets. Internal testing begins with an agreed foothold, such as an employee account or access to a private network. Starting position and available information are independent choices.

For a public API, an external, gray-box engagement with two test accounts can assess tenant isolation. To investigate a compromised workload’s impact, begin internally with its existing permissions. Match the setup to the controls you want to validate.

## How does penetration testing work?

The penetration testing process connects an agreed objective to validated findings and verified fixes. New discoveries can send you back to an earlier stage.

### Planning and scoping

Planning starts with a specific objective, such as determining whether a low-privilege account can reach production data. Testers and system owners agree on authorized targets, exclusions, testing windows, and success criteria before testing begins. Accounts and documentation are prepared in advance.

Rules of engagement define permitted techniques, data handling, emergency contacts, and stop conditions. They also establish whether your SOC knows about the test and how responders can distinguish it from a real incident. [NIST SP 800-115](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-115.pdf) provides a rules-of-engagement template.

### Reconnaissance and vulnerability analysis

Testers map authorized hosts, domains, applications, API endpoints, identities, and dependencies. Automated discovery, configuration review, and manual investigation reveal potential weaknesses and the conditions needed to exploit them.

An exposed admin endpoint, for example, becomes a testable lead once its authentication requirements, reachable functions, and surrounding controls are understood. This analysis focuses testing on plausible attack paths.

### Controlled exploitation and impact assessment

Controlled exploitation establishes whether selected weaknesses provide access within the agreed boundaries. Where authorized, testers investigate privilege escalation and movement to connected resources, tracing how an initial compromise could reach sensitive systems.

Evidence should demonstrate impact with minimal disruption. For instance, reading a synthetic record may prove unauthorized access without retrieving customer data. The assessment distinguishes demonstrated results from inferred consequences and scenarios that could not be safely tested.

### Reporting, remediation, and retesting

The report turns validated findings into engineering work, documenting affected assets, prerequisites, reproduction steps, demonstrated impact, and recommended fixes. Limitations and untested areas clarify gaps in coverage. Meanwhile, remediation owners and target dates keep fixes accountable, and cleanup removes test artifacts. 

Finally, retesting checks the root cause: An authorization fix on one endpoint may leave data accessible elsewhere. Documenting these outcomes alongside the findings completes the assessment.

## What changes when you’re pen testing cloud environments?

Cloud testing follows access across applications, identities, and services. Scope may span accounts, projects, or subscriptions, with [identity and access management (IAM) policies](https://www.wiz.io/academy/cloud-security/iam-security) determining how resources connect. Testing validates these permissions in practice: When an application carries excessive privileges, security teams can pinpoint exposed storage pathways and restrict access before production exposure occurs.

Keep in mind that [shared responsibility](https://www.wiz.io/academy/cloud-security/shared-responsibility-model) defines which resources and configurations you control. While major providers like AWS, Azure, and Google Cloud no longer require prior authorization to test customer-owned workloads and APIs, testing policies strictly forbid targeting underlying virtualization, shared cloud control planes, other tenants, or running denial-of-service simulations. Always review your provider's current policy and third-party dependencies before starting.

Next, remember that deployments, short-lived workloads, and permission changes can alter attack paths during or after testing. Record resource identifiers and relevant configurations so you can recreate the test conditions if the original workload disappears.

Consider a hypothetical document-preview service with a file-read flaw that exposes a workload credential. The credential’s identity can read an entire storage bucket, although the service only needs one folder. Reading a synthetic file outside that folder during an authorized test demonstrates how the application flaw and excessive permissions combine to expose data. Reviewing either issue alone would miss part of the impact.

In this scenario, you’d fix the file-read flaw and restrict the identity to the required data. Retesting both controls, including whether the preview service still works as intended, would complete the process. 

## Penetration testing best practices

Use these [pen testing best practices](https://www.wiz.io/academy/vulnerability-management/penetration-testing-best-practices) to make findings actionable:

- **Prioritize critical assets: **Build realistic scenarios around valuable data, essential services, and administrative access. Share business context with testers so the engagement focuses on consequences that matter to your organization.
- **Make boundaries clear:** Ensure testers and responders know which actions are authorized, who can pause testing, and how to escalate unexpected behavior. Keep those contacts available throughout the engagement.
- **Combine automation with manual investigation:** Automate repeatable discovery and checks, then use expert analysis to examine business rules, unusual trust relationships, and complex attack paths. Match the methods to the environment.
- **Require actionable findings:** Ask for prerequisites, reproduction steps, affected resources, and remediation guidance your engineers can use. Every severity rating should explain the access demonstrated and the potential business impact.
- **Test around material changes:** Reassess after major application releases, authentication changes, the addition of new cloud accounts, or changes to trust relationships. Use targeted assessments between broader recurring engagements.
- **Track fixes through retesting:** Monitor overdue findings and recurring weaknesses. Confirm that remediation blocks the original path, then check related paths where the same root cause could remain.
- **Account for coverage limits:** Record excluded assets, unavailable access, and untested scenarios. Use those gaps to plan subsequent assessments, and maintain visibility as your environment changes between tests.

## How Wiz supports penetration testing and continuous risk validation

Cloud attack paths often span exposed applications, workload identities, and sensitive data, which makes isolated scanner findings difficult to prioritize. The [Wiz Security Graph](https://www.wiz.io/lp/wiz-security-graph) correlates external exposures discovered by [Wiz Attack Surface Management (ASM)](https://www.wiz.io/solutions/asm) with internal cloud permissions and sensitive data classifications. This mapping visualizes complete attack paths, helping your team focus testing on verified business impact and pinpoint exactly where a single remediation can sever an attacker's route.

Because environments change rapidly between scheduled assessments, the [Wiz Red Agent](https://www.wiz.io/blog/introducing-the-wiz-red-agent) extends validation across external web applications and APIs through continuous offensive AI testing. By analyzing application logic, adapting attack patterns to live responses, and delivering reproducible proofs of concept, the Red Agent validates real-world [exploitability](https://www.wiz.io/academy/vulnerability-management/what-is-exploitability) at machine speed to complement and amplify human-led testing.

To bring everything together, Wiz Penetration Test Findings allows security teams to upload and manage results from third-party audits, bug bounty programs, and internal assessments directly in Wiz. By mapping manual pen test findings to the Wiz Security Graph, teams gain immediate cloud context, trace connected attack paths, and assign remediation owners. Paired with Wiz Unified Vulnerability Management, this provides a single platform to track fixes, enforce SLAs with Posture Policies, and monitor risk between scheduled tests.

Ready to see how Wiz can help you identify and address exploitable cloud risk? [Book a demo](https://www.wiz.io/demo) today.

## FAQs about penetration testing

---

[View on wiz.io](https://www.wiz.io/academy/vulnerability-management/what-is-penetration-testing)