What is a cyber risk assessment?

A cyber risk assessment is a method applied to evidence, and it leaves three things behind: a ranked list of risks with a reason beside each rating, a dated report for the people who decide what to fund, and new or updated entries on the risk register. If any of the three is missing, the assessment either never finished or was never written down.

The names vary; the activity does not. Cybersecurity, information security and IT risk assessment describe the same work, though IT risk assessment is sometimes stretched to cover IT projects and service delivery. NIST SP 800-30 Rev. 1 defines risk assessment as "the process of identifying, estimating, and prioritizing information security risks", and those are the risks that "arise from the loss of confidentiality, integrity, or availability of information or information systems".

The newest free guidance is NIST IR 8286A Rev. 1, Identifying and Estimating Cybersecurity Risk for Enterprise Risk Management, published on 18 December 2025.

One boundary matters before the method. Many published step lists end with "apply security fixes". Fixing is treatment, a separate decision made by the person who owns each risk and recorded on the risk register. The assessment stops at a ranked, evaluated list, which is what lets an organisation show later which risks it chose to carry and why.

Why a cyber risk assessment matters

Without an assessment, security spend gets ranked by whatever is loudest that month: a vulnerability score, a headline, the last incident. Severity is a property of a flaw. Risk is a property of that flaw in a particular place, against a particular attacker, at a particular cost.

The scoring standard says so itself. FIRST's CVSS v4.0 specification tells consumers to "enrich the Base metrics with Threat and Environmental metric values specific to their use of the vulnerable system to produce a score that provides a more comprehensive input to risk assessment". A base score is an input to the assessment, never its answer.

CISA made the same move for US federal agencies on 10 June 2026. Binding Operational Directive 26-04 revoked BOD 19-02, which had set remediation deadlines by CVSS severity (critical within 15 calendar days, high within 30), and BOD 22-01. In their place it asks four questions of each vulnerability: is the asset publicly exposed, is the vulnerability on CISA's Known Exploited Vulnerabilities (KEV) Catalog, can an adversary automate every step of the exploit, and does exploitation give partial or total control of the asset. Its remediation deadlines run from three days to the next system upgrade. The directive binds US Federal Civilian Executive Branch agencies, and CISA "strongly encourages all partners to adopt similar actions in their vulnerability management policy".

Run the four questions over two flaws and the order flips. The vulnerability management post covers the prioritisation inputs (EPSS, KEV and SSVC); the assessment's job is to put each flaw inside a scenario with an asset and a consequence.

Somebody usually asks for the assessment by name, and each asker has a document behind them:

• An ISO 27001 certification auditor reads clause 6.1.2 (criteria set before scoring, assessments that produce "consistent, valid and comparable results", named risk owners) and clause 8.2 (assessments at planned intervals and on significant change, with the results retained).
• The HIPAA Security Rule makes risk analysis a required specification for covered entities and business associates, in these words: "Conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information."
• ASD's Information security manual asks, in ISM-1203, that system owners, with each system's authorising officer, "conduct a threat and risk assessment for each system". The ISM is advice, and it becomes an obligation through the Protective Security Policy Framework, a contract, a state policy or a direction.
• The NIST Cybersecurity Framework 2.0 states the outcome of its Risk Assessment category (ID.RA) as "The cybersecurity risk to the organization, assets, and individuals is understood by the organization", and GV.RM-06 asks for a standardised method to calculate and prioritise it.

Boards, cyber insurers and customer security reviews ask too, in plainer words: what are our top risks, and how do you know?

How a cyber risk assessment works, step by step

The standards agree on the core and differ mostly in vocabulary, so a reader can follow either and arrive at the same result.

Where an assessment sits in risk management

ISO 31000:2018's process, as the Australian Department of Finance's Comcover information sheet presents it, runs: establish the scope, context and criteria; identify the risks; analyse them; evaluate them; treat them. Communication and consultation, monitoring and review, and recording and reporting run around every stage. Risk assessment is the middle three: identification, analysis and evaluation.

