| Field | Value |
|---|---|
| Control ID | AC-24 |
| Control Name | Access Control Decisions |
| Framework | NIST SP 800-53 Revision 5 |
| Control Family | Access Control |
| Baselines | — |
| Relevance | Organization (First Party and Third Party) |
| Risk Severity | High |
What this control requires
AC-24 requires organizations to establish and apply access control decisions to every access request before enforcement occurs. Most organizations conflate authorization decisions with enforcement, treating them as a single step. AC-24 forces you to separate the two and prove that each access request passes through a deliberate decision point before any system grants or denies access.
In practice, this means your environment needs a defined mechanism or procedure that evaluates authorization information against each request. The decision itself can happen in a centralized policy engine, a distributed authorization service, or even a manual approval workflow, depending on your architecture. What matters is that the decision is explicit, auditable, and applied consistently before enforcement takes effect.
But in distributed architectures, microservices, and federated identity models, the entity making an access control decision is often not the same entity enforcing it. Without AC-24, access requests can bypass decision logic entirely, reaching enforcement points that default to overly permissive behavior. The other controls in the National Institute of Standards and Technology (NIST) SP 800-53 Access Control family that delegate authorization to enforcement points depend on this separation being in place.
Why it matters
Failure to maintain AC-24 introduces audit risk and may result in certification withdrawal or regulatory findings. Auditors specifically look for evidence that authorization decisions precede enforcement. When that evidence is missing, the finding signals that your access control architecture lacks a verifiable decision layer, which undermines the credibility of your entire Access Control family posture.
The consequence compounds in distributed environments. If access enforcement points operate without upstream decision logic, any misconfiguration at the enforcement layer becomes an uncontrolled access grant. There’s no decision record to trace and no way to prove the access was intentional, because the policy evaluation step never happened.
Specifically, organizations pursuing FedRAMP authorization, StateRAMP, or agency-specific authorities to operate will find that assessors treat missing AC-24 evidence as a systemic weakness. It suggests the organization hasn’t thought through how authorization decisions flow across its architecture, which raises questions about every other access control.
What attackers exploit:
- Authorization bypass in distributed systems where enforcement points accept requests without validating an upstream decision
- Inconsistent decision logic across multiple enforcement boundaries, allowing lateral movement through the path of least restriction
- Default-allow configurations at enforcement points that lack a preceding decision mechanism
- Stale or cached authorization decisions that persist after access rights have been revoked
- Gaps between identity provider assertions and local enforcement, where no decision layer validates the mapping
How to implement
Implementing AC-24 requires you to define where authorization decisions happen in your architecture and prove that enforcement never occurs without a preceding decision. The most common failure mode is assuming that because your system checks permissions, you’ve satisfied AC-24. The control requires the decision and enforcement to be identifiable as distinct, auditable steps.
For your organization
Specifically, start by mapping every access enforcement point in your environment. This includes application-level permission checks, API gateways, network access control lists, database authorization layers, and cloud identity and access management (IAM) policy evaluation points. For each enforcement point, identify the decision mechanism that feeds it and confirm that the decision occurs before any access is granted or denied.
Specifically, document the decision architecture in your access control policy. Define how authorization decisions are made, what information they evaluate (roles, attributes, context, time-of-day restrictions), and how those decisions reach the enforcement point. If you’re using a policy decision point and policy enforcement point (PDP/PEP) model, document the communication channel between them.
The result is only verifiable when logging captures the decision layer, not just the enforcement layer. Decision logs should capture the request, the policy evaluated, the decision outcome, and a timestamp. When an auditor asks how you know enforcement matched the intended decision, these logs are your evidence.
In practice, this means you need to test the separation regularly. Periodically verify that enforcement points reject requests when the decision layer is unavailable or returns a deny. If your enforcement points default to allow when the decision service is unreachable, you have an AC-24 gap that an auditor will identify when reviewing your system configuration settings and access control procedures.
Where this commonly breaks down is in the tooling and process choices. Policy engines (attribute-based access control platforms, policy-as-code frameworks), centralized authorization services, and API gateway policy evaluation layers all support the separation, but organizations frequently undercut it by treating role-based access control (RBAC) assignment as both the decision and enforcement simultaneously. Other common mistakes include failing to log decision outcomes separately from enforcement outcomes and neglecting to test decision-enforcement separation in failover scenarios.
For your vendors
When assessing vendor compliance with AC-24, your NIST SP 800-53 compliance checklist should include specific questions about how authorization decisions are architecturally separated from enforcement.
Specifically, ask vendors to describe their authorization decision architecture. Key questionnaire questions include:
- How are access control decisions made and communicated to enforcement points in your system?
- Can you provide documentation showing that decision logic is evaluated before enforcement for every access request?
- What happens at enforcement points when the decision service is unavailable?
- How are authorization decision outcomes logged independently from enforcement actions?
In practice, questionnaire responses alone aren’t sufficient. Request system design documentation that identifies decision and enforcement components separately, configuration artifacts showing policy evaluation occurs before access grants, and audit logs that capture decision outcomes with timestamps distinct from enforcement logs.
Where this breaks down is when vendors cannot distinguish between their decision and enforcement mechanisms, when all authorization logic is embedded directly in application code with no external decision layer, or when enforcement points default to allow if decision services are unreachable. Treat these as substantive findings, not documentation gaps.
The result is only confirmable through a sample audit trail that shows the chain from access request to decision to enforcement. The trail should include separate entries for the decision evaluation and the enforcement action. If the vendor can only produce a single log entry that combines both, the separation likely doesn’t exist in practice, and you should escalate the finding in your vendor risk assessment.
Evidence examples
| Evidence Type | Example Artifact |
|---|---|
| Access control policy | Access control policy defining how authorization decisions are made, what information is evaluated, and how decisions are communicated to enforcement points |
| System design documentation | Architecture diagrams identifying policy decision points (PDPs) and policy enforcement points (PEPs) with communication flows between them |
| Decision mechanism configuration | Configuration settings for policy engines, authorization services, or API gateways showing decision evaluation occurs before enforcement |
| Authorization decision logs | Audit records capturing each access request, the policy evaluated, the decision outcome, and the timestamp, separate from enforcement logs |
| Procedures for access control decisions | Documented procedures defining when decisions are automated versus manual and the approval workflows for each access type |
| System security plan | System security plan sections describing the AC-24 implementation, including decision architecture and enforcement mapping |
Cross-framework mapping
| Framework | Control(s) | Coverage |
|---|---|---|
| ISO 27001:2022 | 8.3 Information access restriction | Partial |
AC-24’s explicit separation of decision and enforcement extends beyond what ISO 27001:2022 8.3 requires. ISO 8.3 focuses on restricting access to information in accordance with policy, but doesn’t mandate that the decision mechanism be architecturally distinct from enforcement.
Related ISO controls address adjacent concerns without requiring this separation. ISO 27001 5.15 governs access control policy and rules but does not mandate a distinct decision layer.
Separately, ISO 27001 5.18 addresses provisioning and revocation of access rights, covering the lifecycle of permissions rather than the per-request decision architecture that AC-24 demands.
Related controls
- AC-02 — Account Management: AC-02 governs the lifecycle of system accounts, and AC-24 ensures that access decisions are applied to each request those accounts make before enforcement occurs.
- AC-03 — Access Enforcement: AC-03 handles the enforcement of approved authorizations, while AC-24 requires that a distinct decision precedes that enforcement for every access request.
Frequently asked questions
What is NIST SP 800-53 AC-24?
AC-24 is the NIST SP 800-53 control that requires organizations to establish procedures or implement mechanisms ensuring access control decisions are applied to each access request before enforcement occurs. It addresses the architectural separation between deciding whether access should be granted and actually enforcing that decision. This control applies at the organization level and isn’t assigned to any specific baseline, but carries high risk severity because a missing decision layer undermines the entire access control architecture.
What happens if AC-24 is not implemented?
Without AC-24, access enforcement points operate without verified authorization decisions, meaning your systems may grant access based on default configurations rather than deliberate policy evaluation. Auditors will flag the absence as a systemic access control weakness, not just a single missing control. For organizations pursuing FedRAMP or agency-specific authorizations, this gap raises questions about every enforcement point in the environment because there’s no evidence that decisions precede enforcement.
How do you audit AC-24?
Auditing AC-24 starts with reviewing system design documentation that identifies policy decision points and policy enforcement points as distinct components. Request authorization decision logs that capture the access request, the policy evaluated, and the decision outcome with timestamps separate from enforcement logs. Verify that procedures addressing access control decisions define when automated versus manual decisions apply, and test enforcement behavior when the decision service is unavailable to confirm enforcement points don’t default to allow.
What is the difference between access control decisions and access enforcement?
Access control decisions determine whether a specific access request should be allowed or denied based on authorization policies and contextual attributes. Access enforcement is the mechanism that carries out that decision by actually granting or blocking the access. AC-24 requires the decision to happen first and be documented as a distinct step, while AC-03 governs the enforcement that follows. In many architectures, these functions run on different components, such as a centralized policy engine making decisions and distributed gateways enforcing them.