new file: .github/workflows/ci.yml

	new file:   .gitignore
	modified:   README.md
	new file:   docs/communication-plan.md
	new file:   docs/escalation-matrix.md
	new file:   docs/incident-response-policy.md
	new file:   docs/security-program-overview.md
	new file:   pyproject.toml
	new file:   risk_register/risk_register.csv
	new file:   risk_register/scoring_guide.md
	new file:   runbooks/account-compromise.md
	new file:   runbooks/lost-device.md
	new file:   runbooks/phishing.md
	new file:   runbooks/ransomware.md
	new file:   runbooks/suspicious-login.md
	new file:   templates/business-impact-assessment-template.md
	new file:   templates/incident-report-template.md
	new file:   templates/post-incident-review-template.md
	new file:   templates/risk-assessment-template.md
	new file:   templates/vendor-security-review-template.md
	new file:   tests/test_risk_register.py
	new file:   tools/validate_risk_register.py

Author: DCMedic

.github/workflows/ci.yml

@@ -0,0 +1,19 @@
+name: CI
+
+on:
+  push:
+  pull_request:
+
+jobs:
+  validate:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-python@v5
+        with:
+          python-version: "3.11"
+      - run: python -m pip install --upgrade pip
+      - run: pip install -e ".[dev]"
+      - run: ruff check tools tests
+      - run: python tools/validate_risk_register.py risk_register/risk_register.csv
+      - run: pytest

.gitignore

@@ -0,0 +1,9 @@
+.venv/
+__pycache__/
+*.pyc
+.pytest_cache/
+.coverage
+dist/
+build/
+*.egg-info/
+.DS_Store

README.md

@@ -1,2 +1,66 @@
 # security-program-starter
 
