NIST 800-53 Compliant Terraform Modules
Enforced Before terraform apply

Access control, audit logging, system protection, configuration management. The NIST 800-53 controls that map to AWS resource configuration, enforced before terraform apply.

Federal agencies and their contractors use NIST 800-53 as the security baseline. If you sell to the US government or want FedRAMP authorization, this is where you start.

97

Mapped Controls

76 enforced by modules

372

Clauses

35

AWS Modules

No credit card or AWS account needed to start.

From the maintainer of terraform-aws-modules - 2B+ downloads.

IAM · RDS · S3 · VPC · ELB · EC2SOC 2 Type II reportAvailable on AWS Marketplace

Three Steps to NIST 800-53 Compliant Infrastructure

For terraform-aws-modules users, migration is a one-line change. Same workflow, same interface. Bringing your own modules? We can make those compliant too. Join the beta.

1

Change One Line

main.tf
module "s3" {
- source = "registry.terraform.io/..."
+ source = "nist80053.compliance.tf/..."
 
  bucket = "awesome-docs"
}

Browse NIST 800-53 modules at nist80053.compliance.tf →

2

Run Terraform Commands

terminal
$ terraform init
Initializing modules...
- module.s3 in nist80053.compliance.tf/...
Terraform has been successfully initialized!
$ terraform apply
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.
3

Compliance Enforced

AC-3(4) · Block Public Write
AU-9(2) · Public Access Blocked
SC-28(1) · KMS Encryption
SI-14(2) · Versioning + Lifecycle
SC-28(1) · Default Encryption
SC-8(1) · SSL Requests Only
AU-3 · Logging Enabled
CP-9 · Versioning Enabled

Controls with module coverage are enforced automatically. Enforced controls ship as compliant defaults; mapped controls without module coverage stay visible for your team.

Controls Mapped for NIST 800-53

97 controls mapped, 76 enforced by modules, across 372 clauses and AWS services

Enforced: the module configures this by default. Detected: mapped for visibility and evidence, not set by the module.

Enforced (61)Detected (105)
·
  • IAM password policies should have minimum length set to 14 or greater
  • IAM password policies should have strong configurations with minimum length of 8 or greater
  • IAM password policies should have strong configurations
  • IAM groups, users, and roles should not have any inline policies
  • IAM inline policy should not have administrative privileges
  • IAM policies should not allow full administrative privileges
  • IAM policies should not allow full '*' administrative privileges
  • IAM policy should not have statements with admin access
  • IAM root user should have MFA enabled for console access
  • IAM root user hardware MFA should be enabled
  • IAM root user MFA should be enabled
  • IAM root user should not have access keys
  • IAM user access keys should be rotated at least every 365 days
  • IAM user access keys should be rotated at least every 90 days
  • IAM users with access keys unused for 45 days or greater should be disabled
  • IAM users with console access should have MFA enabled
  • IAM users with console access unused for 45 days or greater should be disabled
  • IAM user MFA should be enabled
  • IAM user should not have any inline or attached policies
  • IAM policies should be attached only to groups or roles
  • IAM credentials unused for 45 days or more should be disabled
  • IAM user credentials that have not been used in 90 days should be disabled
  • IAM administrator users should have MFA enabled
  • Secrets Manager secrets should have automatic rotation enabled
  • Secrets Manager secrets should be rotated within a specified number of days
  • Secrets Manager secrets should be rotated as per the rotation schedule

Additional Controls

37 additional controls mapped for NIST 800-53

Enforced (15)Detected (22)

NIST 800-53 Scope: What We Handle vs. What You Own

compliance.tf handles the infrastructure configuration layer for NIST 800-53. Here is what it covers and what stays with your team.

compliance.tf Enforces for NIST 800-53

  • Infrastructure-level security controls (AC, AU, SC, CP, SI families)
  • NIST 800-53 Rev 5 control mapping with specific control IDs
  • Deployment-time evidence generation via AWS-native tools
  • Upstream module updates (terraform-aws-modules kept in sync)
  • Exception management with audit trail
  • Control documentation and security control mapping matrices

Your Team Still Handles for NIST 800-53

  • Risk assessment documentation (RA family)
  • Security planning and system security plans (PL family)
  • Contingency planning procedures (CP family - beyond backup config)
  • Personnel security and screening (PS family)
  • Awareness and training programs (AT family)
  • Incident response procedures (IR family)
  • Physical and environmental protection (PE family)

