/security-comms

name: security-comms
description: "Translate technical security work into the language of non-security audiences — board, executives, engineering, customer success, customers, legal, procurement, sales. Covers incident communication, post-mortem narrative, audit-findings-for-stakeholders, risk justification, security spend justification, and customer-facing breach disclosure. Use when the user mentions 'security comms,' 'communicate this finding,' 'explain to my boss,' 'board update,' 'executive summary,' 'incident communication,' 'breach notification,' 'customer disclosure,' 'security memo,' 'post-mortem narrative,' 'risk justification,' 'why this matters to the business,' 'translate this finding,' 'stakeholder update,' or has technical security work that needs to land with a non-security audience."
allowed-tools: Read, Write, WebSearch

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).

**Common mistake:** Boards get scored heat maps and 30-row CVE tables. They want the punchline.

2. Executive leadership (CEO / CFO / COO / GC)

**They need to know:** What decision is being asked of them? What's the trade-off? What's the cost of inaction?

**Format:** Memo, one to three pages. Lead with the decision; then context, options with trade-offs, recommendation, the cost / time / people / risk if they say no. Quantify where possible (regulatory exposure dollars, customer-trust risk in churn percentage, engineering hours).

**Common mistake:** Asking for budget without naming the alternative if the budget is denied.

3. Engineering leadership / senior engineers

**They need to know:** What's broken, how to fix it, what's the priority, what's the trade-off in their roadmap.

**Format:** Ticket or design-doc-shaped writeup. Specific files / endpoints / commits. Reproduction steps. Fix proposal. Verification step. Effort estimate. Engineering leadership respects specificity; vague "you have an XSS somewhere" creates resentment.

**Common mistake:** Framing security work as urgent without showing the work. Engineers want to verify the finding themselves.

4. Individual engineers (the person who has to do the work)

**They need to know:** What exactly to change, in their code, with verification they can run themselves.

**Format:** Ticket with code-shaped detail — file path, line number, current code, fixed code, the test that proves the fix held. This is the most concrete register of all.

**Common mistake:** Pasting the scanner output without context. The engineer doesn't know which of the scanner's 50 fields matter.

5. Customer success / sales engineering

**They need to know:** What to say to customers who ask. What the answer is to common security questionnaire fields. What changed that they need to mention.

**Format:** Internal FAQ — questions phrased the way a customer would phrase them, answers written for an SE to read aloud or paste into a reply. Avoid security jargon; avoid "we cannot comment" unless legal actually said so.

**Common mistake:** Drafting customer-facing language and not letting customer-success read it for tone before it ships. Security folks default to language that sounds defensive or evasive.

6. Customers (under public disclosure)

**They need to know:** Did my data get accessed? What did you do about it? What do I need to do?

**Format:** A short letter. Lead with what happened in their terms (not yours). State what data may have been involved. State what's been done. State what they should do. Provide a contact path that works. Avoid corporate-PR softeners; they read as evasive.

**Common mistake:** Saying "out of an abundance of caution" when you mean "we don't know yet but we have to tell you." Customers can tell.

Disclosure to customers has legal and regulatory dimensions — this skill produces a draft; legal and possibly outside counsel review before it ships.

7. Procurement / legal / compliance counterparts (internal or vendor-side)

**They need to know:** Are we compliant, what's documented, what's the contractual position, do we have evidence?

**Format:** Structured artifact — questionnaire response, BAA / DPA red-line input, audit