PRMIA CCRM cheat sheet

Asset inventory scope rule: identification covers people, process, technology, facilities, and third parties; omitting any category understates exposure and invalidates downstream quantification.

Threat taxonomy (five classes): natural, accidental/error, adversarial outsider, adversarial insider, and supply-chain/third-party. Each class needs a distinct likelihood source.

Risk = f(asset value, threat event frequency, vulnerability). Identification produces the asset-threat-vulnerability triple; assessment only scores it.

Loss event taxonomy (Basel-style): data confidentiality breach, data integrity breach, availability/business interruption, fraud/theft, and external legal/regulatory liability.

Crown-jewel rule: rank assets by dependency depth, not by replacement cost. Systems with high fan-in (identity, DNS, backup, ERP) rank above high-value but isolated systems.

Threat modeling convention (STRIDE): Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege - one control family per letter.

Third-party identification: include Nth-party (fourth-party) concentration. A single cloud or CDN provider shared across vendors creates correlated, not independent, failure.

Identification completeness check: every asset must map to at least one threat and one loss-event category; unmapped assets are identification gaps, not zero-risk items.

Emerging-risk scan horizon: identification should cover technology change (cloud, OT/ICS convergence, AI/LLM use, remote access) before it appears in incident data.

FAIR decomposition: Risk = LEF × LM, where LEF = TEF × Vulnerability (0–1), and LM = Primary Loss + Secondary Loss (response, fines, reputation).

Annualized loss formula: ALE = SLE × ARO; for frequency-based models use ALE = expected loss per event × annual event frequency.

SLE = asset value × exposure factor. Exposure factor is the percentage of value impaired by one event, not the probability the event occurs.

Qualitative scoring: 5×5 likelihood-impact matrix yields a 1–25 score; scores are ordinal, so averaging or summing them across risks is invalid.

Monte Carlo output reporting: report P50 (median), P90/P95/P99 (capital and insurance sizing), and the mean. Mean > median indicates a heavy right tail.

Risk appetite translation: tolerance is the maximum acceptable loss at a stated confidence (e.g., annual loss at 95th percentile ≤ USD 5m).

Control effectiveness reduces Vulnerability (LEF), not Loss Magnitude, unless the control also limits event scope (e.g., segmentation, backups).

Correlation adjustment: aggregate correlated risks by summing loss distributions (or copula), not by summing individual ALEs, which assumes independence.

Scenario calibration: use internal incident counts for TEF where n ≥ 5–10 per year; below that, use external loss data or expert elicitation with documented ranges.

Treatment options: mitigate, transfer, avoid, accept. Each residual risk decision must record owner, threshold, and review date.

Control selection order: preventive (reduce LEF) → detective (reduce loss duration) → corrective/recovery (reduce LM). Cost justified when ΔALE > control lifecycle cost.

Insurance limit sizing: set limit near the P95–P99 annual aggregate loss; check sublimits for cyber extortion, dependent business interruption, and regulatory defense.

Key risk indicators with thresholds: patch latency (days), MFA coverage (%), privileged account count, backup restore test pass rate, third-party assessment currency.

Incident response sequence: detect → contain → eradicate → recover → post-incident review. Containment precedes eradication; recovery validation precedes return to production.

BCP/DR metrics: RTO (maximum tolerable downtime) and RPO (maximum tolerable data loss). RPO drives backup frequency; RTO drives recovery architecture.

Risk register fields: risk ID, scenario, inherent score, controls, residual score, owner, treatment plan, KRI, review date.

Board reporting rule: express cyber risk in financial and operational terms (loss exceedance curve, tolerance breach count), not technical control counts alone.

Regulatory/contractual drivers to track: incident notification clocks (e.g., 72-hour GDPR-style windows), sector rules, and contractual breach-notice obligations.