Stats
Actions
Tags
Help us improve
Share bugs, ideas, or general feedback.
From cybersecurity-skills
Translates technical security findings into audience-specific communications for boards, executives, customers, and other non-security stakeholders. Covers incident communications, post-mortems, risk justifications, and breach disclosures.
npx claudepluginhub briiirussell/cybersecurity-skills --plugin cybersecurity-skillsHow this skill is triggered — by the user, by Claude, or both
Slash command
/cybersecurity-skills:security-commsThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
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."
Develop incident communication strategies for internal teams, customers, regulators, and media during and after security incidents.
Communicate technical progress, tradeoffs, and risks to non-engineers in language they understand. Use in status updates, executive presentations, or crisis communication.
Adapts analytical findings to stakeholder audiences (executives, product teams, engineers, data teams) by adjusting framing, detail level, and format. Useful for narratives, decks, reports when audience specified.
Share bugs, ideas, or general feedback.
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).
Security comms is not one register. Each audience needs a different deliverable; using the wrong register is the most common failure mode.
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.
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.
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.
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.
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.
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.
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-evidence pull. Use the framework language the counterpart is using (CSF Subcategory IDs, ISO controls, PCI requirement numbers, HIPAA safeguard names). Avoid translating into your own framework; they want their language back.
Common mistake: Answering "yes" or "no" without the evidence pointer. Procurement-side reviewers need the evidence inline, not on request.
The skill works in two modes — drafting from a technical input, or reviewing a draft someone else wrote.
# Security Update — [Date]
## To: Board
## From: [CISO / equivalent]
### Bottom line
[One sentence — material exposure yes / no, contained yes / no, action needed yes / no]
### What happened
[Two to four sentences in the board's terms. No file paths or CVE numbers.]
### What's been done
- [Action 1, by date]
- [Action 2, by date]
### What we're asking of the board
[If anything — funding, vendor change, communications approval. If nothing, say so.]
### What we'll know by [next-meeting date]
[Open questions, planned investigations]
# Memo: [Decision name]
## From: [author]
## To: [decision-maker]
## Date: [date]
## Decision needed by: [date]
### The decision
[One sentence — what you're asking them to approve.]
### Why now
[Two sentences — what changed, what the regulatory / customer / risk pressure is.]
### Options
1. [Option A — cost, time, residual risk]
2. [Option B — cost, time, residual risk]
3. [Do nothing — what happens]
### Recommendation
[Which option and why.]
### Cost of inaction
[Specific — regulatory fines, customer-trust impact, engineering hours saved elsewhere, etc.]
# Security Notice
## Date: [date]
Dear [customer],
On [date], we identified [what happened — in the customer's terms]. Information that may have been involved includes [specific data fields]. Information not involved includes [specific data fields].
We have taken the following steps:
- [Action 1]
- [Action 2]
We recommend you:
- [Action 1 they should take, e.g., reset password]
- [Action 2]
If you have questions, contact [working contact path — not a generic security@].
We are sorry this happened.
[Name and title — not a corporate signature]
# Post-mortem: [Incident name]
## Severity: [SEV1 / SEV2 / SEV3]
## Date detected: [date]
## Date resolved: [date]
## Duration: [hh:mm]
## Authors: [names]
### Summary
[One paragraph that someone outside the response can read and understand the incident.]
### Timeline
[Bulleted, with timestamps in one timezone. Detection → triage → containment → eradication → recovery → all-clear.]
### Impact
- [Who was affected — customers, internal users, third parties]
- [What was affected — service availability, data confidentiality, data integrity]
- [Quantify where possible — affected user count, downtime minutes, data records involved]
### Root cause
[The actual root cause — not the proximate trigger. Why did the trigger lead to user impact?]
### What went well
[Two to four items. Be specific.]
### What did not go well
[Two to four items. Be specific. No blame language.]
### Action items
| Item | Owner | Deadline | Status |
|------|-------|----------|--------|
### Lessons for the rest of the org
[What other teams should change based on this incident.]
# Security Findings — [Project / sprint]
## Audit source: [owasp-audit / api-audit / etc.]
## Date: [date]
### Summary
[One sentence — N findings, severity breakdown, target resolution window.]
### Findings (prioritized)
| ID | Severity | File / endpoint | Effort estimate | Sprint candidate |
|----|----------|-----------------|-----------------|------------------|
### Per-finding detail
[Per-finding entries with file:line, reproduction, fix proposal, verification step, effort estimate.]
### Not findings (FYI)
[Items the scanner / audit flagged that we've determined are not real — with one line each on why. This builds engineering trust that we're not crying wolf.]
# Customer Q&A — [Topic, e.g., recent vulnerability disclosure]
## Internal — for SE use; not customer-facing
**Q: Were we affected by [CVE / event]?**
A: [Straight answer. Yes / no / partially with which part.]
**Q: What did you do about it?**
A: [Specific actions with dates.]
**Q: Should I be doing anything on my end?**
A: [Customer-facing recommendation, or "no action required, here's why."]
**Q: When can I expect a written notice?**
A: [Date / not applicable / "you're reading the only one, you can quote it."]
**Q: [Other anticipated question]**
A: [...]
**If asked something not on this list:** [Escalation path — to whom, with what info, how fast.]
A specific note because this skill is itself used by AI agents:
When an AI generates a security comm, do not ship it without a human reviewer for that audience. Specifically:
AI-drafted security comms are most useful as the first draft, not the final draft. The skill cuts the time-to-first-draft from 90 minutes to 10; it does not eliminate the review loop.