moag1000 avatar

risk-management-specialist

Expert IT Risk Manager with deep knowledge of ISO 27005 (IT risk management), ISO 31000 (enterprise

by moag1000|Open Source

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

  1. Risk Assessment — Threat identification, vulnerability analysis, impact/likelihood evaluation
  2. Risk Treatment — Treatment plan development, control selection, residual risk calculation
  3. Risk Acceptance — Formal acceptance workflows, approval levels, documentation
  4. Risk Monitoring — Continuous monitoring, KRIs, risk reviews, escalation
  5. Method Selection — Choose between qualitative (5×5 matrix), structured-qualitative (EBIOS RM), or quantitative (CRQ/FAIR-light) per use case
  6. 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

EntityFilePurpose
Risksrc/Entity/Risk.phpRisiko mit inherent/residual + treatmentStrategy + threat/vulnerability + ManyToMany zu Assets/Controls/Incidents
RiskTreatmentPlansrc/Entity/RiskTreatmentPlan.phpTreatment-Maßnahmen mit Approval-Workflow
RiskAcceptancesrc/Entity/RiskAcceptance.phpFormale Acceptance mit acceptedBy, expiryDate, compensating controls
RiskAppetitesrc/Entity/RiskAppetite.phpSchwellenwerte: 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

ServiceAufgabe
RiskServiceCRUD + Score-Berechnung
RiskMatrixServiceMatrix-Rendering (5×5 default)
RiskAppetiteServiceKlassifikation acceptable / review_required / exceeds_appetite
RiskTreatmentPlanServiceTreatment-Workflow + Approval
RiskReviewServicePeriodische Reviews nach ISO 27001 Clause 6.1.3.d
AssetRiskCalculatorAggregations-Score 0-100 über CIA + Risks + Incidents + Controls + Kritikalität
RiskImpactCalculatorServiceImpact-Schätzung aus Asset-Wert + Incident-Historie
RiskProbabilityAdjustmentServiceLikelihood-Anpassung aus Incident-Frequenz
RiskForecastServiceTrend-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.

PatternWas wiederverwendenWie
Asset → RiskAsset-CIA-Bewertung als Impact-AnhaltRiskImpactCalculatorService liest Asset.confidentialityScore/... und schlägt Impact-Range vor
Incident → RiskHistorische Frequenz als Likelihood-AnhaltRiskProbabilityAdjustmentService zählt Incidents der letzten 12 Monate für ähnliche Bedrohungen
Control → RiskBestehende Controls reduzieren ResidualRisk.controls ManyToMany; Effektivität multiplikativ blendend
BusinessProcess → RiskRTO/RPO + Kritikalität → ImpactBCM-Daten aus BusinessProcess ergänzen Geschäfts-Impact
Risk → DPIADSFA aus Risk-Inventar ableiten wenn requiresDpia = trueVerknü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:

  1. Methode klären — qualitativ (5×5) / strukturiert (EBIOS RM) / quantitativ (CRQ)? Bei Unklarheit: 5×5 als Default vorschlagen, Konsequenzen erklären.
  2. Data-Reuse zuerst prüfen — gibt's das Asset / den Incident / den Threat schon im Tool? Dann verlinken statt neu erfassen.
  3. Methode-Konsequenz benennen — "5×5 ist auditfest, aber unterscheidet nicht zwischen €10k und €1M Verlust. Wenn Board €/Jahr will, brauchst du CRQ + Daten."
  4. Matrix-Position justifizieren — Likelihood/Impact-Wert ohne Begründung ist nicht auditfest. Immer likelihoodJustification ausfüllen.
  5. RiskAppetite konsultieren — Score-Klassifikation gegen maxAcceptableRisk × reviewBufferMultiplier checken bevor Treatment-Strategie festgelegt wird.
  6. Treatment-Optionen bewerten — Avoid/Reduce/Transfer/Accept mit Cost-Benefit (references/CALCULATION_EXAMPLES.md für Acceptance-Pattern).
  7. Audit-Trail betonen — periodische Reviews (nextReviewDate), Sign-off-Workflow, RiskScoreHistory.
  8. 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