NIST 800-53 on AWS and Azure: what inherits and what you still own

How much of NIST 800-53 does AWS or Azure cover for you?

When a contract or authorization requires SP 800-53 and the system runs on AWS or Azure, the cloud provider covers only the controls it inherits to you, and automated checks in AWS Security Hub or Azure Policy cover only a subset of the controls. The organization owns every control the platform does not carry for it. Inheritance is decided per control and per system, not by the platform's compliance badge or by a green dashboard. Under SP 800-53B, a system that inherits a common control from another provider does not implement that control itself, but that inheritance has to be documented and accepted for the specific system boundary, so the reader should confirm which controls the provider documents as its own and which remain customer responsibilities.

Start by pulling the provider's control responsibility documentation for each service in the boundary and marking every SP 800-53 control as provider, shared or customer. Azure Policy's built-in NIST SP 800-53 Rev. 5 initiative labels its policy mappings as Shared or Customer ownership, and Microsoft warns that a Compliant result covers only the policy definitions, that some controls have no policy and that the view of compliance is partial. AWS Security Hub's NIST SP 800-53 Rev. 5 standard runs automated checks for certain services, says the controls do not cover requirements that need manual checks, and recommends enabling AWS Config resource recording first. Confirm in each console which findings are actually produced for your account, because a control with no mapped check will show nothing at all.

The organization owns its controls. DeployOpen can prepare the system, configuration and evidence where it is engaged under a written scope, but it does not issue assessment results. Only an independent assessor can do that, and the assessor will test inherited controls by reviewing the provider's own assessment evidence and the customer's configuration against it, as SP 800-37 Rev. 2 contemplates for common controls. Ask your assessor early which provider reports they will accept, how they will treat controls the provider marks as shared, and what they expect to see for controls that have no automated check. Those answers decide how much of the remaining work is evidence collection and how much is engineering.

Which controls you can inherit and how to document each one

Inheritance shifts part of the SP 800-53 workload to AWS or Azure, but the system owner still decides what is inherited, proves it and keeps watching it. The four cards below set out the decisions that run in parallel for each inherited control, with the monitoring step tied to SA-9.

Confirm the provider control is in scope

Start by checking whether the provider's control actually covers your system. A common control can apply to the platform layer, to a specific service or to a region, and it may stop at the boundary of a managed feature you have turned on. Map each inherited control to the services in your authorization boundary and record any service that falls outside it. Under SP 800-53B, a system that inherits a common control does not need to implement it, but only for the scope the provider actually covers. Confirm the mapping with the provider's documentation before you rely on it.

Obtain the provider's plan and assessment report

Ask for the provider's security plan, assessment report and plan of action and milestones for each common control you inherit. SP 800-37 Rev. 2 says these artifacts for common controls are made available to owners of inheriting systems after the accountable authorizing officials review and approve them. Check that the report covers the control version and release you are mapping to, and that its assessment date falls within a period you consider current. Where a provider cannot share these documents, treat the control as one you must implement yourself until you have them.

Record the inheritance in the system security plan

Each inherited control needs an entry in your system security and privacy plan that names the provider, the common control and the responsibility you keep. Write down which part of the control the provider covers and which part remains with your team, such as account configuration, key management or log review. Azure Policy marks controls as Shared or Customer ownership, and that label is a starting point, not a substitute for your own statement. Auditors will test the plan against the provider's documents, so the entries must match exactly.

Monitor provider compliance on an ongoing basis

SA-9, External System Services, requires that provider control compliance be monitored on an ongoing basis using defined processes, and that oversight and user roles be documented. Set a recurring review of the provider's updated assessment material, and record who reviews it and what triggers escalation. FedRAMP sets SA-9(2) for all external systems that process or store federal customer data, and at Class D it sets SA-9(5), which requires that information processing, data and system services for federal customer data be located in the U.S., its territories or other locations under U.S. jurisdiction. Confirm region selection against that rule before you deploy.

What AWS Security Hub's NIST 800-53 standard checks