IR 8286A Rev. 1 adopts ISO 31000's three prerequisites: a defined scope, a determined context, and documented criteria. SP 800-30 Rev. 1 gives the assessment four steps of its own: prepare, conduct, communicate and maintain.

What a risk scenario is made of

Each risk is written as a scenario with four parts. IR 8286A Rev. 1 says a cyber risk description needs four inputs: the assets involved and their value, the threats that could harm their confidentiality, integrity or availability, the vulnerabilities or predisposing conditions that make a threat event possible, and the consequences if the threat exploits the weakness against the asset. ISO/IEC 27005:2022 describes a risk scenario the same way, as a sequence or combination of events running from an initial cause to an unwanted consequence.

NIST's own example shows the cause-and-effect form: "External criminal attacker exploits a software vulnerability in the internet-facing customer data site, resulting in 'significant' customer confidential data exfiltration with revenue, reputation, and regulatory implications." Two readers given that sentence would agree on what has to happen for it to occur, which is the test. And the asset need not be technology: NIST counts people, facilities, critical data, intellectual property and services.

The ten steps

Each step leaves an artefact behind, and the artefacts are what an auditor or a board asks to see.

Step 2 carries the rest. SP 800-30 says a methodology has four parts (a process, an explicit risk model, an assessment approach and an analysis approach) and that making them explicit, with a rationale for every assessed value, is how organisations "increase the reproducibility and repeatability of risk assessments". A useful model for a written scale is SP 800-30's Table G-3, which anchors likelihood to frequency: very high is more than 100 times a year, low is less than once a year but more than once every ten years.

Step 4 changes what gets found. SP 800-30 names three starting points (threats, assets and impacts, or vulnerabilities) and warns that "differences in the starting point of the risk assessment can potentially bias the results, causing some risks not to be identified". Its remedy is a second pass from another orientation; ISO/IEC 27005:2022 calls the pair event-based and asset-based identification. IR 8286A Rev. 1 states the cost plainly: "any risks that are not identified at this stage will not be part of the subsequent risk analysis".

Step 6 has three moves in SP 800-30: the likelihood that a threat event is initiated or occurs, the likelihood that it then causes harm, and the two combined. The first depends on the attacker's capability, intent and targeting. The second depends on the controls in place, and IR 8286 Rev. 1 says likelihood and impact "should account for existing and planned controls". The safer convention is to credit only controls with evidence that they operate, and to list planned ones separately for re-rating when they land.

Step 7 is where an assessment comes in low if it stops at the first loss. IR 8286A Rev. 1 separates primary impact, "the initial impact following a negative cybersecurity event", from the secondary losses that follow: lost market share, contracts not renewed, regulatory fines. Leaving them out, says IR 8286 Rev. 1, "would underestimate the total impact, thereby misinforming risk response selection and prioritization".

Qualitative, semi-quantitative and quantitative analysis

SP 800-30 defines three ways to express the result. Qualitative assessment uses categories such as very low to very high; it is easy to communicate, but "unless each value is very clearly defined or is characterized by meaningful examples", different experts can produce very different results. Semi-quantitative assessment uses bins or scales such as 1 to 5 or 0 to 100, whose values do not keep their meaning outside the assessment. Quantitative assessment uses numbers that keep their meaning anywhere, usually probabilities and money, and "most effectively supports cost-benefit analyses", though its rigour drops when subjective judgements are buried inside the numbers.

IEC 31010:2019, as NIST quotes it, gives two criteria for choosing: "the form of output of most use to stakeholders and the availability and reliability of data". NIST's own position, in IR 8286A Rev. 1, is that "quantitatively informed qualitative decision-making should be the objective in the absence of purely quantitative-driven decisions", and IR 8286 Rev. 1 goes further and says quantitative methods are preferred where they are possible.

The practical position for most organisations is a semi-quantitative 1 to 5 scale with a written sentence for every point, plus money estimates, given as ranges, for the few risks where a decision turns on cost. NIST lists the techniques for the money end, from three-point estimation and Monte Carlo simulation to calibration training. FAIR, maintained by the FAIR Institute and standardised by The Open Group as O-RT 3.1 and O-RA 2.1 (both updated in May 2025), is the model built for it. The argument for going further than a matrix is made in full in Risk management beyond the matrix.

