Different types of pen tests: What do I need for my business?

So, you’ve decided to get a pen test! Let me be the first to congratulate you on your journey to improving your security posture. Pen testing is one of the best ways that you can put all the security measures that you’ve implemented to the test. You get a hacker’s-eye-view of your security and a detailed report of the vulnerabilities identified at the end, including remediation advice. Without further ado, let’s get started on understanding the different types of pen tests! Just one small thing, however, you may be wondering: what kind of penetration test do I need for my business?

Understanding the purpose of penetration testing

I know from prior experience in other IT sectors that this is the way that conversations often go, especially when organisations are buying something that they either only need once or buy infrequently. So often, complex products and services are presented as being ‘simple, turn-key solutions’ that get you ‘onboarded easily’ and are ‘virtually stress-free’.

Why penetration testing isn’t a one-size-fits-all solution

The reality is that things are rarely that straightforward, and not properly setting expectations leads to a less-than-stellar customer experience. Now, the point of this article isn’t to labour on about how complex things can be in IT and cyber security, but if things were as easy as 1, 2, 3, then this blog would have exactly one article on pen testing and I’d be (partially) out of a job.

Helping you ask the right questions about penetration testing

Rather, the point of this article is for me to be a good consultant and ask you the questions that will both help you to understand enough about the world of pen testing so that you can make a decision about what you want and to feel confident about it afterwards.

For everything that you have in your organisation that can be pen tested, including the organisation itself, there’s likely one or more flavours of pen test that will be applicable, and that means that there’s likely one or more specialists that might be needed to test those things.

Penetration testing specialisms: Not all testers are the same

For example, I’m a specialist in web with a lot of deep knowledge of PHP-based web apps and JavaScript-based web apps; I’m pretty solid when it comes to networks, but if you need a desktop application reverse-engineered or your cloud configuration reviewed, then that’s not really in my wheelhouse. But now I’m straying into the realms of resource provisioning and that’s not really what you’re here for…

Nevertheless, I’ll admit, sometimes it is as easy as going ‘I have a WordPress website, can you pen test it please’ and everything can get booked up, signed off and scheduled in a jiffy.

But often there are overlapping areas of equipment and infrastructure that need to be tested, and that might mean that what looks like one pen test actually covers two different specialisms. Or even the opposite, where you’re convinced that you’ll need at least two distinct phases, but the reality is that both things can be covered in one go.

A framework for choosing your penetration test

Rather than picking our way through all the things in a business that can be pen tested, let’s start by looking at the most popular types of pen tests and then discussing what they actually cover.

But first, lets think about our types of pen tests (if you’ve read some of my other blogs then you’ll know that I love a framework) because there’s a couple of axes that we could plot on a graph which will add some tasting notes worth considering to the flavour of pen test you end up going for.

Plotting the purpose of pen testing

In my opinion, pen testing exists as points on the spectrum, depending on what it is that you want tested. This spectrum is heavily influenced by the ultimate goal for your organisation. All types of security assessments seek to highlight any vulnerabilities, and it’s a matter of degrees as to how those vulnerabilities are identified.

Understanding black box, white box and grey box testing

This is the basis of the first axis of our pen testing graph: how much knowledge and information do you want the pen tester to have at the time of testing? From a pen tester’s point of view, we’d ask you what kind of box you want your test to be – black, white or grey.

Unfortunately, these are metaphorical boxes, so you don’t get to keep them at the end of the test. In any case, black box testing is where we don’t give the tester any information, other than the bare minimum to allow them to test the right infrastructure and avoid breaking the law, something that we generally try to avoid.

White box testing is the polar opposite of this: we’re giving the tester all of the information that they could require, and this might even go as far as giving them things like the source code to the application or administrator access to the underlying infrastructure.

