The 9 Types of Penetration Testing

There are nine main types of penetration testing categorised by what they target: web application, API, network (external + internal), cloud, mobile, AI/LLM, social engineering, physical, and internal (post-breach). They are also categorised by approach: black box (no information given to testers), grey box (limited information — most common), and white box (full source code and architecture). Most organisations need 2–3 types of pentest per year depending on their stack.

Web application penetration testing is the most-booked type — over 60% of engagements include some form of web app testing. It’s increasingly delivered alongside API penetration testing, since most modern web applications are really API-driven single-page applications or mobile-app frontends. For compliance-driven buyers (ISO 27001, SOC 2, PCI DSS), web + API testing is the baseline.

It’s about how much information the testers get before starting. Black box: nothing — testers start with only what an external attacker would have (a URL, an IP range). Grey box: limited information — typical user accounts at different privilege levels, architecture overview. White box: everything — source code, deployment configs, full credentials. Grey box is the default for almost all compliance and assurance engagements in 2026 because it gives the best coverage-per-day of engagement time.

No. Most organisations need 2–3 types per year. SaaS platforms typically need web app + API + cloud. FinTech adds network testing (especially for APRA-regulated). HealthTech with a mobile app adds mobile. Organisations shipping AI features add LLM testing. The right mix depends on your attack surface — a scoping call with a CREST-certified provider should map this to what you actually run.

Internal penetration testing simulates what an attacker would do after gaining initial access — a compromised laptop, phished employee, or malicious insider. The tester starts inside your network and tries to escalate privileges, move laterally, and reach sensitive data. It tests segmentation, Active Directory hardening, and detection capabilities. Common for APRA-regulated entities (where segmentation is explicitly tested) and mature enterprises.

The newest category — testing of features powered by Large Language Models against the OWASP LLM Top 10. Covers prompt injection (direct and indirect), training-data leakage via prompts, insecure plugin / tool use by agents, model denial of service, and downstream injection from LLM output. Required for organisations shipping customer-facing AI features as the data-protection authorities increasingly view LLM-driven systems as in-scope for normal application security obligations.

Different goals. A penetration test is bounded — one application or environment, 5–14 days, goal is comprehensive vulnerability discovery. A red team engagement is open-ended — full attack-simulation across your organisation, often months, goal is testing your detection and response (your blue team) as much as your prevention. Most organisations book pentests annually. Only mature security programs with established detection capability run red team exercises — because if you can’t currently detect basic attacks, a red team will simply confirm that, expensively.

Testing of your human attack surface — phishing email campaigns, vishing (voice phishing), pretext-based information disclosure, USB drops, smishing (SMS phishing), and physical tailgating. Measures whether your security-awareness training actually changes behaviour under controlled adversarial pressure. Usually delivered as part of a red team engagement, but can be scoped standalone.

On-site adversary simulation — testers physically attempt to enter your premises, bypass access controls (tailgating, lock picking, credential cloning), and plant rogue devices on the internal network. Specialist scope reserved for organisations with sensitive on-site assets — data centres, critical infrastructure, defence supply chain, high-value research facilities. Rare for general SaaS or FinTech engagements.

Start with your attack surface — what would a real attacker target? For most SaaS / FinTech / HealthTech, that’s web app + API as the baseline. Add cloud if you run significant cloud infrastructure. Add mobile if you ship apps that handle sensitive data. Add network testing if you’re APRA-regulated or have substantial internal infrastructure. Add LLM testing if you’re shipping AI features. A CREST-certified provider should map this to your specific stack during the scoping call — and tell you when you don’t need a particular type.