October 13, 2025
Updated: November 4, 2026
A practical guide to authorized penetration testing: scope, process, test types, assessment differences, deliverables, limitations, and next steps.
Mohammed Khalil
What is penetration testing? It is an authorized security assessment that uses controlled attack techniques to find out whether weaknesses can lead to meaningful harm. A penetration test, or pentest, examines agreed systems, accounts, and scenarios, then gives the organization evidence, priorities, and recommendations for fixing the findings. It goes beyond listing possible vulnerabilities: testers investigate how a weakness behaves and what access it could allow. The result is a scoped view of risk at a point in time, followed by remediation and, when agreed, retesting. It does not prove that a system is completely secure.
A penetration test answers a practical question: can someone starting with the agreed level of access get past a security control, and what would that mean for the organization?
New to the vocabulary? Our cyber security terminology guide explains common terms in plain language.
The NIST penetration testing glossary collects definitions from several publications. Their contexts differ, but they connect testing with attempts to defeat security controls or validate whether vulnerabilities can be exploited. The scope and test conditions determine what a particular result establishes.
Penetration testing is one form of ethical hacking. Ethical hacking is the broader practice of using offensive security techniques with authorization; a pentest is a defined engagement with objectives, boundaries, evidence, and deliverables. Finding something on the public internet does not, by itself, grant permission to test it.
The goal might be to assess a release, examine an identity boundary, or validate a fix. A useful penetration testing scope connects that goal to specific assets, roles, environments, and exclusions.
Consider a fictional customer portal with separate accounts for two companies. The owner authorizes a test using two test tenants and dummy records. The question is whether each account can access only its own company's information.
Step | What happens in this illustrative test | What the result means |
|---|---|---|
Define the boundary | The team agrees which test accounts and dummy records may be used. | The test has an explicit permission and data boundary. |
Validate the weakness | A tester confirms that one approved account can retrieve a dummy record belonging to the other test tenant. | The server has failed to enforce the tested access boundary. |
Record minimal evidence | The report records the affected operation, account roles, expected behavior, and observed result. | Engineers can reproduce the finding without collecting real customer data. |
Fix the cause | The engineering team enforces authorization for the requested record on the server. | The fix addresses the access decision, rather than just hiding a button. |
Retest | The original cross-tenant access is blocked, and permitted access still works. | The tested fix works under the recorded conditions; wider coverage still has to be assessed. |
This is an explanation, not a DeepStrike client case study. It illustrates the difference between suspecting an access-control problem and demonstrating one. Severity still depends on the affected data, reachable actions, prerequisites, and scope; the example alone does not establish the risk of every authorization flaw.
The target determines the skills, access, and safeguards the test needs. Applications, application programming interfaces (APIs), and internal networks may share a testing lifecycle while requiring examination of different controls.
Test type | Typical focus | Example assurance question | Important boundary |
|---|---|---|---|
Web application and API | Authentication, authorization, sessions, input handling, and business logic | Can an approved role reach another user's data or action? | Define environments, accounts, APIs, integrations, and data limits. |
Mobile application | Local storage, platform controls, transport, authentication, and backend APIs | Can the app or backend expose protected data under the tested conditions? | Specify platforms, app versions, devices, and backend ownership. |
External network | Internet-facing services, remote access, and perimeter controls | Can an external starting point reach a defined asset or privilege? | Confirm IP ownership, shared infrastructure, provider policies, and exclusions. |
Internal network and identity | Segmentation, directory services, endpoints, permissions, and trust | Can the defined starting access cross a trust boundary? | Identify starting accounts, sensitive segments, and prohibited systems. |
Cloud environment | Identity, storage, configuration, workloads, and trust relationships | Can an approved identity or workload gain unintended access? | Respect provider testing policies and shared-responsibility boundaries. |
Wireless | Authentication, encryption, segmentation, and device exposure | Can an authorized nearby actor cross the intended wireless boundary? | Define locations, network identifiers, devices, and radio constraints. |
Social engineering or physical security | Human verification, business processes, facilities, and response | Can an approved scenario bypass a defined process or access control? | Requires explicit authorization, safeguards, and separate exclusions. |
A wireless penetration test needs a defined physical and radio scope. It is not automatically included in a network test.
Likewise, web application penetration testing should identify the roles and business workflows that matter, rather than treating a list of URLs as complete coverage.
Specialized scope can also include containers, Internet of Things devices, or continuous integration and delivery (CI/CD) pipelines. Specify which layers are included: an application test does not automatically assess its container orchestration, device firmware, or build pipeline. Ownership, test environments, and operational constraints need to be agreed for each.
The main types of penetration testing are named after the target: external network, internal network, web application, API, cloud, mobile application, AI and LLM application, and social engineering testing. Red teaming is a related but separate exercise that pursues an objective across several of those targets. Black box, gray box, and white box are not types of test; they describe how much the testers know at the start, which is covered later in this guide.
Use the table below to match a security question to a test type. The list after the table links to a DeepStrike guide or service page for each type.
Type | What it examines | Choose it when | Learn more |
|---|---|---|---|
External network | Internet-facing hosts, services, remote access, and perimeter controls | You need to know what an outsider can reach from the internet, or you have new public exposure | External penetration testing guide |
Internal network | Segmentation, directory services such as Active Directory, endpoints, and movement from an inside foothold | You want to know how far an attacker could get after a phishing compromise, a stolen laptop, or a compromised vendor account | Internal penetration testing guide |
Web application | Authentication, authorization, sessions, input handling, and business logic in browser-based applications | You are releasing or significantly changing a customer-facing or internal web application | Web application penetration testing services |
API | Object- and function-level authorization, authentication, data exposure, and rate limits on REST, GraphQL, or other APIs | Your product exposes APIs to mobile apps, partners, or integrations | API penetration testing guide |
Cloud | Identity and access policies, storage exposure, workload configuration, and cross-account trust in AWS, Azure, or Google Cloud | Production workloads or sensitive data run in a cloud account and you need to know what an approved identity could reach | Cloud penetration testing services |
Mobile application | On-device storage, platform protections, transport security, and the backend APIs the app calls | You ship iOS or Android apps that handle accounts, payments, or personal data | Mobile application penetration testing services |
AI and LLM application | Prompt injection, data leakage, unsafe tool use, and authorization around model features | You have added a chatbot, copilot, or agent that can read data or take actions | LLM and AI penetration testing services |
Social engineering | Phishing, phone pretexting, and, when agreed, physical entry, measured against verification processes | You want evidence about people and process controls, not only technology | Social engineering penetration testing guide |
Red team | An agreed objective, such as reaching a sensitive system, using any in-scope path while detection and response are observed | Your security program is mature and you want to test detection and response rather than list every flaw | What red teaming is and how it differs |
Guides for each type of penetration testing:
Two points from the table are worth stating plainly. First, the type names the target, while internal versus external describes the starting position, so an “external web application” test or an “internal network” test can still be gray box. Second, APIs deserve their own scope even when the web front end is tested: the OWASP API Security Top 10 (2023) ranks broken object level authorization as the top API risk, and that flaw can sit in endpoints the browser interface never calls.
Start from the risk you need evidence about, not from a list of test names. These rules of thumb cover most first decisions:
Many engagements combine types. A software-as-a-service release might pair web application and API testing; a cloud migration might pair cloud testing with internal testing of the identity paths between on-premises systems and the cloud. Combining types works well as long as the scope statement lists each target, starting point, and exclusion separately, so the report can show what was and was not covered.
The following seven steps describe an engagement from planning through retesting. They are a practical organization of the work, not a claim that every framework defines the same seven phases. Discovery, analysis, and validation often repeat as testers learn more.
Start with the decision the test should support. Examples include evaluating a new customer portal, checking separation between network segments, or validating access controls after a major identity change. Agree what evidence would answer the question and who will act on the findings.
Document the targets, environments, access, testing windows, exclusions, emergency contacts, and stop conditions before testing. Include data handling, evidence retention, cleanup, and third-party requirements. The NIST definition of rules of engagement emphasizes establishing the guidelines and constraints for security testing in advance.
Potentially disruptive techniques, social engineering, and persistence require specific agreement. They are not automatic components of every pentest.
Build an understanding of the approved attack surface: exposed services, application workflows, user roles, integrations, and trust relationships. Available documentation and test accounts can improve coverage. Record inaccessible assets or missing access so they do not disappear from the final scope statement.
Combine suitable automated checks with manual investigation. Look for configuration weaknesses, missing authorization, exposed services, and flawed business logic. A scanner alert is an input to analysis; it is not automatically a confirmed vulnerability or a complete explanation of impact.
For web applications, the OWASP Web Security Testing Guide provides testing guidance that can be adapted to the application. A checklist supports coverage but cannot replace understanding how that application works.
Test whether selected weaknesses can produce the agreed security impact. This may involve controlled exploitation or combining weaknesses into an attack path, within the rules of engagement. Use the minimum evidence needed to support the finding and stop at the agreed boundary.
If a technique is excluded or an impact cannot safely be demonstrated, state that limitation. Do not label an assumed outcome as observed evidence.
Escalate urgent findings through the agreed contact route. Deliver both a decision-focused summary and enough technical detail for engineers to investigate. Record tested scope, exclusions, evidence, severity reasoning, remediation, and residual uncertainty. Remove test artifacts and revoke temporary access as agreed, while retaining the authorized audit trail.
Assign finding owners, prioritize fixes, and track any accepted risk. Retesting checks the reported weakness after a change and records whether it is resolved, partly resolved, or still reproducible. It does not automatically extend the original test to every new feature or related system.
The NIST technical guide to security testing and assessment connects planning and testing with analysis and mitigation.
Our penetration testing methodology guide explores the frameworks and engagement stages in more detail.
These labels describe the information and access supplied at the start. They do not form a ranking from weak to strong testing.
Approach | Starting knowledge | Useful when | Tradeoff |
|---|---|---|---|
Black box | Minimal target information and no privileged access | The question concerns what an unfamiliar external actor could discover and attempt. | Reconnaissance consumes more of the time available, potentially reducing deeper coverage. |
Gray box | Selected accounts, roles, documentation, or architecture | The test needs realistic user access and efficient examination of important paths. | Supplied access must match the intended scenario. |
White box | Extensive architecture, source code, credentials, or implementation details | The priority is depth, coverage, or close examination of particular controls. | It models informed access rather than an unknown outsider's starting point. |
Choose the starting point that answers the security question. The black box vs. white box comparison explains the coverage tradeoffs in more detail.
Internal versus external testing is a separate dimension: it describes where testing starts in relation to the environment. An internal test can use different levels of prior knowledge. See internal vs. external penetration testing when defining that starting position.
A vulnerability scan, vulnerability assessment, pentest, red-team engagement, and bug bounty program answer different questions. The following are common distinctions; the agreed statement of work is the final guide to an engagement's deliverables.
Activity | Primary question | Typical approach | Typical output | Key limitation |
|---|---|---|---|---|
Vulnerability scan | Which known indicators can a configured tool detect? | Automated checks against reachable assets | Scanner results | Credentials, signatures, configuration, and reachability affect accuracy and coverage. |
Vulnerability assessment | What weaknesses exist, and how should they be prioritized? | Discovery, scanning, configuration review, analysis, and selected manual validation | Contextual findings and remediation guidance | Usually does not attempt broad adversarial validation. |
Penetration test | Can selected controls or attack paths be defeated within the authorized scope? | Human-led analysis, tools, and controlled validation | Evidence, impact, remediation, limitations, and agreed retest results | Bounded by time, scope, scenario, and skills. |
Red-team engagement | Can an authorized adversary achieve an objective while exercising detection and response? | An objective-led simulation under separate rules | Attack narrative, objective outcomes, and defensive observations | Does not aim to enumerate every weakness. |
Bug bounty program | What valid findings will eligible researchers report under the policy? | External researcher participation under program terms | Individual reports for triage | Coverage depends on scope, incentives, participation, and program rules. |
A vulnerability assessment can include manual work, and a pentest normally uses tools. The distinction is the question being answered and the evidence delivered, not simply “automated versus manual.” The vulnerability assessment and penetration testing guide develops that distinction.
Tools help testers discover assets, inspect behavior, and collect evidence. A tool's name does not establish the quality or completeness of an engagement.
Tool or method | Role in an authorized test | Important limit |
|---|---|---|
Nmap | Discover reachable hosts, ports, and services within scope | An exposed service is not, by itself, proof of an exploitable weakness. |
Burp Suite Proxy | Inspect and modify HTTP(S) requests and responses between a test browser and an application | The tester still has to understand roles, expected behavior, and business logic. |
Wireshark | Capture and inspect network protocol traffic where capture is authorized | Visibility depends on capture location and available decryption material; encrypted traffic is not automatically readable. |
Vulnerability scanners | Identify potential known weaknesses for investigation | Findings need interpretation and validation; checks can miss flaws or produce false positives. |
Manual test cases | Explore permissions, workflow assumptions, and combinations of weaknesses | Coverage depends on the tester's understanding, available access, and time. |
The official Nmap overview describes its network discovery and security auditing role.
PortSwigger documents how Burp Proxy sits between the browser and target to inspect and modify traffic.
The Wireshark project describes its network protocol analysis capabilities. These are different functions, not interchangeable substitutes for a complete assessment.
For buyers, the useful question is how automation and human investigation fit the scope. Our manual vs. automated penetration testing comparison explains those tradeoffs.
A useful report lets decision-makers prioritize risk and gives engineers enough information to act. Agree the following before the engagement:
Ask for a sanitized sample report before commissioning work. Our penetration testing report guide explains how to assess those deliverables.
Read every finding in a penetration test report through four lenses: severity (how much harm if exploited), exploitability (how likely and how easy exploitation is in your environment), evidence (whether the finding was demonstrated and can be reproduced), and retest status (whether the fix has been verified). A finding can carry a high score yet matter less if it needs access no realistic attacker has, while a modest-looking finding can be urgent if it is easy to reach and chains into something serious. Together, the four checks set the fix order.
Most reports rate findings as critical, high, medium, low, or informational, often with a Common Vulnerability Scoring System (CVSS) score. The CVSS v4.0 specification maps numeric scores to qualitative ratings as follows:
Rating | CVSS score | What to check in the report |
|---|---|---|
Critical | 9.0 to 10.0 | Was the impact demonstrated? Is the asset exposed or holding sensitive data? Was the agreed urgent escalation route used? |
High | 7.0 to 8.9 | The prerequisites, the affected roles, and whether the finding chains with others |
Medium | 4.0 to 6.9 | Whether your environment raises or lowers the impact; medium findings can form part of a high-impact path |
Low | 0.1 to 3.9 | Whether it is a hardening item or a step in a larger attack path |
None or informational | 0.0 | Observations and good practice; no direct security impact was shown |
Treat a base score as a starting point. FIRST describes CVSS output as the severity of a vulnerability relative to other vulnerabilities, and the specification recommends enriching base metrics with Threat and Environmental values. It also labels scores by the metrics used, such as CVSS-B for base metrics only and CVSS-BTE when threat and environmental metrics are included. If a report shows a bare number, ask which version and metric groups produced it and how the tester accounted for your data, users, and compensating controls. Some providers use their own impact-and-likelihood matrix instead; either approach works if the report explains the reasoning behind each rating.
Severity says how bad; exploitability says how reachable. Check whether the tester demonstrated the issue or inferred it from a version number or configuration, what an attacker would need first (network position, a valid account, user interaction, or a specific role), and whether the finding chains with others into an attack path. A good report says plainly when an outcome is assumed rather than observed.
For findings that map to a published CVE, two public sources add outside context. The Exploit Prediction Scoring System (EPSS) from FIRST estimates the probability that a published CVE will be exploited in the wild in the next 30 days, and CISA's Known Exploited Vulnerabilities catalog lists vulnerabilities with evidence of active exploitation. A CVE in that catalog on an internet-facing system deserves attention even when its CVSS rating is only medium. Our EPSS vs. CVSS comparison explains how to use the two together. Neither source covers custom flaws in your own code, such as broken access control, which is where the tester's evidence matters most.
Good evidence lets an engineer who was not on the engagement confirm the issue and verify a fix. For each finding, look for:
If a finding cannot be reproduced, ask the tester before closing it. The cause may be a changed environment, a missing prerequisite, or a false positive. A scanner result that was never validated should be labeled as such, not reported as a confirmed vulnerability.
A retest repeats the original check after remediation, under comparable conditions, and records an outcome such as resolved, partially resolved, not resolved, or not retested (for example, when a risk has been formally accepted). Ask for the date, tester, and evidence behind each status. A retest confirms the specific finding; it does not examine new features or other systems, which is one reason organizations with frequent releases look at continuous penetration testing.
Fix the root cause rather than the symptom. In the access-control example earlier in this guide, hiding a button would leave the missing server-side check in place, and a retest that sends the same request directly would show that the fix is incomplete.
Combine the four checks to set priorities. The table below is a starting framework; your risk appetite, regulatory deadlines, and remediation capacity decide the final order and timelines.
Situation | Suggested priority | Why |
|---|---|---|
Critical or high finding with demonstrated impact on an internet-facing or sensitive system | Fix immediately and use the urgent escalation route | It is reachable, proven, and serious |
Finding maps to a CVE in CISA's Known Exploited Vulnerabilities catalog | Expedite, even if it is rated medium | Active exploitation has been observed |
Several medium or low findings that chain into a high-impact path | Treat the whole path as one high-priority item | The combined outcome is what an attacker would use |
High rating that requires privileged access or an unusual position | Schedule promptly and review compensating controls | Serious if reached, but harder to reach |
Low or informational hardening items | Plan into regular engineering work | Limited direct impact; fixing them reduces future risk |
For report structure, the anatomy of a single finding, and what a strong sample report contains, see our guide to penetration testing reports. Track the fixes in your vulnerability management process so retests and recurring issues stay visible.
Penetration testing can reveal exploitable weaknesses, explain how controls behave together, support remediation priorities, and provide evidence for a security decision. Its value comes from findings the organization can understand and act on.
The limits matter just as much. A test samples agreed conditions during a limited period. It cannot guarantee that every vulnerability will be found, establish that excluded systems are secure, or prevent future changes from introducing weaknesses. The UK NCSC guidance on penetration testing places it within a broader assurance program rather than treating it as a complete security solution.
Consider testing before a significant release, after important architecture or identity changes, following remediation of a serious weakness, or at intervals appropriate to risk and applicable obligations. There is no single schedule that fits every organization. Establish the relevant contract or framework requirements separately; a pentest alone does not demonstrate full compliance.
Use threat modeling to identify important assets and plausible misuse scenarios before selecting test priorities. Maintain vulnerability management, secure development, monitoring, and incident response alongside testing.
When comparing providers, ask who will perform the work, how their experience matches the target, how coverage will be recorded, and how findings will be explained to engineers. Evaluate the proposed scope and sample report alongside the quote.
The DeepStrike penetration testing services overview provides a starting point for discussing the targets and objectives of an engagement.
Complexity, roles, environments, access, and reporting requirements all affect effort. Our penetration testing cost guide explains the factors to clarify when requesting a proposal.
Yes, when the system owner has authorized it in writing and the testing stays within that authorization. Testing without permission can be illegal. Authorization is essential, but it must cover the actual targets and techniques. Testing must also respect applicable law, contracts, and third-party conditions. Obtain written permission from the appropriate owner and resolve shared-service or provider requirements before work begins.
Yes. Even authorized testing can affect availability, performance, or data. The team should agree suitable environments, safeguards, stop conditions, and escalation contacts. A claim of zero operational risk deserves scrutiny.
No. It means the test did not report findings within its scope, methods, access, and time constraints. Review coverage and limitations before using that result to make a release or risk decision.
Automation can assist discovery, triage, and repetitive checks. Assess any service by its demonstrated coverage, validation, handling of business logic, and reporting rather than an “AI” or “manual” label. Accountability for authorization, evidence, and conclusions still needs to be clear.
Duration depends on target complexity, roles, environments, access readiness, and depth. Ask the provider to separate active testing, reporting, remediation time, and retesting in the schedule. A fixed number of days is meaningful only alongside its scope and assumptions.
Assign finding owners, prioritize fixes, and record any accepted risk. Retest the changes when agreed, then use recurring findings to improve engineering practices and preventive controls. Treat the report as an input to remediation, rather than the end of the work.
The main types are external network, internal network, web application, API, cloud, mobile application, AI and LLM application, and social engineering testing, with wireless and physical testing where agreed. Red teaming is a related, objective-led exercise. Black box, gray box, and white box describe how much the testers know at the start, not the type of test.
Check four things for each finding: its severity rating and how it was calculated, how exploitable it is in your environment, whether the evidence lets engineers reproduce it, and whether a retest has confirmed the fix. Demonstrated, high-impact findings on exposed or sensitive systems usually come first.
No. A CVSS base score rates the technical severity of a vulnerability relative to others. Risk also depends on how exposed the asset is, what data or actions it controls, how likely exploitation is, and which compensating controls exist. The CVSS specification recommends adding threat and environmental metrics to base scores for that reason.
A penetration test turns a defined security question into evidence about weaknesses, consequences, and corrective action. Start with a clear objective, choose the access and scope that answer it, and agree how findings will be reported and retested.
Discuss your systems and testing objectives with DeepStrike to define the scope of an engagement.
Mohammed Khalil is a Cybersecurity Architect at DeepStrike, specializing in advanced penetration testing and offensive security operations. With certifications including CISSP, OSCP, and OSWE, he has led numerous red team engagements for Fortune 500 companies, focusing on cloud security, application vulnerabilities, and adversary emulation. His work involves dissecting complex attack chains and developing resilient defense strategies for clients in the finance, healthcare, and technology sectors.
The sources linked alongside the relevant claims are listed here with their specific roles:
Stay secure with DeepStrike penetration testing services. Reach out for a quote or customized technical proposal today
Contact Us
