AC-3: Access Enforcement

To meet the ac-3: access enforcement requirement, you must technically enforce only the access that your policies and approvals allow, across applications, databases, networks, and cloud services. That means every request is evaluated against a defined authorization model (roles, attributes, rules), and anything not explicitly permitted is blocked and logged. ¹

Key takeaways:

• AC-3 is an enforcement control, not a policy-only control; auditors will look for working technical gates, not just written standards. ²
• Your approval workflow must map to system permissions so that “approved authorization” becomes “implemented permission.” ²
• Evidence needs to show design (who should access what) and operation (proof the system enforces it and catches violations). ²

AC-3: Access Enforcement sits at the point where governance either becomes real or fails in production. You can have a strong access control policy, clean org charts, and well-defined data owners, but AC-3 is about whether the system actually blocks unauthorized logical access to information and system resources. ²

For a Compliance Officer, CCO, or GRC lead, operationalizing AC-3 means translating “approved authorizations” into a permissions architecture and operating routine that is consistent across identity providers, SaaS applications, cloud control planes, endpoints, APIs, and databases. The control also becomes a dependency for many other requirements: if you cannot prove enforcement, your access reviews, separation of duties, incident response, and third-party boundary controls become harder to defend.

This page gives requirement-level implementation guidance you can hand to IAM, Security Engineering, and application owners. It focuses on what to build, what to check, what to retain as evidence, and how to avoid the common failure mode: approvals happen in tickets or spreadsheets, but entitlements drift in production.

Regulatory text

Requirement excerpt: “Enforce approved authorizations for logical access to information and system resources in accordance with applicable access control policies.” ¹

Operator meaning:

• “Enforce” means technical controls must prevent actions that are not allowed, across systems in scope. A PDF policy or a manager approval alone does not enforce anything. ²
• “Approved authorizations” means access must be granted based on documented approval routes (system owner, data owner, HR-driven role assignment, etc.) and those approvals must map to specific entitlements. ²
• “In accordance with applicable access control policies” means your enforcement logic must implement your policy choices (least privilege, role-based access, attribute rules, exceptions, emergency access). ²

Plain-English interpretation (what AC-3 is asking you to prove)

You need to prove that:

1. You have defined who is allowed to access which information and resources, and under what conditions (the authorization model).
2. Your systems consistently apply that model at the time of access (the enforcement points).
3. When access is not approved, the system denies it and you can show evidence of that denial and the control’s ongoing health. ²

A practical way to explain AC-3 to operators: “If someone gets access they shouldn’t have, can we show where enforcement failed, and can we stop it from happening again without rewriting the entire program?”

Who it applies to (entity and operational context)

AC-3 is relevant wherever NIST SP 800-53 is used as a baseline, including:

• Federal information systems and programs aligned to NIST SP 800-53. ²
• Federal contractors and service organizations handling federal data or operating systems that must meet NIST 800-53-aligned expectations. ²

Operationally, AC-3 applies to:

• Workforce identities (employees, contractors) and non-human identities (service accounts, API keys, workload identities).
• Systems that store/process sensitive information (regulated data, customer data, federal data) and the infrastructure that controls it (cloud IAM, network segmentation, privileged access tooling).
• Third-party access paths (support portals, shared admin consoles, integrations) where an external entity can gain logical access.

What you actually need to do (step-by-step)

Step 1: Create the AC-3 control card (owner, triggers, boundaries)

Write a one-page runbook that answers:

• Control objective: enforce only approved logical access. ²
• Control owner: typically IAM lead or Security Engineering; GRC owns oversight.
• In-scope systems: identity provider, major SaaS, cloud accounts/subscriptions, production apps, databases, CI/CD, support tooling.
• Trigger events: new hire, role change, termination, vendor onboarding, privileged elevation, new system go-live, incident/emergency access.
• Exception rules: break-glass, time-bound access, compensating monitoring, approval requirements.

This becomes your “operator contract” during audits: who runs AC-3 and how.

Step 2: Define your authorization model in enforceable terms

