AC-3(4): Discretionary Access Control

AC-3(4) requires you to enforce a discretionary access control (DAC) policy that clearly defines which users (subjects) can access which resources (objects), and what those users are allowed to do with information after access is granted. To operationalize it, you must define DAC rules for in-scope systems, implement them in your access mechanisms, and retain evidence that DAC decisions are consistently enforced. ¹

Key takeaways:

• Define “subjects,” “objects,” and allowed post-access actions in a DAC policy that fits your environment. ²
• Implement DAC enforcement in the systems that actually mediate access (OS, databases, collaboration tools, SaaS, and apps). ²
• Keep audit-ready evidence: configuration exports, access control lists, test results, exceptions, and recurring control health checks. ²

Discretionary Access Control is where access decisions are driven by rules your organization defines and administers, typically down to the “who can do what to which resource” level. AC-3(4) is a control enhancement under NIST SP 800-53 that pushes you to do two things operators often skip: (1) write down a real DAC policy that specifies the covered subjects and objects, and (2) enforce that policy so user actions after access is granted are constrained the way you intended. ²

For a CCO, compliance officer, or GRC lead, the practical problem is rarely the concept. It’s scoping and proof. Auditors and customers will ask which systems are in scope, where DAC is enforced, how you prevent “permission drift,” and whether users who can read information can also copy, print, share, or re-permission it without control. AC-3(4) is also a common dependency control: if you cannot show disciplined DAC enforcement, it undermines incident containment, least privilege, data handling, and third-party data segmentation claims.

This page is a requirement-level runbook: define the policy, wire it into technical controls, and produce evidence that survives an audit.

Regulatory text

Requirement (excerpt): “Enforce [organization-defined discretionary access control policy] over the set of covered subjects and objects specified in the policy, and where the policy specifies that a subject that has been granted access to information can do one or more of the following:” ¹

What the operator must do:

1. Write a discretionary access control policy that explicitly defines:
   • Covered subjects (the actors that request access, such as workforce identities, service accounts, and processes).
   • Covered objects (resources like files, database tables, records, mailboxes, repositories, buckets, APIs, and application functions).
   • Allowed actions after access is granted, based on what your policy chooses to control (for example: read-only vs. edit vs. delete; ability to share; ability to change permissions; ability to export). ²
2. Enforce the policy using the mechanisms that actually decide and enforce access in your environment (identity provider, OS permissions, database grants, application authorization, collaboration platform sharing controls, and endpoint controls). ²
3. Demonstrate it’s operating with traceable evidence tied to systems, identities, and configuration states. ²

Plain-English interpretation (what AC-3(4) is really asking)

AC-3(4) expects you to treat discretionary permissions as a governed capability, not an organic byproduct of tools. If a user or process is granted access to information, your policy must define what they are allowed to do next, and your systems must enforce that definition. ²

In practice, this control is about preventing the “I can access it, therefore I can do anything with it” problem. The most common operational gap is uncontrolled downstream behavior: users can re-share sensitive folders, grant others access, create public links, copy regulated data into uncontrolled locations, or elevate privileges through inherited permissions.

Who it applies to (entity + operational context)

AC-3(4) is relevant for:

• Federal information systems and programs aligned to NIST SP 800-53. ³
• Federal contractors and service organizations handling federal data, where NIST 800-53 controls are imposed contractually or through an authorization boundary. ³

Operationally, it applies wherever you have:

• Named users and service accounts accessing information systems.
• Shared data stores (file shares, collaboration sites, code repos, ticketing tools, CRM).
• Application-level authorization (roles, entitlements, object-level permissions).
• Third-party access (support vendors, consultants, and integrated tools) where “subject” includes non-employees.

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

1) Build a “control card” for AC-3(4)

Create a one-page runbook that answers: owner, scope, how it runs, how exceptions work, and what evidence proves it. This eliminates the common audit failure: “policy exists but nobody can show operation.” ²

Minimum fields:

• Control objective (DAC policy defined and enforced)
• Control owner (IAM lead, security engineering, app owner)
• In-scope systems list (by system of record)
• Trigger events (new system onboarding, role changes, major releases, M&A)
• Operating cadence (health checks and sampling)
• Exception process (risk acceptance + compensating controls)
• Evidence bundle + retention location

