How NIST CSF Maps to Real AWS and GCP Controls

The framework runs on six functions, 22 categories, and 106 subcategories, which is the level practitioners actually call "controls" day to day NIST CSF Controls and Categories: Complete Guide 2026 | Isora GRC.

The biggest structural shift is the new Govern function, 31 subcategories sitting at the center of the wheel, feeding strategy and oversight into the other five NIST CSF Controls and Categories: Complete Guide 2026 | Isora GRC. CSF 1.1 was written with critical infrastructure operators in mind NIST CSF Controls and Categories: Complete Guide 2026 | Isora GRC. CSF 2.0 drops that limit and says this applies to any organization, any size, any sector.

The three-level hierarchy isn't just bureaucratic nesting. Functions are the strategic buckets. Categories group related themes inside each function. Subcategories are the actual outcome statements, the things a cloud engineer configures a service to satisfy. CSF 2.0 stays outcome-based on purpose. It says what to achieve, never how. That's exactly why a translation layer into cloud-native services has to exist somewhere, because "achieve least privilege" doesn't tell anyone which IAM policy to write.

Two recent developments show the framework's reach growing rather than shrinking. CISA's Cross-Sector Cybersecurity Performance Goals 2.0 map directly onto all six CSF 2.0 functions and cite specific subcategories by name. And NIST published SP 800-61r3 in April 2025, the first finalized community profile under the new structure. Framework language works fine for governance committees and compliance reporting. Engineering teams need the next layer down: which services, which settings, which artifacts count as evidence. The 2025 Fortra State of Cybersecurity Survey found NIST CSF holds a 54% global adoption rate, the highest of any cybersecurity framework.

CSF 2.0's relationship to SP 800-53

CSF 2.0 defines the outcomes. SP 800-53 Rev. 5 defines the actual controls, things like AC-2, CM-6, AU-6, CA-7, that make those outcomes real. Run CSF alone and there's nothing enforceable to point to. Run 800-53 alone and there's no proof any of it lives in your actual cloud environment. The chain that closes the gap runs three layers deep: CSF sets the outcome, 800-53 sets the control, and cloud-native services generate the evidence.

AWS published its own CSF 2.0 whitepaper (updated January 2025) along with a downloadable service responsibility matrix covering 5 control families. Either way, the control families translate into recognizable products once you line them up.

The shared responsibility model makes all of this possible. AWS secures the cloud infrastructure itself; the customer owns everything tenant-side, meaning configuration, identity, data protection, and the evidence trail that proves any of it happened. Auditors don't sit down and check whether your framework alignment sounds good on paper. They ask who had access, why, when it changed, and what the log shows. That's the entire point of the mapping exercise. GCP maps most directly through SP 800-53 Rev. AU (Audit and Accountability) maps to Cloud Audit Logs and Cloud Logging on GCP, and to CloudTrail and CloudWatch Logs on AWS. CM (Configuration Management) maps to Security Command Center and OS Config on GCP, and to AWS Config on AWS. IA (Identification and Authentication) maps to Cloud Identity and IAM on GCP, and to AWS IAM and SSO on AWS. SC (System and Communications Protection) maps to VPC, Cloud Armor, and Certificate Manager on GCP, and to AWS Shield, WAF, and Certificate Manager on AWS. SI (System and Information Integrity) maps to Binary Authorization and Web Security Scanner on GCP, and to Amazon Inspector on AWS. Cloudaware.com identifies the CSA Cloud Controls Matrix (CCM) as a useful intermediate layer for cloud-native translation, mapping cloud-specific operational controls back to frameworks like NIST SP 800-53.

Govern: the function that runs across every other AWS and GCP control

Govern holds 31 subcategories spread across six categories: organizational context, risk management strategy, cybersecurity roles, policy, oversight, and supply chain risk management. SANS frames its addition as a real shift in how cybersecurity gets treated, moving it from a purely technical function into an enterprise governance responsibility, one that needs board-level engagement sitting alongside the SOC's day-to-day execution.

