Security Compliance
Document security incidents with a structured P0–P3 report, timeline table, and executive summary after detection or during postmortems.
Overview
Security Compliance is an agent skill most often used in Operate (also Ship security) that fills a structured incident response report template after a security or availability event.
Install
npx skills add https://github.com/davila7/claude-code-templates --skill security-complianceWhat is this skill?
- Prebuilt incident summary with severity (P0–P4), status lifecycle, and commander fields
- Timeline table template (UTC time, event, action, owner) for SOC-style narration
- Classification blocks: incident type, attack vector, and affected assets
- Executive summary slot for impact and resolution in 2–3 sentences
- Aligns with CIRT activation and forensic closure milestones in the sample timeline
- Severity scale with four levels (P0–Critical through P3–Low)
- Timeline table with four columns: Time (UTC), Event, Action Taken, Owner
Adoption & trust: 656 installs on skills.sh; 27.8k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You detected or contained an incident but only have chat logs—not a severity-ranked report with timeline, assets, and closure suitable for stakeholders or auditors.
Who is it for?
Solo founders or small teams running web apps who need a first-pass IR write-up without hiring a dedicated incident manager.
Skip if: Teams wanting automated threat detection, CVE scanning, or policy-as-code compliance mapping—this skill outputs a document template, not live telemetry.
When should I use this skill?
A security or availability incident needs formal documentation, executive summary, and a UTC timeline from detection through resolution.
What do I get? / Deliverables
You produce a complete incident record (summary, classification, UTC timeline, owners) ready to archive, share with insurers, or feed into your next hardening pass.
- Filled incident response report (ID, severity, status, commander, dates)
- Classification and affected-assets section
- UTC incident timeline table with owners
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Incident response reports are produced when production is impacted—canonical shelf is Operate because that is when solo teams close the loop on outages and breaches. Errors subphase covers incident handling, containment notes, and remediation tracking—not preventive hardening alone.
Where it fits
After isolating a compromised web server, you populate severity, timeline rows, and owner actions for the postmortem.
Before launch you dry-run the template in a tabletop exercise so everyone knows which fields to fill during a real event.
You attach the closed incident summary to customer trust communications when explaining a brief outage or breach containment.
How it compares
Use instead of blank Google Docs for postmortems when you want security-specific fields and severity semantics baked in.
Common Questions / FAQ
Who is security-compliance for?
Indie and solo builders shipping SaaS or APIs who must document security or availability incidents in a structured way for themselves, customers, or light compliance reviews.
When should I use security-compliance?
During Operate when an incident is open or just resolved; also in Ship security prep if you want a standard report format before launch drills; not for day-one threat modeling without an event.
Is security-compliance safe to install?
It is a local markdown template with no built-in network calls; review the Security Audits panel on this Prism page for the upstream package hash and any community audit notes before trusting the repo source.
SKILL.md
READMESKILL.md - Security Compliance
# Incident Response Report Template ## Incident Summary **Incident ID**: INC-2025-XXX **Severity**: [P0 - Critical | P1 - High | P2 - Medium | P3 - Low] **Status**: [Open | Contained | Resolved | Closed] **Incident Commander**: [Name] **Date Opened**: YYYY-MM-DD HH:MM UTC **Date Closed**: YYYY-MM-DD HH:MM UTC **Executive Summary**: [Brief 2-3 sentence summary of what happened, impact, and resolution] --- ## Incident Details ### Classification - **Incident Type**: [Malware | Phishing | Data Breach | DDoS | Unauthorized Access | Other] - **Attack Vector**: [Email | Web Application | Network | Physical | Social Engineering | Other] - **Affected Assets**: [List systems, applications, or data affected] ### Timeline | Time (UTC) | Event | Action Taken | Owner | |-----------|-------|--------------|-------| | 2025-01-15 14:23 | SIEM alert: Unusual outbound traffic | Analyst began investigation | SOC Analyst | | 2025-01-15 14:30 | Confirmed malware on web-01 | Server isolated from network | SOC Analyst | | 2025-01-15 14:45 | CIRT activated | Incident commander assigned | Security Manager | | 2025-01-15 15:00 | Root cause identified | Vulnerability assessment | Security Engineer | | 2025-01-15 16:00 | Patch applied to all systems | Systems patched and restarted | IT Operations | | 2025-01-15 18:00 | Forensic analysis completed | Evidence collected | Forensic Analyst | | 2025-01-17 10:00 | Systems restored to production | Monitoring in place | IT Operations | | 2025-01-17 12:00 | Incident closed | Post-incident review scheduled | Incident Commander | --- ## Impact Assessment ### Systems Affected - **Production Systems**: [Number and list] - **Development/Test Systems**: [Number and list] - **User Accounts**: [Number affected] ### Data Impact - **Data Confidentiality**: [None | Low | Medium | High | Critical] - Personal Identifiable Information (PII): [Yes/No, quantity if applicable] - Protected Health Information (PHI): [Yes/No, quantity if applicable] - Financial Data: [Yes/No, quantity if applicable] - Intellectual Property: [Yes/No] - Other Sensitive Data: [Specify] - **Data Integrity**: [None | Low | Medium | High | Critical] - Data modified or corrupted: [Yes/No, describe] - **Data Availability**: [None | Low | Medium | High | Critical] - Systems offline: [Duration] - Services unavailable: [List] ### Business Impact - **Downtime**: X hours - **Estimated Financial Loss**: $X,XXX - Direct costs (response, recovery): $X,XXX - Indirect costs (downtime, productivity): $X,XXX - Potential regulatory fines: $X,XXX - **Customers Affected**: [Number] - **Reputation Impact**: [None | Minor | Moderate | Significant | Severe] --- ## Root Cause Analysis ### What Happened [Detailed description of the incident from start to finish] ### How It Happened [Technical explanation of the attack vector and vulnerabilities exploited] ### Why It Happened [Underlying causes: missing patches, misconfiguration, human error, etc.] ### Contributing Factors - Factor 1: [Description] - Factor 2: [Description] - Factor 3: [Description] --- ## Response Actions ### Detection [How the incident was detected: SIEM alert, user report, etc.] ### Containment **Short-term Containment**: - [Action 1: e.g., Isolated affected systems from network] - [Action 2: e.g., Disabled compromised user accounts] - [Action 3: e.g., Blocked malicious IPs at firewall] **Long-term Containment**: - [Action 1: e.g., Patched vulnerable systems] - [Action 2: e.g., Implemented compensating controls] ### Eradication - [Action 1: e.g., Removed malware from all systems] - [Action 2: e.g., Closed vulnerable attack vector] - [Action 3: e.g., Reset all potentially compromised credentials] ### Recovery - [Action 1: e.g., Restored systems from clean backups] - [Action 2: e.g., Verified system integrity] - [Action 3: e.g., Returned systems to production with enhanced monitoring] ### Evidence Collected - **Forensic Images**: [List systems imaged] - **Log Fi