API gateway denies unauthorized partner
A third-party app requests patient read without proper scopes; AC-24 decision at the gateway denies and logs.
Access Control Decisions
High Risk
Moderate
Medium Cost
AC-24 establishes and applies access control decisions that enforce organization-defined access control policies. Healthcare needs reliable decision points—API gateways, EHR security services, and IdP policy engines—that consistently allow or deny ePHI operations.
Control Objective
Ensure access control decisions for ePHI systems are defined, enforced at decision/enforcement points, and aligned to policy.
Implementation Guidance
- Document where authorization decisions occur (EHR, API gateway, IdP, file shares).
- Centralize policy where feasible; avoid contradictory local ACL sprawl.
- Require authenticated identity before decisions.
- Log permit/deny decisions for sensitive operations.
- Test decision changes in non-prod before clinical go-live.
- Cover machine-to-machine FHIR/HL7 clients with client authorization.
- Align emergency access decisions with documented break-glass rules.
- Review decision failures that cause unsafe clinical workarounds.
Real-World Use Cases
How this control shows up in healthcare and HIPAA-covered environments.
EHR order entry authorization
Only credentialed providers with active privileges receive permit decisions for CPOE; students receive supervised limited decisions.
Break-glass decision path
Emergency access triggers a distinct decision path with heightened auditing rather than permanent wide-open roles.
Best Practices
- Explicit decision-point inventory.
- Consistent policy across apps.
- Log sensitive decisions.
- Include non-human clients.
- Test before production changes.
- Pair with AC-25 where applicable.
Common Gaps & Violations
- Authorization only in the UI, not the API.
- Local ACL drift across clinics.
- No logging of deny decisions.
- Service accounts with implicit allow-all.
- Emergency access without decision audit.
Required Documentation
- Access control decision standard (AC-24)
- Decision point architecture
- Policy sources and owners
- Sample decision logs
- Break-glass decision procedure
How to Test & Validate
- Call an API without scope—expect deny and log.
- Verify UI and API enforce the same rule.
- Review break-glass decision audits.
- Spot-check service account authorizations.
- Confirm non-prod promotion path for policy changes.
Audit Considerations
Auditors distinguish role assignment from whether decisions are actually enforced at runtime.
HIPAA Mapping
How this NIST control supports HIPAA Security Rule expectations.
- 164.312(a) Access Control — implement technical policies for access.
- 164.308(a)(4) Information Access Management — isolate and control access.
- 164.312(b) Audit Controls — record access decision activity.
- 164.312(a)(2)(ii) Emergency Access — decisions must still be controlled.
Compliance Tips
- Diagram decision points in the SSP.
- Prefer gateway enforcement for FHIR APIs.
- Measure deny rates for misconfiguration detection.
Frequently Asked Questions
How is AC-24 different from AC-3?
AC-3 requires enforcement of access policy; AC-24 emphasizes establishing and applying the decisions that carry out that enforcement.
Does RBAC alone satisfy AC-24?
Yes if decisions are consistently applied at enforcement points for each ePHI operation.
Related to AC-25?
AC-25 strengthens integrity guarantees for decision and enforcement mechanisms.
References & Resources
- NIST SP 800-53 Rev. 5 — AC-24
- Related controls: AC-3, AC-25, IA-2, AU-2
Related Guidelines
Related controls that commonly accompany AC-24.
Need Help Implementing AC-24?
Our auditors map NIST SP 800-53 controls to your HIPAA Security Rule program — policies, technical evidence, and audit readiness.