NIST Cybersecurity Framework v2.0

ActiveCore framework

Best for: Federal agencies apply it under Executive Order 13800. Critical infrastructure operators (energy, healthcare, financial services, water) encounter it through sector regulations that reference CSF directly. Cyber insurers increasingly require maturity tier assessments during underwriting. Organizations already mapped to NIST 800-53 or ISO 27001 use CSF v2 for board-level reporting. No revenue or size threshold; the framework applies from small businesses to multinationals.

Mandatory?	Voluntary — widely adopted across sectors
Who validates?	Self-assessment; optional third-party
Renewal	No fixed cycle; continuous improvement
Scope	All organizations; six functions: Govern, Identify, Protect, Detect, Respond, Recover
Governing body	National Institute of Standards and Technology (NIST), U.S. Department of Commerce, NIST CSF v2.0 (Feb 2024). Official source

Get started

Point the module source at the NIST Cybersecurity Framework v2.0 endpoint and pin a version range you reviewed:

module "..." {
  source  = "nistcsf.compliance.tf/terraform-aws-modules/<module>/aws"
  version = "<version>"
}

nistcsf.compliance.tf lists every NIST Cybersecurity Framework v2.0 module with its versions, inputs and outputs.

Enforce 87 NIST Cybersecurity Framework v2.0 controls with one registry endpoint change.

Start free trial Get started

What compliance.tf covers and what you handle

Area	Compliance.tf automates	You handle
Certificate and Key Management	Covers ACM certificate status (expiration within 30 days, failed state, pending validation), RSA key length (minimum 2048 bits), and certificate transparency logging. These map directly to PR.DS-01 and PR.DS-02.	Defining and documenting your certificate lifecycle policy, setting up automated renewal workflows, and managing any private CA hierarchies outside ACM.
API Authorization and Access Control	Validates that API Gateway v1 and v2 routes and methods have authorization types configured and that authorizers (Lambda, Cognito, IAM) are attached. Maps to PR.AA-01 through PR.AA-05.	Designing authorization logic within Lambda authorizers or Cognito user pool policies, reviewing least-privilege scopes and token expiration settings, and maintaining periodic user access reviews.
Encryption at Rest	Checks Athena workgroup encryption configuration.	Selecting and managing KMS keys (CMK vs. AWS-managed), defining key rotation schedules, and documenting data classification policies that determine which data requires encryption.
Infrastructure Resilience	Verifies that Auto Scaling groups span multiple AZs, use capacity rebalancing, and attach ELB health checks. Maps to RC.RP-01 and PR.IR-03.	Writing and testing recovery runbooks, defining RTO/RPO targets, conducting tabletop exercises, and documenting business continuity plans that go beyond infrastructure configuration.
Audit Logging and Monitoring	Confirms API Gateway stage logging and AppSync field-level logging are enabled. Maps to DE.CM-01 and DE.CM-09 for continuous monitoring of network and application activity.	Log retention periods, alerting thresholds in your SIEM, incident escalation workflows, and cross-service log correlation for threat detection.
Account Governance	Checks that the AWS account belongs to an AWS Organizations structure. Maps to GV.OC-01 and GV.SC-01 for organizational context and supply chain governance.	Defining and enforcing Service Control Policies (SCPs), establishing an organizational unit hierarchy, and documenting governance roles and responsibilities per the Govern function requirements.

Controls by category

87 of 134 mapped controls are Enforced by compliance.tf modules at terraform plan. The other 47 are Mapped only: NIST Cybersecurity Framework v2.0 lists them, no compliance.tf module checks them.

Data Protection and Encryption (PR.DS)

Expired or failed ACM certificates are an immediate flag; they indicate broken TLS in production. RSA keys below 2048 bits weaken the protection of data in transit that PR.DS-02 covers. Certificate transparency logging gives auditors a verifiable record of issued certificates when they are validating PR.DS-01 and PR.DS-02 evidence.

Control	Status
ACM RSA certificates should use a key length of at least 2,048 bits	Enforced
ACM certificates should have transparency logging enabled	Enforced
Athena workgroups should be encrypted at rest	Mapped

Identity and Access Management (PR.AA)

