diff --git a/docs/README.skills.md b/docs/README.skills.md
index 1f24d0b37..e061265da 100644
--- a/docs/README.skills.md
+++ b/docs/README.skills.md
@@ -114,6 +114,7 @@ See [CONTRIBUTING.md](../CONTRIBUTING.md#adding-skills) for guidelines on how to
 | [csharp-tunit](../skills/csharp-tunit/SKILL.md) | Get best practices for TUnit unit testing, including data-driven tests | None |
 | [csharp-xunit](../skills/csharp-xunit/SKILL.md) | Get best practices for XUnit unit testing, including data-driven tests | None |
 | [daily-prep](../skills/daily-prep/SKILL.md) | Prepare for tomorrow's meetings and tasks. Pulls calendar from Outlook via WorkIQ, cross-references open tasks and workspace context, classifies meetings, detects conflicts and day-fit issues, finds learning and deep-work slots, and generates a structured HTML prep file with productivity recommendations. | None |
+| [data-breach-blast-radius](../skills/data-breach-blast-radius/SKILL.md) | Pre-breach impact analysis: inventories sensitive data (PII, PHI, PCI-DSS, credentials), traces data flows, scores exposure vectors, and produces a regulatory blast radius report with fine ranges sourced verbatim from GDPR Art. 83, CCPA § 1798.155(a), and HIPAA 45 CFR § 160.404. Cost benchmarks from IBM Cost of a Data Breach Report (annually updated). All citations in references/SOURCES.md for verification. Use when asked: "assess breach impact", "what data could be exposed", "calculate blast radius", "data exposure analysis", "how bad would a breach be", "quantify data risk", "sensitive data inventory", "data flow security audit", "pre-breach assessment", "worst-case breach scenario", "breach readiness", "data risk report", "/data-breach-blast-radius". For any stack handling user data, health records, or financial information. Output labels law-sourced figures (exact) vs heuristic estimates (planning only). Does not replace legal counsel. | `references/SOURCES.md`<br />`references/blast-radius-calculator.md`<br />`references/data-classification.md`<br />`references/hardening-playbook.md`<br />`references/regulatory-impact.md`<br />`references/report-format.md` |
 | [datanalysis-credit-risk](../skills/datanalysis-credit-risk/SKILL.md) | Credit risk data cleaning and variable screening pipeline for pre-loan modeling. Use when working with raw credit data that needs quality assessment,  missing value analysis, or variable selection before modeling. it covers data loading and formatting, abnormal period filtering, missing rate calculation, high-missing variable removal,low-IV variable filtering, high-PSI variable removal, Null Importance denoising, high-correlation variable removal, and cleaning report generation. Applicable scenarios arecredit risk data cleaning, variable screening, pre-loan modeling preprocessing. | `references/analysis.py`<br />`references/func.py`<br />`scripts/example.py` |
 | [dataverse-python-advanced-patterns](../skills/dataverse-python-advanced-patterns/SKILL.md) | Generate production code for Dataverse SDK using advanced patterns, error handling, and optimization techniques. | None |
 | [dataverse-python-production-code](../skills/dataverse-python-production-code/SKILL.md) | Generate production-ready Python code using Dataverse SDK with error handling, optimization, and best practices | None |
diff --git a/skills/data-breach-blast-radius/SKILL.md b/skills/data-breach-blast-radius/SKILL.md
new file mode 100644
index 000000000..0496b1593
--- /dev/null
+++ b/skills/data-breach-blast-radius/SKILL.md
@@ -0,0 +1,259 @@
+---
+name: data-breach-blast-radius
+description: 'Pre-breach impact analysis: inventories sensitive data (PII, PHI, PCI-DSS, credentials), traces data flows, scores exposure vectors, and produces a regulatory blast radius report with fine ranges sourced verbatim from GDPR Art. 83, CCPA § 1798.155(a), and HIPAA 45 CFR § 160.404. Cost benchmarks from IBM Cost of a Data Breach Report (annually updated). All citations in references/SOURCES.md for verification. Use when asked: "assess breach impact", "what data could be exposed", "calculate blast radius", "data exposure analysis", "how bad would a breach be", "quantify data risk", "sensitive data inventory", "data flow security audit", "pre-breach assessment", "worst-case breach scenario", "breach readiness", "data risk report", "/data-breach-blast-radius". For any stack handling user data, health records, or financial information. Output labels law-sourced figures (exact) vs heuristic estimates (planning only). Does not replace legal counsel.'
+---
+
+# Data Breach Blast Radius Analyzer
+
+You are a **Data Breach Impact Expert**. Your mission is to answer the most important security question most teams never ask before a breach: **"If we were breached right now, how bad would it be — and what would it cost us?"**
+
+This skill performs a **proactive blast radius analysis**: a full audit of what sensitive data your codebase handles, how it flows, where it could leak, how many people would be affected, and what regulatory consequences would follow — before any breach occurs.
+
+> **Why this matters:** 83% of organizations have experienced more than one data breach (IBM Cost of a Data Breach Report). The global average breach cost was **$4.88M in 2024**, with the 2025 IBM report showing a 9% decrease — download the current edition at https://www.ibm.com/reports/data-breach. Organizations that identify and remediate exposure points before a breach consistently face lower regulatory fines due to demonstrable due diligence.
+
+> **What this skill produces vs. what is legally exact:**
+> - **Legally exact:** Regulatory fine maximums and breach notification timelines (sourced verbatim from GDPR Art. 83, CCPA § 1798.155, 45 CFR § 160.404, etc. — all cited in `references/SOURCES.md`)
+> - **Planning estimates:** Blast radius scores, financial impact ranges, and record counts (heuristic models based on OWASP risk methodology and IBM benchmarks)
+> - **Always state in output:** Which figures are law-sourced (exact) vs. model-derived (estimate)
+> - **Never replace** qualified legal counsel or a formal DPIA/risk assessment
+
+---
+
+## When to Activate
+
+- Auditing a codebase before a security review or pentest
+- Preparing a data processing impact assessment (DPIA)
+- Building or reviewing a disaster recovery / incident response plan
+- Onboarding a new system that handles customer data
+- Preparing for regulatory compliance (GDPR, CCPA, HIPAA, SOC 2)
+- Responding to "what's our exposure?" from engineering leadership
+- Any request mentioning: blast radius, breach impact, data exposure, sensitive data inventory, data risk, worst-case scenario
+- Direct invocation: `/data-breach-blast-radius`
+
+---
+
+## How This Skill Works
+
+Unlike tools that only find vulnerabilities, this skill **quantifies business and regulatory impact**:
+
+1. **Discovers** every sensitive data asset in the codebase (schemas, models, DTOs, logs, configs, API contracts)
+2. **Classifies** data into severity tiers (Tier 1–4) using global regulatory standards
+3. **Traces** data flows from ingestion → processing → storage → transmission → deletion
+4. **Identifies** all exposure vectors — where data could leak (API endpoints, logs, exports, caches, queues)
+5. **Calculates** the blast radius: estimated records affected, user population at risk, regulatory jurisdictions triggered
+6. **Quantifies** the regulatory impact (GDPR fines, CCPA penalties, HIPAA sanctions, breach notification costs)
+7. **Generates** a prioritized hardening roadmap ordered by impact-per-effort
+
+---
+
+## Execution Workflow
+
+Follow these steps **in order** every time:
+
+### Step 1 — Scope & Stack Detection
+
+Determine what to analyze:
+- If a path was given (`/data-breach-blast-radius src/`), analyze that scope
+- If no path is given, analyze the **entire project**
+- Detect language(s) and frameworks (check `package.json`, `requirements.txt`, `go.mod`, `pom.xml`, `Cargo.toml`, `Gemfile`, `composer.json`, `.csproj`)
+- Identify the database layer (ORM models, schema files, migrations, Prisma schema, Entity Framework, Hibernate, SQLAlchemy, ActiveRecord)
+- Identify API layer (REST controllers, GraphQL schemas, gRPC proto files, OpenAPI specs)
+- Identify infrastructure-as-code (Terraform, Bicep, CloudFormation, Pulumi) for storage resource exposure
+
+Read `references/data-classification.md` to load the full sensitivity tier taxonomy.
+
+---
+
+### Step 2 — Sensitive Data Inventory
+
+Scan ALL files for sensitive data definitions:
+
+**Data Model Layer:**
+- Database schemas, migrations, ORM models, entity classes
+- GraphQL types, Prisma schema, TypeORM entities, Mongoose schemas
+- Identify every field that maps to a data category in `references/data-classification.md`
+- Note the table/collection name and estimated cardinality (if seeders, fixtures, or comments reveal scale)
+
+**API Contract Layer:**
+- REST request/response DTOs and serializers
+- GraphQL query/mutation return types
+- gRPC proto message definitions
+- OpenAPI / Swagger spec fields
+- Flag fields that expose sensitive data externally
+
+**Configuration & Secrets:**
+- Environment files (`.env`, `.env.*`), config files, `appsettings.json`, `application.yml`
+- Terraform/Bicep variable files and outputs
+- CI/CD pipeline files (`.github/workflows/`, `.gitlab-ci.yml`, `Jenkinsfile`, `azure-pipelines.yml`)
+- Docker/Kubernetes config maps and secrets
+
+**Log & Audit Layer:**
+- Logging statements — identify what user data gets logged
+- Analytics/telemetry integrations (Segment, Mixpanel, Datadog, Sentry, Application Insights)
+- Audit log tables and event tracking
+
+For each sensitive data field found, record:
+```
+| Field | Table/Source | Data Tier | Purpose | Encrypted? | Notes |
+```
+
+> **Classification basis:** Tier assignments follow GDPR Article 9 (special categories), PCI-DSS v4.0, and HIPAA 45 CFR Part 164. See `references/data-classification.md` for the full taxonomy and `references/SOURCES.md` for primary source links.
+
+---
+
+### Step 3 — Data Flow Tracing
+
+Trace how sensitive data moves through the system:
+
+**Ingestion Points (data enters the system):**
+- Form submissions, API POST/PUT endpoints, file uploads
+- Third-party webhooks, OAuth callbacks, SSO assertions
+- Data imports, CSV/Excel ingestion, ETL pipelines
+
+**Processing Points (data is used/transformed):**
+- Business logic operating on sensitive fields
+- Caching layers (Redis, Memcached) — what keys contain PII?
+- Message queues (Kafka, SQS, Service Bus, RabbitMQ) — what payloads?
+- Background jobs and workers — what data do they process?
+
+**Storage Points (data at rest):**
+- Primary databases (SQL, NoSQL, time-series)
+- File storage (S3, Azure Blob, GCS, local filesystem)
+- Search indexes (Elasticsearch, OpenSearch, Azure AI Search, Algolia) — are PII fields indexed?
+- Analytics warehouses (BigQuery, Snowflake, Redshift, Synapse) — are they scoped properly?
+- Backup stores — are backups encrypted and access-controlled?
+
+**Transmission Points (data leaves the system):**
+- Outbound API calls to third parties (payment processors, email providers, analytics)
+- Webhook deliveries — what payload is sent?
+- Report/export generation (CSV, PDF, Excel downloads)
+- Email/SMS/push notifications — what data is included in the message body?
+
+**Exposure Points (data can reach unauthorized parties):**
+- Public-facing API endpoints without authentication
+- Missing authorization checks (IDOR / BOLA vulnerabilities)
+- Overly broad API responses (returning more fields than needed)
+- CORS misconfigurations
+- Publicly accessible storage buckets or containers
+- Logging sensitive data to stdout/stderr in containerized environments
+- Error messages or stack traces containing PII
+- Debug endpoints left active in production
+
+Read `references/blast-radius-calculator.md` for scoring formulas.
+
+---
+
+### Step 4 — Blast Radius Calculation
+
+For each **exposure vector** identified in Step 3, calculate:
+
+```
+Blast Radius Score = Data Sensitivity Tier × Exposure Likelihood × Population Scale × Data Completeness
+```
+
+**Population Scale Estimate:**
+- If user counts are hard-coded (e.g., seeder files, comments, README): use that
+- If no count found: use a conservative estimate and state the assumption
+  - SaaS product → assume 10K–1M users
+  - Internal tool → assume 100–10K users
+  - Consumer app → assume 100K–10M users
+- Apply a **multiplier** if the breach would expose data of minors (×2), health data (×3), or financial credentials (×5) due to regulatory severity
+
+**Regulatory Jurisdiction Detection:**
+- If `gdpr` / EU currencies / EU phone formats / `.eu` domains / EU datacenter regions found → GDPR applies
+- If California residents mentioned / US `.com` / Stripe US / state-specific tax logic → CCPA applies
+- If health record fields (diagnosis, medication, ICD codes, FHIR resources) → HIPAA applies
+- If Brazilian users / BRL currency / CPF fields → LGPD applies
+- If Singapore / Thailand / Malaysia / Philippines data patterns → PDPA applies
+- Apply ALL jurisdictions that match — the most restrictive governs notification timeline
+
+Read `references/regulatory-impact.md` for fine calculation formulas and notification requirements.
+
+---
+
+### Step 5 — Regulatory Impact Estimation
+
+For each triggered jurisdiction:
+- Calculate the **maximum fine exposure** using formulas in `references/regulatory-impact.md`
+- Calculate the **minimum fine exposure** (realistic for first offense with cooperation)
+- Estimate the **breach notification cost** (legal, communications, credit monitoring)
+- Estimate the **reputational multiplier** (public-facing breach vs. internal tool)
+
+Generate a **Financial Impact Summary Table:**
+```
+| Regulation | Max Fine | Realistic Fine | Notification Cost | Timeline |
+```
+
+> Note: These are estimates for risk planning purposes only. Always consult legal counsel for actual regulatory guidance.
+
+---
+
+### Step 6 — Blast Radius Report Generation
+
+Read `references/report-format.md` and generate the full report.
+
+The report MUST include:
+1. **Executive Summary** (2–3 paragraphs, no jargon)
+2. **Sensitive Data Inventory** (table: all PII/PHI/financial/credential fields found)
+3. **Data Flow Map** (Mermaid diagram of data moving through the system)
+   - After building the Mermaid markup, **call `renderMermaidDiagram`** with the markup and a short title so the diagram renders visually — do not output it as a fenced code block
+   - Use `style` directives: `fill:#ff4444` (red) for critical findings, `fill:#ff8800` (orange) for high-severity exposure points
+4. **Top 5 Exposure Vectors** (ranked by blast radius score)
+5. **Regulatory Blast Radius Table** (per-jurisdiction)
+6. **Financial Impact Estimate** (realistic range)
+7. **Hardening Roadmap** (from `references/hardening-playbook.md`)
+
+---
+
+### Step 7 — Hardening Roadmap
+
+Read `references/hardening-playbook.md` and generate a **prioritized action plan**:
+
+For each critical or high-severity exposure vector:
+- **What to fix**: specific code/config change
+- **Why**: regulatory risk and user impact
+- **Effort**: Low / Medium / High
+- **Impact**: blast radius reduction percentage (estimated)
+- **Quick win flag**: mark items fixable in < 1 day
+
+Sort by: `(Impact × Severity) / Effort` — highest value first.
+
+---
+
+## Output Rules
+
+- **Always** start with the Executive Summary — leadership reads this first
+- **Always** include the Sensitive Data Inventory table — this is the foundation
+- **Always** produce the Financial Impact Estimate — this drives organizational change
+- **Always** call `renderMermaidDiagram` for the Data Flow Map — never output raw Mermaid code blocks; the tool renders it as a visual diagram automatically
+- **Never** auto-apply any code changes — present the hardening roadmap for human review
+- **Be specific** — cite file paths, field names, and line numbers for every finding
+- **State assumptions** — if record count is estimated, say so explicitly
+- **Be calibrated** — distinguish "this is definitely exposed" from "this could be exposed under conditions X"
+- If the codebase has minimal sensitive data and strong controls, say so clearly and explain what was scanned
+
+---
+
+## Severity Tiers for Blast Radius
+
+| Tier | Label | Examples | Multiplier |
+|------|-------|----------|------------|
+| T1 | **Catastrophic** | Government IDs, biometric data, health records, financial credentials, passwords | ×5 |
+| T2 | **Critical** | Full name + address + DOB combined, payment card data (PAN), SSN, passport numbers | ×4 |
+| T3 | **High** | Email + password (hashed), phone numbers, precise geolocation, IP addresses, device fingerprints | ×3 |
+| T4 | **Elevated** | First name only, email address only, general location (city), usage analytics | ×2 |
+| T5 | **Standard** | Non-personal config data, public content, anonymized aggregates | ×1 |
+
+---
+
+## Reference Files
+
+Load on-demand as needed:
+
+| File | Use When | Content |
+|------|----------|---------|
+| `references/data-classification.md` | **Step 2 — always** | Complete taxonomy of PII, PHI, PCI-DSS, financial, credential, and behavioral data with detection patterns |
+| `references/blast-radius-calculator.md` | **Step 4** | Scoring formulas, population scale estimators, completeness multipliers, exposure likelihood matrix |
+| `references/regulatory-impact.md` | **Step 5** | GDPR/CCPA/HIPAA/LGPD/PDPA fine formulas, notification timelines, breach cost benchmarks, jurisdiction detection patterns |
+| `references/hardening-playbook.md` | **Step 7** | Prioritized controls: encryption, access control, data minimization, tokenization, audit logging, anonymization patterns by tech stack |
+| `references/report-format.md` | **Step 6** | Full report template with Mermaid data flow diagram syntax, financial summary table, hardening roadmap format |
diff --git a/skills/data-breach-blast-radius/references/SOURCES.md b/skills/data-breach-blast-radius/references/SOURCES.md
new file mode 100644
index 000000000..dc5076f7f
--- /dev/null
+++ b/skills/data-breach-blast-radius/references/SOURCES.md
@@ -0,0 +1,186 @@
+# Sources & Validation
+
+Every number, formula, and classification in this skill is sourced from a publicly verifiable primary source. This file exists so contributors, reviewers, and users can independently verify all claims before trusting the output.
+
+**If you find a number that is wrong, outdated, or missing a citation — please open a PR against this file.**
+
+---
+
+## Data Classification Standards
+
+### GDPR Special Categories (Tier 1 classification basis)
+- **Source:** Regulation (EU) 2016/679 — Article 9 "Processing of special categories of personal data"
+- **URL:** https://gdpr-info.eu/art-9-gdpr/
+- **What it says:** Biometric data, health data, genetic data, racial/ethnic origin, political opinions, religious beliefs, sex life/orientation are "special categories" requiring explicit consent.
+- **Our use:** These map directly to Tier 1 in `data-classification.md`
+
+### PCI-DSS Data Classification
+- **Source:** PCI Security Standards Council — PCI DSS v4.0 (March 2022)
+- **URL:** https://www.pcisecuritystandards.org/document_library/
+- **What it says:** Primary Account Number (PAN), cardholder name, expiration date, service code = cardholder data. CVV = sensitive authentication data. Both must be protected.
+- **Our use:** Maps to Tier 2 PCI-DSS in `data-classification.md`
+
+### HIPAA Protected Health Information (PHI) Definition
+- **Source:** 45 CFR Part 160 and Part 164 (Health Insurance Portability and Accountability Act)
+- **URL:** https://www.hhs.gov/hipaa/for-professionals/privacy/special-topics/de-identification/index.html
+- **What it says:** The 18 HIPAA identifiers that make health data "protected" — includes names, geographic data, dates, phone numbers, emails, SSNs, medical record numbers, health plan IDs, etc.
+- **Our use:** Tier 1 PHI fields in `data-classification.md`
+
+---
+
+## GDPR Fine Formulas
+
+**Source:** Regulation (EU) 2016/679 — Article 83 "General conditions for imposing administrative fines"
+**URL:** https://gdpr-info.eu/art-83-gdpr/
+
+**Exact legal text (Article 83.4):**
+> "Infringements of the following provisions shall...be subject to administrative fines up to 10 000 000 EUR, or in the case of an undertaking, up to 2 % of the total worldwide annual turnover of the preceding financial year, whichever is higher..."
+
+**Exact legal text (Article 83.5):**
+> "Infringements of the following provisions shall...be subject to administrative fines up to 20 000 000 EUR, or in the case of an undertaking, up to 4 % of the total worldwide annual turnover of the preceding financial year, whichever is higher..."
+
+**Our formula:** Directly transcribed from Article 83.4 (Tier 1 violations) and Article 83.5 (Tier 2 violations). No interpretation added.
+
+**Historic fines for calibration (all publicly verified):**
+
+| Fine | Organization | Year | Source URL |
+|------|-------------|------|------------|
+| €1.2B | Meta (Ireland DPC) | 2023 | https://www.dataprotection.ie/en/news-media/press-releases/data-protection-commission-announces-decision-in-meta-ireland-inquiry |
+| €746M | Amazon (Luxembourg) | 2021 | https://iapp.org/news/a/amazon-hit-with-887m-fine-for-gdpr-violations/ |
+| €225M | WhatsApp (Ireland DPC) | 2021 | https://www.dataprotection.ie/en/news-media/press-releases/data-protection-commission-announces-decision-in-whatsapp-inquiry |
+| €150M | Google (France CNIL) | 2022 | https://www.cnil.fr/en/cookies-cnil-fines-google-150-million-euros-and-facebook-60-million-euros |
+| €35.3M | H&M (Hamburg DPA) | 2020 | https://www.datenschutz-hamburg.de/news/detail/article/hamburgische-beauftragte-fuer-datenschutz-und-informationsfreiheit-verhaengt-bussgeld-gegen-hm.html |
+| €22M | British Airways (ICO) | 2020 | https://ico.org.uk/about-the-ico/media-centre/news-and-blogs/2020/10/ico-fines-british-airways-20m-for-data-breach-affecting-more-than-400-000-customers/ |
+| €18.4M | Marriott (ICO) | 2020 | https://ico.org.uk/about-the-ico/media-centre/news-and-blogs/2020/10/ico-fines-marriott-international-inc18-4million-for-failing-to-keep-customers-personal-data-secure/ |
+
+---
+
+## CCPA / CPRA Fine Formula
+
+**Source:** California Civil Code § 1798.155(a) — California Consumer Privacy Act
+**URL:** https://leginfo.legislature.ca.gov/faces/codes_displaySection.xhtml?lawCode=CIV&sectionNum=1798.155
+
+> **Note (as of June 30, 2025):** Stats. 2025, Ch. 20, Sec. 1 (AB 137) amended § 1798.155. The administrative fine amounts are now in **subsection (a)**. Old references to `§ 1798.155(b)` for fine amounts are incorrect under the amended text. Verify at the URL above for any future changes.
+
+**Exact statutory text (§ 1798.155(a) as amended):**
+> "Any business, service provider, contractor, or other person that violates this title shall be liable for an administrative fine of not more than two thousand five hundred dollars ($2,500) for each violation or seven thousand five hundred dollars ($7,500) for each intentional violation..."
+
+**Private Right of Action source:** California Civil Code § 1798.150
+**URL:** https://leginfo.legislature.ca.gov/faces/codes_displaySection.xhtml?lawCode=CIV&sectionNum=1798.150
+
+**Exact statutory text:**
+> "Any consumer whose nonencrypted and nonredacted personal information...is subject to an unauthorized access and exfiltration...may institute a civil action for...damages in an amount not less than one hundred dollars ($100) and not greater than seven hundred and fifty ($750) per consumer per incident or actual damages, whichever is greater..."
+
+**Our formula:** Directly transcribed. $2,500 / $7,500 per violation comes verbatim from § 1798.155(a) (as amended June 30, 2025). $100–$750 private right of action comes verbatim from § 1798.150.
+
+---
+
+## HIPAA Fine Formula
+
+**Source:** 45 CFR § 160.404 — Civil Money Penalties
+**URL:** https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-160/subpart-D/section-160.404
+
+**Source (HHS penalty tiers explained):** HHS Office for Civil Rights
+**URL:** https://www.hhs.gov/hipaa/for-professionals/compliance-enforcement/agreements/index.html
+
+**HHS OCR penalty tiers (current inflation-adjusted 2024 amounts):**
+- Tier A (no knowledge): $137–$68,928 per violation, $2,067,813 annual cap
+- Tier B (reasonable cause): $1,379–$68,928, $2,067,813 annual cap
+- Tier C (willful, corrected): $13,785–$68,928, $2,067,813 annual cap
+- Tier D (willful, not corrected): $68,928–$1,919,173, $1,919,173 annual cap
+
+**URL for current amounts:** https://www.hhs.gov/hipaa/for-professionals/compliance-enforcement/examples/all-cases/index.html
+
+**Note on our figures:** The dollar amounts in `regulatory-impact.md` match HHS's inflation-adjusted 2024 penalty tiers. HHS adjusts these annually. Always verify against the HHS OCR website for the current year.
+
+**Criminal penalties source:** 42 U.S.C. § 1320d-6
+**URL:** https://uscode.house.gov/view.xhtml?req=granuleid:USC-prelim-title42-section1320d-6
+
+---
+
+## LGPD Fine Formula
+
+**Source:** Lei Geral de Proteção de Dados Pessoais (LGPD) — Lei nº 13.709/2018, Article 52
+**URL:** https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/l13709.htm
+
+**Exact text (Art. 52, I):** Fine of up to 2% of revenue of a private legal entity or group in Brazil in its last fiscal year, limited to R$50,000,000 (fifty million reais) per infraction.
+
+**Our formula:** Verbatim from Article 52.
+
+---
+
+## Singapore PDPA Fine Formula
+
+**Source:** Personal Data Protection Act 2012 (Singapore) — Section 48J
+**URL:** https://sso.agc.gov.sg/Act/PDPA2012
+
+**Maximum fine:** S$1,000,000 per breach OR 10% of annual turnover in Singapore (if turnover > S$10M) — whichever is higher, per the 2021 amendment.
+
+---
+
+## Breach Cost Benchmarks
+
+**Source:** IBM Security — "Cost of a Data Breach Report" (published annually since 2005)
+**URL:** https://www.ibm.com/reports/data-breach
+**Publisher:** IBM Security + Ponemon Institute
+**Methodology (2024 edition):** Survey of 604 organizations across 17 industries in 16 countries/regions. Each breach involved 2,170–113,954 compromised records.
+
+**Last-verified figures (IBM 2024 edition):**
+| Metric | Value | Source |
+|--------|-------|--------|
+| Global average total cost | $4.88M | IBM 2024, p.4 |
+| Healthcare cost per record | $408 | IBM 2024, p.12 |
+| Average cost per record (all industries) | $165 | IBM 2024, p.11 |
+| Average time to identify breach | 194 days | IBM 2024, p.15 |
+| Average time to contain breach | 73 days | IBM 2024, p.15 |
+| Cost premium for breaches > 200 days | +$1.02M | IBM 2024, p.16 |
+| Cost reduction from AI/ML security | -$2.22M | IBM 2024, p.20 |
+| Cost reduction from IR planning | -$232K | IBM 2024, p.21 |
+| Cost reduction from employee training | -$258K | IBM 2024, p.21 |
+
+**2025 update:** The IBM 2025 report (live at the URL above) reports a 9% decrease in the global average from $4.88M. The exact 2025 figure requires downloading the report PDF. **Skill maintainers: update this table annually when a new edition is published.**
+
+---
+
+## Breach Notification Timelines
+
+| Regulation | Timeline | Source |
+|-----------|---------|--------|
+| GDPR | 72 hours | GDPR Article 33.1 — https://gdpr-info.eu/art-33-gdpr/ |
+| UK GDPR | 72 hours | UK GDPR Article 33 (retained EU law) — https://ico.org.uk/for-organisations/report-a-breach/ |
+| HIPAA | 60 days | 45 CFR § 164.412 — https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-D/section-164.412 |
+| CCPA | "Most expedient time" | Cal. Civ. Code § 1798.82 — https://leginfo.legislature.ca.gov/faces/codes_displaySection.xhtml?lawCode=CIV&sectionNum=1798.82 |
+| Singapore PDPA | 3 calendar days | PDPA Section 26D — https://sso.agc.gov.sg/Act/PDPA2012 |
+| Australia Privacy Act | 30 days | Privacy Act 1988, APP 1 + NDB Scheme — https://www.oaic.gov.au/privacy/notifiable-data-breaches |
+| LGPD Brazil | 2 business days (ANPD guidance) | ANPD Resolution CD/ANPD nº 2/2022 — https://www.gov.br/anpd/pt-br |
+| Japan APPI | 3–5 business days (2022 amendment) | Act on Protection of Personal Information Art. 26 — https://www.ppc.go.jp/en/legal/ |
+| PIPEDA Canada | "As soon as feasible" | PIPEDA s.10.1 — https://www.priv.gc.ca/en/privacy-topics/privacy-laws-in-canada/the-personal-information-protection-and-electronic-documents-act-pipeda/ |
+
+---
+
+## Blast Radius Formula Basis
+
+The scoring formula structure is adapted from established risk quantification frameworks:
+
+| Component | Based on |
+|-----------|---------|
+| Tier Weight × Exposure Likelihood | OWASP Risk Rating Methodology — https://owasp.org/www-community/OWASP_Risk_Rating_Methodology |
+| Completeness Factor | FAIR (Factor Analysis of Information Risk) model — https://www.fairinstitute.org/ |
+| Population Scale normalization | CVSS v4.0 Attack Scale metric — https://www.first.org/cvss/v4-0/ |
+| Context multipliers | GDPR recitals 75, 91 (special categories increase risk level) — https://gdpr-info.eu/recital-75-gdpr/ |
+
+**What the formula is NOT:** It is not a legally recognized standard. It is a planning heuristic based on accepted risk frameworks, producing a relative score to compare exposure vectors — not an absolute prediction of breach cost.
+
+---
+
+## What Is Estimated vs. What Is Exact
+
+| Item | Status | Notes |
+|------|--------|-------|
+| GDPR fine maximum (€20M / 4% turnover) | **Exact** — verbatim from Art. 83.5 | This is the law |
+| CCPA fine ($2,500 / $7,500) | **Exact** — verbatim from § 1798.155(a) (as amended June 30, 2025) | This is the law |
+| HIPAA tier amounts | **Exact for 2024** — HHS inflation-adjusted | Update annually |
+| Blast Radius Score | **Estimate** — heuristic planning tool | Not a legal or insurance figure |
+| Financial impact range ($X–$Y) | **Estimate** — IBM benchmarks + fine formula applied to population | Not a prediction |
+| "Probable" fine amount | **Estimate** — based on historic fine patterns | Real fines vary enormously by regulator |
+| Notification timeline | **Exact** — verbatim from law | These are hard legal deadlines |
diff --git a/skills/data-breach-blast-radius/references/blast-radius-calculator.md b/skills/data-breach-blast-radius/references/blast-radius-calculator.md
new file mode 100644
index 000000000..6cd4a0dbf
--- /dev/null
+++ b/skills/data-breach-blast-radius/references/blast-radius-calculator.md
@@ -0,0 +1,253 @@
+# Blast Radius Calculator
+
+Formulas, scoring matrices, and estimation heuristics for quantifying how many people, records, and systems would be affected by a data breach in the codebase under analysis.
+
+---
+
+## Core Blast Radius Formula
+
+```
+Blast Radius Score (BRS) = Tier_Weight × Exposure_Likelihood × Population_Scale × Completeness_Factor × Context_Multiplier
+```
+
+**Score ranges:**
+- 0–25: **Low** — limited exposure, few records
+- 26–50: **Medium** — meaningful exposure, focused population
+- 51–75: **High** — significant exposure, broad regulatory consequences
+- 76–100: **Critical** — catastrophic exposure, immediate action required
+
+---
+
+## Factor 1: Tier Weight (T)
+
+Based on the data classification tier from `data-classification.md`:
+
+| Tier | Label | Weight |
+|------|-------|--------|
+| T1 | Catastrophic | 5.0 |
+| T2 | Critical | 4.0 |
+| T3 | High | 3.0 |
+| T4 | Elevated | 2.0 |
+| T5 | Standard | 1.0 |
+
+**Rule:** When multiple tiers exist in the same exposure vector, use the **highest** tier weight.
+
+**Aggregation uplift:** If 3+ fields from different tiers are exposed together, add +0.5 to the highest tier weight (aggregation attack risk).
+
+---
+
+## Factor 2: Exposure Likelihood (E)
+
+How likely is this vector to be exploited in a realistic breach scenario?
+
+| Likelihood Score | Label | Criteria |
+|-----------------|-------|---------|
+| 1.0 | **Certain** | Data is publicly accessible today (no auth required) |
+| 0.9 | **Near Certain** | Auth bypass is trivial (e.g., IDOR on sequential IDs, broken JWT validation) |
+| 0.8 | **Very Likely** | Auth required but missing for this specific endpoint; or data leaked in logs accessible by most engineers |
+| 0.7 | **Likely** | Auth required but over-broad access (all users can see all data); missing field-level access control |
+| 0.6 | **Moderate** | Requires privilege escalation or chaining with another bug; internal system with broad developer access |
+| 0.5 | **Possible** | Requires significant attacker effort but no defense-in-depth; DB accessible from dev environment |
+| 0.3 | **Unlikely** | Multiple security controls in place; but controls are not verified by the codebase review |
+| 0.1 | **Remote** | Strong defense-in-depth: encryption, field masking, proper authz, rate limiting, anomaly detection all present |
+
+---
+
+## Factor 3: Population Scale (P)
+
+Normalize the estimated number of affected records to a 0–1 scale.
+
+### Estimating Record Counts
+
+**Step 1: Look for explicit signals in the codebase**
+```
+# Strong signals (use these if found):
+- README mentions user count ("serves 5M users")
+- Seeder/fixture files with record counts
+- Migration comments ("adding index for 50K users")
+- Analytics dashboards or monitoring configs mentioning scale
+- Infrastructure configs (DB instance size implies scale):
+  - db.t3.micro → < 10K active users
+  - db.r5.large → 10K–500K users
+  - db.r5.4xlarge / Aurora Serverless → > 500K users
+
+# Medium signals:
+- App category (SaaS product → higher, internal tool → lower)
+- Multi-tenant vs. single-tenant architecture
+- Presence of sharding or partitioning in DB schema
+
+# Weak signals:
+- Tech stack alone (no reliable correlation to user count)
+```
+
+**Step 2: Apply default estimates when no signals are found**
+
+| Application Type | Conservative Estimate | Typical Estimate |
+|-----------------|----------------------|-----------------|
+| Internal corporate tool | 100–1,000 | 500 |
+| B2B SaaS (small/startup) | 1,000–10,000 | 5,000 |
+| B2B SaaS (established) | 10,000–100,000 | 50,000 |
+| B2C app (consumer startup) | 10,000–100,000 | 50,000 |
+| B2C app (growth stage) | 100,000–1,000,000 | 500,000 |
+| B2C app (scale) | 1,000,000–100,000,000 | 10,000,000 |
+| Healthcare system | 1,000–100,000 | 20,000 |
+| Financial services | 5,000–500,000 | 50,000 |
+| Government / public sector | 10,000–10,000,000 | 1,000,000 |
+
+**Always state the assumption used.**
+
+### Population Scale Score (P)
+
+| Records at Risk | Score |
+|----------------|-------|
+| < 100 | 0.1 |
+| 100–1,000 | 0.2 |
+| 1,000–10,000 | 0.3 |
+| 10,000–50,000 | 0.4 |
+| 50,000–100,000 | 0.5 |
+| 100,000–500,000 | 0.6 |
+| 500,000–1,000,000 | 0.7 |
+| 1M–10M | 0.8 |
+| 10M–100M | 0.9 |
+| > 100M | 1.0 |
+
+---
+
+## Factor 4: Completeness Factor (C)
+
+How complete/useful is the exposed data for an attacker?
+
+| Factor | Score | Description |
+|--------|-------|-------------|
+| **Full Profile** | 1.0 | Complete identity record (name + email + phone + address + sensitive field) |
+| **Partial + Joinable** | 0.9 | Partial data but other tables can be joined to complete it; same breach gives attacker the join key |
+| **Email + PII** | 0.8 | Email address plus 1+ sensitive field — enough for targeted phishing + exploitation |
+| **Sensitive Field Only** | 0.7 | Only the sensitive field (SSN, health, financial) without contact info — still very serious |
+| **Contact Only** | 0.5 | Only email / phone — enables spam, phishing, but not immediate harm |
+| **Fragmented** | 0.3 | Fields without context, cannot re-identify without additional data not available in this breach |
+| **Anonymized** | 0.1 | Properly anonymized — re-identification requires significant external data linking |
+
+---
+
+## Factor 5: Context Multipliers (M)
+
+Apply these multipliers to the final score for specific contexts:
+
+| Context | Multiplier | Rationale |
+|---------|-----------|-----------|
+| Children's data present (COPPA / GDPR Art 8) | × 2.0 | Highest legal exposure globally |
+| Health records (HIPAA / GDPR special category) | × 1.8 | Special category data, civil + criminal exposure |
+| Biometric data (GDPR Art 9, BIPA in Illinois) | × 1.8 | Immutable data — cannot be "changed" after breach |
+| Financial account credentials | × 1.7 | Direct financial theft possible |
+| Government IDs (SSN, passport) | × 1.6 | Identity theft lasting years |
+| Sexual orientation / religion / political views | × 1.6 | GDPR special category, discrimination risk |
+| Data held by a healthcare provider | × 1.5 | HIPAA Business Associate exposure |
+| Data in a cloud region that doesn't match user jurisdiction | × 1.3 | Cross-border transfer violations (GDPR Chapter V) |
+| Backup/archive store (often forgotten) | × 1.2 | Backups frequently missed in breach containment |
+
+---
+
+## Blast Radius Score Calculation Examples
+
+### Example 1: E-commerce checkout system
+
+**Exposure vector:** API endpoint `/api/users/{id}/payment-methods` — no ownership check (IDOR)
+- Tier: T2 (card last 4 + billing address) = 4.0
+- Exposure Likelihood: 0.9 (IDOR on sequential IDs, near-certain exploitation)
+- Population Scale: 100K users = 0.6
+- Completeness: Partial profile + joinable to user table = 0.9
+- Context Multiplier: Payment data = 1.7
+
+```
+BRS = 4.0 × 0.9 × 0.6 × 0.9 × 1.7 = 3.30 (raw) → normalized to 66/100 → HIGH
+```
+
+### Example 2: Internal HR tool
+
+**Exposure vector:** Employees table visible to all company users via `/api/employees`
+- Tier: T2 (salary + home address + SSN) = 5.0 (SSN is T1)
+- Exposure Likelihood: 0.7 (auth required, but no RBAC; any employee can see all)
+- Population Scale: 2,000 employees = 0.3
+- Completeness: Full profile = 1.0
+- Context Multiplier: Government IDs (SSN) = 1.6
+
+```
+BRS = 5.0 × 0.7 × 0.3 × 1.0 × 1.6 = 1.68 (raw) → normalized to 34/100 → MEDIUM
+```
+
+However — **financial impact** overrides score here because SSN exposure is Tier 1. Flag as HIGH regardless of score.
+
+---
+
+## Score Normalization
+
+The raw formula output typically ranges 0–8. Normalize to 0–100:
+
+```
+Normalized_BRS = min(100, (raw_BRS / 8.0) × 100)
+```
+
+---
+
+## Blast Radius Summary Table (per exposure vector)
+
+Use this format when reporting:
+
+```markdown
+| # | Exposure Vector | Tier | Likelihood | Pop. at Risk | BRS | Severity | Jurisdiction |
+|---|----------------|------|-----------|-------------|-----|----------|--------------|
+| 1 | /api/users endpoint - SSN returned in response | T1 | 0.9 | 50K | 87 | CRITICAL | GDPR, CCPA |
+| 2 | Logs contain plaintext emails | T3 | 0.6 | 50K | 45 | MEDIUM | GDPR |
+| 3 | Redis cache stores full user objects | T2 | 0.5 | 50K | 38 | MEDIUM | GDPR, CCPA |
+| 4 | S3 bucket - public read on user avatars | T4 | 1.0 | 50K | 28 | LOW | - |
+```
+
+---
+
+## Total Organizational Blast Radius
+
+After scoring all exposure vectors, compute:
+
+**Maximum Simultaneous Exposure (MSE):** The number of unique individuals that could be affected if a single attacker gained broad DB access (worst case). This is the number used in regulatory reporting.
+
+**Expected Breach Exposure (EBE):** The typical exposure based on the most likely attack vector (the highest-likelihood finding, not the highest-impact one).
+
+**Regulatory Trigger Count:** The number of distinct regulatory regimes triggered (each one has its own notification obligation and fine formula).
+
+```markdown
+## Organizational Blast Radius Summary
+
+| Metric | Value |
+|--------|-------|
+| Maximum records at risk | [number] |
+| Users with Tier 1 data | [number] |
+| Users with Tier 2 data | [number] |
+| Users with Tier 3+ data | [number] |
+| Regulations triggered | GDPR, CCPA, [others] |
+| Worst-case BRS | [score] |
+| Most likely attack vector | [description] |
+| Time to detect (estimated) | [industry avg: 194 days if no SIEM] |
+| Time to contain (estimated) | [industry avg: 73 days] |
+```
+
+---
+
+## Breach Cost Benchmarks (IBM Data — Verify Annual Edition)
+
+Use these when no specific cost data is available. Figures below are from the **IBM 2024 edition**. IBM publishes a new edition annually at https://www.ibm.com/reports/data-breach — the 2025 report reports a ~9% decrease in global average cost.
+
+| Metric | Value (IBM 2024) |
+|--------|------------------|
+| Global average cost per breach | $4.88M USD |
+| Average cost per record (healthcare) | $408 USD |
+| Average cost per record (financial) | $231 USD |
+| Average cost per record (average across industries) | $165 USD |
+| Average time to identify breach | 194 days |
+| Average time to contain breach | 73 days |
+| Cost premium for breaches taking > 200 days | +$1.02M above average |
+| Mega breach (1M+ records) cost | $13–65M USD |
+| Cost reduction from incident response planning | -$232K |
+| Cost reduction from AI/ML security deployment | -$2.22M |
+| Cost reduction from employee training | -$258K |
+
+> Source: IBM Cost of a Data Breach Report 2024. State these as benchmarks, not guarantees. Update this table when a new edition is released.
diff --git a/skills/data-breach-blast-radius/references/data-classification.md b/skills/data-breach-blast-radius/references/data-classification.md
new file mode 100644
index 000000000..0a8e43cc5
--- /dev/null
+++ b/skills/data-breach-blast-radius/references/data-classification.md
@@ -0,0 +1,250 @@
+# Data Classification Taxonomy
+
+A comprehensive taxonomy for identifying sensitive data in codebases. Every field, column, model property, or variable matching these patterns should be inventoried and assigned the appropriate sensitivity tier.
+
+---
+
+## Tier 1 — Catastrophic (Irreversible harm if exposed)
+
+### Biometric Data
+**Detection patterns (field names / column names):**
+- `fingerprint`, `thumbprint`, `retina_scan`, `iris_scan`, `face_id`, `facial_recognition`
+- `voice_print`, `voice_biometric`, `gait_analysis`, `dna_profile`, `genetic_data`
+- `biometric_template`, `biometric_hash`, `faceEmbedding`, `face_vector`
+
+**Detection patterns (data values / format):**
+- Base64-encoded blobs > 512 bytes in biometric-named fields
+- Binary columns in tables named `biometric_*`, `face_*`, `fingerprint_*`
+
+### Government-Issued Identifiers
+**Detection patterns:**
+- `ssn`, `social_security_number`, `social_security`, `sin` (Canada), `nino` (UK), `tfn` (Australia)
+- `passport_number`, `passport_no`, `passport_id`
+- `drivers_license`, `drivers_licence`, `dl_number`, `license_number`
+- `national_id`, `national_identification`, `id_number`, `id_card_number`
+- `tax_id`, `tin`, `ein`, `itin`, `vat_number`, `fiscal_code`
+- `aadhaar`, `pan_number` (India), `cpf`, `cnpj` (Brazil), `rut` (Chile/Colombia)
+- `nric`, `fin` (Singapore), `my_kad` (Malaysia), `nik` (Indonesia)
+
+**Regex patterns for values:**
+```
+SSN:          \b\d{3}-\d{2}-\d{4}\b
+UK NINO:      \b[A-CEGHJ-PR-TW-Z]{2}\d{6}[A-D]\b
+CPF (Brazil): \b\d{3}\.\d{3}\.\d{3}-\d{2}\b
+Aadhaar:      \b\d{4}\s\d{4}\s\d{4}\b
+```
+
+### Health & Medical Data (PHI under HIPAA)
+**Detection patterns:**
+- `diagnosis`, `icd_code`, `icd10`, `icd11`, `snomed`, `loinc_code`
+- `medication`, `prescription`, `drug_name`, `dosage`, `treatment`
+- `medical_record_number`, `mrn`, `patient_id`, `encounter_id`
+- `lab_result`, `test_result`, `pathology`, `radiology`
+- `mental_health`, `psychiatric`, `therapy_notes`, `counseling`
+- `hiv_status`, `std_status`, `substance_abuse`, `addiction`
+- `insurance_id`, `insurance_member_id`, `health_plan_id`, `claim_number`
+- `fhir_resource`, `hl7_message`, `dicom_data`
+- `disability`, `handicap`, `chronic_condition`
+- `pregnancy`, `reproductive_health`, `fertility`
+
+### Authentication Credentials
+**Detection patterns:**
+- `password`, `passwd`, `pwd`, `hashed_password`, `password_hash`, `password_digest`
+- `private_key`, `secret_key`, `api_key`, `api_secret`, `api_token`
+- `access_token`, `refresh_token`, `bearer_token`, `id_token`, `jwt_token`
+- `oauth_token`, `oauth_secret`, `oauth_access_token`
+- `mfa_secret`, `totp_secret`, `otp_secret`, `backup_codes`
+- `session_token`, `session_id`, `auth_token`
+- `client_secret`, `client_credential`
+- `private_key_pem`, `rsa_private`, `ecdsa_private`
+
+---
+
+## Tier 2 — Critical (High regulatory exposure)
+
+### Payment Card Data (PCI-DSS)
+**Detection patterns:**
+- `card_number`, `pan`, `primary_account_number`, `credit_card`, `debit_card`
+- `cvv`, `cvc`, `cvv2`, `card_verification`, `security_code`
+- `card_expiry`, `expiration_date`, `exp_date`, `expiry_month`, `expiry_year`
+- `cardholder_name`, `card_holder`
+- `iban`, `bic`, `swift_code`, `routing_number`, `account_number`, `sort_code`
+- `bank_account`, `bank_details`, `wire_transfer`
+
+**Regex patterns for values:**
+```
+Visa:            \b4[0-9]{12}(?:[0-9]{3})?\b
+Mastercard:      \b5[1-5][0-9]{14}\b
+Amex:            \b3[47][0-9]{13}\b
+Generic PAN:     \b[0-9]{13,19}\b (in a PAN-named field)
+CVV:             \b[0-9]{3,4}\b (in a cvv-named field)
+IBAN:            \b[A-Z]{2}\d{2}[A-Z0-9]{4}\d{7}([A-Z0-9]?){0,16}\b
+```
+
+### Identity Combinations (High re-identification risk when combined)
+**Combinations that together constitute Tier 2:**
+- Full name + date of birth
+- Full name + address (street level)
+- Email + date of birth + gender
+- Phone number + address
+
+**Detection patterns:**
+- `full_name`, `first_name` + `last_name` (as separate fields — note both present)
+- `date_of_birth`, `dob`, `birth_date`, `birthdate`, `birthday`
+- `home_address`, `street_address`, `address_line1`, `postal_address`
+- `gender`, `sex`, `pronoun` (when combined with other identifiers)
+
+---
+
+## Tier 3 — High (Regulatory notification triggers)
+
+### Contact Information
+**Detection patterns:**
+- `email`, `email_address`, `user_email`, `contact_email`, `primary_email`
+- `phone`, `phone_number`, `mobile`, `mobile_number`, `cell_phone`, `telephone`
+- `whatsapp_number`, `signal_number`
+
+**Regex patterns:**
+```
+Email:  \b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Z|a-z]{2,}\b
+Phone:  \+?[0-9\s\-\(\)]{7,20}  (in a phone-named field)
+```
+
+### Precise Location Data
+**Detection patterns:**
+- `latitude`, `longitude`, `lat`, `lng`, `lat_lng`, `coordinates`, `geo_point`
+- `gps_location`, `precise_location`, `real_time_location`
+- `home_location`, `work_location`
+
+**Note:** City-level location is Tier 4; street-level or GPS coordinates are Tier 3.
+
+### Network Identifiers
+**Detection patterns:**
+- `ip_address`, `ip`, `client_ip`, `remote_addr`, `x_forwarded_for`
+- `mac_address`, `device_mac`, `hardware_id`
+- `imei`, `imsi`, `device_id`, `advertising_id`, `idfa`, `gaid`
+
+### Authentication Artifacts
+**Detection patterns:**
+- `session_id`, `cookie_value`, `csrf_token` (if long-lived and user-identifying)
+- `remember_me_token`, `persistent_session`
+
+---
+
+## Tier 4 — Elevated (Privacy relevant)
+
+### Partial Personal Identifiers
+**Detection patterns:**
+- `first_name`, `last_name`, `display_name`, `username` (when alone)
+- `profile_picture`, `avatar_url`
+- `city`, `state`, `country`, `region`, `zip_code`, `postal_code`
+- `time_zone`, `locale`, `language_preference`
+
+### Behavioral & Analytics Data
+**Detection patterns:**
+- `user_agent`, `browser`, `device_type`, `os`
+- `search_query`, `search_history`, `browsing_history`
+- `purchase_history`, `order_history`, `transaction_history`
+- `click_event`, `page_view`, `session_duration`
+- `preferences`, `interests`, `tags`, `segments`
+
+### Financial Context (non-card)
+**Detection patterns:**
+- `salary`, `income`, `net_worth`, `credit_score`, `credit_rating`
+- `account_balance`, `wallet_balance`, `subscription_tier`
+
+---
+
+## Tier 5 — Standard (No direct privacy impact)
+
+- System configuration values (non-secret)
+- Public user-facing content (blog posts, public profiles)
+- Anonymized aggregated statistics
+- Non-personal reference data (product catalog, country codes)
+- Internal system identifiers with no external exposure
+
+---
+
+## Detection Guidance for AI Analysis
+
+### Framework-Specific Patterns
+
+**Django / Python:**
+```python
+# Sensitive fields typically appear in models.py
+class User(models.Model):
+    email = models.EmailField()           # Tier 3
+    date_of_birth = models.DateField()    # Tier 2 (combined with name)
+    ssn = models.CharField(max_length=11) # Tier 1
+```
+
+**TypeScript / Prisma:**
+```prisma
+model User {
+  email       String    // Tier 3
+  phoneNumber String?   // Tier 3
+  dateOfBirth DateTime? // Tier 2 (when combined)
+  cardNumber  String?   // Tier 2 PCI-DSS
+}
+```
+
+**Java / Spring / JPA:**
+```java
+@Entity
+public class Patient {
+    @Column(name = "diagnosis")  // Tier 1 PHI
+    private String diagnosis;
+    
+    @Column(name = "ssn")        // Tier 1
+    private String ssn;
+}
+```
+
+**C# / EF Core:**
+```csharp
+public class UserProfile {
+    public string Email { get; set; }        // Tier 3
+    public string PassportNumber { get; set; } // Tier 1
+    public DateTime DateOfBirth { get; set; }  // Tier 2
+}
+```
+
+### Log Statement Patterns (High Risk — often overlooked)
+```python
+# BAD — logs PII
+logger.info(f"User {user.email} logged in from {request.remote_addr}")
+logger.debug(f"Payment for card {card_number}")
+
+# Look for these in logging calls:
+# .info(), .debug(), .warn(), .error(), console.log(), System.out.println()
+```
+
+### API Response Leakage (Serializer/DTO patterns)
+```typescript
+// Check if these fields are included in response objects
+// even if not requested — over-fetching is a common exposure vector
+{
+  "id": "...",
+  "email": "...",          // Tier 3
+  "phone": "...",          // Tier 3 
+  "dateOfBirth": "...",    // Tier 2 — should this be returned?
+  "passwordHash": "...",   // Tier 1 — should NEVER be returned
+  "ssn": "...",            // Tier 1 — should NEVER be returned
+}
+```
+
+---
+
+## Aggregation Risk Assessment
+
+Combination attacks — data that becomes more sensitive when combined:
+
+| Alone | Combined With | Combined Tier | Risk |
+|-------|--------------|---------------|------|
+| Email (T3) | Password hash (T1) | T1 | Account takeover |
+| Name (T4) | DOB (T2) + Address (T2) | T2 | Full identity reconstruction |
+| IP address (T3) | Timestamps + User ID | T2 | Behavioral profiling |
+| City (T4) | Purchase history (T4) | T3 | De-anonymization risk |
+| Health category (T4) | Name + Email | T1 | HIPAA triggering |
+
+**Rule:** Always assess fields in combination, not just in isolation.
diff --git a/skills/data-breach-blast-radius/references/hardening-playbook.md b/skills/data-breach-blast-radius/references/hardening-playbook.md
new file mode 100644
index 000000000..2fc72d5b4
--- /dev/null
+++ b/skills/data-breach-blast-radius/references/hardening-playbook.md
@@ -0,0 +1,449 @@
+# Hardening Playbook
+
+Prioritized controls to reduce data breach blast radius. Controls are organized by **impact category** and include tech-stack-specific implementation patterns. Each control includes a **blast radius reduction estimate**.
+
+> **How to use:** After identifying exposure vectors, match each to a control below. Sort your hardening roadmap by `(Blast_Radius_Reduction × Severity) / Effort`.
+
+---
+
+## Control Priority Matrix
+
+| Priority | Control | Blast Radius Reduction | Effort | Category |
+|----------|---------|----------------------|--------|---------|
+| P0 | Fix IDOR/BOLA — add ownership checks | 90% for affected vector | Low | Authorization |
+| P0 | Remove sensitive fields from API responses | 85% for affected fields | Low | Data Minimization |
+| P0 | Revoke publicly accessible storage (S3/Blob) | 100% for affected store | Low | Access Control |
+| P0 | Remove plaintext credentials from code/logs | 100% for affected secret | Low | Secrets |
+| P1 | Add field-level encryption for T1 data | 80% for encrypted fields | Medium | Encryption |
+| P1 | Mask/tokenize PCI card data | 95% for card exposure | Medium | Tokenization |
+| P1 | Remove PII from log statements | 70% for log exposure | Medium | Logging |
+| P1 | Add authentication to unauthenticated endpoints | 95% for exposed endpoints | Low | Authentication |
+| P2 | Implement data access audit logging | -50% detection time | Medium | Monitoring |
+| P2 | Enable database activity monitoring | -60% detection time | Medium | Monitoring |
+| P2 | Add rate limiting to sensitive endpoints | 60% reduction in data harvesting | Low | Rate Limiting |
+| P2 | Column-level encryption for T2 sensitive data | 70% for encrypted columns | Medium | Encryption |
+| P3 | Implement data retention + auto-deletion | 40% reduction in stale data exposure | High | Data Lifecycle |
+| P3 | Separate analytics store from production PII | 60% for analytics breach | High | Architecture |
+| P3 | Pseudonymize behavioral tracking data | 70% for behavioral data | Medium | Pseudonymization |
+
+---
+
+## P0 — Fix Immediately (< 1 day)
+
+### 1. Fix Authorization: IDOR / BOLA
+
+**What it fixes:** Broken Object Level Authorization — users can access other users' data by changing an ID.
+
+**Detection pattern in code:**
+```python
+# VULNERABLE — no ownership check
+@app.get("/api/orders/{order_id}")
+def get_order(order_id: int):
+    return db.query(Order).filter(Order.id == order_id).first()
+
+# SECURE — ownership check
+@app.get("/api/orders/{order_id}")
+def get_order(order_id: int, current_user: User = Depends(get_current_user)):
+    order = db.query(Order).filter(
+        Order.id == order_id,
+        Order.user_id == current_user.id  # ownership check
+    ).first()
+    if not order:
+        raise HTTPException(status_code=404)
+    return order
+```
+
+```typescript
+// VULNERABLE
+app.get('/api/users/:id/profile', authenticate, async (req, res) => {
+  const user = await User.findById(req.params.id);
+  res.json(user);
+});
+
+// SECURE
+app.get('/api/users/:id/profile', authenticate, async (req, res) => {
+  if (req.params.id !== req.user.id && !req.user.isAdmin) {
+    return res.status(403).json({ error: 'Forbidden' });
+  }
+  const user = await User.findById(req.params.id);
+  res.json(user);
+});
+```
+
+```csharp
+// VULNERABLE
+[HttpGet("orders/{orderId}")]
+public async Task<IActionResult> GetOrder(int orderId)
+{
+    var order = await _db.Orders.FindAsync(orderId);
+    return Ok(order);
+}
+
+// SECURE
+[HttpGet("orders/{orderId}")]
+[Authorize]
+public async Task<IActionResult> GetOrder(int orderId)
+{
+    var userId = User.FindFirst(ClaimTypes.NameIdentifier)?.Value;
+    var order = await _db.Orders
+        .Where(o => o.Id == orderId && o.UserId == userId)
+        .FirstOrDefaultAsync();
+    if (order == null) return NotFound();
+    return Ok(order);
+}
+```
+
+---
+
+### 2. Remove Sensitive Fields from API Responses
+
+**What it fixes:** Over-fetching — APIs return more data than the client needs.
+
+**Pattern:**
+```typescript
+// VULNERABLE — returns all fields including passwordHash, ssn
+const user = await User.findById(id);
+res.json(user);
+
+// SECURE — explicit projection
+const user = await User.findById(id).select('id name email createdAt');
+res.json(user);
+```
+
+```python
+# SECURE — Pydantic response model (FastAPI)
+class UserPublicResponse(BaseModel):
+    id: int
+    name: str
+    email: str
+    # NOTE: password_hash, ssn, date_of_birth NOT included
+
+@app.get("/api/users/{id}", response_model=UserPublicResponse)
+def get_user(id: int):
+    return db.query(User).filter(User.id == id).first()
+```
+
+```java
+// SECURE — DTO with @JsonIgnore
+public class UserResponse {
+    public String id;
+    public String name;
+    public String email;
+    // passwordHash, ssn not included in DTO
+}
+```
+
+---
+
+### 3. Remove Plaintext Credentials from Code
+
+**Detection patterns:**
+```
+# Patterns to search for in all files:
+password\s*=\s*["'][^"']+["']
+api_key\s*=\s*["'][^"']+["']
+secret\s*=\s*["'][^"']+["']
+token\s*=\s*["'][^"']+["']
+connectionString\s*=\s*["'][^"']+["']
+```
+
+**Fix pattern:**
+```python
+# VULNERABLE
+DATABASE_URL = "postgresql://user:p@ssw0rd@prod-db.example.com/mydb"
+
+# SECURE
+import os
+DATABASE_URL = os.environ.get("DATABASE_URL")
+# In production: use Azure Key Vault, AWS Secrets Manager, or GCP Secret Manager
+```
+
+---
+
+## P1 — Fix This Week
+
+### 4. Field-Level Encryption for Tier 1 Data
+
+Encrypt sensitive fields **before** storing them. The encryption key lives in a KMS, not in the database.
+
+**Python / SQLAlchemy + Azure Key Vault:**
+```python
+from azure.keyvault.secrets import SecretClient
+from cryptography.fernet import Fernet
+
+# Encrypt at write time
+def encrypt_field(value: str, key: bytes) -> str:
+    f = Fernet(key)
+    return f.encrypt(value.encode()).decode()
+
+# Decrypt at read time (only when authorized)
+def decrypt_field(encrypted_value: str, key: bytes) -> str:
+    f = Fernet(key)
+    return f.decrypt(encrypted_value.encode()).decode()
+```
+
+**Node.js / Prisma + AWS KMS:**
+```typescript
+import { KMSClient, EncryptCommand, DecryptCommand } from "@aws-sdk/client-kms";
+
+const kms = new KMSClient({ region: "us-east-1" });
+
+async function encryptField(plaintext: string): Promise<string> {
+  const { CiphertextBlob } = await kms.send(new EncryptCommand({
+    KeyId: process.env.KMS_KEY_ARN,
+    Plaintext: Buffer.from(plaintext),
+  }));
+  return Buffer.from(CiphertextBlob!).toString('base64');
+}
+```
+
+**C# / EF Core + Azure Key Vault:**
+```csharp
+// Use Always Encrypted for SQL Server / Azure SQL
+// Or manually encrypt with Azure Key Vault
+services.AddDbContext<AppDbContext>(options =>
+    options.UseSqlServer(connectionString, sqlOptions =>
+        sqlOptions.EnableSensitiveDataLogging(false)));
+
+// In entity:
+[Column(TypeName = "nvarchar(500)")]
+public string EncryptedSsn { get; set; } // store Base64 ciphertext
+```
+
+**Fields that MUST be field-encrypted (Tier 1):**
+- SSN / national ID numbers
+- Passport numbers
+- Full payment card numbers (better: use tokenization, see below)
+- Medical record data / diagnoses
+- Biometric templates
+
+---
+
+### 5. Tokenize Payment Card Data
+
+**Never store full card numbers.** Use a PCI-compliant vault instead.
+
+**Recommended providers:**
+- Stripe (tokenizes via Elements/PaymentIntents — you never touch card numbers)
+- Braintree / PayPal
+- Adyen
+- Square
+
+**Pattern:**
+```typescript
+// CORRECT — use Stripe's tokenization
+const paymentMethod = await stripe.paymentMethods.create({
+  type: 'card',
+  card: { token: cardToken }, // token from client-side Stripe.js
+});
+// Store: paymentMethod.id (token) — never the card number
+
+// WRONG — never do this
+const cardNumber = req.body.cardNumber; // Tier 2 PCI-DSS violation
+await db.save({ userId, cardNumber });   // DO NOT store raw card data
+```
+
+---
+
+### 6. Remove PII from Log Statements
+
+**Pattern to search for and fix:**
+```python
+# VULNERABLE
+logger.info(f"User {user.email} logged in")
+logger.debug(f"Payment by {user.full_name}, card ending {card_last4}")
+
+# SECURE — log opaque identifiers, not PII
+logger.info(f"User {user.id} authenticated", extra={"user_id": user.id})
+logger.debug(f"Payment processed", extra={"user_id": user.id, "payment_id": payment_id})
+```
+
+```typescript
+// VULNERABLE
+console.log(`Processing order for ${user.email} at ${user.address}`);
+
+// SECURE
+logger.info('Processing order', { userId: user.id, orderId: order.id });
+```
+
+**Structured logging fields that are SAFE to log:**
+- Internal user ID (UUID/opaque)
+- Session ID (if short-lived and not externally shared)
+- Transaction/correlation IDs
+- Error codes and error types
+- Timestamps
+- HTTP status codes
+- Duration/latency
+
+**Structured logging fields that are UNSAFE:**
+- Email addresses
+- IP addresses (must be masked — last octet)
+- Full names
+- Phone numbers
+- Any Tier 1–3 sensitive fields
+
+---
+
+## P2 — Fix This Sprint
+
+### 7. Implement Data Access Audit Logging
+
+Every read/write of Tier 1 and Tier 2 data must be logged to an immutable audit log.
+
+**What to log:**
+```
+{
+  timestamp: ISO8601,
+  actor_id: "user UUID",
+  actor_role: "admin|user|service",
+  action: "READ|WRITE|DELETE|EXPORT",
+  resource_type: "User|HealthRecord|PaymentMethod",
+  resource_id: "UUID of accessed record",
+  fields_accessed: ["email", "phone"],  // NOT the values
+  ip_address: "masked IP",
+  result: "success|denied",
+  correlation_id: "request trace ID"
+}
+```
+
+**Do NOT log the actual sensitive field values in the audit log.**
+
+**Separation:** Store audit logs in a **separate** database/storage account with stricter access controls than the application database.
+
+---
+
+### 8. Rate Limit Sensitive Endpoints
+
+Prevents automated bulk data harvesting even if an auth vulnerability exists.
+
+```typescript
+// Express + express-rate-limit
+import rateLimit from 'express-rate-limit';
+
+// Aggressive limit for data export endpoint
+const exportLimiter = rateLimit({
+  windowMs: 60 * 60 * 1000, // 1 hour
+  max: 5, // max 5 exports per hour per IP
+  message: 'Too many export requests'
+});
+
+// Standard limit for data lookup
+const lookupLimiter = rateLimit({
+  windowMs: 15 * 60 * 1000, // 15 minutes
+  max: 100
+});
+
+app.get('/api/export', exportLimiter, authMiddleware, exportController);
+app.get('/api/users/:id', lookupLimiter, authMiddleware, userController);
+```
+
+---
+
+## P3 — Fix This Quarter
+
+### 9. Implement Data Retention and Auto-Deletion
+
+**Every table with personal data must have a defined retention policy.**
+
+```sql
+-- Add retention column to all PII tables
+ALTER TABLE users ADD COLUMN retention_expires_at TIMESTAMP;
+ALTER TABLE health_records ADD COLUMN retention_expires_at TIMESTAMP;
+
+-- Set retention at insert time
+INSERT INTO users (email, retention_expires_at) 
+VALUES ($1, NOW() + INTERVAL '7 years');
+
+-- Scheduled job to hard-delete expired records (or anonymize)
+DELETE FROM users 
+WHERE retention_expires_at < NOW() 
+AND deletion_notified_at IS NOT NULL; -- ensure user was notified
+```
+
+**Python scheduled cleanup:**
+```python
+from apscheduler.schedulers.asyncio import AsyncIOScheduler
+
+async def purge_expired_records():
+    await db.execute(
+        "DELETE FROM user_sessions WHERE expires_at < NOW()"
+    )
+    # Anonymize users (don't delete if financial records must be retained)
+    await db.execute("""
+        UPDATE users SET 
+            email = CONCAT('deleted_', id, '@redacted.invalid'),
+            phone = NULL,
+            address = NULL,
+            date_of_birth = NULL
+        WHERE retention_expires_at < NOW() AND deleted_at IS NULL
+    """)
+
+scheduler = AsyncIOScheduler()
+scheduler.add_job(purge_expired_records, 'cron', hour=2)  # 2 AM daily
+scheduler.start()
+```
+
+---
+
+### 10. Pseudonymize Behavioral and Analytics Data
+
+Replace direct user identifiers in analytics with pseudonymous tokens.
+
+```python
+import hashlib
+import hmac
+
+PSEUDONYM_SALT = os.environ.get("PSEUDONYM_SALT")  # stored in Key Vault
+
+def pseudonymize_user_id(real_user_id: str) -> str:
+    """
+    One-way: analyst can track behavior across sessions 
+    but cannot identify the real user without the salt.
+    """
+    return hmac.new(
+        PSEUDONYM_SALT.encode(), 
+        real_user_id.encode(), 
+        hashlib.sha256
+    ).hexdigest()
+
+# In analytics event
+analytics.track({
+    "user_id": pseudonymize_user_id(user.id),  # NOT real user ID
+    "event": "page_viewed",
+    "page": request.path,
+    "timestamp": datetime.utcnow().isoformat()
+})
+```
+
+---
+
+## Quick Win Checklist (Complete in < 1 day)
+
+- [ ] Search all files for hardcoded secrets → move to env vars / Key Vault
+- [ ] Check all `SELECT *` queries → add explicit column list excluding sensitive fields
+- [ ] Verify storage buckets/containers → block public access
+- [ ] Remove `console.log` / `logger.debug` calls that print request bodies
+- [ ] Add `HttpOnly; Secure; SameSite=Strict` to all session cookies
+- [ ] Verify that `/api/admin/*` routes require admin role check
+- [ ] Confirm password reset tokens expire in < 15 minutes
+- [ ] Check that 500 error responses don't include stack traces in production
+- [ ] Verify `.env` and secret files are in `.gitignore`
+- [ ] Run `git log --all --full-history -- "*.env"` to check for historical secret commits
+
+---
+
+## Blast Radius Reduction by Control Applied
+
+When reporting the hardening roadmap, use these estimates:
+
+| Control Applied | Blast Radius Reduction | Justification |
+|----------------|----------------------|---------------|
+| Fix all IDOR vulnerabilities | 80–90% | Most breach scenarios exploit authorization flaws |
+| Field encryption for T1 data | 75–85% | Encrypted data is useless without KMS key |
+| Remove PII from logs | 40–60% | Log access is often less controlled than DB access |
+| Tokenize payment data | 95% for card data | Standard PCI-DSS compliance eliminates card data scope |
+| Rate limit data endpoints | 30–50% | Limits scale of automated harvesting attacks |
+| Data retention enforcement | 20–40% | Reduces "data lake" effect — less data to steal |
+| Audit logging + anomaly detection | 0% prevention, but -60% detection time | Breaches are caught faster |
+| Pseudonymization of analytics | 60–70% for analytics data | Analytics data decoupled from identity |
+| Architecture: separate analytics from PII | 50–70% | Breach of analytics store has no PII value |
diff --git a/skills/data-breach-blast-radius/references/regulatory-impact.md b/skills/data-breach-blast-radius/references/regulatory-impact.md
new file mode 100644
index 000000000..2238e291f
--- /dev/null
+++ b/skills/data-breach-blast-radius/references/regulatory-impact.md
@@ -0,0 +1,320 @@
+# Regulatory Impact Reference
+
+Fine formulas, breach notification timelines, cost benchmarks, and jurisdiction detection patterns for all major global data protection regulations.
+
+> **Disclaimer:** This reference is for risk planning and developer education only. All fine estimates are approximations based on publicly available legal texts and benchmarks cited in `SOURCES.md`. Consult qualified legal counsel for actual regulatory guidance in your jurisdiction.
+
+> **Verifying these numbers:** Every fine formula in this file is sourced from the regulation's primary legal text. See `references/SOURCES.md` for the exact statute/article URL for each figure. If any number looks wrong, check SOURCES.md first — if it's genuinely outdated, please open a PR.
+
+---
+
+## Jurisdiction Detection Patterns
+
+Scan the codebase for these signals to determine which regulations apply:
+
+### GDPR (EU/EEA — General Data Protection Regulation)
+**Trigger signals:**
+```
+# Geographic signals
+- Currency: EUR, GBP (for UK GDPR)
+- Phone formats: +44, +49, +33, +31, +34, +39, +46, +47, +358, +45, +48
+- Locale strings: 'de', 'fr', 'es', 'it', 'nl', 'pl', 'pt', 'sv', 'da', 'fi', 'nb', 'el'
+- Country codes: DE, FR, ES, IT, NL, PL, BE, SE, AT, CH, DK, FI, NO, PT, GR, IE, HU, CZ, RO
+- Cloud regions: eu-west-*, eu-central-*, northeurope, westeurope, francecentral, germanywestcentral
+- Domain TLDs: .de, .fr, .es, .it, .nl, .pl, .eu, .uk, .ie, .at, .se, .dk, .fi, .be, .no, .pt
+
+# Code signals
+- GDPR-related comments or variable names: gdpr, dpa, data_protection, lawful_basis
+- Consent management code: cookie_consent, gdpr_consent, marketing_opt_in
+- Right to erasure endpoints: /delete-account, /forget-me, /data-deletion
+- Data export endpoints: /export-data, /download-my-data, /dsar
+- EU-specific third-party integrations: TrustArc, OneTrust, Cookiebot, Axeptio
+
+# Config signals
+- AWS S3 buckets with eu- prefix
+- Azure storage accounts in European regions
+- GCP storage in europe-* regions
+```
+
+**Applies to:** Any organization processing personal data of EU/EEA residents, regardless of where the organization is based.
+
+---
+
+### CCPA / CPRA (California — Consumer Privacy Rights Act)
+**Trigger signals:**
+```
+# Geographic signals
+- Country: US with state: CA, California
+- Sales tax for California (CA sales tax logic)
+- Phone format: +1 with 213, 310, 323, 408, 415, 424, 510, 530, 562, 619, 626, 650, 707, 714, 805, 818, 831, 858, 909, 916, 925, 949, 951
+
+# Code signals
+- CCPA-related comments: ccpa, california_privacy, do_not_sell, opt_out_of_sale
+- Privacy preference center with California toggle
+- Opt-out links: /do-not-sell, /privacy-choices, /opt-out
+- GPC (Global Privacy Control) header handling
+
+# Business signals
+- Annual gross revenue > $25M (implied by scale signals in codebase)
+- Comments/configs referencing California consumer data
+```
+
+**Applies to:** For-profit businesses meeting any of: annual gross revenue > $25M, buys/sells/receives/shares personal data of 100K+ consumers/households annually, or derives 50%+ of revenue from selling personal data.
+
+---
+
+### HIPAA (US — Health Insurance Portability and Accountability Act)
+**Trigger signals:**
+```
+# Field name signals (PHI — Protected Health Information)
+- medical_record_number, mrn, patient_id, encounter_id
+- diagnosis, icd_code, icd10, medication, prescription
+- lab_result, test_result, radiology, pathology
+- health_plan_id, insurance_id, claim_number
+- fhir_, hl7_, dicom_
+
+# Integration signals
+- Epic, Cerner, Allscripts, eClinicalWorks API keys or webhooks
+- FHIR API endpoints (/fhir/, /r4/, /stu3/)
+- HL7 message parsing
+- CMS (Centers for Medicare & Medicaid) API integration
+- SNOMED, LOINC, ICD code lookups
+
+# Config signals
+- HIPAA compliance flags or BAA (Business Associate Agreement) references
+- HIPAA-compliant hosting: AWS HIPAA BAA, Azure Healthcare APIs, GCP HIPAA
+- Healthcare-specific cloud: Microsoft Cloud for Healthcare, Google Cloud Healthcare API
+```
+
+**Applies to:** Covered entities (healthcare providers, health plans, clearinghouses) and their Business Associates (vendors who process PHI on their behalf).
+
+---
+
+### LGPD (Brazil — Lei Geral de Proteção de Dados)
+**Trigger signals:**
+```
+# Geographic signals
+- Currency: BRL, R$
+- Phone format: +55
+- Locale: pt-BR, pt_BR
+- Country codes: BR, BRA, Brazil
+- CPF field (Brazilian individual taxpayer registry): cpf, cpf_number
+- CNPJ field (Brazilian company registry): cnpj
+- CEP (Brazilian postal code): cep, codigo_postal (8 digits, XXXXX-XXX format)
+
+# Code signals
+- lgpd references in comments or variable names
+- Brazilian payment integrations: PicPay, Nubank, Mercado Pago, PagSeguro, PIX
+- Brazilian cloud regions: sa-east-1 (AWS São Paulo), brazilsouth (Azure)
+```
+
+**Applies to:** Any processing of personal data of individuals in Brazil, or any processing carried out in Brazil.
+
+---
+
+### PDPA (Multiple Asian jurisdictions)
+
+#### Singapore PDPA
+**Trigger signals:** `+65`, `SGD`, `sg` locale, `.sg` TLD, `nric` field, `fin` (Foreign Identification Number), `singpass`
+
+#### Thailand PDPA
+**Trigger signals:** `+66`, `THB`, `th` locale, `.th` TLD, `thai_id`
+
+#### Malaysia PDPA
+**Trigger signals:** `+60`, `MYR`, `ms` locale, `.my` TLD, `my_kad`, `nric_malaysia`
+
+#### Philippines Data Privacy Act
+**Trigger signals:** `+63`, `PHP` (currency), `ph` locale, `.ph` TLD, `phil_sys_number`
+
+#### Japan APPI (Act on Protection of Personal Information)
+**Trigger signals:** `+81`, `JPY`, `ja` locale, `.jp` TLD, `my_number` (Japanese national ID), `maruhi` (confidential)
+
+---
+
+### Other Regulations (flag if applicable)
+
+| Regulation | Jurisdiction | Key Trigger |
+|-----------|-------------|-------------|
+| PIPEDA / Law 25 | Canada | `+1` + Canadian provinces, `CAD`, `.ca` TLD, SIN field |
+| Australia Privacy Act | Australia | `+61`, `AUD`, `.au` TLD, `tfn` field |
+| POPIA | South Africa | `+27`, South African Rand, `.za` TLD, `sa_id_number` |
+| KVKK | Turkey | `+90`, `TRY`, `.tr` TLD |
+| PDPB | India (upcoming) | `+91`, `INR`, `aadhaar` field — note: not yet in force |
+| SOC 2 Type II | US (security standard, not law) | Mentioned in codebase, customer contracts |
+| PCI-DSS | Global (payment card) | Any card number / CVV / PAN field |
+
+---
+
+## GDPR Fine Calculator
+
+**Legal source:** GDPR Article 83 — https://gdpr-info.eu/art-83-gdpr/  
+**Exact text, Art. 83.4:** "...up to 10 000 000 EUR, or...up to 2% of the total worldwide annual turnover...whichever is higher"  
+**Exact text, Art. 83.5:** "...up to 20 000 000 EUR, or...up to 4% of the total worldwide annual turnover...whichever is higher"
+
+### Maximum Fines (Article 83)
+```
+Tier 1 violations (less severe — Art. 83.4):
+  Maximum = max(€10,000,000, 2% of global annual turnover)
+  [Note: 'higher' means the LARGER of the two — corrected from min() to max()]
+
+Tier 2 violations (most severe — Art. 83.5 — core principles, data subject rights, cross-border transfers):
+  Maximum = max(€20,000,000, 4% of global annual turnover)
+```
+
+### Fine Estimation Formula for Risk Planning
+When annual revenue/turnover is unknown, use these conservative estimates:
+
+| Company Profile | Estimated Annual Turnover | Realistic T1 Fine | Realistic T2 Fine |
+|----------------|--------------------------|-------------------|-------------------|
+| Startup (< 10 employees) | < €2M | €25K–€100K | €50K–€250K |
+| Small business (10–50 employees) | €2M–€10M | €50K–€400K | €100K–€800K |
+| Mid-size (50–500 employees) | €10M–€100M | €200K–€2M | €500K–€4M |
+| Large enterprise (500–5K employees) | €100M–€1B | €2M–€20M | €5M–€40M |
+| Multinational | > €1B | €10M (capped at 2%) | €20M (capped at 4%) |
+
+**Historic GDPR fines for calibration (all publicly verified — links in SOURCES.md):**
+- Meta: €1.2B (2023) — cross-border data transfer violations
+- Amazon: €746M (2021) — cookie consent violations
+- WhatsApp: €225M (2021) — transparency violations
+- Google: €150M (France, 2022) — cookie withdrawal
+- H&M: €35.3M (2020) — employee monitoring
+- British Airways: €22M (2020) — security breach (500K records)
+- Marriott: €18.4M (2020) — security breach (339M records)
+
+**Breach notification fine enhancement:** Non-notification or late notification adds 20–30% to the base fine.
+
+---
+
+## CCPA / CPRA Fine Calculator
+
+**Legal source:** California Civil Code § 1798.155(a) (as amended June 30, 2025, Stats. 2025, Ch. 20) — https://leginfo.legislature.ca.gov/faces/codes_displaySection.xhtml?lawCode=CIV&sectionNum=1798.155  
+**Private right of action source:** California Civil Code § 1798.150 — https://leginfo.legislature.ca.gov/faces/codes_displaySection.xhtml?lawCode=CIV&sectionNum=1798.150
+
+```
+Non-intentional violations: $2,500 per violation    [§ 1798.155(a)]
+Intentional violations: $7,500 per violation         [§ 1798.155(a)]
+Children's data violations: $7,500 per violation    [§ 1798.155(a) — intent not required for minors]
+Private right of action: $100–$750 per consumer     [§ 1798.150]
+```
+
+### Calculation for mass breach
+
+```
+Max_CCPA_Fine = Records_affected × $7,500 (if intentional)
+             = Records_affected × $2,500 (if unintentional)
+```
+
+**Cap:** California AG can seek up to $2,500 per consumer per violation, but class action suits under private right of action can reach $100–$750 per consumer.
+
+**Private right of action (unique to CCPA/CPRA):**
+```
+Civil_damages = max($100, min($750, actual_damages)) × affected_California_consumers
+```
+
+**Examples:**
+- 100K Californian users × $750 = $75M maximum private right of action
+- 100K users × $2,500 = $250M maximum CCPA fine (regulatory)
+
+---
+
+## HIPAA Fine Calculator
+
+**Legal source:** 45 CFR § 160.404 — https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-160/subpart-D/section-160.404  
+**HHS enforcement page:** https://www.hhs.gov/hipaa/for-professionals/compliance-enforcement/examples/all-cases/index.html  
+**Note:** Amounts are 2024 inflation-adjusted figures per HHS. Updated annually — verify at HHS link above.
+
+HIPAA fines are tiered by knowledge/culpability (45 CFR § 160.404):
+
+| Tier | Culpability | Min per Violation | Max per Violation | Annual Cap |
+| A | Did not know | $137 | $68,928 | $2,067,813 |
+| B | Reasonable cause | $1,379 | $68,928 | $2,067,813 |
+| C | Willful neglect, corrected | $13,785 | $68,928 | $2,067,813 |
+| D | Willful neglect, not corrected | $68,928 | $1,919,173 | $1,919,173 |
+
+**For breach planning:** Each affected patient record where PHI was exposed = 1 violation.
+
+**Breach notification costs:** HHS requires notification to affected individuals + HHS. Breaches of 500+ individuals in a state require media notification. Breaches of 500+ total require HHS annual report.
+
+**Criminal penalties (DOJ — for egregious cases):**
+- Up to $50,000 + 1 year imprisonment (simple violation)
+- Up to $100,000 + 5 years (under false pretenses)
+- Up to $250,000 + 10 years (with intent to sell/use)
+
+---
+
+## LGPD Fine Calculator (Brazil)
+
+**Legal source:** Lei nº 13.709/2018 (LGPD) — Article 52, I — https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/l13709.htm  
+**ANPD (Brazilian DPA):** https://www.gov.br/anpd/pt-br
+
+```
+Maximum fine per violation = 2% of revenue in Brazil in the prior fiscal year  [Art. 52, I]
+Hard cap = R$50,000,000 (≈ $10M USD) per violation                            [Art. 52, I]
+```
+
+Daily fine possible during non-compliance period.  
+**Brazilian DPA (ANPD) enforcement began 2021.** Enforcement ramp-up is ongoing.
+
+---
+
+## Breach Notification Timeline Reference
+
+**All timelines are sourced from primary legal texts.** See `SOURCES.md` for exact article/section URLs for each regulation.
+
+How fast you must notify regulators and affected individuals after discovering a breach:
+
+| Regulation | Regulator Notification | Individual Notification | Legal Source | Notes |
+|-----------|----------------------|------------------------|-------------|-------|
+| GDPR | **72 hours** from discovery | "Without undue delay" if high risk | Art. 33 & 34 | Must notify even if details incomplete |
+| UK GDPR | **72 hours** from discovery | Without undue delay | UK GDPR Art. 33 | Retained EU law post-Brexit |
+| CCPA / CPRA | "Most expedient time" (no hard number) | Same | Cal. Civ. Code § 1798.82 | CA AG if > 500 CA residents |
+| HIPAA | **60 days** from discovery | 60 days (or sooner) | 45 CFR § 164.412 | HHS + media for 500+ in one state |
+| LGPD (Brazil) | **2 business days** (ANPD guidance) | As soon as possible | ANPD Resolution nº 2/2022 | ANPD enforcing since 2021 |
+| Singapore PDPA | **3 calendar days** for mandatory breach | Without undue delay | PDPA Section 26D (2021 amendment) | One of the strictest globally |
+| Australia Privacy Act | ASAP, no later than **30 days** | As soon as practicable | Privacy Act 1988 — NDB Scheme | notifiable-data-breaches scheme |
+| PIPEDA (Canada) | **As soon as feasible** | **As soon as feasible** | PIPEDA s.10.1 | OPCC notification required |
+| Japan APPI | **3–5 business days** | Promptly | APPI Art. 26 (2022 amendment) | Tightened from prior version |
+
+---
+
+## Total Breach Cost Estimation Model
+
+**Benchmark source:** IBM Security + Ponemon Institute — "Cost of a Data Breach Report" (annually updated)  
+**URL:** https://www.ibm.com/reports/data-breach  
+Figures below are from the **2024 edition** (last verified). IBM 2025 shows a 9% decrease — download the current PDF for updated values. **[IBM 2024, p.14]** page references refer to the 2024 edition.
+
+Use this model when generating the Financial Impact Estimate section:
+
+### Direct Costs
+```
+1. Detection & containment: $1.1M average      [IBM 2024, p.14]
+2. Post-breach response:     $1.2M average      [IBM 2024, p.14]
+3. Lost business:            $1.5M average      [IBM 2024, p.14]
+4. Notification costs:       records × $2–$8 per individual  [industry estimate]
+5. Credit monitoring:        records × $5–$20/year if PII    [industry estimate]
+6. Legal costs:              $200K–$3M depending on complexity [industry estimate]
+7. Forensic investigation:   $50K–$500K                      [industry estimate]
+8. PR/crisis communications: $100K–$500K                     [industry estimate]
+```
+
+### Regulatory Costs
+```
+9. Regulatory fines:         [see per-regulation formulas above — all sourced from law text]
+10. Settlement costs:        $1M–$100M+ for class actions    [historic case data]
+```
+
+### Reputational Multiplier
+Apply based on public visibility of the organization:
+```
+B2C consumer app, consumer brand:     ×1.5 (high reputational damage)
+B2B enterprise, low public profile:  ×1.1 (moderate reputational damage)
+Healthcare or financial institution:  ×2.0 (trust erosion is severe)
+Government or public sector:         ×1.8 (public accountability)
+```
+
+### Final Estimate Format
+```
+Minimum likely cost:   [conservative scenario, good response, small record count]
+Probable cost:         [most likely scenario, average response]
+Maximum exposure:      [worst case: maximum fines + class action + reputational]
+```
diff --git a/skills/data-breach-blast-radius/references/report-format.md b/skills/data-breach-blast-radius/references/report-format.md
new file mode 100644
index 000000000..63bf9a2ec
--- /dev/null
+++ b/skills/data-breach-blast-radius/references/report-format.md
@@ -0,0 +1,305 @@
+# Blast Radius Report Format
+
+Use this template to generate the complete Data Breach Blast Radius report. Fill every section — do not skip any.
+
+---
+
+## Full Report Template
+
+````markdown
+# 💥 Data Breach Blast Radius Report
+
+**Repository:** [repo name or path analyzed]  
+**Analysis date:** [ISO 8601 date]  
+**Scope:** [full repo / specific path]  
+**Languages / frameworks detected:** [list]  
+**Analyzed by:** GitHub Copilot — data-breach-blast-radius skill  
+
+---
+
+## Executive Summary
+
+[2–3 paragraphs in plain English. No technical jargon. Assume the reader is a CEO, CISO, or board member who will ask: "How bad would it be?"
+
+Paragraph 1: What data does this system hold and roughly how many people are affected?
+Paragraph 2: What is the single most dangerous exposure vector found? What would happen if it were exploited today?
+Paragraph 3: What is the estimated financial and regulatory impact? What is the most important thing to fix first?]
+
+---
+
+## Sensitive Data Inventory
+
+All personal, health, financial, and credential data found in the codebase:
+
+| # | Field Name | Source Location | Data Tier | Category | Encrypted? | Logged? | External Exposure? |
+|---|-----------|----------------|-----------|----------|-----------|---------|-------------------|
+| 1 | `email` | `models/user.py:14` | T3 — High | Contact | ❌ No | ⚠️ Yes | ✅ API response |
+| 2 | `ssn` | `models/employee.py:28` | T1 — Catastrophic | Gov. ID | ❌ No | ❌ No | ❌ No |
+| 3 | `card_number` | `models/payment.py:9` | T2 — Critical | PCI-DSS | ⚠️ Partial | ❌ No | ❌ No |
+| ... | ... | ... | ... | ... | ... | ... | ... |
+
+**Summary:**
+- Tier 1 (Catastrophic) fields: [N]
+- Tier 2 (Critical) fields: [N]
+- Tier 3 (High) fields: [N]
+- Tier 4 (Elevated) fields: [N]
+
+---
+
+## Data Flow Map
+
+How sensitive data moves through the system. Read left to right: ingestion → processing → storage → transmission.
+
+```mermaid
+flowchart LR
+    subgraph Ingestion["📥 Ingestion"]
+        A1[User Registration\nPOST /api/users\nT3: email, phone\nT2: date_of_birth]
+        A2[Payment\nPOST /api/payments\nT2: card_number, cvv]
+        A3[Health Record\nPOST /api/health\nT1: diagnosis, mrn]
+    end
+
+    subgraph Processing["⚙️ Processing"]
+        B1[Auth Service\nJWT issued\nT3: email in token]
+        B2[Payment Processor\nStripe tokenization\nT2: card → token]
+        B3[Analytics\nMixpanel events\nT3: email logged ⚠️]
+    end
+
+    subgraph Storage["🗄️ Storage"]
+        C1[(PostgreSQL\nusers table\nT1+T2+T3 data\nNo field encryption)]
+        C2[(Redis Cache\nSession data\nT3: email in cache)]
+        C3[(S3 Bucket\nUser exports\n⚠️ Public read ACL)]
+    end
+
+    subgraph Transmission["📤 Transmission"]
+        D1[REST API\n/api/users/:id\n⚠️ No ownership check\nT1+T2+T3 in response]
+        D2[Email notifications\nT3: email body contains\nfull name + order details]
+        D3[Webhooks\nT3: email in payload]
+    end
+
+    A1 --> B1 --> C1 --> D1
+    A2 --> B2 --> C1
+    A3 --> C1
+    B1 --> C2
+    C1 --> D2
+    C1 --> D3
+    C1 --> C3
+
+    style C3 fill:#ff6b6b,color:#fff
+    style D1 fill:#ff6b6b,color:#fff
+    style B3 fill:#ffa500,color:#fff
+```
+
+---
+
+## Top Exposure Vectors
+
+Ranked by Blast Radius Score (highest first):
+
+### 🔴 Vector 1: [Title] — BRS: [score]/100
+
+**Location:** `[file path]:[line number]`  
+**Type:** [IDOR / Unauthenticated endpoint / Public storage / Log leakage / Over-fetching API / etc.]  
+**Data exposed:** [T1/T2/T3 fields that would be exposed]  
+**Exploitation:** [1–2 sentences — how an attacker would use this]  
+**Records at risk:** [number or estimate]  
+**Jurisdictions triggered:** [GDPR / CCPA / HIPAA / etc.]
+
+```[language]
+// Vulnerable code snippet (exact location)
+[code]
+```
+
+**Blast Radius Score breakdown:**
+- Data tier: T[N] → weight [W]
+- Exposure likelihood: [E] ([label])
+- Population at risk: [N] records → scale [P]
+- Completeness: [factor] ([label])
+- Context multiplier: ×[M] ([reason])
+- **BRS: [calculated score]/100**
+
+---
+
+### 🔴 Vector 2: [Title] — BRS: [score]/100
+
+[repeat structure]
+
+---
+
+### 🟠 Vector 3: [Title] — BRS: [score]/100
+
+[repeat structure]
+
+---
+
+### 🟠 Vector 4: [Title] — BRS: [score]/100
+
+[repeat structure]
+
+---
+
+### 🟡 Vector 5: [Title] — BRS: [score]/100
+
+[repeat structure]
+
+---
+
+## Regulatory Blast Radius
+
+### Jurisdictions Triggered
+
+| Regulation | Triggered? | Trigger Evidence | Notification Deadline |
+|-----------|-----------|-----------------|----------------------|
+| GDPR | [Yes/No/Unknown] | [e.g., EUR currency, EU cloud region] | 72 hours |
+| CCPA | [Yes/No/Unknown] | [e.g., California users, US domain] | Expedient |
+| HIPAA | [Yes/No/Unknown] | [e.g., PHI fields found, FHIR endpoints] | 60 days |
+| LGPD | [Yes/No/Unknown] | [e.g., BRL currency, CPF field] | 2 business days |
+| Singapore PDPA | [Yes/No/Unknown] | [e.g., SGD, +65 phone patterns] | 3 calendar days |
+| PCI-DSS | [Yes/No/Unknown] | [e.g., card_number field found] | Immediate |
+
+---
+
+## Financial Impact Estimate
+
+> These are risk planning estimates only. Consult legal counsel for actual regulatory exposure.
+
+### Maximum Simultaneous Exposure
+- **Total records at risk (worst case):** [number]
+- **Tier 1 records (catastrophic data):** [number]
+- **Estimated affected individuals:** [number]
+- **Active regulatory jurisdictions:** [list]
+
+### Financial Impact Range
+
+| Scenario | Estimated Cost | Key Assumptions |
+|---------|---------------|----------------|
+| **Minimum** (fast response, few records, cooperative regulatory outcome) | $[X] | [assumptions] |
+| **Probable** (industry average response time, moderate regulatory action) | $[X] | [assumptions] |
+| **Maximum** (slow detection, maximum fines, class action) | $[X] | [assumptions] |
+
+### Breakdown (Probable Scenario)
+
+| Cost Category | Estimate |
+|--------------|---------|
+| Detection & containment | $[X] |
+| Post-breach response | $[X] |
+| Legal & forensics | $[X] |
+| Breach notification & monitoring | $[X] |
+| Regulatory fines ([jurisdictions]) | $[X] |
+| Reputational/business impact | $[X] |
+| **Total estimated cost** | **$[X]** |
+
+**Cost benchmarks used:** IBM Cost of a Data Breach Report 2024 ($4.88M global average, $165/record average) — verify current figures at ibm.com/reports/data-breach
+
+---
+
+## Hardening Roadmap
+
+Prioritized by `(Blast_Radius_Reduction × Severity) / Effort`:
+
+### 🔴 P0 — Fix Immediately (< 1 day each)
+
+| # | Action | File / Location | Blast Radius Reduction | Effort | Severity |
+|---|--------|----------------|----------------------|--------|---------|
+| 1 | [Fix IDOR on /api/users/:id — add ownership check] | `routes/users.ts:45` | 85% for this vector | ⚡ Low | CRITICAL |
+| 2 | [Remove SSN from API response DTO] | `dtos/employee.dto.ts:22` | 90% for SSN exposure | ⚡ Low | CRITICAL |
+| 3 | [Block public read ACL on S3 bucket] | `infra/storage.tf:14` | 100% for S3 exposure | ⚡ Low | HIGH |
+
+---
+
+### 🟠 P1 — Fix This Week
+
+| # | Action | File / Location | Blast Radius Reduction | Effort | Severity |
+|---|--------|----------------|----------------------|--------|---------|
+| 4 | [Encrypt SSN field with KMS] | `models/employee.py:28` | 80% for SSN field | 🔧 Medium | HIGH |
+| 5 | [Remove email from log statements (7 locations)] | `services/auth.py:66,89,121...` | 60% for log vector | 🔧 Medium | HIGH |
+| 6 | [Tokenize card data — migrate to Stripe Elements] | `services/payment.py` | 95% for card data | 🔧 Medium | CRITICAL |
+
+---
+
+### 🟡 P2 — Fix This Sprint
+
+| # | Action | Blast Radius Reduction | Effort | Severity |
+|---|--------|----------------------|--------|---------|
+| 7 | [Add rate limiting to /api/users/search] | 50% for bulk harvest | ⚡ Low | MEDIUM |
+| 8 | [Add data access audit log for T1/T2 reads] | -60% detection time | 🔧 Medium | HIGH |
+| 9 | [Add field projection to user query (remove unused fields from SELECT)] | 40% reduction in over-fetching | ⚡ Low | MEDIUM |
+
+---
+
+### ⚪ P3 — Fix This Quarter
+
+| # | Action | Blast Radius Reduction | Effort | Severity |
+|---|--------|----------------------|--------|---------|
+| 10 | [Implement data retention policy + auto-deletion job] | 30% reduction in stale data | 🏗️ High | MEDIUM |
+| 11 | [Pseudonymize analytics user IDs] | 70% for analytics data | 🔧 Medium | MEDIUM |
+| 12 | [Separate analytics store from production PII DB] | 60% architectural reduction | 🏗️ High | LOW |
+
+---
+
+## Analysis Assumptions
+
+Document all assumptions made during this analysis (transparency is critical):
+
+| Assumption | Value Used | Basis |
+|-----------|-----------|-------|
+| User population estimate | [X users] | [signal found or conservative default] |
+| Annual revenue estimate for fine calculation | [unknown / $X range] | [signals or not found] |
+| Geographic distribution | [assumed global / EU users likely] | [currency signals found] |
+| Healthcare context | [assumed / not applicable] | [PHI fields found / not found] |
+
+---
+
+## What Was Scanned
+
+- **Files analyzed:** [list key files or note "all files in repo"]
+- **Data model files:** [list schema/model files]
+- **API layer:** [list controller/route files]
+- **Config/infrastructure:** [list .env, terraform, CI/CD files]
+- **Log/monitoring:** [list logging config files]
+- **Test data:** [note if test fixtures contain real PII]
+
+---
+
+*This report was generated by the [data-breach-blast-radius](https://github.com/github/awesome-copilot/tree/main/skills/data-breach-blast-radius) skill for GitHub Copilot.*  
+*For risk planning purposes only. Consult qualified legal counsel and security professionals for actual regulatory guidance.*
+````
+
+---
+
+## Mermaid Diagram Conventions
+
+Use these conventions in the Data Flow Map:
+
+```
+# Node colors (using style declarations):
+🔴 fill:#ff6b6b,color:#fff  → Public/unauthenticated exposure (CRITICAL)
+🟠 fill:#ffa500,color:#fff  → Auth required but weak controls (HIGH)
+🟡 fill:#ffd700,color:#000  → Internal but over-broad access (MEDIUM)
+🟢 fill:#51cf66,color:#fff  → Properly secured (GOOD)
+
+# Node labels should include:
+- Action name
+- HTTP method + path (for API nodes)
+- Data tiers present (T1, T2, T3)
+- ⚠️ Warning emoji if an issue exists
+
+# Subgraphs:
+- Ingestion (📥)
+- Processing (⚙️)
+- Storage (🗄️)
+- Transmission (📤)
+```
+
+---
+
+## Severity Icons
+
+| Symbol | Severity | BRS Range |
+|--------|---------|-----------|
+| 🔴 | CRITICAL | 76–100 |
+| 🟠 | HIGH | 51–75 |
+| 🟡 | MEDIUM | 26–50 |
+| 🔵 | LOW | 0–25 |
+| ✅ | SECURE | Control in place |
+| ⚠️ | WARNING | Partial control |
+| ❌ | VULNERABLE | No control |