AC-24 Access control decisions: requirements and evidence

What AC-24 access control decisions requires and why it is hard

AC-24 asks you to separate the access control decision from the enforcement point and to make sure defined decisions are applied to each access request before access is enforced. The decision (who may do what, under which policy) and the enforcement (the gate that lets the request through or blocks it) can sit in the same component or in different ones, and the control's guidance allows different entities to perform each. For an assessor, the question is whether your procedures or mechanisms guarantee that the decision comes first and that the enforcement point honors it. The risk the control targets is familiar: enforcement points that decide inconsistently, cache old roles, or keep applying a policy that was revoked hours earlier. A reverse proxy that trusts a stale group claim, or an API gateway with its own copy of permissions, can grant access that the central policy would refuse.

AC-24 is not selected in any SP 800-53B baseline, so it does not appear in the low, moderate, high or privacy baselines. It enters your scope only when you tailor a baseline to add it or when an overlay or contract brings it in. Confirm this against your own baseline selection and the system security plan before the assessment starts, because an assessor will test whatever the plan says is in scope. The two control enhancements are described in the catalog in general terms only, so read the current text in the CPRT or OSCAL catalog, and agree with your assessor which of them your design needs to address.

Distributed architectures make the control hard to satisfy consistently. Microservices, multiple identity providers, edge gateways, databases with their own row-level rules and third-party applications each may enforce access, and each must receive decisions from a source that is current and authoritative. Start by listing every enforcement point for a sensitive resource, recording where each one gets its decision, how often that decision refreshes, and what happens when the decision service is unreachable. Open-source identity components such as authentik, which delegates sign-in to applications through OAuth2, OpenID Connect, SAML, LDAP, RADIUS and proxy providers, or FreeIPA, which provides single sign-on for Linux and UNIX environments through an MIT Kerberos KDC, can supply authentication and some group data, but they do not by themselves prove that every enforcement point applies the same decision. That proof is the evidence you need to build.

Which systems, teams and third parties AC-24 applies to once it is selected

AC-24 is not in any SP 800-53B baseline, so it reaches a system only when the organization tailors a baseline or adds it through an overlay. Once selected, the work follows where authorization decisions are made and where they are enforced, which often differs across the system boundary.

Distributed enforcement points

Identify every place an access request is enforced: load balancers, API gateways, reverse proxies, application code, database layers and admin consoles. Each enforcement point must receive a decision that was made under the defined procedures before enforcement occurs. Map these points in the system design documentation, because assessors will compare that diagram against the configuration settings they examine.

Central identity and policy services

Determine which services make the decisions, such as an identity provider or a policy engine, and which attributes they use. Document which group memberships, roles or attributes feed each decision. Where a self-hosted identity provider such as authentik or FreeIPA issues decisions, record its configuration as part of the evidence for AC-24.

Delegation by gateways, APIs and applications

Many applications do not decide access themselves. They delegate sign-in and authorization to a provider through protocols such as OAuth2, OpenID Connect, SAML or LDAP. Confirm for each application whether it trusts the decision, performs its own check, or both, and whether that behavior is written down. A gap here is the most common reason an assessor cannot trace a decision to enforcement.

Decisions and enforcement owned by different teams

The control guidance allows decisions and enforcement to be carried out by different entities. Name the owner of the decision procedure and the owner of each enforcement mechanism in the system security plan. Where a platform team runs the gateway and an application team writes the policy, the handoff must be written, tested and reviewed.

SaaS and third-party decision points

When a vendor or cloud service makes or enforces access decisions for your data, it sits inside your AC-24 scope even though you do not operate it. Request the vendor's documentation of its decision logic, its audit records and its change notifications, and record the assumptions in your agreements. Treat any decision point you cannot inspect as a documented risk rather than an assumed control.

Tailoring and overlay records

Because no baseline selects AC-24, the decision to add it must appear in the tailored baseline or overlay with its rationale. Record which systems carry the control and which are excluded, so that the scope is defensible. Ask your assessor to confirm the scope early, since it determines which systems the assessment procedure covers.

