The Map of Security Assessments: Which Assessment Answers Which Question?

Part 1 of this series was about the wrong first question: many companies choose a type of assessment before clarifying what they actually want to find out. Today is about the right order – first the question, then the assessment.

Because the different types of assessments are not interchangeable variants of the same product. Each one answers a different question. And once you sort them by these questions, the jungle of buzzwords turns into a map.

Question 1: "Are we vulnerable?"

This is the question about weaknesses – in systems, applications and configurations. Most technical assessment types live here, and they differ primarily in depth and effort:

Vulnerability scan: Automated, broad, repeatable. Finds known vulnerabilities and obvious misconfigurations across the entire network – but without verification and without chaining. The scan tells you where potential gaps are, not how far an attacker could get with them. In return, it costs a fraction of what manual assessments cost and can be repeated regularly.
Vulnerability assessment: Scan plus manual evaluation. The results are verified, prioritized and put into your context – without active exploitation. The sensible middle ground when a raw scan report would overwhelm your team.
Attack Surface Management / Threat Exposure Management: The continuous view from the outside: what an attacker can find about you on the internet is captured on an ongoing basis – from exposed systems and services to forgotten subdomains to OSINT information such as leaked credentials. It builds on automated scans but goes beyond them: the results are verified, so you work on real exposures instead of noise. The answer to a question too few companies ask themselves: What do we actually look like from the outside – today, not at the time of the last pentest?
Penetration test: Manual, targeted, with exploitation and chaining of vulnerabilities. A pentest answers what the scan leaves open: what can an attacker actually achieve with these vulnerabilities? In return, it is limited to a defined target – an application, a network segment, an API, a mobile app. Depth instead of breadth.
Source code review: Looking into the source code finds what dynamic testing can hardly reach: logic flaws, insecure cryptography, hidden backdoors in dependencies. Particularly valuable for software you develop yourself – and as an integral part of an SSDLC.
Threat modeling and architecture review: The preventive variant of the same question: Are we vulnerable – by design? Instead of testing finished systems, the architecture is analyzed before (or while) building. The cheapest vulnerability is the one that never makes it into production. And threat modeling pays off retrospectively as well: for existing systems, it creates a structured overview of architecture and attack surface – valuable input for selecting and scoping further assessments.

Question 2: "Would we notice an attack – and respond correctly?"

Here it's no longer about individual vulnerabilities, but about your organization as a whole: detection, response, processes, people.

Red teaming: A goal-oriented attack simulation over weeks, against technology, people and processes simultaneously – with defined objectives ("crown jewels") instead of a scope list. A red teaming engagement doesn't measure how many vulnerabilities you have, but whether your defense works as a system. Which is exactly why it's the wrong choice when the fundamentals are missing – more on that in part 3.
Purple teaming: The collaborative variant: attack techniques are played out together with your blue team, and detection gaps are closed directly instead of merely documented. If your goal is improving detection (rather than testing it), purple teaming is often the more efficient path.
Phishing simulation and social engineering: The human factor, viewed in isolation – as a standalone assessment or as a component of a red teaming engagement.

Question 3: "Do we meet requirements?"

The third group of assessments doesn't measure against attackers, but against standards and regulations:

Audit (e.g. ISO 27001, TISAX, BSI IT-Grundschutz): Examines processes, documentation and evidence against a standard. A passed audit proves that your management system works – not that your systems can withstand an attack. Confusing the two is one of the most expensive mistakes in practice.
Gap analysis and maturity assessment: The comparison of your current state against a framework or regulation (NIS2, CRA, DORA) – typically the entry point before a certification or implementation project starts.
Configuration audit / hardening review: Comparing individual systems against benchmarks such as CIS or BSI guidelines. Technical, but without attack simulation – and often the fastest way to make a network measurably more secure. This is exactly the assessment that would have benefited the company from the AD anecdote in part 1 more than the assessment they commissioned.

The Three Most Expensive Mix-Ups

From this map follow the distinctions that go wrong most often in practice:

Scan ≠ pentest. If you buy a "pentest" and receive an annotated scan report, you've paid too much. If you commission a pentest even though you've never scanned and patched, you've also paid too much – the pentester will only find what the scan would have found for less. The printer anecdote from part 1 sends its regards.
Pentest ≠ red teaming. A pentest looks for as many vulnerabilities as possible within a defined scope. A red teaming engagement looks for one path to the objective – and in doing so primarily tests your detection and response. If you want "all vulnerabilities in the web application", you need a pentest, not a red teaming engagement.
Audit ≠ technical security. A certificate on the wall doesn't stop an attacker. Conversely, even the best pentest is no substitute for a working management system that anchors security for the long term.

From Goal to Assessment

As a short version of the map – once you know your goal, you'll find the matching assessment here:

"We want an overview of our vulnerabilities" → vulnerability scan or vulnerability assessment
"We want to continuously know what we look like from the outside" → Attack Surface Management / Threat Exposure Management
"We want to know whether our new application can withstand an attack" → penetration test, complemented by a source code review
"We develop software and want security from the start" → threat modeling and architecture review within the SSDLC
"We lack an overview of our own system and its architecture" → retrospective threat modeling that makes architecture and attack surface visible in a structured way – complemented by Attack Surface Management for externally reachable systems
"We want to know whether we would survive a real attack" → red teaming – provided the fundamentals are in place
"We want to improve our detection and response" → purple teaming
"We need evidence for customers, partners or regulators" → audit or gap analysis
"We want to become measurably more secure, fast" → hardening review with clear remediation measures

What's still missing from this map is the second dimension: your maturity level. Because the very assessment that's exactly right for one company is money down the drain for another.

That's what part 3: The Maturity Staircase will be about in the coming days – which assessment makes sense at which stage, and how to tell where you stand.

Not sure which question you actually want answered – or which assessment fits it? That classification is precisely part of my consulting: selecting the most effective measures within the SSDLC as well as in security consulting aimed at increasing your resilience. Get in touch before you commission – not after.