IT Risk Governance and Risk Appetite
Risk governance is the set of policies, roles, and processes through which an organisation manages risk at the highest level. The board of directors sets risk appetite — the total amount of risk the organisation is willing to accept in pursuit of its objectives. Risk tolerance is narrower: the acceptable variation around specific risk metrics. Risk capacity is the maximum risk the organisation can absorb before existential harm. Risk managers must translate these board-level statements into operational thresholds that IT teams can actually measure. Risk culture is the shared attitudes and behaviours around risk — a healthy risk culture means employees report near-misses without fear of punishment, risk register entries are accurate rather than politically massaged, and executives do not override risk decisions for short-term gain.
Risk Identification and the Risk Register
Risk identification produces the raw material for the risk register. Sources: threat intelligence feeds, vulnerability assessments, audit findings, industry risk libraries (ISACA's Risk IT, FAIR), internal incident data, business process walkthroughs, and external incident databases (FS-ISAC, HHS, SEC disclosures). Each risk entry includes: risk statement (if [threat] exploits [vulnerability] then [impact] to [asset]), likelihood (probability over a time horizon), impact (financial, operational, reputational, regulatory), inherent risk score, current controls, residual risk score, risk owner (accountable for managing the risk), and risk response (accept, avoid, mitigate, transfer). Risk registers are living documents — reviewed at least quarterly and updated after significant changes or incidents.
Qualitative and Quantitative Risk Analysis
Qualitative risk analysis assigns descriptive likelihood and impact ratings (High/Medium/Low or 1-5 scales) and produces a heat map. It is fast, requires no specialised data, and communicates well to non-technical audiences — but it is subjective and does not produce financial figures. Quantitative risk analysis uses financial metrics: Asset Value (AV), Exposure Factor (EF — percentage of asset lost in a single incident), Single Loss Expectancy (SLE = AV x EF — cost per incident), Annual Rate of Occurrence (ARO — expected incidents per year), Annual Loss Expectancy (ALE = SLE x ARO — expected annual cost of the risk). FAIR (Factor Analysis of Information Risk) is the leading quantitative risk model: it decomposes risk into frequency and magnitude components using probability distributions, enabling Monte Carlo simulation and executive-ready financial ranges. FAIR is increasingly expected at CRISC level.
Control Design and Implementation
Control design follows risk assessment: you select controls that reduce either the likelihood or impact of the identified risks to an acceptable residual level. Control principles: preventive controls reduce likelihood (access controls, security training, input validation), detective controls reduce time-to-detection (SIEM, IDS, reconciliation), corrective controls reduce recovery time and impact (backup, patch management, IR procedures). Control cost-benefit: the cost of implementing and operating a control must be less than the expected loss reduction (ALE reduction > annualised control cost). Key CRISC concepts: control deficiency (design gap — the control was never right), control failure (operational gap — the control exists but stopped working), compensating control (an alternative control that achieves the same objective when the primary control cannot be implemented). Controls must be regularly tested to confirm they are still operating effectively.
Third-Party and Supply Chain Risk
Third-party risk management (TPRM) is a growing component of CRISC. Vendors who have access to your data or systems can introduce risk that is outside your direct control. TPRM programme elements: vendor risk tiering (classify vendors by data access, system access, and criticality — tier 1 critical vendors get full on-site assessment), due diligence questionnaires (standard frameworks: SIG, CAIQ, VSAQ), contractual requirements (right to audit clauses, security annexes, data processing agreements, SLA and incident notification obligations), continuous monitoring (security ratings services, SOC 2 reports, annual reassessments), and exit planning (what happens to your data if the vendor fails or is breached?). Supply chain attacks (like SolarWinds) show that even high-tier vendors can be weaponised — software composition analysis and SBOM (Software Bill of Materials) are emerging controls.