2) Define the discretionary access control policy (make it enforceable)

Write the policy so an engineer can map it to configurations:

• Subjects: workforce users, privileged admins, service accounts, third-party identities. ²
• Objects: data repositories and functional objects (e.g., “customer record export function”). ²
• Decision rules: how permissions are granted (role-based groups, request/approval, ticketed changes).
• Post-access constraints: decide which actions you control and where:
  • Permission delegation (can the subject grant others access?)
  • Sharing/link creation (internal-only, domain-restricted, no public links)
  • Export/download (allowed only for certain roles)
  • Delete/modify (restricted for records of record)
  • Administrative permission changes (restricted to limited admins)

Write at least one table that maps object category → allowed actions → approval requirement → enforcing system. A DAC policy without an enforcement mapping is hard to defend in an exam.

3) Scope covered subjects and objects (avoid “boil the ocean”)

Start with the systems that store or process your most sensitive data and the systems most likely to enable uncontrolled sharing:

• Collaboration/content platforms
• File storage and shared drives
• Databases and data warehouses
• Core business apps (CRM, ticketing)
• Source code repos

Document scoping decisions and exclusions with rationale. Auditors accept prioritization when it’s explicit and risk-based.

4) Implement enforcement where access decisions are made

Typical enforcement points:

• Identity provider / directory: groups, role assignments, and lifecycle controls.
• OS / file permissions: ACLs, group ownership, inheritance rules.
• Databases: grants, roles, schema/table permissions.
• SaaS collaboration: sharing restrictions, external collaboration settings, default link permissions.
• Applications: authorization middleware; role/entitlement checks; object-level access control.

Operational requirement: for each in-scope system, identify the “policy enforcement point” (PEP) and the system-of-record for entitlements. Then ensure the DAC rules are implemented there, not in an outdated spreadsheet.

5) Put guardrails around permission delegation and sharing

DAC often breaks when subjects can propagate access without oversight. Pick one of these models per system:

• Owner-managed with constraints: users can share only within the organization and cannot grant higher privileges than they have.
• Admin-managed: only designated admins can change permissions for sensitive objects.
• Hybrid: owners can propose changes; admin approves and applies.

Tie the model to sensitivity tier. Make “who can change permissions” a first-class control objective, not an afterthought.

6) Test the control (prove enforcement, not intent)

Create repeatable tests:

• Attempt to access a restricted object from an unauthorized subject.
• Attempt disallowed actions from an authorized subject (e.g., read allowed; export blocked).
• Attempt permission delegation beyond allowed bounds.

Retain evidence: test scripts, screenshots, logs, or automated test output linked to the system and date.

7) Run recurring control health checks and remediate drift

Permission drift is inevitable. Schedule health checks that look for:

• Orphaned permissions (users who left roles but still have access)
• Overly broad groups
• Public/external sharing
• Direct user grants where group-based was required
• Privileged access outside PAM or break-glass

Track findings to closure with due dates and validation. This directly addresses a known risk factor: teams often cannot show ownership, frequency, or evidence that proves the control is operating. ²

Required evidence and artifacts to retain

Keep an “AC-3(4) evidence bundle” per in-scope system:

Policy + governance

• Approved DAC policy and standards
• System scope list (subjects/objects coverage statement)
• Exception register entries and approvals

Technical configuration

• Screenshots/exports of ACLs, role definitions, group memberships (point-in-time)
• SaaS sharing configuration exports (where available)
• Application authorization configuration (role matrix, entitlement config)

Operational execution

• Access reviews or permission audits relevant to DAC rules
• Test cases and test results showing enforcement
• Tickets/PRs that implemented changes
• Control health check reports and remediation tracking

Retention

• Store in a controlled repository with immutable history where feasible (GRC tool, evidence vault, or version-controlled repository).

Daydream fit: many teams use Daydream to standardize the control card, attach minimum evidence bundles, and run recurring control health checks with remediation tracking so audits don’t turn into a scavenger hunt.

Common exam/audit questions and hangups

Expect these questions:

• “Show me your discretionary access control policy and the systems it covers.” ¹
• “Who are the subjects and what are the objects in System X?”
• “Who can change permissions or share data externally?”
• “Prove enforcement: demonstrate a denied action that your policy prohibits.”
• “How do you detect and correct permission drift?”
• “How do you handle third-party identities and service accounts under DAC?”

