AC-3(3): Mandatory Access Control

AC-3(3) requires you to define a mandatory access control (MAC) policy and technically enforce it for the subjects (users, processes, devices) and objects (files, databases, services) you designate as “covered.” Operationally, you must document the labeling/clearance rules, implement enforcement points, and keep evidence that access decisions are consistently driven by the MAC policy, not discretion.

Key takeaways:

• You must write a MAC policy that specifies covered systems/data, labels, clearances, and decision rules, then enforce it (not just document it).
• Scope is the control: auditors will look for a crisp boundary of “covered subjects/objects” and proof enforcement is on those assets.
• Evidence needs to show repeatable operation: configurations, test results, exceptions, and change control history tied to the policy.

AC-3(3) is the “mandatory access control requirement” that separates aspirational policy from enforced, non-discretionary rules. If your environment includes regulated workloads (federal systems, contractor systems handling federal data, or service organizations supporting those systems), this control becomes a design constraint: access decisions must follow centrally defined rules based on attributes like classification, sensitivity labels, compartments, or other organization-defined tags.

For a CCO or GRC lead, the fastest path to operationalizing AC-3(3) is to treat it as a requirements package with four parts: (1) a written MAC policy that defines what is covered and what rules apply, (2) a technical mechanism that can enforce those rules at decision points, (3) a controlled exception path that does not turn MAC into ad hoc approvals, and (4) an evidence set that proves the mechanism is active, scoped correctly, and monitored.

This page gives requirement-level implementation guidance: what to define, where enforcement typically lives (OS, database, cloud IAM, service mesh, DLP/classification tooling), how to test it, and what artifacts to retain so an assessor can re-perform your logic quickly.

Regulatory text

Requirement (excerpt): “Enforce [organization-defined mandatory access control policy] over the set of covered subjects and objects specified in the policy, and where the policy:” (NIST SP 800-53 Rev. 5 OSCAL JSON)

Operator meaning: You must (a) define a mandatory access control policy, (b) explicitly list which subjects and objects the policy covers, and (c) enforce the policy through technical controls so access decisions are derived from mandatory rules rather than user discretion. The control is not satisfied by having role-based access control alone if users (or data owners) can arbitrarily override access outcomes outside the defined MAC rules. (NIST SP 800-53 Rev. 5 PDF)

Plain-English interpretation (what AC-3(3) is asking for)

Mandatory Access Control means the organization sets access rules based on defined security attributes, and individual users or resource owners cannot change those rules on the fly.

In practical terms, you:

• Assign attributes to subjects (clearance, role + compartment, device trust level, workload identity, etc.).
• Assign attributes to objects (data classification label, sensitivity tag, project compartment, export control tag, etc.).
• Enforce access decisions using a mechanism that evaluates those attributes against a policy you control (not per-folder “share” decisions by end users).

If your environment cannot support true MAC everywhere, you can still meet the requirement by scoping “covered subjects and objects” to the subset where MAC is required, then enforcing it rigorously there. Auditors will expect that scoping rationale to be documented and consistently applied. (NIST SP 800-53 Rev. 5 PDF)

Who it applies to (entity and operational context)

AC-3(3) commonly applies in these contexts:

• Federal information systems and programs aligned to NIST SP 800-53.
• Federal contractors and contractor systems handling federal data, especially where contract terms flow down NIST controls.
• Service organizations providing hosting, SaaS, managed services, or security services that support in-scope federal workloads. (NIST SP 800-53 Rev. 5)

Operationally, this hits teams running:

• Segmented environments (GovCloud / dedicated tenants / enclaves)
• Systems processing sensitive datasets requiring labeling
• Shared platforms where “least privilege” alone is not enough because data must be separated by mandatory policy (compartments/projects/programs)

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

Use this as a build plan you can assign across Security Engineering, IAM, Platform, and GRC.

1) Define the MAC policy (write it so it can be tested)

Create a short MAC policy document or standard that answers:

• Covered subjects: which identities are subject to MAC (human users, service accounts, workloads, devices).
• Covered objects: which resources must be protected by MAC (datasets, S3 buckets, file shares, schemas/tables, message topics, API endpoints).
• Label taxonomy: your labels/attributes (e.g., Public/Internal/Restricted, or program compartments), who can assign them, and how changes are approved.
• Decision rules: what label/clearance pairings allow read/write/admin, and what is always denied.
• Enforcement points: where decisions are enforced (cloud IAM conditions, database row-level security, OS-level MAC, policy engines).
• Exception rules: what can be approved, who approves, max duration, and required compensating controls.