So if black box testing is somewhat reticent with the information and white box testing is like a guided, behind-the-scenes tour, then grey box testing is somewhere between the two, where we’re giving the tester more information but not everything. This might be the case where we’re trying to ascertain how much damage can be done from a particular user’s perspective, for example, most internal infrastructure testing falls underneath this.

Audit-style penetration testing: thorough but controlled

From a business perspective, you might want to think of the same scale as having an audit at one end of the scale, and a simulation at the other. Audits can be like white box pen testing: you give the auditor, the pen tester in our situation, all the access that they need to be able to do the work that they need to do.

So, for our audit-style penetration test, your aim as an organisation is to get a thorough, detailed and all-encompassing report of not just the actual vulnerabilities, but also the potential vulnerabilities that might exist within any given system.

In an application, you might want to provide the source code to allow the consultant to run their static analysis tools as well as being able to look at specific areas of code that might be of interest, like session management, data storage and retrieval or authentication. Likewise, during this type of engagement, the consultant might work closely with your development team to ask specific questions around the nature and architecture of the application.

This audit-style engagement can be very interactive,  consultative and not really feel like there’s much ‘hacking’ being done. But as I’m sure you’ve seen by now, the purpose of an audit isn’t to understand how things perform in real-world scenarios. For that, you need a much more simulation-based engagement, which is the other end of our graph.

Classic penetration tests: simulating real-world attacks

Further towards the simulation end of the scale is where we find our classic suite of penetration tests. I say ‘classic’ as we would say these are the type of penetration test that fits what most pen testing companies would sell it as: a methodical, simulated cyber attack against specific systems within your organisation with the goal being to identify, catalogue and exploit vulnerabilities in order to understand how strong the security measures of that system are.

Different types of pen tests

Common pen tests

With a ‘classic’ penetration test, a security consultant (like myself) will use the techniques, tools and procedures of a cyber criminal to find and exploit vulnerabilities that exist, and they’ll use their creative problem solving and somewhat devious thinking to chain together vulnerabilities to gain further access to a system.

On a personal level, we ethical hackers love to completely compromise systems and gain full control over them, so we’ll try to do things like gain unauthorised access, elevate our privileges and get the system to give us information about things it really shouldn’t.

This end of the pen test spectrum is much closer to what you could expect your systems to be subject to were they under a real cyber attack, and that’s a huge part of the benefit of pen tests: they show you a lot of how your systems actually perform under the unwelcome insistence of a cyber criminal. But they’re not full-blown simulations because they are always scoped.

For example, if I’m testing a web application, I’ll have a pre-defined list of URLs that I’m allowed to test. Most of the time, I’ll be testing a pre-production or development version of the application, or I’ll be testing a clone of the live environment.

Will pen testing disrupt our operations?

Pen testing carries a risk of service disruption, and so understandably, many clients don’t want to run that risk. We also recommend giving us access to non-critical environments, especially with web app testing and publicly facing services.

But the bad guys aren’t known for being scrupulous when it comes to picking and choosing their targets and the things that they’re attacking, so they’re likely to use all and any resources available to them.

Real, targeted cyber attacks are likely to be multi-phased and use a mixture of techniques to gain access to the systems, and that includes things like phishing or even just turning up at your office and pretending to be from the electrical contractor (you might want to read my physical pen testing blog for that one).

For criminals, the scope of their activities is as broad as the organisation itself. There is a type of all-encompassing penetration test that simulates a full-blown, coordinated cyber attack. This is called a red team engagement, and it’s a far-reaching, multi-channel, long-term term and extremely targeted cybersecurity assessment. Usually, there will be multiple consultants involved in the engagement, and it’ll take place over weeks, possibly even months.

What is a red team engagement?

Red team engagements tend to have everything at their disposal, short of things like kidnapping and extortion. Consultants might try to gain access to your network via a phishing campaign whilst simultaneously trying to gain the trust of employees through social media.

  If you want to learn more about the topic, view my Red Teaming vlog series for a quick overview. 

