IT Risk Fundamentals cheat sheet

Risk = likelihood of a threat event × magnitude of impact; inherent risk excludes controls, residual risk is measured after controls are applied.

Risk = Threat × Vulnerability × Impact; a risk requires a threat source, a vulnerability, and an adverse consequence - remove any element and the risk does not exist.

Risk appetite is the amount of risk an organization is willing to accept in pursuit of objectives; risk tolerance is the acceptable deviation around that appetite, expressed as measurable limits.

Risk capacity is the maximum risk an organization can absorb before viability is threatened; capacity is always greater than or equal to appetite.

Qualitative scales (High/Medium/Low) use defined criteria for likelihood and impact; quantitative analysis expresses risk in monetary terms, typically as annualized loss expectancy (ALE).

SLE (single loss expectancy) = asset value × exposure factor; ALE = SLE × annualized rate of occurrence (ARO).

Risk register entries contain: risk ID, description, cause, affected asset, owner, inherent rating, controls, residual rating, and treatment decision.

Four treatment options: mitigate (reduce likelihood or impact), transfer (insurance, contracts), avoid (eliminate the activity), accept (documented decision by risk owner).

Risk owner is accountable for the risk and its treatment decision; control owner operates the control; risk owners accept residual risk, not the security team.

NIST SP 800-30 risk assessment steps: prepare, conduct (identify threat sources, identify vulnerabilities, determine likelihood, determine impact, determine risk), communicate, maintain.

ISO 31000 process: establish context, identify, analyze, evaluate, treat, monitor and review, communicate and consult - iteration is explicit, not linear.

COSO ERM components: governance and culture, strategy and objective-setting, performance, review and revision, information-communication-reporting.

FAIR (Factor Analysis of Information Risk) decomposes risk into loss event frequency (threat event frequency × vulnerability) and loss magnitude (primary and secondary loss).

Three lines model: first line owns and manages risk, second line provides oversight and challenge, third line (internal audit) gives independent assurance.

Key risk indicators (KRIs) are forward-looking metrics with thresholds; key performance indicators (KPIs) measure achievement of objectives - a KRI predicts loss, a KPI reports results.

Control types: preventive (stops the event), detective (identifies it), corrective (restores after it), compensating (substitutes when the primary control is unavailable).

Control categories by nature: administrative/managerial, technical/logical, physical/environmental.

Risk treatment must be recorded with a decision date and reviewer; accepted risks require periodic re-evaluation because likelihood and impact change over time.

Threat modeling (e.g., STRIDE: spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege) identifies threats against a design before deployment.

Vulnerability management metrics: mean time to detect, mean time to remediate (MTTR), and percentage of critical vulnerabilities remediated within SLA.

A vulnerability is a weakness; a threat is a potential cause of harm; exposure is the condition of being susceptible - risk combines all three with impact.

Risk heat map plots likelihood against impact; cells above the tolerance line require treatment or formal acceptance by the accountable owner.

Inherent risk minus control effectiveness equals residual risk; control effectiveness is judged by design adequacy plus operating effectiveness evidence.

Business impact analysis (BIA) determines RTO and RPO per process; RTO is maximum tolerable downtime, RPO is maximum tolerable data loss measured in time.

Risk aggregation across systems can exceed the sum of individual risks when systems share dependencies, single sign-on, or the same network segment.

Third-party risk: inherent vendor risk is tiered by data sensitivity and system criticality; residual vendor risk depends on contractual clauses and assurance reports (e.g., SOC 2 Type II).

Risk reporting to the board should state risk exposure against appetite, trend direction, and treatment status - not raw vulnerability counts.