+A portfolio-ready security program repository that demonstrates practical cybersecurity governance, incident response planning, and lightweight risk management.
+
+This repository is designed to showcase an employer-friendly blend of:
+- Incident response documentation
+- Security operations process design
+- Risk register management
+- Business-aligned security communication
+- Documentation quality and maintainability
+
+It is intentionally defensive and organizational in nature. It does not include exploit code, offensive tooling, or destructive capabilities.
+
+## What is included
+
+### 1. Incident response program documents
+Core program documents that define how an organization prepares for, responds to, and learns from security incidents.
+
+### 2. Runbooks
+Actionable, scenario-specific playbooks for common security events:
+- Ransomware
+- Phishing
+- Account compromise
+- Lost device
+- Suspicious login activity
+
+### 3. Templates
+Reusable forms and structured templates for:
+- Incident reporting
+- Post-incident reviews
+- Risk assessments
+- Vendor security reviews
+- Business impact assessments
+
+### 4. Lightweight risk register
+A simple CSV-based risk register suitable for small businesses, startups, student projects, or early-stage governance programs.
+
+### 5. Validation tooling
+A small Python validation script and tests to ensure the risk register has the expected structure and scoring values.
+
+## Why this repository matters
+
+Many technical portfolios focus only on code. This repository demonstrates the ability to:
+- Build repeatable security processes
+- Communicate clearly with leadership and stakeholders
+- Align operational security with business risk
+- Create documentation that teams can actually use
+- Think like a future security analyst, GRC professional, incident responder, or security manager
+
+## Quick start
+
+Clone the repository and review these files first:
+
+- `docs/security-program-overview.md`
+- `docs/incident-response-policy.md`
+- `runbooks/ransomware.md`
+- `risk_register/risk_register.csv`
+
+To validate the risk register locally:
+
+```bash
+python -m venv .venv
+source .venv/bin/activate
+pip install -e ".[dev]"
+python tools/validate_risk_register.py risk_register/risk_register.csv
+pytest

docs/communication-plan.md

@@ -0,0 +1,60 @@
+# Security Incident Communication Plan
+
+## Purpose
+
+This plan defines how incident-related information should be communicated during and after a security event.
+
+## Communication Principles
+
+- Communicate facts, not assumptions.
+- Keep messages concise and audience-specific.
+- Avoid speculation about cause until evidence supports it.
+- Escalate communication needs early for regulated or high-visibility incidents.
+
+## Core Audiences
+
+### Internal Technical Teams
+Need actionable detail on systems, indicators, impact, and required response actions.
+
+### Leadership
+Need concise summaries of business impact, severity, decision points, and recovery outlook.
+
+### Employees
+Need clear behavioral guidance, especially during phishing, password reset, or system outage scenarios.
+
+### Customers / Clients
+Need carefully approved communication if their data, service availability, or contractual obligations are affected.
+
+### Regulators / Legal / Insurance
+Need timely, accurate information based on applicable requirements and contractual triggers.
+
+## Initial Internal Update Template
+
+- Incident title:
+- Severity:
+- Time identified:
+- Current status:
+- Known affected systems:
+- Known business impact:
+- Actions underway:
+- Next update time:
+
+## External Communication Considerations
+
+Before external communication, confirm:
+- What is known versus unknown
+- Whether legal review is required
+- Whether notification thresholds are met
+- Whether language aligns with contractual obligations
+- Whether communications are approved by leadership
+
+## Update Cadence
+
+Suggested cadence during active major incidents:
+- Severity 1: every 30 to 60 minutes
+- Severity 2: every 2 to 4 hours
+- Severity 3: daily or as needed
+
+## Approved Spokespersons
+
+Only designated leadership, communications, legal, or approved incident response leadership should issue external statements.

docs/escalation-matrix.md

@@ -0,0 +1,29 @@
+# Escalation Matrix
+
+## Purpose
+
+This matrix provides example triggers for escalating a security issue beyond the immediate technical team.
+
+## Escalation Triggers
+
+| Trigger | Escalate To | Example |
+|---|---|---|
+| Suspected ransomware | Leadership, legal, IT leadership, incident coordinator | Multiple systems encrypted |
+| Suspected credential theft affecting privileged accounts | Security lead, IAM lead, leadership | Admin account compromise |
+| Exposure of regulated or sensitive data | Legal, compliance, leadership | Customer PII exposure |
+| Widespread phishing campaign | IT support, communications, security lead | Multiple users report same lure |
+| Lost or stolen corporate device | IT support, asset owner, security lead | Laptop missing during travel |
+| Business-critical outage with security indicators | Leadership, operations, incident coordinator | ERP unavailable after suspicious activity |
+
+## Severity Guidance
+
+| Severity | Typical Escalation |
+|---|---|
+| 1 | Immediate leadership notification |
+| 2 | Management notification within the same business day |
+| 3 | Team-level handling with management awareness as needed |
+| 4 | Track and monitor unless trend or context warrants escalation |
+
+## Notes
+
+This matrix should be tailored to the organization’s actual reporting structure, legal obligations, and operational risk tolerance.

docs/incident-response-policy.md

@@ -0,0 +1,81 @@
+# Incident Response Policy
+
+## Purpose
+
+This policy establishes the organizational approach for identifying, reporting, triaging, investigating, containing, eradicating, and recovering from information security incidents.
+
+## Policy Statement
+
+The organization will maintain a documented incident response capability to ensure security incidents are managed consistently, efficiently, and in a manner that supports business continuity, legal obligations, and stakeholder communication.
+
+## Objectives
+
+The incident response process aims to:
+- Detect and validate incidents quickly
+- Reduce harm to systems, data, users, and operations
+- Preserve evidence when appropriate
+- Support timely internal and external communications
+- Capture lessons learned for future improvement
+
+## Incident Lifecycle
+
+The organization will manage incidents using the following lifecycle:
+
+1. Preparation
+2. Identification
+3. Containment
+4. Eradication
+5. Recovery
+6. Lessons Learned
+
+## Severity Levels
+
+### Severity 1
+Critical business impact, major outage, ransomware, widespread compromise, regulated data exposure, or executive-level escalation.
+
+### Severity 2
+Confirmed compromise with meaningful operational or security impact, but not enterprise-critical.
+
+### Severity 3
+Limited scope event, suspicious activity, or contained issue with low immediate business impact.
+
+### Severity 4
+Informational event, false positive, or issue requiring tracking but not formal escalation.
+
+## Roles and Responsibilities
+
+### Incident Coordinator
+Leads overall response, ensures documentation is maintained, and drives decision-making.
+
+### Technical Response Lead
+Performs technical investigation, containment, and recovery coordination.
+
+### IT Support / System Owners
+Assist with affected assets, restoration, and validation of service recovery.
+
+### Management / Leadership
+Approves high-impact business decisions and external communications when needed.
+
+### Legal / Compliance / HR
+Engaged as appropriate for regulatory, contractual, employee, or legal considerations.
+
+## Reporting Requirements
+
+All suspected incidents must be reported as soon as possible through the organization’s designated reporting channel. Reports should include:
+- Date and time observed
+- Reporting individual
+- Systems or users involved
+- Observable symptoms
+- Any actions already taken
+
+## Evidence Handling
+
+When evidence preservation may be necessary:
+- Do not alter impacted systems unnecessarily
+- Record all response actions and timestamps
+- Preserve relevant logs, screenshots, emails, and artifacts
+- Coordinate with legal or forensics personnel where applicable
+
+## Post-Incident Review
+
+All Severity 1 and Severity 2 incidents should receive a documented post-incident review. Severity 3 and 4 events may receive a review when recurring patterns or control weaknesses are identified.

docs/security-program-overview.md

@@ -0,0 +1,86 @@
+# Security Program Overview
+
+## Purpose
+
+This repository represents a lightweight, practical security program foundation suitable for a small business, startup, nonprofit, student lab, or internal department.
+
+The purpose of this program is to reduce security risk by establishing:
+- Clear response procedures for common incidents
+- Consistent documentation standards
+- Basic communication and escalation paths
+- A repeatable method for identifying and tracking risk
+
+## Program Objectives
+
+The security program is designed to achieve the following objectives:
+
+1. Improve organizational readiness for security incidents.
+2. Reduce confusion during high-pressure events.
+3. Ensure incidents are documented consistently.
+4. Support appropriate escalation to leadership and stakeholders.
+5. Track material risks in a simple and maintainable format.
+6. Encourage continuous improvement after incidents occur.
+
+## Scope
+
+This starter program covers:
+- Incident response planning
+- Operational runbooks
+- Incident documentation
+- Post-incident review
+- Lightweight risk tracking
+
+This starter program does not yet include:
+- Full business continuity planning
+- Disaster recovery architecture
+- Detailed compliance mappings
+- Third-party audit evidence collection
+- Formal governance committee structures
+
+## Intended Users
+
+This repository is useful for:
+- Security analysts
+- IT managers
+- Cybersecurity students
+- Security operations teams
+- Small business technology leaders
+- GRC and risk professionals
+
+## Operating Principles
+
+The following principles guide the program:
+
+- Keep procedures simple enough to use under stress.
+- Escalate early when business risk is uncertain.
+- Preserve evidence and document actions as they occur.
+- Communicate clearly and factually.
+- Focus on business impact, not just technical symptoms.
+- Learn from every incident and refine the process.
+
+## Program Components
+
+### Policies and Core Documents
+These define expectations, roles, and governance direction.
+
+### Runbooks
+These provide scenario-specific guidance for common security events.
+
+### Templates
+These standardize documentation and reporting.
+
+### Risk Register
+This records and prioritizes identified risks.
+
+## Maintenance Approach
+
+The repository should be reviewed at least quarterly and after any major incident, organizational change, or control failure.
+
+Suggested maintenance cadence:
+- Monthly: review open risks and update statuses
+- Quarterly: review runbooks and escalation contacts
+- After incidents: complete lessons learned and update related documentation
+
+## Portfolio Value
+
+This repository is intentionally structured to demonstrate that security is not only a technical discipline. It is also a documentation, communication, and risk management discipline.

pyproject.toml

@@ -0,0 +1,24 @@
+[project]
+name = "security-program-starter"
+version = "1.0.0"
+description = "Portfolio-ready incident response runbooks, templates, and lightweight risk register."
+readme = "README.md"
+requires-python = ">=3.10"
+license = { text = "MIT" }
+authors = [
+  { name = "Nick", email = "nick@example.com" }
+]
+dependencies = []
+
+[project.optional-dependencies]
+dev = [
+  "pytest>=8.0.0",
+  "ruff>=0.6.0",
+]
+
+[tool.ruff]
+line-length = 100
+target-version = "py310"
+
+[tool.pytest.ini_options]
+testpaths = ["tests"]

risk_register/risk_register.csv

@@ -0,0 +1,7 @@
+risk_id,title,description,asset_or_process,threat,vulnerability,existing_controls,likelihood,impact,inherent_score,residual_likelihood,residual_impact,residual_score,owner,treatment,status,target_date
+R-001,Weak MFA Adoption,Remote access accounts are not consistently protected by multifactor authentication,Remote Access,Credential Theft,Inconsistent MFA enforcement,Password policy and limited MFA,4,5,20,2,4,8,IT Manager,Mitigate,In Progress,2026-06-30
+R-002,Single Admin Account Dependency,Too few staff have documented administrative backup coverage,Identity and Access Management,Operational Disruption,Key person dependency,Admin procedures exist but are informal,3,4,12,2,3,6,Security Lead,Mitigate,Open,2026-07-15
+R-003,Inadequate Phishing Awareness,Users may not identify malicious email attempts,Email and User Accounts,Phishing,Limited awareness training,Spam filtering and user reporting mailbox,4,4,16,3,3,9,HR and IT,Mitigate,Open,2026-08-01
+R-004,Untracked Vendor Access,Third-party support access is not centrally reviewed,Vendor Management,Unauthorized Access,Incomplete vendor inventory,Ad hoc approval process,3,4,12,2,3,6,Operations Manager,Mitigate,Open,2026-07-31
+R-005,Endpoint Encryption Gaps,Some portable devices may not have confirmed full disk encryption enabled,Mobile Devices,Data Exposure,Inconsistent asset verification,Asset inventory and baseline standards,3,5,15,2,3,6,Endpoint Administrator,Mitigate,In Progress,2026-06-20
+R-006,Backup Restoration Uncertainty,Backups exist but restoration testing is not consistently documented,Backup and Recovery,Extended Outage,Insufficient recovery validation,Daily backups,3,5,15,2,4,8,Infrastructure Lead,Mitigate,Open,2026-09-01