They might attempt to clone an access card by camping out in a coffee shop that’s near your office and waiting for an unsuspecting staff member to leave their belongings unattended. Meanwhile, they’ll be probing your company websites and other external infrastructure and cataloguing and exploiting vulnerabilities.

Even things like sending thank-you hampers to team members with malware-infected USB drives aren’t beyond the purview here. Red team engagements are the closest you can get to an ‘all-out’ attack against your organisation as a whole, and an enlightening way to understand how your security posture performs overall.

Now that we’ve established the different intensities of a penetration test, let’s look at the different types of pen test, and see the types of things they’re used to test and where they tend to sit on the simulation scale.

Types of penetration tests and when to use them

Internal Infrastructure Testing

With this type of testing, we assume that an attacker has already made it past the outer defences and they’ve got access to your internal network. This is usually either by compromising a user’s device, exploiting an unpatched internal system, or even gaining physical access to your network and plugging in a reverse shell device. Internal infrastructure testing focuses on things like domain controllers, file servers, printers and other systems that are only supposed to be accessible from inside your organisation.

Internal pen tests are typically grey box—the consultant is given access to the network as if they were a regular user or a compromised endpoint, but generally a regular, low-privileged user. From there, the goal is to see what and how far that access can be abused.

Can we escalate privileges?
Can we move laterally across systems?
Can we access and exfiltrate sensitive data?

A good internal pen test can reveal everything from misconfigured certificate permissions to that vulnerable Windows 2000 server that’s been quietly running in the corner for a couple of decades.

In terms of our pen testing scale, internal infrastructure testing tends to sit right in the centre. It’s more simulation than audit, but it still needs to be scoped and controlled so there’s no social engineering or phishing involved unless it’s paired with a red team engagement.

It’s about identifying the damage that can be done once the attacker is inside the building (virtually speaking), and for that reason, it’s essential for most mid-size or enterprise organisations.

If you’re just starting out with your pen testing journey, an internal infrastructure test is one of the best places to start.

External Infrastructure Testing

I like to think of this as the doors-and-windows test. External infrastructure testing looks at what an attacker can see and do from the outside. Think web servers, firewalls, VPN gateways, email servers and any other exposed admin panels. Basically, if it’s reachable from the internet, it’s fair game.

External pen tests are often black or grey box. You might give the tester a list of IPs or domain names and say ‘see what you can find’, but a lot of external infrastructure is behind a firewall, so in this case you’ll generally whitelist the tester’s IP address, making the test ‘more black than grey’.

Either way, the goal here is to assess how hard it would be for an outside attacker to compromise your systems and how much of a risk your external-facing services really create.

Read our blog on the differences between internal and external infrastructure. 

This type of testing is often what people think of when they hear the term ‘penetration test’ because it generally sits firmly on the simulation side of the scale, and it’s often a company’s first real engagement with pen testing.

It can find all sorts of things from open ports and out-of-date software to exposed credentials or weak login portals, and since this is the most likely point of entry for actual attackers, it’s not only the best place to start with your pen testing, but a key area to cover regularly.

Web Application Testing

If you have a website or portal that accepts user input, then you have a potential attack surface. Actually, let me refine that statement as it’s not quite accurate: if you have a website, then you have an attack surface.

Web app testing focuses on finding vulnerabilities in how your web app handles user input, authentication, file uploads, and all of the features that you’ve built into it. It also focuses on all of the features that you didn’t build into it, so it looks for things like SQL injection, cross-site scripting (XSS), broken access control, local file inclusions and any other bugs and vulnerabilities that might exist.

Web application testing can range from grey to white box, depending on whether you give the consultant credentials, documentation, or even source code.

The more access you provide, the more thorough the test. On the simulation scale, web app tests are middle to high simulation: they try to replicate real-world attacks, but within a defined scope. For example, you might say ‘test everything behind this login page’ or ‘just focus on the admin area only’.