How likelihood and impact combine

A risk matrix is a combination rule, and NIST uses two different ones. SP 800-30's Table I-2 is a lookup: it says "the risk level is typically not higher than the impact level, and likelihood can serve to reduce risk below that impact level", so very high likelihood with low impact gives low, and low likelihood with very high impact gives moderate. IR 8286 Rev. 1 records exposure in the register as likelihood multiplied by impact, under which both of those cells score 10 out of 25.

Either rule works if it is written down. Choose one, write it into the criteria with its tie-break, and state which way it leans. Louis Anthony Cox's 2008 paper "What's Wrong with Risk Matrices?" shows that matrices have poor resolution and can rate a smaller risk above a larger one, and concludes that they "should be used with caution, and only with careful explanations of embedded judgments".

A worked example: a payroll software company's annual assessment

A 280-person payroll software company in Melbourne runs payroll for about 1,900 employer customers and has held ISO/IEC 27001:2022 certification since August 2025. Its annual assessment, the planned interval clause 8.2 asks for, runs from 3 August to 4 September 2026. Priya Raman, Head of Security, leads it with the Head of Customer Support, the platform engineering lead and the CFO. The company, the people and the figures are fictional; the threat patterns are published.

Purpose and scope. The assessment has two jobs: decide which treatments go into the 2027 security budget the board approves on 18 November 2026, and produce the dated results the surveillance auditor will ask for on 24 November 2026. In scope are the payroll platform (the pay engine, the payroll ledger database, the internet-facing managed file transfer server customers upload pay inputs to, the bank file service, the support console and the build pipeline) and the support desk process. Corporate IT is out of scope; it was assessed in March 2026. Ratings cover the next twelve months.

The method, unchanged from 2025 so the results compare. Likelihood runs 1 to 5 as the chance of the event in the next twelve months: under 5%, 5 to 20%, 20 to 50%, 50 to 80%, over 80%. Impact runs 1 to 5 on four dimensions (money, personal information, missed or late pay runs, regulators and customers) and takes the worst. A 4 starts at AUD 500,000. A 5 is above AUD 2 million or the personal information of more than 1,000 people. The level is likelihood multiplied by impact, and ties break toward the higher impact. The appetite threshold is 10 for risks to customer funds, payroll data and pay runs, against an organisation default of 12. Every rating carries a sentence of reason and names the controls it credits, and each assessor scores alone before the group discusses.

Two passes. On 10 August the team works asset-first from the business impact analysis, which names the pay run as the critical process. On 13 August it works threat-first from CISA's published advisories and the support desk's call log. Between them they write six scenarios:

• S1: a social engineering crew calls the support desk posing as a customer's payroll officer, has that user's MFA reset to a device it controls, and changes employee bank details before a pay run, diverting that customer's net pay.
• S2: ransomware encrypts the payroll ledger in the 48 hours before a fortnightly pay run. Its immutable backups restored in nine hours in a May 2026 test.
• S3: an attacker exploits an unpatched flaw in the managed file transfer server, the pattern CL0P used against MOVEit Transfer in 2023, and copies every customer's uploaded pay inputs, including tax file numbers and bank details.
• S4: a compromised open-source dependency pulled by the build pipeline ships code that copies bank details out of the pay engine.
• S5: a payment file is altered between the bank file service and the bank, which signed files over an authenticated channel make unlikely.
• S6: credential stuffing against the employee self-service login locks staff out on pay day. MFA prevents takeover, so the cost is support load and lockout.

The threat-first pass found the risk ranked first. The asset-first pass saw the support console as a system with patch levels and access logs; it took CISA's advisory on Scattered Spider, actors who persuaded help desks to "transfer the employee's MFA to a device they control", read against the call log, to see the reset process as the weakness.

