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.
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.
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.