Adjusting Security Testing to the Organizational Context has three parts: how organizational structures shape security testing, how government regulation such as GDPR (General Data Protection Regulation) shapes security policies and what that means for testing, and — the centre of gravity — analyzing an attack scenario. That last section walks the attacker's own route: information gathering and reconnaissance, both passive (public web content, search-engine dorking, social media harvested for spear phishing) and active (vishing, dumpster diving, port scans, operating-system fingerprinting, DNS enumeration, vulnerability scanning, open-source intelligence), then detection through NIDS (network intrusion detection system) and log analysis, the range of attacker types from script kiddies to politically motivated groups, and denial-of-service attacks.
This is one of only two chapters carrying an analysis-level (K4) learning objective, and the attack-scenario objective is the single most valuable topic on the paper per question asked — those questions weigh more than the rest. It is also, with chapter 4, the heaviest by official study time, while being asked relatively rarely: the volume of material is not proportional to the number of questions. Spend the time on reasoning, not recall. You will be given a scenario and asked to infer plausible attack sources and motivations, which means recognising which reconnaissance step leaves which trace.
Passive vs active reconnaissance — reading public sources touches nothing; a port scan or DNS enumeration interacts with the target and can be detected.
Motivation vs capability — a scenario can point to who would want this and to who could manage it; the analysis objective asks for both, and they rarely coincide.
Vishing vs phishing — voice-based pretexting is counted here as active information gathering.
Vulnerability scanning as reconnaissance — the same activity is a test in chapter 2 and an attacker's step here; context decides.
Regulation vs policy vs test — GDPR imposes obligations, the organization writes policies from them, and only then can a test verify the implementation.
A rootkit is persistence, not intrusion — it hides an attacker already inside; it is not the entry mechanism.
Structure changes testing — who reports to whom decides who may authorize, see and act on security test results.
Detection is specification-bound — a NIDS reports what it was told to look for, so "no alert" is not "no attack".
This chapter is covered most heavily (4 questions) in CT-STE — Mock Exam 1 (Zero Trust, Access Control & Threat Modelling), CT-STE — Mock Exam 2 (Attacker Profiling, DevOps Pipelines & Standards as Oracles), CT-STE — Mock Exam 3 (Reconnaissance Analysis, Standards & Regression)