---
title: NIST Cybersecurity Framework 2.0 on AWS: Implementation & Maturity Guide
description: NIST CSF 2.0 on AWS: Govern + six functions, tiers, 800-53/171/CMMC. July 2026 Tier-3 checklist.
url: https://www.joinhorizon.co/blog/nist-csf-2-0-aws-implementation-guide/
datePublished: 2026-04-27T00:00:00.000Z
dateModified: 2026-10-28T00:00:00.000Z
author: nash-ogden
category: Security & Compliance
tags: nist-csf, nist, compliance, frameworks, cmmc, governance, security, aws
---

# NIST Cybersecurity Framework 2.0 on AWS: Implementation & Maturity Guide

> NIST CSF 2.0 on AWS: Govern + six functions, tiers, 800-53/171/CMMC. July 2026 Tier-3 checklist.

**NIST CSF 2.0** (published **February 2024**) remains the 2026 default organizing language for cybersecurity outcomes: six functions with **Govern** as the foundation, then Identify, Protect, Detect, Respond, Recover. As of **July 2026**, implementations should target 2.0, not 1.1.

**First-party benchmark (illustrative plan below):** many orgs move Tier 1/2 → **Tier 3 (Repeatable)** in ~12 months when Govern cadence exists. Tools alone stall at Tier 2.

