IT risk management is a disciplined way of naming threats to services and data, assigning each one an owner, and deciding which are reduced and which are accepted knowingly. A team manager does not need a separate department for it: what they need is an asset inventory, a risk register, a treatment decision and a steady review rhythm.
Quick Overview
What you’ll learn:
- What belongs in a risk register and what is merely a defect list
- What a register looks like when nobody is dedicated to maintaining it
- Which risk-analysis duty the NIS2 directive actually imposes
- Which review rhythm keeps a register current rather than archival
Who this article is for:
- IT team managers and technical leads with no risk function behind them
- People accountable for compliance and service continuity in a mid-size company
- Service owners who have to sign off on accepting a risk
Reading time: 7 minutes
What Gets Assessed: Assets, Not Tools
The first rollout mistake is starting from a list of threats. That list is endless and grows faster than any team can read it. The starting point is an inventory of what genuinely has to be protected: services, data, privileged accounts, supplier integrations. Only a named asset can carry a loss scenario, and without a scenario there is nothing to assess.
The second mistake is mixing the risk register with a defect list. An unpatched library in a single service is a vulnerability — an item for engineers and scanning tools. It becomes a risk only once a sentence says what happens to the service and who bears the consequence: “losing access to the HR system for a day stops payroll.” The first is closed by a ticket; the second needs an owner’s decision.
The distinction looks like paperwork and decides who reads the register. A register full of vulnerabilities is read by the administrator alone. A register written in the language of service impact is read by the board — and that is the precondition for anything following from it.
A Register You Can Actually Maintain
The risk assessment guide published by csrc.nist.gov (SP 800-30 Rev. 1) frames assessment as the combination of likelihood and impact magnitude, with levels and assignment criteria written down explicitly. The likelihood-by-impact matrix is a description tool, not a verdict: its worth depends entirely on whether the level thresholds were named before the grid was filled in rather than fitted afterwards.
A register that survives inside a team carries, for every entry: a named asset, a loss scenario, a likelihood level, an impact level, a risk owner, a treatment decision and a review date. The risk management material collected on enisa.europa.eu gathers the methodologies and guidance used when choosing a scale; treatment itself comes down in practice to reduce, transfer, avoid or accept. Acceptance is a legitimate decision — provided it carries the signature of whoever bears the consequence, rather than the silence of the team.
What the minimal register leaves out matters just as much. There is no score calculated to a precision the inputs cannot support, because output precision will never exceed the quality of the input estimate. And there is no entry without an owner: a risk nobody holds will be neither reviewed nor closed.
Who Owns the Register: the Govern Function
Registers that die usually die of ownership rather than method, which is why the framework published as csrc.nist.gov CSF 2.0 is worth reading next to the assessment guide. Its Govern function covers exactly what a register needs in order to stay alive: a risk management strategy, named roles and responsibilities, policy, and oversight of the whole programme. The other functions — Identify, Protect, Detect, Respond and Recover — consume the register rather than maintain it.
What NIS2 Requires and Where Compliance Starts
The NIS2 directive — Directive (EU) 2022/2555, published on eur-lex.europa.eu — names risk analysis and information system security policies as the first of its risk-management measures in Article 21. The same act makes management bodies responsible for approving those measures and overseeing their implementation, which moves the register from the status of a technical document to that of board material.
For a team manager the consequence is narrow and practical: if the company is an in-scope entity, the risk register stops being good practice and becomes evidence. Evidence has a date, an author and a decision trail — precisely the fields described above as the minimum. Compliance does not begin with buying a tool; it begins with the organisation holding one current version of that record.
It is also worth separating the duty to run a process from the duty to report incidents, because compliance conversations tend to blur them together. The first is continuous and measured by review rhythm; the second is triggered by an event and measured by reaction time.
Review Rhythm and the Risk Owner’s Role
Registers die in two ways: reviewed too rarely to catch change, or reviewed so often that the team fills them in mechanically. A quarterly pass over the whole register, plus an ad-hoc review after any material change of architecture, supplier or data scope, is enough in a mid-size organisation.
Risk owner is a function, not a job title. It is whoever holds the budget and the mandate either to reduce the consequence or to accept it knowingly — usually the service owner or the head of an area, not the systems administrator. Where a CISO exists, their role is to run the process and challenge the estimates, not to absorb risks from their owners. Getting this wrong is the most common cause of registers in which every entry belongs to one person and therefore to nobody.
The last element of a rollout plan is the least technical one: language. If the register reads so that the deciding person understands it without a translator, the process starts shaping decisions. If it does not, it ends up as an annex to an audit file.
Read Also
- How to Effectively Manage Risk in Projects: Building Organizational Resilience — the project-side register and where it hands over to service ownership
- The NIS2 Directive: what do companies need to know and how to prepare? — scope and duties the register is meant to evidence
- IT security audits: how to prepare — an audit reads the risk register as evidence, so its checklist shows which fields and which review rhythm have to be in place before the auditor arrives
Build Your Skills
This topic is developed in the Risk management in information security and Strategic risk management in the organization courses. The first works at the information-security layer, the second on the register and board-level decisions. Contact us to match the scope to your area of accountability.
Frequently Asked Questions (FAQ)
How does IT risk management differ from project risk management?
In scope and horizon. Project risk concerns delivering scope on time and on budget, so it closes with the project. IT risk concerns the service that keeps running afterwards, and it has a maintenance owner. The registers often run in parallel; what joins them is the moment a project hands over the service and its risks together.
Which assessment method should a team start with?
A qualitative one, with named likelihood and impact levels. Quantitative methods make sense once historical data on outages and downtime cost exists; without that, a numeric result is false precision. Moving to quantitative assessment is easier from a working qualitative register than the other way round.
Do we need dedicated risk management software?
Not at the start. A register of a few dozen entries lives fine in a spreadsheet or in the issue tracker the team already uses. A dedicated tool earns its keep once there are multiple business units, an audit-trail requirement and links to a supplier register — in other words, when manual upkeep starts losing versions.
Can a team manager run the register without information security support?
They can run it, but they should not approve it alone. Maintaining the register is editorial and procedural work, well within a manager’s remit. Approving a risk acceptance needs the service owner’s mandate, and in a regulated organisation it also needs the management body to approve the measures.