The compliance lead decides what the standard is expected to cover before anyone enables it. AWS Security Hub's NIST SP 800-53 Rev. 5 standard runs automated checks that support a subset of the requirements, and only for certain AWS services. AWS recommends enabling AWS Config resource recording first, because many checks read configuration state that Config records. Setup is therefore a scoping exercise, not a switch to flip.

Confirm the services and checks: Review the control list in the AWS documentation for your account and Region, and record which services and checks apply to your environment.
Enable Config recording first: Turn on AWS Config resource recording in each account and Region in scope so the checks have configuration history to evaluate.
Record the gaps at enablement: Note which controls have no automated check and assign each one to a named owner for manual evidence.
Set aggregation and ownership: Decide which administrator account aggregates findings and who triages them.

Before go-live, confirm in writing with your assessor which controls the team will treat as automated evidence and which will not.

How Azure Policy's Rev. 5 initiative reports compliance

The Azure Policy built-in initiative for NIST SP 800-53 Rev. 5 is one evidence source, not a verdict on the system. It maps policy definitions to individual controls, and each mapped control carries an ownership label of Shared or Customer. Microsoft's own warning is the right starting point: a Compliant result shows only that the mapped policy definitions pass, some controls have no policy at all, and the compliance view is partial. Treat the regulatory compliance dashboard as a list of technical signals to be reviewed, with each red, green or unassigned control traced back to the policy definition, the scope and the evidence that backs it.

Shared ownership means the cloud provider and your organization both contribute, so you need the provider's documentation before you can rely on the mapping. Pull the provider's control responsibility and attestation material for the services in your boundary, and file it against the control in your System Security and Privacy Plan. Customer ownership means the policy result is at best a partial input, because your organization must prove the control itself. For those controls, decide what document, configuration export, access review or ticket will satisfy the assessor, and store that evidence with the policy state rather than relying on the green tile.

Before relying on the mapping, open the Microsoft Learn details for the initiative and confirm three things: which policy definitions are mapped to each control, which controls list no policy, and which ownership label applies to each control in your environment. Record the initiative version you assessed, because mappings change as Microsoft updates the built-in content. Then compare that list against your own control inventory. Any control with no policy, or one whose policy only covers part of the requirement, needs a manual check or an alternate source of evidence in your assessment plan.

Why automated checks cover only part of the controls

A compliant score in AWS Security Hub or Azure Policy shows that specific technical settings matched a check. SP 800-53 assessments ask for more: documented procedures, observed people and reviewed records. The cards below cover the gaps that automated checks leave open.

Requirements that need manual checks

AWS states that the NIST SP 800-53 Rev. 5 standard in Security Hub does not cover requirements that need manual checks. Those gaps sit in the same control families as the automated checks, so a team can see high scores while parts of a control remain untested. Before accepting the score as evidence, map each Security Hub control to the determination statements it covers in SP 800-53A and list the statements left open. Assign an owner and an evidence type to each open statement.

Controls with no policy definition

Microsoft warns that some controls in the Azure Policy NIST SP 800-53 Rev. 5 initiative have no policy definition, and that the compliance view is partial. A control with no policy never turns green, and it never turns red either. Teams often read the absence as a pass. Review every control in the initiative that shows no mapped policy, then decide whether it is met by a process, a manual record or a different tool.

Organizational procedures and people

Controls for training, personnel screening, termination and incident response depend on people following documented steps. A policy engine can confirm that a logging setting is enabled, but it cannot confirm that a background screening was completed before access was granted. Auditors look for signed rules of behavior, training completion records, sanction decisions and incident tickets. Plan how each of these records is produced, retained and reviewed by someone outside the process.

Interviews and document examination

SP 800-53A gives each control a set of determination statements and asks assessors to examine, interview and test. A cloud configuration check covers only the test method for the technical setting. The examine method needs current policies and plans, and the interview method needs staff who can explain how the control runs day to day. Build a matrix that lists each determination statement, the method used and the artifact the assessor will receive.

Scope and tailoring decisions

A policy initiative applies its checks to the resources it can see, and it does not know which controls your organization tailored out, which it assigned to a common control provider, or which it compensated. Those decisions live in the system security and privacy plan. Compare the scope of every automated check with the boundary and tailoring recorded in the plan, and document any resource that falls outside the monitored scope.