**Reproduce this:** [CSF 2.0 Tier-3 checklist](https://www.joinhorizon.co/examples/architecture-blog-2026/nist-csf-2/csf20-tier3-checklist.md)

**Counter-case:** there is **no** NIST CSF certification badge. Use ISO 27001 / SOC 2 / CMMC for external attestation; CSF organizes outcomes.

> [Contact](https://www.joinhorizon.co/contact-us/) for CSF programs on AWS / GovCloud.

## The six CSF 2.0 functions

CSF 2.0 organizes outcomes into six functions:

| Function                | Question it answers                                                |
| ----------------------- | ------------------------------------------------------------------ |
| **Govern** (NEW in 2.0) | How are cybersecurity risk management decisions made and overseen? |
| **Identify**            | What assets, risks, and dependencies do we need to protect?        |
| **Protect**             | How do we prevent or limit the impact of cyber events?             |
| **Detect**              | How do we discover that something happened?                        |
| **Respond**             | How do we contain and act on what we detected?                     |
| **Recover**             | How do we restore operations and improve from what we learned?     |

The functions are concurrent, not sequential. A mature program operates all six continuously.

## Govern (GV): the 2.0 addition

The Govern function recognizes that cybersecurity stagnation comes from weak governance more than from tooling. It has six categories: Organizational Context (GV.OC), Risk Management Strategy (GV.RM), Roles, Responsibilities, and Authorities (GV.RR), Policy (GV.PO), Oversight (GV.OV), and Cybersecurity Supply Chain Risk Management (GV.SC).

### Operationalizing Govern on AWS

| CSF Subcategory                                | What you need                                | AWS / org evidence                              |
| ---------------------------------------------- | -------------------------------------------- | ----------------------------------------------- |
| GV.OC-01 Organizational mission                | Documented mission and cyber risk in context | Board / leadership docs                         |
| GV.RM-01 Risk strategy approved                | Risk appetite, tolerance, and methodology    | Signed risk strategy doc                        |
| GV.RR-02 Cybersecurity roles assigned          | Documented org chart with security roles     | RACI for AWS Org accounts                       |
| GV.PO-01 Policies established and communicated | Information security policy + sub-policies   | Policy library, training records                |
| GV.OV-01 Cybersecurity strategy reviewed       | Quarterly leadership review                  | Management review minutes                       |
| GV.SC-04 Suppliers known                       | Third-party inventory with risk tier         | Vendor register, SBOM, AWS Marketplace tracking |

Govern is largely organizational evidence: minutes, signed policies, training rosters, and a vendor register. AWS contributes by being a documented supplier (AWS Artifact provides AWS's compliance attestations for your supply chain register).

## Identify (ID): asset, risk, and dependency visibility

Identify is about knowing what you have. On AWS, this means continuous inventory.

| CSF Subcategory                                  | AWS service                                                 | What it does                                             |
| ------------------------------------------------ | ----------------------------------------------------------- | -------------------------------------------------------- |
| ID.AM-01 Hardware inventory                      | AWS Config, Resource Explorer                               | Real-time inventory of all AWS resources across accounts |
| ID.AM-02 Software inventory                      | Inspector v2, Systems Manager Inventory                     | Package and library inventory with CVE mapping           |
| ID.AM-03 Data flows                              | VPC Flow Logs, Network Access Analyzer                      | Traffic analysis between resources                       |
| ID.AM-04 External systems                        | AWS Marketplace tracking, IAM Identity Center external IdPs | Third-party integrations                                 |
| ID.AM-05 Resource prioritization                 | Resource tags, Cost Allocation Tags                         | Criticality classification                               |
| ID.RA-01 Asset vulnerabilities identified        | Inspector v2, GuardDuty                                     | Continuous CVE and threat scanning                       |
| ID.RA-05 Threats and vulnerabilities prioritized | Security Hub, Inspector risk scoring                        | CVSS + KEV + reachability                                |

**Tagging is the underpinning.** Without consistent tags (`environment`, `data-classification`, `owner`, `criticality`), nothing in Identify scales. Use AWS Organizations Tag Policies to enforce required tags.

## Protect (PR): safeguards

Protect is the largest function, with controls covering identity, awareness, data, infrastructure, and platform integrity.

| CSF Subcategory                        | AWS services                                              |
| -------------------------------------- | --------------------------------------------------------- |
| PR.AA-01 Identities issued and managed | IAM Identity Center, IAM, Cognito                         |
| PR.AA-03 Access permissions managed    | IAM policies, IAM Access Analyzer, Verified Permissions   |
| PR.AA-05 Authentication strength       | MFA enforced, IAM password policies, FIDO2 keys           |
| PR.AT-01 Personnel awareness           | Annual security training, phishing simulations            |
| PR.DS-01 Data at rest protected        | KMS, S3 encryption, EBS encryption, RDS encryption        |
| PR.DS-02 Data in transit protected     | ACM (TLS), VPC endpoints, PrivateLink                     |
| PR.DS-10 Sensitive data identified     | Macie, custom data identifiers                            |
| PR.IR-01 Network integrity protected   | VPC, Security Groups, Network Firewall, Shield, WAF       |
| PR.PS-01 Configuration management      | Config conformance packs, IaC pipelines                   |
| PR.PS-04 Logging implemented           | CloudTrail, CloudWatch Logs, VPC Flow Logs, Security Lake |
| PR.PS-06 Software updated              | Systems Manager Patch Manager, Inspector                  |

For a deep dive on the IAM side, see [AWS IAM best practices for least-privilege](https://www.joinhorizon.co/blog/aws-iam-best-practices-least-privilege-access-control/) and [Verified Permissions with Cedar](https://www.joinhorizon.co/blog/amazon-verified-permissions-cedar/).

## Detect (DE): continuous monitoring and anomaly detection

![Architecture diagram of GuardDuty sending a finding through EventBridge to a ticket system](../../assets/images/blog/nist-csf-2-0-aws-implementation-guide-detect.webp)

_Figure: incident declaration in the article's Detect mapping. GuardDuty findings reach EventBridge, which opens the ticket in the system you already use. The attack-sequence page rule is the incident-response article. The checklist files under the other NIST folder were left alone. [Open the draw.io source](https://www.joinhorizon.co/examples/architecture-blog-2026/nist-csf-2-0-aws-implementation-guide/detect.drawio)._

Detect is where AWS-native services do the heavy lifting.

| CSF Subcategory                                       | AWS service                                              |
| ----------------------------------------------------- | -------------------------------------------------------- |
| DE.CM-01 Networks monitored                           | VPC Flow Logs analysis, GuardDuty, Network Firewall logs |
| DE.CM-02 Physical environment monitored               | Inherited from AWS (Artifact reports)                    |
| DE.CM-03 Personnel activity monitored                 | CloudTrail data events, IAM Access Analyzer              |
| DE.CM-06 External service provider activity monitored | CloudTrail Lake, third-party SaaS logging                |
| DE.CM-09 External actor anomalies detected            | GuardDuty (S3 protection, Malware Protection, EKS, RDS)  |
| DE.AE-02 Detected events analyzed                     | Security Hub, Security Lake (OCSF), Detective            |
| DE.AE-04 Adverse event impact estimated               | Detective behavior graphs, Security Hub severity         |
| DE.AE-08 Incidents declared                           | EventBridge → ServiceNow / Jira / PagerDuty integration  |

**Security Lake** is the strategic anchor. Centralizing OCSF-formatted logs means downstream tools (Athena, OpenSearch, third-party SIEM) all consume the same schema. See our [Security Lake guide](https://www.joinhorizon.co/blog/amazon-security-lake-ocsf/).

## Respond (RS): incident response

| CSF Subcategory                          | What it requires                                                  |
| ---------------------------------------- | ----------------------------------------------------------------- |
| RS.MA-01 Incident response plan executed | Documented IR runbook tested annually                             |
| RS.MA-04 Incidents triaged and validated | Severity scoring, containment SLAs                                |
| RS.AN-03 Forensic data analyzed          | CloudTrail Lake queries, Detective investigation                  |
| RS.CO-02 Internal stakeholders notified  | EventBridge → SNS / Slack notifications                           |
| RS.CO-03 External stakeholders notified  | Customer / regulator notification procedure (GDPR 72h, HIPAA 60d) |
| RS.MI-01 Incidents contained             | Automated containment via Lambda + Step Functions                 |
| RS.MI-02 Incidents eradicated            | Forensic snapshot, instance termination, credential rotation      |

The runbook needs to specify **who has authority**: for high-severity events, who can quarantine an EC2 instance, who can rotate root credentials, who can disable a federated identity. Document this with explicit IAM permissions and break-glass procedures.

## Recover (RC): restoration and lessons learned

![Architecture diagram of AWS Backup restoring a critical function that is then verified](../../assets/images/blog/nist-csf-2-0-aws-implementation-guide-recover.webp)

_Figure: recovery in the article. AWS Backup restores the critical function, and a restore test checks the result. Pilot Light, warm standby, and multi-region designs stay in the article as the patterns around this hop. [Open the draw.io source](https://www.joinhorizon.co/examples/architecture-blog-2026/nist-csf-2-0-aws-implementation-guide/recover.drawio)._

| CSF Subcategory                      | AWS service                                                |
| ------------------------------------ | ---------------------------------------------------------- |
| RC.RP-01 Recovery plan executed      | Documented BCP/DR plan, tested annually                    |
| RC.RP-04 Critical functions restored | AWS Backup, Pilot Light / Warm Standby / Multi-Region      |
| RC.RP-06 Restoration verified        | Restore tests with success criteria                        |
| RC.IM-02 Lessons learned applied     | Post-incident review, policy updates, control improvements |

Recovery is also about communications during an incident. Document customer status page updates, internal Slack channels, and escalation paths in the recovery plan, not the response plan.

## Implementation tiers: how to progress

CSF defines four implementation tiers describing rigor:

### Tier 1: Partial

- Risk management practices ad hoc and reactive
- Limited cybersecurity awareness
- No formal information sharing
- Cybersecurity policy is informal or undocumented

**On AWS:** Manual incident response, reactive misconfiguration fixes, no centralized logging, ad hoc IAM policies.

### Tier 2: Risk Informed

- Risk management practices approved by management but not consistently applied organization-wide
- Cybersecurity awareness exists at management level
- Limited information sharing with peers and partners

**On AWS:** GuardDuty enabled but findings not consistently triaged, Security Hub deployed but no playbooks, IAM policies reviewed periodically but not enforced.

### Tier 3: Repeatable

- Formal cybersecurity risk management policy approved
- Practices regularly updated based on changes in threats, technology, and mission
- Risk-informed policies applied consistently

**On AWS:** Documented runbooks, automated containment for known threats, Config conformance packs enforced, quarterly access reviews via Access Analyzer.

### Tier 4: Adaptive

- Continuous improvement informed by lessons learned and predictive indicators
- Cybersecurity is part of organizational culture and integrated with enterprise risk management
- Real-time information sharing

**On AWS:** Security Lake feeds threat intelligence into automated response, threat models updated quarterly, GenAI-driven anomaly detection, [automated remediation pipelines](https://www.joinhorizon.co/blog/from-reactive-to-proactive-automating-aws-security-remediation/).

**Most commercial organizations target Tier 3 within 18 months.** Tier 4 requires significant analyst capacity and is appropriate for high-target industries (defense, finance, healthcare) and regulated organizations under continuous attack.

## NIST SP 800-53, SP 800-171, and CMMC on AWS

For organizations needing more than the framework, meaning actual control language for federal or DoD work:

| Standard                  | Purpose                                     | AWS environment                                                                          |
| ------------------------- | ------------------------------------------- | ---------------------------------------------------------------------------------------- |
| **NIST SP 800-53 Rev 5**  | Federal information system controls (FISMA) | AWS GovCloud (US), FedRAMP High                                                         |
| **NIST SP 800-171 Rev 2** | Protecting CUI in non-federal systems       | AWS GovCloud (US), FedRAMP High preferred; AWS commercial regions for some Level 1 work |
| **NIST SP 800-172**       | Enhanced security for high-value CUI        | AWS GovCloud (US), additional controls                                                   |
| **CMMC Level 1**          | FAR 52.204-21 (17 basic safeguards)         | AWS commercial acceptable                                                                |
| **CMMC Level 2**          | NIST SP 800-171 Rev 2 (110 controls)        | AWS GovCloud (US) standard                                                               |
| **CMMC Level 3**          | NIST SP 800-172 enhancements                | AWS GovCloud (US), additional architecture                                               |

If you're a defense contractor handling CUI, you're working toward CMMC Level 2, and your AWS environment is GovCloud (US). The infrastructure controls inherit from FedRAMP High; you implement the application-layer 800-171 controls.

## Implementation plan: 12 months to Tier 3

A realistic CSF 2.0 program plan:

### Months 1 to 2: Govern foundation

- Adopt an information security policy approved by leadership
- Establish quarterly cybersecurity oversight cadence
- Document risk management methodology and risk appetite
- Stand up a vendor risk register

### Months 2 to 4: Identify

- Roll out organization-wide tagging policy
- Deploy AWS Config across all accounts
- Inspector v2 enabled organization-wide
- First risk assessment completed

### Months 3 to 6: Protect

- IAM Identity Center deployed; MFA enforced
- KMS strategy documented; encryption at rest 100%
- VPC standardization with Network Firewall where required
- Security awareness training rolled out

### Months 4 to 8: Detect

- GuardDuty across all accounts (Org-wide)
- Security Hub aggregation
- Security Lake stood up
- Critical alert routing to PagerDuty / Slack

### Months 6 to 10: Respond

- IR runbooks documented and tested
- Automated containment for top-5 finding types
- Tabletop exercise quarterly

### Months 8 to 12: Recover

- BCP/DR documented and tested
- Backup with cross-region replication
- Restore test logged quarterly

### Month 12: Tier assessment

Engage a third party to assess your current tier and identify the path to the next.

## What to do this week

1. Score current tier honestly (Partial → Adaptive).
2. Stand up Govern artifacts (roles, risk appetite, review cadence).
3. Map Detect/Respond to Org GuardDuty + Security Hub using the [Tier-3 checklist](https://www.joinhorizon.co/examples/architecture-blog-2026/nist-csf-2/csf20-tier3-checklist.md).

## What this post doesn't cover

Full SP 800-53 control-by-control FedRAMP packages and C3PAO assessment logistics.

[Talk to our security team](https://www.joinhorizon.co/contact-us/)

## FAQ

### What changed in NIST CSF 2.0 vs 1.1?
The biggest change is the addition of a sixth function, Govern, at the top of the framework. CSF 1.1 had five functions (Identify, Protect, Detect, Respond, Recover); CSF 2.0 adds Govern as the foundation. This reflects a real-world finding: organizations stagnate at Tier 2 (Risk-Informed) maturity because governance is treated as paperwork, which leaves the other functions without the system that enables them. The 2.0 revision also removes the "critical infrastructure" framing, so CSF is now explicitly intended for any organization. Categories were renumbered, examples were modernized to address cloud and supply chain, and the implementation tiers were sharpened.

### How does NIST CSF differ from NIST SP 800-53?
NIST CSF is a high-level outcomes framework: what you should achieve. NIST SP 800-53 is a control catalog: specific controls you can implement. CSF has ~108 categories and subcategories; SP 800-53 has ~1,000 controls organized into 20 control families. Federal agencies must comply with SP 800-53 (FISMA mandate). Federal contractors handling Controlled Unclassified Information (CUI) must comply with SP 800-171, which is a tailored subset of SP 800-53. Most commercial organizations use CSF as their organizing framework and reach into SP 800-53 for specific control language when needed. AWS has published a CSF mapping; AWS GovCloud (US) is FedRAMP High and supports SP 800-53 and 800-171 workloads.

### How does CMMC relate to NIST CSF and SP 800-171?
CMMC (Cybersecurity Maturity Model Certification) is the DoD program for certifying defense contractors. CMMC 2.0 has three levels. Level 1 (Foundational) maps to FAR 52.204-21 (17 basic safeguarding requirements). Level 2 (Advanced) maps directly to NIST SP 800-171 Rev 2 (110 controls) and is the level most contractors handling CUI need. Level 3 (Expert) adds NIST SP 800-172 controls for high-value programs. CMMC certification requires third-party assessment by a C3PAO. AWS GovCloud (US) is the standard environment for CMMC Level 2 workloads, and its FedRAMP High authorization satisfies the underlying infrastructure controls.

### What are NIST CSF implementation tiers and how do I progress through them?
CSF defines four tiers describing the rigor of cybersecurity risk management practices: Tier 1 (Partial): ad hoc, reactive, undocumented. Tier 2 (Risk Informed): practices documented but not consistently applied; risk awareness exists at management level. Tier 3 (Repeatable): formal policies, regular review, integrated risk management across the organization. Tier 4 (Adaptive): continuous improvement, lessons learned drive policy updates, real-time threat intelligence. Most organizations start at Tier 1 or 2 and target Tier 3 within 18 months. Tier progression comes from formalizing decision-making, governance cadence, and continuous monitoring, not from adding tools.

### Do I need NIST CSF certification?
There is no formal NIST CSF certification. CSF is a framework, not a certification standard. Some organizations get a third-party CSF assessment (a written report describing their tier and gaps) for sales or due-diligence purposes, but there is no badge equivalent to ISO 27001 or SOC 2. If you need a certification: ISO 27001 (international), SOC 2 Type II (US enterprise SaaS), or CMMC (DoD contractors) are the standards. CSF is the organizing framework you use internally; the certifications above provide external attestation.

---

*Source: https://www.joinhorizon.co/blog/nist-csf-2-0-aws-implementation-guide/*