Skip to content

NIST Cybersecurity Framework v2.0

Best for: Federal contractors and agencies must align 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
RenewalNo fixed cycle; continuous improvement
ScopeAll organizations; six functions: Govern, Identify, Protect, Detect, Respond, Recover

🏛 National Institute of Standards and Technology (NIST), U.S. Department of Commerce · NIST CSF v2.0 (Feb 2024) Official source →

Get Started

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

What Compliance.tf Covers vs. What You Handle

  • What Compliance.tf automates

    • Certificate and Key Management: Five controls cover 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.
    • 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. Four controls in total, mapping to PR.AA-01 through PR.AA-05.
    • Encryption at Rest: Checks Athena workgroup encryption configuration. The full benchmark includes additional controls for S3, EBS, RDS, and other storage services, building a broader encryption-at-rest posture under PR.DS-01.
    • Infrastructure Resilience: Three controls verify that Auto Scaling groups span multiple AZs, use capacity rebalancing, and attach ELB health checks. Maps to RC.RP-01 and PR.IR-01.
    • 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.
    • 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.

  • What you handle

    • Certificate and Key Management: 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: 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: 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: 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: Log retention periods, alerting thresholds in your SIEM, incident escalation workflows, and cross-service log correlation for threat detection.
    • Account 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

Data Protection and Encryption (PR.DS) (3 controls)

Expired or failed ACM certificates are an immediate flag; they indicate broken TLS in production. RSA keys below 2048 bits fail the minimum key length requirement under PR.DS-02. Certificate transparency logging gives auditors a verifiable record of issued certificates when they are validating PR.DS-01 and PR.DS-02 evidence.

RSA certificates managed by ACM should use a key length of at least 2,048 bits compliance.tf module ACM certificates should have transparency logging enabled compliance.tf module Athena workgroups should be encrypted at rest

Identity and Access Management (PR.AA) (3 controls)

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.

API Gateway methods authorizer should be configured API Gateway routes should specify an authorization type API Gateway V2 authorizer should be configured

Logging and Continuous Monitoring (DE.CM) (2 controls)

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.

API Gateway stage logging should be enabled AppSync graphql API logging should be enabled compliance.tf module
Additional Controls (125)

AWS Backup (1)

Backup plan min frequency and min retention check

AWS CloudTrail (4)

At least one enabled trail should be present in a region CloudTrail trails should be integrated with CloudWatch logs CloudTrail trail logs should be encrypted with KMS CMK CloudTrail trail log file validation should be enabled

AWS CodeBuild (2)

CodeBuild projects should have logging enabled CodeBuild project S3 logs should be encrypted

AWS Database Migration Service (3)

DMS endpoints for Redis OSS should have TLS enabled DMS endpoints should use SSL DMS replication instances should not be publicly accessible compliance.tf module

AWS IAM (1)

IAM password policies for users should have strong configurations

AWS KMS (1)

KMS CMK rotation should be enabled compliance.tf module

AWS Lambda (1)

Lambda functions should restrict public URL compliance.tf module

AWS Systems Manager (1)

SSM parameters encryption should be enabled compliance.tf module

Amazon CloudFront (3)

CloudFront distributions should require encryption in transit compliance.tf module CloudFront distributions access logs should be enabled compliance.tf module CloudFront distributions should use custom SSL/TLS certificates compliance.tf module

Amazon CloudWatch (3)

CloudWatch alarm should have an action configured compliance.tf module CloudWatch alarm action should be enabled compliance.tf module Log group retention period should be at least 365 days compliance.tf module

Amazon CloudWatch Logs (1)

Log group encryption at rest should be enabled compliance.tf module

Amazon DocumentDB (1)

AWS DocumentDB clusters should have an adequate backup retention period

Amazon DynamoDB (4)

DynamoDB table should have deletion protection enabled compliance.tf module DynamoDB table should be encrypted with AWS KMS compliance.tf module DynamoDB table should have encryption enabled compliance.tf module DynamoDB table point-in-time recovery should be enabled compliance.tf module

Amazon EBS (3)

Attached EBS volumes should have encryption enabled compliance.tf module EBS snapshots should be encrypted EBS volume encryption at rest should be enabled compliance.tf module

Amazon EC2 (5)

EC2 instance detailed monitoring should be enabled compliance.tf module EC2 instances should not have a public IP address compliance.tf module EC2 instances should use IMDSv2 compliance.tf module EC2 launch templates should use Instance Metadata Service Version 2 (IMDSv2) compliance.tf module EC2 transit gateways should have auto accept shared attachments disabled

Amazon ECR (2)

ECR repositories should have image scan on push enabled compliance.tf module ECR private repositories should have tag immutability configured compliance.tf module

Amazon ECS (1)

ECS task definitions should not share the host's process namespace compliance.tf module

Amazon EFS (2)

EFS file system encryption at rest should be enabled compliance.tf module EFS file systems should be encrypted with CMK compliance.tf module

Amazon ElastiCache (4)

ElastiCache Redis cluster automatic backup should be enabled with retention period of 15 days or greater compliance.tf module ElastiCache for Redis replication groups should be encrypted at rest compliance.tf module ElastiCache for Redis replication groups should be encrypted with CMK compliance.tf module ElastiCache for Redis replication groups should be encrypted in transit compliance.tf module