Deliverable: a “control card” style runbook with owner, triggers (new system, new dataset, new identity provider), and operational steps so it runs the same way every time. (NIST SP 800-53 Rev. 5 PDF)

2) Scope “covered subjects and objects” into an inventory you can prove

Turn the policy scope into an auditable list:

• Systems/applications in scope
• Data stores and key datasets
• Identity sources and account types
• Administrative interfaces (console access, kubectl, database admin)

Practical tip: tie scope entries to your CMDB, cloud account inventory, or data catalog so you can show completeness without manually curated spreadsheets.

3) Choose enforcement mechanisms that are actually mandatory

Common enforcement patterns (pick what fits; you may need more than one):

• OS/platform MAC: SELinux/AppArmor for workloads that need kernel-level MAC.
• Cloud policy conditions: attribute-based access control using tags/labels and conditional IAM.
• Data-layer controls: database row-level security, column masking, or policy-based views mapped to subject attributes.
• Central policy engine: OPA/Gatekeeper, Cedar/AVP-style authorization, or service mesh authorization policies to enforce request-time decisions.
• Information protection tooling: classification + DLP rules that block exfiltration based on labels.

Your selection must support the core requirement: access outcomes are controlled by centrally managed policy, not discretionary sharing.

4) Implement labeling and identity attribute pipelines

MAC fails when labels and attributes are inconsistent. Build two pipelines:

• Object labeling pipeline: how a dataset/bucket/topic gets labeled at creation, how re-labeling works, and how you prevent unlabeled objects from becoming accessible.
• Subject attribute pipeline: how a user/service account gets clearance/compartment attributes, how changes are approved, and how terminations remove attributes.

Operational guardrails that exam teams like:

• “No label, no access” default for covered objects
• Attribute changes require ticket + approval + logging
• Automated detection of unlabeled or mis-labeled objects in scope

5) Test the policy with negative tests (prove denial)

Create a repeatable test plan:

• Attempt access with insufficient clearance and confirm denial
• Attempt cross-compartment access and confirm denial
• Attempt privileged override paths and confirm they are blocked or tightly controlled
• Verify logs show policy decision outcomes and the attributes evaluated

Store test results as evidence. Refresh after major changes (new label category, IAM refactor, new data platform).

6) Stand up exception handling that doesn’t break MAC

Exceptions are where MAC implementations collapse into “temporary admin access.” Set a strict path:

• Ticketed request tied to a business justification
• Approver independent of requestor
• Time-bound access with automatic expiry
• Compensating controls (session recording, heightened monitoring, limited data export)
• Post-exception review to remove recurring exceptions by fixing design gaps

7) Run control health checks and remediation

Operate AC-3(3) like a living control:

• Periodic checks that covered objects remain labeled
• Drift detection for policy enforcement points (IAM policies, OPA bundles, RLS configs)
• Review of exceptions and “break-glass” usage
• Track findings to closure with evidence

This addresses a common audit failure mode: teams can describe the design but cannot show it operates continuously. (NIST SP 800-53 Rev. 5 PDF)

Required evidence and artifacts to retain

Keep an “evidence bundle” that lets an assessor re-perform your control:

Policy & scope

• Approved MAC policy (versioned)
• List/inventory of covered subjects and objects
• Label taxonomy and attribute definitions
• RACI/ownership for label assignment and attribute granting

Technical enforcement

• Config exports/screenshots for enforcement points (IAM conditions, RLS policies, OS MAC config, policy engine bundles)
• Reference architecture showing where decisions occur
• Change records for policy updates (tickets/PRs)

Validation

• Test plan + test results (including denial tests)
• Sample logs demonstrating policy evaluation and denied decisions
• Monitoring/alerting rules for drift or unlabeled objects

Exceptions

• Exception tickets, approvals, duration, and expiry proof
• Compensating control evidence (session logs, alerts)
• Post-exception review notes

Retention location matters. Store artifacts in a controlled repository with access logging.

Common exam/audit questions and hangups

Auditors and customer assessors tend to focus on these points:

1. “Show me the covered boundary.”
   They will ask which systems and datasets are governed by MAC and why.

2. “Is it actually mandatory?”
   If a data owner can share a folder or change an ACL outside the policy, expect pushback unless you can show that behavior is out of scope or blocked.

3. “Where is the policy evaluated?”
   They will want named enforcement points and evidence of configuration.

4. “Prove deny.”
   Allow rules are easy to show; denial behavior is what demonstrates mandatory enforcement.