On AWS, a handful of services carry this weight. AWS Organizations sets up the account hierarchy and enforces policy boundaries through service control policies. AWS Service Catalog curates which services teams are even allowed to spin up. AWS Audit Manager automates compliance evidence collection and ships with a prebuilt NIST CSF v1.1 framework template, though Audit Manager is no longer open to new customers.

GCP covers the same ground differently. Organization policies enforce governance boundaries through the resource hierarchy: organization, then folder, then project. Security Command Center gives centralized visibility into policy posture across the whole org. Tagging strategy and how you structure accounts and projects end up being the practical, day-to-day expression of GV.OC, the organizational context subcategory.

The provider hands you the tooling, but Govern itself stays almost entirely the customer's job. Policy approval, vendor risk assessment, deciding who holds which role, none of that gets automated away. Supply chain risk management deserves particular attention here, since CSF 2.0 pulled it out of CSF 1.1's old ID.SC placement and elevated it into Govern as its own explicit set of subcategories (GV.SC). Any startup building on top of third-party APIs or outside ML model providers is already living inside this subcategory, whether or not anyone's labeled it that way. Organizations that prioritize Govern report up to 50% better compliance efficiency as regulatory pressure keeps climbing, though this vendor-reported figure should be treated as directional rather than gospel Leadership in 2026. The AWS CSF 2.0 whitepaper states that AWS Control Tower provides automated landing zones and guardrails as one of several services supporting the Govern function, with AWS Organizations recommended as the starting point for setting up the multi-account environment.

Identify: asset inventory and risk assessment in AWS and GCP

Identify splits into three categories: asset management (ID.AM), risk assessment (ID.RA), and improvement (ID.IM). The underlying logic is blunt: no control can be complete if you don't actually know what exists. In a multi-cloud setup, that means pulling assets from every provider into a single inventory rather than trusting each platform's own view in isolation.

AWS gives Identify a fairly deep bench. AWS Config tracks configuration inventory and flags compliance drift; its conformance packs map directly to CSF ID.AM subcategories and continuously evaluate CM-8, the asset inventory control. AWS Security Hub aggregates security findings across every account and region in the environment. Systems Manager maintains managed instance inventory. Amazon Inspector runs automated vulnerability assessment against EC2 instances and container images. Trusted Advisor rounds things out with resource utilization and security checks.

Security Command Center handles asset discovery and pulls risk findings together across the GCP organization. Cloud Asset Inventory keeps a continuous record of resources and policy configurations. OS Config covers OS-level inventory and patch state.

ID.AM is usually where cloud teams start, and the first real gaps appear there too: untagged resources nobody remembers creating, orphaned service accounts still holding permissions, data stores nobody documented. IAM belongs in this conversation as well, functioning as an ongoing process. Treated as a continuous control mapped to AC-2 and AC-6, least privilege is not a policy but a process, meaning roles, service accounts, and federated identities must be reviewed and reduced over time, with evidence found in identity change history and access review records. Data classification fits here too. Knowing what data exists and where it actually lives has to happen before the right Protect controls can even get chosen downstream. GCP services supporting Identify.

Protect: access control, encryption, and platform hardening mapped to native services

Start with access control. On AWS, that's IAM roles, service control policies, permission boundaries, and AWS SSO (now Identity Center) for federated access; the standard practice is least privilege, where each role only carries the permissions its task actually needs, checked through regular access reviews that strip out anything extra. GCP runs the same idea through Cloud Identity, IAM, Identity-Aware Proxy for context-aware access decisions, and VPC Service Controls to draw a boundary against data exfiltration.

