risk-management

# Risk Management Skill

Threat-informed risk management methodology. Begin with risk identification
using asset inventory and threat intelligence, then assess likelihood and
impact quantitatively, select treatment options, maintain a governed risk
register, and report risk posture to leadership.


## risk-identification

# Risk Identification

## Purpose
Systematically identify risks using threat-informed asset analysis, threat modelling, vulnerability inputs, and business context mapping.

---

## 1. Threat-Informed Asset Inventory

### Critical Asset Identification
```
Criteria for criticality:
  - Revenue generation (e.g. payment processing, trading systems)
  - Regulatory compliance (e.g. systems processing PII, PHI, PAN)
  - Operational dependency (e.g. manufacturing control, logistics)
  - Reputational impact (e.g. customer-facing systems)
  - Intellectual property (e.g. source code repositories, R&D data)

Asset criticality rating: Critical / High / Medium / Low

For each critical asset, map:
  - Which threat actor groups target this type of asset?
  - What ATT&CK techniques are most relevant?
  - What existing controls mitigate those techniques?
```

### MITRE ATT&CK Groups for Asset-to-Threat Mapping
```
Financial sector assets:
  APT28 (G0007), FIN7 (G0046), Lazarus Group (G0032)
  Relevant techniques: T1566 (phishing), T1078 (valid accounts),
  T1486 (ransomware), T1041 (exfil over C2)

Healthcare assets:
  APT41 (G0096), BRONZE BUTLER (G0060)
  Relevant techniques: T1190 (exploit public), T1003 (credential dump)

OT/ICS assets:
  Sandworm (G0034), XENOTIME
  Relevant techniques: T0800-T0900 range (ICS techniques)
```

---

## 2. Threat Modelling Integration

### STRIDE per Asset Type
| Threat | Description | Example |
|--------|-------------|---------|
| Spoofing | Identity falsification | Credential theft, session hijack |
| Tampering | Data modification | Man-in-the-middle, SQL injection |
| Repudiation | Deny action occurred | Log deletion, audit trail gaps |
| Information Disclosure | Unauthorised data access | Data exfiltration, misconfigured bucket |
| Denial of Service | Service disruption | DDoS, ransomware |
| Elevation of Privilege | Gain unauthorised access | Local privilege escalation, SSRF |

### PASTA (Process for Attack Simulation and Threat Analysis)
```
Stage 1: Define objectives (business impact analysis)
Stage 2: Define technical scope (DFDs, system inventory)
Stage 3: Decompose application (trust boundaries, entry points)
Stage 4: Threat analysis (threat actors, attack patterns)
Stage 5: Vulnerability analysis (scanners, pen test, CVEs)
Stage 6: Attack modelling (attack trees per threat scenario)
Stage 7: Risk analysis (risk scoring, treatment priority)
```

---

## 3. Vulnerability Input Sources

| Source | Cadence | Scope |
|--------|---------|-------|
| Vulnerability scanner (Tenable, Qualys) | Weekly | All in-scope assets |
| Penetration test findings | Annual / Ad hoc | Selected scope |
| Bug bounty reports | Continuous | External attack surface |
| CISA KEV (Known Exploited Vulnerabilities) | Continuous | All CVEs with active exploitation |
| NVD/CVE feed | Continuous | Vendor-specific CVEs |
| Threat intelligence | Continuous | TTPs and IOCs |

### CISA KEV Integration
```
# Monitor CISA KEV catalogue
curl https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json

# For each KEV entry affecting your asset inventory:
# 1. Immediate escalation if asset is in CDE or critical tier
# 2. Emergency patching SLA: 24-48h for active exploitation
# 3. Add to risk register immediately as High/Critical
```

---

## 4. Business Context Mapping

For each identified risk, capture business context:

| Dimension | Questions |
|-----------|----------|
| Revenue impact | Which revenue streams are affected? Estimated $ loss per day of outage? |
| Regulatory exposure | Which regulations are implicated? Potential fine range? |
| Reputational risk | Would this be public? Media coverage potential? Customer impact? |
| Operational dependency | How long before manual processes fail? Vendor dependencies? |
| Legal liability | Data subject notification requirements? Class action exposure? |

---

## 5. Emerging Threat Horizon Scanning

