Skip to main content
CloudArq
frameworknist 800-53
scopeaws
families7
compliance guide · aws · nist 800-53

NIST 800-53 on AWS: AC, AU, SC and more, mapped

A control-family guide for AWS teams working against NIST SP 800-53. Every control below — Access Control, Audit & Accountability, Configuration Management, Contingency Planning, Identification & Authentication, System & Communications Protection, System & Information Integrity — is paired with the exact read-only CloudArq checks that evidence it. This is posture and evidence, not an authorization.

Updated 2026-07-20 · ~11 minute read

85
checks mapped to controls
6
control families covered
14
controls mapped below
0
agents installed
See CloudArq map these View pricing
audience

Who this is for

Engineering and security teams on AWS who have been handed a NIST 800-53 control set — because you sell to a federal or regulated buyer, because a prime contractor flowed the requirement down, or because your own control framework is built on 800-53. You need to know which controls your AWS configuration already evidences and which it does not, without hand-auditing every account. If you have a GRC team running the full assessment, use this to keep the AWS-technical controls green between reviews.

definition

What NIST 800-53 actually is (one paragraph)

NIST Special Publication 800-53 is a catalog of security and privacy controls published by the U.S. National Institute of Standards and Technology. Controls are grouped into families identified by a two-letter prefix — AC (Access Control), AU (Audit & Accountability), SC (System & Communications Protection), and so on — and each control carries an identifier like AC-2 or SC-28. It is the backbone of FedRAMP and of most U.S. federal authorization work, but it is control-set, not cloud-specific: a control such as “protect information at rest” applies whether the data lives on-prem or in an S3 bucket. This page maps the AWS-technical half of that catalog to concrete, read-only checks.

mapping

How CloudArq maps to the control families

CloudArq maps 102 of its automated checks to NIST 800-53 control identifiers across 7 families. The number is the provable per-framework mapped count — the distinct checks that carry an 800-53 control, not the full check registry (most cost, performance, and sustainability checks have no 800-53 control, so they are excluded). It is bound to a single source of truth and drift-guarded against the backend mapping, so the figure on this page can never quietly diverge from what the scanner actually maps.

Each check below describes a capability the read-only audit can surface — a configuration that does not evidence its control — never an observed attack or an asserted violation. When a control fails, CloudArq groups it under its 800-53 identifier and ships a copy-paste CLI or Terraform fix plus the evidence pointer an assessor will ask for.

Access Control (AC)

Who — and what — can reach your resources. Auditors start here.

4 controls
  • AC-2Account management — CloudArq checks for missing root-account MFA, root-account access keys, and stale IAM access keys (no_mfa_root, root_access_keys, old_access_keys).
  • AC-3Access enforcement — checks for AI data-capture and invocation-log sinks left readable beyond their intended principals (sagemaker_data_capture_pii_sink, invocation_log_sink_exposure).
  • AC-4Information flow enforcement — checks for internet-reachable self-hosted inference endpoints and security groups open to SSH from anywhere (exposed_self_hosted_inference_endpoint, open_ssh).
  • AC-6Least privilege — checks for wildcard IAM policies, Lambda functions bound to admin roles, and privileged AgentCore gateway execution roles (iam_policy_wildcard, lambda_admin_role, gateway_privileged_role).

Audit & Accountability (AU)

You can't reconstruct what you never recorded.

3 controls
  • AU-2Event logging — checks that CloudTrail is enabled and that Bedrock model-invocation logging is on where Bedrock is in use (no_cloudtrail, bedrock_invocation_logging_off).
  • AU-3Content of audit records — evidenced by the CloudTrail and Bedrock invocation-logging checks above; when those trails run, the records they emit carry the who / what / when NIST expects.
  • AU-9Protection of audit information — checks for a publicly exposed invocation-log sink and an unencrypted CloudTrail trail (invocation_log_sink_exposure, cloudtrail_not_encrypted).

Configuration Management (CM)

A known-good baseline you can detect drift against.

1 controls
  • CM-2Baseline configuration — checks that AWS Config is recording your resource inventory and flags reliance on the default VPC as an unmanaged baseline (config_not_enabled, default_vpc_in_use).

Contingency Planning (CP)

Can you restore the data and the system after loss?

2 controls
  • CP-9System backup — checks that RDS automated backups are enabled and that DynamoDB point-in-time recovery is on (no_backups_rds, dynamodb_no_pitr).
  • CP-10System recovery & reconstitution — evidenced by the same backup and point-in-time-recovery checks; without a retained backup there is nothing to reconstitute from.

Identification & Authentication (IA)

Prove who is calling before you let them act.

2 controls
  • IA-2Identification & authentication (organizational users) — checks for missing MFA on the root account and on IAM users (no_mfa_root, iam_users_no_mfa).
  • IA-5Authenticator management — checks for IAM access keys past their rotation window and Secrets Manager secrets with no rotation configured (old_access_keys, secrets_no_rotation).

System & Communications Protection (SC)

Encrypt data moving across the wire and sitting at rest.

