security-documentation

# Security Documentation Skill

Author clear, actionable, audit-ready security documentation.

## Phase Map

```
Phase 1 → Policy Writing            [read: references/policy-writing.md]
Phase 2 → Runbook Authoring         [read: references/runbook-authoring.md]
Phase 3 → Incident Templates        [read: references/incident-templates.md]
```

## Output Format

Produce structured Markdown documents following the templates in each phase reference file, suitable for direct use in governance repositories.


## policy-writing

# Policy Writing — Reference

Use during Phase 1 to author clear, audit-ready security policies following a consistent structure.

## Policy Structure Template

```markdown
# [Policy Name] Policy

**Policy ID:** POL-[ID]
**Version:** 1.0
**Effective Date:** YYYY-MM-DD
**Review Date:** YYYY-MM-DD (typically 12 months from effective date)
**Owner:** [Job Title, e.g., Chief Information Security Officer]
**Approved By:** [Name, Title]

---

## 1. Purpose
[One to two sentences explaining why this policy exists and what risk it addresses.]

## 2. Scope
[Clearly state who and what this policy applies to: employees, contractors, systems, data types, geographic regions.]

## 3. Policy Statements
[Numbered list of specific, measurable, enforceable requirements.]

3.1 All [subject] must [action] when [condition].
3.2 [Subject] must not [prohibited action].
3.3 [Subject] should [recommended action] to [achieve outcome].

## 4. Roles and Responsibilities
| Role | Responsibility |
|------|---------------|
| [Role] | [What this role must do under this policy] |

## 5. Compliance and Enforcement
[Consequences of non-compliance. Reference to disciplinary procedure.]

## 6. Related Documents
- [Procedure/Standard name] — [Document ID]
- [Related policy name] — [Document ID]

## 7. Revision History
| Version | Date | Author | Change Summary |
|---------|------|--------|----------------|
| 1.0 | YYYY-MM-DD | [Name] | Initial release |
```

## Language Guidelines

| Term | Usage | Example |
|------|-------|---------|
| **must** | Mandatory requirement — no exceptions without formal approval | "All users must enable MFA." |
| **must not** | Absolute prohibition | "Administrators must not share privileged account credentials." |
| **should** | Recommended best practice; deviation must be documented | "Systems should use HTTPS for all external communications." |
| **may** | Permissive; discretionary | "Users may request exceptions via the security exception process." |

Never use "should" when you mean "must". Auditors read "should" as optional.

## Common Policy Types

| Policy | Addresses | Key Frameworks |
|--------|-----------|---------------|
| Acceptable Use Policy (AUP) | Permitted use of company systems and data | ISO 27001 A.8.1 |
| Access Control Policy | User provisioning, MFA, privileged access | ISO 27001 A.8.5, PCI DSS Req 7/8 |
| Incident Response Policy | IR process, roles, escalation, notification | ISO 27001 A.5.26, NIST CSF RS |
| Password / Authentication Policy | Password complexity, rotation, MFA | CIS Controls 5, NIST SP 800-63 |
| Data Classification Policy | Data tiers, handling requirements, retention | ISO 27001 A.5.12 |
| Vulnerability Management Policy | Scan frequency, SLAs by severity | PCI DSS Req 6/11 |
| Third-Party / Supplier Security Policy | Vendor assessment, contractual requirements | ISO 27001 A.5.19 |
| Cryptography Policy | Approved algorithms, key management | ISO 27001 A.8.24 |



## runbook-authoring

# Runbook Authoring — Reference

Use during Phase 2 to write operational security runbooks that enable any trained analyst to execute the procedure correctly and consistently.

## Runbook Principles

1. **Assume nothing** — write for an analyst who has never performed this task before.
2. **One action per step** — each step should be a single, verifiable action.
3. **Include expected outcomes** — tell the analyst what success looks like at each step.
4. **Flag decision points** — make branching logic explicit (IF / THEN / ELSE).
5. **Keep it current** — runbooks must be reviewed when the underlying system changes.

## Runbook Structure Template

```markdown
# [Runbook Name]

**Runbook ID:** RB-[ID]
**Version:** 1.0
**Trigger:** [What event or condition initiates this runbook]
**Owner:** [Team / Role responsible for maintaining this runbook]
**Last Reviewed:** YYYY-MM-DD
**Estimated Duration:** [X minutes]

---

## Prerequisites
- Access required: [List systems/tools the analyst must have access to]
- Permissions required: [Specific permissions needed]
- Dependencies: [Other runbooks or procedures that must be completed first]

## Step-by-Step Procedure

### Step 1 — [Action title]
**Action:** [Specific action to perform]
**Command/UI path:** [Exact command or navigation path]
```
example command here
```
**Expected outcome:** [What the analyst should see if successful]
**If this fails:** [What to do if the expected outcome is not seen]

### Step 2 — [Action title]
[Repeat structure]

## Decision Points

### [Decision: e.g., Is the alert a true positive?]
- **YES** → Proceed to Step [N]
- **NO** → Proceed to Step [M] (false positive handling)

## Escalation Criteria
[When should the analyst escalate, and to whom?]

## Communication Templates
[Pre-written notification messages for stakeholders]

## Post-Procedure Actions
- [ ] Log actions taken in incident/change ticket
- [ ] Update asset inventory if changes made
- [ ] Notify stakeholders of completion
```

