AC-3(4): Discretionary Access Control

AC-3(4): discretionary access control requirement shows up when your environment allows a user to pass along access to data they can already see, such as sharing a folder, granting a role to a teammate, delegating mailbox access, adding someone to a workspace, or changing an object’s ACL. If you do not define and enforce guardrails, the result is permission sprawl: sensitive objects become readable by unintended users through “helpful” sharing, inherited groups, or ad hoc delegation.

This requirement is an enhancement to access enforcement: your policy must state which subjects (users, service accounts, processes) and objects (files, records, databases, buckets, SaaS workspaces) are covered, and the system must enforce the discretionary rules for those covered items ¹. For operators, the fastest path is to (1) pick where DAC is allowed, (2) define what a permitted “re-share” looks like, (3) restrict permission changes to controlled roles or workflows, and (4) preserve proof that the controls operate.

Regulatory text

Excerpt (verbatim): “Enforce {{ insert: param, ac-3.4_prm_1 }} 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 with this text

• Define the policy parameter(s). The excerpt includes a variable parameter. In practice, you must fill in what “discretionary access control” means for your organization: who can grant access, to what objects, using which mechanisms, with which limits ³.
• Specify scope explicitly. Your policy must name the covered subjects (e.g., workforce users, admins, service accounts) and covered objects (e.g., shared drives, case management records, cloud buckets, SaaS workspaces) where DAC is permitted or prohibited ².
• Enforce it technically. “Enforce” means the system prevents out-of-policy sharing/permission changes, or routes them through an approved path you control ³.

Plain-English interpretation

If a user can access information, DAC is the set of features that let that user share it onward or change who else can access it. AC-3(4) requires you to decide when that is allowed and then enforce those rules, so access does not spread through informal sharing.

Practical framing for a CCO/GRC lead:

• You are not trying to stop collaboration.
• You are trying to make “sharing” a governed action with boundaries, audit trails, and clear accountability.

Who it applies to (entity and operational context)

This applies to organizations operating systems aligned to NIST SP 800-53, including:

• Federal information systems and service organizations supporting them ³
• Federal contractors and contractor systems handling federal data ³

Operationally, prioritize systems where end users can grant access without admin involvement:

• Enterprise file sharing and collaboration (shared drives, document platforms)
• SaaS workspaces (tickets, CRM, HRIS, product analytics)
• Cloud data stores with ACLs (object storage, data lakes)
• Internal apps with record-level sharing or delegation features
• Third-party platforms where your users can invite external collaborators (third party risk angle)

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

1) Build a “DAC inventory” (where sharing/permission delegation exists)

Create a table with columns: System, Object types, Permission model (RBAC/ABAC/DAC hybrid), Sharing actions available to end users, External sharing possible, Admin controls, Logs available, Owner.

Minimum output: a scoped list of “covered subjects and objects” aligned to policy language ².

2) Decide your DAC rules (policy decisions you must make explicit)

Write rules that answer:

• Who can grant access? Owner only, managers, data stewards, admins, or specific roles.
• What can they grant? Read-only vs edit vs reshare/grant.
• To whom? Internal only, specific domains, approved third parties, no personal accounts.
• How is it granted? Through groups only, via access request workflow, time-bound access, or direct ACL edits.
• What is prohibited? Public links, “anyone with link,” external invites, privilege escalation via sharing.

Keep rules testable. If an auditor asks “show me where the system blocks external sharing,” you should be able to point to a setting, control, or workflow.

3) Implement technical enforcement (not just policy)

Common enforcement patterns:

• Centralize grants through groups/roles. Reduce direct object-level ACL edits. Where possible, restrict “share” to adding users to pre-approved groups.
• Limit who can change permissions. Convert “everyone can share” into “only owners/stewards can share,” and separate “can edit content” from “can manage access.”
• Block or constrain external sharing. If you must allow it, require allowlisted domains and an approval step tied to third party onboarding.
• Require authenticated access; disable anonymous links. If anonymous links are required for a business process, constrain by time and content type and log the exception.
• Log all permission changes. Capture who granted access, what object, what permission, when, and how it was approved.

Your goal is simple: a user can only pass access forward in the exact ways your policy allows ³.

4) Put a workflow around exceptions

DAC always collides with real work. Don’t pretend it won’t.

• Define an exception type (temporary external share, emergency access, one-off delegation).
• Require business justification, data classification, approver, expiration, and revocation owner.
• Track exceptions in a register with closure evidence.

5) Operate the control on a recurring cadence (control health)

Auditors expect sustained operation, not a one-time configuration.

• Review a sample of recent permission changes and validate they match policy.
• Check for drift: new systems, new object types, new sharing features.
• Track remediation to closure with an owner and due date.

If you use Daydream, this is where a requirement control card and recurring health checks remove ambiguity: owner, triggers (new system onboarding, new sharing feature rollout), and the minimum evidence bundle stay consistent across audits ³.

