7.3. Test Output Analysis and Reporting
💡 First Principle: Raw vulnerability data is not actionable intelligence. A scanner that reports 2,000 findings across your environment has told you nothing useful until those findings are classified by exploitability, mapped to asset criticality, and translated into a prioritized remediation plan that resource-constrained teams can actually execute. The gap between "findings" and "fixes" is where most security programs fail — not because they lack detection capability, but because they lack a triage framework that connects technical severity to business impact.
Security assessment output serves two fundamentally different audiences: technical teams who need to know what to fix and how, and business leadership who need to know what it means and what it costs. Reporting that speaks only one language fails the other audience — and security programs that cannot communicate risk to executives cannot secure budget for remediation.
Why this matters: Exam questions frequently test whether you can distinguish between vulnerability scoring systems (CVSS vs. EPSS vs. CISA KEV), understand the difference between a scan finding and a confirmed vulnerability, and apply risk-based prioritization rather than treating all "critical" findings equally.
⚠️ Common Misconception: "CVSS score alone should determine remediation priority." CVSS Base Score measures technical severity in isolation — it does not account for whether the vulnerability is actively exploited, whether a compensating control exists, or whether the affected asset is internet-facing versus buried in an isolated network. Two vulnerabilities with the same CVSS 9.8 can have radically different real-world risk depending on context.