Likelihood, with evidence. S1 rates a 4. Someone will try: the help-desk pattern is published, and two reset calls in the June quarter were judged suspicious. It would work against today's controls: MFA is in place, but resets are approved on knowledge-based questions, and nobody tells the customer when bank details change. S3 rates a 3 with high uncertainty. Managed file transfer products have been mass-exploited before (CISA and FBI describe CL0P exploiting MOVEit Transfer from 27 May 2023), and the server faces the internet by design. Against that, critical advisories for it were patched within 72 hours on the last four occasions.

Impact, counting secondary loss. S1's primary loss is about AUD 1.25 million: roughly AUD 1.1 million of diverted pay, reimbursed to the customer's staff while the funds are chased, and about AUD 150,000 of incident response. That rates a 4. The losses that follow take it further. The assessors judge the breach notifiable under the Privacy Act's Notifiable Data Breaches scheme, which requires notice to affected individuals and the Office of the Australian Information Commissioner (OAIC) when a breach is likely to result in serious harm: about 420 people, and some AUD 120,000 of notification and regulator work. The CFO puts customer non-renewals at AUD 0.8 million to 1.5 million a year. Other customers send fresh security questionnaires, which cost staff time nobody has priced. The total clears AUD 2 million even at the low end, so S1's impact is a 5.

Counting only the primary loss would have scored S1 at 16, one point ahead of S3, with a far weaker case for funding.

Level, evaluation and ranking. The published rule gives S1 20, S3 15, S2 12, S4 10, S6 10 and S5 5. S4 and S6 tie at 10, and the tie-break puts S4 first because its impact is higher; SP 800-30's Table I-2 gives the same order, moderate against low. Three scenarios exceed the threshold of 10, and three sit at or under it.

Hand-off and maintenance. The report goes to the executive committee on 4 September 2026, and all six scenarios go on the risk register on 7 September, where owners are named and responses chosen (the risk register guide covers that work). The assessment stops here. The report names the events that re-open it before August 2027: a critical advisory for the managed file transfer product (S3 is re-rated within the week), a new integration or bank channel, an acquisition, or a material incident. When the surveillance auditor asks for the clause 8.2 results in November, the answer is the dated report and the criteria it used.

Common mistakes

The eight failure modes below share one root: a score produced by reflex rather than by a method someone else could repeat. Here is S1 scored both ways; four of the differences carry the number of the mistake behind them.

1. Scoring before the scales are written. If a 4 means "possible" to one assessor and "expected this year" to another, the ranking is noise. Write a sentence for every point, publish the rule and the tie-break, and put a reason beside every rating; SP 800-30 says that annotation increases the repeatability of qualitative results.
2. Treating a control checklist or a maturity score as the assessment. ASD's ISM says its guidelines help with identification and treatment, but "an organisation will still need to undertake their own risk analysis and risk evaluation activities". Use the catalogue as an input, then do the analysis.
3. Ranking by vulnerability severity. A CVSS base score describes the flaw, not where it sits. Ask where the flaw is, whether it is being exploited, whether the exploit can be automated, and what an attacker gains.
4. Looking from one direction only. An asset-first pass finds what the organisation already worries about. Run a second pass from the threats, or the reverse, as SP 800-30 recommends.
5. Counting only the primary loss. Rate the losses that follow (notification, regulators, customers who leave) and record which impact dimension drove the rating.
6. Crediting controls that are planned, unproven or beside the point. MFA does not stop an attacker who talks the help desk into resetting it. Credit only controls with evidence that they work against this scenario, and list planned ones separately; NIST allows planned controls to be counted, so say which convention you used.
7. Converging on the first number said in the room. NIST's bias table names overconfidence, group think, following trends and availability (over-weighting what you heard about last week). Take individual estimates before discussion and check past estimates against what happened.
8. Running it once a year and filing it. SP 800-30 says "the validity and usefulness of any risk assessment is bounded in time". Keep a planned interval and add written triggers for significant change.

A cyber risk assessment compared with its neighbours

Most of the confusion with neighbouring activities clears once you ask two questions of each: what does it look at, and what does it produce.

An audit belongs on the map too. It tests whether controls operate as described, and a finding that cannot be fixed inside the audit's timeframe becomes a risk on the register. The map below places each neighbour by what it looks at and shows what it hands to the assessment.

