CISM Information Security Risk Assessment: Identification, Analysis and Threats

Information security risk identification and assessment is the part of the risk management life cycle that finds what could harm the organization's information and measures how much it matters, so that management can decide what to do about it. It answers three questions in order: what do we have that is worth protecting, what could happen to it, and how likely and how damaging would that be for the business. Deciding the response (mitigate, transfer, avoid or accept), assigning risk ownership and reporting are the next step, covered in the lesson on information security risk response.

The CISM view is a manager's view. The information security manager participates in and oversees the life cycle: sets the method, makes sure the right people take part, challenges weak inputs and makes the results usable for decisions. They do not personally scan every server or own every business risk.

The assessment starts with scope and assets. Before any scanning or threat research, identify the business processes and information assets in scope and establish what each is worth. Without that inventory there is nothing to attach threats, vulnerabilities or impact to, and no way to tell whether a finding matters.

Asset value sets proportionate protection. The main reason to value information assets is to decide how much protection each one justifies: you do not spend more protecting an asset than its loss would cost. Value information by the business, legal and reputational impact of its loss or disclosure, not by the cost of the hardware or storage that holds it. The asset owner sets the value, with the security manager guiding the method and challenging values that ignore impact, such as a research data set valued only at what its servers cost to buy. Recognized frameworks such as ISO/IEC 27005 and NIST SP 800-30 likewise establish context and scope before identifying threats and vulnerabilities and estimating likelihood and impact. ISO/IEC 27005 also allows an event-based approach that starts from risk sources and events rather than an asset list, but the assets and processes in scope still have to be known to judge impact.

Risk is the combination of the likelihood that a threat exploits a vulnerability and the impact that event would have on the business. Threats and vulnerabilities are inputs to risk; neither is the risk on its own.

• Asset: anything of value to the organization: information, the systems and people that process it, and the business processes that depend on it.
• Threat: a potential cause of harm (a criminal group, an insider, a flood, a software failure).
• Vulnerability: a weakness a threat could exploit (an unpatched flaw, a missing review, a weak process).
• Likelihood: how probable the event is, given the threat's capability and intent, the vulnerability's exposure and the controls in place.
• Impact: the consequence for the business: financial loss, regulatory penalties, disruption, harm to customers and reputation.

A vulnerability's severity rating is not a risk rating. A critical-rated flaw on an air-gapped training-room workstation that holds no business data can do little harm to the business, so the risk is low. The same flaw on a system that partners reach over the internet and that holds contract data is a very different risk. The rating describes the weakness; the context decides the risk.

Know which component a control reduces. Some controls mainly lower likelihood (patching, multi-factor authentication, cable locks); others mainly lower impact (backups, encryption, insurance pays out after the loss). Encrypting backup tapes does not make the courier less likely to lose a box; it limits the business impact of the loss, because whoever finds the tapes cannot read them.

Ordinal scores can hide rare, severe losses. On a multiplied risk matrix, likelihood 4 x impact 2 and likelihood 2 x impact 4 give the same score of 8, yet the first leans towards frequent, tolerable losses and the second towards rarer events that hurt far more each time. At the extremes, a rare event with severe impact can exceed the organization's risk tolerance in a single occurrence however low its product score. Present the likelihood and impact profile, not just the product, so senior management can see the difference.

Qualitative analysis rates risk on descriptive or ordinal scales (low/medium/high, 1 to 5); quantitative analysis expresses it in numbers, usually money and probability. Neither is always better: choose by the decision the analysis must support and the data available.

When the question is whether a control is worth its cost, answer in money. A heat map before and after a control cannot tell senior management whether a large investment pays back; an estimate of the annualized loss it removes can. Semi-quantitative approaches (numeric scores mapped to defined ranges) sit between the two.

Scarce loss data does not rule out quantitative analysis. If the board wants monetary figures but the organization has little history of its own losses, use calibrated expert estimates expressed as ranges (for example a minimum, most likely and maximum loss), combined with whatever industry data is relevant, and say how uncertain the result is. Methods such as Open FAIR are built for this. The goal is a defensible estimate now that is honest about its uncertainty: an estimate is only as credible as the reasoning behind each range, and figures that are not representative of the organization's own exposure distort the result.

Annualized loss expectancy (ALE) is the expected loss per year from a risk: the single loss expectancy multiplied by the annualized rate of occurrence.