Pick an authorization approach per system class (you can mix approaches, but document it):

• RBAC: roles map to job functions; roles map to permission sets.
• ABAC/policy-based: attributes (department, clearance, environment) drive decisions.
• Resource-based policies: permissions live with the resource (common in cloud).

Minimum artifacts:

• Role catalog (business role → technical groups/permission sets).
• Data/resource ownership mapping (who approves access to what).
• Privileged access definitions (what counts as admin, what tools grant it).

Step 3: Map approvals to provisioning pathways (close the “ticket-to-permission” gap)

For each access type, document the path from request to enforcement:

• Request intake (ITSM, IAM portal, access request workflow).
• Required approvers (manager, system owner, data owner).
• Provisioning mechanism (SSO group sync, SCIM, IaC, cloud IAM pipeline).
• Deprovisioning mechanism (HR feed, disable account, remove from groups, rotate keys).

Audit focus: you must be able to point from an approval to the actual entitlement in the system.

Step 4: Implement enforcement points and default-deny behavior

List the actual technical gates, by layer:

• Identity layer: SSO + MFA policies; group membership gates application access.
• Application layer: app roles, permission checks, administrative UI restrictions.
• Data layer: database roles, row/column controls where used, controlled query interfaces.
• Cloud control plane: IAM roles, permission boundaries, SCPs/organizations policies where used.
• Network layer: segmentation, private endpoints, firewall rules (where applicable to logical access).

Operator check: confirm that “no approval” equals “no access,” not “access until someone notices.”

Step 5: Instrument logging and monitoring for enforcement outcomes

AC-3 becomes defensible when you can show:

• Allow/deny decisions (where available).
• Privilege changes (role grants, group changes).
• Admin actions and policy changes that affect access control.

Centralize logs where feasible and protect them from tampering. Even if AC-3 does not prescribe a specific logging stack, exams commonly ask how you would detect bypass or misconfiguration.

Step 6: Run recurring control health checks (prove ongoing operation)

Set an operating cadence that checks:

• Orphaned accounts and stale access paths (especially third-party access).
• Privileged role assignments and exceptions.
• Drift between defined roles and actual entitlements.
• Systems not integrated to your identity provider (common AC-3 gap).

Track findings to closure with due dates and evidence of remediation. ²

Step 7: Build an exception process that auditors can follow

Exceptions are normal; unmanaged exceptions break AC-3. Minimum exception requirements:

• Business justification
• Approver and expiration
• Compensating controls (enhanced monitoring, limited scope)
• Proof of removal at end of exception period

Daydream can help here by turning AC-3 into a repeatable control card with a standard evidence bundle and a queue of control-health tasks tied to owners, so “approved authorization” stays linked to “implemented permission” over time.

Required evidence and artifacts to retain

Use an “evidence bundle” per system and per review cycle. Keep:

• AC-3 control card/runbook with owner, scope, triggers, and exceptions.
• Access control policy references and system-specific standards/procedures. ²
• Role/entitlement mapping (role catalog, group-to-permission mapping, cloud role definitions).
• Samples of access requests and approvals mapped to implemented permissions (ticket → group/role assignment → effective access proof).
• Configuration evidence: screenshots/exports of IAM policies, permission sets, application role configs, conditional access rules (as applicable).
• Change records for access policy changes (approvals, peer review where used).
• Logs or reports showing enforcement and/or denied attempts (where the platform produces them).
• Control health check results, issues list, and closure evidence.

Retention location matters. Auditors want a stable repository with access controls around the evidence itself.

Common exam/audit questions and hangups

Questions you should be ready to answer

• “Show me how an approved request becomes effective access in System X.”
• “What prevents a system admin from granting access outside the process?”
• “How do you enforce access for non-human identities and integrations?”
• “What happens when someone changes roles or leaves?”
• “Which systems are not on SSO, and how do you enforce access there?”
• “Show evidence the control operates, not just that it’s designed.” ²

Hangups auditors raise

