The main types of penetration testing vary by target, tester knowledge and team awareness.
That is why you might need a grey box web application test or a double-blind internal exercise.
The right test follows the system and attack path your business needs to validate, so start with the target before deciding what the tester and your team should know.
Let’s go through it.
How Penetration Testing Types are Categorised
Penetration testing types are categorised by target, tester knowledge and team awareness.
Because each choice controls a different part of the engagement, the following table works as a three-part scoping check.
| Category | Question to answer | Common options | What your choice changes |
|---|---|---|---|
| Target environment | What needs testing? | Network, web app, API, mobile, cloud, wireless, people or premises | Skills, test cases and authorised boundaries |
| Tester knowledge | What should the tester receive? | Black, white or grey box | Realism, coverage, time and access |
| Team awareness | Who should know? | Blind, double-blind, targeted, red or purple team | Secrecy, safety and whether response is tested |
By Target Environment
The target environment defines what the tester may assess. We suggest choosing it first, because an external network test won’t cover the portal, cloud tenant or mobile API behind it unless you add those systems.
By How Much the Tester is Told
Tester knowledge defines the information and access supplied before testing.
Black box favours outside realism, white box favours depth, and grey box provides selected accounts or documents. Choose the model that matches your question.
By How Much the Internal Team is Told
Team awareness defines who knows the test is happening.
It ranges from open collaboration to a covert test of detection and response. Because providers use “blind” differently, name every informed party in the rules.
Types of Penetration Testing by Target Environment
Target-environment penetration testing focuses the assessment on one defined part of your business, such as public systems, your internal network, apps, cloud environment, Wi-Fi, people or physical sites.
Choose the starting point by following the route an attacker could use to get in, move around or reach something valuable.
When those parts connect, a combined scope will usually give you a more useful answer than testing one in isolation.
External Network Penetration Testing
External network penetration testing looks at what anyone on the internet can reach in your environment. That can include public IP addresses, VPNs, firewalls, DNS, email and exposed servers.
If one of these services is your front door, start here; if it leads into your app or cloud tenant, add that layer to the scope.
Internal Network Penetration Testing
Internal network penetration testing shows how far an attacker could get after they land on a staff device, VPN connection or office network.
It follows credentials, permissions and network paths towards your servers, backups and data.
Internal network penetration testing is a strong fit when you rely on Active Directory or on-premises infrastructure; if identity is mainly managed in your cloud tenant, start with cloud testing.
Web Application Penetration Testing
Web application penetration testing checks whether someone can bypass the controls in your browser-based service.
It examines sign-in flows, access control, user input, file handling and the business rules behind your portal.
Use it for a SaaS product, e-commerce site or customer portal, and include each role that can approve, view or change sensitive information.
API Penetration Testing
API penetration testing looks behind the screens at the endpoints that move data and trigger actions between systems.
It tests authentication, authorisation, data exposure, resource controls and the API inventory.
If your web app, mobile app or partner integration relies on APIs, test each relevant role and deployed version.
Mobile Application Penetration Testing
Mobile application penetration testing follows your iOS or Android app from the handset to its backend.
It checks local storage, authentication, traffic, deep links, tampering and reverse engineering.
Use it when your app handles sensitive actions, and test the supporting API as well because weak backend controls can undermine an otherwise sound app.
Cloud Penetration Testing
Cloud penetration testing looks at the parts of AWS, Microsoft Azure or Google Cloud that your team configures and controls.
It checks who can access what, where data is exposed and whether secrets, workloads, networks or CI/CD connections create a route into a critical system.
Use cloud penetration testing when a cloud role or configuration error could expose sensitive systems or data.
Wireless Penetration Testing
Wireless penetration testing asks whether someone near your site could misuse Wi-Fi to reach a network they should not.
It checks authentication, encryption, access points and separation between corporate, guest and device networks.
If your office, clinic, warehouse or venue relies on wireless access, name each site, SSID and physical boundary so the test stays within your environment.
Social Engineering Penetration Testing
Social engineering penetration testing asks whether a convincing request could lead someone in your team to bypass a control.
A phishing message, phone call or help-desk request can test payment, password-reset and data-release workflows.
Set the targets, data-handling rules and stop conditions upfront, because the point is to find the weak step and improve it, not catch anyone out.
Physical Penetration Testing
Physical penetration testing checks whether someone could get through your on-site controls and reach a device, network point or restricted area.
It can include reception, access cards, tailgating, equipment rooms and unattended devices.
Use it where physical access could expose systems or sensitive material, and agree on written authority and safety boundaries before testing starts.
Types of Penetration Testing by Tester Knowledge
Tester knowledge determines what the tester can see and use before a penetration test begins.
It does not change the target, but it does change whether the engagement feels like an outside attack or goes deeper into your environment.
Choose black, white or grey box testing based on the question you need answered.
Black Box Penetration Testing
Black box penetration testing starts the tester with almost no inside knowledge.
Use it when you want to see what an outsider could find through public information and whether that path leads anywhere useful.
Because the tester has to map the environment from scratch, a fixed engagement may give less time to logged-in functions.
White Box Penetration Testing
White box penetration testing gives the tester the inside view, such as source code, diagrams, configurations, documents or test accounts.
Give this access when you want the tester to spend more time on deeper flaws instead of rebuilding a map your team already has.
If you also need a source-code review or configuration audit, name it in scope because white box access alone does not include either deliverable.
Grey Box Penetration Testing
Grey box penetration testing gives the tester enough access to act like a real customer, staff member or compromised account.
Grey box penetration testing is often a practical fit for an SMB because it keeps the starting point realistic without using much of the engagement on basic discovery.
For a SaaS product, testing several roles can show whether one customer can cross into another tenant’s records or functions.
Types of Penetration Testing by Team Awareness
Team awareness determines who in your business knows a penetration test is happening.
That choice decides whether the exercise tests the system alone, your defenders’ normal response, or both.
The following models run from a controlled covert check to an open exercise where testers and staff work side by side.
Blind Testing
Blind testing gives the tester limited information while a small sponsor group in your business knows the test is scheduled.
It lets you see what an outsider could find without making the whole exercise covert.
Agree who is informed before testing starts, because providers use the term “blind” differently.
Double-Blind Testing
Double-blind testing keeps most of your defenders unaware while the tester also starts with limited information.
It shows whether normal monitoring and escalation pick up the activity without advance warning.
Keep a small control group available to authorise the work and handle emergencies, and use this approach once you have dependable logging and clear response ownership.
Targeted Testing
Targeted testing is an open exercise where the tester and nominated staff work together. It suits broad technical coverage, rapid learning or validation after a major change.
Because both sides share context, your team can see how a weakness appears in the logs and confirm the fix sooner.
Red Team, Blue Team and Purple Team Exercises
Red, blue and purple team exercises test how an attacker and your defenders perform against a broader business objective.
The red team simulates the attack, the blue team detects and responds, and the purple team brings both sides together to improve the controls.
Because the exercise can link identity, endpoints, cloud and social engineering into one attack path, it sits within offensive security rather than a narrow asset-by-asset test.
It is most useful after you have addressed known gaps through scoped penetration testing.
The Five Phases of a Penetration Test, and How They Change by Type
A penetration test moves from scope to mapping, analysis, controlled exploitation, then reporting and retesting. This five-phase model adapts NIST SP 800-115, while the type you select changes how each phase works:
- Set the scope and rules: Define the objective, targets, exclusions, timing, contacts and stop conditions. Cloud tests must follow provider rules, while social, physical and covert tests need tighter safety controls.
- Map the environment: Identify technologies, roles and likely entry points. A black box test relies on public information, whereas a white box test starts with supplied inventories and diagrams.
- Analyse vulnerabilities: Combine tools with manual testing to find weaknesses and attack chains. Web and API tests focus on roles and business logic, while cloud tests focus on identities and configuration.
- Validate impact through controlled exploitation: Prove whether selected weaknesses can create authorised impact. An internal test may cover lateral movement, while a social test runs approved pretexts.
- Report, remediate and retest: Prioritise fixes, explain the evidence and confirm remediation. A compliance scope maps named requirements, whereas a purple team exercise also records detection gaps.
The authorisation you agree at the start applies throughout the test.
Put brute-force attempts, denial-of-service testing, persistence and access to customer data in writing. If a technique isn’t approved, it stays out of scope.
How to Choose the Right Type of Penetration Testing for Your Business
Choose the proper type of your pen test in three passes: follow your critical systems, match the evidence to your obligations, then define the scope.
This keeps the test useful when you need to fix risk, win work or complete an insurance review.
Start With the Systems the Business Actually Depends On
Start with the system whose loss would stop revenue, expose valuable data or block recovery. ASD advises businesses to assume compromise and prioritise their “crown jewels” in its Annual Cyber Threat Report 2024–2025.
Once you know the likely entry point and what follows it, use the table to connect that path to a starting scope.
| Your dependency | Start with | Add when needed |
|---|---|---|
| SaaS or customer portal | Web app and API | Cloud controls the data path |
| iOS or Android service | Mobile and API | A web admin console controls users |
| VPN, remote access or public servers | External network | You need to test post-entry movement |
| Active Directory or office servers | Internal network | An internet service is the likely entry |
| Cloud workloads and privileged roles | Cloud | An app, API or person can reach the tenant |
| Payments, resets or data-release workflows | Social engineering | Technical access follows a successful pretext |
If you can’t make that connection yet, use a vulnerability assessment to find the critical asset and where deeper testing will help.
Match the Test to Your Compliance and Cyber Insurance Obligations
Match your penetration test scope to the exact obligation you need to meet, whether that is a framework clause, maturity tier or insurer question.
Relevant evidence can help you win work, pass a supplier review or renew insurance, although a generic report may not.
Work through the four triggers below because each expects different evidence:
- Essential Eight: The Essential Eight has its own assessment process. A pen test can validate attack paths, but it doesn’t determine maturity, so give the provider your boundary, target level and relevant controls.
- SMB1001:2026: Testing isn’t a blanket requirement at every tier. If you target Diamond, check the current SMB1001 publication and agree how an external specialist will deliver annual penetration testing, vulnerability assessment and social engineering.
- Cyber insurance: Use your cyber insurance application, broker advice and policy wording to set the scope. Testing can support underwriting evidence, but it doesn’t guarantee cover, price or claim acceptance.
- Customer, tender or contract. Follow the buyer’s wording on test type, date, independence, remediation and retesting. Matching it can prevent an evidence gap from delaying your bid.
Set Scope, Frequency and Depth Before You Request a Quote
Set the assets, test depth, delivery requirements and retest trigger before you request a quote.
Your brief should give the provider enough detail to price the work properly, including:
- The objective, assets at risk and what success looks like;
- In-scope systems, sites and user groups;
- Excluded third parties and connected services;
- Environments, test data and user roles;
- Tester access and whether your team knows the test is happening;
- Permitted techniques, contacts and stop conditions; and
- Reporting requirements, framework mapping and retesting.
When every provider prices the same agreed job, you can compare scope, evidence and cost without discovering later that a cheaper quote left out the testing you needed.
Set the repeat trigger at the same time, because a test only reflects your environment at the time it was performed.
Annual testing gives many SMBs a useful baseline, while major releases, cloud migrations, acquisitions, incidents or a new contractual obligation may justify testing sooner.
What a Penetration Test Report Should Tell You
A penetration test report should tell you what was tested, what the tester proved and what your team should fix first. The report can only support those decisions when it includes:
- Scope, dates, methods, exclusions and limitations;
- An executive summary tied to your business objective;
- Reproducible evidence for each validated finding;
- The attack path, required access and realistic impact;
- Priorities based on likelihood, impact and your environment;
- Specific remediation your team can assign; and
- Fixed, partly fixed and unresolved findings after retesting.
Ask for separate executive and technical views if customers or directors need different details. A clean retest record can also close evidence requests during a tender or customer review.
Where Penetration Testing Fits Alongside Continuous Security Monitoring
Penetration testing proves attack paths at a point in time, while continuous monitoring watches your changing environment.
Because they answer different questions on different schedules, treat them as connected activities:
- Vulnerability scanning asks which known weaknesses are visible, so run it regularly and after material change.
- Penetration testing asks whether selected weaknesses can reach an important asset, so use it at planned intervals and after major change.
- Retesting asks whether the fix closed the proven path, so schedule it after remediation is ready.
- Continuous monitoring asks whether suspicious activity is happening now, which makes it an ongoing function.
- Incident response defines who investigates, contains and recovers when an alert becomes an incident.
Together, these activities connect discovery, proof and response. Because a penetration test ends, your team still needs to operate the monitoring that follows.
If it can’t, a dedicated managed security service could help your business provide ongoing triage and escalation.
Choose the Right Penetration Test with Redscale
The wrong test can leave the very system you need assessed outside the scope. That gap quickly becomes costly when a client, assessor or insurer asks for evidence your report cannot provide.
By scoping the test around the route an attacker could actually take, you avoid last-minute surprises when deadlines close in.
Where that route crosses systems, our dedicated penetration testing service can assess connected web apps, APIs, mobile apps, networks and cloud systems in one engagement.
With Redscale penetration testing service, you receive evidence across the full path, which is the kind reviewers expect.
Plus, our testers hold OSCP, CREST and GMOB certifications, and they’ll talk through your environment before you commission the assessment.
That way, you know the scope matches your assurance needs before the work begins.
Book a free discussion with a Redscale-certified tester to map the evidence your next client, assessor or insurer will ask for.