### Sources for Horizon Scanning
```
Zero-day advisories:
  - CISA advisories (https://www.cisa.gov/uscert/ncas/alerts)
  - Vendor security bulletins (Microsoft Patch Tuesday, Adobe, etc.)
  - Project Zero (https://googleprojectzero.blogspot.com/)

Threat actor intelligence:
  - MITRE ATT&CK Groups (https://attack.mitre.org/groups/)
  - Mandiant/CrowdStrike threat reports
  - ISAC advisories (FS-ISAC, H-ISAC, E-ISAC for sector-specific)

Supply chain events:
  - Software supply chain attacks (e.g. SolarWinds-style)
  - Open source package compromises (npm, PyPI)
  - CISA supply chain security alerts

Geopolitical factors:
  - State-sponsored threat actors activated by geopolitical events
  - Critical infrastructure targeting during conflict periods
```

---

## 6. Risk Identification Workshop Facilitation

```
Workshop Format:
  Duration: 2-4 hours
  Participants: Business owners, IT/security, Legal/Compliance
  Facilitator: CISO/GRC lead

Structured approach:
  1. Review asset inventory (15 min)
  2. Review recent threat intelligence (15 min)
  3. Brainstorm risks per asset/process (60 min)
     - "What could go wrong?"
     - "What would cause us to fail our regulatory obligations?"
     - "What do our adversaries want from us?"
  4. Initial risk categorisation (30 min)
  5. Assign owners and prioritise for assessment (30 min)

Output: Raw risk list with initial categorisation for formal assessment
```



## risk-assessment

# Risk Assessment

## Purpose
Score identified risks using qualitative and quantitative methods, calibrate against risk appetite, and prioritise for treatment.

---

## 1. Qualitative Scoring

### Likelihood Scale
| Score | Label | Criteria |
|-------|-------|---------|
| 1 | Rare | < once in 5 years; no known exploits; nation-state effort required |
| 2 | Unlikely | Once in 2-5 years; limited attack complexity; few known threat actors |
| 3 | Possible | Once per 1-2 years; known CVEs exist; commodity tools available |
| 4 | Likely | Once per year; actively exploited in wild; easy to execute |
| 5 | Almost Certain | Multiple times per year; trivial to exploit; automated exploitation |

### Impact Scale
| Score | Label | Criteria |
|-------|-------|---------|
| 1 | Negligible | Minimal disruption; no regulatory impact; < $10k financial impact |
| 2 | Minor | Limited disruption; internal only; $10k-$100k |
| 3 | Moderate | Customer-facing impact; possible regulatory notification; $100k-$1M |
| 4 | Major | Significant breach; regulatory fine likely; $1M-$10M; media coverage |
| 5 | Catastrophic | Business-threatening; regulatory action; > $10M; existential reputational damage |

### Risk Matrix
```
         Impact
         1    2    3    4    5
L     5 [5]  [10] [15] [20] [25]
i     4 [4]  [8]  [12] [16] [20]
k     3 [3]  [6]  [9]  [12] [15]
e     2 [2]  [4]  [6]  [8]  [10]
h     1 [1]  [2]  [3]  [4]  [5]
o
o  Risk score = Likelihood × Impact
d  
   Critical = 20-25
   High     = 12-19
   Medium   = 6-11
   Low      = 1-5
```

---

## 2. Inherent vs Residual Risk

```
Inherent Risk  = Risk BEFORE any controls are applied
                 (assess as if no controls exist)

Residual Risk  = Risk AFTER existing controls are considered
                 (assess current state with controls in place)

Example:
  Scenario: Ransomware attack on backup systems
  Inherent: Likelihood=4, Impact=5 → Score=20 (Critical)
  Controls in place: Immutable backups, offline copies, tested recovery
  Residual: Likelihood=2, Impact=3 → Score=6 (Medium)
  
  Document: what controls justify the likelihood/impact reduction
```

---

## 3. Risk Appetite and Tolerance

### Appetite vs Tolerance
```
Risk Appetite: Amount of risk the organisation is WILLING to accept
               (strategic, board-approved statement)
               Example: "We accept Medium operational risks as cost of doing business.
                         We do NOT accept any Critical risks without treatment plan."

Risk Tolerance: Acceptable variation around risk appetite
                (specific thresholds per risk category)

Risk Capacity:  Maximum risk the organisation CAN bear
                (financial, operational, reputational limits)
```

### Risk Appetite Statement by Category
| Risk Category | Appetite | Tolerance Threshold |
|--------------|---------|-------------------|
| Regulatory/Legal | Zero tolerance | No violations acceptable |
| Customer data breach | Very Low | < 1 incident per 3 years |
| Operational disruption | Low | < 4 hours downtime for critical systems |
| Financial fraud | Low | < 0.1% of annual revenue |
| Third-party incident | Medium | < 2 per year with < $100k impact each |