How an assessor tests AC-24 under SP 800-53A

This table maps the single AC-24 determination statement and its examine, interview and test methods in SP 800-53A to the objects each method uses, the evidence an assessor will ask for, and the findings that most often appear. Read each row as a question the assessor will put to the system owner, then check the evidence you can produce before the assessment starts.

Assessment method	Objects the assessor uses	Evidence the assessor requests	Common findings
Examine	Access control policy, procedures addressing access control decisions, system design documentation, system configuration settings and associated documentation, system audit records	Written procedure that names where authorization decisions are made, design diagrams showing decision points ahead of enforcement, configuration exports from the policy engine or identity provider, and log samples showing decisions recorded	Procedures that describe enforcement but never state where the decision is made; design documents that omit decision points in distributed components
Interview	Organizational personnel with responsibilities for establishing procedures regarding access control decisions to the system	Walkthrough by the system owner or security engineer explaining how a request reaches a decision point, which team changes policy, and who approves changes	Staff cannot name the component that decides, or decisions depend on a team that is not named in the procedures
Test	Mechanisms applying established access control decisions and procedures	Sample requests traced through the system showing the decision occurs before access is granted, with logs or test output for each sample	Decision made after the resource has already been accessed, or a bypass path such as a direct service-to-service call that skips the decision point
Determination statement	Defined access control decisions applied to each access request before access enforcement	Coverage evidence showing every access path to protected resources passes through a documented decision point	Coverage gaps for administrative interfaces, APIs or batch jobs that were left out of the decision inventory
Audit records	System audit records of decisions and enforcement events	Retained records that tie each decision to the request and the enforcement result	Records that show enforcement outcomes without the decision that preceded them

Implementing AC-24 step by step

This sequence turns AC-24 from a policy statement into a documented decision path, where each access request is evaluated by a defined authorization decision before any enforcement point acts on it. Each step ends with an artifact an assessor can examine, interview against or test.

Inventory access decisions and their owners
List every point where the system decides whether a request is authorized, including application logic, API gateways, identity providers, directory services, network proxies and administrative tools. For each decision, record the policy it applies, the data or function it protects and the named role accountable for the policy. Done means every decision has a named owner and a written policy reference, and the inventory is approved by the owner of the access control policy. Assessors will ask for this list first, so keep it under configuration management.
Map the decision-to-enforcement path
Draw the path a request takes from the point where it arrives to the point where access is granted or denied, marking every decision point and every enforcement point. Distributed architectures often split these across services, so note which entity evaluates each decision and which entity enforces it, since AC-24 allows the two to be different parties. Done means the diagram and a short narrative cover every route into protected resources, including administrative and service-to-service paths that bypass a user interface.
Choose procedures or mechanisms for each decision
For each decision point, decide whether the requirement is met by a documented procedure, an automated mechanism or a combination. A mechanism might be a policy engine or an identity provider that issues tokens only after evaluation, while a procedure might require a reviewer to approve manual grants before enforcement. Record the choice and the reason in the system security plan. Done means each decision has a stated method and a named owner for that method, and no route in the diagram depends on an undocumented choice.
Configure applications to delegate sign-in and authorization
Where an open-source identity provider is used, configure applications to request authentication and authorization decisions from it rather than making their own. For example, an identity provider such as authentik can act as the identity provider for applications through OAuth2, OpenID Connect, SAML, LDAP, RADIUS and proxy providers, and FreeIPA can provide single sign-on for Linux and UNIX environments through an MIT Kerberos KDC. Confirm with each vendor which decision types their configuration can enforce in your environment. Done means each application's configuration file or setup record shows the decision source, and a test account confirms that denied requests never reach the protected resource.
Test that decisions precede enforcement
Run test cases that submit requests the policy should deny and confirm that enforcement blocks them only after the decision returns, and that no enforcement point grants access on a default or cached result. Include edge cases such as expired tokens, revoked roles, and requests that arrive through a second path. Record the expected result, the actual result and the logs for each case. Done means every decision point in the inventory has at least one passing test and one failing test with evidence attached, which mirrors the test method AC-24 assessment procedures use.
Collect audit records and decision evidence
Enable logging at each decision point and at each enforcement point so that the request, the policy applied, the decision and the outcome can be reconstructed. Store these records under the retention and protection rules set for audit data, and confirm that they can be pulled for a sample period. Done means an assessor can select a request from the logs and trace it from decision to enforcement, and the records are referenced in the access control procedures.
Review the decision path after changes
Repeat the inventory, path mapping and tests whenever an application, identity provider, policy or network route changes, and after any change to AC-2 or AC-3 processes that feed the decisions. Record the review date, the reviewer and any updated diagrams. Done means the decision inventory and diagram match the production configuration, and any gaps found in review are tracked in the plan of action and milestones until closed.

