Security Comms — Translating Security Work for Non-Security Audiences

The skill that closes the gap every other skill produces. The audit family generates findings; the response family generates incidents; the governance family generates roadmaps. None of those outputs survive contact with a board, a customer, a sales engineer trying to answer a security questionnaire, or a CFO asking "is this going to cost us money."

This skill takes technical security work and turns it into the deliverable that audience can actually use. It's the skill security practitioners reach for two to three times a week and that founders without dedicated security teams reach for whenever a finding has to leave the security context.

Cross-references: feeds from every other skill (audit output, incident write-ups, threat-model summaries, CSF assessments) and produces audience-specific deliverables; pairs especially closely with finding-triage (the disposition writeup) and incident-triage (the response narrative).

The seven audiences (and what each one actually needs)

Security comms is not one register. Each audience needs a different deliverable; using the wrong register is the most common failure mode.

1. Board of directors / non-executive directors

They need to know: Are we materially exposed? Is the team handling it? Is more investment needed?

They do not need: CVE numbers, file paths, scanner names, technical jargon, the methodology.

Format: One slide or one page. Three sections — current posture in one paragraph, top three risks with one sentence each, named investments / decisions needed. Numbers must be material (in dollars or % impact), not raw counts ("we have 47 vulnerabilities" tells them nothing; "two of our payments-team services have unpatched issues an attacker could use to access customer card data" tells them what to do).