A good web app pen tester needs to understand business logic as well as security flaws. They’re looking for places where functionality can be abused and misused, not just for outdated JavaScript libraries.

Web app testing is a must-have if you’re developing your own software, especially if you provide any kind of Software as a Service (SaaS) platform. Due to the insane amount of variations with web applications, it’s also one of the most technically detailed types of pen tests.

API Testing

APIs are effectively the backbone of modern apps, but they’re easily neglected when it comes to security testing because they’re literally designed to operate in the background. API pen testing focuses specifically on these endpoints, and similar to web app testing, it’ll look at how they authenticate users, validate inputs, handle data access and enforce permissions.

Like web app testing, API testing can be grey or white box. You’ll usually give a tester documentation, test credentials and sometimes even access to API gateway logs or back-end behaviour. A tester will look for things like Insecure Direct Object Reference (IDOR), privilege escalation opportunities, interesting error messages, and any improper business logic flows.

In the audit/simulation scale, API tests can swing both ways. If you’re giving full access and working collaboratively with the tester, it’s closer to an audit. If you’re giving them an endpoint and asking them to break it, then it’s more like a simulation.

Either way, API testing is vital for any company that builds or integrates APIs, especially if they’re customer-facing or they handle sensitive data.

Mobile Application Testing

Mobile app testing looks at Android or iOS apps and how they behave from a security perspective. This includes local storage, API communication, authentication mechanisms, reverse engineering the app package and even seeing how the app handles jailbroken/rooted devices.

Mobile pen testing tends to be a bit of a hybrid. There’s white box activity, like inspecting the decompiled code, and simulation activity, like attempting to intercept traffic or messing around with session tokens. Depending on how deep you want to go, it can sit in the middle or toward the simulation end of our scale.

App testing is one of those areas where it’s easy to overlook issues because you assume the app store vetting process or internal QA processes caught everything. Mobile apps nowadays are often just front-ends to APIs, which can be vulnerable, and it’s quite hard to find that they contain hardcoded secrets that can give an attacker a foothold.

If you have a mobile app, and especially if it’s tied to sensitive operations like making payments or handling personal data, this test should be on your radar.

Cloud Configuration Review

Now we start to gently meander back toward the audit side of things. A cloud configuration review isn’t about trying to hack into your systems; it’s all about reviewing the setup of your cloud services to make sure they’re secure. Think Amazon AWS, Microsoft Azure, and Google Cloud Platform: all of them have their best practices and common pitfalls.

These reviews tend to be white box engagements. You give the consultant access to the cloud console or a snapshot of the configuration, and they assess things like IAM roles, S3 bucket permissions, logging, key management, and network segmentation. No exploits, no payloads; just a thorough, meticulous review.

Cloud reviews are vital because misconfiguration is one of the biggest causes of data breaches. I’ve personally found huge data leaks on application tests due to misconfigured cloud storage permissions. And because cloud platforms move quickly and constantly evolve, what was secure six months ago might not be today.

If your infrastructure is heavily cloud-based, a cloud configuration review should be part of your regular security processes, even if you’re already performing pen tests on the apps that run on top of said infrastructure.

Build Reviews

Another one on the audit end of the spectrum, a build review involves assessing how secure your systems are before they go live. This might include reviewing base images for servers and desktops, container setups or even infrastructure-as-code scripts.

The aim is to catch issues early, before they become vulnerabilities in a running environment, and compare them against known benchmarks like the Centre for Internet Security Benchmarks (CIS Benchmarks).

These benchmarks are heavily detailed and incredibly thorough security baselines for pretty much any information system you can think of; operating systems like Linux, Windows, as well as benchmarks for cloud providers, network devices… The list goes on.

This kind of test is white box by nature and often involves a fair amount of collaboration with DevOps or platform engineering teams. It’s less about breaking in, more about stress-testing your defaults and comparing them to agreed-upon best practices.