The most common finding in this category is API Gateway methods left at authorization type NONE after a development stage gets promoted to production. Assessors want configuration exports showing the authorizer type (Cognito, Lambda, IAM) per route, and they will probe endpoints directly if the documentation looks incomplete.

Control	Status
API Gateway methods should require an authorizer	Mapped
API Gateway routes should require an authorization type	Enforced
API Gateway V2 routes should require an authorizer	Enforced

Logging and Continuous Monitoring (DE.CM)

DE.CM calls for continuous monitoring of events that could indicate a cybersecurity incident. API Gateway stages need both execution and access logging flowing to a centralized destination with defined retention. AppSync field-level logging is the mechanism assessors look for when evaluating detection coverage for unauthorized GraphQL query patterns.

Control	Status
API Gateway stages should have logging enabled	Mapped
AppSync GraphQL APIs should have field-level logging enabled	Enforced

Additional controls (126)

AWS Backup (1)

Control	Status
Backup plan rules should retain recovery points for at least 35 days	Mapped

AWS CloudTrail (4)

Control	Status
CloudTrail trails should have at least one enabled trail present in a region	Mapped
CloudTrail trails should be integrated with CloudWatch logs	Mapped
CloudTrail trails should have logs encrypted using a customer managed KMS key	Mapped
CloudTrail trails should have log file validation enabled	Mapped

AWS CodeBuild (2)

Control	Status
CodeBuild projects should have logging enabled	Mapped
CodeBuild projects should have S3 logs encrypted	Mapped

AWS Database Migration Service (3)

Control	Status
DMS endpoints for Redis OSS should have TLS enabled	Mapped
DMS endpoints should use SSL	Enforced
DMS replication instances should not be publicly accessible	Enforced

AWS IAM (1)

Control	Status
IAM password policies should have strong configurations	Mapped

AWS KMS (1)

Control	Status
KMS CMK rotation should be enabled	Enforced

AWS Lambda (1)

Control	Status
Lambda functions should restrict public URL	Enforced

AWS Systems Manager (1)

Control	Status
SSM parameters encryption should be enabled	Enforced

Amazon CloudFront (3)

Control	Status
CloudFront distributions should require encryption in transit	Enforced
CloudFront distributions access logs should be enabled	Enforced
CloudFront distributions should use custom SSL/TLS certificates	Enforced

Amazon CloudWatch (3)

Control	Status
CloudWatch alarms should have an action configured	Enforced
CloudWatch alarms should have action enabled	Enforced
CloudWatch log groups should have retention period of at least 365 days	Enforced

Amazon CloudWatch Logs (1)

Control	Status
Log groups should have encryption at rest enabled	Enforced

Amazon DocumentDB (1)

Control	Status
DocumentDB clusters should have an adequate backup retention period	Mapped

Amazon DynamoDB (4)

Control	Status
DynamoDB tables should have deletion protection enabled	Enforced
DynamoDB tables should have AWS KMS encryption enabled	Enforced
DynamoDB tables should have encryption enabled	Enforced
DynamoDB tables should have point-in-time recovery enabled	Enforced

Amazon EBS (2)

Control	Status
Attached EBS volumes should have encryption enabled	Enforced
EBS snapshots should be encrypted	Mapped

Amazon EC2 (5)

Control	Status
EC2 instances should have detailed monitoring enabled	Enforced
EC2 instances should not have a public IP address	Enforced
EC2 instances should use IMDSv2	Enforced
EC2 launch templates should use Instance Metadata Service Version 2 (IMDSv2)	Enforced
EC2 transit gateways should have auto accept shared attachments disabled	Mapped

Amazon ECR (2)

Control	Status
ECR repositories should have image scan on push enabled	Enforced
ECR private repositories should have tag immutability configured	Enforced

Amazon ECS (1)

Control	Status
ECS task definitions should not share the host's process namespace	Enforced

Amazon EFS (2)

Control	Status
EFS file systems should have encryption at rest enabled	Enforced
EFS file systems should be encrypted with CMK	Enforced

Amazon ElastiCache (4)

Control	Status
ElastiCache Redis clusters should have automatic backups enabled with a retention period of 15 days or greater	Enforced
ElastiCache for Redis replication groups should be encrypted at rest	Enforced
ElastiCache for Redis replication groups should be encrypted with CMK	Enforced
ElastiCache for Redis replication groups should be encrypted in transit	Enforced