How decision and enforcement points fit together in a distributed system

The core point of AC-24 is that the component that decides whether an access request is allowed and the component that actually lets or blocks the request can be separate. The policy decision point evaluates the request against the defined access control decisions, and the policy enforcement point sits in front of the resource and carries out that answer. SP 800-53 Rev. 5 describes the decision and enforcement roles so that they can be performed by different entities, which is why the control matters most in distributed architectures, where a shared identity service may decide and dozens of applications, gateways or hosts enforce. Your job is to decide where each role lives, and to be able to show an assessor that every enforcement point acts only on a decision that was actually made.

For a single request, the flow usually runs in five steps: the subject authenticates, the enforcement point intercepts the request and collects the subject identity, the request context and the resource being accessed, the decision point evaluates that input against the approved rules, and the enforcement point permits or denies the request and records the outcome. The trust boundary should be drawn around the decision point and the policy data it reads, because an enforcement point that can be configured or reached by an unauthorized party can bypass the decision entirely. Map each hop to a specific system and owner in your system design documentation, and confirm which components are reachable only over authenticated, protected channels. Illustratively, a gateway that forwards a request when the decision service is unreachable has created a fail-open path that an assessor will ask you to explain.

AC-3 covers the enforcement mechanism itself, including how approved authorizations are applied to resources, so the two controls should be tested together. AC-2 supplies much of the decision input, because account status, roles and approvals determine what the decision point should return, and a removed account that still resolves to a permit is a decision failure, not an enforcement failure. Check that account lifecycle events reach the decision point in a timely way and that enforcement points cannot cache stale grants indefinitely. The catalog allows different entities to perform the decision and the enforcement, so if a third party operates the enforcement layer, your procedures and contract terms must still show that its decisions match your defined rules.

Evidence that passes an AC-24 assessment

An assessor testing AC-24 looks for proof that defined access control decisions are made and applied before enforcement, and that the people responsible understand their role. The artifacts below connect policy, design, configuration and logs, so each one should point to the same decision points. Keep them dated and reviewed so they still describe the system at assessment time.

Access control policy and procedures

Assessors start with the access control policy and the procedures that describe how access control decisions are defined, approved and applied to each request. Check that the procedures name the decision points, the authoritative decision source for each resource and the conditions that trigger a re-evaluation. Confirm that the document reflects the current identity and authorization architecture, and that the owner has reviewed it on the schedule set in your AC-1 procedures.

System design documentation of decision points

Architecture diagrams and data flow documents should show where each decision is made and where enforcement happens, including any distributed or delegated decision component. This matters because AC-24 separates decisions from enforcement, which may be performed by different entities. Mark each decision point, the component that owns it and the systems that depend on its answer, then update the diagrams whenever an application or identity provider changes.

Configuration settings for decision components

Export the configuration of the identity provider, policy engine and each enforcing gateway or application integration, then record the settings that govern authorization, such as provider bindings, token scopes and group or role mappings. For open-source platforms, store these as version-controlled files so changes leave a history. Ask the implementer to confirm which settings are authoritative and which are local overrides.

