Original study context
This is a cleaned-up migration of a 2021 information-assurance post on risk management in cyber security. The original article focused on two areas: bias in decision-making and the NIST Risk Management Framework.
I was looking at risk as a structured way to decide what should be protected, what should be fixed first, which controls make sense, who owns the decision, and how that decision should be monitored after the initial assessment. The shift for me was moving from “find the issue” to “understand the issue, rank it, choose a response, and keep checking whether the response is still working”.
Risk as prioritisation
Risk management is a way of prioritising security work. Not every vulnerability, misconfiguration, weak process, or exposed service carries the same level of risk. A finding needs context before it can become a sensible decision.
The context includes the asset involved, the data or service it supports, the threats that apply, the vulnerabilities present, the controls already in place, and the impact if the issue is exploited or the service fails. Likelihood and impact sit at the centre of that judgement. A weakness on an isolated test system does not carry the same weight as a weakness on a public system that handles sensitive data or supports business-critical work.
Prioritisation also has to account for business reality. Some controls reduce risk but create operational cost, downtime, usability problems, or maintenance burden. Risk work does not remove technical judgement; it gives that judgement a route into decisions about cost, ownership, timing, and acceptable exposure.
Bias in risk decisions
I started with bias because risk decisions are made by people. A risk assessment can look structured on paper and still be influenced by assumptions, incentives, previous experience, group pressure, or the way information is presented.
The bias types I covered were:
- Cognitive bias: unconscious factors that distort beliefs or create a subjective view of the situation.
- Motivational bias: distortion driven by incentives, pressure, or personal motivation.
- Nonverbal bias: judgements affected by body language, appearance, presentation, or dress.
- Affinity bias: favouring people who feel familiar or similar, such as those from the same background, workplace, course, or social group.
- Halo and horns effect: allowing one positive or negative trait to shape the whole judgement of a person, system, or decision.
- Similarity bias: preferring people or ideas that feel similar to our own working style or personality.
- Contrast effect: judging something against a recent experience rather than against a stable baseline.
- Attribution bias: explaining our own mistakes through external factors while blaming others more directly for theirs.
- Confirmation bias: looking for evidence that supports a judgement already made.
- Conformity bias: adapting views or behaviour to fit the group.
In cyber security, those biases can affect risk scoring, incident severity, control selection, and escalation. A familiar system can be treated as safer than it is. A loud stakeholder can make a lower-risk issue feel urgent. A team can keep looking for evidence that supports its first assessment and miss signs that the risk is different.
The practical answer is not to pretend bias can be removed completely. It is to make assumptions visible, use repeatable criteria, record why decisions were made, and invite review before a technical finding becomes a business decision.
Risk assessment factors
A risk assessment needs enough structure to avoid becoming a list of opinions. The factors I associated with the process were assets, threats, vulnerabilities, impact, likelihood, existing controls, and organisational context.
Assets are the systems, data, services, processes, or people that need protection. Threats are the events or actors that could cause harm. Vulnerabilities are weaknesses that could be exploited or could allow failure. Controls are safeguards already in place or planned to reduce the risk.
Likelihood asks how plausible the event is. Impact asks what happens if it occurs. The answer may include confidentiality, integrity, availability, privacy, legal exposure, operational disruption, financial loss, reputational damage, or safety concerns. A high-impact event with a low likelihood may be handled differently from a common low-impact issue.
Ownership is part of the assessment as well. Someone has to accept, mitigate, transfer, or avoid the risk. Without ownership, risk scoring becomes documentation rather than management.
NIST Risk Management Framework
The NIST Risk Management Framework gave the post its main structure. I was using it as a seven-step process for managing information security and privacy risk across organisations and systems. The original source tied it to NIST standards and to US federal information-security requirements such as FISMA.
I treated the framework as a cycle rather than a one-off checklist. The steps were prepare, categorise, select, implement, assess, authorise, and monitor.
Prepare
Prepare is the organisation-level setup work. Before choosing controls, the organisation needs roles, responsibilities, strategy, risk appetite, and a view of its current risk position.
The tasks I noted included:
- identifying risk-management roles;
- defining a risk-management strategy and how much risk the organisation is willing to tolerate;
- assessing risk across the organisation;
- tailoring control baselines and cyber security profiles to the organisation;
- identifying common controls, such as shared access groups or permissions;
- prioritising systems by impact if compromised;
- defining a continuous monitoring strategy.
This step creates the operating context. It answers who is responsible, what the organisation cares about, and how risk decisions should be made consistently.
Categorise
Categorise is about understanding systems and information based on impact. A system that handles sensitive data, supports critical services, or affects many users should not be treated the same as a low-impact internal system.
The tasks I covered were:
- documenting system characteristics;
- categorising systems and information;
- reviewing and approving the categorisation.
This is where asset context starts to shape priority. Categorisation helps decide which systems need stronger controls, closer monitoring, or senior-level risk decisions.
Select
Select is where controls are chosen, tailored, allocated, and documented. The goal is to reduce risk to a level the organisation can justify without breaking the operation the system supports.
The tasks I noted included:
- selecting controls for the environment;
- tailoring controls to fit the organisation;
- allocating controls to systems, teams, or shared services;
- documenting planned control implementations;
- updating the monitoring strategy to reflect the planned controls;
- reviewing and approving the control plan.
The examples I used were practical: network intrusion detection, host intrusion detection, Active Directory permissions, file permissions, policies, and monitoring changes. The exact controls depend on the system, but the decision needs to be recorded.
Implement
Implement is where the selected controls are put into place. This can include firewall rules, file permissions, detection systems, access groups, configuration changes, and policy updates.
The implementation step also includes updating documentation when the plan changes. If a control is implemented differently from the original design, that difference needs to be recorded so assessment and monitoring are based on the real environment.
Assess
Assess checks whether the controls were implemented correctly and whether they are operating as intended.
The tasks I covered were:
- selecting an assessor or assessment team;
- creating and approving an assessment plan;
- assessing controls against the plan;
- producing assessment reports;
- identifying remediation actions;
- preparing plans of action and milestones based on findings.
This step links technical testing to governance. A control is not finished just because it exists. It has to be checked, reported on, and improved where gaps are found.
Authorise
Authorise is the accountability step. Senior decision-makers need enough information to decide whether the remaining security and privacy risk is acceptable.
The tasks I noted included:
- assembling an authorisation package;
- analysing and determining risk from system operation;
- choosing a risk response;
- making an authorisation decision;
- reporting deficiencies or control gaps that create significant risk.
This is where risk ownership becomes explicit. A technical team can identify and explain the risk, but the decision to operate with remaining risk has to be owned by the appropriate authority.
Monitor
Monitor is the ongoing step. Risk changes as systems, users, threats, controls, and business requirements change. The framework does not end after authorisation.
The monitoring tasks I covered were:
- watching for system and environmental changes;
- reassessing controls over time;
- responding to risk based on monitoring results;
- updating authorisation packages, plans, reports, and actions;
- reporting the security and privacy posture of systems;
- reviewing ongoing authorisation decisions;
- planning secure system disposal so sensitive information is not exposed.
Continuous monitoring is what keeps the risk decision alive. A control that worked when it was approved may stop being effective after a configuration change, business change, software update, new threat, or operational workaround.
From technical findings to decisions
The risk-management process gave me a cleaner way to think about technical findings. A finding is not automatically a priority just because it appears in a scan or report. It needs to be tied to an asset, an exposure path, a likely impact, existing controls, and an owner.
That changes the conversation. Instead of simply saying “this is vulnerable”, the better question is what the vulnerability allows, which business process or data is affected, how likely exploitation or failure is, what controls already reduce the exposure, and which response makes sense.
The possible responses are not always the same. A risk can be mitigated with controls, avoided by changing the approach, transferred through insurance or outsourcing, accepted by accountable management, or monitored while a longer-term fix is planned. Those decisions need evidence and review, not just a severity label.
For SOC and incident-response work, the same thinking applies. Alerts, incidents, and control failures need business context. Likelihood, impact, ownership, monitoring, and reassessment help turn technical signals into decisions that can be explained and defended.
Currentness note
This is a historical learning note based on a 2021 WordPress post and the NIST Risk Management Framework material I was studying at the time. It should not be treated as a complete governance, risk, and compliance guide.
Risk terminology, NIST guidance, security controls, and organisational expectations change over time. I would still carry forward the method: identify what is at risk, understand likelihood and impact, choose controls deliberately, assign ownership, document the decision, and keep monitoring as the environment changes.