Amazon Kinesis (3)

Control	Status
Kinesis firehose delivery streams should have server side encryption enabled	Mapped
Kinesis streams should be encrypted with CMK	Mapped
Kinesis streams should have server side encryption enabled	Mapped

Amazon MSK (1)

Control	Status
MSK clusters should require TLS for client-broker connections	Enforced

Amazon Neptune (5)

Control	Status
Neptune DB clusters should publish audit logs to CloudWatch Logs	Mapped
Neptune DB clusters should have automated backups enabled	Mapped
Neptune DB clusters should be configured to copy tags to snapshots	Mapped
Neptune DB clusters should have deletion protection enabled	Mapped
Neptune DB clusters should be encrypted at rest	Mapped

Amazon OpenSearch Service (3)

Control	Status
OpenSearch domains should have encryption at rest enabled	Enforced
OpenSearch domains should use HTTPS	Enforced
OpenSearch domains node-to-node encryption should be enabled	Enforced

Amazon RDS (11)

Control	Status
RDS clusters should have deletion protection enabled	Enforced
RDS DB clusters should be encrypted at rest	Enforced
RDS DB clusters should be configured for multiple Availability Zones	Enforced
RDS DB instances and clusters should have enhanced monitoring enabled	Enforced
RDS DB instance backup should be enabled	Mapped
RDS DB instances backup retention period should be greater than or equal to 7	Enforced
RDS DB instances should have deletion protection enabled	Enforced
RDS DB instance encryption at rest should be enabled	Enforced
RDS DB instances should have multiple AZ enabled	Enforced
RDS DB instances should not use public subnet	Enforced
RDS DB instances should prohibit public access	Enforced

Amazon Redshift (9)

Control	Status
Redshift clusters should have automatic snapshots enabled	Enforced
Redshift clusters should have automatic upgrades to major versions enabled	Enforced
Redshift cluster encryption in transit should be enabled	Enforced
Redshift clusters should have audit logging and encryption enabled	Enforced
Redshift clusters should have enhanced VPC routing enabled	Enforced
Redshift clusters should have KMS encryption enabled	Enforced
Redshift clusters should have required maintenance settings	Enforced
Redshift clusters should have Multi-AZ deployments enabled	Enforced
Redshift clusters should prohibit public access	Enforced

Amazon S3 (21)

Control	Status
S3 access points should have block public access settings enabled	Mapped
S3 buckets should not use ACLs for user access control	Enforced
S3 buckets should have cross-region replication enabled	Enforced
S3 buckets should have default encryption enabled	Enforced
S3 buckets should have default encryption enabled using KMS	Enforced
S3 buckets should have event notifications enabled	Enforced
S3 buckets should have lifecycle policies configured	Enforced
S3 buckets should have logging enabled	Enforced
S3 buckets should have MFA delete enabled	Mapped
S3 buckets should not be accessible to all authenticated users	Enforced
S3 buckets should have object lock enabled	Enforced
S3 buckets should have object logging enabled	Mapped
S3 buckets should have policies that prohibit public access	Enforced
S3 buckets should restrict cross-account permissions	Mapped
S3 buckets should prohibit public read access	Enforced
S3 buckets should prohibit public write access	Enforced
S3 buckets with versioning enabled should have lifecycle policies configured	Enforced
S3 buckets should have versioning enabled	Enforced
S3 Multi-Region Access Points should have block public access settings enabled	Mapped
S3 public access should be blocked at account level	Enforced
S3 public access should be blocked at bucket level	Enforced

Amazon SNS (1)

Control	Status
SNS topics should be encrypted at rest	Enforced

Amazon SQS (2)

Control	Status
SQS queues should have encryption at rest enabled	Enforced
SQS queues should be encrypted with KMS CMK	Enforced

Amazon VPC (3)

Control	Status
VPC security groups should not allow ingress from 0.0.0.0/0 to remote server administration ports (IPv4)	Mapped
VPC security groups should not allow ingress from ::/0 to remote server administration ports	Mapped
VPC subnet auto assign public IP should be disabled	Enforced

