security-comms

Name: security-comms
Author: briiirussell

108installs36forks

How to install security-comms?

briiirussell/cybersecurity-skills/security-comms

$npx -y skills add briiirussell/cybersecurity-skills --skill security-comms

Installs into the current project.

Summary

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, secur

Files · 1

View on GitHub

SKILL.md

1	# Security Comms — Translating Security Work for Non-Security Audiences
2
3	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."
4
5	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.
6
7	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).
8
9	## The seven audiences (and what each one actually needs)
10
11	Security comms is not one register. Each audience needs a different deliverable; using the wrong register is the most common failure mode.
12
13	### 1. Board of directors / non-executive directors
14
15	They need to know: Are we materially exposed? Is the team handling it? Is more investment needed?
16
17	They do not need: CVE numbers, file paths, scanner names, technical jargon, the methodology.
18
19	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).
20
21	Common mistake: Boards get scored heat maps and 30-row CVE tables. They want the punchline.
22
23	### 2. Executive leadership (CEO / CFO / COO / GC)
24
25	They need to know: What decision is being asked of them? What's the trade-off? What's the cost of inaction?
26
27	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).
28
29	Common mistake: Asking for budget without naming the alternative if the budget is denied.
30
31	### 3. Engineering leadership / senior engineers
32
33	They need to know: What's broken, how to fix it, what's the priority, what's the trade-off in their roadmap.
34
35	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.
36
37	Common mistake: Framing security work as urgent without showing the work. Engineers want to verify the finding themselves.
38
39	### 4. Individual engineers (the person who has to do the work)
40
41	They need to know: What exactly to change, in their code, with verification they can run themselves.
42
43	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.
44
45	Common mistake: Pasting the scanner output without context. The engineer doesn't know which of the scanner's 50 fields matter.
46
47	### 5. Customer success / sales engineering
48
49	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.
50
51	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.
52
53	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

briiirussellPublisher · 30 listings

Preview

briiirussell/cybersecurity-skills

# 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 ge

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 t

Cross-references: feeds from every other skill (audit output, incident write-ups, threat-model summaries, CSF assessments) and produces audience-specific delive

Repobriiirussell/cybersecurity-skills

LicenseMIT

TypeSkills

CategorySecurity

UpdatedMay 2026

Repo stars320

First seenJul 22, 2026

People who liked this also viewed

6 picks

Type

security-comms

108installs36forks

View on GitHub

How to install security-comms?

briiirussell/cybersecurity-skills/security-comms

$npx -y skills add briiirussell/cybersecurity-skills --skill security-comms

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Security Comms — Translating Security Work for Non-Security Audiences
2
3	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."
4
5	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.
6
7	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).
8
9	## The seven audiences (and what each one actually needs)
10
11	Security comms is not one register. Each audience needs a different deliverable; using the wrong register is the most common failure mode.
12
13	### 1. Board of directors / non-executive directors
14
15	They need to know: Are we materially exposed? Is the team handling it? Is more investment needed?
16
17	They do not need: CVE numbers, file paths, scanner names, technical jargon, the methodology.
18
19	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).
20
21	Common mistake: Boards get scored heat maps and 30-row CVE tables. They want the punchline.
22
23	### 2. Executive leadership (CEO / CFO / COO / GC)
24
25	They need to know: What decision is being asked of them? What's the trade-off? What's the cost of inaction?
26
27	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).
28
29	Common mistake: Asking for budget without naming the alternative if the budget is denied.
30
31	### 3. Engineering leadership / senior engineers
32
33	They need to know: What's broken, how to fix it, what's the priority, what's the trade-off in their roadmap.
34
35	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.
36
37	Common mistake: Framing security work as urgent without showing the work. Engineers want to verify the finding themselves.
38
39	### 4. Individual engineers (the person who has to do the work)
40
41	They need to know: What exactly to change, in their code, with verification they can run themselves.
42
43	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.
44
45	Common mistake: Pasting the scanner output without context. The engineer doesn't know which of the scanner's 50 fields matter.
46
47	### 5. Customer success / sales engineering
48
49	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.
50
51	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.
52
53	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

briiirussellPublisher · 30 listings

Preview

briiirussell/cybersecurity-skills

# 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 ge

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 t

Cross-references: feeds from every other skill (audit output, incident write-ups, threat-model summaries, CSF assessments) and produces audience-specific delive

Repobriiirussell/cybersecurity-skills

LicenseMIT

TypeSkills

CategorySecurity

UpdatedMay 2026

Repo stars320

First seenJul 22, 2026

People who liked this also viewed

6 picks

Type