5. “How do labels and attributes get governed?”
   They will look for approvals, change control, and detection of mislabeling.

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails	How to avoid it
Treating RBAC as MAC without attribute-driven rules	RBAC can be discretionary and role sprawl hides policy intent	Use attributes (labels/compartments) and central decision logic mapped to them
Policy exists, but enforcement is partial	“Covered objects” not fully protected creates audit gaps	Define scope tightly and prove every in-scope object has enforcement enabled
Labels are manual and inconsistent	Mislabels become silent access control bypasses	Automate labeling at creation; run detection for unlabeled objects
Exceptions become permanent	Permanent exceptions defeat mandatory rules	Time-bound exceptions with expiry; track recurring exceptions to remediation
No operational evidence	Control “design” cannot be re-performed	Maintain a minimum evidence bundle per cycle (NIST SP 800-53 Rev. 5 PDF)

Enforcement context and risk implications

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

From a risk standpoint, AC-3(3) gaps usually surface as:

• Cross-tenant or cross-program data exposure in shared platforms
• Over-permissioned service accounts accessing restricted datasets
• Inability to demonstrate to federal customers that separation controls are enforced technically rather than procedurally

For regulated customers, failure to enforce mandatory separation often becomes a contractual noncompliance issue even before it becomes a breach scenario. Anchor your implementation to demonstrable enforcement and repeatable evidence. (NIST SP 800-53 Rev. 5 PDF)

Practical 30/60/90-day execution plan

Use phases rather than day-count promises; sequence work to produce audit-ready outputs quickly.

First 30 days (Immediate)

• Assign a single control owner and publish a one-page control card: objective, scope approach, enforcement approach, evidence list. (NIST SP 800-53 Rev. 5 PDF)
• Draft MAC policy: labels/attributes, decision rules, exceptions, and “covered” definition.
• Identify one “reference system” (highest-risk dataset or federal workload) as the pilot scope.
• Pick enforcement points for the pilot and define required logs.

Days 31–60 (Near-term)

• Implement labeling and attribute pipelines for the pilot (approvals + automation where feasible).
• Configure enforcement (IAM conditions/RLS/OPA/OS MAC) and run denial tests.
• Build the evidence bundle structure in your GRC repository: what gets saved, by whom, and where. (NIST SP 800-53 Rev. 5 PDF)
• Implement exception workflow and expiry mechanism for the pilot.

Days 61–90 (Operationalize and scale)

• Expand scope from pilot to the full set of covered subjects/objects defined in your policy.
• Add drift detection and periodic health checks; track remediation items to closure. (NIST SP 800-53 Rev. 5 PDF)
• Run a tabletop audit: have an internal reviewer request evidence and re-perform a sample of access decisions end-to-end.
• If you use Daydream, map AC-3(3) to a control card, attach the evidence bundle template, and schedule recurring health checks so ownership and proof stay current.

Frequently Asked Questions

Do we need SELinux/AppArmor to satisfy AC-3(3)?

No. AC-3(3) requires mandatory enforcement of an organization-defined MAC policy, but NIST does not prescribe a single mechanism. If cloud IAM conditions, database row-level security, or a policy engine enforces mandatory rules for your covered scope, that can satisfy the intent. (NIST SP 800-53 Rev. 5 PDF)

How do I define “covered subjects and objects” without boiling the ocean?

Start with the datasets and systems where separation is contractually required or where impact is highest, then explicitly declare that as “covered” in the policy. Auditors accept scoped controls when the scope is justified, consistently applied, and enforced. (NIST SP 800-53 Rev. 5 PDF)

What’s the minimum proof an auditor will ask for?

Expect requests for the MAC policy, the in-scope inventory, enforcement configurations, and test results that include denied access attempts. Also expect evidence of ongoing operation: change control history and periodic checks. (NIST SP 800-53 Rev. 5 PDF)

Can we handle MAC with tickets and manual approvals?

Manual approvals can support exceptions, but they do not replace technical enforcement for covered subjects and objects. If the control depends on humans to block access, assessors often mark it as procedural rather than mandatory. (NIST SP 800-53 Rev. 5 PDF)

How should we handle break-glass admin access under MAC?

Treat break-glass as an exception path: tight eligibility, short duration, strong logging, and a required after-action review. Keep break-glass from becoming the normal way work gets done by tracking frequency and removing root causes.

How does Daydream help with AC-3(3) operationalization?

Daydream is a practical place to store the control card, scope inventory, and the evidence bundle, then run recurring control health checks with tracked remediation. That directly addresses a common gap: teams can’t show ownership, cadence, or proof that the control keeps operating. (NIST SP 800-53 Rev. 5 PDF)