Sample decision and enforcement audit records

Assessors ask for samples showing that a decision was requested, evaluated and then enforced for a real access request, including denials. Pull logs that tie the requesting identity, the resource, the decision result and the enforcement outcome to one event. Confirm that logs from the decision component and the enforcing component can be correlated by a shared request or session identifier, and that the logs are retained long enough for the sampling your assessor plans.

Records of personnel responsibilities

Keep role descriptions, assignment records and training evidence for the people who define, approve, operate and review access control decisions. The assessor will interview them, so their records should match what they say about their duties. Update assignments when staff change roles, and record who approved each change to a decision rule, since an unowned rule is a common finding.

Change records for decision logic

Changes to authorization policies, role mappings and provider configuration should go through a documented review with an approver and a rollback path. Keep the tickets, pull requests and deployment records that show when each change went live and who tested it. Review the change log at least as often as you review access, because undocumented changes to decision logic are hard to explain in an assessment.

What meeting AC-24 costs in money and effort

This table breaks the cost of meeting AC-24 into components, showing who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Read it as a checklist for building a quote, since no price or duration for AC-24 work is published by NIST and the figures depend on the system's own topology.

Cost component	Who is paid or who does the work	One-time or recurring	What drives it
Design and documentation of decision points	Internal architects and security staff, possibly an implementation partner	One-time, then updated on change	Number of systems that make access decisions and how many documented procedures exist
Engineering to route enforcement through decisions	Internal platform engineers or an implementation partner under a fixed-scope agreement	One-time per enforcement point, plus change work	Number of enforcement points, whether decisions are centralized or distributed, and how many applications already delegate sign-in
Identity platform tooling or licenses	Software vendor or open-source project, with hosting paid by the organization	Licenses recur where commercial; open-source software has no license fee but still needs hosting and operations	Choice between commercial and self-hosted identity components and the size of the user base
Evidence collection and upkeep	Internal compliance and operations staff	Recurring, tied to review cycles and audit timing	Whether decision logs and configuration exports are generated automatically or gathered by hand
External testing or review of decision logic	Independent security testers or assessors, chosen by the organization	Recurring at the frequency the organization sets	Breadth of access paths tested, number of distributed components and whether testing includes authorization bypass attempts
Auditor or assessor sampling	Independent auditor or assessor, who issues any report	Recurring with each assessment cycle	Number of decision points in scope, how well evidence is organized, and how many exceptions are found
Ongoing support and retainers	Implementation partner under an optional retainer, or internal staff	Recurring, if a retainer is chosen	Frequency of upgrades to identity components and rate of change in application access models

Who owns AC-24: your team, a partner and the auditor

Your organization owns AC-24. Someone accountable in your organization must define which access control decisions apply to each access request, who approves those decisions and how they are reviewed. AC-24 separates decisions from enforcement, and the decision logic can sit with a different entity than the component that enforces it, but the decisions and the accountability for them remain yours. An outside partner can build the mechanisms, but it cannot set your authorization rules or accept the residual risk on your behalf.

Decision ownership: Name the role that defines authorization decisions for each system and documents the rules in the access control policy and procedures.
Procedure approval: Keep the procedures addressing access control decisions approved, current and aligned with the rules that AC-2 account management and AC-3 access enforcement actually apply.
Operational review: Review audit records and exceptions so that decisions made by the mechanisms match the approved procedures over time.
Interview readiness: Make sure the people who establish these procedures can explain them, because assessors interview them directly.
Scope decisions: Decide whether AC-24 is in scope for each system, since it is not selected in any SP 800-53B baseline and must be added by tailoring or overlay.

Before engaging anyone, confirm internally who owns each of these points and write that ownership into the system security plan.

Where AC-24 usually fails and how to close each gap

