AC-3(15): Discretionary and Mandatory Access Control

AC-3(15) requires you to enforce both discretionary access control (DAC) and mandatory access control (MAC) rules—exactly as defined in your access control policy—across the specific users/processes (“subjects”) and data/resources (“objects”) you designate as covered. To operationalize it, you must define the DAC/MAC model, map it to systems and data, implement technical enforcement, and keep assessor-ready evidence. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Key takeaways:

• Write a policy-level decision: where you use DAC, where you require MAC, and what “covered subjects and objects” means in your environment.
• Implement enforcement in the control plane (IAM), data plane (labels/ACLs), and workload plane (OS/app controls), then test it continuously.
• Evidence is the control: configuration exports, label/ACL mappings, authorization tests, and exceptions with approvals.

The ac-3(15): discretionary and mandatory access control requirement is easy to misunderstand because most organizations already “do access control,” but do not explicitly run both DAC and MAC in a way that is provable to an assessor. AC-3(15) is not asking for a generic role-based access control story. It’s asking you to (1) define the discretionary and mandatory rules you will enforce, (2) define which subjects and objects those rules apply to, and (3) show that enforcement is technical and consistent.

In practice, DAC is the mechanism that allows an authorized user (or a data owner acting under delegated authority) to grant access to an object, usually through ACLs, sharing settings, or group membership management. MAC is the mechanism that prevents subjects from overriding centrally defined rules, typically through classifications/labels and policy decisions made by the system (not the user). AC-3(15) pushes you to be explicit about where user discretion is allowed and where it is prohibited.

This page gives requirement-level implementation guidance for a CCO, GRC lead, or security compliance owner who needs to operationalize AC-3(15) quickly, document it cleanly, and be ready for assessment against NIST SP 800-53 Rev. 5. (NIST SP 800-53 Rev. 5)

Regulatory text

Requirement excerpt: “Enforce {{ insert: param, ac-3.15_prm_1 }} over the set of covered subjects and objects specified in the policy; and” (NIST SP 800-53 Rev. 5 OSCAL JSON)

Operator interpretation of the excerpt:

• You must choose and document what “discretionary and mandatory access control” means for your environment (the parameter is organization-defined in the control catalog). (NIST SP 800-53 Rev. 5 OSCAL JSON)
• You must define the covered subjects (humans, service accounts, processes, devices) and covered objects (datasets, systems, tables, files, queues, APIs) in policy, not in tribal knowledge. (NIST SP 800-53 Rev. 5 OSCAL JSON)
• You must technically enforce both DAC and MAC as specified, then be able to demonstrate the enforcement with repeatable evidence. (NIST SP 800-53 Rev. 5 OSCAL JSON)

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

AC-3(15) requires two distinct access control behaviors:

1. Discretionary Access Control (DAC): Within defined bounds, authorized users or delegated owners can grant or change access to an object (examples: sharing a folder with a group; granting read access to a database view via a ticketed request).

2. Mandatory Access Control (MAC): The system enforces non-bypassable rules based on centrally governed policy (examples: “Restricted” data cannot be accessed from unmanaged devices; “Export-controlled” data cannot be shared outside a specific tenant; workloads without an approved tag cannot query a labeled dataset).

Your job is to define where discretion is allowed and where mandatory rules must override discretion, then prove the enforcement works.

Who it applies to (entity and operational context)

AC-3(15) is most relevant to:

• Federal information systems and contractor systems handling federal data, especially where NIST SP 800-53 is the governing control baseline. (NIST SP 800-53 Rev. 5 OSCAL JSON)
• Environments with mixed access control models, such as:
  • SaaS collaboration + enterprise IAM + data warehouses
  • Cloud infrastructure with service accounts and CI/CD pipelines
  • Multi-tenant systems where customer data separation matters
  • Systems that process regulated, classified, or contract-restricted datasets (even if “classification” is internal labels rather than government classification)

Operationally, this is owned by Security/IAM and platform teams, with compliance and data governance as design authorities.

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

1) Define “DAC” and “MAC” in your policy (and constrain DAC)

Create an AC-3(15) policy addendum or a dedicated section in your Access Control Policy that answers:

• DAC definition: What mechanisms count as discretionary in your environment (ACLs, group-based grants, workspace sharing, repo permissions), and who can exercise that discretion.
• DAC constraints: Which objects can never be shared at discretion, and what approvals are required for discretionary grants.
• MAC definition: What centrally enforced rules exist (labels/classifications, device trust, network zones, tenant boundaries, attribute-based policies), and which system components enforce them.

Output: “AC-3(15) Decision Record” (one page) that an assessor can read in minutes. (NIST SP 800-53 Rev. 5 OSCAL JSON)

2) Specify “covered subjects” and “covered objects” (scope that is testable)

Do not scope this as “all users and all data” unless you can test it. Write a scope statement that is:

• Subject scope examples: workforce identities in IdP; privileged admins; service accounts used by production workloads.
• Object scope examples: production customer data stores; source code repos; regulated data buckets; CI/CD secrets stores.

Output: a maintained inventory list or CMDB slice that names systems, data stores, and identity types in-scope for AC-3(15). (NIST SP 800-53 Rev. 5 OSCAL JSON)

3) Implement DAC enforcement points (how discretion is expressed)

You need consistent, logged, and reviewable ways for discretionary grants to occur:

• Route discretionary access changes through standard workflows (ticket + approval, access request system, or documented admin actions).
• Use groups/roles as the primary discretionary mechanism; minimize direct user-to-object grants where possible to reduce drift.
• Ensure DAC changes generate audit logs (who granted what, to whom, when, for what object).

Implementation examples:

• Collaboration suites: disable “anyone with link” for covered objects; require named principals or managed groups.
• Cloud storage: allow object ACL grants only via a controlled admin group and request workflow.

4) Implement MAC enforcement points (non-bypassable controls)

MAC means the user cannot override the rule by “sharing” or by changing an ACL. Common enforcement patterns:

• Label-based policy enforcement: data labels drive access decisions (ABAC-style), and labels are centrally managed.
• Device- and network-based restrictions: only managed devices or specific network contexts can access certain labels/systems.
• Tenant and boundary enforcement: strict separation between environments and customers; no cross-tenant access without break-glass.

What auditors look for: evidence that a user with discretionary authority still cannot bypass mandatory constraints.

5) Test both models with negative tests (prove it fails closed)

Build a small, repeatable authorization test suite:

• Pick representative subjects (standard user, data owner, admin, service account).
• Pick representative objects (one per label/classification tier).
• Execute tests that show:
  • DAC works within bounds (authorized owner can grant access through the approved method).
  • MAC overrides DAC (owner attempts to share an object in a way that violates policy and the system blocks it).

Retain test outputs and link them to the scoped subject/object list. (NIST SP 800-53 Rev. 5 OSCAL JSON)

6) Establish governance: exceptions, break-glass, and reviews

You need controlled mechanisms for reality:

• Exceptions: documented, time-bound, approved by data owner + security; include compensating controls.
• Break-glass: emergency access that is logged, alerted, and reviewed after use.
• Periodic access reviews: focus on discretionary grants and privileged paths that can mutate access.

Daydream (as a workflow and evidence system) fits naturally here: map AC-3(15) to a control owner, store the decision record, attach configuration exports and test results on a schedule, and track exceptions as expiring tasks so evidence stays current. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Required evidence and artifacts to retain

Keep evidence tied to “policy → implementation → operation”:

Policy / design

• AC-3(15) Decision Record: DAC definition, MAC definition, constraints, and covered subjects/objects. (NIST SP 800-53 Rev. 5 OSCAL JSON)
• Data classification/labeling standard (if labels drive MAC).
• Access control matrix (subjects × objects × allowed actions), at least for covered systems.

Implementation

• IAM/IdP configuration exports: roles/groups, admin delegation model.
• System configs showing MAC enforcement (label policy configs, conditional access rules, tenant boundary controls).
• Sample object ACLs for covered repositories/data stores.

Operational

• Access request tickets and approvals for discretionary grants.
• Audit logs for access changes and for blocked attempts where MAC denies.
• Test scripts and test results for DAC and MAC scenarios.
• Exception register with approvals, expiry dates, and compensating controls.

Common exam/audit questions and hangups

Assessors commonly probe:

• “Show me your covered subjects and objects list. Where is it documented and updated?” (NIST SP 800-53 Rev. 5 OSCAL JSON)
• “Where do users have discretion to grant access? Show the workflow and logs.”
• “Demonstrate a case where a data owner tries to grant access but the system blocks it due to MAC.”
• “How do you prevent service accounts from gaining broader access through role sprawl?”
• “How do you review discretionary grants for drift over time?”

