Is risk assessment the whole process?

No. It informs responses, implementation, review, and continuing monitoring.

Can some risk be accepted?

Yes, through an informed decision by the appropriate authority under the organization's criteria.

Does a successful control test eliminate all risk?

No. It provides evidence about a defined scenario and conditions; remaining risks and changes still require review.

AI Glossary / Data governance and quality / Intermediate

IT risk management

Definition

IT risk management is the ongoing process of identifying, assessing, responding to, and monitoring risks arising from an organization's use of information technology. It connects technical evidence with business objectives, accountable decisions, and follow-through. Responses may change an activity, reduce risk through controls, share some consequences, or accept remaining risk under defined authority. The objective is informed management of uncertainty, not a promise that every possible technology failure will be eliminated.

What it means

A risk assessment produces understanding; risk management turns that understanding into decisions and sustained action. A register of risks is useful only if owners, responses, deadlines, and review conditions are clear. IT risk management also extends beyond cybersecurity to operational reliability and technology delivery concerns. It should fit the organization's wider risk process so that technology decisions reflect business priorities rather than becoming a separate technical scoring exercise.

How it works

Establish the scope, objectives, decision criteria, and responsible roles. Identify meaningful scenarios, assess their likelihood and consequences, and evaluate existing controls. Select a response with an accountable owner and resources, then verify that the action has been implemented and works as intended. Reassess what remains, obtain the appropriate acceptance decision where needed, and monitor changes. Communicate material risks and dependencies to the level that can act. Repeat the cycle as systems, suppliers, and organizational needs evolve.

Three practical examples

Resilience planning: a team tests recovery for a critical service and addresses gaps against the business's interruption tolerance.
Supplier dependency: an organization evaluates how a provider outage would affect its operations and defines workable contingency arrangements.
AI release: a project assesses risks from data errors and unauthorized model changes, assigns controls and owners, and reviews the remaining exposure before deployment.

Think of it this way

Think of managing a journey by identifying hazards, choosing a route, preparing contingencies, and checking conditions along the way. A map of hazards alone does not complete the journey safely. The analogy is limited because organizational risks involve many owners and interconnected services, and accepting a risk may require authority beyond the person operating the technology.

Worked example

In an original simplified case, a team identifies that loss of a dataset could prevent a required model evaluation. It records the scenario, assigns an owner, and proposes a backup. The task is initially marked complete when the backup job succeeds. A restoration exercise then shows that the label dictionary was not included, so the recovered data cannot support the intended evaluation. The response is revised to cover the missing dependency and retested. The risk is reassessed only after that evidence is available. This example distinguishes implementing a control from demonstrating that it addresses the business consequence, and shows why residual risk cannot be inferred from a completed task checkbox.

Illustrative case study

Fictional example: Larch Retail maintains a risk register with several overdue actions but no named decision-makers. During a review, the organization assigns business owners, clarifies which decisions require escalation, and connects actions to a reporting schedule. Some responses are changed because the original proposals no longer fit the service. This invented case illustrates that risk management depends on governance and current evidence, not merely the existence of a periodically updated spreadsheet.

Common misconceptions and mistakes

Do not assume risk management is a one-time audit or a list of controls copied from a framework. Do not close a risk simply because an action was purchased or configured. Avoid delegating acceptance of major business consequences to someone without the appropriate authority. Also, sharing or insuring some financial consequences does not necessarily remove operational responsibilities or harm to people. Record the scope and limits of each response, and do not hide uncertainty behind a precise-looking score.

Business use

Effective IT risk management helps organizations make deliberate choices about investment, service design, and change. For AI projects, keep risk review connected to the system's purpose, data, users, dependencies, and potential consequences. Track whether agreed controls work in the deployed workflow and whether conditions have changed. Use concise reporting that identifies the decision needed, the evidence, and the accountable owner. Integrating technology risk with wider organizational priorities helps avoid both neglecting serious exposures and spending effort on low-value controls.

Check your understanding

A backup has been created, but restoration has never been tested. Is the data-loss risk necessarily resolved?

Answer: No. The organization needs evidence that the required information can be restored and used within the relevant constraints. A completed backup task is not the same as demonstrated recovery capability.

Related terms

Risk tolerance
risk register
risk owner
risk appetite
residual risk
control effectiveness
enterprise risk management

Learn next

take one risk scenario and trace it from identification to a decision and a testable response. Specify what evidence would justify changing its status and what event would trigger reassessment. Distinguish the person implementing a control from the person authorized to accept the remaining business risk.

Sources

Sources: NIST CSRC, risk management, https://csrc.nist.gov/glossary/term/risk_management , relevant definition consulted; NIST SP 800-39, https://csrc.nist.gov/pubs/sp/800/39/final , abstract read; NIST IR 8286 Revision 1, https://csrc.nist.gov/pubs/ir/8286/r1/final , overview and abstract read; ISACA, Optimizing Risk Response, https://www.isaca.org/resources/white-papers/optimizing-risk-response , publication summary excerpt consulted. Security guidance is applied as one part of broader IT risk management. Examples are original and do not prescribe a mandatory framework or legal compliance outcome.

Previous: IT risk Next: Item-item collaborative filtering