Every engineering team knows where the bodies are buried. The service account with admin rights nobody remembers granting. The library two major versions behind. The one database with no tested restore.
Most of these never make it to anyone outside the team. They live in Slack threads, sprint retros and the back of someone's head. Then one of them breaks, and suddenly leadership wants to know why nobody raised it.
IT risk management is mostly about closing that gap. Not with heavy process, but by writing technical risks down in a way the rest of the business can understand and act on.
Why engineers should care about IT risk management
It is easy to see risk management as something compliance teams do to engineering. In practice, it is one of the few ways to get time and budget for the work engineers already know matters.
"We should upgrade this library" competes with feature work and usually loses. "There is a known vulnerability in a library that handles customer payment data, and it is two versions behind" gets a different response. Same problem, framed as a risk with a clear impact.
Start with a simple risk register
You do not need a framework to begin. A shared file with a consistent structure is enough. Here is a format that works well for engineering teams:
- id: RISK-014
title: Payment service depends on an unsupported library version
description: >
The payments API uses a library version that no longer receives
security patches. A newly disclosed vulnerability could expose
card transaction data.
owner: payments-team
likelihood: 3 # 1 (rare) to 5 (almost certain)
impact: 5 # 1 (minor) to 5 (severe)
score: 15
controls:
- WAF rule blocking the known exploit pattern
- Weekly dependency scan in CI
action: Upgrade to the supported version in Q4 sprint 2
review_date: 2026-12-01
The fields that matter most are the owner, the score and the action. A risk with no owner is a complaint, not a risk.
Score risks the same way every time
Likelihood multiplied by impact is crude, but consistency matters more than precision. Agree on what each number means for your team. For example:
- Impact 5: customer data exposed, regulatory reporting likely, or a major outage on a revenue-critical service
- Impact 3: degraded service for some users, internal data exposed, recovery within a day
- Impact 1: minor inconvenience, no customer effect
Once the scale is agreed, scores stop being opinions and start being comparable across teams.
Common IT risks hiding in most stacks
If you are building your first register, these usually show up quickly:
- Over-privileged access. Service accounts and old employee accounts with more rights than they need.
- Unsupported dependencies. Libraries, runtimes or operating systems past end of life.
- Untested backups. Backups that exist but have never been restored.
- Single points of failure. One region, one engineer who understands a system, one vendor with no alternative.
- Expiring certificates and secrets. Easy to fix, painful when missed.
- Third-party APIs. External services your product depends on, with no monitoring or fallback.
Map risks to controls you already have
Most teams already run controls without calling them that. Code review, CI security scans, access reviews, on-call runbooks and change approvals are all controls.
Linking each risk to the controls that reduce it does two things. It shows auditors and security teams that the risk is managed, and it shows the team where a control is missing.
Use the telemetry you already collect
Key risk indicators sound like a compliance term, but engineers usually have the data already. A few examples:
- Number of dependencies with known critical vulnerabilities
- Days since the last successful restore test
- Count of accounts with admin access
- Certificates expiring in the next 30 days
Put these on an existing dashboard and set a threshold. When one crosses it, the related risk gets reviewed.
When a spreadsheet stops being enough
A YAML file or spreadsheet works well for one team. It starts to struggle when there are dozens of teams, hundreds of risks, auditors asking for evidence, and leadership wanting one view across IT and cyber risk.
At that point, many organisations move to dedicated IT risk management software that connects risks, controls, issues and evidence in one place. The tooling matters less than the habit, though. Teams that already keep a clean register make that transition far more easily.
A practical way to start this week
- Spend 30 minutes with your team listing the top ten technical risks you worry about.
- Give each one an owner, a score and one next action.
- Link each risk to any control that already reduces it.
- Pick two or three indicators you can track from existing tools.
- Review the list once a month in an existing meeting, not a new one.
None of this needs a new process. It just makes the risks you already know about visible to the people who decide priorities.
Final thoughts
Engineers are often the first to spot IT risk and the last to be asked about it. A simple, consistent register changes that. It turns "we should really fix this" into something the business can weigh, fund and track.
Disclosure: I work with MetricStream, one of the companies mentioned in this post.
Top comments (0)