NIST CSF 2.0, released in February 2024, made two structural changes that matter for cloud security practitioners. First, it added a sixth function — Govern (GV) — that didn't exist in CSF 1.1. Second, it significantly expanded the Protect (PR) function, particularly around identity management and access control. Both changes have direct implications for how cloud-native controls should be mapped and documented.
This isn't a comprehensive CSF 2.0 overview — NIST's own documentation covers the framework structure thoroughly. This is specifically about which of the new and revised subcategories have concrete cloud-native control analogs, and where the mapping is straightforward versus where it requires interpretation.
The Govern Function and Why It Matters for Cloud
CSF 1.1's five functions — Identify, Protect, Detect, Respond, Recover — were technology-agnostic but oriented toward operational security activities. The Govern function formalizes organizational security governance: policies, roles, oversight, and risk management processes. The six subcategories most relevant to cloud-native environments are GV.OC (Organizational Context), GV.RM (Risk Management), GV.RR (Roles and Responsibilities), GV.PO (Policy), GV.OV (Oversight), and GV.SC (Supply Chain Risk Management).
For teams running workloads on AWS or Azure, GV.PO — "Policies, processes, procedures, and practices to manage the organization's cybersecurity risks are established and communicated" — is the subcategory that maps most directly to the org-boundary control layer. An SCP that enforces a specific security requirement is only satisfying GV.PO if it reflects a documented policy that was deliberately set. An SCP that exists because someone copied a best-practice document without policy review is not.
The cloud-native analog for GV.PO isn't just "we have SCPs." It's: "our SCPs are derived from documented security requirements, attached to the correct org hierarchy, and reviewed on a cadence." That requires a policy lifecycle process that most teams don't have, and CSF 2.0 GV.PO is what calls it out explicitly.
GV.SC (Supply Chain Risk) has cloud-native relevance specifically for third-party integrations and marketplace tools. If you use a third-party CSPM tool, a marketplace AMI, or an AWS Partner solution, GV.SC asks whether you've assessed the security posture of that vendor. For cloud-native control mapping purposes, this translates to: are there SCPs or IAM conditions that limit what third-party tooling can access in your accounts?
Protect: PR.AA and Identity Management
CSF 2.0 introduced PR.AA (Protect: Identity Management, Authentication, and Access Control) as a more detailed successor to CSF 1.1's PR.AC. The key subcategories for cloud-native mapping:
PR.AA-01 — "Identities and credentials for authorized users, services, and hardware are managed by the organization." For AWS, this maps to IAM credential management: rotation policies, unused credential cleanup, and the SCP-level control that prevents IAM users from being created in production accounts (forcing federated access):
{
"Sid": "DenyIAMUserCreationInProd",
"Effect": "Deny",
"Action": [
"iam:CreateUser",
"iam:CreateLoginProfile",
"iam:CreateAccessKey"
],
"Resource": "*",
"Condition": {
"ArnNotLike": {
"aws:PrincipalArn": [
"arn:aws:iam::*:role/OrgSecurityAdmin"
]
}
}
}PR.AA-02 — "Identities are proofed and bound to credentials based on the context of interactions." This maps to MFA enforcement SCPs for sensitive IAM actions, discussed in the CC6 mapping article. For Azure, it maps to Conditional Access policies requiring MFA for management plane operations.
PR.AA-05 — "Access permissions, entitlements, and authorizations are defined in a policy, managed, enforced, and reviewed." This is the permission boundary + SCP combination. The "enforced" requirement is what SCPs address. The "reviewed" requirement is what IAM Access Analyzer addresses. Both are needed for PR.AA-05 coverage, but they're often managed by different teams with different cadences.
PR.AA-06 — "Physical access to assets is managed, monitored, and enforced commensurate with risk." For cloud-hosted workloads, physical access to AWS/Azure/GCP data centers is covered by the provider's own controls and compliance certifications. Teams reference these rather than implementing their own physical access controls. In a CSF 2.0 mapping document, PR.AA-06 should note: "AWS/Azure/GCP SOC 2 Type II certification covers physical access controls for cloud infrastructure. Organization is responsible for physical access to on-premises equipment." This is a clarification, not a gap.
Protect: PR.DS and Data Security
PR.DS (Protect: Data Security) has several subcategories with direct cloud-native analogs:
PR.DS-01 — "The confidentiality, integrity, and availability of data-at-rest are protected." For AWS, this maps to S3 encryption policies (SSE-KMS enforcement via bucket policy or SCP), EBS encryption by default (a per-account setting enforceable via SCP), and RDS encryption requirements. The SCP for enforcing EBS encryption by default across all accounts:
{
"Sid": "DenyUnencryptedEBSVolumes",
"Effect": "Deny",
"Action": "ec2:CreateVolume",
"Resource": "*",
"Condition": {
"Bool": {
"ec2:Encrypted": "false"
}
}
}PR.DS-02 — "The confidentiality, integrity, and availability of data-in-transit are protected." For AWS, this maps to requiring TLS for S3 bucket access (S3 bucket policy with aws:SecureTransport condition), enforcing HTTPS for CloudFront origins, and the SCP-level requirement that resources don't allow unencrypted endpoints. Azure maps this to Storage Account minimum TLS version policies.
PR.DS-10 — "The confidentiality, integrity, and availability of data-in-use are protected." This is the subcategory that CSF 2.0 added for runtime data protection. For most cloud workloads, the cloud-native analog is memory encryption via confidential computing instances (AWS Nitro Enclaves, Azure Confidential Computing, GCP Confidential VMs). This is a newer and narrower control surface — not every team needs it, and mapping it as "not applicable" for standard workloads is accurate documentation.
Protect: PR.PS and Platform Security
PR.PS is another new subcategory structure in CSF 2.0, covering platform security — the security of the hardware and software infrastructure on which organizational assets run. The cloud-native mappings here are mostly provider-managed controls that organizations reference rather than implement:
PR.PS-01 — "Configuration management practices are established and applied." For cloud environments, this is Infrastructure as Code + pre-deploy policy gates. An SCP or CloudFormation Hook that prevents non-compliant configuration from deploying is a PR.PS-01 control. The evidence is the deployment gate itself, not a configuration management database.
PR.PS-04 — "Logs and other security data are generated and retained." For AWS, this maps to requiring CloudTrail to be enabled across all accounts (enforceable via SCP by denying cloudtrail:StopLogging and cloudtrail:DeleteTrail) and S3 server access logging and VPC Flow Logs. The SCP for protecting CloudTrail:
{
"Sid": "ProtectCloudTrailIntegrity",
"Effect": "Deny",
"Action": [
"cloudtrail:StopLogging",
"cloudtrail:DeleteTrail",
"cloudtrail:UpdateTrail",
"cloudtrail:PutEventSelectors"
],
"Resource": "*",
"Condition": {
"ArnNotLike": {
"aws:PrincipalArn": [
"arn:aws:iam::*:role/OrgSecurityAdmin"
]
}
}
}What CSF 2.0 Doesn't Map Cleanly
Several CSF 2.0 subcategories don't have clean cloud-native control analogs, and trying to force the mapping creates documentation that's technically inaccurate.
GV.OV (Oversight) — "The results of organization-wide cybersecurity risk management activities and performance against established cybersecurity-related expectations are used to inform, improve, and adjust the risk management strategy." This is a governance and reporting function. AWS Security Hub, Azure Security Center, and GCP Security Command Center provide the data that feeds this function, but they're not implementations of it. GV.OV requires humans making risk decisions. The cloud tools provide inputs to those decisions.
RS.MA (Respond: Incident Management) subcategories require documented runbooks, incident response plans, and exercises. These are organizational processes, not cloud configurations. The cloud-native control contribution to RS.MA is automation of response actions (AWS Systems Manager Automation, Azure Logic Apps, GCP Cloud Functions triggered by Security Command Center findings), but the process layer is out of scope for cloud control mapping.
RC.RP (Recover: Incident Recovery Plan Execution) has no cloud-native control mapping — it's an operational plan that may use cloud capabilities (backup restoration, failover) but isn't itself a cloud control.
Being precise about what cloud-native controls actually cover — and documenting the gaps explicitly — is more defensible than a mapping table that claims everything maps to something. CSF 2.0 reviewers, whether internal or external, will notice when a mapping is a stretch.
Building the Mapping Document
A practical CSF 2.0 cloud-native control mapping document has four columns: CSF subcategory ID, subcategory description (abbreviated), cloud control(s) that address it, and coverage status (Covered / Partial / Not Applicable / Gap). The "Partial" and "Gap" rows are the ones that drive remediation work.
For the Govern function, most subcategories will be "Partial" because they require both technical controls and organizational processes. The cloud control handles the technical half; the process documentation handles the other half. Documenting both in the same mapping table — with links to the relevant process documentation — is what makes the mapping credible.
CSF 2.0 is a framework, not a standard. There's no certification to achieve. But it's increasingly referenced in contracts, RFPs, and regulatory guidance. Having a defensible, accurate mapping of what your cloud-native controls actually cover — and where your real gaps are — is more valuable than a comprehensive-looking table that doesn't hold up to scrutiny.