TL;DR: The NIST Cybersecurity Framework 2.0 organizes cyber risk around Govern, Identify, Protect, Detect, Respond, and Recover, with Profiles and Tiers turning that structure into measurable cloud security planning according to Orca Security. Its real value for identity teams is that it exposes where IAM evidence, cloud posture, and governance reporting still fail to line up.
NHIMG editorial — based on content published by Orca Security: NIST CSF guidance for cloud security and identity governance
Questions worth separating out
Q: How should security teams map IAM controls to the NIST CSF in cloud environments?
A: Start by linking identity controls to CSF outcomes such as Govern, Protect, Detect, and Respond at the workload and account level.
Q: Why do cloud IAM programmes struggle to use CSF as a governance model?
A: They often treat the framework as a reporting checklist instead of a way to show ownership, scope, and evidence.
Q: How can organisations tell whether CSF alignment is real or just documentation?
A: Look for evidence that Profiles are built from live inventory, access data, and monitored cloud activity rather than policy statements alone.
Practitioner guidance
- Tie CSF Profiles to real identity data Build Current and Target Profiles from cloud inventory, access entitlements, session logs, and data classification so the framework reflects actual workload behaviour, not policy intent.
- Separate enterprise and provider responsibilities Document where your organisation owns identity configuration, key management, and data protection, then map each responsibility explicitly to the cloud shared responsibility model.
- Measure identity blast radius in cloud Track how many accounts, workloads, and sensitive datasets each privileged identity can reach, and use that metric to prioritise remediation before control counts alone.
What's in the full article
Orca Security's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step CSF mapping examples for cloud inventory, logging, and identity controls across AWS, Azure, and GCP
- Detailed explanation of Core, Tiers, and Profiles for teams that need to build reporting artefacts
- Practical cloud alignment examples showing how unified posture data supports governance evidence and remediation tracking
- Frequently asked questions on CSF mandatory status, maturity interpretation, and cloud implementation pitfalls
👉 Read Orca Security's analysis of NIST CSF 2.0 in cloud environments →
NIST CSF in cloud security: what IAM teams still miss?
Explore further
CSF alignment becomes hollow when identity evidence is not scoped to real cloud workload behaviour. The framework is outcome-based, but outcomes are only meaningful when the organisation can prove which identities can reach which assets, data, and sessions. If Current and Target Profiles are built from generic policy language instead of operational access evidence, the programme reports compliance without demonstrating control. The practitioner lesson is that identity governance must be tied to runtime reality, not abstract control claims.
A few things that frame the scale:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared with nearly 1 in 4 for securing human identities.
A question worth separating out:
Q: What is the difference between Implementation Tiers and Profiles in NIST CSF?
A: Implementation Tiers describe how consistently risk management is performed, while Profiles describe the current and desired cybersecurity outcomes for a defined scope. Tiers help frame governance rigor, but Profiles expose the concrete gaps that drive remediation. Teams need both, but they answer different questions and should not be used interchangeably.
👉 Read our full editorial: NIST CSF 2.0 shows where cloud identity governance still breaks