What is penetration testing?
Penetration testing is an authorized, time-boxed attempt to exploit weaknesses and prove what an attacker could achieve. Useful proof must support remediation, so NIST SP 800-115 frames a disciplined lifecycle: planning, execution, analysis, reporting, and mitigation. The lifecycle ties every exploit to an objective, evidence standard, and remediation plan.
Security testing methods answer different questions. Scanning finds what looks weak; penetration testing proves whether a weakness is exploitable and where it leads. Red teaming evaluates whether people and controls can stop an adversary pursuing a goal. Continuous exposure validation checks whether exploitable paths return as the environment changes.
Penetration tests matter most when you need evidence of exploitability, business-logic flaws, or control failure under realistic conditions. Scanning and continuous validation provide breadth; skilled testers add depth, judgment, and creative chaining.
Vulnerability Management Buyer's Guide
This buyers guide will not only help you objectively choose or replace a vulnerability management solution, but also provide insights on how your organization can work together to own the responsibility of security as one team.
General penetration testing best practices
These eight practices help you turn an authorized test into evidence your team can use to reduce risk. Apply them across external, internal, web application, cloud, and hybrid environments, then adapt the test cases to each use case.
1. Define objectives and scope
Start with a business question: Can an external attacker reach customer data, or can a compromised account gain access to a critical system? Identify the systems, applications, identities, and data involved, with explicit inclusions and exclusions. Confirm ownership and third-party dependencies before testing. A measurable objective, such as demonstrating access to a canary record, gives testers a clear stopping point and defenders a specific path to close.
2. Choose the appropriate testing model
Match the information and access you give testers to the uncertainty you want to remove. Black-box testing starts with little prior knowledge; gray-box testing provides limited access; white-box testing supplies architecture or code for deeper analysis. These models describe tester knowledge, while external, internal, and application testing describe the surface being assessed. Use the comparison below to select the right combination.
| Knowledge model | Best fit | Cloud caveat |
|---|---|---|
| Black box | Public endpoints from an unknown starting point. | Shows exposure; can miss hidden trust edges. |
| Gray box | Authenticated application, IAM, tenant-isolation, or lateral-movement testing. | Requires scoped test identities but reveals authorization and trust paths that black-box testing may miss. |
| White box | Deep testing of complex logic, infrastructure as code, serverless, or AI systems. | Fastest route to deep flaws; requires strict handling of source code, secrets, and test data. |
Choose a delivery approach that fits the required expertise, independence, and retest speed. An internal team brings architectural context, a specialist partner adds independent expertise, and penetration testing as a service (PTaaS) can support repeatable engagements and retests.
3. Agree on rules of engagement
Get written authorization and define permitted targets, identities, actions, testing windows, rate limits, and stop conditions. Specify whether testers may escalate privileges, access data, or make changes, and document production restrictions. Agree on evidence handling, cleanup, and an always-available stop contact. Use synthetic data, canary records, and dedicated test accounts wherever possible.
4. Map assets and trust relationships
Reconcile discovered assets with inventories, application owners, and deployment records. Map how requests move between applications, services, identities, and data stores. Include third-party connections only where authorized. This exposes gaps that a hostname list misses and gives testers hypotheses to validate, such as whether a low-privilege account can reach a sensitive service through an unexpected trust relationship.
5. Combine automated discovery with manual validation
Use automated tools to discover assets and flag potential weaknesses, then validate findings in the context of the application and its business logic. Experienced testers can investigate authorization boundaries, unexpected workflows, and combinations of weaknesses that isolated checks miss. Record reproducible evidence and stop once the agreed impact is demonstrated; collecting more sensitive data rarely improves the finding.
6. Coordinate monitoring and communication
Agree whether defenders know the schedule or whether detection is part of the exercise. Confirm logs capture the relevant application, identity, network, and runtime activity, and define how testers will report critical discoveries. Coordinate with operations teams so unexpected service degradation triggers a pause. For cloud environments, ensure cloud detection and response telemetry can support the investigation.
7. Report business impact and assign remediation owners
Show the complete path: entry point → exploit → identity or permission → target → impact. Engineering teams need reproduction steps, affected resources, evidence, root cause, a practical fix, and retest criteria. Leadership needs the reachable business asset, blast radius, accountable owner, and remediation status. Put those views in a single tracked handoff so a severity score doesn’t become a substitute for explaining the risk.
8. Retest fixes and repeat testing as systems change
Reproduce the original conditions and confirm the attack path is broken, including related permission edges and alternate routes. Broader changes need regression coverage. Schedule tests according to risk and major application, architecture, or identity changes. Track remediation time, retest pass rate, recurring root causes, coverage gaps, and ownership. Continuous discovery can feed new hypotheses into the next focused test.
What is a penetration testing report? Components and examples
Penetration testing report is a formal document that details vulnerabilities found during a simulated attack, with evidence, risk ratings, and fixes.
Read more
External penetration testing best practices
Start from the perspective of an attacker outside the organization. Reconcile authorized domains, IP ranges, exposed applications, APIs, and remote-access services with the current asset inventory. Check forgotten services and newly exposed endpoints, and confirm ownership before testing anything discovered outside the agreed scope.
Validate authentication and access controls on public services, including administrative interfaces and account recovery flows. Prioritize weaknesses that could expose data or provide an initial foothold. If a finding could lead into internal or cloud systems, document that path and follow the agreed pivot permissions before going further. Use controlled proof and rate limits to protect availability.
External penetration testing: A practitioner's guide
External penetration testing assesses the exploitability of public-facing assets. It doesn’t just determine whether vulnerabilities exist; it also indicates whether attackers can actually reach and leverage them.
Read more
Internal penetration testing best practices
Define the starting position precisely: a compromised workstation, a standard user, or a limited service account. Each gives a different view of internal risk. Map reachable systems, directory services, privileged accounts, network segments, and trust relationships instead of assuming everything inside the network is trusted.
Test whether segmentation and authorization prevent movement toward critical systems. Evaluate excessive permissions, credential handling, and privilege-escalation paths using scoped identities and canary data. Include federated and cross-account access where authorized. Record which identity and permission enabled each step so teams can fix the root cause and retest the entire chain.
Watch 12-min demo
Learn about the full power of the Wiz cloud security platform. Built to protect your cloud environment from code to runtime.
Web application and API penetration testing best practices
Inventory application routes, API endpoints, user roles, tenant boundaries, and sensitive workflows. Test both unauthenticated behavior and authenticated sessions with dedicated accounts representing different roles. Verify that access decisions are enforced by the server for each object and action, rather than relying on what the interface hides.
Cover authentication, session handling, input validation, file handling, and business logic. Probe whether users can access another tenant’s records or perform actions outside their role, using synthetic records to demonstrate impact. Combine automated coverage with manual workflow testing, and record the requests, responses, and account context needed to reproduce each finding.
What is application penetration testing?
Application penetration testing is a simulated cyberattack against a software application designed to identify exploitable security vulnerabilities before malicious actors do.
Read more
Cloud and AI penetration testing best practices
Cloud scope must include resources, identities, and data relationships. One public endpoint may lead through an API gateway, a function or Kubernetes service, and several workload identities before reaching data. Include authorized accounts, subscriptions, projects, regions, registries, CI/CD systems, infrastructure-as-code repositories, and secret stores. A cloud infrastructure entitlement management (CIEM) view can help identify effective permissions and cross-account reach.
Keep scope current as workloads appear and disappear. Use account lineage, tags, resource types, ownership, and deployment events to decide how new assets enter scope. Preserve image digests, identity bindings, network reachability, and logs for ephemeral resources. State explicitly whether testers may assume roles, access metadata-service credentials, call downstream APIs, or cross account boundaries.
Check the current AWS penetration testing policy, Azure penetration testing guidance, and Google Cloud security FAQ for the providers in scope. While major cloud providers no longer require prior approval forms to test customer-owned workloads and APIs, their policies strictly prohibit targeting hypervisors, shared cloud control planes, other tenants, or conducting denial-of-service tests. Provider terms never replace the resource owner’s explicit authorization or your agreed rules of engagement.
For AI workloads, extend coverage beyond model endpoints to prompts, retrieval pipelines, vector stores, training data, registries, agent identities, plugins, tools, and Model Context Protocol (MCP) servers. AI security posture management (AI-SPM) can help inventory models, services, data, and exposure. Use the OWASP Top 10 for Large Language Model Applications and MITRE ATLAS as starting points, then choose cases based on the application’s actual trust boundaries.
Test prompt injection, authorization gaps, poisoned retrieval, unsafe output handling, data disclosure, model extraction, and excessive agent permissions. For MCP and agent workflows, check server authentication, per-tool authorization, consent, credential propagation, and indirect injection through tool descriptions or results. Verify that permitted tools cannot be chained into an unapproved action.
Use canary records to test retrieval and tenant isolation, and check for leakage into logs, caches, outputs, or exported datasets. Keep state-changing tools sandboxed and enforce requests and spend caps. Capture prompts, retrieved content, tool calls, and responses so findings explain what happened and support a reproducible retest.
Connect penetration testing to cloud attack paths
The Wiz Red Agent uses AI to autonomously test exposed web applications and APIs, uncover logic flaws, and validate exploitable risks at machine speed. Operating on top of Wiz Attack Surface Management, the Red Agent analyzes application behavior in real time and links proven weaknesses directly to cloud context.
For deep, authenticated testing, teams can launch Red Agent-powered Security Assessments. By providing the Red Agent with specific credentials or role instructions, security teams can simulate authenticated attacks and validate complex authorization boundaries behind a login.
To unify exposure management across cloud and hybrid infrastructure, Penetration Test Findings in Wiz centralizes results from external audits, bug bounty programs like HackerOne, and internal exercises. Teams can upload PDF reports with AI-assisted extraction, map validated issues directly onto the Wiz Security Graph, and convert findings into Posture Policies. This connects isolated pen test observations to underlying cloud permissions, sensitive data, and resource owners, ensuring remediation breaks the entire attack path.
Request a demo to see how Wiz unifies penetration test findings with continuous cloud context to eliminate exploitable attack paths across your environment.
Uncover Vulnerabilities Across Your Cloud
Stop chasing alerts—Wiz maps your entire cloud to find and prioritize real risks immediately.
