skills/regulatory-risk-assessment/SKILL.md

name, description

name	description
regulatory-risk-assessment	Produce a structured regulatory risk assessment / risk-register entry for regulated-industry features (banking, payments, PSD2/PSR, DORA, AML). Use when filing a CAD issue that needs a Risk:LOW/MEDIUM/HIGH level, or designing features touching payments, auth, data storage, or external APIs ("what are the risks?", "compliance gate", "risk register").

regulatory-risk-assessment

Produce a structured regulatory risk assessment for a feature, component, or integration — generating a risk register entry that satisfies the audit requirements of regulated-industry clients (banking, finance, insurance, PSD2/PSR, DORA, AML/KYC contexts).

Use when:

• Filing a Gitea issue dispatched via CAD (needs Risk: LOW/MEDIUM/HIGH)
• Designing a feature touching payments, auth, data storage, external APIs
• Preparing a client deliverable in a regulated industry
• "what are the risks?" / "compliance gate" / "risk register" in session

Do not use for: routine refactoring, docs-only changes, internal tooling with no external data or user impact.

What this skill produces

A docs/risk-register.md section with this schema:

R-[DOMAIN]-[NN] — [Short risk title]

Field	Value
Risk	What could go wrong (concrete, specific)
Regulatory reference	Which obligation/regulation, if any
Likelihood	H / M / L
Impact	H / M / L
Overall	H / M / L (highest of likelihood x impact)
Mitigation	What we are doing about it
Validation	Test name or Gitea issue number
Status	open / mitigated / accepted

Risk ID namespace: R-AUTH-NN authentication and authorization R-DATA-NN data storage, retention, privacy R-API-NN external API integration R-PAY-NN payment and financial transactions R-INFRA-NN infrastructure and availability R-AGENT-NN agentic / AI execution R-COMP-NN compliance and regulatory obligation

Mechanics

Step 1 — Scope the assessment

1. What external systems does this touch?
2. What user data does it read, write, or transmit?
3. What happens on silent failure? Loud failure?
4. What is the blast radius of a worst-case bug?
5. Is a regulation implicated?

Step 2 — Enumerate risks (common examples) Auth/OAuth: token theft, refresh failure, insufficient scope Email/Gmail: misclassification archives HUMAN thread, PII in logs Payment/PAIN.001: wrong amount, duplicate submission, missing field Agentic: irreversible action without approval, prompt injection, spirals Infra: single point of failure, secret in logs

Step 3 — Declare overall risk level Highest individual risk = feature overall level (LOW/MEDIUM/HIGH). This is the Risk: declaration in the CAD agent-ready issue contract.

Step 4 — Write validations Every mitigation needs a validation: - Specific test name (TestXxx) - Gitea issue number - Manual verification step with acceptance criteria Not acceptable: "will test later", "review manually"

Step 5 — Update docs/risk-register.md Append entries. Create if absent:

# Risk Register
All entries follow R-[DOMAIN]-[NN] schema.
See skills/regulatory-risk-assessment/SKILL.md for conventions.
Last updated: [date]

Integration with assessor-loop

For complex regulated-industry features (PSD2/PSR, DORA, AML), route to mathias/assessor-loop for deep obligation decomposition first. Use this skill standalone for internal tooling or general engineering risk.

Integration with CAD

Every CAD-dispatched issue must include: Risk: LOW | MEDIUM | HIGH

CAD pre-flight (agentsquad#29) rejects issues without it. If genuinely no risks: declare LOW and note why.

Example entry

R-DATA-01 — Email misclassification archives a HUMAN thread

Field	Value
Risk	LLM labels a real person's email as NOISE, causing auto-archive
Regulatory reference	None (internal)
Likelihood	M
Impact	H
Overall	H
Mitigation	Phase 1 read-only; HUMAN class never auto-archived in any phase
Validation	TestClassifier_HumanThreadNeverArchived; 1-week Phase 1 review
Status	open