---

## 4. FAIR Model for Financial Quantification

### FAIR Components
```
Risk = Loss Event Frequency × Loss Magnitude

Loss Event Frequency (LEF):
  LEF = Contact Frequency × Probability of Action
  
  Contact Frequency: How often does the threat actor encounter the asset?
  Probability of Action: Given contact, what's the probability of attack?

Loss Magnitude (LM):
  Primary Loss: Direct financial impact (recovery costs, lost revenue)
  Secondary Loss: Indirect (regulatory fines, reputation, legal liability)

Vulnerability: Probability that a threat succeeds given a threat event occurs
  Vulnerability = f(Threat Capability, Control Strength)
```

### FAIR Analysis Example
```
Scenario: Ransomware attack on core ERP system

Contact Frequency: 12 times per year (opportunistic scanning)
Probability of Action: 30% (attacker attempts if contact made)
Threat Event Frequency: 12 × 0.30 = 3.6 events/year

Vulnerability:
  Threat Capability: High (ransomware-as-a-service, low skill threshold)
  Control Strength: Medium (MFA deployed but unpatched vuln present)
  Vulnerability: 60%

Loss Event Frequency: 3.6 × 0.60 = 2.16 events/year

Loss Magnitude (per event):
  Primary: $500k (recovery, downtime, IT labour)
  Secondary: $200k (regulatory notification, customer notification, brand)
  Total LM: $700k

Annualised Loss Expectancy (ALE): 2.16 × $700k = $1,512,000/year

Decision: Investment up to $1.5M/year in controls is financially justified.
```

---

## 5. Risk Aggregation

For portfolio-level risk view:
```
1. Group risks by risk category (cyber, operational, strategic, legal)
2. Sum residual risk scores per category
3. Identify concentration risk (many risks from single threat actor/vendor)
4. Identify correlated risks (ransomware hitting both primary and backup simultaneously)
5. Produce aggregate risk view for board

Correlation warning signs:
  - Multiple critical assets on same network segment
  - Multiple critical vendors using same data centre
  - Multiple controls dependent on same underlying technology
```



## risk-treatment

# Risk Treatment

## Purpose
Select appropriate treatment for each identified risk, document rationale, implement controls, and reassess residual risk.

---

## 1. Treatment Options

### Accept
```
Criteria:
  - Residual risk within risk appetite
  - Cost of control exceeds benefit
  - No cost-effective control exists

Requirements:
  - Documented risk owner sign-off (named individual, not role)
  - CISO awareness and concurrence
  - Board notification for High/Critical accepted risks
  - Defined review date (annual maximum)
  - Logged in risk register with acceptance rationale

Template:
  I, <Name, Title>, accept the residual risk of <risk title> (score: <n>)
  on behalf of <Business Unit>. I understand that this risk may materialise
  and accept responsibility for any resulting business impact.
  Accepted: <date>  Review: <date>
```

### Mitigate
```
Control selection framework:
  1. Map risk to relevant framework controls:
     NIST 800-53 (US federal), CIS Controls v8, ISO 27001 Annex A
  
  2. Prioritise controls with highest risk reduction:
     - CIS Controls IG1/IG2 for most common risks
     - CISA KEV remediation for exploited vulnerabilities
     - ATT&CK mitigations for specific techniques
  
  3. Document:
     - Control name and description
     - Implementation timeline
     - Responsible party (RACI)
     - How control effectiveness will be measured
     - Expected residual risk after implementation
```

### Transfer
```
Mechanisms:
  Cyber Insurance:
    Coverage types: first-party (response costs, business interruption),
                    third-party (liability to customers/regulators)
    Key considerations:
      - Aggregate limit vs per-incident limit
      - Exclusions (war exclusions, systemic risk like SolarWinds)
      - Sublimits for ransomware payments
      - Retention/deductible (typically $250k-$1M for enterprise)
    
    Gap analysis: Ensure insured loss events map to your risk register

  Contractual Transfer:
    SLAs with vendors (service credit for downtime)
    BAA/DPA for regulatory liability transfer
    Indemnification clauses for vendor-caused breaches
    Note: Regulatory liability cannot be fully transferred (GDPR: controller remains accountable)
```