AC-24 fails less often because a team chooses the wrong access model and more often because decisions are scattered across components with no owner, no record and no shared description. The cards below cover the gaps assessors most often find, and each pairs the gap with a fix that a self-hosted platform team can check in its own environment.

Local decisions with no source

An enforcement point, such as a reverse proxy, API gateway or application, makes its own allow or deny call from a hard-coded rule or a local cache. AC-24 expects defined decisions to be applied before enforcement, so an enforcement point with no documented decision source has nothing to point an assessor to. Inventory each enforcement point and name the decision service, policy store or identity provider it relies on, such as an authentik provider for applications that delegate sign-in.

Policy copies that drift

The same access rule often lives in an identity directory, a gateway config and an application table, and the copies diverge after a change is made in only one place. Assessors testing the mechanisms that apply decisions will compare them against the approved policy. Pick one authoritative source for each rule, generate or sync the other copies from it, and record the sync job as evidence.

Decision logic missing from the SSP

The system security and privacy plan often describes that access is controlled but not how the decision is made, which component makes it, or which inputs it uses. An assessor reading the plan cannot trace an access request to a documented decision path. Write a short decision flow for each system that names the decision point, the policy source, the inputs such as group or attribute data, and the enforcement point that acts on the result.

No audit record of decisions

Many systems log logins but not the authorization decisions behind them, so a denied request or a changed rule leaves no trace. AC-24 is tested with system audit records as an examine object, so the gap is visible during assessment. Confirm that allow and deny outcomes, the policy version applied and the requesting identity are written to a central log store with retention set by your audit requirements.

No named owner for decisions

Interview objects for AC-24 include the personnel responsible for establishing procedures for access control decisions, and a gap appears when that role is unclear. Platform, application and identity teams may each assume another group owns the policy. Assign one accountable owner for the decision procedure, name a delegate for each platform, and document who approves changes to the authoritative policy source.

Unclear split between deciding and enforcing

Teams sometimes treat decision and enforcement as one function, so the decision service is not separately identified or tested. AC-24's guidance allows different entities to make the decision and enforce it, which means the split should be deliberate. Document which component decides, which enforces, and how the enforcer confirms the decision came from an approved source, then test that path directly rather than only testing the final allow or deny.

AC-24 questions buyers ask before hiring help

What does it cost to meet AC-24 access control decisions?

No supplied fact gives a price for meeting AC-24, and DeployOpen does not publish a price list. The cost comes from the work that surrounds one procedure: defining which access decisions the system makes, writing the procedure, configuring the mechanisms that apply those decisions, collecting audit records, and preparing evidence for an assessor. The main cost drivers are the number of systems and identity sources in scope, how many access paths exist (web, API, administrative, and distributed services), and how much of the design already exists. Ask any partner for a fixed-scope quote that lists each system, each deliverable and what the client team must provide. Ask the independent assessor separately for its fee, because the assessor and the implementation partner are paid for different work.

How long does AC-24 work take, and what sets the timeline?

No supplied fact gives a duration for AC-24 work, so treat any timeline as a claim to verify in writing. The timeline depends on how many systems enforce access decisions, whether an identity provider already centralizes decisions, how mature the existing access control policy and procedures are, and how quickly the client's architecture and security teams can review design documents. Distributed architectures usually take longer because decisions and enforcement may sit in different services. Ask for milestones tied to written deliverables, and confirm which steps depend on client reviews, change windows or assessor scheduling.

What does the internal team need to provide for AC-24?

The organization owns its controls, so its own people must make the decisions the control describes. Expect to provide:

A named owner for the access control policy and the procedures addressing access control decisions
Access to system design documentation, configuration settings and audit records for each in-scope system
Staff who can explain which roles, attributes or rules the system uses to decide access
Time from application owners and security reviewers to approve the design and test results

Without these inputs, an implementation partner cannot document decisions that the organization has not yet made.

Can we implement AC-24 in-house without an outside partner?