• Exposure factor (EF): the share of the asset's value lost in one event (0 to 100%).
• Single loss expectancy (SLE) = asset value (AV) x EF.
• Annualized rate of occurrence (ARO): expected events per year. Once every five years is 0.2; once every 20 years is 0.05.
• ALE = SLE x ARO.
• Annual net benefit of a control = ALE before the control - ALE after the control - annual cost of the control. A negative result means the control costs more than the loss it prevents.

Worked example (illustrative figures). A system is worth USD 1,000,000 and an outage would cost 25% of that value, so SLE = USD 250,000. It is expected once every two years (ARO 0.5), so ALE = USD 125,000. A control costing USD 60,000 a year would cut the rate to once every ten years (ARO 0.1): new ALE = USD 25,000. Net benefit = 125,000 - 25,000 - 60,000 = USD 40,000 a year, so the control is justified on these numbers.

Common slips: multiplying asset value by ARO and forgetting the exposure factor; using the SLE as the annual figure; subtracting the control cost from only one ALE; or converting "once every N years" wrongly (the ARO is 1/N).

A risk scenario is a short, plausible story of how a threat could exploit a weakness and what that would do to the business. It links threat, vulnerability, event and business impact, which is what makes it useful for decisions: a list of vulnerabilities or threat actors on its own is not a scenario.

• Involve business process owners in estimating impact. Security knows the threats and weaknesses; the business knows what an outage, a disclosure or a fraud would cost. Impact ratings built without the owners are the ones they later dispute.
• Use scenario libraries as a starting point, not the whole set. Generic industry scenarios capture common risks but miss those specific to the organization's own processes, technology and threats. Tailor them, and add top-down (from business objectives) and bottom-up (from known weaknesses) scenarios.

Risk aggregation: many low risks with a common cause can add up to a high enterprise risk. When several units each rate the same weak process, shared platform or identical device as low, the manager should assess the combined exposure across all of them. Identical weaknesses fail together: one compromised software build pushed to every subsidiary's point-of-sale terminals can stop sales everywhere at once, a common-mode failure that no single subsidiary's assessment shows. This is a key reason to review risks across the enterprise, not only unit by unit.

A common methodology makes results comparable. Risks from different units can only be compared, prioritized and aggregated if everyone uses the same method, the same scales and the same criteria for what each rating level means. Two regions that both use high/medium/low labels, where one means days of downtime and the other means regulatory exposure, are still inconsistent: the same label hides different measures. The fix is to agree, in writing, what each rating level means across the organization, so that a rating carries the same meaning wherever it was produced. A shared method still needs professional judgement and business participation; it does not remove them.

Monitoring the threat and technology landscape lets the information security manager anticipate how risk is changing before it shows up as an incident. The purpose is to update the organization's risk picture: to see which new threats, and which technologies the business is likely to use, will change likelihood or impact.

Threat intelligence is valuable when it is relevant, timely and actionable: it concerns the organization's own assets, technologies and sector, and arrives in time to change a decision. Intelligence that does not apply to the organization adds noise, however much of it there is. Intelligence comes at different levels and feeds different consumers:

Credible new intelligence triggers reassessment. When a trusted source (a national CERT advisory, the vendor itself, a peer organization) confirms that attackers are using a weakness in something the organization depends on, the likelihood of that risk has changed. Reassess it promptly and let the new rating drive the response and its timing, rather than leaving the old rating in place until the next scheduled review.

Emerging technology: assess the risk first, and build the review into adoption. When business units adopt something new, such as browser-based AI transcription tools for internal meetings, the first step is to understand what it means for data, legal obligations and the business, so that whatever follows (rules, controls, approved alternatives) is proportionate to an assessed risk. The sustainable answer is to embed a security risk review in the business's technology selection and change processes, so risk is assessed where the decisions are made rather than after the fact. For autonomous AI agents, for example one allowed to approve supplier refunds, the central risk question is what the agent can do to data and systems without a human checking it. A supplier's third-party attestation describes the supplier's own controls; it says nothing about the permissions your deployment grants the agent.

Threat modeling is a structured analysis of how a system could be attacked, done at design time so the design can still change. It maps components, data flows and trust boundaries, then asks what could go wrong at each point (methods such as STRIDE give a checklist of threat types).