Standards and references

NIST SP 800-30 Rev. 1, Guide for Conducting Risk Assessments (September 2012). Still the current edition after fourteen years, and free. Chapter 2 has the risk model and the three analysis approaches, Chapter 3 the four steps, and Appendices G to I example likelihood, impact and combination scales.

NIST IR 8286A Rev. 1, Identifying and Estimating Cybersecurity Risk for Enterprise Risk Management (18 December 2025). The most current free document on identification and estimation: Section 2.2 for the four-part scenario and the bias table, Section 2.3 for qualitative and quantitative estimation. Its parent, IR 8286 Rev. 1, covers the register and the response.

NIST CSF 2.0 (26 February 2024). ID.RA-01 to ID.RA-05 describe the assessment's outcomes, and GV.RM-02 and GV.RM-06 describe the appetite statements and the standardised method that should exist before it starts.

ISO/IEC 27005:2022, Guidance on managing information security risks (fourth edition, October 2022). The ISO guidance written for an ISO 27001 management system. ISO sells its standards, so the descriptions of ISO/IEC 27005, ISO 31000:2018 and ISO/IEC 27001:2022 here come from dated secondary sources and NIST's citations; check the wording against a licensed copy before quoting it.

IEC 31010:2019, Risk management. Risk assessment techniques (June 2019). The catalogue of techniques and the criteria for choosing between qualitative and quantitative ones.

Australian Signals Directorate, Information security manual (September 2026 release). ISM-1633 and ISM-1203 for system-level assessments, ISM-1452 for supply chain risk assessments, and the "Monitor the system" section for the events that should re-open one.

CISA, BOD 26-04 (10 June 2026), with FIRST's CVSS v4.0 specification and EPSS. The current statement, from a US federal agency, that vulnerability severity is an input to risk rather than a ranking.

The Open Group, Open FAIR (O-RT 3.1 and O-RA 2.1, May 2025). The taxonomy and analysis method for quantifying a scenario in money.

How Alvor helps

With Alvor, an organisation runs its assessment on criteria it wrote itself, and every score, chart and export reads from them.

The criteria are one versioned record: a likelihood scale with a label, a description and a frequency guide for each point; impact ratings described across the organisation's own impact dimensions; and, for each risk level, what it means, the response expected, who may accept it and how often it is reviewed. The heat map draws its axis labels from those scales, the Excel export prints them on its Criteria sheet so a committee or an auditor sees how the numbers were made, and the AI analyst reads them before it drafts anything.

Each risk starts as a scenario. In intake, the reporter writes the risk statement and the scenario, records how it was identified, picks the affected assets from the asset register, and adds the consequences and existing controls. The asset register already carries each asset's business criticality, how it flows down the dependency graph, and scanner findings attached to the asset they belong to, so the asset and weakness parts of a scenario start from records.

Scoring is likelihood multiplied by impact on 1 to 5 scales, with the assessment rationale recorded beside the score. In the Assess studio, an AI analyst running on the organisation's own model provider (bring your own model, including any OpenAI-compatible endpoint, configured by an administrator) can draft the likelihood and impact, the STRIDE threats, recommended controls, the rationale and the root cause into the form. Nothing it drafts is saved until a person submits. Controls link to a risk with an effectiveness rating, and the threat library suggests controls for a threat, so the controls a rating credits are named.

Evaluation is automatic. Every risk gets a verdict against the appetite threshold set for its category, or the organisation default: within appetite, exceeds appetite, or a tolerance breach. It uses the residual score where one exists and the inherent score otherwise, and a Breaches tab lists what is over the line. Review dates are scheduled from each level's cadence and show on the owner's dashboard; risks nearing or past their due date are notified.

Risks also arrive between assessments. A compliance finding escalates into the register with the link kept on both records, a Secure by Design sign-off approved with conditions creates a risk in the same transaction, and a Business Continuity exercise finding can be escalated by someone with risk write access. Owners, responses and acceptance are covered in the risk register guide.

Alvor runs as a dedicated single-tenant instance in the region you choose, on your own servers, or air-gapped. Risk Management covers the module in full.