Elastic Load Balancing (7)

Control	Status
ELB application and classic load balancer logging should be enabled	Enforced
ELB application load balancer deletion protection should be enabled	Enforced
ELB application and network load balancer listeners should use ACM certificates	Enforced
ELB classic load balancers should have cross-zone load balancing enabled	Enforced
ELB classic load balancers should span multiple availability zones	Mapped
ELB network load balancers should have TLS listener security policy configured	Mapped
ELB listeners should use approved SSL/TLS protocol versions	Mapped

Other (18)

Control	Status
CloudFormation stacks should have notifications enabled	Mapped
Cognito identity pools should not allow unauthenticated identities	Mapped
Elasticsearch domains should have audit logging enabled	Mapped
Elasticsearch domains should require TLS 1.2 for connections	Mapped
ES domain encryption at rest should be enabled	Mapped
Elasticsearch domain error logging to CloudWatch Logs should be enabled	Enforced
Elasticsearch domain should send logs to CloudWatch	Mapped
Elasticsearch domain node-to-node encryption should be enabled	Mapped
FSx for OpenZFS file systems should be configured to copy tags to backups and volumes	Enforced
FSx for Lustre file systems should be configured to copy tags to backups	Enforced
Glue data catalog metadata encryption should be enabled	Mapped
Glue data catalog connection password encryption should be enabled	Mapped
Glue jobs bookmarks encryption should be enabled	Mapped
Glue jobs CloudWatch logs encryption should be enabled	Mapped
Glue jobs S3 encryption should be enabled	Mapped
MSK Connect connectors should be encrypted in transit	Mapped
Network Firewall policies should have default stateless action set to drop or forward for fragmented packets	Enforced
Network Firewall policies should have default stateless action set to drop or forward for full packets	Enforced

Framework	Control overlap	Note
ISO/IEC 27001:2022	Medium 59%
PCI DSS v4.0	Medium 58%
NIST Cybersecurity Framework v1.1	Medium 53%

Frequently asked questions

Is NIST CSF v2 mandatory for my organization?

For most private-sector organizations, no. CSF v2 is voluntary. Federal agencies must follow it under Executive Order 13800, and federal contractors may face contractual requirements to demonstrate CSF alignment. Several sector-specific regulators (FERC for energy, state insurance commissioners) reference CSF in binding rules. Even without a mandate, cyber insurers increasingly ask for CSF maturity tier assessments during underwriting.

What changed between CSF v1.1 and v2.0?

The addition of the Govern (GV) function is the biggest structural change. It raises cybersecurity governance, risk strategy, and supply chain risk management to a top-level function rather than distributing them across other categories. CSF v2 also added explicit measurement subcategories (GV.MT), dedicated supply chain risk management subcategories (GV.SC), and broadened applicability language beyond critical infrastructure to all organization types. The Informative References are now maintained online as a living catalog rather than a static appendix.

How do CSF v2 Tiers relate to compliance?

Tiers describe organizational maturity, not compliance levels. Tier 1 (Partial) means ad hoc risk management; Tier 4 (Adaptive) means risk decisions are data-driven and continuously refined. No specific tier is required. Your target should reflect your risk appetite, threat environment, and resource constraints. Auditors may ask you to document current and target tiers per function.

How do I map existing NIST 800-53 controls to CSF v2?

NIST maintains an online Reference Tool (https://csrc.nist.gov/projects/cybersecurity-framework/filters) with official mappings from CSF v2 subcategories to 800-53 Rev 5 controls. Export your 800-53 control inventory, then map each control to one or more CSF subcategories using the tool. Gaps typically surface in the Govern function (GV.OC, GV.RM, GV.SC), since those organizational governance requirements were not prominent in 800-53.

How long does a CSF v2 assessment take?

For a mid-size organization with an existing security program, a self-assessment typically runs 4 to 8 weeks, covering stakeholder interviews, evidence collection across all six functions, gap analysis, and target profile development. Third-party assessments add 2 to 4 weeks for report generation and review. The Govern function usually takes the most time; it requires documentation of board-level risk oversight, supply chain policies, and measurement programs that many organizations have not yet formalized.

Enforce 87 NIST Cybersecurity Framework v2.0 controls with one module source change.