rtexit-method 0.1.0 → 0.1.1

package/packaged-assets/.agents/skills/rt-compliance-mapper/SKILL.md

@@ -0,0 +1,773 @@
+---
+name: rt-compliance-mapper
+description: "Map security findings to compliance frameworks: PCI-DSS v4.0, GDPR, ISO 27001:2022, HIPAA, SOC 2 Type II, NIST CSF 2.0, CIS Controls v8. Creates compliance impact table per finding showing which controls are violated and regulatory implications. Estimates financial penalty exposure for GDPR/PCI violations."
+---
+
+# rt-compliance-mapper
+
+## 1. Overview
+
+The compliance mapper skill bridges the gap between raw technical security findings and the regulatory and contractual obligations of the client organisation. A SQL injection finding means one thing to an engineer; it means EUR 20 million or 4 % of global turnover to a CISO presenting to a board under GDPR, and it means a failed PCI QSA assessment to a CFO running a card-present payment environment.
+
+This skill is invoked at the reporting phase of an engagement — after findings are confirmed and logged in `findings-master.csv` — to produce per-finding compliance tables and a consolidated regulatory exposure summary. Output feeds directly into the executive report generated by `rt-agent-scribe`.
+
+### When to Run This Skill
+
+- After all exploitation phases are complete and findings are stable in the tracker.
+- Before executive report generation so compliance tables are ready to embed.
+- When a client explicitly asks "which regulations does this finding affect?" during a debrief.
+- When estimating maximum financial penalty exposure to justify remediation investment.
+
+### Frameworks Covered
+
+| Framework | Version | Scope |
+|---|---|---|
+| PCI-DSS | v4.0 (March 2024) | Payment card data environments |
+| GDPR | 2016/679 | EU personal data processing |
+| ISO 27001 | 2022 revision | Information security management systems |
+| HIPAA | 2013 Omnibus Rule | US healthcare data (PHI) |
+| SOC 2 | Type II (Trust Services Criteria 2017) | SaaS/cloud service providers |
+| NIST CSF | 2.0 (February 2024) | Voluntary cybersecurity framework |
+| CIS Controls | v8 (2021) | Prioritised security controls |
+
+---
+
+## 2. Engagement Lifecycle Position
+
+```
+RECON → EXPLOITATION → POST-EXPLOITATION
+                                  ↓
+                         findings-master.csv
+                                  ↓
+                    [rt-compliance-mapper]  ← YOU ARE HERE
+                                  ↓
+                    compliance-impact.md
+                    penalty-exposure.md
+                                  ↓
+                    [rt-agent-scribe → executive report]
+```
+
+The skill reads from the finding tracker CSV, maps each finding to relevant control violations across all applicable frameworks, and writes two output documents that Layla (rt-agent-scribe) imports into the final deliverable.
+
+---
+
+## 3. Step-by-Step Workflow
+
+### Step 1 — Load Findings from Tracker
+
+Export current findings in JSON format for processing:
+
+```bash
+python3 {project-root}/_rtexit/scripts/finding_tracker.py export --format json > /tmp/findings_export.json
+```
+
+Verify export contains expected findings:
+
+```bash
+python3 {project-root}/_rtexit/scripts/finding_tracker.py stats
+```
+
+Expected output example:
+```
+=== Finding Statistics ===
+🔴 CRITICAL  :   2  ██
+🟠 HIGH      :   5  █████
+🟡 MEDIUM    :   4  ████
+🔵 LOW       :   3  ███
+⚪ INFO      :   1  █
+
+   TOTAL    : 15
+```
+
+Log the compliance mapping activity to the engagement timeline:
+
+```bash
+python3 {project-root}/_rtexit/scripts/autodoc_engine.py log \
+  --skill rt-compliance-mapper \
+  --phase reporting \
+  --note "Compliance mapping initiated — 15 findings queued" \
+  --operator "analyst-01"
+```
+
+### Step 2 — Identify Applicable Frameworks
+
+Before mapping, confirm with the client brief which frameworks apply. Ask:
+
+1. Does the client process payment cards? → PCI-DSS v4.0
+2. Does the client process EU personal data? → GDPR
+3. Is the client ISO 27001 certified or pursuing certification? → ISO 27001:2022
+4. Does the client handle US healthcare data (PHI/ePHI)? → HIPAA
+5. Is the client a SaaS/cloud provider with enterprise customers? → SOC 2
+6. Does the client follow NIST CSF as a baseline? → NIST CSF 2.0
+7. Has the client adopted CIS Controls as their security baseline? → CIS Controls v8
+
+For a typical fintech client: PCI-DSS, GDPR, ISO 27001, SOC 2, NIST CSF, CIS Controls.
+For a healthcare SaaS: HIPAA, GDPR (if EU patients), SOC 2, NIST CSF, ISO 27001.
+
+### Step 3 — Map Each Finding to Control Violations
+
+For each finding in the tracker, produce a compliance impact table using the mapping reference in Section 4. The table format is:
+
+```
+| Framework     | Control ID          | Control Name                          | Violation Type | Severity Impact |
+|---------------|---------------------|---------------------------------------|----------------|-----------------|
+| PCI-DSS v4.0  | Req 6.3.3           | All software is protected from known  | Direct         | Critical        |
+|               |                     | vulnerabilities                       |                |                 |
+| GDPR          | Art. 32(1)(b)       | Appropriate technical security        | Direct         | High            |
+|               |                     | measures for processing               |                |                 |
+| ISO 27001     | A.8.8               | Management of technical               | Direct         | High            |
+|               |                     | vulnerabilities                       |                |                 |
+```
+
+Violation types:
+- **Direct** — The finding is itself the violation (e.g., unencrypted card data = PCI Req 3.5 violation).
+- **Indicative** — The finding indicates a process failure that implies a control violation (e.g., missing patching = failure of vulnerability management programme).
+- **Potential** — The finding could lead to a control violation if exploited (e.g., SSRF that might reach internal data stores).
+
+### Step 4 — Estimate Financial Penalty Exposure
+
+Only applicable for GDPR and PCI-DSS. Calculate both frameworks where relevant.
+
+#### GDPR Penalty Estimation
+
+GDPR Article 83 defines two penalty tiers:
+
+- **Tier 1 (Art. 83(4)):** Up to EUR 10 million or 2% of global annual turnover (whichever is higher). Applies to: processor agreements, consent mechanisms, data breach notification (Art. 33/34), privacy by design (Art. 25), DPO obligations.
+- **Tier 2 (Art. 83(5)):** Up to EUR 20 million or 4% of global annual turnover (whichever is higher). Applies to: lawful basis violations (Art. 6), data subject rights violations (Art. 17/18/20), international transfer violations (Art. 44).
+
+Formula used:
+```
+Max_Penalty = MAX(EUR_cap, annual_turnover × percentage)
+Expected_Penalty = Max_Penalty × likelihood_factor × severity_factor
+
+likelihood_factor: 0.1 (low) / 0.3 (medium) / 0.6 (high) / 0.9 (near-certain)
+severity_factor:   0.1–1.0 based on number of data subjects affected and sensitivity
+```
+
+#### PCI-DSS Penalty Estimation
+
+Card network fines for QSA assessment failures:
+- **Level 1 Merchant (>6M transactions/year):** USD 5,000–100,000/month during non-compliance period.
+- **Level 2 Merchant (1M–6M transactions/year):** USD 5,000–25,000/month.
+- **Service Provider Level 1:** USD 10,000–100,000/month.
+
+Additionally: forensic investigation costs (USD 12,000–100,000), card replacement liability, and potential card scheme termination.
+
+### Step 5 — Write Output Documents
+
+Create two files per engagement:
+
+**File 1:** `{output-dir}/docs/reports/compliance-impact.md`
+Per-finding compliance mapping tables (Section 6 shows full example).
+
+**File 2:** `{output-dir}/docs/reports/penalty-exposure.md`
+Consolidated financial penalty estimate (Section 6 shows full example).
+
+Log evidence of both documents:
+
+```bash
+python3 {project-root}/_rtexit/scripts/autodoc_engine.py custody \
+  --finding "COMPLIANCE-SUMMARY" \
+  --evidence "{output-dir}/docs/reports/compliance-impact.md" \
+  --operator "analyst-01"
+
+python3 {project-root}/_rtexit/scripts/autodoc_engine.py custody \
+  --finding "COMPLIANCE-SUMMARY" \
+  --evidence "{output-dir}/docs/reports/penalty-exposure.md" \
+  --operator "analyst-01"
+```
+
+Log completion:
+
+```bash
+python3 {project-root}/_rtexit/scripts/autodoc_engine.py log \
+  --skill rt-compliance-mapper \
+  --phase reporting \
+  --note "Compliance mapping complete — compliance-impact.md and penalty-exposure.md written" \
+  --operator "analyst-01"
+```
+
+---
+
+## 4. Framework Control Mapping Reference
+
+### 4.1 Finding Type → Control Violation Cross-Reference
+
+Use this table to rapidly map a finding to the correct controls. Find the finding category in the left column, then read across for each framework.
+
+#### SQL Injection / Command Injection
+
+| Framework | Control(s) Violated |
+|---|---|
+| PCI-DSS v4.0 | Req 6.2.4 (secure development), Req 6.3.3 (protect against known vulnerabilities), Req 11.3.1 (internal vulnerability scans) |
+| GDPR | Art. 25 (data protection by design), Art. 32(1)(b) (appropriate technical measures) |
+| ISO 27001:2022 | A.8.25 (secure development life cycle), A.8.28 (secure coding), A.8.8 (technical vulnerability management) |
+| HIPAA | 164.312(a)(2)(iv) (encryption/decryption), 164.312(e)(2)(ii) (encryption in transit), 164.306(a)(1) (confidentiality safeguards) |
+| SOC 2 | CC7.1 (system components protected from vulnerabilities), CC8.1 (change management controls) |
+| NIST CSF 2.0 | PR.DS-2 (data-in-transit protected), DE.CM-8 (vulnerability scans), ID.RA-1 (asset vulnerabilities identified) |
+| CIS Controls v8 | CIS 16 (application software security), CIS 7.5 (perform automated vulnerability scans) |
+
+#### Broken Authentication / Weak Credentials
+
+| Framework | Control(s) Violated |
+|---|---|
+| PCI-DSS v4.0 | Req 8.2.1 (unique IDs), Req 8.3.6 (password complexity), Req 8.4.2 (MFA for non-console admin), Req 8.6.1 (system/application accounts) |
+| GDPR | Art. 32(1)(b) (appropriate technical measures — authentication) |
+| ISO 27001:2022 | A.5.17 (authentication information), A.8.5 (secure authentication) |
+| HIPAA | 164.312(d) (person/entity authentication), 164.312(a)(2)(i) (unique user identification) |
+| SOC 2 | CC6.1 (logical access security), CC6.2 (prior to access being granted, register and authorise users) |
+| NIST CSF 2.0 | PR.AA-1 (identities and credentials managed), PR.AA-3 (users authenticated) |
+| CIS Controls v8 | CIS 5 (account management), CIS 6 (access control management) |
+
+#### Sensitive Data Exposure / Unencrypted Data
+
+| Framework | Control(s) Violated |
+|---|---|
+| PCI-DSS v4.0 | Req 3.4.1 (PAN rendered unreadable), Req 3.5.1 (encryption keys protected), Req 4.2.1 (strong cryptography in transit) |
+| GDPR | Art. 5(1)(f) (integrity and confidentiality), Art. 32(1)(a) (pseudonymisation and encryption) |
+| ISO 27001:2022 | A.8.24 (use of cryptography), A.8.20 (networks security) |
+| HIPAA | 164.312(a)(2)(iv) (encryption/decryption — addressable), 164.312(e)(2)(ii) (encryption in transit — addressable) |
+| SOC 2 | CC6.7 (data transmission restrictions), CC6.8 (physical media protected) |
+| NIST CSF 2.0 | PR.DS-1 (data at rest protected), PR.DS-2 (data in transit protected) |
+| CIS Controls v8 | CIS 3.10 (encrypt sensitive data in transit), CIS 3.11 (encrypt sensitive data at rest) |
+
+#### IDOR / Broken Access Control
+
+| Framework | Control(s) Violated |
+|---|---|
+| PCI-DSS v4.0 | Req 7.2.1 (access control system established), Req 7.3.1 (access granted on least privilege), Req 8.2.5 (inactive accounts removed) |
+| GDPR | Art. 5(1)(f) (integrity and confidentiality), Art. 25 (data protection by design — access minimisation), Art. 32(1)(b) |
+| ISO 27001:2022 | A.5.15 (access control), A.5.18 (access rights), A.8.3 (information access restriction) |
+| HIPAA | 164.312(a)(1) (access control standard), 164.312(a)(2)(i) (unique user identification), 164.308(a)(4) (information access management) |
+| SOC 2 | CC6.1 (logical access security software), CC6.3 (role-based access) |
+| NIST CSF 2.0 | PR.AA-5 (access permissions managed), PR.AA-6 (physical access managed) |
+| CIS Controls v8 | CIS 6.1 (establish an access granting process), CIS 6.3 (require MFA for externally-exposed applications) |
+
+#### Missing Patches / Outdated Software
+
+| Framework | Control(s) Violated |
+|---|---|
+| PCI-DSS v4.0 | Req 6.3.3 (all software protected from known vulnerabilities), Req 12.3.2 (targeted risk analysis for each requirement) |
+| GDPR | Art. 32(1)(b) (appropriate technical measures), Art. 32(1)(d) (regular testing and evaluation) |
+| ISO 27001:2022 | A.8.8 (management of technical vulnerabilities) |
+| HIPAA | 164.308(a)(1)(ii)(B) (risk management — implement security measures) |
+| SOC 2 | CC7.1 (monitor system components for vulnerabilities) |
+| NIST CSF 2.0 | ID.RA-1 (asset vulnerabilities identified and documented), RS.MI-3 (newly identified vulnerabilities mitigated) |
+| CIS Controls v8 | CIS 7 (continuous vulnerability management) |
+
+#### Exposed Credentials / API Keys in Source Code
+
+| Framework | Control(s) Violated |
+|---|---|
+| PCI-DSS v4.0 | Req 3.7.1 (key management procedures), Req 6.2.4 (prevent common vulnerabilities in bespoke software), Req 8.6.2 (passwords for application/system accounts not hard-coded) |
+| GDPR | Art. 32(1)(b) (appropriate technical measures), Art. 25 (data protection by design) |
+| ISO 27001:2022 | A.8.28 (secure coding — secrets management), A.5.17 (authentication information — no hard-coded credentials) |
+| HIPAA | 164.312(a)(2)(i) (unique user identification), 164.308(a)(1)(ii)(D) (information system activity review) |
+| SOC 2 | CC6.1 (access security software/infrastructure), CC6.6 (logical access from outside the system boundary) |
+| NIST CSF 2.0 | PR.AA-1 (identities and credentials managed), PR.PS-1 (configuration management) |
+| CIS Controls v8 | CIS 4.10 (use unique passwords), CIS 5.4 (restrict administrator privileges to dedicated accounts) |
+
+#### Missing Security Headers / TLS Misconfiguration
+
+| Framework | Control(s) Violated |
+|---|---|
+| PCI-DSS v4.0 | Req 4.2.1 (strong cryptography in transit), Req 6.3.3 (protect against known vulnerabilities) |
+| GDPR | Art. 32(1)(a) (pseudonymisation and encryption), Art. 32(1)(b) (appropriate technical measures) |
+| ISO 27001:2022 | A.8.20 (networks security), A.8.24 (use of cryptography) |
+| HIPAA | 164.312(e)(1) (transmission security standard), 164.312(e)(2)(ii) (encryption in transit) |
+| SOC 2 | CC6.7 (data transmitted using encryption or other controls) |
+| NIST CSF 2.0 | PR.DS-2 (data in transit protected) |
+| CIS Controls v8 | CIS 3.10 (encrypt sensitive data in transit) |
+
+---
+
+## 5. Templates
+
+### Template A — Per-Finding Compliance Impact Table
+
+Copy this template for each finding in the tracker. Replace values accordingly.
+
+```markdown
+### Compliance Impact: F-003 — SQL Injection in /api/v1/login
+
+**Finding Summary:** Unauthenticated SQL injection vulnerability in the login endpoint
+allows an attacker to bypass authentication, extract the full user database, and
+potentially execute operating system commands via xp_cmdshell (MSSQL).
+
+**CVSS Score:** 9.8 (Critical) | **CWE:** CWE-89 | **Asset:** api.acmepay.com/api/v1/login
+
+#### Compliance Impact Table
+
+| Framework | Control ID | Control Name | Violation Type | Regulatory Severity |
+|---|---|---|---|---|
+| PCI-DSS v4.0 | Req 6.2.4 | Prevent common vulnerabilities in bespoke software | Direct | Critical |
+| PCI-DSS v4.0 | Req 6.3.3 | All software protected from known vulnerabilities | Direct | Critical |
+| PCI-DSS v4.0 | Req 3.4.1 | PAN rendered unreadable anywhere it is stored | Direct | Critical |
+| PCI-DSS v4.0 | Req 11.3.1 | Internal vulnerability scans performed periodically | Indicative | High |
+| GDPR | Art. 25 | Data protection by design and by default | Direct | High |
+| GDPR | Art. 32(1)(b) | Appropriate technical measures for processing security | Direct | High |
+| GDPR | Art. 33 | Notification of personal data breach to supervisory authority | Potential | Critical |
+| ISO 27001:2022 | A.8.25 | Secure development life cycle | Direct | High |
+| ISO 27001:2022 | A.8.28 | Secure coding | Direct | High |
+| ISO 27001:2022 | A.8.8 | Management of technical vulnerabilities | Indicative | High |
+| SOC 2 | CC7.1 | System components protected from vulnerabilities | Direct | High |
+| SOC 2 | CC8.1 | Change management controls to prevent unauthorised changes | Indicative | Medium |
+| NIST CSF 2.0 | PR.DS-2 | Data in transit protected | Potential | High |
+| NIST CSF 2.0 | DE.CM-8 | Vulnerability scans performed | Indicative | Medium |
+| CIS Controls v8 | CIS 16 | Application software security | Direct | High |
+| CIS Controls v8 | CIS 7.5 | Perform automated vulnerability scans | Indicative | Medium |
+
+#### Regulatory Implications
+
+**PCI-DSS:** This finding alone is sufficient to fail a PCI DSS assessment. Requirement 6.2.4
+mandates that all bespoke software be protected against injection attacks. A QSA discovering
+this vulnerability during an assessment would classify the environment as non-compliant,
+triggering card network fines until remediation is validated.
+
+**GDPR:** SQL injection affecting a user database containing EU personal data constitutes a
+likely personal data breach under Article 4(12) GDPR. If exploited, the controller must notify
+the supervisory authority within 72 hours (Art. 33) and, if high risk to individuals, notify
+affected data subjects (Art. 34). Failure to implement input validation violates Art. 32 and
+Art. 25.
+
+**ISO 27001:2022:** Annex A.8.25 and A.8.28 require that secure development practices include
+input validation and protection against injection vulnerabilities. This finding indicates the
+control is not implemented or not effective.
+
+#### Remediation Priority for Compliance
+
+- **PCI-DSS remediation deadline:** Immediate — 24–72 hours (card network SLA for Critical findings)
+- **GDPR breach assessment deadline:** Immediate — determine if exploitation has occurred; if yes, 72-hour notification clock starts
+- **ISO 27001 corrective action:** 30 days (documented in ISMS corrective action register)
+```
+
+### Template B — Consolidated Penalty Exposure Report
+
+```markdown
+# Regulatory Penalty Exposure Summary
+**Engagement:** RT-2026-031 | **Client:** AcmePay Ltd | **Date:** 2026-05-31
+**Analyst:** analyst-01 | **Frameworks:** PCI-DSS v4.0, GDPR, ISO 27001:2022, SOC 2
+
+## Executive Summary
+
+Based on 15 confirmed findings across the engagement, the organisation faces material
+regulatory exposure under PCI-DSS v4.0 and GDPR. The total maximum estimated financial
+exposure is **EUR 24.3 million** in regulatory fines plus **USD 1.2–3.6 million** in
+PCI-DSS non-compliance penalties. This does not include litigation, breach notification
+costs, or reputational damage.
+
+## GDPR Penalty Exposure
+
+**Applicable Tier:** Article 83(5) — Tier 2 (4% of global annual turnover)
+**Client Annual Turnover (est.):** EUR 85 million
+**4% of Turnover:** EUR 3.4 million
+**Statutory Maximum (higher of turnover % or EUR cap):** EUR 20 million
+
+| Finding | GDPR Articles Violated | Tier | Max Exposure |
+|---|---|---|---|
+| F-003: SQL Injection in Login API | Art. 25, 32(1)(b), 33 | Tier 2 | EUR 20M |
+| F-007: Unencrypted PII in S3 Buckets | Art. 5(1)(f), 32(1)(a) | Tier 2 | EUR 20M |
+| F-011: IDOR Exposing 43,000 User Records | Art. 25, 32(1)(b), 5(1)(f) | Tier 2 | EUR 20M |
+| F-012: Missing Breach Detection Logging | Art. 32(1)(d) | Tier 1 | EUR 10M |
+| F-015: Third-Party API Key Exposed in Git | Art. 32(1)(b), 28 | Tier 1 | EUR 10M |
+
+**Realistic Penalty Estimate (GDPR):**
+
+ICO and CNIL historical penalty data shows actual fines at 10–40% of maximum for
+first-time violations with good remediation cooperation. Estimated realistic penalty:
+
+```
+Base: EUR 20M (Tier 2 maximum, highest applicable)
+× Likelihood factor: 0.35 (prior good standing, cooperative remediation)
+× Severity factor: 0.55 (43,000 data subjects affected, sensitive financial data)
+= EUR 3.85 million estimated realistic GDPR fine
+```
+
+## PCI-DSS Penalty Exposure
+
+**Merchant Level:** Level 1 (>6M card transactions/year)
+**Issuing Card Scheme:** Visa / Mastercard
+
+| Period | Monthly Fine Range | Source |
+|---|---|---|
+| Month 1 (non-compliance confirmed) | USD 5,000–10,000 | Card scheme non-compliance tier 1 |
+| Month 2–3 (unresolved) | USD 25,000–50,000/month | Escalated tier |
+| Month 4+ (persistent) | USD 50,000–100,000/month | Maximum tier |
+
+**Findings triggering PCI non-compliance:**
+
+| Finding | PCI-DSS Requirement Violated | Non-Compliance Category |
+|---|---|---|
+| F-003: SQL Injection | Req 6.2.4, 6.3.3 | Bespoke software security |
+| F-005: Stored Card Numbers Unencrypted | Req 3.4.1 | Protect stored account data |
+| F-008: Weak TLS 1.0 on Payment API | Req 4.2.1 | Strong cryptography in transit |
+| F-009: Shared Admin Credentials | Req 8.2.1, 8.3.6 | Unique user IDs, password policy |
+| F-013: No Quarterly ASV Scans | Req 11.3.2 | External vulnerability scans |
+
+**Estimated PCI Penalties (12-month non-compliance scenario):**
+- Month 1–3: USD 5,000 + 50,000 + 50,000 = USD 105,000
+- Month 4–12: USD 100,000 × 9 = USD 900,000
+- Forensic investigation (if breach confirmed): USD 80,000–150,000
+- Card replacement liability (estimated): USD 200,000–1,500,000
+
+**Total PCI Exposure (12-month): USD 1.28–2.66 million**
+
+## Remediation Investment Justification
+
+| Remediation Investment | vs GDPR Exposure | vs PCI Exposure | ROI |
+|---|---|---|---|
+| USD 80,000 (immediate critical fixes) | Reduces EUR 3.85M risk by ~60% | Stops monthly fines immediately | 2,700% |
+| USD 200,000 (full remediation programme) | Eliminates GDPR exposure | Full PCI compliance restored | 950% |
+
+## ISO 27001:2022 / SOC 2 Implications
+
+ISO 27001 and SOC 2 do not carry direct financial penalties but have material commercial impact:
+
+- **ISO 27001:** 8 control violations found across A.8.x domain. Continued certification
+  requires a corrective action plan submitted to certifying body within 30 days of
+  internal audit findings. Certification suspension risk if findings remain unresolved at
+  next surveillance audit.
+- **SOC 2 Type II:** 5 Trust Services Criteria gaps identified (CC6.1, CC6.3, CC7.1, CC7.2, CC8.1).
+  Current SOC 2 report would likely receive a qualified opinion or adverse opinion if these
+  findings were in scope during the reporting period. Enterprise customers may invoke
+  vendor risk review clauses.
+```
+
+---
+
+## 6. Integration with finding_tracker.py and autodoc_engine.py
+
+### Reading Findings from the Tracker
+
+The compliance mapper reads the `findings-master.csv` directly. Each row contains:
+
+```
+id, title, severity, cvss, status, asset, cwe, cve, mitre, phase, date, operator, notes
+```
+
+Example row (as it appears in the CSV):
+```
+F-003,SQL Injection in Login API,CRITICAL,9.8,CONFIRMED,api.acmepay.com/api/v1/login,CWE-89,,T1190,exploitation,2026-05-28,analyst-01,unauthenticated; full db dump confirmed
+```
+
+To process all Critical and High findings for compliance mapping:
+
+```bash
+# Export filtered findings for mapping
+python3 {project-root}/_rtexit/scripts/finding_tracker.py export --format json \
+  | python3 -c "
+import json, sys
+findings = json.load(sys.stdin)
+priority = [f for f in findings if f['severity'] in ('CRITICAL','HIGH')]
+print(json.dumps(priority, indent=2))
+" > /tmp/priority_findings.json
+
+echo "Priority findings for compliance mapping:"
+cat /tmp/priority_findings.json | python3 -c "
+import json, sys
+findings = json.load(sys.stdin)
+for f in findings:
+    print(f\"  {f['id']} [{f['severity']}] CVSS {f['cvss']}: {f['title']}\")
+"
+```
+
+### Writing the Compliance Output to the autodoc Directory
+
+The compliance output documents live in the standard autodoc output structure:
+
+```
+{RTEXIT_OUTPUT}/
+└── docs/
+    └── reports/
+        ├── compliance-impact.md      ← per-finding compliance tables
+        └── penalty-exposure.md       ← financial penalty summary
+```
+
+Reference these paths in the autodoc log so Layla can locate them:
+
+```bash
+# After writing compliance-impact.md, register it
+python3 {project-root}/_rtexit/scripts/autodoc_engine.py log \
+  --skill rt-compliance-mapper \
+  --phase reporting \
+  --cmd "write compliance-impact.md" \
+  --output "compliance-impact.md written — 15 findings mapped across 7 frameworks" \
+  --finding "COMPLIANCE-SUMMARY" \
+  --operator "analyst-01"
+
+# Log penalty exposure document
+python3 {project-root}/_rtexit/scripts/autodoc_engine.py log \
+  --skill rt-compliance-mapper \
+  --phase reporting \
+  --cmd "write penalty-exposure.md" \
+  --output "GDPR exposure: EUR 3.85M estimated. PCI exposure: USD 1.28-2.66M over 12 months." \
+  --finding "COMPLIANCE-SUMMARY" \
+  --operator "analyst-01"
+
+# Register both as evidence with hash
+python3 {project-root}/_rtexit/scripts/autodoc_engine.py custody \
+  --finding "COMPLIANCE-SUMMARY" \
+  --evidence "_rtexit-output/docs/reports/compliance-impact.md" \
+  --operator "analyst-01"
+
+python3 {project-root}/_rtexit/scripts/autodoc_engine.py custody \
+  --finding "COMPLIANCE-SUMMARY" \
+  --evidence "_rtexit-output/docs/reports/penalty-exposure.md" \
+  --operator "analyst-01"
+```
+
+### Annotating Individual Findings with Compliance Data
+
+After mapping, add compliance notes back to individual finding tracker entries. The tracker does not have a dedicated compliance field, but the `notes` field can carry a compliance reference tag:
+
+```bash
+# The finding_tracker.py 'add' command creates the finding; notes can be updated
+# by editing the finding MD file directly:
+
+FINDING_MD="_rtexit-output/docs/findings/F-003.md"
+
+# Append compliance mapping reference to the finding file
+cat >> "$FINDING_MD" << 'EOF'
+
+## Compliance Impact
+
+**Frameworks Affected:** PCI-DSS v4.0, GDPR, ISO 27001:2022, SOC 2, NIST CSF 2.0, CIS Controls v8
+
+**Key Violations:**
+- PCI-DSS Req 6.2.4, 6.3.3 — Direct violation, triggers non-compliance
+- GDPR Art. 32(1)(b), Art. 25 — Direct violation, potential Art. 33 breach notification
+- ISO 27001:2022 A.8.28 — Direct violation
+
+**Penalty Exposure:** EUR 20M max GDPR (Tier 2); USD 100K/month PCI non-compliance
+
+See: `_rtexit-output/docs/reports/compliance-impact.md#F-003`
+See: `_rtexit-output/docs/reports/penalty-exposure.md`
+EOF
+```
+
+---
+
+## 7. Example Output — Finished Compliance Impact Report
+
+This is what `compliance-impact.md` looks like when complete for a real engagement.
+
+```markdown
+# Compliance Impact Report
+**Engagement:** RT-2026-031 — AcmePay Ltd External Penetration Test
+**Date:** 2026-05-31 | **Classification:** CONFIDENTIAL — CLIENT EYES ONLY
+**Prepared by:** RTExit Red Team Operations
+
+---
+
+## Applicable Frameworks
+
+| Framework | Version | Applicable | Rationale |
+|---|---|---|---|
+| PCI-DSS | v4.0 | YES | Client processes Visa/MC card payments (>6M tx/year) |
+| GDPR | 2016/679 | YES | Client processes EU resident personal data |
+| ISO 27001 | 2022 | YES | Client holds ISO 27001:2022 certification (cert. expires 2027-03) |
+| HIPAA | Omnibus 2013 | NO | Client does not process US healthcare data |
+| SOC 2 | Type II | YES | Client is SaaS provider; enterprise customers require SOC 2 report |
+| NIST CSF | 2.0 | YES | Client stated NIST CSF as security baseline in engagement briefing |
+| CIS Controls | v8 | YES | Client uses CIS Controls v8 as implementation roadmap |
+
+---
+
+## F-001 — Unauthenticated Remote Code Execution via File Upload
+
+**Severity:** CRITICAL | **CVSS:** 10.0 | **Asset:** portal.acmepay.com/upload
+
+| Framework | Control ID | Control Name | Violation Type | Regulatory Severity |
+|---|---|---|---|---|
+| PCI-DSS v4.0 | Req 6.2.4 | Prevent common vulnerabilities in bespoke software | Direct | Critical |
+| PCI-DSS v4.0 | Req 6.3.3 | All software protected from known vulnerabilities | Direct | Critical |
+| PCI-DSS v4.0 | Req 11.4.1 | Penetration testing performed at least once every 12 months | Indicative | High |
+| GDPR | Art. 25 | Data protection by design and by default | Direct | Critical |
+| GDPR | Art. 32(1)(b) | Appropriate technical measures | Direct | Critical |
+| GDPR | Art. 33 | Breach notification within 72 hours | Potential | Critical |
+| ISO 27001:2022 | A.8.25 | Secure development life cycle | Direct | Critical |
+| ISO 27001:2022 | A.8.28 | Secure coding | Direct | Critical |
+| ISO 27001:2022 | A.8.8 | Management of technical vulnerabilities | Direct | Critical |
+| SOC 2 | CC7.1 | System components protected from vulnerabilities | Direct | Critical |
+| SOC 2 | CC9.2 | Business disruption and use of recovery | Potential | High |
+| NIST CSF 2.0 | PR.DS-2 | Data in transit protected | Potential | High |
+| NIST CSF 2.0 | RS.MI-2 | Incidents mitigated | Potential | High |
+| CIS Controls v8 | CIS 16.11 | Use vetted libraries and frameworks | Direct | Critical |
+| CIS Controls v8 | CIS 7.6 | Remediate detected vulnerabilities | Indicative | High |
+
+**Regulatory Implications:** Full system compromise via unauthenticated RCE is a worst-case
+scenario for every applicable framework. PCI DSS would classify the CDE as fully compromised,
+requiring an emergency forensic investigation. GDPR breach notification obligations are
+triggered if any personal data was accessed. ISO 27001 certification may be suspended pending
+corrective action. SOC 2 report integrity is undermined.
+
+---
+
+## F-003 — SQL Injection in Authentication Endpoint
+
+**Severity:** CRITICAL | **CVSS:** 9.8 | **Asset:** api.acmepay.com/api/v1/login
+
+| Framework | Control ID | Control Name | Violation Type | Regulatory Severity |
+|---|---|---|---|---|
+| PCI-DSS v4.0 | Req 6.2.4 | Prevent common vulnerabilities in bespoke software | Direct | Critical |
+| PCI-DSS v4.0 | Req 6.3.3 | All software protected from known vulnerabilities | Direct | Critical |
+| PCI-DSS v4.0 | Req 3.4.1 | PAN rendered unreadable anywhere it is stored | Potential | Critical |
+| GDPR | Art. 25 | Data protection by design | Direct | High |
+| GDPR | Art. 32(1)(b) | Appropriate technical measures | Direct | High |
+| ISO 27001:2022 | A.8.28 | Secure coding | Direct | High |
+| ISO 27001:2022 | A.8.8 | Technical vulnerability management | Indicative | High |
+| SOC 2 | CC7.1 | System components protected from vulnerabilities | Direct | High |
+| NIST CSF 2.0 | ID.RA-1 | Asset vulnerabilities identified | Indicative | High |
+| CIS Controls v8 | CIS 16 | Application software security | Direct | High |
+
+**Regulatory Implications:** Authentication bypass via SQL injection exposes PAN data stored
+in the same database, triggering PCI DSS non-compliance across Requirements 3, 6, and 11.
+GDPR Art. 32 requires appropriate measures which must include input validation. Given the
+authentication context, any exploitation would constitute a notifiable breach.
+
+---
+
+## F-007 — AWS S3 Bucket Containing PII Publicly Accessible
+
+**Severity:** HIGH | **CVSS:** 8.2 | **Asset:** s3://acmepay-user-exports (eu-west-1)
+
+| Framework | Control ID | Control Name | Violation Type | Regulatory Severity |
+|---|---|---|---|---|
+| PCI-DSS v4.0 | Req 3.5.1 | Primary account numbers protected with strong cryptography | Direct | High |
+| PCI-DSS v4.0 | Req 12.3.4 | Hardware and software reviewed for security vulnerabilities | Indicative | Medium |
+| GDPR | Art. 5(1)(f) | Integrity and confidentiality principle | Direct | Critical |
+| GDPR | Art. 32(1)(a) | Pseudonymisation and encryption | Direct | Critical |
+| GDPR | Art. 33 | Breach notification to supervisory authority | Potential | Critical |
+| GDPR | Art. 34 | Communication to affected data subjects | Potential | High |
+| ISO 27001:2022 | A.5.10 | Acceptable use of information and other assets | Direct | High |
+| ISO 27001:2022 | A.8.20 | Networks security | Indicative | High |
+| SOC 2 | CC6.7 | Data transmitted using encryption or other controls | Direct | High |
+| NIST CSF 2.0 | PR.DS-1 | Data at rest protected | Direct | Critical |
+| CIS Controls v8 | CIS 3.3 | Configure data access control lists | Direct | High |
+| CIS Controls v8 | CIS 3.11 | Encrypt sensitive data at rest | Direct | High |
+
+**Regulatory Implications:** An S3 bucket containing first name, last name, email address,
+and partial card numbers of 43,000 users being publicly accessible is a confirmed personal
+data breach under GDPR Article 4(12). The 72-hour supervisory authority notification clock
+under Article 33 starts from when the controller becomes aware — which is the date of this
+report. Individuals whose data was exposed must be notified under Article 34 if the breach
+is likely to result in high risk to their rights and freedoms. The ICO will consider the
+duration of exposure, volume of data subjects, and sensitivity of data categories when
+determining any fine.
+
+---
+
+## Summary Table — All Findings
+
+| Finding | Severity | CVSS | PCI-DSS | GDPR | ISO 27001 | SOC 2 | NIST CSF | CIS |
+|---|---|---|---|---|---|---|---|---|
+| F-001 RCE via File Upload | CRITICAL | 10.0 | Req 6.2.4, 6.3.3 | Art. 25, 32, 33 | A.8.25, A.8.28 | CC7.1 | PR.DS-2 | CIS 16 |
+| F-002 SSRF Internal Access | CRITICAL | 9.6 | Req 6.2.4 | Art. 32 | A.8.28 | CC7.1 | PR.DS-5 | CIS 16 |
+| F-003 SQL Injection Login | CRITICAL | 9.8 | Req 6.2.4, 3.4.1 | Art. 25, 32, 33 | A.8.28, A.8.8 | CC7.1 | ID.RA-1 | CIS 16 |
+| F-004 JWT None Algorithm | HIGH | 8.8 | Req 8.2.1 | Art. 32 | A.5.17, A.8.5 | CC6.1 | PR.AA-3 | CIS 5 |
+| F-005 Stored Cards Plaintext | HIGH | 8.5 | Req 3.4.1, 3.5.1 | Art. 5(f), 32(a) | A.8.24 | CC6.7 | PR.DS-1 | CIS 3.11 |
+| F-006 Admin Default Password | HIGH | 8.8 | Req 8.3.6 | Art. 32 | A.5.17 | CC6.1 | PR.AA-1 | CIS 5 |
+| F-007 Public S3 PII Bucket | HIGH | 8.2 | Req 3.5.1 | Art. 5(f), 32(a), 33 | A.5.10, A.8.20 | CC6.7 | PR.DS-1 | CIS 3.3 |
+| F-008 TLS 1.0 Payment API | HIGH | 7.4 | Req 4.2.1 | Art. 32(a) | A.8.24 | CC6.7 | PR.DS-2 | CIS 3.10 |
+| F-009 Shared Admin Account | HIGH | 7.8 | Req 8.2.1 | Art. 32 | A.5.17 | CC6.2 | PR.AA-1 | CIS 5.4 |
+| F-010 IDOR User Profiles | MEDIUM | 6.5 | Req 7.2.1 | Art. 25, 32 | A.5.15, A.8.3 | CC6.1 | PR.AA-5 | CIS 6.1 |
+| F-011 IDOR Invoice Data | MEDIUM | 7.1 | Req 7.2.1, 7.3.1 | Art. 25, 32 | A.5.15 | CC6.3 | PR.AA-5 | CIS 6 |
+| F-012 No Audit Logging | MEDIUM | 5.3 | Req 10.2.1 | Art. 32(1)(d) | A.8.15 | CC7.2 | DE.CM-3 | CIS 8 |
+| F-013 No Quarterly ASV Scans | MEDIUM | 5.5 | Req 11.3.2 | Art. 32(1)(d) | A.8.8 | CC7.1 | ID.RA-1 | CIS 7 |
+| F-014 Weak Password Policy | LOW | 4.3 | Req 8.3.6 | Art. 32 | A.5.17 | CC6.1 | PR.AA-1 | CIS 5 |
+| F-015 API Key in Git History | HIGH | 7.5 | Req 8.6.2 | Art. 32, 28 | A.8.28, A.5.17 | CC6.6 | PR.AA-1 | CIS 4.10 |
+```
+
+---
+
+## 8. Quality Checklist
+
+Use this checklist before delivering the compliance mapping output. Every item must be checked.
+
+### Completeness
+
+- [ ] Every finding in `findings-master.csv` with status CONFIRMED or EXPLOITED has been mapped
+- [ ] Every applicable framework has been assessed for each finding (not just the obvious ones)
+- [ ] Violation type (Direct / Indicative / Potential) is assigned for every row in every table
+- [ ] Regulatory severity column is filled (Critical / High / Medium) for every row
+- [ ] The "Regulatory Implications" narrative paragraph is written for every Critical and High finding
+- [ ] The consolidated summary table covers all findings
+
+### Accuracy
+
+- [ ] PCI-DSS requirement numbers are from v4.0 (not v3.2.1 — note: v4.0 renumbered some requirements)
+- [ ] GDPR article numbers are from the full Regulation 2016/679, not GDPR recitals
+- [ ] ISO 27001:2022 control codes use the new A.5–A.8 numbering (not the old A.5–A.18 from 2013)
+- [ ] HIPAA citations reference the Security Rule (164.3xx) not the Privacy Rule (164.5xx) for technical findings
+- [ ] SOC 2 citations use Trust Services Criteria (CC prefixes), not old SAS 70 criteria
+- [ ] NIST CSF 2.0 citations use the new six-function structure (Govern/Identify/Protect/Detect/Respond/Recover)
+- [ ] CIS Controls citations reference v8 control numbers (CIS 1–18), not v7 (CIS 1–20)
+
+### Financial Calculations
+
+- [ ] GDPR penalty tier (Tier 1 vs Tier 2) is correctly identified for each violating article
+- [ ] Client annual turnover figure is sourced (from engagement brief, Companies House, or client-provided)
+- [ ] Both EUR cap and turnover percentage are calculated; the higher value is used
+- [ ] Likelihood factor is justified in a comment (not just stated as a number)
+- [ ] Severity factor accounts for: number of data subjects, data sensitivity, duration of exposure
+- [ ] PCI-DSS merchant level is confirmed (Level 1/2/3/4) — this affects fine amounts
+- [ ] PCI forensic investigation cost range is included in total exposure
+
+### Format and Presentation
+
+- [ ] Documents are saved to `{RTEXIT_OUTPUT}/docs/reports/compliance-impact.md` and `penalty-exposure.md`
+- [ ] Both documents are registered in the autodoc engine via `custody` command with SHA-256 hash
+- [ ] Timeline entry logged via `autodoc_engine.py log` for compliance mapping activity
+- [ ] Classification header is present on all output documents (CONFIDENTIAL — CLIENT EYES ONLY)
+- [ ] Engagement reference number appears on all output documents
+
+---
+
+## 9. Common Mistakes to Avoid
+
+### Using Outdated Control Numbers
+
+**Wrong:** Citing ISO 27001:2013 Annex A controls (e.g., "A.12.6.1 — Management of technical vulnerabilities").
+**Right:** ISO 27001:2022 renumbered controls significantly. Technical vulnerability management is now A.8.8. Always use 2022 revision control IDs.
+
+**Wrong:** Citing NIST CSF 1.1 subcategory codes (e.g., "PR.IP-12 — Vulnerability management plan").
+**Right:** NIST CSF 2.0 (February 2024) reorganised subcategories and added a new "Govern" function. Use 2.0 codes (e.g., ID.RA-1 for vulnerability identification).
+
+### Conflating Violation Types
+
+**Wrong:** Marking a "Missing patch on internal server" finding as a Direct GDPR Art. 33 violation (breach notification).
+**Right:** Art. 33 violation is Potential — it only becomes direct if the unpatched system was actually breached and personal data was accessed. Mark it as Potential until breach is confirmed.
+
+### Over-claiming GDPR Penalties
+
+**Wrong:** Stating "This finding results in a EUR 20 million fine."
+**Right:** EUR 20M is the statutory maximum. Realistic fines are calculated on a case-by-case basis by the supervisory authority. Always present the maximum alongside a calibrated realistic estimate and state clearly these are estimates.
+
+### Forgetting Framework Applicability
+
+**Wrong:** Mapping every finding to HIPAA for a UK fintech client.
+**Right:** Confirm applicability before mapping. HIPAA only applies to US-based covered entities and their business associates handling PHI. For a UK payments company with no US healthcare relationships, HIPAA is not applicable.
+
+### Missing the "Regulatory Implications" Narrative
+
+**Wrong:** A table with control violation ticks but no explanation of what it means.
+**Right:** Every Critical and High finding needs a prose paragraph explaining what the violation means in plain language — specifically: what the regulator would say, what notification obligations are triggered, and what the practical consequence is for the client's certification or compliance programme.
+
+### Ignoring the Timeline on Breach Notification
+
+**Wrong:** Writing "GDPR breach notification may be required" with no timeframe.
+**Right:** GDPR Art. 33 sets a hard 72-hour deadline from when the controller becomes "aware" of a breach. The date of the penetration test report delivery is the point at which the controller becomes aware. State this explicitly and name the specific date the 72-hour clock starts.
+
+### Calculating PCI Fines Without Merchant Level
+
+**Wrong:** Stating "PCI fines apply" without specifying the amount range.
+**Right:** PCI-DSS fine amounts differ by merchant level (Level 1 through 4) and service provider level. Confirm with the client their transaction volumes before quoting specific monthly fine ranges. A Level 1 merchant faces USD 50,000–100,000/month in the sustained non-compliance tier; a Level 3 merchant faces USD 5,000–10,000/month.
+
+### Mapping Only Critical/High Findings
+
+**Wrong:** Only producing compliance tables for CRITICAL findings.
+**Right:** Medium and Low findings often map to important indicative violations — particularly for process controls like vulnerability management (PCI Req 11.3.2, ISO 27001 A.8.8) and logging (PCI Req 10.2.1). A missing quarterly ASV scan is a Medium/Low technical finding but a direct PCI-DSS Requirement 11 violation. Missing audit logging is a Medium finding but violates GDPR Art. 32(1)(d) (regular testing and evaluation). Map all confirmed findings.
+
+---
+
+*Skill maintained by RTExit Red Team Operations. Output documents feed into rt-agent-scribe for executive and technical report generation.*