The right penetration test depends on what you most need to protect and how an attacker would reach it. Most organisations start with their internet-facing infrastructure and their most important web application or API, then add internal network, cloud, mobile or social engineering testing as their systems, risks and obligations require.
Penetration testing covers several distinct services, and buying the wrong one is a common way to spend a budget without answering the question you care about. This article explains what each main type tests, the question it answers and when it is usually the right choice. For how a test runs once you have chosen, see what happens during a penetration test.
Executive Summary & Key Takeaways
- Start from the question you need answered, such as “could an outsider reach our customer data?”, not from a list of test types.
- Infrastructure tests look at networks and servers. Application and API tests look at the logic of your software. Most organisations need both.
- Cloud testing focuses on how you have configured your accounts and identities, not on the provider’s own platform.
- Social engineering tests your people and processes, which matters because phishing is the most commonly reported attack on UK businesses.
- Compliance can decide part of the answer for you. PCI DSS, for example, specifies internal, external and segmentation testing.
Start with the question, not the test
Before choosing a type, write down what you are worried about and who will read the report. Typical questions include:
- Could someone on the internet get into our network or systems?
- If a laptop or user account were compromised, how far could an attacker get?
- Could one customer of our platform see another customer’s data?
- Is our new application safe to launch?
- Would our staff and processes stop a convincing phishing email or phone call?
Each question points to a different type of test. Many organisations have more than one question, which is why a test often combines types.
The main types of penetration test
| model | What it tests | Question it answers | Common triggers |
|---|---|---|---|
| External infrastructure | Internet-facing hosts, services and remote access | What can an outsider reach and exploit? | Annual testing, new services, audit or insurer requests |
| Internal infrastructure | Internal network, servers, Active Directory | How far could an attacker get from inside? | Ransomware concern, network change, PCI DSS |
| Web application | Logins, sessions, access control, business logic | Can users do things they should not? | New application or major release, customer questionnaires |
| API | Authentication, authorisation, data exposure | Can the API be abused directly? | Mobile apps, partner integrations, SaaS platforms |
| Cloud | Identity, permissions, storage and network configuration | Could a weakness in our cloud setup expose data? | Migration, new accounts, rapid growth |
| Mobile application | App storage, communications, client-side controls | Can the app or its back end be abused? | App launch or major update |
| Social engineering | Staff responses to phishing and pretexting | Would our people and processes hold? | Phishing concern, payment fraud risk |
External and internal infrastructure
An external test looks at everything an outsider can reach from the internet: websites, remote access, email services and any exposed management interfaces. An internal test starts from inside, as if an attacker had compromised a device or a user account, and measures how far they could move. In our experience, internal tests often reveal the biggest risks, because many networks are better defended at the edge than inside.
Web applications
Web application testing focuses on how your software behaves: whether users can access other users’ data, skip steps in a process or escalate their privileges. Testers commonly use the OWASP Top 10 as a baseline. The current release is the OWASP Top 10 2025 (OWASP, retrieved 27 October 2026). The most valuable findings are often in business logic that is specific to your application and that no standard list covers.
APIs
APIs deserve their own attention because they expose functions and data directly, without a user interface in the way. The OWASP API Security Top 10 2023 puts broken object level authorisation first: APIs that accept an object identifier without checking the caller is allowed to access that object (OWASP, retrieved 27 October 2026). If your product is a SaaS platform, test whether one customer can reach another customer’s data. Our article on tenant isolation testing covers that in detail.
Cloud
A cloud penetration test looks at what you control: identities and roles, storage permissions, network exposure and how services are connected. You cannot test the provider’s own infrastructure. AWS, for example, does not permit customers to carry out security assessments of AWS infrastructure or AWS services themselves, and lists the services customers may test without prior approval (AWS, retrieved 27 October 2026).
Mobile applications
Mobile testing covers the app on the device (how it stores data, how it talks to its back end and whether its controls can be bypassed) and the APIs behind it. The OWASP Mobile Application Security Verification Standard (MASVS) is the common reference, with control groups covering areas such as storage, cryptography, authentication, network communication and resilience to tampering (OWASP, retrieved 27 October 2026).
Social engineering and red teaming
Social engineering tests whether your people and processes would stop a convincing phishing email, phone call or impersonation attempt. That matters because phishing was reported by 38% of UK businesses, making it by far the most common type of breach or attack (Cyber Security Breaches Survey 2025/2026, DSIT and Home Office, retrieved 27 October 2026). Red teaming goes further: a longer, goal-based exercise that tests detection and response as well as prevention. It suits organisations with mature security monitoring.
Matching the test to your situation
These are common starting points, not rules:
- A SaaS business selling to larger customers: web application and API testing of the product, with tenant isolation in scope, plus a cloud test of the hosting environment.
- An office-based business with mostly cloud software: an external infrastructure test, a review of how your cloud and identity services are configured, and a phishing exercise.
- A business that takes card payments: PCI DSS v4.0.1 requires internal and external penetration testing at least once every 12 months and after significant change, plus testing of segmentation controls if you use segmentation to reduce scope (PCI SSC, retrieved 27 October 2026).
- A business launching a new application: test the application and its APIs before go-live, with time to fix findings before launch.
- A systemically important financial firm: regulator-led schemes may apply. CBEST is the Bank of England, PRA and FCA framework for intelligence-led testing (Bank of England, retrieved 27 October 2026), and identified EU financial entities must carry out threat-led penetration testing at least every three years under Article 26 of DORA (EUR-Lex, retrieved 27 October 2026). These follow their own rules on who can test: CBEST uses Bank of England-accredited CREST members, and DORA sets requirements for testers in Article 27. Falx can advise and support the internal team that runs the programme.
Penetration testing of any kind is still relatively uncommon. 13% of UK businesses reported carrying out penetration testing in the previous 12 months (Cyber Security Breaches Survey 2025/2026, DSIT and Home Office, retrieved 27 October 2026). If you are only able to test one thing this year, test the system that would hurt most if it were breached.
How much the testers are told in advance (black, grey or white box) is a separate choice from the type of test. It mainly affects how much coverage you get for the time spent, which we cover in what affects the cost of a penetration test.
Common mistakes
- Buying an infrastructure test to answer an application question. A network test will not tell you whether one customer can see another’s data.
- Testing the web front end but not the API behind it, when the API is what attackers will use.
- Assuming the cloud provider tests your configuration. They secure their platform; your accounts and permissions are your responsibility.
- Skipping internal testing because the external test came back clean.
- Starting with red teaming before the basics are in place. A red team will tell you what an infrastructure test could have found for less.
Frequently asked questions
Do we need both an internal and an external test?
Usually, yes. An external test shows what an outsider can reach today. An internal test shows what happens after one device or account is compromised, which is how many serious incidents unfold. If budget forces a choice, pick based on where you think you are weakest.
Is a cloud configuration review the same as a cloud penetration test?
They overlap but are not the same. A configuration review checks your settings against a benchmark. A penetration test tries to exploit weaknesses and chain them, for example from an exposed credential to a storage bucket. Many organisations use both.
Can we test the SaaS products we use, such as our CRM?
Generally not the product itself, as that belongs to the vendor and testing it without permission is not authorised. You can test how you have configured it, such as user permissions and integrations, and ask the vendor for evidence of its own testing.
Can one test cover several types?
Yes. A single engagement often combines, for example, a web application, its API and the cloud environment it runs in. Combining them lets testers follow an attack path across boundaries, which separate tests can miss.
Getting started
If you are unsure which test fits, start with the question you need answered and who will read the report. Our penetration testing service covers every type above and starts with a scoping conversation to match the test to your risks.
For help deciding, talk to our team.
Jared Henderson
Writing about cyber security and technology at Falx.
