Risk management is risk management

I have spent most of my career managing risk on delivering projects and products. On Agile programs and on older Waterfall ones, the same job was always there in the background. Work out what could go wrong, write it down, decide what to do about it, and keep an eye on it. RAID logs, risk registers, "the risks" on a pack, in Confluence, in Jira. Different names, same job.

So when I sat down to build a security risk assessment and a risk register for cirmp AI, the SOCI Act compliance tool I am building, I expected it to feel unfamiliar, and it did not. It was the same way of working I had used for years. Identify the risk, rate how likely it is and how much it would hurt, decide how to treat it, give it an owner, and review it. The structure was familiar. What was different was the rigour around it.

The same lifecycle and register, in two domains. Delivery on the left, security on the right.

The part that is the same

If you have run risk on a project, you already know most of this.

You start by listing what could go wrong. Then you score each one, usually how likely it is against how bad the impact would be, and that gives you a rating. The high ones get attention, the low ones get watched. Each risk gets an owner, a treatment, and a place on a register you actually revisit, not a document you write once and forget.

The register has the same structure too. An ID, a description, a rating before you do anything, the action you are taking, the rating you expect afterwards, who owns it, and where it sits in the queue. In delivery we talked about the risk before and after mitigation. In security it is called inherent and residual. Same idea, different word.

And it fails the same way in both worlds. The moment a risk register becomes a one-off document that nobody opens again, it stops being risk management and turns into paperwork. I have watched that happen on delivery programs for years. Security is no different.

The part that is different

In delivery, the thing you are assessing is usually scope, schedule, budget, dependencies, a vendor who might slip. In security, you are assessing threats and weaknesses, the ways someone could get in and what they could reach once they did. And that someone matters. A delivery risk does not usually have a person deliberately trying to make it happen. A security risk often does. You are not only managing chance, you are managing a deliberate attacker.

The frameworks are more formal. On the delivery side I used RAID logs, steering committees, and risk-based backlog ordering. On the security side there is a stricter set of references, ISO 27005 and NIST SP 800-30 for the method, the ACSC Information Security Manual for the controls, and for critical infrastructure the CIRMP hazard domains.

Likelihood is judged differently too. On a project I would weigh up experience and a bit of judgement. In security, likelihood leans on threat information, how exploitable a weakness is, and whether attackers are using it right now. There are whole feeds and scores for that (CVSS, EPSS, the known-exploited lists), which is more precise than judging a vendor on a hunch.

And the impact is bigger. A delivery risk costs time, money, scope, maybe reputation. A security risk can mean a data breach, a clinical system offline, patient safety, legal exposure, and a board signature on the line. In a regime like CIRMP, the risk work goes in front of the board and the regulator, not just a steering committee.

What I took from it

A few things stuck with me:

• The structure is the same. If you can run a delivery risk register, you can run a security one. Do not let the jargon convince you otherwise.
• As I have been reading ISO 27005, NIST, and the ISM, I reckon the discipline of actually reviewing the register matters more than the frameworks. A simple register you actually review beats a detailed one nobody opens.
• The real addition in security is the deliberate attacker and the need for evidence. You are managing someone who is trying, and you have to be able to prove what you did about it.
• Security likelihood is less of a guess. Use the threat information, do not rely on guesswork.
• A good template does half the work. So here is one.

The template

I have put together a blank Security Risk Assessment and Risk Register template, the same structure I used on cirmp AI, stripped back to an empty version you can fill in. It has the method, the likelihood and impact scales, the rating bands, and the register columns ready to go. Download it here.

It also lives in my open template repo on GitHub, sk-cyber-templates, which is MIT licensed and free to use. I will add more there as I build them.

Use it for a security review, or borrow the register for your next delivery program. It works in both.

If you run risk, in delivery or in security, I would love to know where the two feel the same to you, and where they are different. What is the one column on your register you would never drop?