Amazon Kinesis (3)

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

Amazon MSK (1)

MSK clusters should be encrypted in transit among broker nodes compliance.tf module

Amazon Neptune (5)

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

Amazon OpenSearch Service (3)

OpenSearch domains should have encryption at rest enabled compliance.tf module OpenSearch domains should use HTTPS compliance.tf module OpenSearch domains node-to-node encryption should be enabled compliance.tf module

Amazon RDS (11)

RDS clusters should have deletion protection enabled compliance.tf module RDS DB clusters should be encrypted at rest compliance.tf module RDS DB clusters should be configured for multiple Availability Zones compliance.tf module RDS DB instance and cluster enhanced monitoring should be enabled compliance.tf module RDS DB instance backup should be enabled compliance.tf module RDS DB instances backup retention period should be greater than or equal to 7 compliance.tf module RDS DB instances should have deletion protection enabled compliance.tf module RDS DB instance encryption at rest should be enabled compliance.tf module RDS DB instance multiple az should be enabled compliance.tf module RDS DB instances should not use public subnet compliance.tf module RDS DB instances should prohibit public access compliance.tf module

Amazon Redshift (9)

AWS Redshift clusters should have automatic snapshots enabled compliance.tf module AWS Redshift should have automatic upgrades to major versions enabled compliance.tf module Redshift cluster encryption in transit should be enabled compliance.tf module Redshift cluster audit logging and encryption should be enabled compliance.tf module AWS Redshift enhanced VPC routing should be enabled compliance.tf module AWS Redshift clusters should be encrypted with KMS compliance.tf module AWS Redshift should have required maintenance settings compliance.tf module Redshift clusters should have Multi-AZ deployments enabled compliance.tf module Redshift clusters should prohibit public access compliance.tf module

Amazon S3 (21)

S3 access points should have block public access settings enabled S3 buckets access control lists (ACLs) should not be used to manage user access to buckets compliance.tf module S3 bucket cross-region replication should be enabled compliance.tf module S3 bucket default encryption should be enabled compliance.tf module S3 bucket default encryption should be enabled with KMS compliance.tf module S3 buckets should have event notifications enabled compliance.tf module S3 buckets should have lifecycle policies configured compliance.tf module S3 bucket logging should be enabled compliance.tf module S3 bucket MFA delete should be enabled compliance.tf module S3 bucket ACLs should not be accessible to all authenticated user compliance.tf module S3 bucket object lock should be enabled compliance.tf module S3 buckets object logging should be enabled S3 bucket policy should prohibit public access compliance.tf module S3 bucket cross-account permissions should be restricted compliance.tf module S3 buckets should prohibit public read access compliance.tf module S3 buckets should prohibit public write access compliance.tf module S3 buckets with versioning enabled should have lifecycle policies configured compliance.tf module S3 bucket versioning should be enabled compliance.tf module S3 Multi-Region Access Points should have block public access settings enabled S3 public access should be blocked at account level compliance.tf module S3 public access should be blocked at bucket levels compliance.tf module

Amazon SNS (1)

SNS topics should be encrypted at rest compliance.tf module

Amazon SQS (2)

AWS SQS queues should be encrypted at rest compliance.tf module SQS queues should be encrypted with KMS CMK compliance.tf module

Amazon VPC (1)

VPC subnet auto assign public IP should be disabled compliance.tf module

Elastic Load Balancing (7)

ELB application and classic load balancer logging should be enabled compliance.tf module ELB application load balancer deletion protection should be enabled compliance.tf module ELB application and network load balancers should only use SSL or HTTPS listeners compliance.tf module ELB classic load balancers should have cross-zone load balancing enabled compliance.tf module ELB classic load balancers should span multiple availability zones compliance.tf module ELB network load balancers should have TLS listener security policy configured compliance.tf module ELB listeners SSL/TLS protocol version should be checked compliance.tf module

Other (18)

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

  • NIST 800-53 Rev 5 — 🟢 High overlap (85%)

    NIST 800-53 Rev 5 is the detailed control catalog that CSF v2 references. CSF Categories and Subcategories map directly to 800-53 control families. Satisfying 800-53 covers most CSF v2 subcategories, though CSF v2's Govern function introduces organizational risk governance expectations that go beyond 800-53's PM family.

  • ISO/IEC 27001:2022 — 🟢 High overlap (70%)

    NIST published a formal crosswalk between CSF v2 and ISO 27001:2022 Annex A controls. The Protect and Detect functions align closely with ISO 27001 domains A.8 (Technology) and A.12 (Operations Security). ISO 27001 requires a certified ISMS, which CSF does not, so the governance models differ.

  • SOC 2 — 🟡 Medium overlap (55%)

    SOC 2 Trust Services Criteria (especially CC6 and CC7) partially overlap with CSF v2 Protect and Detect functions. SOC 2 focuses on service organization controls with formal audit attestation, while CSF v2 is a voluntary risk management framework. Controls for encryption, access management, and monitoring commonly satisfy both.

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.