NIST Cybersecurity Framework v1.1
Deprecated Framework
This framework has been superseded by NIST Cybersecurity Framework v2.0. Organizations should migrate to version 2.0, which was released in February 2024 with an additional Govern function and enhanced guidance on supply chain risk management.
Best for: Federal contractors and subcontractors demonstrating a cybersecurity risk management program aligned with NIST guidance. Organizations in critical infrastructure sectors (energy, financial services, healthcare, transportation) that reference the CSF in regulatory filings or board-level risk reporting. Companies preparing for NIST 800-171 or CMMC assessments often use CSF v1.1 as a baseline. Note: CSF v2.0 supersedes this version, but many active assessment programs remain tied to v1.1.
🏛 National Institute of Standards and Technology (NIST), U.S. Department of Commerce · NIST CSF v1.1 (Apr 2018, superseded by v2.0) Official source →
Get Started
module "..." {
source = "nistcsfv11.compliance.tf/terraform-aws-modules/<module>/aws"
version = "<version>"
}
What Compliance.tf Covers vs. What You Handle
What Compliance.tf automates
- Encryption at Rest: Checks encryption configuration on API Gateway cache stages and backup recovery points. apigateway_stage_cache_encryption_at_rest_enabled and backup_recovery_point_encryption_enabled confirm that data-at-rest encryption is active on covered services.
- Encryption in Transit: Flags ACM certificates expiring within 30 days and API Gateway stages missing SSL certificates. Controls: acm_certificate_expires_30_days and apigateway_rest_api_stage_use_ssl_certificate.
- Network and Instance Hardening: Verifies that WAF web ACLs are attached to API Gateway stages and that launch configurations enforce IMDSv2, disable public IPs by default, and restrict metadata hop limits. Covers autoscaling_launch_config_requires_imdsv2 and apigateway_stage_use_waf_web_acl.
- Backup and Recovery: Confirms backup plan retention meets the 35-day minimum, that recovery point manual deletion is disabled, and that recovery points have not expired prematurely. Covers backup_plan_min_retention_35_days and backup_recovery_point_manual_deletion_disabled.
- High Availability and Resilience: Checks that Auto Scaling groups span multiple availability zones with health check integration, deploy multiple instance types, and that CloudFront distributions have origin failover configured.
- Logging and Monitoring: Validates API Gateway stage logging, X-Ray tracing on REST API stages, and SNS notifications on CloudFormation stacks. Covers apigateway_stage_logging_enabled and apigateway_rest_api_stage_xray_tracing_enabled.
What you handle
- Encryption at Rest: Define and document your encryption policy, manage KMS key rotation schedules, audit key access grants, and extend encryption coverage to services outside the scope of these controls (including application-level encryption).
- Encryption in Transit: Enforce minimum TLS version requirements (TLS 1.2+), configure certificate auto-renewal, and validate TLS on internal service-to-service communication paths not fronted by API Gateway.
- Network and Instance Hardening: Write and tune WAF rule sets, define security group and NACL policies, run penetration testing, and manage your vulnerability scanning program.
- Backup and Recovery: Set RPO and RTO targets per workload, run periodic recovery tests (tabletop and live), document recovery runbooks, and verify that backup data actually restores successfully.
- High Availability and Resilience: Capacity planning, chaos engineering exercises, failover procedures for stateful workloads, and cross-region disaster recovery testing where applicable.
- Logging and Monitoring: Build detection rules and alerting thresholds in your SIEM, staff a security operations function to triage alerts, and retain logs for the period your risk profile or regulatory obligations require.
Controls by Category
Detect: Security Continuous Monitoring (DE.CM) (3 controls)
The most frequent gap is not missing logging but logging that exists without feeding into alerting. Assessors check whether API activity reaches CloudWatch, whether distributed tracing gives request-level visibility, and whether infrastructure change notifications actually reach the security operations team.
Protect: Data Security (PR.DS) (2 controls)
Configuration snapshots, certificate inventory exports, and KMS key policies are the primary evidence set here. Expired or soon-to-expire ACM certificates, API stages transmitting without TLS, and unencrypted backup recovery points are the most common findings. Assessors also check that approved algorithms are in use, not just that encryption is nominally enabled.
Recover: Recovery Planning (RC.RP) (1 control)
The first thing an assessor asks for is documented RPO and RTO targets per workload, then checks that backup configurations actually enforce them. Core evidence includes AWS Backup plan definitions showing 35-day minimum retention, vault lock policies blocking manual deletion, and records of successful backup job completion. Organizations routinely fail on the deletion protection requirement, leaving recovery points exposed to insider threat or ransomware.
Additional Controls (133)
AWS CloudTrail (4)
AWS CodeBuild (4)
AWS Database Migration Service (1)
AWS IAM (2)
AWS KMS (1)
AWS Lambda (5)
compliance.tf module Lambda functions should be configured with a dead-letter queue compliance.tf module Lambda functions should be in a VPC compliance.tf module Lambda functions should restrict public URL compliance.tf module Lambda functions should use latest runtimes compliance.tf module AWS Secrets Manager (1)
Amazon CloudFront (6)
compliance.tf module CloudFront distributions should require encryption in transit compliance.tf module CloudFront distributions access logs should be enabled compliance.tf module CloudFront distributions should use SNI to serve HTTPS requests compliance.tf module CloudFront distributions should use custom SSL/TLS certificates compliance.tf module CloudFront distributions should have AWS WAF enabled compliance.tf module Amazon CloudWatch (3)
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)
Amazon DynamoDB (3)
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 DynamoDB Accelerator (1)
Amazon EBS (2)
compliance.tf module EBS volume encryption at rest should be enabled compliance.tf module Amazon EC2 (10)
compliance.tf module EC2 instance should have EBS optimization enabled compliance.tf module EC2 instances should have IAM profile attached compliance.tf module EC2 instances should be in a VPC compliance.tf module EC2 instances should not use key pairs in running state compliance.tf module EC2 instances should not have a public IP address compliance.tf module EC2 instances should not use multiple ENIs compliance.tf module EC2 instances should use IMDSv2 compliance.tf module Paravirtual EC2 instance types should not be used compliance.tf module EC2 transit gateways should have auto accept shared attachments disabledAmazon ECR (2)
compliance.tf module ECR private repositories should have tag immutability configured compliance.tf module Amazon ECS (3)
compliance.tf module ECS fargate services should run on the latest fargate platform version compliance.tf module ECS task definitions should not share the host's process namespace compliance.tf module Amazon EFS (4)
compliance.tf module EFS file systems should be encrypted with CMK compliance.tf module Amazon EKS (3)
compliance.tf module EKS clusters endpoint should restrict public access compliance.tf module EKS clusters should be configured to have kubernetes secrets encrypted using KMS compliance.tf module Amazon EMR (1)
Amazon ElastiCache (1)
Amazon Kinesis (1)
Amazon OpenSearch Service (7)
compliance.tf module OpenSearch domains should have encryption at rest enabled compliance.tf module OpenSearch domains should have fine-grained access control enabled compliance.tf module OpenSearch domains should use HTTPS compliance.tf module OpenSearch domains should be in a VPC compliance.tf module OpenSearch domains logs to AWS CloudWatch Logs compliance.tf module OpenSearch domains node-to-node encryption should be enabled compliance.tf module Amazon RDS (17)
compliance.tf module RDS clusters should have deletion protection enabled compliance.tf module IAM authentication should be configured for RDS clusters compliance.tf module RDS DB clusters should be configured for multiple Availability Zones compliance.tf module RDS database clusters should use a custom administrator username compliance.tf module RDS DB instance and cluster enhanced monitoring should be enabled compliance.tf module RDS DB instance automatic minor version upgrade 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 instances should have iam authentication enabled compliance.tf module Database logging should be enabled compliance.tf module RDS DB instance multiple az should be enabled compliance.tf module RDS database instances should use a custom administrator username 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 (10)
compliance.tf module AWS Redshift clusters should have automatic snapshots 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 AWS Redshift clusters should not use the default Admin username compliance.tf module Redshift clusters should not use the default database name compliance.tf module Redshift clusters should prohibit public access compliance.tf module Amazon S3 (19)
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 enabledS3 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 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)
Amazon SageMaker (4)
Amazon VPC (1)
Elastic Load Balancing (9)
compliance.tf module ELB application load balancer deletion protection should be enabled compliance.tf module ELB application load balancers should be configured with defensive or strictest desync mitigation mode compliance.tf module ELB application load balancers should be configured to drop HTTP headers compliance.tf module Application Load Balancer should be configured to drop invalid http headers compliance.tf module ELB application and network load balancers should only use SSL or HTTPS listeners compliance.tf module Application and Network Load Balancer listeners should use secure protocols to encrypt data in transit 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 Other (6)
compliance.tf module The default stateless action for Network Firewall policies should be drop or forward for full packets compliance.tf module Related Frameworks
Frequently Asked Questions
Is NIST CSF v1.1 mandatory for my organization?
For most private-sector organizations, no. The CSF is voluntary. It becomes effectively mandatory in specific contexts: federal agencies and contractors subject to Executive Order 13800, organizations in critical infrastructure sectors where regulators reference the CSF (e.g., FFIEC, NERC CIP crosswalks), and companies whose customers or partners require CSF alignment in contract language. If none of those apply, the CSF is still widely used as a common language for communicating cybersecurity risk to boards and executives.
Should I adopt CSF v1.1 or migrate to v2.0?
If you are starting fresh, use v2.0. It was published in February 2024 and adds the Govern function, which addresses organizational governance gaps that v1.1 left implicit. If you have an existing v1.1 program, plan a transition within 12 to 18 months. NIST provides a subcategory mapping to ease migration, and most v1.1 work carries forward. The gap is primarily in governance and supply chain controls.
How long does a CSF assessment take?
For a mid-size organization doing this for the first time, expect 4 to 8 weeks, depending on how many systems are in scope and whether you have an existing control inventory. The process means defining your Current Profile (where you are), your Target Profile (where you need to be), and a gap analysis between the two. There is no formal certification. Organizations doing this for regulatory reporting or board presentations often bring in a third-party assessor, which adds roughly 2 to 4 weeks.
How do CSF 'Tiers' differ from 'Profiles'?
Tiers (1 through 4) describe the maturity of your risk management practices, from Partial (Tier 1) to Adaptive (Tier 4). They are not levels to climb sequentially. Profiles describe the alignment of your cybersecurity activities to business requirements, risk tolerance, and available resources for specific CSF subcategories. Use Profiles to capture current state and target state. Tiers characterize how your organization manages risk overall. An assessor will ask for both, but Profiles are the operational artifact you will maintain and update.
What evidence do I need to demonstrate CSF alignment in AWS?
At minimum: AWS Config rule evaluation results or equivalent policy-as-code scan outputs covering each subcategory, CloudTrail logs demonstrating continuous monitoring (DE.CM), IAM policies and access reviews for PR.AC, backup configuration and restore test records for RC.RP, and an incident response plan with tabletop exercise results for RS.RP. Running the compliance.tf NIST CSF v1.1 benchmark produces a control-level report that maps directly to subcategories, which most assessors accept as technical evidence alongside your policy documentation.