Hangup to anticipate: teams describe RBAC and call it MAC. RBAC can be part of DAC or MAC depending on who can change roles and whether mandatory rules override role assignments.

Frequent implementation mistakes (and how to avoid them)

1. Policy says “we enforce DAC and MAC” with no definitions.
   Fix: write the decision record with concrete mechanisms and boundaries tied to named systems. (NIST SP 800-53 Rev. 5 OSCAL JSON)

2. No explicit “covered objects” scope.
   Fix: list the systems/data stores and keep a change-controlled inventory slice for AC-3(15).

3. MAC exists only as a guideline, not enforcement.
   Fix: implement a deny rule that cannot be overridden by owners (device trust, label-based denies, tenant boundary rules).

4. Testing only shows successful access, not denied access.
   Fix: add negative tests and keep the evidence.

5. Evidence scattered across teams.
   Fix: assign a control owner and a recurring evidence cadence. Daydream helps by centralizing control mapping and recurring artifacts so assessments don’t turn into a scavenger hunt. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so treat AC-3(15) as an assessment-driven control: the risk is control failure leading to unauthorized access, excessive sharing, and inability to demonstrate consistent enforcement during audits against NIST SP 800-53. (NIST SP 800-53 Rev. 5)

Practical 30/60/90-day execution plan

First 30 days (define and scope)

• Appoint control owner (IAM or security engineering) and compliance counterpart.
• Draft AC-3(15) Decision Record: DAC/MAC definitions, constraints, covered subjects/objects.
• Identify enforcement points per covered system (IdP, data platforms, collaboration tools, cloud).
• Stand up an evidence folder/index in Daydream and assign artifact owners. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Days 31–60 (implement and prove)

• Implement or tighten DAC workflows (group-based grants, approvals, logging).
• Implement at least one clear MAC control per covered tier (label-based policy, conditional access, or boundary enforcement).
• Create a repeatable DAC/MAC test plan with both allow and deny cases.
• Run the first evidence collection cycle: configs + sample logs + test outputs.

Days 61–90 (operationalize and audit-ready)

• Add exception workflow with expiry and periodic review.
• Schedule recurring evidence capture (configuration exports, access change logs, test reruns).
• Run an internal mini-assessment: answer the audit questions using only retained artifacts.
• Close gaps and document residual risk with compensating controls and ownership.

Frequently Asked Questions

Do we have to implement “true” government-style classification labels for MAC?

No specific labeling scheme is mandated in the provided excerpt, but you do need centrally enforced rules that cannot be overridden by user discretion, and you must define them in policy. If you already have data sensitivity tiers, you can map MAC enforcement to those tiers. (NIST SP 800-53 Rev. 5 OSCAL JSON)

We use RBAC everywhere. Does that satisfy AC-3(15)?

RBAC alone is not proof of both DAC and MAC. You must show where access can be granted at discretion and where mandatory rules override those grants, then demonstrate enforcement across covered subjects and objects. (NIST SP 800-53 Rev. 5 OSCAL JSON)

What are “subjects” and “objects” in plain terms?

Subjects are actors that request access (users, service accounts, processes). Objects are resources being accessed (files, records, tables, APIs, systems). AC-3(15) requires you to specify which of these are covered in policy. (NIST SP 800-53 Rev. 5 OSCAL JSON)

How do we prove MAC overrides DAC without building a custom system?

Use a denial scenario your current stack can enforce, such as conditional access rules, tenant restrictions, or label-based denies in a data platform. Document the scenario and retain logs or test outputs showing the deny occurs even when an owner tries to grant access. (NIST SP 800-53 Rev. 5 OSCAL JSON)

What evidence do assessors accept if we can’t export full configurations from a SaaS tool?

Provide what you can export (admin settings, role assignments, policy screenshots where exports are limited) plus audit logs and test results that demonstrate enforcement. Pair that with a clear policy definition and scoped subject/object list. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Where does Daydream help most for AC-3(15)?

AC-3(15) often fails on evidence and repeatability, not intent. Daydream helps by mapping the requirement to an owner and procedure, scheduling recurring evidence capture, and tracking exceptions to expiry so you can produce a clean assessment packet quickly. (NIST SP 800-53 Rev. 5 OSCAL JSON)