Hangups that trigger findings:

• Policy exists but no mapping to systems and enforcement points.
• Evidence is screenshots without context, date, or system identifier.
• Controls rely on “users should not share” training, without technical enforcement.
• Exceptions exist informally and cannot be enumerated.

Frequent implementation mistakes (and how to avoid them)

1. Treating DAC as only file permissions. Many of your highest-risk objects live in SaaS apps and databases. Include application authorization and sharing settings in scope.
2. Letting object owners grant permissions without guardrails. If owners can grant access broadly, define constraints and monitoring.
3. No explicit rule for “what happens after read access.” Decide whether export, copy, print, and re-sharing are allowed for sensitive objects and enforce those decisions where possible.
4. Evidence mismatch. Auditors need to see: policy requirement → system configuration → test or operational check. Keep the chain intact.
5. One-time implementation. Drift turns a good design into a failing control. Run health checks and track remediation with validation. ²

Risk implications (why this control matters operationally)

Weak DAC enforcement commonly leads to:

• Unauthorized access through inherited permissions or stale group membership
• Excessive internal sharing that expands breach blast radius
• Third-party access sprawl (support accounts, integrations)
• Inability to prove segmentation and controlled handling of federal or regulated data

For regulated programs, this shows up as an authorization boundary weakness: you cannot credibly claim you control access if subjects can redistribute access without policy constraints and monitoring.

Practical 30/60/90-day execution plan

First 30 days (establish control ownership + scope + policy draft)

• Name a control owner and backups; publish the AC-3(4) control card. ²
• Inventory in-scope systems that store or process sensitive data; identify enforcement points.
• Draft the DAC policy with a subjects/objects table and post-access actions you will control.
• Define an exceptions process and evidence bundle checklist.

Days 31–60 (implement enforcement in priority systems + initial testing)

• Implement DAC rule configurations in the highest-risk systems first (collaboration, file storage, core data stores).
• Lock down permission delegation and external sharing where policy requires it.
• Create a standard test plan and execute it for each priority system; store results in the evidence repository.
• Start a remediation backlog for permission drift findings.

Days 61–90 (operationalize: health checks, metrics, audit readiness)

• Establish recurring access/permission health checks with clear owners and due dates. ²
• Integrate DAC checks into change management (new apps, new repositories, new integrations).
• Run an internal “audit simulation”: pick a system, trace policy → config → enforcement test → drift remediation evidence.
• Close top remediation items and document accepted residual risks as formal exceptions.

Frequently Asked Questions

What counts as “subjects” and “objects” for AC-3(4)?

Subjects are the actors that request access, including employees, admins, service accounts, and third-party identities. Objects are the resources being accessed, such as files, records, tables, repositories, and application functions. ²

Does AC-3(4) require users to manage access themselves?

No. The control requires an organization-defined discretionary access control policy and enforcement of that policy. Your policy can allow owner-managed permissions, admin-managed permissions, or a hybrid, as long as it is defined and enforced. ¹

How do we prove “enforcement” in an audit?

Show the written policy, the system configuration that implements it, and a test or log evidence demonstrating denied or constrained actions per the policy. Pair that with recurring health check outputs that identify and correct drift. ²

We have RBAC. Do we still need DAC?

Many environments use RBAC as the primary mechanism, but discretionary permissions still exist in file shares, collaboration tools, and application-level sharing. AC-3(4) focuses on enforcing your defined discretionary policy over covered subjects and objects. ²

How should we handle third-party access under AC-3(4)?

Treat third-party identities as subjects in scope when they can access your objects. Require the same entitlement process, limit permission delegation, and retain evidence of approval, configuration, and periodic review for those accounts. ²

What’s the minimum evidence set we should standardize across systems?

Standardize on: (1) system scope statement, (2) configuration export or screenshot set, (3) enforcement test results, (4) exception records, and (5) recurring health check report with remediation tracking. This aligns to the audit expectation that you can show ownership, operating cadence, and traceable evidence. ²

Footnotes

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

2. NIST SP 800-53 Rev. 5 PDF

3. NIST SP 800-53 Rev. 5