### Avoid
```
Risk avoidance = eliminate the activity that creates the risk

Examples:
  - Discontinue storing CHD (removes PCI-DSS scope)
  - Migrate to managed SaaS (eliminates self-managed server risk)
  - Terminate a high-risk vendor relationship
  - Disable a legacy system with no viable patching

Document: business impact of avoidance and explicit decision by accountable owner
```

---

## 2. Control Selection Framework

### CIS Controls v8 Implementation Groups
| Implementation Group | Target Organisation | Focus |
|---------------------|---------------------|-------|
| IG1 (Essential) | Small organisations; limited IT resources | 56 safeguards (basic hygiene) |
| IG2 (Medium) | Mid-size; IT and security staff present | IG1 + additional 74 safeguards |
| IG3 (High) | Large; dedicated security team | All 153 safeguards |

### Top CIS Controls by Risk Reduction (Foundational)
```
CIS 1: Inventory of Enterprise Assets → T1200, T1078 mitigations
CIS 2: Inventory of Software → T1072, T1059 mitigations
CIS 3: Data Protection → T1048, T1485 mitigations
CIS 4: Secure Configuration → T1098, T1190 mitigations
CIS 5: Account Management → T1078, T1136 mitigations
CIS 6: Access Control (MFA) → T1078.001, T1078.003 mitigations
CIS 7: Continuous Vulnerability Management → all exploitation techniques
CIS 8: Audit Log Management → T1070, T1562 mitigations
```

---

## 3. Treatment Documentation Template

```
RISK TREATMENT RECORD
======================
Risk ID:          RISK-<YYYY>-<nnn>
Risk Title:       <Ransomware attack on ERP system>
Inherent Score:   20 (Critical) — L4 × I5
Treatment Decision: Mitigate + Transfer
Risk Owner:       <VP Technology>

Mitigating Controls (to implement):
  CTL-001: Deploy EDR on all servers (CIS 10.1)
           Owner: IT Security | Due: 2026-09-01 | Status: In Progress
  CTL-002: Immutable backup solution
           Owner: IT Operations | Due: 2026-08-01 | Status: Complete
  CTL-003: Phishing-resistant MFA for all admin accounts (CIS 6.3)
           Owner: IT Security | Due: 2026-07-01 | Status: Complete

Cyber Insurance:
  Policy: <Insurer> | Limit: $10M | Retention: $500k
  Coverage confirmed for ransomware events: Yes

Expected Residual Score: 8 (Medium) — L2 × I4
Actual Residual Score: <assessed after control implementation>

Review Date: 2027-06-01
Next Risk Review: Quarterly (due to High residual)
```

---

## 4. Post-Treatment Residual Risk Assessment

After implementing mitigating controls:
1. Re-assess likelihood with controls in place (reduce likelihood score)
2. Re-assess impact (note: controls rarely reduce impact of a successful attack, but may limit blast radius)
3. Calculate new residual score
4. If residual score still exceeds risk appetite threshold:
   - Identify additional controls
   - Formal risk acceptance by appropriate authority
   - Board notification if Critical remains after treatment

---

## 5. Treatment Prioritisation

| Priority | Criteria | Timeline |
|----------|---------|---------|
| P1 Critical | Residual risk Critical; active exploitation; regulatory exposure | Immediate (< 30 days) |
| P2 High | Residual High; known threat actor interest; significant business impact | 60 days |
| P3 Medium | Residual Medium; theoretical exploitation; moderate impact | 90 days |
| P4 Low | Residual Low; minimal exploitation likelihood; low impact | 180 days |



## risk-register

# Risk Register

## Purpose
Design and govern a structured risk register as the authoritative source of risk information for the organisation.

---

## 1. Risk Register Schema

### Required Fields per Risk Entry
```
Core Identification:
  Risk ID:           RISK-<YYYY>-<nnn>
  Title:             <Concise risk name>
  Description:       <Detailed description of the risk scenario>
  Date Identified:   <YYYY-MM-DD>
  Date Last Updated: <YYYY-MM-DD>
  Status:            Active / In Treatment / Accepted / Closed

Business Context:
  Asset/Process:     <Critical asset or business process at risk>
  Business Impact:   <Revenue / Regulatory / Operational / Reputational>
  Threat Actor:      <Internal / External / Nation-State / Insider>
  Threat Event:      <What could happen: ransomware, data theft, outage>

Risk Assessment:
  Existing Controls: <list existing controls addressing this risk>
  Inherent Risk:     Likelihood (1-5) × Impact (1-5) = <score>
  Residual Risk:     Likelihood (1-5) × Impact (1-5) = <score>
  Risk Rating:       Critical / High / Medium / Low

Treatment:
  Treatment Decision: Accept / Mitigate / Transfer / Avoid
  Treatment Actions:  <control references>
  Risk Owner:         <named individual>
  Due Date:           <YYYY-MM-DD>
  Progress:           <% complete or status>

Governance:
  Review Date:       <YYYY-MM-DD>
  Next Review:       <YYYY-MM-DD>
  Escalation Status: <Board notified Y/N>
  Exceptions:        <any accepted deviations>
```

