TL;DR: A risk management methodology for IT teams should start with scope, data quality, and control ownership, because reactive risk handling amplifies incidents, compliance exposure, and operational disruption, according to Zluri’s guide. The real test is whether risk work is tied to identity governance, SaaS access, and continuous monitoring rather than treated as a periodic paperwork exercise.
NHIMG editorial — based on content published by Zluri: Security & Compliance How To Create A Risk Management Methodology?
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
Questions worth separating out
Q: How should security teams build identity risk into a risk management methodology?
A: Security teams should treat identity as a core risk dimension, not a separate technical checklist.
Q: Why do SaaS and identity risks often belong in the same assessment model?
A: Because SaaS often creates the identities, permissions, and delegation paths that later become the attack route.
Q: What do organisations get wrong when they use qualitative risk matrices for access risk?
A: They often rate the application in isolation and miss the reach of the underlying identity.
Practitioner guidance
- Add identity scope to every risk assessment Require each assessment to list service accounts, API keys, privileged users, and delegated SaaS access tied to the asset.
- Score SaaS risk by access reach, not just application criticality Include hidden integrations, third-party connections, and dormant credentials in the severity rating.
- Build lifecycle checks into the risk methodology Link risk reviews to offboarding, rotation, and entitlement recertification so stale access is visible before it becomes an incident.
What's in the full article
Zluri's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step guidance for choosing between NIST RMF, ISO 27005, COBIT, OCTAVE, and similar methodologies
- The article's own example of using Zluri to surface SaaS risk, vendor risk, and access-related vulnerabilities
- A practical checklist for aligning risk methodology to organisational goals, data quality, and resource availability
- The article's FAQ section on core risk management principles and risk assessment models
👉 Read Zluri's guide to creating a risk management methodology for IT teams →
Risk management methodology for IT teams: what IAM teams miss?
Explore further
Risk methodology fails when identity is treated as an input instead of the control plane. The article correctly frames risk as cross-functional, but the governance mistake is to score applications without scoring the identities attached to them. In modern IT, service accounts, API keys, and delegated SaaS access are often the mechanism through which risk becomes real. Practitioners should treat identity exposure as a primary risk dimension, not a downstream technical detail.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
A question worth separating out:
Q: How do you know if a risk management methodology is actually reducing identity exposure?
A: You should see fewer unmanaged identities, faster offboarding, more complete access reviews, and a shrinking set of high-risk privileges over time. If the same exposed credentials and delegated accounts keep reappearing, the methodology is measuring risk but not changing behaviour. Effective governance leaves a visible reduction in identity blast radius.
👉 Read our full editorial: Risk management methodology for IT teams needs identity scope