3 controls
  • SC-8Transmission confidentiality & integrity — checks for CloudFront distributions that allow plaintext HTTP and S3 buckets that do not enforce TLS on requests (cloudfront_no_https, s3_no_ssl_enforcement).
  • SC-12Cryptographic key establishment & management — checks for KMS keys with rotation disabled and Route 53 hosted zones without DNSSEC signing (kms_key_rotation_disabled, route53_dnssec_disabled).
  • SC-28Protection of information at rest — checks for unencrypted EBS volumes and AgentCore Memory stores on an AWS-owned key rather than a customer-managed KMS key (unencrypted_ebs, memory_no_cmk).

System & Information Integrity (SI)

Patch the flaws, then watch for what slips through.

2 controls
  • SI-2Flaw remediation — checks for instances missing SSM patch compliance and ECR repositories without scan-on-push enabled (ssm_unpatched, ecr_no_scan_on_push).
  • SI-4System monitoring — checks that GuardDuty is enabled and that baseline monitoring is in place across the account (guardduty_disabled, no_monitoring).
product · output

How CloudArq groups the gaps by control

compliance-gaps · framework · nist 800-53illustrative example
Critical1High2Medium2
AC-6
IAM policy grants Action:* on Resource:*
iam_policy_wildcard · policy/example-admin
fix →
SC-28
EBS volume not encrypted at rest
unencrypted_ebs · vol-0example · eu-north-1
fix →
AU-2
CloudTrail disabled in a region
no_cloudtrail · eu-west-1
fix →
IA-2
IAM user without MFA
iam_users_no_mfa · user/example-ci
fix →
SI-4
GuardDuty disabled
guardduty_disabled · eu-north-1
fix →

Illustrative only — sample rows, not a real account. Each failing control ships a copy-paste CLI / Terraform fix and its evidence pointer for the assessor.

scope · honest

What this does — and what it does not do

CloudArq maps 102 checks to the technical controls in the AC, AU, CM, CP, IA, SC, and SI families — encryption, access, logging, monitoring, and backup posture a read-only scanner can read from your AWS configuration.

It does not cover the management, operational, and physical controls — policy, training, media handling, personnel, physical access — that live in people and process, not in AWS configuration. It is not a NIST 800-53 assessment and not an Authorization to Operate. A scanner shows posture; it does not certify, guarantee, or grant an authorization — that is the job of an assessor and an authorizing official. CloudArq the business holds no certifications; the product maps its checks to framework controls so you walk into the assessment with the AWS-technical evidence already in hand.

faq

Frequently asked

01Does CloudArq make my AWS environment NIST 800-53 compliant?
No — and no scanner can. CloudArq maps 102 of its automated checks to the technical controls in seven NIST 800-53 families (AC, AU, CM, CP, IA, SC, SI) and shows you where your AWS configuration does and does not evidence them. That is posture, not compliance: 800-53 compliance is an organizational judgement about the full control set, made by an assessor. CloudArq gives you the AWS-technical evidence and a guided fix for each gap; it does not certify, guarantee, or grant an authorization.
02Which NIST 800-53 revision does CloudArq target — Rev 4 or Rev 5?
CloudArq maps to the technical controls by their control identifier (AC-2, AU-9, SC-28, and so on) rather than to a specific revision, and it does not assert Rev 4 or Rev 5. Those identifiers are stable across revisions for the AWS-infrastructure controls this mapping covers — encryption, access, logging, monitoring, backup — so the mapping stays useful whichever baseline your assessor works from.
03Which control families does CloudArq cover, and how deep?
The mapping spans seven families — Access Control (AC), Audit & Accountability (AU), Configuration Management (CM), Contingency Planning (CP), Identification & Authentication (IA), System & Communications Protection (SC), and System & Information Integrity (SI) — across 17 controls. It covers the AWS-technical controls a scanner can read (MFA, least privilege, encryption at rest and in transit, CloudTrail, GuardDuty, backups, patch state). It does not cover the management, operational, and physical controls — policy, training, media handling, personnel — that live in people and process, not in AWS configuration.
04Is CloudArq read-only? Will it change my AWS configuration?
CloudArq connects through a read-only IAM role secured with an ExternalId. It never stores your credentials, application data, database contents, or S3 objects, and the audit is read-only end to end. Every finding is detection plus a guided fix — a copy-paste CLI or Terraform change you apply yourself. CloudArq never auto-fixes.
05Does this replace a NIST 800-53 assessment or an ATO?
No. An Authorization to Operate is granted by an authorizing official after an assessor evaluates the full control set — including the organizational controls a scanner cannot see. CloudArq is continuous evidence for the AWS-technical slice of that work: it keeps the encryption, access, logging, and monitoring controls green between assessments and shows drift the moment it appears, so you walk into the assessment with the technical posture already documented.
06How does NIST 800-53 relate to the other frameworks CloudArq maps?
The AWS-technical controls overlap heavily. A single encrypted-at-rest finding evidences NIST SC-28, ISO 27001 Annex A.8.24, and SOC 2 CC6.1 at once. CloudArq maps the same read-only audit to eight frameworks, so one scan produces control-mapped evidence for each — see the ISO 27001 and SOC 2 pages for those control breakdowns.

See the 800-53 mapping on your audit

Connect a read-only IAM role, run the audit, and CloudArq groups your failing controls by 800-53 identifier — 102 checks mapped across 7 families, each with a guided fix and an evidence pointer. The same read-only scan also maps to seven other frameworks, so one audit produces control-mapped evidence for each.

Working against a related framework? Here is the ISO 27001 Annex A mapping and the SOC 2 on AWS checklist.

See the demo View pricing