Required evidence and artifacts to retain

Retain evidence that proves policy definition, technical enforcement, and operational monitoring:

Policy & scope

• Access control policy section defining discretionary access control rules and the covered subjects/objects ²
• Data classification mapping that drives stricter sharing rules for sensitive objects

Technical configuration

• Screenshots/exports of sharing settings (e.g., external sharing disabled, domain allowlist, owner-only permission changes)
• Configuration-as-code snippets or change records where available
• Role/group definitions showing who can manage permissions

Operational evidence

• Permission change logs (audit logs) with at least: actor, target object, privilege granted, timestamp
• Access request tickets/approvals for grants that require workflow
• Exception register with approvals, expirations, and revocation evidence
• Control health check results and remediation tickets to validated closure

Common exam/audit questions and hangups

• “Which systems are in scope for DAC, and why?” Expect to show your DAC inventory and the policy mapping to covered subjects/objects ².
• “Can an end user share data externally? Show me guardrails.” Be ready with configuration evidence and an example request/approval path.
• “How do you prevent permission escalation via sharing?” Auditors look for separation between content editing and permission management.
• “How do you detect inappropriate sharing?” You need audit logs and review evidence, not verbal assurances.
• “What happens when a third party is invited into a workspace?” Tie it to third party intake, minimum access, and termination/offboarding.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails AC-3(4)	Fix that works in practice
Policy says “users must share responsibly”	Not enforceable; no defined DAC rules 3	Replace with explicit allowed actions, roles, and object scope
Allowing direct ACL changes by broad user populations	Creates untracked privilege expansion	Restrict permission management to owners/stewards; prefer groups
External sharing left “on” by default	High likelihood of accidental disclosure	Default deny; allowlist domains; require approvals
No logs retained for permission changes	You can’t prove enforcement or investigate	Enable and retain audit logs; centralize log access for audits
Exceptions handled in chat/email	No traceability	Use a ticketed workflow with expiration and revocation proof

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite specific actions.

Risk-wise, DAC failures commonly show up as:

• Data exposure through “anyone with link” sharing
• Persistent access for former project members or external collaborators
• Privilege escalation where users grant access beyond business need

For a CCO/GRC lead, the compliance risk is twofold: unauthorized disclosure and inability to produce evidence that sharing controls are defined and enforced ³.

A practical 30/60/90-day execution plan

Days 0–30: Define scope and rules that can be tested

• Name an owner for AC-3(4) and document triggers (new systems, new collaboration features).
• Build the DAC inventory for your highest-risk systems first (collaboration, CRM, ticketing, cloud storage).
• Draft DAC rules: internal vs external sharing, who can grant, which objects are restricted, and which actions require approval ².
• Define the minimum evidence bundle and where it will be retained.

Days 31–60: Implement enforcement and logging

• Configure systems to match policy: owner-only permission changes, disable anonymous links, restrict external sharing, enforce group-based access where feasible.
• Turn on audit logs for permission changes and validate you can reconstruct “who granted what to whom.”
• Stand up the exception workflow and exception register.

Days 61–90: Prove operation and close gaps

• Run the first control health check: sample permission changes, validate approvals, verify expirations and revocations.
• Remediate drift: tighten settings, remove unauthorized external collaborators, fix overbroad groups.
• Package evidence for audit: policy excerpt, configs, logs, samples, and remediation closure notes.
• If you manage controls in Daydream, convert the above into a control card with owner, run steps, and recurring checks so the control survives staff turnover ³.

Frequently Asked Questions

Does AC-3(4) mean we must allow discretionary access control?

No. It requires enforcement of DAC rules where your policy permits DAC for covered subjects and objects. Many teams restrict DAC heavily and document that limitation in policy ².

What counts as a “subject” and an “object” for scoping?

Subjects include users, admins, and service accounts that can grant or pass access. Objects include files, records, folders, buckets, and SaaS resources with permissions or sharing controls ³.

We use RBAC. Do we still need AC-3(4)?

If your tools let users delegate access (invites, sharing links, object ACLs), you still have discretionary behavior layered on top of RBAC. Scope AC-3(4) to those features and enforce guardrails.

How do we handle external sharing to a third party for a project?

Treat it as a governed event: require an access request, confirm the third party is approved to receive the data type, restrict permissions, and set an expiration with a named revocation owner.

What evidence is most persuasive in an audit?

Auditors respond well to (1) a clear policy statement defining allowed discretionary actions, (2) system settings that enforce it, and (3) logs or tickets showing permission changes followed the process ³.

What’s the fastest way to reduce risk without breaking collaboration?

Start by separating “edit content” from “manage access,” disable anonymous/public links, and force external sharing through a short approval workflow with time-bound access.

Footnotes

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

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

3. NIST SP 800-53 Rev. 5