Common Penetration Testing Types Explained

Not all pen tests are the same thing.

When someone says "we've had a pen test done," the natural follow-up question should be: which kind? Because penetration testing isn't a single activity any more than "surgery" is a single procedure. An external infrastructure test and a social engineering assessment are about as similar as a knee replacement and cataract surgery — both are operations, both require trained professionals, and neither one substitutes for the other.

This matters because scoping the wrong type of test is worse than not testing at all. It creates false confidence. You believe you've been assessed when you've actually only looked at one layer — and the attacker, who doesn't respect your scope boundaries, walks in through the layer you didn't test.

This article explains each common type in plain English: what it targets, how it works, what it typically uncovers, and who should be commissioning it. If you're responsible for deciding what gets tested and how, this is the guide that helps you have an informed conversation with your provider.

External infrastructure.

An external infrastructure test simulates an attacker on the internet with no insider knowledge and no credentials. They can see only what's publicly visible — your IP addresses, domain names, and any services exposed to the outside world. The tester's job is to find out how much damage can be done from that starting position.

Think of it as a stranger walking the perimeter of your building. They're checking every door, every window, every service hatch. They're looking at the locks, reading the signs, and testing whether anything's been left open. They haven't been given keys — they're working with what's available to anyone who cares to look.

Internal infrastructure.

An internal test begins where an external attacker's successful breach ends — inside your network. The tester is given a laptop on the corporate LAN (or a VPN connection) with standard user privileges, simulating a compromised employee workstation, a rogue insider, or an attacker who made it past the perimeter through phishing or an exploited VPN.

If external testing checks the locks on the doors, internal testing asks: once someone's inside the building, what can they reach? The answer, in most organisations, is: far too much.

The internal network is where organisations are most consistently vulnerable, because it has historically been treated as a trusted zone. Firewalls guard the perimeter. Monitoring watches the ingress points. But inside, the network is often flat, Active Directory is weakly configured, and credentials are scattered like house keys left under doormats.

The typical internal test follows a predictable arc: capture credentials through broadcast poisoning, crack a service account hash, use it to query AD for escalation paths, find a route to Domain Admin, and demonstrate full domain compromise — often within hours. The statistic from our engagements: Domain Admin is achieved in approximately 85% of internal tests.

Web application.

Web application testing examines the software, not the server. While infrastructure testing asks "is this machine secure?", application testing asks "is the code running on it secure?" These are entirely different questions with entirely different answers.

Your web server might be perfectly patched and hardened — but if the application it hosts has a SQL injection vulnerability in the login page, none of that matters. Application-layer vulnerabilities are the most common cause of data breaches, and they can only be found through dedicated application testing that includes significant manual effort.

Web application testing is typically benchmarked against the OWASP Testing Guide (currently v4.2) and the OWASP Top 10, but experienced testers go well beyond these. The most damaging findings — business logic flaws, complex authorisation bypasses, chained attack paths — live outside any checklist.

Mobile application.

Mobile testing assesses iOS and Android applications from a fundamentally different threat model than web testing. A web application runs on a server you control. A mobile application runs on a device the attacker controls. They can decompile it, inspect its storage, intercept its traffic, and reverse-engineer its logic. Every secret embedded in the binary is a secret the attacker already has.

The test covers the app itself (local storage, binary protections, runtime behaviour), its network communication (API calls, certificate validation, data in transit), and the back-end APIs it talks to (which frequently overlap with web application testing but are often less rigorously protected because developers assume the mobile client is "trusted").

Mobile testing follows the OWASP Mobile Application Security Testing Guide (MASTG) and the Mobile Top 10. It's essential for financial services, healthcare, e-commerce, and any organisation whose mobile app handles sensitive user data.

Cloud configuration.

A cloud security assessment evaluates your AWS, Azure, or GCP environment for misconfigurations, architectural weaknesses, and access control failures. It's not a traditional pen test in the sense of "break in from the outside" — it's a systematic review of how your cloud estate is configured, with particular attention to the things that go wrong when the shared responsibility model is misunderstood.

The shared responsibility model is simple in theory: the cloud provider secures the physical infrastructure, the hypervisor, and the managed services. You secure everything you build on top — identity, access, storage permissions, network configuration, encryption, logging, and application code. In practice, this boundary is routinely misunderstood, and the resulting misconfigurations are a leading cause of cloud breaches.

Cloud reviews are benchmarked against the CIS Benchmarks for the relevant provider, supplemented with manual assessment of architecture, trust chains, and realistic privilege escalation paths. The output isn't just a compliance checklist — it's an attacker's roadmap through your cloud estate, with recommendations to shut down each path.

Wireless.

Wireless penetration testing assesses your Wi-Fi environment — corporate networks, guest networks, and anything else broadcasting a signal — for vulnerabilities that an attacker within physical range could exploit to intercept traffic, capture credentials, or gain direct access to the corporate network.

This is an on-site engagement. The tester arrives with specialist hardware — directional antennae, wireless adapters capable of monitor mode and packet injection, portable access points — and operates from within or near your premises. The range of a corporate Wi-Fi network frequently extends well beyond the building envelope: into the car park, the neighbouring office, the coffee shop across the road.

Social engineering.

Social engineering assesses the hardest thing to patch in any organisation: human behaviour. It tests whether your people — from the receptionist to the CFO — can recognise and resist the manipulation techniques that real attackers use every day.

This isn't about making people feel foolish. It's about measuring your organisation's human-layer defences under realistic conditions, identifying where training has gaps, and building a culture where reporting suspicious activity is instinctive rather than embarrassing.

The most important metric from a social engineering assessment isn't the click rate or the compromise rate — it's the report rate. An organisation where 20% of people click but 80% report the phish within 10 minutes has a strong security culture. An organisation where 5% click but nobody reports it has a dangerous one — because in a real attack, that unreported 5% is the attacker's foothold.

The complete comparison.

How to choose the right combination.

No single test type covers everything. The right programme is a combination — chosen to match your environment, your threat landscape, and your maturity level.

Five mistakes that waste your budget.

The bottom line.

Penetration testing isn't one thing — it's seven (at least). External, internal, web application, mobile, cloud, wireless, and social engineering assessments each target a different layer, use different techniques, and find different vulnerabilities. No single type covers everything, and assuming otherwise creates blind spots that attackers will find.

The right approach is to match the test to the question. "Could someone on the internet break in?" is an external test. "What happens when a phishing email succeeds?" is an internal test. "Are our developers writing secure code?" is a web application test. "Would our staff recognise a targeted attack?" is a social engineering assessment.

Start with the layers most exposed and most valuable. Build from there. And always, always test the internal network — because the perimeter will fail eventually, and what matters then is what the attacker finds on the other side.