How to build an SP 800-53 system on AWS or Azure, step by step

This sequence turns a cloud workload into an SP 800-53 system whose inherited, automated and manual controls are documented, tested and ready for an independent assessor to examine.

Define the system boundary and impact level
The organization, with its authorizing official and security team, defines which AWS accounts or Azure subscriptions, workloads, data stores and administrative paths belong to the system, and records the information types it processes. Impact level is then set so the matching SP 800-53B baseline (low, moderate or high) can be selected, with the privacy baseline added where PII is processed. Done means a signed boundary description, an inventory of cloud resources in scope and a documented baseline selection that names each tailoring decision.
Map provider inheritance to the baseline
Each control in the selected baseline is marked as system-specific, shared or inherited. The team reviews the cloud provider's published compliance documentation and its shared responsibility model, then confirms which controls the provider implements for the infrastructure layer and which remain with the organization, such as identity configuration, data classification, logging content and application security. Under SP 800-53B an inherited common control need not be implemented again, so each inheritance claim must be backed by the provider's own documentation and the organization's written acceptance. Done means a control responsibility matrix that every control owner has reviewed.
Enable AWS Security Hub or Azure Policy checks
The cloud platform team turns on AWS Config resource recording before enabling the NIST SP 800-53 Rev. 5 standard in AWS Security Hub CSPM, as AWS recommends, or assigns the Rev. 5 built-in initiative in Azure Policy at the chosen scope. Findings and compliance states are exported to the system's evidence store, and any control with no automated check is listed for manual handling. Done means the standard or initiative is active across every account or subscription in the boundary, with its scope recorded.
Triage automated results and resolve misconfigurations
Engineers review failed and unknown findings, fix the underlying resource settings through infrastructure as code where possible, and document any finding that is accepted as a risk or does not apply to the boundary. Teams should confirm for each control whether the automated check actually tests the requirement, because both AWS and Microsoft state that their checks cover only part of the control set. Done means every finding is either resolved with a re-scan result or recorded with a documented risk decision and an owner.
Close gaps with manual control evidence
For controls that no automated check covers, such as personnel screening, training records, contingency exercises, media sanitization and vendor oversight, control owners produce procedures, records and samples that show the control operating. Where a control depends on a process outside the cloud account, the owner documents the process and its evidence location. Done means each control in the baseline points to at least one evidence artifact or to a documented gap entered in the plan of action and milestones.
Write the system security and privacy plan
The security team writes the system security and privacy plan, describing the boundary, architecture, data flows, baseline selection, tailoring, the responsibility matrix, and how each control is implemented and by whom. Inherited controls reference the provider documentation the organization relies on and any common control package made available by an authorizing body. Done means the plan is complete for every control in the baseline and has been reviewed and approved by the accountable authorizing official.
Hand the package to an independent assessor
The organization assembles the plan, the responsibility matrix, scan and policy exports, manual evidence, and the plan of action and milestones, then engages an independent assessor to test the controls against SP 800-53A procedures. The assessor, not the implementation partner or the platform team, issues the assessment report and any authorization decision. Done means the assessor has accepted the package, the open findings are tracked, and the organization holds a signed assessment report for the authorizing official's decision.

What must be in place before an assessor starts

An assessor testing an SP 800-53 system on AWS or Azure will first ask whether the boundary, baseline and evidence trail are settled. The checks below cover what the organization owns, what the cloud provider covers, and what the assessor needs to see before testing begins.

Baseline and impact level confirmed

Confirm the system's FIPS 199 impact level and the matching SP 800-53B baseline (low, moderate or high) before any control is mapped. The baseline decides which controls and enhancements apply, so a policy initiative scoped to the wrong baseline will report compliance against the wrong list. Check that the tailoring decisions, including any overlays, are written down and signed off by the system owner. Ask the assessor which baseline profile they will test against.

Inheritance statements approved

Each control inherited from the cloud provider or a shared service needs a written inheritance statement. Under SP 800-37 Rev. 2, the plans, assessment reports and POA&Ms for common controls are shared with inheriting system owners only after the accountable authorizing officials review and approve them. Check that every inherited control names its provider, the provider evidence relied on, and the authorizing official who approved it. Treat any control without an approved statement as one you still own.

