Exercise 2: Why a Report Needs Both an Executive Summary and Technical Findings — Possible Solution
====================================================================

THE TWO DIFFERENT AUDIENCES
------------------------------
Per this chapter's own table, the Executive Summary is written for
"non-technical decision-makers, budget-holders," covering "overall
risk posture, business impact, high-level statistics... no deep
technical detail." The Technical Findings section is written for
"engineers and IT staff who will actually fix each issue," covering
"full technical detail, exact reproduction steps, affected systems,
evidence."

WHY A TECHNICAL-ONLY REPORT FAILS
------------------------------
Per this chapter, "a report with only technical detail rarely secures
the budget or priority needed from people who don't have time to
parse it." Decision-makers responsible for allocating budget and
setting organizational priority are, by definition, not the people
who will personally read raw request/response evidence or step-by-
step reproduction instructions. If the report only speaks in that
technical language, the people with the authority to fund and
prioritize the fix may never actually understand why it matters
enough to act on — the finding could be technically excellent and
still go nowhere.

WHY AN EXECUTIVE-ONLY REPORT FAILS
------------------------------
Per this chapter, "a report with only an executive summary gives the
engineers who need to fix each issue nothing concrete to act on." Even
if leadership is fully convinced a finding is serious and allocates
budget to fix it, the engineers actually doing the fixing need the
technical specifics — which system, what the exact vulnerable
behavior is, how to reproduce it, what evidence confirms it — none of
which a high-level executive summary provides. Budget and intent alone
don't fix a vulnerability; someone still has to know exactly what's
wrong and where.

WHY BOTH SECTIONS TOGETHER SOLVE THIS
------------------------------
Per this chapter, "a good report serves both audiences without forcing
either one to wade through content meant for the other." Separating
the two sections lets each audience get exactly what they need,
efficiently — decision-makers get the business case for prioritizing
the work, and engineers get the technical detail to actually perform
it, without either group having to sift through material aimed at the
other.

WHY THIS WORKS AS AN ANSWER
------------------------------
It explains the specific, distinct failure mode of omitting EACH
section individually, using the chapter's own stated audiences and
reasoning, rather than a generic "different readers need different
things" answer.