## Common Runbook Types

| Runbook Type | Trigger | Key Steps |
|-------------|---------|-----------|
| Phishing Response | Suspicious email reported | Analyse headers → block sender/URL → scan mailboxes → notify affected users |
| Account Compromise | Anomalous login alert | Force password reset → revoke sessions → review activity → notify user |
| Ransomware Containment | EDR alert on file encryption | Network isolate host → collect evidence → determine scope → initiate restore |
| DDoS Response | Traffic volume exceeds threshold | Enable scrubbing → activate CDN protection → notify ISP → monitor |
| Privileged Account Lockout | Admin locked out | Verify identity → unlock via break-glass → investigate cause → audit |

## Quality Checklist

- [ ] Every step has a single, testable action
- [ ] All commands tested in a non-production environment
- [ ] All tool/system names match current environment (no outdated names)
- [ ] Escalation path and contact details current
- [ ] Runbook reviewed by at least one analyst who did not write it
- [ ] Version controlled and stored in accessible location (not only on single person's laptop)



## incident-templates

# Incident Templates — Reference

Use during Phase 3 to produce standardised incident records, severity classifications, and regulatory notification timelines.

## Incident Record Template

```markdown
# Incident Record — INC-[YYYY]-[NNNN]

**Incident Title:** [Brief descriptive title]
**Severity:** P[1/2/3/4]
**Status:** Open / Contained / Resolved / Closed
**Incident Commander:** [Name]
**Date/Time Detected:** YYYY-MM-DD HH:MM UTC
**Date/Time Declared:** YYYY-MM-DD HH:MM UTC
**Date/Time Resolved:** YYYY-MM-DD HH:MM UTC

---

## Summary
[One paragraph: what happened, how it was detected, current status]

## Affected Systems
| System | Impact | Owner |
|--------|--------|-------|
| [system name] | [description of impact] | [team/person] |

## Timeline
| Date/Time (UTC) | Event |
|----------------|-------|
| YYYY-MM-DD HH:MM | [What happened] |

## Indicators of Compromise (IOCs)
- File hash: [SHA256]
- IP address: [IP]
- Domain: [domain]

## Actions Taken
| Date/Time | Action | By Whom |
|-----------|--------|---------|
| | | |

## Regulatory Notification Required?
[ ] GDPR — 72-hour notification to supervisory authority
[ ] PCI DSS — Notify card brands and acquiring bank within 24 hours
[ ] NIS2 — 24-hour early warning; 72-hour incident notification
[ ] HIPAA — 60-day notification to HHS (and individuals if > 500 affected)

## Root Cause
[Identified after containment — what enabled the incident to occur]

## Lessons Learned
[Post-incident review findings]
```

## Severity Classification Table

| Severity | Criteria | Response SLA | Escalation |
|----------|----------|-------------|-----------|
| **P1 — Critical** | Active data breach; ransomware encrypting; critical system down; nation-state activity suspected | Declare in 15 min; contain within 1 hour | CEO, Board, Legal, DPO |
| **P2 — High** | Confirmed compromise of Tier 1/2 asset; significant data exposure risk; major service degraded | Declare in 30 min; contain within 4 hours | CISO, CTO, Legal |
| **P3 — Medium** | Isolated malware on single endpoint; suspicious activity under investigation; minor data exposure | Declare in 2 hours; contain within 24 hours | Security Manager, IT Director |
| **P4 — Low** | Policy violation; minor misconfiguration; no confirmed compromise | Acknowledge within 8 hours; resolve within 72 hours | Security Team Lead |

## Regulatory Notification Deadlines

| Regulation | Jurisdiction | Trigger | Initial Notification | Full Notification | Notify Who |
|------------|-------------|---------|---------------------|------------------|------------|
| GDPR | EU / EEA | Personal data breach with risk to individuals | 72 hours | 30 days (to individuals) | Supervisory authority (ICO in UK) + affected individuals |
| HIPAA Breach Notification Rule | USA | Breach of unsecured PHI | N/A — no early warning | 60 days from discovery (to HHS + individuals) | HHS Office for Civil Rights; patients |
| NIS2 Directive | EU | Significant incident affecting essential/important entity | 24 hours (early warning) | 72 hours (incident notification); 1 month (final) | National CSIRT / competent authority |
| PCI DSS v4.0 | Global (card data) | Suspected or confirmed account data compromise | Immediately (24 hours best practice) | As required by card brands | Card brands (Visa/MC/Amex) + acquiring bank |
| SEC Cybersecurity Rules | USA (public companies) | Material cybersecurity incident | 4 business days (8-K filing) | Annual disclosure (10-K) | SEC (public disclosure) |