NIST Cybersecurity Framework v1.1
Deprecated
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.
| Mandatory? | Voluntary — widely adopted across sectors |
|---|---|
| Who validates? | Self-assessment; optional third-party |
| Renewal | No fixed cycle; continuous improvement |
| Scope | Critical infrastructure and all sectors; five core functions |
| Governing body | 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
Point the module source at the NIST Cybersecurity Framework v1.1 endpoint and pin a version range you reviewed:
module "..." {
source = "nistcsfv11.compliance.tf/terraform-aws-modules/<module>/aws"
version = "<version>"
}nistcsfv11.compliance.tf lists every NIST Cybersecurity Framework v1.1 module with its versions, inputs and outputs.
What compliance.tf covers and what you handle
| Area | Compliance.tf automates | You handle |
|---|---|---|
| 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. | 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 | 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. | 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 | 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. | Write and tune WAF rule sets, define security group and NACL policies, run penetration testing, and manage your vulnerability scanning program. |
| 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. | 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 | 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. | Capacity planning, chaos engineering exercises, failover procedures for stateful workloads, and cross-region disaster recovery testing where applicable. |
| 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. | 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
99 of 139 mapped controls are Enforced by compliance.tf modules at terraform plan. The other 40 are Mapped only: NIST Cybersecurity Framework v1.1 lists them, no compliance.tf module checks them.
Detect: Security Continuous Monitoring (DE.CM)
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)
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)
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.
| Control | Status |
|---|---|
| Backup plan rules should retain recovery points for at least 35 days | Mapped |
Additional controls (133)
AWS CloudTrail (4)
AWS CodeBuild (4)
AWS Database Migration Service (1)
| Control | Status |
|---|---|
| DMS replication instances should not be publicly accessible | Enforced |
AWS IAM (2)
AWS KMS (1)
| Control | Status |
|---|---|
| KMS CMK rotation should be enabled | Enforced |
AWS Lambda (5)
AWS Secrets Manager (1)
| Control | Status |
|---|---|
| Secrets Manager secrets should be encrypted using CMK | Enforced |
Amazon CloudFront (6)
Amazon CloudWatch (3)
Amazon CloudWatch Logs (1)
| Control | Status |
|---|---|
| Log groups should have encryption at rest enabled | Enforced |
Amazon DynamoDB (3)
Amazon DynamoDB Accelerator (1)
| Control | Status |
|---|---|
| DynamoDB Accelerator (DAX) clusters should be encrypted at rest | Mapped |
Amazon EBS (1)
| Control | Status |
|---|---|
| Attached EBS volumes should have encryption enabled | Enforced |
Amazon EC2 (10)
Amazon ECR (2)
Amazon ECS (3)
Amazon EFS (4)
Amazon EKS (3)
Amazon EMR (1)
| Control | Status |
|---|---|
| EMR cluster Kerberos should be enabled | Mapped |
Amazon ElastiCache (1)
Amazon Kinesis (1)
| Control | Status |
|---|---|
| Kinesis streams should have server side encryption enabled | Mapped |
Amazon OpenSearch Service (7)
Amazon RDS (17)
Amazon Redshift (10)
Amazon S3 (19)
Amazon SNS (1)
| Control | Status |
|---|---|
| SNS topics should be encrypted at rest | Enforced |
Amazon SageMaker (3)
Amazon VPC (3)
Elastic Load Balancing (9)
Other (6)
Related frameworks
| Framework | Control overlap | Note |
|---|---|---|
| PCI DSS v4.0 | High 82% | |
| NIST Cybersecurity Framework v2.0 | High 69% | |
| HIPAA Omnibus Rule 2013 | High 68% |
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 under 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. Compliance.tf control pages list the CSF subcategories each control maps to, which helps you assemble that technical evidence alongside your policy documentation.