---
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.*
