Cyber risk assessment: how to build a register and make decisions

A list of weak passwords, old software, and untested backups does not yet explain what the company could lose. Cyber risk assessment connects these facts to business processes: interrupted sales, unavailable documents, a data leak, or a mistaken payment. Management needs the result to choose actions and allocate resources.

A useful assessment produces a risk register, agreed criteria, and a list of decisions. Each entry needs an owner, verified inputs, a next action, and a review date. The process below can apply to one service, a department, or the entire company.

Agree on the purpose, scope, and participants

First define the decision the assessment will support. For example, assess readiness to move client documents to the cloud or identify risks to reliable sales operations. Specify the systems, data, sites, and providers within scope. Record exclusions and external dependencies separately. An excluded service can still stop an included process.

Assign an assessment coordinator and process owners. IT confirms system design and security status. Employees explain how work happens and which workarounds they already use. The process manager assesses consequences and makes decisions within their authority. If a risk exceeds that authority, identify who must approve it. A contractor can help collect evidence, but cannot replace the business decision owner.

Choose a clear assessment method and document it before filling in the register. NIST guidance helps organize assessment preparation, execution, and maintenance. Industry requirements and contracts may add mandatory checks and evidence. Completing a template alone does not prove that every applicable requirement has been met.

Collect facts and describe scenarios

Start with processes and related assets

Use the existing inventory of equipment, software, and services. An asset identifier, purpose, owner, important data, and business process connections are enough for the assessment. Add external services, employees with special privileges, and manual operations where the result depends on them. Do not create a parallel copy of every asset record. Link to a verified record instead of entering it again.

Confirm information through several sources: settings, logs, technical test results, tickets, contracts, and discussions with owners. Record each piece of evidence's date and source separately. If recovery test information is missing, write recovery unverified rather than no backups. Uncertainty requires investigation, not an invented fact.

Connect the threat, weakness, and consequences

Describe a risk as a possible event with a cause and a business consequence. Phishing is too broad a description. A more useful entry states that an attacker uses stolen credentials to access business email and substitute payment details. This identifies the affected process, event, and potential harm. Another scenario involves an administrator's mistake: deleting a shared folder causes downtime if recovery does not work.

• Consider external attacks, employee mistakes, access misuse, and configuration errors.
• Check dependencies on providers, cloud services, power, and site availability. Include them when they affect the selected cyber risk scenario.
• Identify consequences for data availability, integrity, and confidentiality. Then translate them into interrupted operations, costs, obligations, and customer impact.
• Separate events with different owners or treatment options. You can combine the same weakness across several related systems while retaining the list of affected assets.

Assess existing controls through evidence

Record what already reduces the event's likelihood or the severity of its consequences. Examples include multifactor sign in, restricted permissions, updates, training, segmentation, logs, and tested backups. A control's name matters less than its scope and performance in the required scenario. A copy without a successful recovery test does not prove that the service can return. Installed protection does not prove that it works on every required device.

Record the state of each control and confirmed gaps. The article on priority controls for regulated businesses explains how to implement initial protections. Use control verification results when choosing risk treatment actions.

Assess likelihood and consequences with consistent criteria

Three qualitative levels can provide a starting point. Agree on the assessment period and the characteristics of each level. Do not present the word high as a calculated percentage. If evidence is limited, record the uncertainty and an action to reduce it. The process owner should understand the rating, rather than simply find a colored diagram convincing.

These criteria are an example, not a universal standard. The company must define its critical operations and acceptable losses. Use your own figures for financial amounts, downtime, and contractual limits. A likelihood and consequence matrix helps agree on priority, but equal ratings do not make two risks identical. Account for dependencies, scale, and confidence in the evidence.

Separate inherent, current, and expected risk

If a decision needs a comparison, assess the scenario without protective controls and separately with the controls that actually work. The second rating can be called current residual risk. Record expected risk after planned changes separately: a plan does not reduce the current rating. After implementing and testing changes, reassess residual risk using new evidence. You do not need all three ratings for every entry. State clearly which controls, assumptions, and facts the assessment includes.

Complete the register and choose next actions

The following training example contains three entries with hypothetical roles and ratings. Replace them with data from your own environment. Each row should describe one manageable scenario, rather than the company's entire security condition.

Add evidence links, the assessment author and date, status, selected treatment, implementer, deadline, and completion criterion to the working register. The risk owner decides on consequences; the task owner makes the specific change. One person may hold both roles in a small company, but distinguish them in the entry. Restrict access to detailed information about permissions and weaknesses. Give management the appropriate summary.

Choose risk treatment and agree on a plan

• Reduce: change access, configuration, or a process to reduce likelihood or consequences.
• Avoid: stop the risky operation or replace the way it is performed.
• Share responsibility and consequences through a contract or insurance while retaining your own obligations and dependence on the provider.
• Accept: an authorized owner explicitly agrees to the residual risk, conditions, and review date. A lack of budget or an implementer does not itself mean agreed acceptance.

Set priority, resources, and timing based on consequences, attack path accessibility, and dependencies. Assign one owner and a verification method to each task. If remediation requires an interruption, agree on a work window, application test, and rollback to previous settings. If a change cannot yet happen, record a temporary control, its limits, and a review date. If there are signs that an incident has already occurred, start the agreed response process instead of waiting for the assessment to finish.

Verify results and maintain the register

Close a task after verifying its result, rather than receiving a message that a tool was installed. For risk R002, evidence would be successful recovery of the required data under agreed conditions. After verification, update the control status, residual risk rating, and owner's decision. If the effect is weaker than expected, reopen the issue. Keep the change history so the reason for a revised rating remains visible.

Schedule periodic reviews based on criticality and applicable requirements. Also revisit an entry after an incident, provider change, new evidence, or a significant access or infrastructure change. No single mandatory frequency applies to every company. Automated discovery and reports can refresh the underlying facts, but assigned people still agree on consequences, assumptions, and risk acceptance.

Before presenting the result to management, check that the scope is clear, important scenarios connect to processes, existing controls are verified, criteria are consistent, and unknowns are flagged. Each priority risk needs an owner and a decision. Each action needs an implementer, deadline, and verification criterion. The register then supports work rather than merely listing alarming descriptions.

If the assessment lacks verified technical evidence about security conditions, discuss a review with DKs through the Security Assessment page. The results can help refine entries and choose justified actions.

Sources

• NIST guidance on conducting risk assessments
• NIST on cyber risk registers and organizational objectives