Yes, an organization can implement AC-24 with its own staff, since the control asks for procedures or mechanisms and the organization decides how to meet it. The questions to answer honestly are whether the team has time to document decisions across every system, whether it can test mechanisms against the examine, interview and test methods in SP 800-53A, and whether it has people who can keep evidence current after go-live. An outside partner typically adds value by preparing systems, configurations and evidence on a fixed scope, while the organization keeps authority over its decisions. Compare both options against the same written scope before choosing.

Is AC-24 required by an SP 800-53B baseline?

No. SP 800-53B Release 5.2.0 does not select AC-24 for the low, moderate or high security control baselines or for the privacy baseline. Organizations can still add it by tailoring a baseline or through an overlay, and a contract, regulator or agency may require it in that form. Confirm the required baseline and any tailoring decisions with the authorizing official or the party that set the requirement before scoping work, because a baseline without AC-24 does not remove the need for it in the client's own risk assessment.

What can an implementation partner not do for AC-24?

An implementation partner cannot issue the assessment. Only an independent assessor or certification body issues assessment results, reports or certificates. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. The organization remains responsible for its control decisions, for the accuracy of its evidence, and for the risk it accepts. Ask any partner to state this boundary in the statement of work, and ask the assessor to confirm which evidence it will examine, interview and test.

How do mechanisms that enforce AC-24 decisions get tested?

An assessor checks that the decisions are defined, that a procedure or mechanism applies them before enforcement, and that the design holds across the system. Under SP 800-53A, the assessor reviews the access control policy, procedures, design documentation, configuration settings and audit records, interviews the people responsible, and tests the mechanisms. Prepare a decision inventory, configuration exports from the identity provider and policy engines, and sample audit records showing decisions being made before enforcement. The identity provider authentik, for example, can delegate sign-in to applications through OpenID Connect and SAML, which gives a single place to show configured providers, though the organization still needs its own decision procedure. Confirm each platform's capability in its own documentation before relying on it.

Which open-source tools help produce AC-24 evidence?

Self-hosted identity components can produce much of the configuration and audit evidence. authentik documents providers for OAuth2, OpenID Connect, SAML, LDAP, RADIUS and proxy access, which shows how applications delegate sign-in. FreeIPA provides single sign-on for Linux and UNIX environments through an MIT Kerberos KDC, which can centralize identity for those hosts. Neither tool decides what the organization's policy should be, so the decision procedure still has to be written and approved by the owner. Confirm which decision points each product controls in the target environment before scoping.

How DeployOpen prepares AC-24 for your assessment

DeployOpen works on AC-24 as a fixed-scope implementation engagement. Before any work starts, the scope, deliverables and timeline are agreed in writing, and the scope names the systems whose access decisions are in play, such as the applications that rely on an identity provider, the directory services behind them and the enforcement points that act on those decisions. Work happens inside the organization's own cloud accounts, data centers or air-gapped networks. The organization keeps ownership of its control design and its risk acceptance decisions. DeployOpen's part is to prepare the systems, configurations, documentation and evidence that an assessor will examine and test.

In practice, that preparation means documenting where each access decision is made and where it is enforced, then confirming that the two are wired together for every request. An engagement might produce a written description of the decision points, configuration exports for the identity provider and directory, sample audit records showing that decisions were logged, and test results from the mechanisms that apply those decisions. Ask any implementation partner to show, in the written scope, which of these artifacts it will produce and which the organization must supply itself, such as the access control policy and the procedures that define who sets authorization rules.

DeployOpen does not issue audit reports, attestations or certifications. The independent assessor or auditor that the organization selects examines the evidence, performs the assessment procedures and reaches the findings. Because AC-24 is not selected in any SP 800-53B baseline, confirm with your assessor and authorizing official whether the control is in scope for your system at all, and if it is, whether it was added through tailoring or an overlay. That decision should be recorded before the preparation work is scoped, so that the evidence set matches what the assessor will actually test.

AC-24 Access control decisions