• Inconsistent enforcement between cloud, SaaS, and custom apps.
• Manual provisioning with no reconciliation.
• No clear owner for access models in line-of-business apps.
• Exceptions that never expire.

Frequent implementation mistakes (and how to avoid them)

1. Policy-only compliance. You have an access policy, but no proof of technical denial for unauthorized access.

   • Fix: inventory enforcement points and collect config evidence per system.

2. Approvals stored separately from entitlements. A ticket is approved, but permissions are granted manually and later drift.

   • Fix: standardize provisioning paths (SSO/SCIM/IaC) and require a link from request to entitlement.

3. Ignoring service accounts and API keys. Non-human access grows fast and bypasses reviews.

   • Fix: treat non-human identities as first-class principals with ownership, purpose, scope limits, and rotation/deprovision triggers.

4. No exception lifecycle. Break-glass becomes “forever glass.”

   • Fix: expiry, re-approval, and removal evidence.

5. Incomplete scope. Legacy systems, support tools, and third-party access paths get missed.

   • Fix: maintain a living system inventory that flags “not integrated” systems and tracks compensating controls.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page focuses on audit defensibility and operational risk.

Operational risk is straightforward: if you cannot prove enforcement, unauthorized access becomes a plausible root cause for data exposure, service disruption, and integrity failures. AC-3 is often where assessors decide whether your access management is real or aspirational because it ties policy, approvals, and system behavior together. ²

Practical 30/60/90-day execution plan

First 30 days: Stabilize scope and accountability

• Assign an AC-3 control owner and publish the control card (scope, triggers, exceptions).
• Inventory in-scope systems and identify top enforcement points (IdP, cloud IAM, key SaaS, production apps).
• Define the minimum evidence bundle and create a single evidence repository structure.
• Pick two high-risk systems and build the “approval → entitlement → effective access” trace end-to-end.

Days 31–60: Standardize enforcement and reduce manual paths

• Build/refresh role catalogs and group/permission mappings for priority systems.
• Integrate key apps to SSO/central IAM where feasible; document compensating controls where not feasible.
• Implement or tighten privileged access paths (admin role grants, break-glass workflow, logging).
• Start control health checks and track remediation items to closure.

Days 61–90: Prove operation and extend coverage

• Expand traceable workflows to remaining critical systems.
• Add non-human identity governance (ownership, purpose, scope, lifecycle).
• Run an internal mini-audit: sample access grants, verify approvals, verify enforcement, verify logging.
• Put AC-3 on an ongoing operating cadence with evidence capture built into the workflow (Daydream is a natural place to manage the control card, evidence bundle, and remediation tracking across system owners).

Frequently Asked Questions

Does AC-3 require role-based access control (RBAC)?

AC-3 requires enforcement of approved authorizations, not a specific model. RBAC is common because it’s auditable, but policy-based and resource-based approaches can also satisfy AC-3 if approvals map cleanly to enforced permissions. ²

What counts as “approved authorization” in practice?

An approved authorization is whatever your access control policy and procedures define as a valid approval route, such as manager + system owner approval or HR-driven role assignment. You must be able to trace that approval to the implemented entitlement in the target system. ²

How do we handle systems that cannot integrate with SSO?

Document the system as an exception in scope management, define a manual provisioning and deprovisioning workflow, and add compensating controls such as tighter admin restrictions and stronger monitoring. Keep evidence that the workflow is followed and reviewed.

Are logs required to meet AC-3?

AC-3’s text focuses on enforcement, but audits commonly expect evidence that enforcement is operating. Logs, reports, or platform audit trails often become the most practical proof when paired with configuration snapshots. ²

How should we treat third-party access under AC-3?

Treat third parties as identities that need explicit approval, least-privilege entitlements, and lifecycle controls tied to contract end or access end. Your evidence should show who approved the access and how the system enforces the boundary.

What’s the fastest way to make AC-3 audit-ready?

Start with a narrow set of high-risk systems, build a clean approval-to-entitlement trace with configuration evidence, and run a repeatable health check that generates artifacts every cycle. Then expand system coverage without changing the underlying method.

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5