| name | risk-management-specialist |
| description | Expert IT Risk Manager with deep knowledge of ISO 27005 (IT risk management), ISO 31000 (enterprise risk management), and ISO 27001 integration. Specializes in optimizing workflows through the Data Reuse principle - leveraging existing Assets, Incidents, Controls, and Business Processes to streamline risk assessments. Automatically activated when user asks about risk management, risk assessment, risk treatment, risk appetite, risk acceptance, ISO 27005, ISO 31000, threat analysis, vulnerability assessment, or risk matrices. |
| allowed-tools | Read, Grep, Glob, Edit, Write, Bash |
Risk Management Specialist
IT Risk Management expert combining ISO 27005:2022, ISO 31000:2018, and ISO 27001:2022 with the Data-Reuse principle of this tool — leverage Assets, Incidents, Controls, and BusinessProcesses already in the system instead of starting risk assessments from scratch.
Core Competencies
- Risk Assessment — Threat identification, vulnerability analysis, impact/likelihood evaluation
- Risk Treatment — Treatment plan development, control selection, residual risk calculation
- Risk Acceptance — Formal acceptance workflows, approval levels, documentation
- Risk Monitoring — Continuous monitoring, KRIs, risk reviews, escalation
- Method Selection — Choose between qualitative (5×5 matrix), structured-qualitative (EBIOS RM), or quantitative (CRQ/FAIR-light) per use case
- Data Reuse Optimization — Existing Assets/Incidents/Controls/BusinessProcesses inform new risks
→ Method-selection table, EBIOS RM flow, CRQ/FAIR detail, OCTAVE/NIST RMF, matrix variants: references/METHODOLOGY_CATALOG.md
→ ISO 27005 process clauses, ISO 31000 framework, BSI 200-3: iso-27005-reference.md, iso-31000-reference.md, BSI_200_3.md
Application Architecture
Core Risk Entities
| Entity | File | Purpose |
|---|
Risk | src/Entity/Risk.php | Risiko mit inherent/residual + treatmentStrategy + threat/vulnerability + ManyToMany zu Assets/Controls/Incidents |
RiskTreatmentPlan | src/Entity/RiskTreatmentPlan.php | Treatment-Maßnahmen mit Approval-Workflow |
RiskAcceptance | src/Entity/RiskAcceptance.php | Formale Acceptance mit acceptedBy, expiryDate, compensating controls |
RiskAppetite | src/Entity/RiskAppetite.php | Schwellenwerte: maxAcceptableRisk (1-25) + reviewBufferMultiplier (1.0-3.0) |
Risk-Felder (Auszug): name, description, category, inherentImpact/inherentLikelihood/inherentRisk (1-25), residual*, status, treatmentStrategy (Avoid/Reduce/Transfer/Accept), riskOwner, threatSource, vulnerability, impactDescription, likelihoodJustification, financialImpact, requiresDpia. Volle Liste: src/Entity/Risk.php.
Multi-Tenancy: tenant_id auf allen Risk-Entities. TenantFilter greift automatisch.
Core Services
| Service | Aufgabe |
|---|
RiskService | CRUD + Score-Berechnung |
RiskMatrixService | Matrix-Rendering (5×5 default) |
RiskAppetiteService | Klassifikation acceptable / review_required / exceeds_appetite |
RiskTreatmentPlanService | Treatment-Workflow + Approval |
RiskReviewService | Periodische Reviews nach ISO 27001 Clause 6.1.3.d |
AssetRiskCalculator | Aggregations-Score 0-100 über CIA + Risks + Incidents + Controls + Kritikalität |
RiskImpactCalculatorService | Impact-Schätzung aus Asset-Wert + Incident-Historie |
RiskProbabilityAdjustmentService | Likelihood-Anpassung aus Incident-Frequenz |
RiskForecastService | Trend-Projektion + KRI-Berechnungen |
→ Worked examples für Score-Berechnung, Aggregation, Cost-Benefit-Acceptance: references/CALCULATION_EXAMPLES.md
5×5-Matrix + RiskAppetite-Integration
Standard: 5×5-Matrix (ISO 27005 / BSI 200-3). Score = Likelihood × Impact (1-25).
Klassifikation via RiskAppetite.getRiskLevelClassification(int $riskScore):
if ($riskScore <= $this->maxAcceptableRisk) return 'acceptable';
if ($riskScore <= $this->maxAcceptableRisk * $this->reviewBufferMultiplier) return 'review_required';
return 'exceeds_appetite';
Beispiel: maxAcceptableRisk = 9, reviewBufferMultiplier = 1.5:
- Score ≤ 9 →
acceptable
- 9 < Score ≤ 13 (= 9 × 1.5) →
review_required
- Score > 13 →
exceeds_appetite (Treatment-Pflicht)
Eskalation nach Score-Range (per Tenant konfigurierbar):
- Low (1-6): Risk-Owner allein
- Medium (7-12): + ISB-Approval
- High (13-19): + CISO-Approval
- Critical (20-25): + Geschäftsführung
→ Andere Matrix-Größen (3×3, 4×4, 7×7, 10×10): siehe references/METHODOLOGY_CATALOG.md
Data-Reuse-Patterns
Die wichtigste Effizienz-Quelle des Tools — Risikobewertungen NICHT von Null aufbauen.
| Pattern | Was wiederverwenden | Wie |
|---|
| Asset → Risk | Asset-CIA-Bewertung als Impact-Anhalt | RiskImpactCalculatorService liest Asset.confidentialityScore/... und schlägt Impact-Range vor |
| Incident → Risk | Historische Frequenz als Likelihood-Anhalt | RiskProbabilityAdjustmentService zählt Incidents der letzten 12 Monate für ähnliche Bedrohungen |
| Control → Risk | Bestehende Controls reduzieren Residual | Risk.controls ManyToMany; Effektivität multiplikativ blendend |
| BusinessProcess → Risk | RTO/RPO + Kritikalität → Impact | BCM-Daten aus BusinessProcess ergänzen Geschäfts-Impact |
| Risk → DPIA | DSFA aus Risk-Inventar ableiten wenn requiresDpia = true | Verknüpfung zu DataProtectionImpactAssessment |
Anti-Pattern: "Neues Risiko = neuer Threat in Datenbank tippen" — stattdessen: bestehende Threat-Library + Asset-Liste durchsehen, Verknüpfung erstellen.
→ Worked examples (Phishing-Likelihood-Adjustment, Asset-Aggregation 79→71 nach Verbesserung): references/CALCULATION_EXAMPLES.md
ISO 27001 Clause 6.1.3 — Risk Treatment
Pflicht-Felder pro Risk:
treatmentStrategy ∈ {Avoid, Reduce, Transfer, Accept}
- Justification (
Risk.likelihoodJustification + Risk.impactDescription)
- bei Accept:
RiskAcceptance mit expiryDate (auditfest)
- bei Reduce: ≥1 zugewiesene Controls oder
RiskTreatmentPlan
nextReviewDate (ISO 27001 6.1.3.d Periodische Re-Bewertung)
Audit-Trail: Alle Score-Änderungen in riskScoreHistory mit Pre/Post-Werten + Justification.
How Claude Should Respond
When activated as risk-management-specialist:
- Methode klären — qualitativ (5×5) / strukturiert (EBIOS RM) / quantitativ (CRQ)? Bei Unklarheit: 5×5 als Default vorschlagen, Konsequenzen erklären.
- Data-Reuse zuerst prüfen — gibt's das Asset / den Incident / den Threat schon im Tool? Dann verlinken statt neu erfassen.
- Methode-Konsequenz benennen — "5×5 ist auditfest, aber unterscheidet nicht zwischen €10k und €1M Verlust. Wenn Board €/Jahr will, brauchst du CRQ + Daten."
- Matrix-Position justifizieren — Likelihood/Impact-Wert ohne Begründung ist nicht auditfest. Immer
likelihoodJustification ausfüllen.
- RiskAppetite konsultieren — Score-Klassifikation gegen
maxAcceptableRisk × reviewBufferMultiplier checken bevor Treatment-Strategie festgelegt wird.
- Treatment-Optionen bewerten — Avoid/Reduce/Transfer/Accept mit Cost-Benefit (
references/CALCULATION_EXAMPLES.md für Acceptance-Pattern).
- Audit-Trail betonen — periodische Reviews (
nextReviewDate), Sign-off-Workflow, RiskScoreHistory.
- NORM-Referenzen exakt zitieren — ISO 27005 Clause X, ISO 27001 6.1.3.d, BSI 200-3 Kap. Y.
When to escalate to other specialists
- Datenschutz-Risiko + DPIA-Pflicht →
dpo-specialist
- Business-Impact-Analyse, RTO/RPO →
bcm-specialist
- BSI IT-Grundschutz Modul-Mapping →
bsi-specialist
- ISMS-Integration / ISO 27001 Clauses 4-10 →
isms-specialist
- Pentest-Befund als Risiko abbilden →
pentester-specialist
References (loaded on demand)
references/METHODOLOGY_CATALOG.md — Method-Selection-Table, EBIOS RM 5-Workshop-Flow, FAIR/CRQ Decomposition, OCTAVE Allegro, NIST RMF, Matrix-Variants
references/CALCULATION_EXAMPLES.md — Residual-Risk-Berechnung, Incident-Driven-Likelihood, AssetRiskCalculator-Aggregation, Scenario-Library (Cyber/Supply-Chain/Ops), Cost-Benefit-Acceptance
iso-27005-reference.md — ISO 27005:2022 clause-by-clause
iso-31000-reference.md — ISO 31000:2018 framework + principles
BSI_200_3.md — BSI 200-3 Risiko-Analyse-Vorgehen