• Timing: the greatest benefit comes during design, before key architecture decisions are fixed. Done after deployment or after a penetration test, it explains problems that are now expensive to fix.
• Scope: include every data flow that crosses a trust boundary, especially integrations with external services such as messaging providers, embedded analytics libraries and partner file transfers. A model that stops at the components the team built misses the riskiest interfaces.
• Maintenance: the model is a living document. When the design or data flows change (a mobile client is added, a webhook to a logistics provider is opened) the model must be updated to cover them; a one-time review at the start of the project goes stale.

The manager's role is to make threat modeling part of the development process, check its scope and currency, and feed its results into the risk assessment.

Vulnerability management is the continuing cycle of finding, prioritizing, remediating and verifying weaknesses, and the information security manager oversees that it reduces risk rather than just producing scan reports. The cycle covers scope (which assets), frequency, prioritization, remediation time frames, verification, and the exceptions that cannot be fixed in time, which go to risk response for a decision.

Prioritize by risk, not by raw score. A CVSS base score describes the flaw in general; it knows nothing about your environment. Rank findings by:

• the criticality of the affected asset and the data it holds;
• its exposure (internet-facing or reachable from untrusted networks);
• evidence of active exploitation (for example a listing in CISA's Known Exploited Vulnerabilities catalog or credible intelligence).

So a moderately scored flaw that attackers are already using on an exposed remote-access gateway can deserve attention before a top-scored flaw on a lab system that holds nothing of value. The three factors above set priority; practical considerations only decide how the work is scheduled.

Remediation time frames are set by severity so that remediation speed matches risk: the riskiest findings close first, and exposure windows are shortest where the potential harm is greatest.

Measure outcomes. The best indicator for senior management is the share of critical (high-risk) findings remediated within the agreed time frame. Prefer metrics that show risk going down over metrics that show work being done.

Keep the scope matched to where the assets are. A program that meets every target but covers only corporate IT systems, after the company acquired factories with their own operational technology, gives false assurance: its metrics describe part of the estate. Review scope whenever the environment changes.

Inherent risk is the risk before controls are considered; residual risk is what remains after controls are applied. Residual risk is the figure management compares with risk appetite, so it is only as reliable as the evidence that the controls actually work.

A control that stops operating raises residual risk, not inherent risk. If a monthly reconciliation of privileged accounts, rated effective, quietly stopped running, the residual risk recorded for those accounts is understated until it is reassessed.

Base residual ratings on evidence of operating effectiveness. Independent test results showing that a control worked over a period are the strongest basis. Evidence that only shows how a control is supposed to work, or that someone says it works, is weaker. If a low residual rating depends heavily on one manual control that has never been tested, test it before decision makers rely on the rating.

Gap analysis compares the current state of controls with a target state, such as a newly adopted framework, a standard or the organization's own policy. Define the target state first; without it there is no gap to measure. Gap analysis is the technique built to measure shortfall against requirements; other assessment techniques answer different questions.

When a control deficiency is found, evaluate the resulting risk first. Determine what the deficiency exposes (for example backups of a production scheduling system that have not been test-restored for two years) before deciding how to act on it. The size of the risk decides the urgency and who must be told; whether the remaining exposure is treated or accepted is a risk response decision.

Risk must be reassessed whenever a significant internal or external change could alter it, not only at the scheduled annual cycle. Typical triggers:

• External: new or changed laws and regulations (for example new penalties for a type of data breach, which change impact), credible intelligence of new or active threats (which changes likelihood), major shifts in technology.
• Internal: mergers and acquisitions (especially connecting an acquired network), outsourcing or new third parties handling sensitive data, new business lines, major system or architecture changes, significant incidents.

Routine, expected activity that does not change the threats, vulnerabilities, assets or impact in play does not by itself require an out-of-cycle reassessment; the test is whether the change could materially alter the risk.

Assess a change before it happens. If a decision such as moving payroll to an external service bureau is made mid-cycle, reassess the risks to the data before the move, while the contract and controls can still be shaped. A provider's certifications are useful input about how it runs security, but they do not replace an assessment of your specific data, scope and obligations. Likewise, when a known change such as a new regulation is coming, assess its effect as soon as it is known, so there is time to respond before it applies.

The manager's job is to make sure these triggers are monitored and that risk management is built into business and IT processes such as change management, procurement and project approval, so reassessment happens as a matter of course.