regulatory-landscape-mapping

What this skill does

# Regulatory Landscape Mapping

You map the regulatory landscape that applies to a product, service, or business. You inventory regulations, classify them, assess applicability and risk, surface overlaps and conflicts, and flag upcoming changes. Output is structured — not legal advice.

## Core rules

- **Not legal advice**: output is a structured mapping. Always include a disclaimer. Recommend consulting qualified legal counsel for compliance decisions.
- **Evidence or `[Assumed]`**: every applicability claim traces to the input context or is labeled `[Assumed]` with rationale
- **No fabricated regulations**: do not invent laws, standards, or deadlines that aren't widely known or supplied
- **Freshness flag**: regulations change — always include a "verify currency" note with a specific caveat
- **Jurisdiction-specific**: a regulation is meaningless without a jurisdiction

## Input handling

Follow shared foundation §7 — interview mode. Gather at minimum:

| Dimension | Required | Default |
|---|---|---|
| **Subject** (product/service/business) | Yes | — |
| **Industry** | Yes | — |
| **Jurisdictions** | Yes | — |
| **Data sensitivity** | No | Inferred |
| **User groups** (B2B / B2C / minors / vulnerable) | No | Inferred |
| **Revenue model & threshold** | No | Asked if may trigger threshold-based regimes |

**Exit interview when**: subject, industry, and jurisdictions are clear.

## Phase 1 — Setup

### 1. Collect input

Accept:
- A subject + industry + jurisdiction list
- A business case reference
- A product description with context (markets, users, data)
- No / vague input → interview mode (§7)

### 2. Detect scope

- **Subject**: product / service / business being mapped
- **Industry**: sector (healthcare, fintech, e-commerce, SaaS-general, adtech, public-sector, etc.)
- **Jurisdictions**: country / region (EU, UK, US, US-CA, AU, etc.)
- **Data sensitivity**: personal, special category, health, financial, children's, biometric
- **User groups**: B2B, B2C, minors, vulnerable populations, employees
- **Revenue / scale**: triggers thresholds (e.g., DMA gatekeeper, DSA very large online platform, HIPAA covered entity, PCI-DSS merchant level)

### 3. Confirm scope

Present:

```
**Subject**: [name]
**Industry**: [sector]
**Jurisdictions**: [list]
**Data sensitivity**: [categories]
**User groups**: [B2B / B2C / minors / ...]
**Scale / revenue thresholds**: [relevant or N/A]
```

Ask for confirmation. Ask render mode per `diagram-rendering` mixin and output path (default: `/documentation/[case]/regulatory-landscape/`).

## Phase 2 — Regulation inventory

Build a structured inventory. Categories:

| Domain | Examples (not exhaustive) |
|---|---|
| **Privacy / data protection** | GDPR (EU), UK GDPR, CCPA / CPRA, LGPD (BR), PIPEDA (CA), POPIA (ZA) |
| **Information security** | NIS2 (EU), CIRCIA (US), sectoral rules |
| **Sectoral — Healthcare** | HIPAA (US), MDR (EU), FDA rules, EU Health Data Space |
| **Sectoral — Financial** | PSD2 / PSD3 (EU), MiCA (EU), DORA (EU), SOX (US), GLBA (US), Basel rules |
| **Sectoral — Payments** | PCI-DSS (industry), PSR (UK) |
| **Content & platforms** | DSA (EU), DMA (EU), Online Safety Act (UK), Section 230 (US) |
| **AI-specific** | EU AI Act, NYC AEDT, US state AI laws |
| **Consumer** | Consumer Rights Act, warranty laws, distance-selling rules |
| **Accessibility** | EAA (EU), ADA (US), WCAG via reference |
| **Employment** | GDPR employee data, labor laws, remote work rules |
| **Environmental / ESG** | CSRD (EU), SEC climate rules (US), CBAM (EU) |
| **Tax** | VAT rules, e-invoicing mandates (by jurisdiction) |
| **Export control / sanctions** | EU sanctions, OFAC (US), dual-use rules |
| **Industry-specific voluntary** | ISO standards, industry codes of conduct |

Per regulation:

| Field | Description |
|---|---|
| **Name** | Common + official name |
| **Jurisdiction** | Where it applies |
| **Domain** | Category above |
| **Applicability to subject** | Yes / Likely / Possibly / No — with rationale |
| **Mandatory vs voluntary** | mandatory / industry voluntary / de facto standard |
| **Severity of non-compliance** | critical / high / medium / low (based on fines + operational risk) |
| **Status** | in force since [date] / upcoming from [date] / proposed |
| **Evidence** | Input reference OR `[Assumed]` with rationale |

## Phase 3 — Applicability assessment

For each inventoried regulation, produce a short assessment (1–3 sentences):
- **Why it applies** (or doesn't) for this subject
- **Key obligations** (3–5 concrete duties)
- **Typical controls** (3–5 controls teams usually implement)

Do not paraphrase the full text of regulations. Focus on what the team needs to act on.

## Phase 4 — Overlaps and conflicts

### Overlaps

Two regulations demanding similar things — consolidate control requirements:
- "GDPR Art. 32 (security of processing) ↔ ISO 27001 controls ↔ SOC 2 CC6" — one control program can satisfy all
- "HIPAA Privacy Rule ↔ GDPR" in a US-EU health product — overlap on patient consent, breach notification, access rights

### Conflicts

Two regimes demanding contradictory behavior:
- "US CLOUD Act access vs GDPR data-transfer restrictions"
- "US-state AI disclosure vs EU AI Act transparency timing"
- "Employee monitoring laws vs security-monitoring obligations"

Per conflict: regimes involved, specific tension, typical resolution approach (e.g., data residency, dual legal basis, in-jurisdiction processing).

## Phase 5 — Upcoming changes

Call out regulations with known upcoming effective dates within 24 months. Include:
- **Name** and what it changes
- **Effective date**
- **Preparation runway** (high / medium / low)
- **Who is most affected** (by size / sector / business model)

Freshness caveat: these dates may have shifted since training — verify with current authoritative sources.

## Phase 6 — Risk overview

Produce a risk overview by regulation:

| Regulation | Severity | Applicability | Status | Net risk |
|---|---|---|---|---|
| ... | critical / high / medium / low | Yes / Likely / Possibly / No | in force / upcoming | High / Medium / Low |

Net risk = severity × applicability × proximity (in-force now = higher immediate risk than a 2-year-out upcoming regime).

## Phase 7 — Roadmap recommendations

One paragraph:
- Which regulations are most critical to address first
- Where to invest in shared control programs (overlaps)
- What specialist input is needed (legal, sectoral)
- Pointer to `control-framework-mapping` for detailed control work and `data-flow-diagramming` for privacy-specific mapping

## Phase 8 — Diagrams

### 1. Regulation coverage by jurisdiction and domain

```mermaid
flowchart TB
    subgraph EU["EU"]
        EU_P["Privacy<br/>GDPR"]
        EU_S["Security<br/>NIS2"]
        EU_AI["AI<br/>EU AI Act"]
        EU_DA["Platforms<br/>DSA / DMA"]
    end
    subgraph US["US"]
        US_P["Privacy<br/>State laws (CCPA, ...)"]
        US_H["Sectoral<br/>HIPAA"]
    end
    subgraph Global["Global standards"]
        G_S["Security<br/>ISO 27001, SOC 2"]
        G_PCI["Payments<br/>PCI-DSS"]
    end
    SUBJECT["[Subject]"] --> EU_P
    SUBJECT --> EU_S
    SUBJECT --> US_P
    SUBJECT --> G_S
```

### 2. Net risk matrix

```mermaid
quadrantChart
    title Net regulatory risk — [Subject]
    x-axis Low Applicability --> High Applicability
    y-axis Low Severity --> High Severity
    quadrant-1 Monitor
    quadrant-2 HIGH RISK
    quadrant-3 Low priority
    quadrant-4 Latent risk
    [Regulation 1]: [x, y]
    [Regulation 2]: [x, y]
```

### 3. Overlap map (optional)

Mermaid flowchart showing shared control requirements across regimes.

## Phase 9 — Diagram rendering

Per `diagram-rendering` mixin. File names:
- `regulation-coverage.mmd` / `.png`
- `net-risk-matrix.mmd` / `.png`
- `regulation-overlaps.mmd` / `.png` (optional)

## Phase 10 — Report assembly and approval

```markdown
# Regulatory Landscape: [Subject]

**Date**: [date]
**Disclaimer**: Structured mapping only. Not