
risk-management-specialist
Expert IT Risk Manager with deep knowledge of ISO 27005 (IT risk management), ISO 31000 (enterprise
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:
RiskAcceptancemitexpiryDate(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
likelihoodJustificationausfüllen. - RiskAppetite konsultieren — Score-Klassifikation gegen
maxAcceptableRisk×reviewBufferMultiplierchecken bevor Treatment-Strategie festgelegt wird. - Treatment-Optionen bewerten — Avoid/Reduce/Transfer/Accept mit Cost-Benefit (
references/CALCULATION_EXAMPLES.mdfü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-Variantsreferences/CALCULATION_EXAMPLES.md— Residual-Risk-Berechnung, Incident-Driven-Likelihood, AssetRiskCalculator-Aggregation, Scenario-Library (Cyber/Supply-Chain/Ops), Cost-Benefit-Acceptanceiso-27005-reference.md— ISO 27005:2022 clause-by-clauseiso-31000-reference.md— ISO 31000:2018 framework + principlesBSI_200_3.md— BSI 200-3 Risiko-Analyse-Vorgehen