AWS Config recording enabled

AWS recommends enabling AWS Config resource recording before relying on the Security Hub NIST 800-53 Rev. 5 standard, because its automated checks read recorded configuration state. Confirm recording is on in every account and region in scope, and that the recorder covers the resource types the checks evaluate. For Azure, confirm the equivalent: policy assignments are in place at the right scope and evaluation results are being produced. Ask your assessor how they will verify that coverage is complete.

Policy and finding history retained

Assessors test over a period, not on a single day, so the history of policy evaluations and Security Hub findings must survive. Decide how long compliance results and configuration history are kept, and confirm that the retention setting is applied to the storage location, not only to the console view. Export findings on a fixed schedule to a store the organization controls. A missing history window will push the assessor toward sampling where you expected continuous evidence.

Manual control evidence stored

Automated checks cover only part of the NIST 800-53 catalog, and AWS states that its controls do not cover requirements needing manual checks. Identify each manual control, such as security awareness training records, personnel screening, incident response exercises and risk assessments, and assign an owner and evidence location for each. Store the evidence with dates and approver names in a system the assessor can access. Ask the assessor which manual controls they expect to see evidence for at the first meeting.

Provider documentation on file

Under SA-9, the organization must monitor provider control compliance on an ongoing basis and document oversight roles for external system services. Keep the provider's current compliance reports, shared responsibility documentation and any customer agreement terms on file, with a review date for each. Record which provider reports you reviewed, what you concluded, and any gaps you accepted. Confirm with the provider which reports are available to customers under your agreement, since access terms vary.

Who owns each part of the cloud-based SP 800-53 program

This table shows who is responsible for each component of an SP 800-53 system built on AWS or Azure, and what evidence each component produces. Read it as a split of responsibility: the cloud provider supplies inherited controls, the organization owns its configuration, decisions and risk acceptance, and DeployOpen prepares configuration and evidence only when engaged under written scope. The main takeaway is that no row produces an authorization decision on its own, because only an independent assessor issues the assessment report.

Component	Owner	Evidence produced
Provider controls	Cloud provider, documented in its shared responsibility model and compliance documentation	Provider compliance documentation the organization reviews and maps to inherited controls
Configuration of platform checks	Organization, with DeployOpen preparing settings if engaged under written scope	AWS Security Hub or Azure Policy compliance results, enablement records and exception approvals
Customer-specific controls	Organization, which implements and operates them in its own accounts, subscriptions and processes	Configuration baselines, access reviews, logs, runbooks and tested procedures
System security and privacy plan	Organization, approved by its authorizing official	Plan describing each control, its implementation status and any inherited or common control
Plan of action and milestones	Organization, which owns risk decisions and remediation dates	Tracked weaknesses with owners, planned fixes and status history
Assessment report	Independent assessor, not the organization or DeployOpen	Report issued by the independent assessor that tests controls against SP 800-53A procedures

Questions about SP 800-53 on AWS and Azure

Does enabling AWS Security Hub make my system compliant with NIST SP 800-53?

No. Enabling the NIST SP 800-53 Rev. 5 standard in AWS Security Hub turns on automated checks for a subset of the requirements on certain AWS services, and AWS states that these controls do not cover requirements that need manual checks. Recording resource configurations in AWS Config first is the prerequisite AWS recommends, because the checks depend on that data. The rest of the work sits with you: system categorization, the system security plan, policies and procedures, personnel controls, incident response testing and the evidence that shows each control operates. Treat the Security Hub findings as one input to your assessment, and confirm in the current AWS documentation which checks apply to the services you run.

Can Azure Policy compliance results be shown to an assessor as proof of SP 800-53 compliance?

Azure Policy compliance results are useful evidence for specific technical settings, but they do not prove the system meets SP 800-53 on their own. Microsoft's built-in NIST SP 800-53 Rev. 5 initiative maps policy definitions to controls marked Shared or Customer, and Microsoft warns that a Compliant result covers only those policy definitions, that some controls have no policy and that the compliance view is partial. An assessor will ask what each control requires, how it was tested under the assessment procedures and what the results show over time. Export the compliance state with dates, pair it with configuration baselines and change records, and explain in the assessment report which controls the policies do not address.

