AC-3 Access Control

Access Enforcement

High Risk Moderate Medium Cost

AC-3 requires the information system to enforce approved authorizations for logical access to information and system resources. Where AC-2 decides who gets an account and which roles they hold, AC-3 is the technical gate: permissions, ACLs, claims, and application rules that actually allow or deny actions on ePHI and supporting systems.

Control Objective

Make sure access decisions written in policy and provisioning tickets are enforced by the system at the moment a user tries to read, write, or administer data.

Implementation Guidance

  1. Choose an access-control model per platform (RBAC, ABAC, or hybrid) and document how roles map to permissions.
  2. Enforce authorization in the application and data layer — not only at the network perimeter.
  3. Deny by default: users receive only the permissions their approved role grants.
  4. Separate read, write, export, print, and admin capabilities in EHR and document systems where the product allows.
  5. Protect administrative interfaces (EHR config, IdP admin, database consoles) with stricter roles and MFA.
  6. Review effective permissions after role changes; do not assume removing a user from one group clears all paths.
  7. For file shares and cloud drives that may hold ePHI, replace open 'Everyone' grants with named security groups.
  8. Log authorization failures and privileged overrides (break-glass) for audit review.

Real-World Use Cases

How this control shows up in healthcare and HIPAA-covered environments.

Front-desk vs clinical chart access

Registration staff need demographics and scheduling, not full clinical notes. AC-3 role packs in the EHR grant front-desk functions only. When a clerk's curiosity browsing is attempted, the system denies chart sections outside that role — and the denial is logged.

Imaging share left wide open

A radiology export folder on a file server allows Domain Users modify rights. AC-3 remediation replaces that with a radiology-tech group and read-only for referring-provider group, matching the access matrix from your risk analysis.

Cloud analytics extract

A BI tool connects to an EHR warehouse. AC-3 enforced via service principal scopes and row-level security so analysts see only the clinics and data classes approved for quality reporting — not unrestricted production PHI dumps.

Best Practices

  • Maintain a living access-control matrix (role × system × permission).
  • Prefer groups/roles over direct user ACLs.
  • Test 'negative cases' (user should NOT see X) during go-lives.
  • Re-validate enforcement after EHR upgrades and module activations.
  • Pair with AC-6 least privilege so roles stay narrow.
  • Treat break-glass access as an enforced exception path with monitoring — not a permanent elevated role.

Common Gaps & Violations

  • Policy says role-based access, but many users are in 'All Clinical Staff' with near-admin rights.
  • Network login works, yet file shares still use Everyone/Full Control.
  • Application permissions drifted from the documented matrix after years of one-off tickets.
  • Reports and exports bypass screen-level EHR controls.
  • No enforcement testing — only screenshots of role names.

Required Documentation

  • Access control policy referencing technical enforcement
  • Role/permission matrix for systems with ePHI
  • Configuration baselines (EHR roles, IdP apps, NTFS/cloud ACLs)
  • Break-glass authorization procedure
  • Evidence of periodic effective-access reviews

How to Test & Validate

  1. Authenticate as a low-privilege test user and attempt actions outside the role; confirm deny.
  2. Authenticate as an approved role and confirm required job functions still work.
  3. Inspect group nesting / role inheritance for unintended privilege paths.
  4. Sample export/print/API paths that might bypass UI controls.
  5. Review break-glass events for the last quarter.

Audit Considerations

Assessors will ask you to demonstrate enforcement live (or via recorded walkthrough), not only list role names. Bring the matrix and show how a real job role maps to system permissions.

HIPAA Mapping

How this NIST control supports HIPAA Security Rule expectations.

  • 164.312(a)(1) Access Control — technical policies and procedures for systems that maintain ePHI to allow access only to authorized persons or software.
  • 164.308(a)(4)(ii)(B) Access Authorization — policies for granting access to ePHI must be backed by technical enforcement.
  • 164.308(a)(4)(ii)(C) Access Establishment and Modification — changes to access rights should be reflected in enforced permissions.
  • 164.312(a)(2)(i) Unique User Identification — enforcement depends on tying actions to distinct identities.

Compliance Tips

  • After every major EHR optimization project, run an access-enforcement regression test.
  • Include 'effective access' reports (not just assigned roles) in quarterly reviews.
  • Document compensating controls where a legacy system cannot enforce fine-grained AC-3.

Frequently Asked Questions

Is AC-3 the same as authentication?

No. Authentication (IA family) proves identity. AC-3 decides what that identity is allowed to do after logon.

What if our EHR cannot separate permissions finely enough?

Enforce what the product allows, restrict residual risk with monitoring, workforce agreements, and physical controls, and record the limitation in your risk analysis.

Do APIs and interfaces need AC-3?

Yes. Interface accounts and API clients must be authorized for only the transactions they need.

References & Resources

  • NIST SP 800-53 Rev. 5 — AC-3 Access Enforcement
  • NIST SP 800-162 Guide to ABAC
  • HIPAA Security Rule §§ 164.308(a)(4), 164.312(a)
  • Related controls: AC-2, AC-5, AC-6, AU-2, IA-2

Need Help Implementing AC-3?

Our auditors map NIST SP 800-53 controls to your HIPAA Security Rule program — policies, technical evidence, and audit readiness.