If you’re deploying infrastructure regularly, or if you’ve moved toward containerisation and CI/CD pipelines, build reviews are an efficient way to prevent misconfigurations from becoming technical debt.

Vulnerability Scanning

Let’s be clear: vulnerability scanning is not a pen test. But, unfortunately, it’s often sold as one, and that’s where the confusion starts. Vulnerability scanning involves running automated tools against your systems to identify known issues. It’s quick, relatively cheap, and useful, but it’s not a replacement for a trained consultant running a pen test.

On our audit-to-simulation scale, this sits firmly on the audit end. It’s about coverage, not creativity. The tool doesn’t think, doesn’t prioritise, doesn’t chain vulnerabilities together, it just reports what it finds. The real value comes when someone interprets those results and turns them into actionable fixes and/or cool hacks to brag to their teammates about.

That said, vulnerability scanning still has its place. It’s great as a regular hygiene check, and many organisations run scans weekly or monthly. As a tester, I always include vulnerability scans in my tests. But it should be paired with real testing, ideally done by humans and at regular intervals.

Red Teaming

Finally, the grandfather of attack simulation: the Red Team. Red team engagements simulate full-scale, multi-vector, determined attacks against your organisation. The team can use phishing, social engineering, physical intrusion, network exploitation, web app flaws and pretty much anything they can get their hands on in order to breach your defences.

Red teaming is black box by default, though occasionally there may be some grey areas depending on the scope. It’s long-form, targeted, and resource-intensive. The idea is to test not just your systems, but your processes, your people and your detection and response capabilities.

Red teaming sits way out there at the far end of the simulation scale. It’s as close as you can get to a real-world attack without actually being breached. The goal isn’t just to find vulnerabilities, it’s to demonstrate how an attacker could exploit your organisation end-to-end.

If pen testing tries to break into the vault, then red teaming actively tries to steal the gold. If you’re mature in your security journey and want to test your ability to detect and respond to active and persistent threats, then this is the engagement for you.

Your quick guide to different types of pen tests: What do you need?

	24x7 Continuous Security Monitoring Our services provide 24x7x365 automated security monitoring to detect threats and respond to incidents in real time.
	Incident Containment & Response Our security analysts will triage, investigate and mitigate incidents, and escalate to your team as required.
	Out of Hours Response & Escalation High and critical severity alerts are escalated and responded to around the clock by experienced security analysts.
	Standard & Custom Detection Rules We deploy our library of standard detection rules and create custom detections for your organisation.
	Security Orchestration & Automation We configure automation and orchestration playbooks to respond to incidents faster and reduce false positives.
	Engineering & Customisation Our engineers will configure, tune and adjust your monitoring environment to maximise security coverage.
	Threat Enriched Monitoring Logs and alerts will be enriched and contextualised using threat intelligence to improve detection accuracy.
	Defined Service Targets We monitor service performance using Mean Time to Respond and Mean Time to Notify service targets.

Conclusion

The question ‘What kind of pen test do I need for my business?’ doesn’t have a one-size-fits-all answer. It depends on what you’re trying to protect, who you’re trying to protect it from, how mature your existing security is and what kind of actionable insight you’re hoping to gain. Sometimes you’ll need a single test, clearly scoped.

Other times, you’ll need a blend of approaches to get a full picture. The trick isn’t just choosing from the menu—it’s knowing why you’re ordering what you are. If you’re not sure, then any good security partner will help you figure out what you need and what you don’t. They’ll ask the right questions, explain the options, and make sure the test you get is the test you need.

So if you’ve made it this far, congratulations again! You’re not just planning a pen test, but you’re planning it properly.

And if you’re tasked with getting a quote for ‘a pen test’ with no added details, you now know that you have to ask: what kind of test, for what purpose, and what does it simulate?

You’re taking control of your security and testing it with intention.

Ready to talk about your penetration testing objectives?

Get in touch with our expert team who can help guide you in the right direction for your business.