How is inherited control documentation handled when AWS or Azure provides part of a control?

Inheritance is documented in your system security and privacy plan, where each control is marked as system-specific, hybrid or common, and the provider's responsibility is stated separately from yours. Under SP 800-53B, a system that inherits a common control from another provider does not need to implement that control itself, but you still need to identify which controls are inherited, confirm the provider's coverage and record it. For a provider's own assessment evidence, such as a FedRAMP package or a SOC report, you should check whether it covers the specific services and regions you use. SP 800-37 Rev. 2 expects common control plans, assessment reports and plans of action to be made available to inheriting system owners after the accountable officials review them, so request that package rather than relying on the provider's marketing summary.

What drives the effort of an SP 800-53 build on AWS or Azure?

The main drivers are the impact level of the system, the number of services and accounts in scope, and how much of the baseline your provider and your existing programs already cover. The low, moderate and high baselines in SP 800-53B differ in size, and the privacy baseline applies regardless of impact level, so the selected baseline sets the volume of work. Effort also rises with the number of custom workloads, third-party services and external system providers that must be overseen under SA-9, and with the state of your logging, configuration baselines and vulnerability processes. Ask any consultant or internal lead to break effort down by control family and by one-time versus recurring activity, such as continuous monitoring and annual assessment.

What does the internal team need to contribute to an SP 800-53 program on a cloud platform?

The internal team owns the controls, so it needs named people who can make decisions and sign off on them. Typical contributions include a system owner who accepts risk, a security lead who maintains the plan and plan of action and milestones, engineers who own configuration baselines and pipelines, an identity lead for access and authentication controls, and a process owner for incident response, contingency testing and personnel security. Staff must also be able to produce evidence on a regular schedule, not only during an assessment. A partner can prepare systems, scripts and documentation, but the organization must be able to explain and operate them after handover. Ask any proposal to name the internal roles it assumes.

Can an implementation partner issue an SP 800-53 certification or authorization?

No. An implementation partner can plan, configure, document and test systems and prepare evidence for an assessment, but it cannot issue an assessment report or an authorization. Authorization to operate is granted by the organization's authorizing official after reviewing an assessment, and for FedRAMP or other programs the assessment must be performed by an independent assessor that meets that program's rules. DeployOpen prepares systems, controls and evidence for compliance assessments and does not issue audit reports, attestations or certifications. Confirm with the program owner which assessor types are accepted before you sign a statement of work.

How DeployOpen works on this

DeployOpen works inside your AWS or Azure accounts to set up the platform, the policy checks and the evidence that show which SP 800-53 controls you own and which you inherit. We prepare systems and documentation for your assessor, while your organization keeps ownership of every control decision.

How we scope

Written scope lists the AWS or Azure accounts, subscriptions and self-hosted platforms covered by the 800-53 system boundary.
Scope records which controls you inherit from the cloud provider and which remain customer-owned, with the responsibility split agreed in writing.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before any configuration work begins.

How we build

We configure AWS Config recording and Security Hub or Azure Policy initiatives within the agreed scope, then document where automated checks stop.
Self-hosted open-source platforms are deployed, hardened and integrated inside your own cloud accounts or data centers.
Manual control requirements, such as personnel screening and policy approvals, are mapped to owners and procedures rather than left to tooling alone.

How we hand over

Handover includes configuration records, policy check results and a control-by-control evidence index for your assessor to review.
Documentation explains which findings are inherited, which are customer-owned and which need an operator decision before sign-off.
Only independent assessors issue assessment reports or authorizations; DeployOpen prepares the systems, controls and evidence they examine.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Retainers can cover periodic re-running of policy checks when cloud service configurations or the SP 800-53 release in use change.
Ask us to confirm in writing which parts of support, testing and evidence refresh are included before you sign.

NIST 800-53 on AWS and Azure: inherited controls and policy checks