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, not as the system that enables the other functions. The 2.0 revision also removes the "critical infrastructure" framing — 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 — 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. The tier progression is not driven by adding tools — it is driven by formalizing decision-making, governance cadence, and continuous monitoring.

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.

NIST CSF 2.0 on AWS: Implementation & Maturity Guide (2026)

NIST Cybersecurity Framework 2.0 is the most widely adopted cybersecurity framework outside of compliance certifications — a common language used by federal agencies, contractors, critical infrastructure operators, and commercial enterprises pursuing maturity rather than a badge. The 2.0 revision (published February 2024) added a sixth function — Govern — at the foundation, and is the version every implementation in 2026 should target.

This guide walks through operationalizing CSF 2.0 on AWS: mapping each function to AWS services, advancing through implementation tiers, and understanding the relationship to NIST SP 800-53, SP 800-171, and CMMC for organizations that need both the framework and a downstream certification.

Need help operationalizing NIST CSF on AWS? FactualMinds builds CSF programs for federal contractors, fintech, and critical infrastructure operators — including FedRAMP-adjacent workloads on AWS GovCloud. Talk to our security team.

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 is a governance problem, not a tooling problem. 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 — 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 and Verified Permissions with Cedar.

Detect (DE) — Continuous Monitoring and Anomaly Detection

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.

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

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.

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 — 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–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–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–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–8: Detect

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

Months 6–10: Respond

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

Months 8–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.

Get Started

If you’re a federal contractor, fintech under regulatory scrutiny, or a critical infrastructure operator, NIST CSF 2.0 is the organizing language for your security program. We help organizations build CSF programs that satisfy regulators, accelerate FedRAMP / CMMC pursuits, and integrate with downstream certifications like ISO 27001 and SOC 2.

Talk to our security team →

NIST Cybersecurity Framework 2.0 on AWS: Implementation & Maturity Guide

The Six CSF 2.0 Functions