How do the four activities compare?
The four activities compare differently because they look for different evidence and produce different decisions. Finding an old software version, proving an attack path, investigating possible compromise and estimating business loss are separate tasks.
The investigation may use IDS, SIEM and EDR capabilities, but the tool name doesn’t replace the purpose of the activity.
Scroll sideways to see every column.
| Activity | Main question | Typical output | What the result doesn’t prove |
|---|---|---|---|
| Vulnerability scanning | Where might weaknesses exist? | Potential findings and affected assets | That every finding is exploitable |
| Penetration testing | Can an authorised attack achieve an objective? | Validated paths, evidence and recommendations | That no other attack path exists |
| Threat hunting | Is hidden malicious activity present? | Investigated leads and evidence | That the environment is certainly clean |
| Risk assessment | How likely and costly is the scenario? | Risk estimates and treatment priorities | That an attack will occur on a schedule |
What does a vulnerability scan actually establish?
A vulnerability scan establishes potential findings that need interpretation and, where appropriate, validation. It may identify exposed services, known vulnerable software or configuration issues. NIST SP 800-115 discusses security testing and assessment methods.
An unauthenticated scan sees what is exposed from its vantage point. An authenticated scan can inspect more local detail using an approved account, subject to its permissions. These views complement each other.
A version match can be wrong if a vendor backported a fix without changing the visible version string. A scanner can also miss a weakness, especially outside its checks or visibility. Validate findings and consider business context before treating every result as equally urgent.
Interpreting an exposed service starts with its protocol, port and expected use.
A finding about password storage needs an accurate distinction between hashing, encryption and encoding.
What makes penetration testing different from scanning?
Penetration testing tests whether an authorised attack can achieve a defined objective within agreed rules. It may use scan results, but its purpose is to investigate and validate attack paths rather than simply collect a finding list.
For example, a tester might show that a weak service account can reach sensitive records after several permission steps. That chain is more useful than a list of disconnected warnings. The report should explain the evidence, business effect and fixes.
Written authorisation, scope, permitted techniques, timing and stop conditions matter. A test against production systems can interrupt service or expose data. Permission to scan one server isn’t permission to attack every connected system.
A clean result is bounded by scope, time and methods. It doesn’t establish that no weakness exists anywhere.
Attack paths often cross firewall and segmentation boundaries, so document the connections the test actually validated.
A service-account finding may concern authorization rather than authentication if the account can reach more data than its role needs.
How does threat hunting differ from incident response?
Threat hunting proactively investigates a hypothesis about malicious activity that may have escaped routine detection; incident response manages a suspected or confirmed incident. Hunting can trigger response when it finds evidence.
A hunter might ask whether unusual service-account activity signals persistence. They examine identity logs, endpoint events and other evidence, compare it with normal activity and refine the hypothesis. Microsoft’s hunting documentation describes proactive queries over security data.
Hunting isn’t scanning a subnet for missing patches. A scan asks about weaknesses; a hunt asks about activity or compromise. It also isn’t random searching: a useful hypothesis identifies what evidence would support or weaken it.
For an account-focused hunt, compare spraying and credential-stuffing patterns with the login evidence available.
Suspected certificate or signing-key misuse requires a clear account of public and private key roles.
What does risk assessment add to technical findings?
Risk assessment connects a scenario to likelihood, business impact and existing controls so the organisation can choose a response. A technical severity score is one input, not the whole decision.
A flaw on an isolated training machine may have less business effect than a moderate weakness on a public service handling customer payments. Exposure, asset importance, attacker capability and control strength all change the picture.
NIST SP 800-30 sets out a risk-assessment approach. Risk treatment can include reducing risk, avoiding an activity, sharing some risk through arrangements such as insurance, or formally accepting it. Insurance doesn’t remove the technical weakness.
For numerical practice, work through ALE, SLE and ARO.
How should these activities inform each other?
They should share evidence while keeping their purposes clear. Scanning can identify a candidate weakness; a scoped test can validate an attack path; a hunt can check for evidence that the path was already used; risk assessment can guide the response.
That sequence is an example, not a rule. You might start with a business risk review, or with a hunt after receiving credible threat information. Choose the activity that fills the current evidence gap.
When a question asks for the best next step, look for whether the team needs a weakness inventory, validated exploitation, signs of compromise or a business decision.
The same purpose-first approach helps with PBQ evidence and response tasks.