---

## 2. Risk Register Governance

### Quarterly Review Cycle
```
Month 1 (review month):
  Week 1: Risk owners update their risks (progress, new information)
  Week 2: GRC team aggregates and prepares risk report
  Week 3: Security Steering Committee reviews and approves
  Week 4: Board risk committee receives top 10 risk update

Criteria for interim (outside quarterly) review:
  - Material security incident that activates a risk
  - Significant change in threat landscape (new zero-day, nation-state activity)
  - Major business change (acquisition, new product, market entry)
  - Regulatory change affecting risk profile
  - Vendor breach affecting supply chain
```

### Escalation Thresholds
| Condition | Escalation |
|-----------|-----------|
| New Critical risk | CISO notification within 24h; Board at next meeting |
| Residual risk remains Critical after treatment | Board approval for acceptance |
| Risk score increased by 2+ levels | Risk Owner + CISO review within 1 week |
| Risk owner departure | Immediate re-assignment required |
| Treatment overdue by > 30 days | CISO notification; leadership escalation |

---

## 3. GRC Platform Integration

### Common GRC Tools and Risk Register Features
| Tool | Key Features |
|------|-------------|
| ServiceNow GRC | Workflow automation, control inheritance, audit trail |
| Archer | Flexible schema, quantitative risk, regulatory mapping |
| LogicGate | Visual risk workflow, scoring models, reporting |
| OneTrust | Privacy-focused, regulatory mapping, vendor risk |
| Vanta | SOC 2 / ISO 27001 automation, continuous monitoring |
| Spreadsheet (fallback) | Excel/Google Sheets with defined schema and access controls |

### Minimum Spreadsheet Requirements
```
- Access restricted (not widely shared)
- Version control (dated save copies)
- Change log tab (who changed what and when)
- Hash/checksum of file (integrity)
- Read-only copy exported for audit
```

---

## 4. Risk Register Maintenance

### New Risk Entry Triggers
- Vulnerability scanner finding with CVSS > 9.0 (Critical)
- Penetration test finding (always add to register)
- Security incident (severity Medium or above)
- Threat intelligence advisory naming organisation's sector/technology
- Compliance gap identified in audit
- Business change (new system, new market, new third party)

### Risk Closure Criteria
- Treatment fully implemented and verified
- Risk appetite met (residual risk within tolerance)
- Formal closure sign-off by risk owner and CISO
- Evidence of control effectiveness documented
- Note: Never delete closed risks; mark as Closed with closure date

---

## 5. Sample Risk Register (Abbreviated)

| Risk ID | Title | Inherent | Residual | Treatment | Owner | Due | Status |
|---------|-------|---------|---------|-----------|-------|-----|--------|
| RISK-2026-001 | Ransomware on ERP | C (20) | M (8) | Mitigate | VP Tech | 2026-09-01 | In Progress |
| RISK-2026-002 | Supply chain compromise | H (15) | M (9) | Mitigate+Transfer | CISO | 2026-12-01 | In Progress |
| RISK-2026-003 | Insider data exfiltration | H (12) | M (6) | Mitigate | HR+IT | 2026-08-01 | In Progress |
| RISK-2026-004 | PCI-DSS non-compliance | H (16) | L (4) | Mitigate | Compliance | 2026-07-01 | Complete |
| RISK-2026-005 | Legacy system (EOL) | M (9) | M (9) | Accept | CTO | — | Accepted |



## risk-reporting

# Risk Reporting

## Purpose
Communicate risk posture effectively to executive and board audiences, track trends, and meet regulatory reporting requirements.

---

## 1. Executive Risk Dashboard Design