Encryption and key management sit under PR.DS, the data security category. AWS KMS prices customer-managed keys at $1 per CMK per month, with cryptographic API calls running $0.03 per 10,000 calls as of 2025 pricing. The real decision here is architectural: native AWS KMS, bring-your-own-key with customer-supplied key material, or hold-your-own-key where the customer retains the key entirely, and each option carries its own sovereignty and compliance tradeoffs. For workloads that need hardware-backed key isolation, AWS CloudHSM offers dedicated FIPS 140-3 Level 3 hardware security modules. GCP covers the same spectrum with Cloud KMS and Cloud HSM, and customer-managed encryption keys (CMEK) are available across most of its storage and data services. None of this stops at encryption at rest, either. Key rotation and audit logging are part of the same evidence trail auditors expect to see.

Network and platform protection round out the picture. GCP answers with Cloud Armor for DDoS and WAF coverage, its own Certificate Manager, and VPC firewall rules. GCP's Binary Authorization enforces a policy that only trusted container images get deployed in the first place, while Security Command Center Premium handles continuous misconfiguration detection.

Resilience gets its own category, PR.IR. Network segmentation, multi-AZ architecture, and workload isolation aren't just good operational habits here. They're Protect-function controls in their own right, with their own evidence expectations. Protect (PR) covers access control, awareness and training, data security, platform security, and resilience across 5 categories in CSF 2.0, including PR.AA (Identity Management, Authentication, and Access Control). On AWS, this includes AWS Shield for DDoS protection, AWS WAF, AWS Certificate Manager for TLS provisioning, and Amazon Macie for sensitive data discovery in S3. On AWS, this includes CIS Benchmark conformance packs in AWS Config, with AWS Security Hub standards for CIS, PCI, and FSBP providing continuous scoring.

Detect: the AWS and GCP services that turn logs into findings

Detect covers two categories: continuous monitoring and adverse event analysis. This is the function where raw log volume either turns into something actionable or just piles up unread.

AWS runs this through a small stack of purpose-built services. GuardDuty applies machine learning across CloudTrail, VPC Flow Logs, and DNS logs to catch account compromise, crypto mining, and exfiltration patterns. Inspector, already doing work in Identify, also flags vulnerabilities on EC2 instances and container images. Security Hub pulls findings from GuardDuty, Inspector, Macie, and third-party tools into one normalized finding format. CloudTrail logs should be forwarded into the CloudWatch Logs pipeline and ingested into a SIEM, with CloudWatch alarms configured for anomalous patterns such as unexpected key deletion requests, unusual encryption volume spikes, failed Decrypt calls from unrecognized principals, and DisableKey events.

GCP's Detect stack runs on a similar logic. Cloud Audit Logs break out into Admin Activity, Data Access, System Event, and Policy Denied logs, mapping straight onto the AU control family. Security Command Center aggregates findings across misconfigurations, vulnerabilities, and active threats, and it lines up with CA-7, the continuous monitoring control. Google Security Operations, the product formerly known as Chronicle, works as a cloud-native SIEM built for log ingestion and threat detection at real scale. Cloud Logging serves as the central sink, exporting into BigQuery or Pub/Sub for teams running their SIEM elsewhere.

The failure pattern occurs the same way on both platforms. If assets, exceptions, identities, and findings aren't tied to live cloud state as things change, the team ends up reconstructing what happened after the fact, usually during the audit itself, which is the worst possible time to be doing archaeology. Detect controls only hold up under audit if log retention periods, review cadence, and clear ownership got defined ahead of time, not improvised afterward.

Respond and Recover: closing the loop with AWS and GCP automation

Respond covers four categories: incident management, analysis, mitigation, and reporting. Recover covers two: recovery planning and improvements, plus communication.

CloudWatch handles alarms, dashboards, and automated actions, and Lambda functions triggered by CloudWatch Events can execute containment steps such as isolating a compromised instance or revoking credentials. Systems Manager Incident Manager adds the structure around that automation: runbooks, escalation paths, and a documented process for what happens once an alarm fires.

That's the throughline across all six functions. Govern sets the policy, Identify inventories what's there, Protect locks it down, Detect watches for trouble, and Respond turns the watching into action. None of it works as a one-time project. Each function depends on the evidence the others produce, and the whole chain only holds together if someone's actually reviewing what the logs say, not just collecting them. AWS services supporting Respond.