Get in touch with us
We at accompio will be happy to help you.
15.09.2026
Vulnerability scan, pentest and red teaming: three terms that are frequently mentioned alongside each other in the field of cybersecurity. Yet although all three methods are designed to help improve a company's IT security, they pursue different objectives.
Whilst a vulnerability scan automatically searches for known technical vulnerabilities, a pentest goes considerably deeper and checks which vulnerabilities are actually exploitable. Red teaming, on the other hand, does not primarily focus on finding individual vulnerabilities. The aim here is to simulate a realistic attack and check, how well a company detects and responds to such an attack.
Fabian Mosch, Head of Offensive Services at r-tec (part of the accompio group), and his team conduct various attack simulations for clients. In an expert interview, he explains the differences between the three testing methods, where companies often have false expectations, and when each approach is appropriate.
Which test method matches which security objective? Fabian Mosch explains in the video how vulnerability scanning, pentesting and red teaming differ in terms of approach, depth and outcome.
The transcript was created from the subtitles of the expert interview and edited for spelling and special characters.
00:06 Three tests, three truths: scan, pentest and red teaming
We have a new accompio focus topic for you. A warm welcome! Today is all about three tests and therefore three truths: vulnerability scan, pentest, and red teaming. And all of this with Fabian Mosch. A warm welcome! Would you like to briefly tell us who you are, what you do at accompio, and yes, what this topic is, why we are so burning with interest in it today?
00:27 Fabian Mosch and Offensive Services
Yes, my name is Fabian Mosch. I am Head of Offensive Services. I lead the team that carries out attack simulations of all kinds within the company for our clients. These are both technical attack simulations and vulnerability assessments, as well as human ones. And exactly, among other things we do vulnerability scans, pentests and red teaming projects. And why we are so interested in this is because usually these three tests are lumped together a bit, aren't they?
00:49 The difference between vulnerability scanning, pentesting and red teaming
Also companies are very quick to say, oh, which of these now or how I combine it doesn't matter really, but they actually have completely different goals. What is the difference between these three tests? Well, let's put it this way, it's not just the companies that mix this up, it's actually also the service providers that mix this up, or service providers that sell one as the other on the market. Unfortunately, that's, unfortunately that's how it is, but unfortunately that's the market. With a vulnerability scan, the whole thing is done completely automatically by software. That means you actually have no effort at all and therefore low costs.
You basically enter which systems should be checked, press start,
01:28 How an automated vulnerability scan works
wait a few minutes, have results and you can then hand those results over to the customer. That means you can check a lot of systems in a very short space of time and then have an overview. However, that doesn't really go into depth. With a pentest, it's also about doing the whole thing. So on the one hand, there's a human behind it, you first look at things in an automated way and afterwards the human reviews it and practically filters things out and checks what can actually be exploited, what cannot be exploited, and also approaches it with logical thinking and considers what else I can exploit now, rather than just running software, and really going through the attack paths from front to back.
That means you have more vulnerabilities, you have a more in-depth check.
02:08 What is additionally tested in a pentest
But of course it’s a bit more expensive and involves a bit more time, because there’s a human behind it and the human element is involved. And red teaming isn’t about finding technical vulnerabilities at all. It’s not even primarily about finding vulnerabilities at all, but rather about seeing how attack detection works. How quickly am I at detecting attacks? When do I detect them and how can I perhaps also improve my attack detection? And what you’ve just described – we’ll be getting into a bit more detail on that shortly – are those actually the expectations that companies have, or where do they often get it wrong?
02:40 What is the objective of red teaming
Yes, I would say that in most cases it actually isn't like that, because in most cases we encounter companies that may have previously done pentests with other service providers and were of the opinion that they had done a pentest. Then they did a pentest with us, had completely different results presented to them and were surprised. And when we then saw the reports from the other companies,
03:00 Why the test methods are frequently confused
for example, or having spoken with the client, we saw relatively quickly that these are vulnerability scan results. There is nothing there that a human found, but rather these are all things that were found by the software and they were sold as a pentest. Unfortunately, that happens often because then you can sell it quickly and cheaply, write pentest on it, but actually it was just a scan. On the other hand, we also have clients who say, I'd like a vulnerability/pentest scan or a red team test. That means they don't know what one is? They don't know what the other is? Exactly there, the terms are all just mixed up.
I heard somewhere once that I can have an attacker simulated and then they use one word or another, but don't even know themselves yet what lies behind it. And then we just explain that initially in presales. And it can also be that a company has said they actually want to do a red teaming project because they've heard the term somewhere, and in conversation it turns out, oh no, they actually want to do a pentest. Then we explain it again very briefly now. So vulnerability scan, let's start with that, is rather limited. You just said that. What exactly does a classical vulnerability scan achieve?
04:00 Typical vulnerability scan results
So, what are the typical products, manufacturers like Tenable Nessus would be an example for that. What they do, ultimately, is look for open services, meaning they scan IPs or domains and look for services. Let's say I've found a web server or I've found an SSH or an FTP or something else. They also check version numbers, meaning they check: I found this in such and such a version and automatically compare that with vulnerabilities that can be found online and then say, okay, I found the outdated version, there's the vulnerability, that can be exploited and show that to you, they partly also have the logic built in to exploit vulnerabilities.
So then they just use it to show that it's there. But they can also give you things like, I've got some outdated encryption or something similar. Exactly. But they don't really go into depth, because everything that, yeah. That then brings a risk with it. Right, if I now exclusively carry out vulnerability scans? Yes, I'd say if you only do that and rely on it completely, that's a false sense of security. Let's put it that way. Because then I believe,
05:08 Where automated scanners reach their limits
Right, I've tackled all of those vulnerabilities. Now everything is green. That's actually really difficult too. Nowadays, getting a vulnerability scanner to show everything as green and completely free of vulnerabilities takes a huge amount of time. But in most companies, when we run a vulnerability scan over the internet or internally, we can, I'd say, not exploit 90 % of things in reality. So 90 % of these vulnerabilities shown by a scanner cannot be exploited by us as attackers at all because there are no details and no exploits, meaning no software to take advantage of these vulnerabilities.
And well, if you don't have someone who takes a close look at it and knows what of that is exploitable and what isn't, then I think that gives a false sense of security, or you can also waste too much time fixing things that don't really get you very far. And there are vulnerabilities that aren't even recognised at all. What kind of vulnerabilities are those typically? Well, you have to look at the different areas.
06:00 What additional insights a pentest provides
So, let's say, in a web application, a scanner can't see if I have a document download function and there is an ID—let's say this document with the number 106 is my payslip—then I can go into the web application and change the 106 to 805 and then view another employee's payslip. A scanner, a piece of software, cannot find that at all. Purely logically, purely technically, because it can't distinguish: Is this a document for me? Is this a document from another user? That means you somehow need a human to look at it, to assess it, just to be able to say whether this works or doesn't work.
And that is what I then have with the pentest, where I have a targeted, manual check. Correct, exactly. So what does that essentially consist of? Then such a pentest. So it's again a question of what you're checking. With a web application, we just had that example. Let's say we come via the internet and try to get into the company via the internet. With a scanner, it would now tell me there's a patch version that is out of date, there I have a vulnerability and update that. When we do a pentest, we would probably rather say John Doe has a password.
07:00 An attacker's perspective
Summer 2026 exclamation mark. We guessed that. That's why we got in and after that we were able to achieve this and that with it. That is just a vulnerability. A scanner is not going to go ahead, create an email list, guess passwords and try to get into the company. I think that's utopian. It's also probably associated with certain risks if it tests that automatically. That's why we do it in a controlled and manual way. But there are also differences in quality, it has to be said, with pentests. What factors determine the quality then? Blimey, that's naturally on the one hand probably the question of the experience of the people doing it, I can imagine.
Well, on the other hand, perhaps what kind of tools, what kind of instruments are used. Yes, but I think the primary things are what kind of experience is behind it, what kind of team is behind it, what kind of knowledge base might they have, what kind of proprietary tools and techniques do they have? How long have they been on the market? Do they maybe already do research or something like that, do they publish their own things? I think those are criteria by which you can at least tell whether there is more quality behind it or if it's rather just a run-of-the-mill scan being sold as a pentest? What difference do I then still have to red teaming?
So then I actually have realistic attack simulations, right? We sell realistic attack simulations as a separate project.
08:20 Red Team and Blue Team working together
There we do, so to speak, the pentest approach, very loud, and very, so very, very fast in order to achieve as much as possible. With red teaming, it's more the case that we try not to be detected. Ah right, okay. We are given the objective of trying to get into the corporate network or spread within the corporate network. We are given some kind of objective to work with. That could be, try to access the CEO's mailbox, try to access the payroll, try to access this, that, or the other. That is your goal. We try to work our way along that. It's not about finding as many vulnerabilities as possible and providing the client with vulnerabilities, but rather it's solely about us achieving our goal while avoiding detection as much as possible.
And on the other side for the Blue Team. The Blue Team are basically the people who work in the SOC. In the Security Operations Center, they are the ones who analyse, assess and evaluate the alerts, the warnings when an attacker is present. For them, it is about detecting that we are on the network, that we are trying to exploit certain things, and also kicking us back out again. That means noticing this and, on the other hand, reacting and taking active measures to get us back out. And precisely then, it is about how quickly that worked.
09:30 Which test method suits which company
Were certain things overlooked? Were they not recognised? Can some things simply not be recognised from a technical standpoint because certain logs are missing, for example? And things like that can be found out through a red teaming project. That's already a lot of results that the other tests just don't offer, right? Exactly. And I really look in every direction. So I look at the technology, the processes, the people. Everything is included. It's the complete chain. It's the complete chain from A to Z. In most cases in a project like this, the blue team isn't informed in advance either, but only individual, select people in the company are involved, and they then know whether it's a real attacker or the red team, so they can check and compare.
Because if a real attack happens in parallel to a project like that, you obviously need to be able to tell the difference and assess it too. Exactly. But that's why the people also have to work under precisely these, this sort of pressure situation, just as if a real attack were actually happening, until it's eventually clarified. Once it's clarified, yes, you then have to consider how to approach the whole thing further. From that moment on, the mindset of the defenders naturally shifts too. How do I react? But if we now take these three methods, let's say, or these three tests
10:40 How often tests are useful
Comparing them, which method would you say is now best suited for what, and where do they perhaps complement each other quite well? So I would say a scan is suitable for any company. Yes, most of our clients also run scans on their own environment themselves. That means they have bought scanners themselves and scan their own environment, so that when we carry out a scan, we find almost nothing at all. That is why this is also usually the least frequently chosen project with us, that someone wants to carry out a scan, because that is relatively easy to do oneself. Um, a pentest, I would say, is fundamentally suitable for any company that can already muster some sort of budget for it.
The very small businesses usually can't manage it. So you really have to spend at least €5,000 to €10,000 for a project like that, and having an open budget every year, that's also only possible from a certain company size onwards. If you can do that, if you have the budget, or if you plan for it permanently, then it definitely makes sense. Because then you get your hands on completely new insights. And Red Teaming is actually only worth it if you already have a Blue Team, if you already have a Security Operations Center. If you already think, I can detect attacks, I've built something up there, and if you want to test whether that actually works.
That means doing a red team project when you don't have a blue team at all and don't have any attack detection at all doesn't make all that much sense. At most, to tell management, you're not detecting anything. That's why you should perhaps establish that first. And how often should I do tests like that then? The respective ones? Exactly, scans can basically always be done? Theoretically you can run those daily, also to see what gets fixed when? In reality, daily is exaggerated. In reality, you can perhaps do that every few weeks or once a quarter. Internally, externally and then make a comparison, which vulnerabilities are still there, which have been newly added, which are dropping away?
That means you can do that very regularly, and it's also completely automated. I'd recommend a pentest every—well, that also varies from company size to company size. Some of our clients do 100 to 200 days of pentesting a year, which works out to about 10 or 20 projects. Some do one pentest a year, and some do a pentest every two years.
12:50 How companies continue working with the results
I think the important thing is just that you do it repeatedly, that you don't just do it once. That you stick with it. And that you do it again after a certain amount of time, because it's always a snapshot. It's always the point in time at which we checked what was achievable there. And that can change, of course. In a month, in a year, if you don't do it at all for several years, you'll probably no longer have a lot of things on your radar. Yes, and now I'm gaining a whole lot of insights from these tests. What do I ideally do with them? Ideally, both vulnerability scanner results and pentest results are each recorded as a security incident in the process.
That means, people say, I have a problem here, I have a security problem here, this needs to be addressed, it will be recorded somewhere in the ticketing system. It has to be worked on by someone, it has to be tracked, it has to be addressed, it has to be fixed. The measures have to be tackled and that's how it should be integrated into the complete process. In his experience, is that how it's done? Frequently not. I believe. At least not from what I've experienced. If a company is well set up, and does this frequently, then they do do it that way. There are also some cases where the report is simply forwarded to the IT department and they're told, sort it out!
14:00 Why tests do not replace a security process
And perhaps it will look similar after a year or two. Or half of it has been fixed and the other half hasn't. That's why, exactly. But we also need to clearly state once again that tests alone do not constitute ongoing security processes, do they? So I can't just rely solely on my tests. No, I mean, outside of pentests, outside of scans, outside of red teaming, there are various things that a company must and should have on its radar in the security environment. And for that, there are certainly many other interviews with other people too that give you all of that. But the things a company must have on its radar are much more than just run a scan, run a pentest.
There's a lot more to it than that, but that would go beyond the scope. That's what the other talks are for. That's exactly how we'll do it. Everything is evolving. The attackers, the technologies, the processes. Where do we have to expect these tests to evolve?
15:00 How attacks and pentests are changing
Well, as for us, we at least always try to represent that with our tests. Well, not with vulnerability scans, they just develop the way they are further developed by the manufacturer and what they build in. With pentests, we always try as much as possible to mirror what we also see in the world and what we also see in incidents and what we see being exploited where and how. That means, for example, bringing more and more artificial intelligence into the tests, for instance, because that is precisely what is currently emerging and that is what allows you to find new, different attack paths than before. Exactly. We just always try to stay as up to date as possible and to keep our projects up to date accordingly.
How exactly that will develop? Things are certainly moving very fast. As we're actually coming to a close now, could you summarise each of these test methods for us in one sentence? Let's start with the vulnerability scan again.
16:00 The right method starts with the safety goal
Also, vulnerability scanning across a very large number of systems in a short space of time and at low cost: getting a good initial overview of vulnerabilities, technical vulnerabilities. A pentest involves a bit more effort and slightly higher costs. A deeper analysis on a not quite so large scope. Somewhat fewer systems, but in return with new, different insights that you wouldn't otherwise gain and that you couldn't otherwise technically detect with software alone. And with red teaming, unlike the other two, the primary aim is not to find vulnerabilities, but to evaluate attack detection, to see what is detected when and how, what further measures should be taken, or how the process should be optimised to detect things better.
So a completely different objective. Yes. But they still have a common goal, namely to improve IT security.
17:00 Conclusion
At best. Fabian, thank you very much indeed for the conversation. Thank you very much indeed for watching and listening. We look forward to seeing you again at the next accompio Focus-Talk.
A Vulnerability scan is largely automated using software. The company defines which systems are to be checked, starts the scan and subsequently receives an overview of identified vulnerabilities.
For example, this involves identifying open services, software versions, or known security vulnerabilities and comparing them against publicly known flaws.
The big advantage: Many systems can be checked in a short time. This makes a vulnerability scan well suited for regular checks and a quick overview of the technical attack surface.
However, an automated scanner does not really go into depth. It can certainly identify a potential vulnerability, but cannot always assess whether and how it can actually be exploited in the specific environment.
At Penetration testing, brief Pentest, humans also come into play.
Here too, automated tools can be used initially. A pentester then analyses the results and specifically checks which vulnerabilities are actually exploitable. This is not just about individual technical vulnerabilities, but also about tracing potential attack paths from start to finish.
An example from the interview illustrates the difference: a scanner can detect an outdated software version, whereas a pentester can additionally investigate whether this can actually be used to gain access to the company. Furthermore, they check what subsequent steps would be possible thereafter.
Logical vulnerabilities can also play a role. For example, if a web application does not correctly distinguish between different users' documents, human understanding of the application context is necessary for this.
At Red Teaming the objective shifts significantly once again.
The primary aim is not to find as many vulnerabilities as possible. Instead, the red team simulates a realistic attack with a specific objective: for example, gaining access to a particular mailbox or to sensitive corporate data.
In doing so, the team tries to act as inconspicuously as possible and avoid being recognised.
On the other side is the blue team, such as the security operations centre. Its task is to detect and assess activities and initiate appropriate countermeasures.
This allows a red team project to demonstrate:
Red Teaming therefore considers the entire attack chainfrom technology and processes through to people.
„Red teaming is not about finding as many vulnerabilities as possible. It is about achieving our objective while remaining as undetected as possible.“
Fabian Mosch, Head of Offensive Services at r-tec (part of the accompio group)
Offensive Security is the overarching approach of examining security measures from an attacker's perspective. A penetration test manually investigates a clearly defined scope for exploitable vulnerabilities and attack paths. Red teaming, on the other hand, simulates as realistic an attack as possible with a specific objective, testing above all how well detection and response function. A vulnerability scan complements these approaches as an automated inventory of known technical vulnerabilities.
The question is therefore not which test is fundamentally the „best“. What matters is, what research question a company wants to answer.
A vulnerability scan is fundamentally suitable for any company and can be carried out regularly. It provides a quick overview of technical vulnerabilities and can also be operated by companies themselves.
A pentest goes a step further. It is particularly useful when a company wants certain systems or applications to be tested in a targeted and more in-depth manner.
Red teaming, in turn, requires a certain foundation. Anyone who does not yet have a functioning blue team or established attack detection can only gain limited insights into their quality through a red team project.
For vulnerability scans, Fabian Mosch recommends carrying them out regularly. Depending on the environment, scans can take place every few weeks or once a quarter, for example. This makes it possible to track which vulnerabilities are new and which have been fixed.
In pentests, the frequency depends more heavily on company size, scope and individual requirements. Above all, the crucial factor is that a pentest not as a one-off snapshot is being considered.
Because IT environments are continuously changing. New systems, applications and configurations can create new vulnerabilities.
By contrast, Red Teaming focuses less on a fixed frequency. It is particularly useful when corresponding detection and defence structures are already in place and their effectiveness needs to be realistically tested.
A test alone does not improve IT security. What matters is what happens with the results afterwards.
Vulnerabilities from scans and pentests should therefore be integrated into existing security and IT processes. This includes, for example, documenting identified issues, assigning responsibilities, planning measures and tracking their implementation.
A report that is merely forwarded to IT is not sufficient for this.
Equally important is the realisation that scans, pentests and red teaming replace a complete security process. They are individual building blocks within a broader security strategy.
| Vulnerability scan | Pentest | Red Teaming | |
| Destination | Find known technical vulnerabilities | Check exploitability and attack paths | Testing threat detection and response |
| Procedure | Automated | Automated + manual | Realistic attack simulation |
| Scope | Many systems possible | Defined, smaller scope | Specific target |
| Depth | Overview | In-depth audit | entire attack chain |
| Focus | Technology | Technology + human analysis | Technology + processes + people |
| Result | Vulnerability overview | Detailed attack vectors | Insights into Detection & Response |
accompio supports companies in choosing the appropriate security approach and testing their infrastructure accordingly.
Vulnerability scans, pentests and red teaming pursue different objectives. Precisely for that reason, they complement each other.
The Vulnerability scan quickly provides a broad overview of known technical vulnerabilities. The Pentest goes deeper and shows which of these vulnerabilities are actually exploitable and what attack paths can result from them. This Red Teaming finally considers the perspective of a realistic attacker and tests how well a company detects and responds to such activities.
This means all three methods are justified. The crucial thing is not to carry out as many tests as possible, but rather to use the right method for the specific question and then translate the insights gained into concrete improvements.
In the end, all three approaches have the same goal: to sustainably improve IT security.
Fabian Mosch is a security expert at r-tec (part of the accompio group) and knows how companies can put their IT security to the test.
A vulnerability scan automatically searches for known technical vulnerabilities. In a pentest, an expert also analyses the results and checks manually which vulnerabilities are actually exploitable and what attack paths result from them.
A pentest focuses on the technical security of a defined scope and the exploitability of vulnerabilities. Red teaming, on the other hand, simulates a realistic attack as far as possible, primarily to test the organisation's ability to detect and respond to attacks.
No. A vulnerability scan provides an important overview, but it cannot detect all types of vulnerabilities and cannot reliably assess which of the vulnerabilities found are actually exploitable. It should therefore be understood as part of a more comprehensive security process.
That depends on the company size, the system tested and individual requirements. According to Fabian Mosch, the most important thing is to repeat pentests regularly, as an assessment always represents merely a snapshot of the respective IT environment.
Red Teaming is particularly useful when a company already has structures in place for attack detection, such as a blue team or a security operations centre. It then allows for a realistic test of whether attacks are detected and appropriate countermeasures are initiated.