### Dashboard Components
```
1. RISK HEAT MAP (5x5 grid)
   Plot all open risks by likelihood and impact
   Use colour coding: Red=Critical, Orange=High, Yellow=Medium, Green=Low
   Include previous quarter positions to show trend direction

2. TOP 10 RISKS TABLE
   | Rank | Risk Title | Current Score | vs Prior | Treatment | Owner | Due |
   Show movement: arrows (up/down/stable) vs prior quarter

3. TREATMENT STATUS SUMMARY
   By category: In Treatment / Accepted / Not Started / Overdue
   Progress bar per severity band

4. NEW AND CLOSED RISKS
   New risks this period: <n>
   Risks closed this period: <n>
   Net change: <+n / -n>

5. RISK APPETITE COMPLIANCE
   Number of risks exceeding appetite by tier:
     Critical with no treatment plan: <n> (target: 0)
     High open > 90 days: <n> (target: < 3)
```

---

## 2. Risk Trend Analysis

### Trend Metrics (Quarter-over-Quarter)
```
Risk Portfolio Summary:
                      Q2 2026    Q1 2026    Change
Critical risks:          2          4        -2 (improvement)
High risks:             8          7        +1 (new risk added)
Medium risks:          15         16        -1
Low risks:             12         11        +1
Total open:            37         38        -1

Average residual score:  7.8       8.2      -0.4 (improvement)

Risks by domain:
  Cyber (technical):   18
  Third-party:          8
  Operational:          7
  Regulatory:           4

Treatment velocity:
  Risks closed this quarter:    6
  Average days open for closed: 45 days
```

---

## 3. Risk Posture Narrative

### Executive Summary Template
```
RISK POSTURE SUMMARY — Q2 2026
================================

Overall posture: AMBER (Moderate Risk)

The organisation's risk posture has improved marginally quarter-over-quarter,
with 2 Critical risks resolved through successful control implementation.
The overall residual risk score decreased from 8.2 to 7.8 (out of 25).

Key positive developments:
  - EDR deployment completed across all server infrastructure
  - Immutable backup solution fully operational (ransomware risk reduced to Medium)
  - Privileged access management implemented for 95% of admin accounts

Key concerns:
  - Third-party risk in AMBER due to 3 critical vendors overdue for reassessment
  - Legacy ERP system remains a Medium risk pending upgrade (scheduled Q4)
  - New emerging risk: AI system prompt injection identified (added to register)

Risks requiring Board attention:
  - RISK-2026-002: Supply chain compromise — treatment plan approved but
    implementation delayed; revised target Q4 2026; CISO monitoring weekly
```

---

## 4. Risk Appetite Compliance Report

```
RISK APPETITE COMPLIANCE REPORT
=================================
Organisation Risk Appetite Statement:
  "We accept Medium operational risks; we do NOT accept Critical risks without
   an approved treatment plan and timeline."

Compliance Status:
  Critical risks with no treatment plan:      0  ✓ COMPLIANT
  Critical risks accepted without Board note:  0  ✓ COMPLIANT
  High risks open > 90 days:                  2  AMBER (target: < 3)
  High risks with no owner assigned:          0  ✓ COMPLIANT

Breach of appetite this period:
  RISK-2026-007 (New): Unpatched RCE in legacy system (Critical, L5×I5)
  Status: Treatment plan approved; emergency patching in progress
  Board notification: Sent 2026-06-01
  Expected compliance: 2026-06-15
```

---

## 5. Regulatory Risk Reporting Requirements

### Selected Regulatory Requirements
| Regulation | Risk Reporting Requirement |
|------------|--------------------------|
| DORA (EU) | Annual ICT risk reporting to regulatory authorities; incident reporting |
| NYDFS (NY) | Annual certification by CISO to Superintendent; risk assessment required |
| PCI-DSS | Annual risk assessment; quarterly vulnerability scans |
| HIPAA | Annual risk analysis; risk management programme |
| NERC CIP | CIP-002 risk-based categorisation of BES Cyber Systems |
| GDPR Art 32 | Regular testing and evaluation of technical measures |

### Board Risk Reporting Format for Regulated Entities
```
For regulated financial services / healthcare:
  1. Risk appetite statement (board-approved, reviewed annually)
  2. Top 10 material ICT/cyber risks with residual scores
  3. Inherent vs residual risk comparison (controls effectiveness)
  4. Treatment plan status and timeline
  5. Incidents and near-misses with root cause analysis
  6. Control deficiencies and remediation timeline
  7. Emerging risks identified this period
  8. Benchmarking vs sector (if available)
```