Most organisations can run a risk assessment once. The real challenge is building the discipline to reassess critical systems and assets year after year, in a way that still produces meaningful results 12 months later. That is where the process usually falls apart.
Your second assessment should be easier because the foundation is already in place: the threats have been assessed, critical assets and dependencies mapped, risk appetite defined and previous decisions documented. The next cycle is therefore about reviewing what has changed — not rebuilding the assessment from scratch.
The instinct when starting risk analyses is to jump straight to assessing your systems: what could go wrong with the HR platform, the CRM, the file server? It's a reasonable instinct, and it's also why so many risk assessments stall before they finish.
A better starting point is to assess the threats themselves, once, for the organisation as a whole. Fire damage, cyber vandalism, user error — for each one, decide how likely it is and what it would do to confidentiality, integrity and availability if it happened. This becomes your threat catalogue, and every subsequent assessment draws from this information rather than starting from a blank page.
Don't do this alone. The organisations that get the most out of it bring in the people who actually know the threats — a CTO for technical vulnerability assessments and department heads for impact assessments — and work through the catalogue together. Skip categories that clearly don't apply yet, but leave them in the catalogue rather than deleting them; the moment you adopt a new tool, you'll want them back.
The payoff shows up in year two. As our Information Security Manager puts it:
“The first time, we went through it meticulously. Every year after that, we just ask: has anything changed? New threats? New systems? New ways of driving our business? It's a lot easier now.”
That's the entire point of a shared baseline — the hard thinking happens once, and every cycle after that is a review, not a rebuild.
Once the threat picture is in place, the next question is which assets to assess. That means listing your critical systems and vendors — not every single asset, just what is genuinely critical to the business, to the people whose data you hold, or to the wider operating environment. For a first pass, 10 to 15 assets are usually enough; scope creep here is the fastest way to stall a risk assessment process before it produces anything useful.
The part that's easy to skip is linking those assets together. A system rarely stands alone — it depends on a vendor, perhaps a network too, and the security of all three is connected. When you map those dependencies, risk starts flowing between assets automatically: a system with a genuinely low risk score can still be exposed because a vendor has a poor track record — and, as a result, a high risk score of its own. NorthGRC surfaces this as an inherited risk flag, so it's visible at a glance rather than buried in someone's memory of a supplier conversation from 18 months ago.
This is worth taking seriously. In KPMG's 2026 global survey on third-party risk management, only 18 % of organisations describe their third-party risk programmes as fully integrated with enterprise risk management, and just 15 % of risk leaders say they have high confidence in the data behind those programmes. Vendor risk that lives in a separate spreadsheet from the rest of your risk landscape is, in practice, vendor risk nobody is really watching.
Do this mapping properly once, and it stays largely intact: assets and vendors don't reshuffle every year, so next cycle you're checking the picture for changes rather than redrawing it from scratch.
A structured approach to assessing threats, assets and treatment doesn't have to be built from scratch.
→ Download the free guide to risk management with ISO 27005.
Once you have decided which assets belong within scope, the next question is how deeply each one should be assessed. Even among your critical assets, not everything requires the same level of analysis.
A combined assessment, where you separately rate the impact and probability of a breach of confidentiality, integrity and availability, is the level most teams use for established systems. A threat-based assessment goes further by examining each relevant threat against the specific asset, producing a more detailed picture where the additional depth is justified.
The judgement call is knowing which systems earn the detailed version. A new IT purchase, or any system your organisation is about to depend on for the first time, is worth the full threat-based treatment before you commit. An established system you've reviewed for three years running probably doesn't need the same depth every single cycle.
Whichever level you choose, write down why. A comment explaining why probability was rated low, or why a vulnerability pushed impact higher than the default, is the difference between a risk treatment meeting that runs smoothly and one where nobody can remember what the original concern even was — and it's exactly what next year's reviewer will thank you for.
Risk evaluation is where assessments turn into decisions, and it goes faster when the decision criteria are set before the results come in. Setting a risk appetite — for instance, treating anything scored medium or below as acceptable — gives every assessment an automatic indication of whether it needs attention, without anyone having to re-argue the threshold for every asset.
If the risk exceeds what the organisation is willing to tolerate, it needs treatment.
Treatment is where the plan becomes concrete: create a task and delegate the responsibility so risks get revisited on a schedule rather than forgotten until the next incident. Tying that task into the planning system the rest of the organisation already uses means it doesn't become a side project that quietly stalls — and it leaves a paper trail that makes next year's assessment a status check rather than a fresh investigation.
Everything above is a methodology you could run in spreadsheets, and plenty of organisations do. What changes when it runs on a connected GRC platform is that the four stages stop being separate exercises loosely held together by a shared template.
NorthGRC ships with a built-in threat catalogue maintained by senior security consultants, giving you an expert-vetted baseline to tailor to your own environment rather than a blank list to start from scratch. Assets and vendors can be created manually, imported from Excel, or synced via an API from your CMDB. Once they're linked and assessed, inherited risk is calculated automatically rather than tracked in someone's head. The same risk landscape supports business impact, data-subject impact and societal impact side by side, so information security, data protection and operational technology teams work from one connected picture rather than three separate ones.
Risk treatment tasks flow straight into the planning module with owners, deadlines and notifications attached, and the reporting stage pulls from live assessment data rather than a static export. The report a board sees in month 12 reflects what was actually assessed, because the history lives in the platform, not scattered across someone's inbox and memory.
Seeing the whole cycle run end-to-end is easier to follow live than to describe in writing. Book a demo to watch a full walkthrough from the threat catalogue to a board-ready report.