compliance.tf covers the NIST 800-53 technical controls that map to AWS resource configuration, primarily the AC, AU, SC, CP, and SI families. Organizational and procedural controls remain your team's responsibility.

Operational Rules (lifecycle blocks, tagging, instance restrictions) are also applied alongside NIST 800-53 compliance controls.

NIST 800-53 Audit Evidence - Built Into Your Workflow

Your auditor does not need to trust compliance.tf. Evidence comes from AWS-native tools they already accept.

Evidence your auditor already trusts

Every compliance.tf module enforces controls before terraform apply. When AWS Config, Security Hub, or Audit Manager evaluates your resources, they report clean findings because the controls are built into the modules, not bolted on after the fact.

  • AWS Config rules validate resource configuration continuously
  • Security Hub aggregates findings across accounts and regions
  • Audit Manager generates assessment reports mapped to NIST 800-53
  • Downloadable control mapping matrices for your auditor
evidence.json
{
  "framework": "NIST 800-53",
  "clause": "SC-28(1)",
  "control": "s3_bucket_default_encryption_enabled",
  "status": "COMPLIANT",
  "source": "AWS Config",
  "resource": "arn:aws:s3:::awesome-docs",
  "evaluated": "2026-08-14T10:30:00Z"
}

Prevention vs. Detection for NIST 800-53

compliance.tf prevents non-compliant deployments. Scanning tools detect them after the fact. Most mature programs use both.

DimensionIaC Scanning
Checkov / Trivy / Prowler
Compliance.tf
Prevents non-compliant configs before terraform applyNo (post-plan scan)Yes
Maps controls to framework clause IDsPartialYes
Produces auditor-accepted evidence (AWS-native)Scan reports onlyYes
Exception management with audit trailSuppression rulesYes
Same interface as terraform-aws-modulesN/AYes
Keeps pace with upstream module updatesN/AYes
Catches runtime drift / console changesYesNo
Covers non-Terraform resourcesYesNo
Internal engineering timeMediumLow

We recommend keeping scanning tools active alongside compliance.tf for defense in depth. The scanner validates what compliance.tf already enforces.

NIST 800-53 Compliance Questions

Is this Rev 4 or Rev 5?

compliance.tf maps controls to NIST 800-53 Revision 5, the current version published in September 2020. Rev 5 added privacy controls and reorganized several control families. If you need Rev 4 mappings for legacy authorization packages, contact us.

Which control families does this cover?

compliance.tf enforces controls from the Access Control (AC), Audit and Accountability (AU), System and Communications Protection (SC), Contingency Planning (CP), and System and Information Integrity (SI) families. These are the families most directly tied to infrastructure configuration.

How is this different from Checkov, Trivy, or Prowler?

Those tools are detective controls. They scan infrastructure after you write it and report findings you fix manually. compliance.tf is a preventive control. The modules cannot silently produce non-compliant resources - every exception is an explicit parameter in your code, visible in review. Compliant defaults ship up front instead of findings to remediate later. Most teams keep their scanners running alongside compliance.tf for defense in depth.

Can I adopt this gradually, or is it all-or-nothing?

Fully incremental. Start with one module in one environment. Your existing modules continue working untouched. If you use Terragrunt or Terramate to orchestrate your runs, nothing changes - you’re only swapping the module source line. There is no global policy agent to deploy, no wrapper binary, no sidecar. Each module source line is independent.

Will my auditor accept this as evidence?

Your auditor does not need to trust compliance.tf directly. Evidence comes from AWS-native tools they already accept: AWS Config, Security Hub, and Audit Manager. We enforce controls before terraform apply, so those tools report the enforced controls as passing.

What if I want to switch back or compliance.tf shuts down?

Our modules are standard Terraform. They work with Terraform, OpenTofu, Terragrunt, Terramate, and any tool that speaks the Terraform module protocol. Every module is a drop-in replacement for its upstream terraform-aws-modules equivalent with the same variables and outputs. Change your module source line back, run terraform init. Your infrastructure does not change. No lock-in, no proprietary state.

Start Deploying NIST 800-53-Compliant Infrastructure

$1,000/year for all 35 modules, all frameworks. 30-day free trial.

No credit card required. Switch back at any time.

Or browse the NIST 800-53 registry first - no signup needed: nist80053.compliance.tf

Stay Informed About New Features

Join the mailing list for releases, new modules, and roadmap updates. No spam. Unsubscribe anytime.

Not convinced yet, or missing a feature you need? Send us an email - we really want to hear your feedback!