The Report the Board Will Actually Read
After a three-week internal and external engagement for a PCI DSS Level 1 merchant, you have 88 findings, 7 of them critical, and a report due to a CISO who presents to the board in ten days. The remediation team is three people with a monthly patch window. One critical finding - 40 Kerberoastable service accounts, 12 with domain admin - cannot be remediated for nine months because a legacy order-entry application depends on RC4 and a shared service identity. Last year's report listed 60 findings; 40 remain open and two were re-reported as new. The client asks for the raw scanner output and your working exploit scripts 'so the team can reproduce.' You also found that four teams share one local administrator password that predates LAPS, and one engineer's name appears in the tooling logs you reviewed.
1. How do you structure the report so a board and a three-person remediation team can both use it?
Read the worked answer
Eighty-eight findings is not a message. The messages are: an unauthenticated external attacker can reach domain admin in a handful of steps; one patch cycle removes 61 of the 96 high findings; and the risks accepted last year are still open. Structure the document around those.
1. One-page executive summary. Business impact in the client's own language - outage, cardholder data exposure, regulatory consequence - the three things worth funding, and what happens if they are not funded. No CVEs on this page.
2. Risk register sorted by risk score, with an accountable business owner named per item, not an IT team.
3. Thematic root causes. 'No service-account lifecycle,' 'no local administrator password management,' 'no emergency patch lane.' Each theme closes many findings at once, which is the only way three people make a dent in 88 items. LAPS alone removes 22 of them.
4. A 30/90/180-day roadmap sized to three people and a monthly window, with an explicit note that the critical items require an out-of-band change - pretending they fit the monthly cycle is how they get deferred.
5. A 'previously reported, still open' section with last year's IDs mapped to this year's, so carryover is visible rather than silently renumbered.
6. Appendix with technical detail and reproduction steps for the engineers.
Track one metric across reports: median time-to-remediate by severity. It is the number that tells the board whether anything changed.
2. The client asks for the raw scanner file and your exploit scripts. How do you respond?
Read the worked answer
Split the request by purpose rather than answering yes or no.
Raw scanner output: provide it. If the goal is remediation verification and re-scanning, giving them the file and the scan policy saves everyone time and lets them measure progress between engagements. Sanitize only what the contract requires - credentials, internal hostnames in a privileged segment, anything classified.
Exploit scripts: not as an attachment. Handing working code to a three-person team with no named owner transfers risk rather than reducing it, and once it is in email or a wiki it is effectively public inside the organization. Options in order of preference: an access-controlled repository with MFA for named individuals; annotated proof-of-concept output - request/response pairs, command lines, screenshots - that is sufficient to reproduce without shipping something executable; or running the verification yourself as part of the included retest. Most clients who ask for the scripts actually want assurance that the finding is real and fixable, and a reproduction transcript delivers that.
Check the contract first. Many SOWs contain IP and confidentiality clauses that govern tooling and require written approval before sharing, plus retention and destruction obligations at engagement close. Also be honest about what the scripts are: throwaway code with hardcoded targets and no error handling, not production tooling. Offer the validation session - it converts a liability question into a service.
3. How do you handle the nine-month legacy dependency and the 40 unresolved items, and how do you write up the shared local admin password and the named engineer?
Read the worked answer
Reframe 'cannot be fixed.' It is only acceptable as a risk acceptance, and an acceptance needs four things: a named business owner who accepts it (not the security team), a written rationale, compensating and detective controls during the interim, and an expiry and review date. Interim controls that genuinely reduce likelihood for 40 Kerberoastable accounts, 12 of them domain admin: remove those 12 from Tier-0 and migrate them to gMSAs or a tiered admin model, disable RC4 where the legacy application permits, alert on 4769 events with RC4 encryption against privileged SPNs, restrict logon rights for those accounts, and lengthen passwords for any that can be changed. Detective controls do not remove the risk; say so in the residual-risk statement. Because this is a PCI Level 1 merchant, the arrangement is a compensating control and needs the documented targeted risk analysis the standard requires plus a control that meets or exceeds the original requirement - a promise with a date is not a control.
Carryover. Separate 'won't fix' from 'can't fix'; both get an owner and a due date on the same dashboard. Set a monthly risk-committee cadence so this year's 40 do not become next year's 41.
The shared password and the named engineer. Report the control failure - one local administrator password shared across four teams, no LAPS, no rotation - because that is what is actionable. Do not name the engineer. The finding is the absence of a control, not an individual's behaviour; naming them turns a technical finding into an HR dispute and makes the whole team defensive about the report. Strip identifiers from log excerpts in the appendix.