Risk Assessment
How threat, vulnerability, and business context combine into decisions about what to protect and why
What is Cybersecurity Risk?
Cybersecurity risk is usually expressed as a combination of likelihood and consequence. A practical shorthand is Risk = Threat x Vulnerability x Impact. A threat source (for example a criminal group, insider, or accidental actor) uses a vulnerability (a weakness in technology, process, or people) to create impact on an asset the organisation values. That impact may be financial, operational, legal, safety-related, or reputational. This framing is consistent with ISO 27005 guidance on information security risk management and NIST SP 800-30 Rev. 1, which both emphasise understanding threat events, predisposing conditions, likelihood, and adverse impact.
The key operational point is that not all risks are equal. Some can be accepted because the consequence is minor or the event is unlikely. Others are intolerable because even one occurrence would be severe. A mature program therefore ranks risks rather than treating every vulnerability or alert as equally urgent. References: ISO 27005 and NIST SP 800-30 Rev. 1 (https://csrc.nist.gov/pubs/sp/800/30/r1/final).
The Three Pillars
A useful way to explain risk to technical and non-technical stakeholders is to separate it into three pillars: threat, vulnerability, and impact. Threat answers who might target you and with what capability, intent, and opportunity. Vulnerability answers what weaknesses exist in systems, configurations, code, identity controls, or business processes. Impact answers what happens if exploitation succeeds: downtime, data loss, fraud, legal exposure, recovery cost, and mission disruption.
In practice, organisations often have good data for the first two pillars but weaker analysis for the third. Threat intelligence can indicate active campaigns and attacker behaviour. Vulnerability management can show exposure and patch status. Impact requires business knowledge: which systems drive revenue, which data triggers regulatory obligations, and which outages matter most. link42 treats these pillars as connected inputs rather than isolated dashboards, because prioritisation quality depends on all three.
Business Context is the Missing Piece
Threat and vulnerability data are broadly available. What makes risk assessment organisation-specific is business context. Sector matters because adversaries, legal obligations, and operational tolerances differ. A finance provider, public hospital, and university can face the same vulnerability but very different consequences. Data classification matters because personal information (PII, meaning personally identifiable information), health records, payment data, and classified material each attract different compliance duties and breach impacts.
Architecture also changes risk posture. Internet-facing SaaS platforms, hybrid enterprise networks, and air-gapped operational technology environments have different attack surfaces and detection options. Existing controls matter: strong identity, segmentation, backups, and incident response can substantially reduce residual risk. Finally, constraints matter. Budget, staffing, and delivery timelines determine treatment realism. Good assessments therefore capture context explicitly instead of assuming a generic "average organisation" baseline that fits nobody.
Risk Assessment vs Risk Management
Risk assessment and risk management are related but different activities. Assessment identifies and evaluates risks by analysing threats, vulnerabilities, likelihood, and impact. Management decides treatment actions and tracks outcomes over time. Common treatment options are: accept (risk is tolerable), mitigate (implement controls to reduce likelihood or impact), transfer (for example insurance or contractual allocation), and avoid (stop the activity creating the risk).
The Australian Information Security Manual (ISM) aligns with this broader management lifecycle through phases such as define, select, implement, assess, authorise, and monitor. In other words, assessment is an input; management is the governance process that turns analysis into accountable decisions. Teams often over-invest in scoring models but under-invest in ownership, deadlines, and reassessment cadence. A risk without an owner, treatment plan, and review date is documentation, not management.
Qualitative vs Quantitative Risk
Qualitative risk assessment uses categories such as Low, Medium, High, and Critical. Its strengths are speed and communication clarity, especially for cross-functional decision-making. Its weakness is subjectivity: two teams may rate the same scenario differently without calibrated criteria. Quantitative risk assessment estimates numeric loss, often in currency terms. A classic model uses Annual Loss Expectancy (ALE) = Single Loss Expectancy (SLE) x Annual Rate of Occurrence (ARO). This supports budget and investment analysis but requires stronger data quality assumptions.
Most organisations blend both methods. Qualitative scoring handles broad portfolio triage. Quantitative modelling is applied to high-value decisions such as major architecture changes, cyber insurance strategy, or board-level investment cases. FAIR (Factor Analysis of Information Risk) is the most recognised quantitative framework in cybersecurity and provides structured decomposition of frequency and magnitude. Reference: https://www.fairinstitute.org/.
Risk Appetite and Tolerance
Risk appetite is the total level and type of risk an organisation is willing to pursue or retain in support of objectives. Risk tolerance defines acceptable variation around that appetite for specific activities or systems. These are governance settings set by executive leadership and the board, informed by legal obligations, strategic goals, and stakeholder expectations. Security teams advise, but they do not unilaterally set enterprise appetite.
A practical statement might be: "We accept Medium residual risk for non-critical internal systems but require Low residual risk for systems handling classified or safety-critical data." This turns abstract policy into operational guidance for control selection, exception handling, and escalation. Without explicit appetite and tolerance, teams either over-control low-value systems or under-protect critical assets, both of which waste resources and increase unmanaged exposure.
The link42 Approach
link42 is designed to combine the four inputs that most teams currently manage in separate tools. threat10 contributes threat intelligence context: active adversary behaviour, campaign indicators, and attacker capability trends. patch8 contributes vulnerability exposure and remediation state. rule1 contributes framework-aligned control guidance, including ISM mapping and implementation expectations. System profiles contribute business context: criticality, data sensitivity, architecture, ownership, and constraints.
These inputs are fused into an AI-assisted risk assessment workflow that prioritises recommendations with explicit reasoning, rather than opaque scores. The objective is to reduce analyst time spent stitching evidence together and increase decision confidence for technical leaders and executives. This capability aligns with Phase 5C of the platform roadmap: integrated, explainable, context-aware risk prioritisation that supports both operational triage and governance reporting.
Continue Learning
If you want to apply these concepts in a structured way, continue with formal methodologies and then map them to control frameworks and operational data sources. The sequence below moves from conceptual model to execution detail.